Project · Template library

Project template library — states gallery

The project-level half of the composition template system: the seven reusable objects a creator authors once and applies to many collections. Every object here is versioned, immutable once published, and never read at runtime — they exist to help an author construct a collection-local artefact, which is the only thing the runtime trusts.

The companion gallery covers the collection side — applying these, resolving conflicts, compiling contracts: composition-apply-states-gallery-2026-08-19.html.

Specs: Phase2/Composition Template System/token-contract-system-spec.md §2–§4D · state-policy-design.md · token-variant-actions-spec.md. Chrome follows build-mocks/style-guide/page-shell.md.
01Library home · seven object typesReached from the project shell. Each card routes to that type's list. Counts are per project. The composition card is visually last because it references the others — it is the bundle, not a peer.
Studio/Project: Neon District/Templates
Project · Templates

Templates.

Author once, apply to any collection in this project. Editing a template never changes a collection that already applied it.

Attribute template6Sets of attribute definitions. No requirement levels — those live on the token type.Latest · Trading card core v3
Token type template4A token type plus its full attribute assignment matrix.Latest · Trading card v2
Asset spec3Required media slots that gate go-Live. Existence only, never content.Latest · Graded slab v2
Tier set template2Custom rarity tiers. Tiered mode only — Uniform has nothing to configure and Weighted's tiers are platform-fixed.Latest · Military ranks v1
Variant profile3A variant set — keys, names, optional assets. Never the topology.Latest · Seasonal reskin v1
State policy2What may change after claim, who may change it, under what limits.Latest · Garden pet v1
Action template5Trigger presentation — button wording and warning text.Latest · Open v2
Composition3One pinned reference per axis, applied in a single action. Authoring only — nothing pins it, runtime never reads it.Latest · Graded card — TAG v4
02Create a template · two entry points here, one in the collectionThe library creates from blank or by duplicating a version. Promotion is not a library action — you save what you built from the collection you built it in, because that is where the object is and where you can see it. The library's job is to make sure you know promotion exists (see the empty state below). All three paths produce a Draft head.

Why promotion isn't a library action: starting here would mean a picker that reaches into a collection to find an object you can already see on screen. It is a "save what I built" action, so it belongs on the thing being saved — the same reason Save As lives in the document, not the template gallery. It is the exact inverse of apply: apply snapshot-copies project → collection, promote snapshot-copies collection → project, and neither creates a link.
+ New template · in the library
BlankStart from nothing
Duplicate a versionVary a working setup, or diverge for one collection
Promote from a collectionnot here — done from the collectioncollection
Blank · new token type template

Immutable after creation. Renaming later changes the label only.

You can publish with none, then add them later — each edit opens a new Draft.

Empty library · where discovery has to happen
Project · Templates

No templates yet.

Templates let you set something up once and apply it to any collection in this project. Start from scratch — or, if you have already built a collection you are happy with, save that setup as a template from the collection itself.

This is the one place the library must mention promotion. A creator with an empty library has no templates because they have not built anything yet — or because they have, by hand, and do not know they can keep it. The second sentence and the second button exist for that person.

03Draft and Published · two states, no ReviewTemplates never go Live and have no Review stage. The three-stage model exists because collection and token go-live is public, irreversible and involves money — none of which applies to an object that is never public and never read at runtime. What the split does buy is the thing that matters: a half-authored template cannot be applied.

Editing a published version opens a new Draft head — it never mutates the version. One Draft head per object at a time. A Draft can always be discarded; a published version can be deleted only while nothing Live derives from it.
Draft · the working head
Trading card3 of 6 attributes assignedDraft
!
Not appliable yet. Publish this to make it available to collections.
Published · immutable, appliable
Trading card v2Applied by 4 collectionsPublished
Trading card v1Pinned by 2 Live collectionsUndeletable
04Attribute template library · definitions onlyA template holds definitions only — key, label, kind, arity, constraints. It carries no requirement levels: required versus optional belongs to the (token_type, attribute) pair, which is why the token type template exists and why assignment is mandatory on every apply. The list shows which collections applied each version, so a change can be reasoned about before it is made.
Neon District/Templates/Attribute templates
Project · Attribute templates

Attribute templates.

Sets of attribute definitions, applied into a collection's master schema.

TemplateVersionAttributesApplied byState
Trading card core
v3set_name · card_number · year · foilPaper Trail · Corner Shop2 Live
Trading card core
v2set_name · card_number · yearVaulties1 Live
Print run
v1print_run · printerPaper TrailDraft only
Slab grading
v1grader · grade · cert_noNot applied yetEditable
Showing 4 of 6 versionsA version applied by a Live collection cannot be deleted
Trading card core · v3
1set_nameCategory · single-select · 12 allowed values
2card_numberText · max 16 chars
3yearNumber · 1900–2100
4foilBoolean
05Token type template · the assignment matrixThe object that closes the biggest gap. An attribute template carries definitions only, and assignment is a mandatory step of every apply — so without this a creator re-authors the type and re-assigns every attribute in every collection. Referenced attribute templates are pinned to a version; anything left unassigned lands unassigned, which is a valid state meaning "not allowed on this type".
Studio/Neon District/Templates/Token type · Trading card
v2 · draft
Project · Token type template

Trading card.

Applied to a collection, this creates the token type and writes the matrix below, so the mandatory assignment step is already satisfied.

Attribute templates referenced
Trading card coreset_name · card_number · year · foilv3 pinned
Print runprint_run · printerv1 pinned
Template

Immutable after creation. Renaming changes the label only.

AttributeFromKindLevel on this type
set_nameTrading card core v3Category
card_numberTrading card core v3Text
yearTrading card core v3Number
foilTrading card core v3Boolean
print_runPrint run v1Number
printerPrint run v1Text
Showing 6 of 6 attributesEvery attribute has a level — unassigned is one of them
06Tier set template · Tiered rarity only, with reserved-name validationOffered only for Tiered. Names and colours must not reuse the reserved Weighted official set or its palette — validated at save time in the library, so a template can never be stored in a state that would fail on apply. Nothing supply-dependent is carried: quotas and budgets compute against each collection's own Max Supply.
Valid · saved
1General#92580B
2Colonel#6366F1
3Sergeant#10B981
4Private#6B6B6B
i
Order is identity — rarest first. Reordering a saved template produces a new version.
Rejected · reserved name
1Legendary#92580B
2Colonel#6366F1
Legendary is reserved for the Weighted official tier set. Choose a different name.
!
Reserved names: Inconceivable · Mythical · Legendary · Epic · Rare · Uncommon · Common. Reserved palette: amber · violet · blue · green · slate.
07Variant profile · the set, never the topologySeeds a token definition's variant list — keys, names, an optional pinned asset each. Which variant reaches which stays declared per token, because from_variant indexes that token's own list. A profile is what a hundred tokens sharing two variants needed: authored once instead of two hundred by hand.
Templates/Variant profile · Seasonal reskin
v1
Project · Variant profile

Seasonal reskin.

Two variants, no outcome payload — a pure reskin, so a transitioned copy stays stackable into its new variant class.

1standardasset · none → falls back to primary
2holidayasset · media/holiday-frame
i
Topology is not here. After applying this profile, declare Reached from on each variant in the token's Variants tab. Bulk "set reached-from" tooling exists for applying the same shape across many tokens.
08Composition · one pinned reference per axisThe bundle. Every axis is optional and an absent axis is absent — no "none" placeholder object. Applying a composition is exactly equivalent to applying each referenced template in turn, then compiling: it is a macro, not an authority.
Templates/Composition · Graded card — TAG
v4
Project · Composition

Graded card — TAG.

Applied at the point a token type is set up in a collection — the one moment every axis has somewhere to land.

Axes
Token type profileTrading cardv2 pinned
Asset specGraded slabv2 pinned
Tier set templateabsent — Weighted uses the official tier setabsent
Variant profileabsentabsent
State policyabsentabsent
Deltas · the closed set
slot_requirementdig_report → optional

Only two overrides exist: attribute_requirement and slot_requirement — requirement-level flips. Anything structural is a second profile version, never a delta.

09Version pinning · what freezes and what stays editableA variant binds an exact template version. When a token goes Live, the versions it pinned become immutable — the template itself stays editable, and each edit makes a new version future tokens may pin. Editing never reaches a Live token. This is deliberately narrower than freezing a whole template, which would reach across every collection in the project.
Templates/Action template · Open
Project · Action template

Open.

Versions, their pins, and what each one can still do.

VersionButton wordingPinned byState
v1Open it4 Live tokens · Corner Shop, Paper TrailFrozen
v2Open2 Live tokens · VaultiesFrozen
v3Open walletNo pins yetEditable
Showing 3 of 3 versionsA version with a Live pin cannot be deleted. An unpinned version can.
✓
Editing this template is safe. It produces v4; v1 and v2 keep serving their Live tokens exactly as they were pinned.
10Delete · the confirm names the affected collectionsDeleting a template that variants on Draft/Review tokens still bind clears those triggers. Because the library is project-scoped, the confirm must name the collections, not just a token count — someone deleting from the project library may not have the dependent collection in mind. Canonical red destructive confirm, left-aligned.

Delete template · Open v3?

✕
This clears the trigger on 3 variants across 2 collections — they will have no action button until a new trigger is set. This can't be undone. Live tokens are unaffected: they pinned v1 and v2.
Corner Shop2 variants · DraftDraft
Vaulties1 variant · ReviewReview
11Ownership referenceNot a screen — the reference a developer needs beside the build. A grey reference table placed next to the feature it documents, per the style guide's notes-and-alerts rule.
Who owns what · from token-contract-system-spec.md §2.1
ObjectLives inEditable whileFrozen byRuntime reads it?
Attribute templateProject libraryAlwaysNever — new versionsNo
Token type templateProject libraryAlwaysNever — new versionsNo
Asset specProject libraryAlwaysNever — new versionsNo
Tier set templateProject libraryAlwaysNever — new versionsNo
Variant profileProject libraryAlwaysNever — new versionsNo
State policyProject libraryAlwaysNever — new versionsNo
Action templateProject libraryAlwaysPinned versions freeze at token LiveNo
CompositionProject libraryAlwaysNever — new versionsNo — authoring only
Master attribute schemaCollectionDraft · ReviewCollection LiveVia the contract
Token typeCollectionDraft · ReviewCollection LiveVia the contract
Collection rarity + tiersCollectionDraft · ReviewCollection LiveYes
Token contractCollectionNever — immutablePublishedYes — sole authority
Variant set + topologyToken definitionToken DraftToken LiveYes
Attached policy snapshotToken definitionToken Draft · ReviewToken LiveYes
State valuesHoldingPer the policy's write rulesNever — living memoryYes

Three rules fall out of it. A project object is never authority — it is a source you copy from. A collection or token object is always authority, and always local. Runtime reads exactly two things: the compiled contract, and the token's own state.

12Project navigation · where Templates landsA destination list, not a drawn sidebar — the style guide keeps the sidebar out of mocks so one redesign doesn't touch every file. The library is an eighth project destination.
Project shell destinations · the addition marked
Recommended
1Project overview
2Collections
3Generators
4Templatesnew
5Media library
6Access
7Whitelist
8Beneficiaries
Why there

After generators because the library is authoring infrastructure rather than a shared asset pool, and before media library so the three "things you build with" sit together.

Alternative considered: a tab under project overview, beside Burn / Reputation and Billing. Rejected — overview is presentation and metadata, and the library is neither.

All seven object types live inside this one destination as lists, rather than each becoming a destination. Eight top-level project entries is already the ceiling.