# Decision Provenance Standard™ v1.2 — Companion D: Diagrams
**Status**: Companion to the Decision Provenance Standard v1.2 (rev. 10). Explanatory, **non-normative**.
> **These figures are explanatory aids, not normative.** The text of the Standard is the contract; every figure here *illustrates* a section of that text. Where a figure and the normative text appear to differ, the text governs. Captions and cross-references use "as shown in" / "illustrated by," never "as required by." Every state name, transition label, field name, enum value, signal name, and controlled-vocabulary chip rendered in these figures is a verbatim protected conformance token — rendered with exact case, hyphens, and underscores.
---
## Notation Key
The figure set uses one consistent visual language. Learn it once; it holds across all eight figures.
| Notation | Meaning |
|---|---|
| **Rounded rectangle** | A state or a step |
| **Double border** | Terminal / irreversible state (e.g., Charter `closed`, record `affirmed` + sealed), or a binding attestation — marked by border weight, never by color alone |
| **Solid arrow** | A transition |
| **Dashed arrow** | A conditional / edge-case transition, or a one-way pointer |
| **Accent (a single desaturated blue, plus heavier stroke)** | The one load-bearing element of a figure — comprehension does not depend on the color; the heavier stroke carries the same signal in grayscale |
| **Monospace text** | A literal field name, enum value, or signal token (e.g., `mode_declaration`, `dispatch_mode`, `affirmed`, `seal_hash`) |
Color is never the only signal. Every distinction is carried by shape, border style, stroke weight, or label, so the figures remain fully legible in grayscale and to screen-reader and print-only readers.
---
## List of Figures
| Figure | Title | Illustrates |
|---|---|---|
| Figure 3-1 | Charter Lifecycle State Machine | §3.3 |
| Figure 3-2 | Mode Dispatch Grammar and the Embedded-Mode-2 Edge Case | §3.4 / §4.4 / §4.7 |
| Figure 4-1 | Disclosure Block Flow | §4.6.2 / §4.6.3 |
| Figure 4-2 | Mode-Drift Four-Layer Composed Mitigation | §4.8.1 |
| Figure 4-3 | Emission-Cadence by Semantic Class | §4.8.2 |
| Figure 5-1 | Decision-Record State Machine: Two Distinct State Families | §5.1 / §6.2 |
| Figure 6-1 | Artifact-Set Relationship Map | §3 / §5 / §6 / §7 (orientation) |
| Figure 7-1 | The Three Conformance Levels: Cumulative Criteria | §7.2 / §7.3 / §7.4 |
---
### Figure 3-1 — Charter Lifecycle State Machine
```mermaid
stateDiagram-v2
direction TB
state "open" as open
state "mode-declared" as mode_declared
state "fields-required" as fields_required
state "fields-completed" as fields_completed
state "closed" as closed
state "new Charter v2 (prior_charter_ref)" as newCharter
[*] --> open : charter_id, charter_name,
decision_class, accountable_owner,
created_at
open --> mode_declared : mode_declaration populated
(mode-1 / mode-2 /
mode-1-with-embedded-mode-2-summary)
mode_declared --> fields_required : inside_decisions, outside_decisions,
cadence, record_location,
re_decision_triggers, escalation_rule
fields_required --> fields_completed : schedule_of_records,
conformance_level_declared,
conditional disclosure_metadata_pointer
fields_completed --> closed : closed_at set
(subsumption / dissolution / retirement)
closed --> [*]
closed --> newCharter : reactivation =
NEW Charter (dashed)
```
**Figure 3-1 — Charter Lifecycle State Machine.** A forward-only state machine in which each transition is gated by a named set of Charter fields; `closed` is terminal and reactivation creates a new Charter.
**Full description.** The Charter lifecycle is a forward-only state machine with five states: `open`, `mode-declared`, `fields-required`, `fields-completed`, and `closed`. Each transition requires a named set of Charter fields to be populated before it can be crossed: creation into `open` requires `charter_id`, `charter_name`, `decision_class`, `accountable_owner`, and `created_at`; `open` to `mode-declared` requires `mode_declaration` populated with one of `mode-1`, `mode-2`, or `mode-1-with-embedded-mode-2-summary`; `mode-declared` to `fields-required` requires `inside_decisions`, `outside_decisions`, `cadence`, `record_location`, `re_decision_triggers` (at least one outcome and one market trigger), and `escalation_rule`; `fields-required` to `fields-completed` requires `schedule_of_records`, `conformance_level_declared`, and a conditional `disclosure_metadata_pointer` when the mode is `mode-2` or `mode-1-with-embedded-mode-2-summary`; `fields-completed` to `closed` requires `closed_at` to be set on subsumption, dissolution, or explicit retirement. The `closed` state is terminal; a closed Charter cannot return to a prior state. Reactivation creates a new Charter carrying a `prior_charter_ref` back-pointer, shown as a dashed off-ramp from `closed` to a separate "new Charter v2" node, not a back-edge into any prior state. The `review-required` interrupt is deliberately absent here: it is a record-level state, not a Charter-level state (see Figure 5-1).
*Illustrates §3.3.*
---
### Figure 3-2 — Mode Dispatch Grammar and the Embedded-Mode-2 Edge Case
```mermaid
flowchart TB
subgraph altitudes["Two altitudes — 1:1 value alignment"]
direction LR
charterField["Charter altitude field:
mode_declaration"]
recordField["Record altitude field:
dispatch_mode"]
charterField -. "same enum value" .-> recordField
end
altitudes --> enumGate{"Exhaustive enumeration —
exactly three values.
No fourth mode."}
enumGate --> m1["mode-1
Mode 1 — Human-Led, AI-Enforced"]
enumGate --> m2["mode-2
Mode 2 — AI-Led, Human-Reviewed"]
enumGate --> m1e["mode-1-with-embedded-mode-2-summary
human-authored container,
AI-authored embedded sub-outputs"]
m2 -. "requires the disclosure block" .-> a50["Disclosure block flow
(see Figure 4-1)"]
m1e --> edgeInset
subgraph edgeInset["Edge-case inset — authorship is content-level, not container-level"]
direction TB
container["mode-1 container
(human-authored)"]
embedded["embedded AI-generated span
carries its OWN disclosure block:
mode_1_edge_case_flag = true"]
container --> embedded
end
enumGate -. "no runtime fourth mode" .-> fourth["A fourth mode is raised as an issue or
pull request (GOVERNANCE.md),
NEVER a runtime workaround"]
```
**Figure 3-2 — Mode Dispatch Grammar and the Embedded-Mode-2 Edge Case.** Mode is declared at two altitudes that align one-to-one, drawn from an exhaustive three-value enumeration; the third value handles content-level embedded authorship.
**Full description.** Mode is declared at two altitudes that align one-to-one: the Charter field `mode_declaration` and the decision-record field `dispatch_mode`. The enumeration is exhaustive with exactly three values: `mode-1` (Mode 1 — Human-Led, AI-Enforced), `mode-2` (Mode 2 — AI-Led, Human-Reviewed), and `mode-1-with-embedded-mode-2-summary` (Mode 1 with the embedded-Mode-2-summary edge case). A `mode-2` record requires the disclosure block (see Figure 4-1). The third value handles the edge case where a human-authored `mode-1` container holds an AI-authored embedded span; authorship is judged at the content level, not the container level, so that embedded span carries its own disclosure block at the embed point with `mode_1_edge_case_flag` set to `true`. No fourth mode exists; a fourth mode is raised as an issue or pull request under GOVERNANCE.md, never through a runtime workaround. The three token families are distinct and rendered verbatim: `mode-declared` is a Charter state, `mode_declaration` and `dispatch_mode` are fields, and `mode-1` / `mode-2` / `mode-1-with-embedded-mode-2-summary` are enum values.
*Illustrates §3.4, §4.4, §4.7.*
---
### Figure 4-1 — Disclosure Block Flow
```mermaid
flowchart TB
subgraph block["Disclosure block — exactly FIVE required fields"]
direction TB
f1["declaring-authority"]
f2["ai-system-identity"]
f3["jurisdictional-applicability-tag
{eu, us-federal, us-delaware, uk, israel, other:<jurisdiction>}"]
f4["content-type-tag
{decision-summary, recommendation, decision-aid,
draft, classification, synthetic-media, other:<type>}"]
f5["generation-timestamp"]
end
block --> anon{"4-of-5 anonymization gate"}
anon --> pass["FOUR fields pass through UNCHANGED:
ai-system-identity, jurisdictional-applicability-tag,
content-type-tag, generation-timestamp"]
anon --> transform["ONLY declaring-authority may be replaced,
by a placeholder such as:
anonymized-deployer-class:product-organization"]
pass --> test["Conformance test: a required block lacking ANY of the five fields
=> non-conformant at Level 2+"]
transform --> test
```
**Figure 4-1 — Disclosure Block Flow.** The disclosure block has exactly five required fields; under the 4-of-5 anonymization rule, four survive unchanged and only `declaring-authority` may be replaced by a placeholder.
**Full description.** The disclosure block has exactly five required fields: `declaring-authority`, `ai-system-identity`, `jurisdictional-applicability-tag`, `content-type-tag`, and `generation-timestamp`. Two fields carry controlled vocabularies: `jurisdictional-applicability-tag` takes a value from `{eu, us-federal, us-delaware, uk, israel, other:}`, recording where the artifact circulates; `content-type-tag` takes a value from `{decision-summary, recommendation, decision-aid, draft, classification, synthetic-media, other:}`. Under the four-of-five anonymization rule, four fields survive anonymization unchanged and only `declaring-authority` may be replaced by a placeholder such as `anonymized-deployer-class:product-organization`. That placeholder contains the substring "product-organization" but is not framing text. A required block lacking any of the five fields makes the record non-conformant at Level 2 or above. A note states that the block is required for Mode 2 content and for AI-drafted content embedded in Mode 1, unless the Charter declares the exclusion (or was written before v1.1 and its outputs meet the test), and that whether Article 50 applies is for the deployer to determine.
*Illustrates §4.6.2, §4.6.3.*
---
### Figure 4-2 — Mode-Drift Four-Layer Composed Mitigation
**Figure 4-2 — Mode-Drift Four-Layer Composed Mitigation.** Four orthogonal mitigation layers — no two sharing an actor or a detection moment — plus a phased Layer 1 rollout, structurally closing the silent-drift failure mode.
**Full description.** The Mode-Drift mitigation composes four orthogonal layers, no two sharing an actor or a detection moment. Layer 1, statistical detection, is run by an independent classifier on a disjoint corpus at a post-close population-sampling moment; its coverage is a 15% baseline, up to 100% on the first hundred records, and 30% on embedded-summary Charters, and it routes drift candidates above the `0.75 confidence threshold` to Layer 3. Layer 2, the in-flow audit hook, is run by the original declaring authority as a record-close hard gate, covering 100 percent of Mode-1 records through a four-question Substantive-Authorship Challenge (Q1–Q4); Yes or Uncertain on Q1–Q3, or not Yes on Q4, or a declined answer, or a Layer 1 / Layer 2 mismatch, routes to Layer 3 and blocks `closed`. Layer 3, the Mode-Confirmation Audit primitive, is run by a designated peer reviewer (named in the Charter; not the original author; not the Charter owner if the owner is the author) at the `review-required` interrupt; it confirms, migrates, or demotes per §6.4 and is the only layer with authority to change Mode classification. Layer 4, the Named Human-Attestation Fallback, is bound at record close by a named attestor at 100 percent coverage through the `mode_classification_attestation` object. The two composition axes are actor-independence and detection-moment-independence; the combined false-negative is bounded by the product of layer rates and the false-positive is bounded by Layer 3's peer gate. Layer 1 rolls out in phases: detection-only in weeks 1–3 (corpus A + B), detection-only in weeks 4–6 (corpus C adversarial), and enforcement from week 7 onward with full firing authority for `no_silent_mode_drift_in_sample`. The silent-drift failure mode is closed on day one because Layers 2, 3, and 4 are live on day one; Layer 1 adds population-level signal from week 7.
*Illustrates §4.8.1.*
---
### Figure 4-3 — Emission-Cadence by Semantic Class
```mermaid
flowchart TB
principle["Emission frequency is matched to the rate
at which signal truth can actually change."]
subgraph row1["Level 1 signals (6)"]
l1fire["Fire at Charter fields-completed + mode-migration events"]
l1why["Truth value cannot change between Charter-state events"]
l1fire --- l1why
end
subgraph row2["Level 2 signals (11)"]
l2rec["Per-record signals fire at record closed"]
l2sample["Sample-level signals fire at AUDIT CADENCE
(15% rolling / first-100 / 30% embedded-summary override):
no_silent_mode_drift_in_sample,
no_passive_promotion_to_affirmed_in_sample,
redaction-attestation, altitude-consent"]
l2rec --- l2sample
end
subgraph row3["Level 3 signals (6)"]
l3fire["Fire at every state transition + scheduled reporter runs"]
l3why["Continuous-audit by definition"]
l3fire --- l3why
end
principle --> row1 --> row2 --> row3
```
**Figure 4-3 — Emission-Cadence by Semantic Class.** Signal emission frequency is matched to the rate at which each signal's truth can actually change.
**Full description.** Conformance signals fire on a cadence matched to how fast their truth can change. The six Level 1 signals fire at Charter `fields-completed` and mode-migration events, because their truth value cannot change between Charter-state events. The eleven Level 2 signals split into per-record signals that fire at record `closed` and sample-level signals — `no_silent_mode_drift_in_sample`, `no_passive_promotion_to_affirmed_in_sample`, redaction-attestation, and altitude-consent — that fire on an audit cadence of 15% rolling with first-100 and 30%-embedded-summary overrides. The six Level 3 signals fire at every state transition and on scheduled reporter runs, being continuously auditable by definition. There are 23 signals in total: 6 Level 1, 11 Level 2, 6 Level 3.
*Illustrates §4.8.2.*
---
### Figure 5-1 — Decision-Record State Machine: Two Distinct State Families
```mermaid
stateDiagram-v2
direction LR
state "Family A — schema dispatch states (record_state field), section 6.2" as FamilyA {
direction TB
state "dispatched" as dispatched
state "drafted" as drafted
state "closed" as closedA
state "review-required" as reviewRequired
state "re-opened-with-mode-migration" as reopened
[*] --> dispatched
dispatched --> drafted
drafted --> closedA
drafted --> reviewRequired : interrupt
reviewRequired --> reopened : re-open
reopened --> drafted : migration loop
closedA --> [*]
}
state "Family B — record lifecycle states, section 5.1" as FamilyB {
direction TB
state "draft" as draftB
state "reviewed" as reviewed
state "affirmed" as affirmed
[*] --> draftB
draftB --> reviewed
reviewed --> affirmed
affirmed --> [*]
}
```
**Figure 5-1 — Decision-Record State Machine: Two Distinct State Families.** A decision record carries two deliberately distinct state families — schema dispatch and record lifecycle — that must not be conflated.
**Full description.** A decision record carries two deliberately distinct state families that must not be conflated, drawn as two separate lanes. Family A is the schema dispatch workflow carried on the `record_state` field: `dispatched`, then `drafted`, then `closed`, with a `review-required` interrupt branching off `drafted` and a `re-opened-with-mode-migration` path that loops from `review-required` back to `drafted`. This is the only place `review-required` legitimately appears; it is not a Charter state (contrast Figure 3-1). Family B is the record lifecycle, rendered as a separate track: `draft`, then `reviewed`, then `affirmed`. Family B is not a separate enum field — `affirmed` is reached when `affirmation_record` and `seal_hash` are populated per §5.1(3), and the record is sealed simultaneously. The past-tense schema state `drafted` (Family A) is distinct from the lifecycle state `draft` (Family B); conflating them is a conformance defect. Supersession is via `supersedes`, with the original retained in full; sealing is via `seal_hash`.
*Illustrates §5.1, §6.2.*
---
### Figure 6-1 — Artifact-Set Relationship Map
**Figure 6-1 — Artifact-Set Relationship Map.** A one-picture orientation showing how the standard's artifacts compose before the reader reaches the normative prose.
**Full description.** This orientation map shows how the standard's artifacts compose. A Charter governs a decision class, declares a Mode (Figure 3-2), commits a Schedule of Records, names an `accountable_owner`, and declares a `conformance_level_declared`. The Schedule of Records enumerates five required record types: Decision record, Re-decision record, Escalation record, Charter-amendment record, and Disclosure-review record (§6.3.1). A Decision Record is dispatched under a Charter, carries a `dispatch_mode`, transits the record lifecycle (Figure 5-1), and conditionally attaches a Disclosure Block (Figure 4-1) on Mode 2 and Mode-1 edge-case records. Conformance Signals are read off the Charter, record, lifecycle, and schedule (Figure 4-3) and grade the Conformance Levels (Figure 7-1). The standard points one-way, via a dashed neutral pointer, to the deploying organization's methodology; it does not depend on any named methodology and carries no branded node.
*Illustrates §3, §5, §6, §7 (orientation).*
---
### Figure 7-1 — The Three Conformance Levels: Cumulative Criteria
```mermaid
flowchart TB
subgraph L3["Conformance Level 3 — Continuously Auditable (section 7.4.1) — subsumes Level 2"]
l3a["1. Re-decision triggers fire and produce records on the declared cadence"]
l3b["2. Escalation rule produces records when invoked"]
l3c["3. Disclosure blocks reviewed within the review cadence (last_reviewed_at, or a disclosure-review record)"]
l3d["4. Schedule of records is queryable and exportable on demand"]
subgraph L2["Conformance Level 2 — Mode-Disambiguated (section 7.3.1) — subsumes Level 1"]
l2a["1. Every decision record carries its dispatch_mode field"]
l2b["2. Every Mode 2 record within the §4.6 requirement carries a complete disclosure block (FIVE fields — see Figure 4-1)"]
l2c["3. Every Mode 1 edge-case record whose embedded content is within the §4.6 requirement carries a per-record disclosure block (reads mode_1_edge_case_flag)"]
l2d["4. Schedule sample audit returns no silent drift (no_silent_mode_drift_in_sample)"]
subgraph L1["Conformance Level 1 — Charter-Conformant (section 7.2.1)"]
l1a["1. Charter has reached the fields-completed lifecycle state"]
l1b["2. mode_declaration populated with one of three values"]
l1c["3. Schedule of records committed and non-empty"]
l1d["4. record_location resolves to a durable surface"]
l1e["5. accountable_owner names one human"]
l1f["6. re_decision_triggers meets two-class minimum"]
l1g["7. escalation_rule populated with a named, exact trigger"]
end
end
end
L3 --> rule["Cumulative rule: a Charter that does not grade at Level 1 cannot grade at Level 2 or 3."]
rule --> footer["self-declared; the Steward does not certify, grade, or audit."]
```
**Figure 7-1 — The Three Conformance Levels: Cumulative Criteria.** Three cumulative conformance levels drawn as nested bands; all are self-declared and the Steward does not certify, grade, or audit.
**Full description.** The three conformance levels are cumulative, drawn as nested bands with Level 1 innermost. Level 1, Charter-Conformant (§7.2.1), has seven structural criteria: the Charter has reached the `fields-completed` lifecycle state; `mode_declaration` is populated with one of the three enumerated values (`mode-1`, `mode-2`, `mode-1-with-embedded-mode-2-summary`); the schedule of records is committed and non-empty; `record_location` resolves to a durable surface; `accountable_owner` names one human; `re_decision_triggers` meets the two-class minimum; and `escalation_rule` is populated with a named, exact trigger. Level 2, Mode-Disambiguated (§7.3.1), subsumes Level 1 and adds four record-discipline criteria: every decision record carries its `dispatch_mode` field; every Mode 2 record within the §4.6 requirement carries a complete disclosure block of five fields (Figure 4-1); every Mode 1 edge-case record whose embedded content is within the §4.6 requirement carries a per-record disclosure block at the embed point reading `mode_1_edge_case_flag`; and the schedule-of-records sample audit returns no silent drift findings (`no_silent_mode_drift_in_sample`). Level 3, Continuously Auditable (§7.4.1), subsumes Level 2 and adds four criteria: re-decision triggers fire and produce records on the declared cadence; the escalation rule produces records when invoked; disclosure blocks are reviewed within the review cadence (`last_reviewed_at`, or a disclosure-review record); and the schedule of records is queryable and exportable for counsel and auditor review on demand. A Charter that does not grade at Level 1 cannot grade at Level 2 or 3. All levels are self-declared; the Steward does not certify, grade, or audit.
*Illustrates §7.2, §7.3, §7.4.*
---
*End of Companion D.*