Brand Ship

When to use this

Use before a brand goes live, before handing a system to an internal team or an agency, and before the moment when fixing something becomes expensive.

Use it when the work looks finished. Looking finished is the condition this skill exists to test.

Do not use it to re-litigate strategy. If the strategy is wrong, that is a Brand Review finding and blocking here is too late to be useful — though you must still say so.

Inputs

Everything the system has produced, plus the things that are usually assumed: the actual source files, the actual exports, the actual templates in the tools people use, the font licenses, the live surfaces, the names of the people who will own each thing after launch.

Also the review-decision.md risk register and any unresolved blockers. Shipping over an unresolved blocker is a decision someone must make explicitly, not one that happens by omission.

Ask for evidence that each check was performed, not confirmation that it was. "Legal has looked at it" is not a record. Who, when, covering what scope, and what did they say?

Mission

Decide whether the brand can operate in the world, not whether it can be presented.

A brand ships into hands that were not in the room: a support agent writing at speed, a salesperson building a deck the night before, a contractor with the wrong font file, a developer implementing a color that fails contrast. The gate is about them.

Method

1. Define release scope. Markets, audiences, surfaces, assets, templates, applications, and explicit exclusions.
2. Audit the critical path — the encounters customers actually have first and most. Verify those before anything that only appears in the guidelines.
3. Verify strategic readiness. The position is decided, the proof exists or is scheduled, and the organization's behavior has been changed to match. A launched promise the company cannot keep is worse than no promise.
4. Verify expression readiness. Recognition holds without the logo. Verbal and visual systems agree. Applications exist in real form.
5. Verify asset integrity. Source files open. Exports are correct and named. Templates work in the tools people have. Fonts are licensed for the actual use, including web serving, embedding, and headcount tier. Documentation is current. Ownership is assigned.
6. Verify accessibility against a named standard. Record what was tested, how, what passed, what failed, and what was not tested.
7. Verify legal and cultural boundaries. Trademark, regulated claims, imagery rights, licensed assets, cultural references. Confirm each check was performed by the right authority — not that it was discussed.
8. Verify governance is operational. Decision rights populated with real people, source of truth reachable, exception log in use.
9. Verify measurement. Every claimed outcome has an owner, a baseline or an explicit statement that none exists, a signal, and a review date.
10. Record known limitations — understood, accepted, non-blocking, with owners.
11. Issue the verdict: SHIP, SHIP WITH KNOWN LIMITATIONS, or DO NOT SHIP.

What must be established

The difference between verified and assumed, for every line of the readiness matrix. "Templates exist" and "templates were opened and used to produce a real piece" are different claims, and only one of them is a check.

What was not verified. An honest unverified list is more valuable than a complete-looking matrix, because it tells the organization where its risk actually sits after launch.

Strong versus merely complete

The gate is strong when the DO NOT SHIP verdict is genuinely available and everyone knows it.

Failure modes

• Blocking on inconsequential preferences, which teaches the organization that this gate is noise.
• Shipping because the presentation is polished.
• Accepting a claim that a check was performed without recording who performed it and when.
• Verifying guidelines rather than applications.
• Launching with no baseline captured, making every later impact claim unfalsifiable. Baselines can only be taken before launch; this is the last moment.
• Recording limitations nobody owns, which converts them into surprises.
• Approving launch with no post-launch learning plan, so the organization never finds out what the brand actually changed.

Never claim without evidence

Never state that trademark clearance, legal clearance, regulatory compliance, cultural safety, or accessibility compliance has been achieved. Record what was checked, by which named authority, on what date, covering what scope — and record explicitly what remains unchecked. These are the claims that carry financial and legal consequence, and a release report is exactly where a false one does the most damage.

Never claim business impact from the launch. Record the measurement plan, the baseline, and the review point.

Never let "we believe it is fine" enter the report as verification. It is a known limitation.

Output

Produce release-report.md using the structure in references/release-report.md.

Verification

• Recheck every blocker personally. Blockers reported as resolved by the team responsible for them are the most common source of launch failure.
• Confirm the critical-path encounters were verified in their real form, not in a mockup.
• Confirm someone outside the core team can find the source of truth and use it to produce correct work. If they cannot, the system has not shipped regardless of what was delivered.
• Confirm every claimed outcome has a measurement owner and a baseline, or is explicitly marked as a hypothesis with no baseline.
• Read the unverified list aloud to whoever is accountable for the launch. If it surprises them, the review is not finished.
• Counterfactual pass. For each recommendation: if it were removed, what meaningful outcome becomes less likely? No credible answer means cut it, downgrade it, or reframe it.
• Fresh-eyes pass. Read the output as someone who must act on it and was not in the process. Cut process debris, duplicated findings, unearned certainty, and any sentence that impresses without changing a decision.

Complete when

The release decision is defensible, the limitations are known and owned, the organization can operate the brand without the people who built it, and there is a plan for learning what the brand actually changed.

Handoff

The post-launch learning agenda returns to Brand Intelligence as evidence for the next cycle — this is where the system closes. Unresolved risks return to Brand Review. Exceptions granted to ship return to Brand Governance with expiry dates, or they become permanent by default.