Broad branding guides reasonably cover research, positioning, identity, voice, and application. A developer handoff begins later. Its job is to translate approved brand direction into website decisions without asking the implementer to invent missing policy or design rules.

Keep six kinds of material separate. Traditional identity assets include logos, marks, brand colors, typefaces, photography, illustration, and verbal guidance. Website design decisions assign those materials to semantic roles, scales, layouts, modes, and usage rules. Product requirements define behavior, permissions, validation, content, and recovery. Delivery artifacts carry approved design decisions into a repository or tool. Implemented consumers are the components and surfaces that read those artifacts. Acceptance evidence records what was checked and what remains unresolved.

Record each decision as a chain from authority to evidence. This exposes two common mistakes: treating the latest export as the source of truth, and treating a correct token value as proof that the interface uses it correctly.

• Artifact: the asset, rule, token group, file, or reference under review.
• Source of truth: the approved location and version that has authority over the decision.
• Semantic purpose: what the decision means in the interface, not merely its visual value.
• Delivery format: how the decision reaches the project, such as written guidance, DTCG tokens, CSS variables, a Tailwind theme, or a registry item.
• Intended consumer: the component, template, agent, build tool, or runtime style layer expected to use it.
• Owner: the person or team allowed to resolve ambiguity or approve a change.
• Permitted changes: transformations the implementer may make without returning for approval.
• Known omissions: required roles, modes, states, breakpoints, assets, or rules that the source does not define.
• Acceptance evidence: the surface, state, viewport, mode, and observable result used to verify the implementation.

artifact: ""
status: ready-to-implement | requires-decision | reference-only | outside-handoff
source_of_truth:
  location: ""
  version_or_date: ""
  approved_by: ""
semantic_purpose: ""
delivery:
  format: ""
  path_or_identifier: ""
intended_consumers:
  - ""
owner: ""
permitted_changes:
  - ""
known_omissions:
  - ""
acceptance_evidence:
  surfaces:
    - ""
  states:
    - ""
  viewports_or_containers:
    - ""
  color_modes:
    - ""
  expected_observation: ""
notes: ""

The status field controls what happens next. It prevents a reference image from gaining accidental authority and keeps undefined requirements out of the implementation queue.

• Ready to implement: the authority, semantic purpose, consumer, permitted changes, and relevant acceptance conditions are explicit.
• Requires a decision: the input is relevant, but at least one material rule is missing or contradictory. Assign an owner and block only the affected work.
• Reference only: the item communicates direction or context but is not precise enough to govern implementation. Mood boards and campaign mockups often belong here.
• Outside the website handoff: the item belongs to another discipline or deliverable, such as trademark review, campaign planning, product permissions, or final editorial copy. Record the boundary so its absence is not mistaken for a developer task.

Classification is granular. A logo package may be ready for placement while its minimum size at narrow widths still requires a decision. A color system may be ready for light mode while dark mode remains undefined. Splitting the record this way lets work continue without hiding the unresolved part.

Raw colors are ingredients. Website code needs roles such as page background, foreground, card, muted surface, border, primary action, destructive action, focus ring, and status colors. Each foreground and surface pairing needs an intended use. If light and dark modes are supported, record both mappings and say whether a mode may fall back to another value.

Do not derive error, warning, success, selection, or focus colors from a brand accent unless the authority assigns those meanings. The same hex value can be valid as a campaign color and wrong as an interface role.

Record the family for each role, the approved weights, the type scale, line-height rules, letter spacing, fallbacks, and where mono or display faces are allowed. A font family name alone leaves the browser and developer to choose weights and metrics. It also says nothing about headings, body copy, labels, buttons, tables, or numerical data.

Font delivery is a separate implementation decision. The brand kit can approve families and roles while the project still needs a loading strategy, available files, fallbacks, and performance checks. Those technical choices should preserve the approved roles without pretending the visual handoff settled every delivery trade-off.

Specify the spacing scale, page gutters, content widths, section rhythm, grid behavior, corner radii, borders, shadows, and recurring motifs that make the system recognizable. Name exceptions. If a motif is decorative, say where it may appear and how it behaves in constrained containers.

For logos, record the approved variants, clear space, minimum useful size, background restrictions, and whether cropping or recoloring is permitted. For photography and illustration, include selection and treatment rules rather than a folder of examples alone. Alternative text and content meaning still depend on the actual page context; a brand asset library cannot supply them universally.

Breakpoints, container behavior, reflow, truncation, navigation changes, density, and touch targets are website decisions. Hover, focus, pressed, selected, disabled, loading, success, empty, and error states need requirements where the product can reach them. A static brand board does not define those behaviors.

The handoff may define visual treatment for buttons, inputs, cards, navigation, tables, charts, and dialogs. It does not automatically define what those components do. Permissions, validation, confirmation, cancellation, data handling, and recovery belong to product requirements. Keep that authority separate even when both kinds of rule appear in the same interface.

The public Ambient Sage kit shows how several handoff layers can connect. It assigns Plus Jakarta Sans to heading and body roles, with weights 400, 500, 600, and 700. JetBrains Mono fills the mono role at weights 400, 500, and 700. The published scale is compact-product. Its color system includes semantic roles for light and dark modes, while written guidance describes a warm-sage canvas, tonal card treatment, restrained yellow accent, and oversized numerical values.

This is more useful than a font list because it links families to roles and weights, and more useful than a palette because it provides semantic mappings and usage guidance. The same kit is available through DESIGN.md, DTCG token JSON, CSS variables, Tailwind outputs, shadcn registry JSON, a registry installation path, the Identity Forge CLI, and MCP access.

The example has firm limits. It does not prove that Plus Jakarta Sans and JetBrains Mono are the best pairing for another product. It does not establish another product's component behavior, responsive rules, content requirements, accessibility conformance, or production readiness. Those decisions still need local owners and evidence.

A delivery artifact should carry an approved decision without quietly becoming the authority that created it. Record which source produced the artifact, when it was generated, and which consumer reads it. If an export and its source disagree, resolve the source or regeneration path before patching the visible component.

• DESIGN.md carries intent, usage rules, layout guidance, motifs, component treatments, and constraints that are difficult to express as token values.
• DTCG tokens provide a structured representation that can feed tools or transformations while retaining token names and values.
• CSS variables expose theme values directly to styles and components. Their presence does not prove that every component references the correct role.
• Tailwind output maps decisions into the project's utility and theme conventions. Local utilities can still override or bypass the mapping.
• A shadcn registry item packages values for a compatible installation path. It remains a delivery mechanism, not evidence that the installed components satisfy every brand rule.
• CLI access applies or writes artifacts into a project. MCP access lets a compatible agent discover, read, or apply kit information. In either case, the receiving project still needs a declared authority and acceptance record.

Choose surfaces that exercise different roles instead of checking every route superficially. Include the modes, states, and container widths the product actually supports.

• Navigation: logo treatment, active state, hierarchy, focus, and narrow-width behavior.
• Headings and body copy: role mapping, permitted weights, line length, wrapping, and vertical rhythm.
• Forms: labels, inputs, help text, validation, disabled controls, focus, and recovery states that are in scope.
• Buttons and links: primary, secondary, destructive, pressed, disabled, and focus treatments where required.
• Cards and overlays: surface roles, foreground pairings, borders or tonal separation, radius, spacing, and stacking.
• Tables or metrics: heading hierarchy, numerical treatment, alignment, density, long values, and empty states.
• Status states: success, warning, error, selection, and loading roles without inventing meaning from decorative colors.
• Light and dark modes: semantic parity, legibility, local overrides, and components that retain a raw light-mode value.
• Narrow containers: wrapping, reflow, clipping, navigation changes, and motifs that compete with content.

A screenshot can reveal a mismatch but rarely identifies its owner. Trace one approved decision through the complete chain. A controlled change makes stale or bypassed layers visible.

1. 1

   Choose one low-risk approved decision

   Use a reversible token or typography mapping that has a clear source and a representative consumer. Record the current source version and expected surfaces.

2. 2

   Confirm the authoritative record

   Verify the semantic purpose, allowed modes, owner, and expected value or rule. If authority is ambiguous, stop the test and route that ambiguity first.

3. 3

   Regenerate or update the selected delivery artifact

   Use the normal delivery path. Record the artifact version or resulting change so an outdated export can be distinguished from an incorrect implementation.

4. 4

   Inspect the intended consumer

   Confirm that the relevant component or style layer reads the semantic role. Look for raw values, aliases, copied constants, framework defaults, and local overrides.

5. 5

   Check representative surfaces

   Inspect the applicable state, viewport, container, and color mode. Record both the expected change and any surface that did not change.

6. 6

   Classify every mismatch by layer

   A wrong source decision returns to the design owner. A stale export returns to the delivery process. A bad mapping belongs to the consumer integration. A local override belongs to the implementation. A change elsewhere may be unrelated drift and should not be folded into the brand fix without evidence.

7. 7

   Restore or approve the controlled value

   Return to the approved value unless the test itself was an authorized update. Preserve the evidence record either way.

Finish intake with an explicit decision. Approval should be scoped to the decisions and surfaces supported by the evidence, not phrased as a general claim that the brand or website is complete.

decision: approve | revise | block
scope:
  decisions: []
  consumers: []
  surfaces: []
  modes: []
  viewports_or_containers: []
resolved_evidence:
  - decision: ""
    source_of_truth: ""
    delivery_artifact: ""
    observed_result: ""
unresolved:
  - issue: ""
    classification: missing-decision | stale-artifact | consumer-mapping | local-override | unrelated-drift
    owner: ""
    required_evidence: ""
    next_action: ""
    blocks: ""
permitted_implementation_step: ""
reviewed_by: ""
reviewed_on: ""

The next implementation step should follow directly from this record. Apply the approved artifact when the chain is complete. Request a named decision when authority is missing. Fix the identified delivery or consumer layer when the source is already correct. That keeps the developer from turning an unresolved brand question into a permanent local convention.

• How To Build a Brand From Scratch (2026): Shopify presents the brand kit and style guide within a broader process that also covers audience research, voice, naming, story, logo creation, application, and measurement.
• What is a Brand? Definition and Examples: Ramotion describes brand components across visual identity, verbal identity, interaction experiences, values, and positioning, showing that a brand extends beyond a logo.
• What is Branding? Understanding Its Importance: HubSpot covers brand strategy, visual assets, voice, and application across websites and other channels as parts of a broader branding process.
• Ambient Sage Design Kit: The public Ambient Sage kit documents Plus Jakarta Sans for heading and body roles, JetBrains Mono for the mono role, semantic light and dark tokens, written guidance, and several developer delivery formats.
• How to generate a DESIGN.md (and what it is): Identity Forge describes DESIGN.md as a written design brief containing intent, color and type systems, layout and spacing rules, component treatments, motifs, and explicit usage constraints.
• Semantic color tokens explained: Identity Forge explains that semantic tokens name colors by purpose, such as background, foreground, primary, border, and ring, rather than by raw hue.
• AI UI review checklist: test generated interfaces before you ship: The review guide separates product requirements, design authority, delivery artifacts, implementation evidence, and accessibility evidence, and recommends tracing controlled changes to the layer responsible for a mismatch.
• Shadcn design system generators: do you need a theme, a system, or an agent handoff?: Identity Forge distinguishes a visual theme from a broader design system and an agent handoff, and recommends inspecting token meaning, mode parity, typography, layout guidance, installation routes, and known gaps.