Define the approval boundary before comparing offers
Start with the business situation, not a standard deliverables list. A pre-launch SaaS company that needs positioning, naming, a logo, a marketing site, and product direction faces a different buying decision from an established product that needs executable color and typography rules. Yet both may be sold as a brand identity package.
Write the boundary in one paragraph before you review proposals. Name the objective, included surfaces, intended consumers, internal owners, implementation work funded elsewhere, and exclusions. This keeps an impressive but narrow offer from winning by implication.
- Objective: launch, visual refresh, repositioning, merger, product expansion, or consistency repair.
- Included surfaces: website, sales deck, lifecycle communication, documentation, product UI, mobile app, or another named surface.
- Intended consumers: founders, marketing designers, product designers, developers, agencies, coding agents, or web builders.
- Internal owners: who may approve strategy, messaging, identity assets, product rules, licensing status, and implementation decisions.
- Separate work: website production, product design, component engineering, migration, content writing, accessibility review, or quality assurance.
- Exclusions: anything a reasonable buyer might otherwise infer from the package name.
Do not approve a category label
Terms such as full identity, design system, brand book, and AI-ready package have no fixed scope across providers. Replace each label with the exact artifact, format, owner, consumer, and evidence you expect.
Normalize the package with a scope matrix
Use these rows as comparison fields, not as a universal shopping list. Mark each one required, conditional, unresolved, or not applicable for your engagement. A row is required only when your stated objective or an intended surface depends on it.
| Default status to consider | Promised artifact to name | Approval evidence to request | |
|---|---|---|---|
| Strategic foundation | Required for positioning or rebrand work; otherwise conditional | Research summary, audience decision, positioning, brand principles, or another contracted record | Approved version, decision owner, exclusions, and unresolved disagreements |
| Verbal identity | Required when messaging or voice is in scope | Message hierarchy, value proposition, voice guidance, naming work, or copy examples | Named approver, approved version, intended channels, and excluded writing work |
| Logo system | Required for a new identity; conditional for a visual refresh | Editable master artwork, approved variants, minimum-size and misuse guidance, plus contracted exports | Artifact inventory, version, formats, variant coverage, and recorded rights or licensing review status |
| Color and typography | Usually required for a visual identity | Approved palette and roles, type families, roles, available weights, scale, and usage constraints | Editable or machine-readable values, source version, permitted substitutions, and unresolved licensing questions |
| Imagery, icons, and motifs | Conditional on the surfaces that use them | Asset library, art-direction rules, icon set, illustration system, or motif guidance | Source files, allowed transformations, provenance or recorded usage status, and examples tied to named surfaces |
| Marketing templates | Conditional on current campaign and sales needs | Named templates such as sales deck, social asset, case study, or landing-page system | Editable files, content limits, responsive variants where relevant, and an accountable maintainer |
| Product UI rules and states | Required only when product identity is in scope | Semantic roles, component treatments, interaction states, modes, responsive behavior, and product-specific exceptions | Coverage matrix for named surfaces and states; screenshots alone do not establish reusable rules |
| Implementation artifacts | Required when the package promises developer or agent readiness | Tokens, CSS, framework configuration, registry item, DESIGN.md, or another specified output | Artifact version, target environment, compatibility owner, mapping destination, and validation responsibility |
| Rights or licensing record | Required when assets or fonts need documented review | Recorded ownership, source, license, usage restrictions, transfer terms, or review status | Responsible reviewer and status for each relevant asset; the record is not independent legal validation |
| Documentation | Required when more than one person or tool must reuse the system | Brand guide, usage rules, decision log, asset index, or machine-readable instructions | Current version, named audience, source relationships, exclusions, and update owner |
| Maintenance and corrections | Required for an ongoing system; conditional for a fixed handoff | Support window, update process, change ownership, correction terms, and archive location | Named correction owner, response boundary, retest trigger, and final handoff date |
The owner and intended consumer matter as much as the artifact. A typography sheet may be complete for a marketing designer but insufficient for a developer who needs files, fallbacks, available weights, loading decisions, and UI roles. Record that mismatch instead of marking the entire row complete.
Use four field statuses consistently
- Required: approval depends on this field and its required evidence.
- Conditional: the field becomes required only for a named surface, channel, technology, or event.
- Unresolved: a decision or evidence item is still open and has an owner.
- Not applicable: the field is outside the recorded scope, with a reason.
Unresolved is a valid status during comparison. It isn't the same as omitted. An unresolved field stays visible, has an owner, and can become a contract item. An omission disappears until it causes a dispute.
Keep four proof boundaries separate
A package can promise an artifact, deliver it, map it into a project, and still fail in the final surface. Each step is a separate claim. Decide in advance which level the provider owes and which belongs to your implementation team.
| Declared | Delivered | Mapped | Observed | |
|---|---|---|---|---|
| Evidence | Proposal, statement of work, or package description names the obligation | An identifiable, versioned artifact exists in the agreed format | A named project or system points to the intended artifact or role | A named consumer was inspected under recorded conditions |
| What it proves | The provider promised the item within the stated scope | The agreed file or document was supplied | A downstream destination has an explicit relationship to the artifact | The tested surface produced the recorded result in that condition |
| What it does not prove | That the item was supplied, usable, or correct | That a project can consume it or that the result is acceptable | That the correct value reaches every consumer or state | That untested surfaces, modes, states, or environments behave the same |
| Typical owner | Commercial or project owner | Provider and receiving owner | Implementation owner | Reviewer for the named surface and condition |
Match evidence to the promise
A logo-only engagement may legitimately end with delivered files. A package that promises a working product design system needs stronger evidence. Don't demand runtime proof from an offer that excludes implementation, and don't accept a source file as runtime proof when implementation was promised.
Inspect the handoff, not the presentation
Review the actual delivery folder, document set, or export before approval. A case-study mockup shows a visual direction. It doesn't tell you whether the editable source, approved variants, current token values, or usage restrictions are present.
- Source and version: identify the governing file, document, or system and record its date or version.
- Delivered artifacts: list actual filenames or identifiers rather than broad categories.
- Editable and export formats: distinguish master sources from convenience exports.
- Variants and conditions: record logo arrangements, color modes, interaction states, responsive cases, and channel-specific versions that are in scope.
- Typography: record roles, family names, available weights, substitutions, and any unresolved loading or licensing work.
- Color: distinguish raw palette values from semantic roles and record whether light and dark values exist where promised.
- Intended destinations: name the website, product, deck system, repository, builder, or agent expected to receive the output.
- Restrictions and exclusions: record prohibited uses, allowed transformations, work reserved for another team, and claims the artifact does not establish.
- Open decisions: retain blank or disputed fields as unresolved items with owners and due conditions.
Treat usage and licensing as a recorded status, not a casual checkbox. The acceptance record can show which review was supplied, who owns the remaining question, and what use was contemplated. It can't independently establish legal rights.
Copy the proposal-to-handoff acceptance record
Create one record for each meaningful package layer or artifact group. Complete the contracted fields before delivery so both sides know what approval requires. At handoff, replace promises with exact artifact identifiers and evidence states.
package_item: ""
status: required | conditional | unresolved | not_applicable
reason_for_status: ""
source:
location_or_identifier: ""
version_or_date: ""
approved_by: ""
contracted_scope: ""
promised_artifact: ""
delivered_artifact:
location_or_identifier: ""
version_or_date: ""
editable_or_export_format: ""
recorded_usage_or_licensing_status:
status: ""
reviewed_by: ""
restrictions_or_open_questions:
- ""
owner: ""
intended_consumers:
- ""
exclusions:
- ""
unresolved_fields:
- ""
approved_exceptions:
- ""
required_evidence:
declared: required | not_applicable
delivered: required | not_applicable
mapped: required | not_applicable
observed: required | not_applicable
evidence_locations:
declared: ""
delivered: ""
mapped: ""
observed: ""
correction_owner: ""
retest_trigger: ""
disposition: accept | revise | block
decision_owner: ""
decision_date: ""
notes: ""Choose accept, revise, or block
| Use when | What happens next | |
|---|---|---|
| Accept | Every required item has the promised artifact and required evidence; exclusions and open non-blocking work are explicit and owned | Record the accepted version, archive the evidence, and hand named artifacts to their intended consumers |
| Revise | The package is substantially delivered, but a correctable artifact, format, variant, record, or non-critical evidence item is incomplete | Assign the correction owner, preserve the current version, and retest only the affected acceptance fields |
| Block | A required obligation is absent, the delivered artifact contradicts the approved source, essential rights status is unresolved, or no authorized owner can resolve a material gap | Do not approve or ask downstream teams to implement the disputed item; return it to the accountable owner |
A revision isn't a softer word for an unknown obligation. Use it when both the promise and the correction path are clear. Block when the missing decision changes what was bought, who may use it, or whether a critical intended consumer can proceed.
Worked record: Ambient Sage v1 covers one package layer
Ambient Sage v1 works as an example because its public evidence is specific. It is an implementation-ready design kit, not a complete agency-style SaaS identity package.
Token specimen · real values
Ambient Sage
Live renderAmbient Sage's actual tokens — the same values its exports use.
| Recorded result | Evidence state | |
|---|---|---|
| Scope status | Required only if this buyer needs an implementation-ready design-kit layer | Declared and delivered |
| Typography | Plus Jakarta Sans for headings and body; JetBrains Mono for mono, with the recorded weight sets | Delivered in the public kit evidence |
| Semantic color system | 28 semantic color tokens with light and dark values | Delivered in the public kit evidence |
| Guidance and exports | DESIGN.md plus shadcn, Tailwind, and DTCG exports | Delivered; consuming-project compatibility remains unverified |
| Strategy and verbal identity | Positioning, messaging, naming, and voice are outside this artifact's evidence | Not established by this artifact |
| Logo system | No logo design or logo handoff is established by the design-kit evidence | Outside this artifact's evidence |
| Usage or licensing approval | A buyer-specific approval record has not been supplied by this example | Unresolved for the buyer to route to the responsible reviewer |
| Project mapping | No consuming repository or builder is named in this example | Unresolved until a project owner maps the artifacts |
| Accessibility and runtime behavior | No product surface, state, viewport, assistive technology, or runtime condition was tested by this record | Unresolved and requires separate evidence |
That boundary is useful in a commercial comparison. A buyer can compare the design-kit layer with an agency package without treating them as substitutes. If the brief also requires positioning, messaging, naming, logo creation, or legal review, those rows still need another artifact and owner.
Inspect an implementation-ready layer before comparing it
Use Ambient Sage to see the token, typography, spacing, and guidance layer in context. Then return to the matrix and mark which strategic, identity, legal, and implementation responsibilities still sit elsewhere.
Route implementation work after package approval
Package acceptance should stop where implementation begins. Once the upstream artifacts are approved, use the brand-kit-for-web-developers guide to prepare developer intake. Use the brand-guidelines-for-saas-product-ui guide when approved identity rules must become product roles, components, states, modes, and local exceptions.
Keeping the stages separate prevents two opposite mistakes. One is rejecting a valid identity engagement because it excluded implementation work. The other is approving an implementation claim because the provider delivered attractive upstream assets.
An export is a handoff input
A token file, DESIGN.md, framework configuration, or registry item can carry approved decisions into a project. It doesn't prove that the project accepts the format, maps the intended roles, uses the current version, or renders the expected result.
Find the first divergence when a handoff is disputed
When the delivered package and a downstream result disagree, don't assign blame from the screenshot. Trace the chain in order. Stop at the first point where the recorded expectation and evidence part company.
- 1
Check the contracted promise
Confirm that the disputed item was actually required, identify the promised artifact and evidence level, and read the exclusions. If the work was excluded, route the new need as a scope decision.
- 2
Inspect the delivered artifact
Compare the exact delivered version with the approved source. Check whether the required file, rule, variant, or value is present and current.
- 3
Inspect the export or distribution step
If the source is correct, verify that the expected export or distributed artifact was produced from it. Record the version, destination, and any transformation.
- 4
Inspect the consuming-project mapping
Check whether the named project maps the delivered role or asset to the intended destination. A valid export can still be unused, stale, or mapped to the wrong local role.
- 5
Check approved local exceptions
Determine whether the consumer intentionally overrides the shared decision. An approved exception records a different rule; it doesn't prove that the upstream package failed.
- 6
Observe the named consumer
Reproduce the issue in the recorded surface, state, mode, viewport, and environment. Assign correction ownership to the first divergent layer and define the smallest retest that can close it.
This process also prevents unnecessary rework. If the delivered artifact is correct and the first divergence is a stale project mapping, the provider doesn't need to redesign the source. If the source omitted a contracted state, a local patch shouldn't quietly become the permanent answer.
Approve one important consumer before the whole package
Before signing off, complete the acceptance record for the most important intended consumer. For a launch, that might be the marketing site. For a product refresh, it might be the primary application shell. For an agent-ready handoff, it might be the repository or builder expected to consume the kit.
If you can't name the source, artifact, owner, exclusions, required evidence, and correction path for that one consumer, the package isn't ready for broad approval. Mark the exact gap as revise or block, assign it, and retest after the responsible layer changes.
Sources
- Brand Identity Design Services for SaaS & Tech - Orbix Studio: The captured service page places strategy, messaging, logo design, visual identity, brand guidelines, and adjacent SaaS design services within a broad commercial offer.
- How to Build a Clear Brand Identity for B2B SaaS Companies: The guide treats audience, positioning, mission, values, messaging, and visual foundations as distinct parts of B2B SaaS brand development.
- Brand identity for AI & SaaS startups - The Branx: The captured package names creative strategy, logo, color, typography, imagery, a brand guide, and Figma, PDF, and LLM-readable outputs, illustrating how one provider defines a particular scope.
- SaaS Brand Identity Through Product Design - Nexaflow: The article treats the product interface as a major brand surface and provides an audit workflow for finding differences between marketing and product.
- What exactly should I hand over as final deliverables for a SaaS logo project?: The discussion records practical uncertainty about logo variants, file formats, usage guidance, color specifications, source files, and what the original agreement required.
- Ambient Sage Design Kit: The public Ambient Sage v1 page identifies Plus Jakarta Sans and JetBrains Mono roles, 28 semantic light and dark color tokens, DESIGN.md, and implementation exports.
- Brand kit for web developers: The guide separates approved identity inputs, delivery artifacts, project consumers, unresolved decisions, and implementation acceptance evidence.
- Brand guidelines for SaaS product UI: The guide separates portable brand intent, reusable design-system contracts, product mappings, local exceptions, and observed product behavior.