manni:ai-context:1.0.0-proposal.3

The question it answers: how did machines make this page, and how may they use it? Two production fields (provenance, meta-provenance) and two consumption fields (risks, sample-questions).

Fields

Field	Type	Location	Notes
`provenance`	list of entries	`external`	Which body lines a machine wrote, as one entry per range. Each entry names the machine, the lines, and an integrity hash that pins them. Managed by `manni meta derive`
`meta-provenance`	list of entries	`external`	Per-model attribution of machine-proposed metadata: which fields and evals, at what confidence
`risks`	string or list; open list	`page`	Pre-flight flags for agents and reviewers. Recommended: `cost-incurring` · `destructive` · `irreversible` · `privileged` · `open-world` · `read-only` · `idempotent`. Any other non-empty string is legal
`sample-questions`	string or list	`page`	Questions this page should answer. Retrieval evals use them

A provenance entry has generated-by, lines (one body line, or a range such as "12-30"), and integrity (sha256- and 64 hex digits over those lines), all required. A meta-provenance entry requires generated-by. Its fields are JSON Pointers to the values it proposed, such as /intent or /kg/label. Its evals are the ids of the evals it proposed. Its confidence is a number from 0 to 1 per pointer or eval id. It needs at least one of fields or evals.

The Location column is the x-manni-location mark each field carries in manni:ai-context:1.0.0-proposal.3. page means the value belongs in the document’s own metadata and is meant to reach delivered output. external means it belongs in the collection’s external-metadata manifest. A field is page when a third-party or user-owned agent fetching the page would act on it. risks and sample-questions are addressed to an agent at read time, while both provenance records describe how the page was made. See field location for how the marks are used.

Example

---
title: Install the operator on Kubernetes
description: Deploy the operator with Helm and verify the rollout.
provenance:
  - generated-by: claude-fable-5
    lines: 4-18
    integrity: sha256-78af1d3321f9cbb177a7e4c958e39be56fd14cb93c1e441778bc4232e0fe4b1f
meta-provenance:
  - generated-by: claude-fable-5
    fields: [/intent, /sample-questions]
    confidence: { /intent: 0.9, /sample-questions: 0.84 }
risks: [privileged, cost-incurring]
sample-questions:
  - How do I install the operator on EKS?
  - Which Helm values enable the webhook?
---

Design decisions

Machines propose; humans retire the provenance. A meta-provenance entry is the review trail for machine-filled metadata. A human deletes the entry once its fields are reviewed, so a surviving entry means machine metadata nobody has checked. The same key serves the kg block and both eval vocabularies. So the whole family has one answer to “which of this metadata did a machine write, and has anyone checked?”
provenance attributes the prose; meta-provenance attributes the metadata. They record different facts. The machines that wrote a page are the distinct generated-by values across its provenance entries. Consumers use them for self-preference-bias checks: a judge should know when it is grading its own author.
risks is an open list. Seven flags are recommended. cost-incurring, destructive, irreversible, and privileged cover operations. open-world, read-only, and idempotent mirror MCP’s tool annotations, the published prior art for agent-facing hints. Any other non-empty string is legal. The assurances are worth stating because an unannotated page has not been assessed, which is different from being safe. For the same reason, a consumer that branches on a flag should treat an unknown value as a caution. Unknown does not mean safe.
sample-questions closes the retrieval loop. Ask them against the corpus and measure whether this page carries the answer. Per-page assertions belong to the evals vocabulary instead.

What reviewers should poke at

Two questions. Do generated-by and provenance belong here or in core? The eval bias check and the kg harvest both read generated-by, which argues for the one vocabulary that is always present. And is risks the right name for a field that carries assurances (read-only) alongside cautions?

Proposal 0046 changes both production records, in draft 1.0.0-proposal.2. provenance becomes a record of which machine wrote which body lines. Each entry names the machine, a line range, and an integrity hash that pins those lines. manni meta derive stamps it from git, and validate reports a pin whose text has changed. Both commands do that today, while the drafts stay under review. The per-model field attribution that 1.0.0-proposal.1 called provenance is renamed meta-provenance, with the same review semantics. Its fields become JSON Pointers, so /kg/label reaches into a block. It also takes over the kg block’s provenance and the eval vocabularies’ eval-provenance. After review, the page-level generated-by would be dropped, since provenance names the machines per range. manni meta fill already writes meta-provenance for the fields it fills. Both records would stay in ai-context, which answers the first question.