First-pass mock for asset specs — named templates of required media slots, per Design Documentation/Phase2/asset-spec-design.md. A spec is authored once at the project level (alongside things like revenue presets), then applied to token types in any collection in that project, and gates go-Live: a token can't go Live until every required slot has a file. It verifies existence only, never content — human review stays the content check. First consumer: the graded-slabs programme (front + back photos required per slab). Snapshot-on-apply, versioned — editing the template never mutates tokens that already carry a copy. Replacing a slot's file is a plain overwrite — no version history is kept, and only project admins can do it.
01Project · Asset specs listLives at the project level, not inside any one collection — same shelf as revenue presets. A spec authored here is reusable across every collection in the project; it only takes effect on a given collection once applied to one of that collection's token types (frames 04–05). Each spec shows its slots, version, and where it's currently applied.
Studio/Toko Studios (internal)/Asset specs
Asset specs
2 specs
Graded slab v2
2 required slots: Front photo · Back photo — applied to 1 token type (Slab, Vaulted Slabs — Series 1).
Signed print v1
1 required slot: Signature close-up — not applied yet.
02Spec editorA spec is an ordered list of slots (fields ruled 2026-07-21): key (slug, unique, immutable after creation — renaming is a label change only, so files never orphan) · display label (unique in the spec) · optional description written for whoever fills the slot · explicit sort order (drag handle, never creation order) · kind (Image · Video · Audio · Document) + allowed filetypes and optional max size (per the RWA archetype ruling) — set per slot in the "+ Add slot" form, frame 03. One slot may carry the primary-asset flag (★, image slots only) — its file automatically becomes the token's card image, so nobody uploads a duplicate front view for art. Every slot shown here is required — for a spec applied directly to a token type, requirement isn't a per-slot toggle — a slot simply exists. Optionality is resolved when the contract is compiled (token-contract-system-spec.md §4.2, §5.3), and a composition may flip one slot with a typed slot_requirement delta (§4C.3). Dev note: max_files exists in the schema (default 1) but the V1 editor doesn't expose it. Saving bumps the version; applied token types keep their snapshot until re-applied pre-Live.
Asset spec · Graded slab
⠿frontFront photo ★Image · JPG, PNG, WEBPRequired
Full slab, certification number visible, high resolution.
⠿backBack photoImage · JPG, PNG, WEBPRequired
Entire reverse of the slab; barcode must be visible.
⠿dig_reportDIG reportDocument · PDFRequired
TAG's Document Imaging & Grading report, where the grader supplies one.
⠿unboxingUnboxing videoVideo · MP4, MOV · max 200 MBRequired
Vault intake unboxing, filmed unbroken start to finish.
Currently version 2. Saving changes creates version 3 — token types that already carry version 2 are not changed until you re-apply.
03Add a slot — kind, filetypes, sizeOpened from "+ Add slot" above. Kind picks the media family; the allowed-filetype checklist and default max size below it change to match (Image → JPG/PNG/WEBP; Video → MP4/MOV; Audio → MP3/WAV/M4A; Document → PDF). Image and document already have a shipped consumer (slab photos; the DIG report); video and audio are equally selectable, just without a consumer pinning their conventions down yet — filetypes/size are set per slot either way. The primary-asset flag only appears for Image, and only one slot in a spec may carry it. key is generated from the label and locked once saved.
Add slot
ImageVideoAudioDocument
MP4 MOV WEBM
Not available for Video — only an Image slot can become the token's card image.
Required — a spec applied directly to a token type has no optional slots; optionality is set later, only if a composition references this spec.
04Collection · where a spec gets appliedApplying a spec to a token type reuses the existing per-type settings surface — the same Attributes → Token types panel a creator already visits to set each type's attribute requirements (`attribute-system-design.md`, `token-type-attribute-assignment.md`). Pick a type's tab, and a Required media section sits alongside its attribute assignments, showing the spec currently applied (or none) with an action to apply, change, or remove one. This opens the apply modal (frame 05) pre-filtered to the type whose tab is active.
Toko Studios/Vaulted Slabs — Series 1/Attributes
Token types
2 types
Slab 60 tokens
Required media
Graded slab v2 · Front photo, Back photo, DIG report, Unboxing video
05Apply · pick token typesReached either from a token type's "Change spec" (frame 04, pre-filtered to that one type) or from the project-level spec list (frame 01, for applying across several collections at once) — same modal either way, the established batch-select pattern (token-state policy attach, bulk listing). A collection with one token type is effectively a whole-collection application. Live tokens are skipped (locked).
Apply · Graded slab v2
✓Slab · Vaulted Slabs — Series 1 (42 tokens · 40 Draft, 2 Live — Live skipped)
✓Slab · Vaulted Slabs — Series 2 (18 tokens · all Draft)
Poster · Print Vault (no physical media requirement)
Each selected type snapshots version 2 of this spec. Editing the spec later never changes them — re-apply pre-Live to update.
06Edit token · Details tabRequired media lives on Details, not on the token's Assets tab — Assets already means something specific (the main display asset and any freeform additional images); required-media slots are a different thing, a fixed set of certification/compliance files a spec demands, so they sit with the rest of the token's core facts instead. Once a spec is applied to this token's type, its slots show up right here — not only on the collection's Overview status checklist (frame 07). A filled slot shows its thumbnail; a missing required slot is called out plainly, with an upload action in place. Uploading or replacing a slot's file is a project-admin action — the ordinary media-edit right isn't enough.
Edit token · #042
Front photo ✓ Present
Back photo Missing — required
Required by this token's type (Graded slab v2) — configured at the project level, under Asset specs, not here.
Only project admins can upload or replace a slot's file. Replacing overwrites it directly — there's no version history to restore from.
07Collection · Overview status checklistThis is a Manage → Overview row, not a separate page — required media joins the same "Collection status" block every other setup item already lives in (collection type, tokens added, attributes, supply, rarity, guards…), existence check only, via one shared function (the R34/R61 pattern; mirrors the default-variant R50 gate). It names which tokens are missing which slots collection-wide; the per-token detail (frame 06) is where a creator actually goes to fix one.
Studio/Vaulted Slabs — Series 1/Overview
Collection status
Token types 2 types
Slab · Poster — each carries its own attribute schema and, optionally, an asset spec.
↗
Required media 2 tokens missing
#042 — missing: back · #051 — missing: front, back. These can't go Live until their slots are filled.
40 of 42 complete
↗
08Slot states · atomic replace · no historySlot states are derived, never stored: Missing · Uploading · Present · Failed — the gate counts only Present (a completed file reference); an in-flight upload is pending, not present. The existing asset uploader already owns the in-progress/failed mechanics — no new machinery. Replace is atomic: the current file stays active until the new upload completes, then swaps — the slot never transiently empties, so the go-Live checklist never flickers. Amended 2026-08-03: replaced files are not retained — this is a required-media gate, not a custody vault, and there's no version history to browse or restore from; a replace is a plain overwrite. Only project admins can upload or replace a slot. Ref-vs-blob drift is caught by the periodic invariant audit; a dangling reference fails the gate closed.
#042 · Required media
Graded slab v2
Front photo ✓ Present
Back photo ◌ Uploading… 62%
Label detail Missing — required
Cert scan ✕ Upload failed — retry
Replacing "Front photo" overwrites it immediately — the file it replaces is not kept, and only a project admin can do this.
09After Live · vault-added photos & visibilityRuled 2026-07-21. The spec and its slot list lock on Live (keys never removed or renamed on a Live snapshot); slot files follow standard media permissions. The vault may add additional photos after Live (extra angles, re-shoots) — supplementary media, not public by default. The creator enables public visibility per token, with batch visibility controls on the minted bulk-select pattern so enabling a whole series isn't tedious. These are token media — distinct from the custody vault-images (insurance/dispute evidence, never token assets).
#042 · Additional photos added by Geneva Vault SA
3 photos
▣
angle_left.jpg
Added 20 Jul 2026 · after Live
Not public
▣
corner_detail.jpg
Added 20 Jul 2026 · after Live
Not public
▣
case_reshoot.jpg
Added 21 Jul 2026 · after Live
Public
Batch: select tokens in Manage minted → bulk bar → "Photo visibility" applies one choice across the selection.
Note (not UI) — open questions
From asset-spec-design.md (post-ruling 2026-07-21, amended 2026-08-03): still open — per-variant slots (deferred; variants never apply to RWA); the creator-facing name ("Asset spec" vs "Media requirements", glossary once ruled). Ruled: one spec per token type, with composition (token-contract-system-spec.md §4C) as the mix-and-match layer on top rather than spec nesting — checked against its own non-slab worked example (a Generated Art collection), which simply omits the asset-spec axis; per-slot Review approval rejected (R50 — Review is stage-only; the gate stays existence-only); filetype set + max size ship (RWA archetype ruling); no version history is retained, and only project admins can upload or replace a slot (amended 2026-08-03 — this closes the blob-lifecycle question, since nothing is retained); the entity is deliberately not NFT-specific — applies_to is a typed reference, tokens are just the first consumer. Generator-produced art is still not a spec slot — specs cover additional required media.