The Folio Carries the Product

In plain terms: the owner asked whether it is wise to bet the whole product on one idea — that every piece of a document is a filed record (a Folio) shown through one kind of card (the Stack). The answer, on the record, is yes, and the bet is safer than it sounds: the record is the thing that matters; the card is furniture that can be replaced without touching the record. The part of the bet worth defending hardest is that the AI works on the same records, the same way a human junior does — so a lawyer can review its work clause by clause. The same sitting settled who the product is for: a Builder authors a kit once; a Maker is walked through it as a set of questions and never sees the machinery underneath.

The farm bet — the five jobs

The owner asked the widest frame question directly: is the product right to bet everything on the Stack/Folio carrying

1. the user's interaction with content,
2. the attributes that make content reusable and searchable,
3. display control,
4. addressability and referenceability, and
5. the AI interacting with content the same way a human does?

Assessed broadly yes. The bet is really two stakes the architecture already separates:

• The Folio — identity, versions and envelope, held in the domain and the schema — carries all five jobs.
• The Stack is replaceable furniture over it. The compound-Stack rebuild and the folio unification each demonstrated this by changing one half without the other.

Job 5 — AI parity — is the strongest and most defensible part of the bet. Goldie works on the same addressable units, reads the same About card, and goes through the same propose-review-accept lifecycle as a human junior. That is what makes AI drafting reviewable at the clause level, which is the only form a careful lawyer can trust.

Jobs 3 and 4 hang on questions that remain open elsewhere: display control depends on whether one projection engine or three produce the canvas, the Word file and the PDF; addressability's acid test is intra-document cross-references surviving reorder and renumber (flow.adapt points there, unproven). Those are filed as open decisions, not settled here.

Assessed sound and not filed: the margin cliff (spine, glyph menu, grip), the header row as filing tab (the label is not the heading — the heading prints, the label does not), the fold-for-chrome-never-for-paper rule, and per-card proposal review as the product's differentiator. The Stack's anatomy — spine, grip, glyph menu, header, fold, the facets in one sized window, the Goldie control, the work bar — was interrogated part by part on 2026-08-29 and every enumerated part earns its place; the findings were placement, not surplus or absence.

The two audiences

The Builder/Maker/Reader distinction is two separate audiences, not three permission levels on one user:

• A Builder authors a kit — for example a will-kit interview system — working structurally, inside one card's Goldie control panel at a time.
• A Maker runs the kit and is interviewed in the side panel across the whole document. The Maker sees questions and never YAML; each folio's guide is the plain-language prompt. display.hidden_from keeps gathering-only blocks (the willmaker's wishes) out of the reading version.

This is the leverage model: the Builder's expertise amortises across every matter the kit runs. The venue split matches each audience's mental model — the Builder thinks per card, the Maker thinks in one guided flow — and the recorded Inspector-is-only-for-interviews ruling protects the seam.

The interview is a projection

The strongest architectural fact of the sitting: the interview is a projection of the same folios the document prints from. It is derivable — ask the empty required fields, in flow order, honouring conditions — the same move that made interview progress derived state. There is no second authored form to drift from the document. This is the product's stated position, not one of two options. What remains open is only the engineering half: whether the interview's backend machinery reduces to that projection, and which verified non-derivable remnants, if any, must persist.

What this settles

• Do not re-raise whether the Folio should carry the five jobs, or whether the Stack could be swapped for other furniture — it can, by design.
• Do not re-raise whether the AI should edit through a separate door: it works on the same units, through the same review lifecycle, as a person.
• Do not re-raise whether the interview needs its own authored form.

The contract terms this feature still needs ruled — hidden-is-not-inert, the Builder rehearsing their own interview, a mid-interview matter pinning the kit's version, and where the lawyer's review sits in the Maker flow — are filed as open owner decisions under backlog/decisions/.