Appearance
The schema view — the reconciliation as a working classification system
STATUS: OPEN — the companion to the family reconciliation. That page argues the options; this page shows them as a schema — every axis as a table row, the ontology as one map, the pipeline flow that content category and content type actually drive, each option as a structural delta, and the concrete build list a ruling unlocks. Nothing here is new argument; marks belong on the reconciliation page's nine proposals. Every number on this page was probed live on 16 August 2026.
1 · The ontology, in one map
How a piece of content is described once the reconciliation lands the recommended way. Solid boxes are stored facts; the worlds are computed views; the family lives in the registry, not on pieces.
2 · The master classification table — one row per axis
The whole system as a table: each axis answers exactly one question, with one storage shape. Status is the honest state: LIVE (in the database now, probed) · DORMANT (exists, switched off) · TO BUILD (ruled but unbuilt) · OPEN (the thing being ruled). All facts probed 16 Aug 2026.
| Axis | The one question | Where it lives, and how | Status |
|---|---|---|---|
| Content type | What kind of piece is this? | On the piece; one primary value from the ratified list (64 types after the 16 August rulings). Today: 36 values in use, 6,393 pieces untyped. | LIVE — migration owed after the ruling |
| Content-type family | Which shelf holds this type? | In the registry as a parent pointer on each type — this mechanism already exists: the ten current families are live parents over 52 of 53 registered values (one parent still reads "proof & advocacy" where you ratified "social proof"). The ruling re-points these parents; it builds nothing new. | OPEN — the ruling (proposal 1) |
| Several types, one primary | What else is this piece, end to end? | A types junction with one row marked primary — does not exist yet. | TO BUILD (ruled; confirm at proposal 8) |
| Content role | What job does the piece do? | On the piece; several allowed; 19 registered values (announce · explain · prove · educate…). | LIVE |
| Marketing intent | What business program is it serving? | On the piece; one value of 12 registered; 6,581 pieces carry it; a human edit wins forever. | LIVE |
| Media format | What kind of file or experience? | On the piece; one value; fully populated. | LIVE |
| Ownership | Who paid for where it ran? | On the piece; owned · paid · earned · partner. | LIVE |
| Channel stack | Where does it live? | On the piece; the channel is derived by a database trigger from the page surface — never guessed. The full ratified stack (media type → channel → platform → touchpoint → placement) is vocabulary awaiting its columns. | LIVE base — stack build owed |
| Page surface | Which surface of the site? | On the piece; one value. | LIVE |
| Asset role | Its job inside its campaign system? | On the campaign-membership link, never the piece — the column already exists, barely written. Hero · teaser · cutdown · adaptation… | LIVE column — write-path owed |
| Variant / appearance | Which version of which creative, seen where? | A link between pieces that are the same creative — ruled, not built. Whether the middle level gets its own name is proposal 7. | TO BUILD (ruled) |
| Subject | What is it about? | Product, feature, and theme links — the live graph; several allowed. | LIVE |
| Container membership | What initiative does it belong to? | Edges to containers: campaign · program · project · event/season. Relationships, never labels. | LIVE |
| Campaign type | Why does the campaign exist? | On the campaign, never the piece; 21 active registered values — note the list itself mixes ideas (objective, season, relationship, channel) and even contains "project", a grouping kind; a cleanup guard is queued. | LIVE |
| Source type | Where did we collect it from? | On the piece, required — and it is the routing key (16 active routes). | LIVE |
| World lens | Which of the five worlds does it serve? | A computed view over container membership + registry family + product links. Stored on no piece. | TO DEFINE (proposal 1) |
3 · How this drives the pipeline — pre-classification, routing, full classification
This is the part the ruling actually changes. Verified against the running router this week: the prompt a piece gets is resolved in two layers, and the second layer is the one on the table.
In plain words, step by step:
① Ingest. The collectors write the facts that need no judgment: where it came from, what kind of file it is, which page surface. The channel is derived automatically — never guessed. The ruling changes nothing here.
② Pre-classification routing. The router picks the prompt by source first (16 active routes: youtube, meta ads, landing pages, newsroom…). Its second, smarter layer — route by what the content is about — exists but is switched off: 12 rows, all inactive, keyed on the old mixed carve (brand campaign, product campaign, brand identity, customer story…). This is where the ruling bites hardest: whatever the family layer becomes either re-keys that dormant layer or retires it. The recommendation keeps routing on facts knowable at ingest, and keeps the family out of prompts entirely.
③ Full classification. The routed prompt runs; the analyzer reads type, roles, messaging, and the visual axes. The ratified rule: every choice list it sees is generated from the registry. The carve decides how those lists are grouped and worded — under the recommendation, prompts list types and never ask for a family at all.
④ Normalize and write. Every emitted value resolves onto the registry (exact match → alias → close match → flagged for review). A human's correction is never overwritten. The one big value migration — the splits, the 6,393 untyped, the catch-all piles — runs once, after the ruling.
⑤ Lenses and shelves. Browse groups by facts already written. The five worlds become computed lenses; the families become the registry's shelves; a check enforces that a piece's world never contradicts its container.
4 · The four carves as schema — the same mechanics, compared
The reconciliation page argues these; here is what each one is, structurally.
| Mechanic | Option A — five worlds stored | Option B — deliverable families stored | Option C — the ten kept | Recommended — registry grouping + lenses |
|---|---|---|---|---|
| New stored field on each piece | a world column (five values) | a deliverable-family column (seven values) | a family column (ten values) | none — the piece stores only its type(s) |
| What the registry carries | the five worlds as a vocabulary | the seven families as a vocabulary | the ten families as a vocabulary | a family parent pointer on each of the 64 types + its media applicability |
| The router's semantic key becomes | the world (but 29 of 64 types can't answer it without the container) | the deliverable family (restates the format split the router already makes) | the ten families (family words compete with role words in prompts) | stays on facts: source + format at ingest, type after classification; family never routes |
| The analyzer is asked to | guess a container fact from pixels | restate the media format | pick between family and role words that overlap | pick a type from a generated, media-filtered list — nothing else changes |
| Backfill owed | a world on all ~14,000 pieces, container-checked | a family on all pieces, format-checked | none (status quo values stay) | none on pieces — one registry write per type (64 rows) |
| What can drift | world vs container (silently, on every re-org) | family vs format (two names for one fact) | family vs role (two names for one fact) | nothing stored twice — the conformance check watches lens vs container |
5 · The worked example, as rows — the Codex story under the recommended schema
Four objects, exactly the fields above. The display line at the end of each is composed from the fields, never stored.
The campaign (a container object)
| Field | Value |
|---|---|
| Campaign type | feature launch |
| Brand | OpenAI |
| Promotes product / feature | Codex → Codex Plugins |
| Contains | the hero film · the announcement article (with its key visual inside) |
The hero film (a piece)
| Field | Value |
|---|---|
| Content type (primary) | launch film |
| Media format | video |
| Asset role — on its campaign membership | hero |
| Subject | Codex · Codex Plugins |
| Ownership / channel | owned · video platform |
| World lens (computed) | Campaigns — because its container is a campaign |
| Display, composed | Feature Launch · Hero Launch Film · Codex Plugins |
The announcement article (a piece)
| Field | Value |
|---|---|
| Content type (primary) | announcement article |
| Media format | text |
| Channel stack | owned web → OpenAI site → blog/newsroom surface |
| Subject | Codex · Codex Plugins |
| Container | the same campaign |
| World lens (computed) | Campaigns (via container) — without the container it would read Content |
| Display, composed | Feature Launch · Announcement Article · OpenAI Blog |
The key visual (a piece, child of the article)
| Field | Value |
|---|---|
| Content type (primary) | key visual |
| Media format | image |
| Asset role | hero (of the article) |
| Parent piece | the announcement article |
| Craft | graphic design; gradient and serif type are treatment, on their own axes |
| The UI region inside it | a moment, at moment grain — never the image's type |
| Display, composed | Hero Key Visual · Codex Plugins · Graphic Design |
Notice what no object needed: a stored family, a stored world, or a "product launch content" label. The containment chain carries that meaning once, on the container.
6 · What ruling this creates — the build list
Each item exists as schema work the moment its gating proposal is marked; execution belongs to the pipeline lane. This is the "create all of those items" list, in order:
| # | Build item | Gated by | What it is |
|---|---|---|---|
| 1 | Registry family layer — a family parent pointer on each of the 64 type rows, plus per-type media applicability; retire the fragmented grouping values (the rough media split and the leftover inactive rows) | proposal 1 | 64 registry writes + cleanup; stored on no piece |
| 2 | The several-types junction with one primary per piece | already ruled | new junction + write path, the moments pattern |
| 3 | Value migration on the master list — the splits and moves already ratified (social post, advertisement image, blog post, feature launch…), then the 6,393 untyped and the catch-all piles, sampled before any full run | proposal 1 settles the target | one migration pass, cost-gated |
| 4 | Performance-ad re-home — retype its pieces to their real kinds; paid-ness lands on ownership/placement/ad format | proposal 2 | small value migration |
| 5 | Router second-layer decision — re-key or retire the 12 dormant semantic routes; routing stays on ingest facts + type under the recommendation | proposal 1 | route-table refresh |
| 6 | Generated analyzer choice lists — every prompt's type list generated from the registry, filtered by media applicability; kills the hand-synced constants | proposal 1 | the ratified governance rule, applied to this axis |
| 7 | The five world lenses — defined as computed views over container membership, registry family, and product/experience links | proposals 1 + 4 | view definitions + browse wiring |
| 8 | The lens-versus-container conformance check — a piece's world reading must never contradict its container facts | proposals 1 + 4 | one new check on the conformance report |
| 9 | Asset-role write path — the membership role column exists and is barely written; the campaign work fills it | already ruled | write-path work |
| 10 | The appearance model — one creative, many appearances (durations, aspect ratios, languages) | already ruled | the remaining deliverable-ladder level |
Where to mark
Marks belong on the reconciliation page, proposals 1–9. This page updates itself to match whatever is ruled — it is the machine view of the same decision.