T04 — Views per audience, and projections regenerated from a shipped prompt

Rendered from .claude/briefs/T04-views-and-projections.md in the repository. The text below is that file. Source: https://riskmandate.ai/admin/work/T04/↗ · noindex · written by scripts/site/build-admin.mjs

From: the graph brief §1 items 5–6, §3, §4 item 6. Size: several days; do it after T01–T03. Touches: scripts/site/build-abp-vault.mjs, site/vaults/*/data/views/, site/vaults/*/prompts/, site/vaults/*/projections/, site/vaults/_app/index.html.

The task

Amended 16 September (direction__consequences-assets-and-the-vault-as-a-website.md §4): the reading app gains Who are you? directly under Start here — executive, technical, risk and governance, buyer, the agent itself — and the first four views ship with the MVP vault rather than after it. Each view also decides which consequences (T11) that audience is shown.

Eight audiences: CEO, CFO, CTO, investor, buyer, operator, engineer, project manager. Each is a view: an authored filter over the graph saying which behaviours, which counts, which evidence it shows, and what it hides and why. Each has a prompt (prompts/<audience>.md) that turns the graph and the evidence into that audience's prose, and a projection (projections/<audience>.md) generated by prompts/build.sh, dated, with the prompt's hash in its footer. The build refuses to write a projection whose prompt hash does not match the prompt beside it, the same discipline the delta has. Shipping the prompt and the script is a selling point: the customer can regenerate it.

Constraints

• Views and prompts are authored; everything else is derived. Say which in every file's header.
• The projection is text a stakeholder reads, so every rule of the site applies to it: no score, no verdict, no conformity language, the ABP never called the policy. The prompt must say so.
• The build must run without a model credential (it verifies hashes and refuses stale projections); generating a projection is a separate, explicit step that records model, version and date in the projection's footer.
• Start with two audiences (operator and buyer, because the vault app already speaks to them) and one vault; generalise only when the shape holds.
• No model identifiers in anything committed other than the projection footers, which record what produced them as data.

Done means

• Two views, two prompts, two projections in one vault; the build refuses a stale one; the renderer shows for the operator / for the buyer as tabs or a picker.
• An implementation brief in docs/briefs/ saying what held and what did not.