Writing
Prose-governance tokens — voice, rhythm, casing, register, and disclaimer
templates — for the same reason color and spacing are tokenized: a house
style decided once should be enforceable everywhere, not re-argued in every
document review. Like Paper, Writing tokens ship generically and empty of
tenant-specific vocabulary; a brand override repoints the alias the same way
themes/<brand>.json repoints color.
Voice
Active voice
Name the actor and the consequence. Default posture for every register below.
Planned / intended / may / target
Not-yet-true capabilities wear their status visibly — the BCSC disclosure posture, tokenized so it's mechanically enforceable rather than a style-guide sentence someone has to remember.
Mechanism, number, verifiable claim
Never borrow a named institution for prestige — support a claim with the mechanism and a real number instead.
Prefer concrete over abstract
use > utilize · end > terminate ·
explain > elucidate · a named number > a vague quantifier.
Rhythm
| Rule | Value |
|---|---|
| Target sentence length | 15–20 words (18-word house average) |
| Fact-of-record sentence ceiling | 25 words — a target for a definition/compliance/legal claim, not a hard gate |
| Paragraph length | 3–7 lines; past 7 a paragraph usually carries two ideas |
| Heading density | ~1 heading per 120–140 body words |
| Lead length | 100–400 words |
Casing
Title, heading, and slug casing follow one rule consistently: capitalize the first word plus proper nouns, acronyms, and code identifiers only — never a generic title-case pass, and no leading article ("the"/"a"/"an") on a title, heading, or slug.
Designing with the token registry
The Designing With The Token Registry
Register
Seven registers, each tied to a real content profile rather than a subjective "tone":
| Register | Posture |
|---|---|
| how-to | Operational imperative |
| reference | Neutral factual clause |
| communications | Institutional |
| journal | Academic |
| legal | Plain-language binding |
| specialist | Prescriptive normative |
| financial-disclosure | Precise compliance disclosure |
Content profiles compose registers rather than picking one in isolation: documentation blends reference + how-to; corporate and project pages read as reference throughout.
Financial-disclosure patterns
Four named, reusable prose patterns for the vehicle-proforma document family (Financial Report Layout / Proforma Vehicle Layout) — each backed by a real example pulled from a document that shipped, not invented copy. Narrower than a register (a posture) or a disclaimer template (a slot-fill string): a named move for a specific recurring situation.
| Pattern | When |
|---|---|
| Basis of preparation | The single closing paragraph of a vehicle proforma — issuer, security, holdings, cost-recovery, tax treatment, structural caveat, in order. |
| Form Note overlay opening | The opening paragraph of an optional/alternate-scenario section — what the base assumes, what triggers the alternate, what stays the same. |
| Forward-looking inline hedge | Any inline projection or target figure — a clause, not a sentence, reusing the document-level BCSC footer's hedge vocabulary. |
| Fixed-sum, not-conditioned-on-evidence | A fixed fee whose "reimbursement" framing could otherwise imply a documentation requirement that doesn't exist. |
Full pattern detail, each with its real shipped-document example: see
writing.semantic.pattern.financial-disclosure.* in
Tokens — Writing tier.
Entity-label pattern — cross-reference, not a duplicate token
Corporate-structure diagrams (org charts) have their own recurring labeling convention: legal name → registry code (monospace) → defined alias (quoted, italic) → jurisdiction (parenthesized) → node ID. That's a genuine Writing-shaped convention, but it's deliberately not a second token here. It's already defined, authoritatively, inside the Org Chart Print component's own recipe — the five stacked label zones. A parallel Writing token describing the same shape would just be a second copy of that definition. Duplicated tokens like that have drifted stale every time they've been tried, so this is a pointer, not a fork. Read the convention from the component.
Disclaimer templates
Four real, parameterized templates — placeholders resolve per tenant, never hardcoded to PointSav or Woodfine at the token layer:
| Template | Shape |
|---|---|
| Securities forward-looking | {corporate_entity} operates {technology_subsidiary} as {entity_relationship}... — forward-looking-statement notice with material-risk and no-update-obligation clauses |
| Trademark footer | {marks} are trademarks of {owner_entity}, used in {jurisdictions}... |
| Privacy posture | This interface operates on a {telemetry_scope} architecture. |
| Contact block | {role}, {entity}, {address}, {email}, {phone} |
Lexicon — ships empty by design
The banned/required-term and thematic-anchor lists are a real, defined structure with no generic entries — a brand override supplies actual terms the same way a theme file repoints color aliases. There is currently no PointSav- or Woodfine-specific term list published here; this page intentionally does not invent one.
Revision loop
One documented editorial pattern: draft-improves-draft — each
revision pass sets up a clearly better next pass, and a single pass revises
one altitude at a time (structure, then paragraph, then sentence), top-down
rather than mixing levels.
Important Information
Design System disclosure
This site provides open-source design tokens, documentation, and self-hostable software published by Woodfine Capital Projects Inc. Information here is for general reference only and does not constitute an offer, warranty, or a guarantee of fitness for any particular purpose. Statements regarding planned, intended, or targeted future features are forward-looking and subject to change without notice; they are not undertaken to be updated except as required by law.