Release 0.3.0-draft.1 · Development standards
A brand system is useful when people can tell which decisions are firm, which files to use and when a departure needs review.
Decision and release status
The current website identity is accepted for development. This exact 0.3.0-draft.1 package remains a draft production release. Logo preservation and blog exclusion are binding owner constraints; recommended dimensions, application recipes and new rules are proposed operating standards. A coherent handbook is not itself proof of print, accessibility, licensing or production approval.
Use separate records for approval (draft → review → approved → deprecated), technical verification (not run / pass / fail / blocked), and distribution (internal / named partner / public). A publicly accessible file can still be a draft. An approved asset may remain private.
Leigh / Woblar owns approval. Contributors may make documented proposals and reversible review artifacts within their task. Changes to logo geometry, brand architecture, core palette/family, material commercial claims or publication require the relevant owner decision. Routine crop, layout and typographic scale choices can be made within this system and reviewed with the deliverable.
Exceptions
Record the affected rule ID, purpose, audience/medium, proposed departure, reason, risk, scope, expiry, owner decision and evidence. Prefer the smallest departure that solves the problem. An approved exception for one supplier or campaign does not silently amend the general rule.
Asset lifecycle
Use descriptive filenames with purpose, variant, dimensions where helpful and version. Keep a source master, editable working source and exports distinct. Record provenance and licences in the asset register. Deprecation should identify the replacement and migration scope; preserve historical releases instead of overwriting their evidence. Do not treat old review art as a default because it is easier to find.
The existing /brand library is an authorised supporting reference after verification against this direction and the source assets. It is not automatically the authority for every old rule. Earlier terracotta, serif and lime-led concepts are superseded. Their files may remain for history but should never be routed into new production defaults.
Review quarterly and whenever offers, products, privacy behaviour, logo/font assets, platforms or claims change. Sample a campaign, a reading document, a tool flow and an agent output. Record findings and follow-through; a scheduled date alone is not a completed review.
Operating rules
GOV-001 — Keep release approval explicit
- Do: Keep new rules and assets draft until the owner approves the exact production release.
- When: Release, handover and publication
- Variation: Prepare complete review exports under authorised development work.
- Avoid: Equating identity direction acceptance or technical checks with release approval.
- Check: Check release identifier, owner decision and distribution scope.
GOV-002 — Make exceptions traceable
- Do: Record rule, reason, scope, expiry and owner decision for material departures.
- When: Any proposed departure from fixed identity or release controls
- Variation: Routine layout variation within documented ranges.
- Avoid: Quietly converting a one-off exception into the default.
- Check: Locate an exception record linked to the affected deliverable.
GOV-003 — Maintain one source of truth
- Do: Keep versioned source, exports, asset register and deprecation links aligned.
- When: Updates and agency handover
- Variation: Read-only export snapshots clearly labelled with their source version.
- Avoid: Competing independently edited manuals or silent asset replacement.
- Check: Compare release values, asset references and replacement routes.