# 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.