Decision Provenance Standard™ — Glossary

Purpose: The site's structural spine and DefinedTermSet SEO/GEO asset. Each entry is a self-contained Direct Answer Fragment (40–80 words) that reads standalone and survives extraction into any context. Definitions reconcile strictly to the normative text of the Decision Provenance Standard™ (CORE rev. 8; the conformance contract is unchanged from rev7, so every token, count, cardinality, and state-transition is exact).

Not legal advice. Records produced under the Decision Provenance Standard are input to counsel and auditors, never a substitute for their judgment. They are not evidence, certification, or attestation. There is no certifying body; every conformance level is self-declared. No attorney-client relationship is created by reading or adopting the Standard.

Terms are grouped logically: the Standard and its firewall → the Charter and its fields → the mode-dispatch grammar → the record and its lifecycle → conformance and its safeguards → governance. A see § pointer cites the CORE section each definition derives from. Terms flagged for normative-text reconciliation are listed at the end.

The Standard

Decision Provenance Standard™

Gloss: An open standard for audit-ready records of how decisions get made.

The Decision Provenance Standard™ ("the Standard") is an open standard, published under CC-BY 4.0, for producing and maintaining audit-ready decision provenance in organizations that dispatch consequential decisions through a mix of human and AI authorship. It formalizes one artifact set — Charters, decision records, schedules of records, conformance signals, conformance levels, disclosure metadata — and one dispatch grammar, Mode 1 and Mode 2. It makes decisions affirmable, auditable, and resumable regardless of who authored the analysis.

See § 1.1, § 2.2.

Audit-ready decision provenance

Gloss: A structured record of how a decision was made — that is input to evidence, never evidence itself.

Audit-ready decision provenance is a structured record of how a decision was made — inputs, reviewers, dispatch mode, sign-offs — that counsel and auditors can use as input when preparing evidence, certifications, or attestations; the provenance itself is not evidence, certification, or attestation. This is the Standard's load-bearing object. Counsel and auditors convert it into evidence as their professional judgment requires; the artifacts produced under the Standard do not.

See § 1.4.1, § 2.2.7.

The firewall

Gloss: The non-negotiable rule that the Standard's records inform but never satisfy a legal or regulatory obligation.

The firewall is the Standard's load-bearing posture: audit-ready decision provenance is input to counsel and auditors, never a substitute for their judgment. The records are not evidence, certification, or attestation; nothing in the Standard is legal advice or a regulatory substitute; no attorney-client relationship is created. There is no certifying body and no certification track. The records inform the obligated party's work without satisfying any obligation, which belongs to that party.

See § 1.4.2, the On-Ramp firewall.

Self-declared conformance

Gloss: The deployer declares its own conformance level; no outside body certifies it.

Self-declared conformance means the adopting organization declares which conformance level its Charter meets and improves against the named criteria over time. No one grades it from outside. The Standard's Steward does not certify, grade, or audit conformance and maintains no central registry of conformant organizations. The deployer records the self-declaration in its own decision register; a third-party reader treats it as one input among others and forms an independent judgment.

See § 7.1, § 11.2.

The Charter

Charter

Gloss: The artifact that binds an organization to a way of deciding a recurring decision class.

A Charter is the artifact that binds an organization to a decision-making mechanism for a recurring decision class. It names the decision class, the accountable owner, the inputs, the cadence, the success criteria, the escalation rule, and the re-decision triggers that reopen the decision. A Charter is not a contract and not a regulatory filing; it is the operational commitment to a way of deciding, recorded in a form that survives leadership transitions.

See § 2.2.1, § 3.1.

Charter required fields (as a concept)

Gloss: The structured fields a Charter must carry, each required at a named lifecycle state.

A Charter carries structured fields that become required at named lifecycle states: charter_id, charter_name, decision_class, and accountable_owner at open; inside_decisions, outside_decisions, and mode_declaration at mode-declared; cadence, record_location, re_decision_triggers, and escalation_rule at fields-required; schedule_of_records, conformance_level_declared, and (when Mode 2) disclosure_metadata_pointer at fields-completed. A Charter omitting any required field has not reached that state.

See § 3.2, § 3.3.

Re-decision trigger

Gloss: A pre-declared condition that reopens a decision when outcome or market evidence demands.

A re-decision trigger is a named outcome condition or market condition declared up-front on a Charter that, when fired, reopens the decision class the Charter governs, regardless of decision status. A Charter declares at minimum one outcome-evidence trigger (for example, a metric miss against a guardrail) and one market-evidence trigger (for example, a competitor ships a substitute). The two-class minimum is a Level 1 structural requirement; triggers firing on cadence is a Level 3 operating signal.

See § 2.2.14, § 3.2.

The Mode-Dispatch Grammar

Mode 1

Gloss: Human-Led, AI-Enforced — a human authors the decision; the AI checks the human's work.

Mode 1 — Human-Led, AI-Enforced is the dispatch mode in which a human authors the decision and an AI worker checks that work against the Charter. The human is the author of record; the AI is the discipline mechanism: it reads Charter state, monitors record completeness against required fields, and emits conformance signals. The AI does not author substantive decision content under Mode 1. Article 50 disclosure does not attach as a baseline matter.

See § 2.2.5, § 4.2.

Mode 2

Gloss: AI-Led, Human-Reviewed — an AI authors the decision; a named human reviews before action.

Mode 2 — AI-Led, Human-Reviewed is the dispatch mode in which an AI worker authors the substantive decision content (analysis, options framing, recommendation) and a named human reviews the AI-authored draft before action. The AI is the author of record; the human is the reviewer of record and the declaring authority for any disclosure obligation. The reviewer signs off, requests revision, or invokes Mode 2 to Mode 1 demotion when re-authoring is needed.

See § 2.2.6, § 4.3.

dispatch_mode

Gloss: The decision-record field recording which mode a specific decision dispatched under.

dispatch_mode is the field on a decision record that records the mode under which the specific decision dispatched. Its enumeration is identical to the Charter-level mode_declaration field: mode-1, mode-2, or mode-1-with-embedded-mode-2-summary. The Charter declares the mode it authorizes; the record records the mode it dispatched under. The two are paired-but-distinct primitives at different altitudes, so downstream sections bind to either without ambiguity.

See § 2.2.15, § 4.4.

Embedded-Mode-2 edge case

Gloss: AI-generated content embedded inside an otherwise human-authored Mode 1 artifact triggers Article 50 at the embed point.

The embedded-Mode-2 edge case governs AI-generated summary, recommendation, or decision-aid content embedded inside an otherwise human-authored (Mode 1) artifact. The authorship analysis is content-level, not container-level: that embedded content is Mode 2 under Article 50 even when the surrounding artifact is Mode 1, and must carry disclosure metadata at the embed point. The structural handling is the third mode_declaration value, mode-1-with-embedded-mode-2-summary, with the mode_1_edge_case_flag set per-record.

See § 4.7, § 4.4.

Article 50 disclosure block

Gloss: The five-field transparency metadata every Mode 2 artifact must carry, structuring (not satisfying) the EU AI Act obligation.

The Article 50 disclosure metadata block is the structured input every Mode 2 artifact must carry at generation, attached so it cannot be separated through routine handling. Its five required fields are: declaring-authority, ai-system-identity, jurisdictional-applicability-tag, content-type-tag, and generation-timestamp. The block structures the inputs the human declaring authority needs to discharge a disclosure obligation under EU AI Act Article 50. It does not generate disclosure text, satisfy the obligation, or certify adequacy.

See § 4.6.2, § 2.2.11.

4-of-5 anonymization rule

Gloss: When a Mode 2 artifact is anonymized for publication, four of five disclosure fields survive unchanged; only the declaring authority may transform.

The 4-of-5 rule governs how the anonymization protocol handles published install references carrying Mode 2 artifacts. Anonymization removes client-identifying fields but must preserve Article 50 disclosure metadata: where anonymization and disclosure preservation conflict, disclosure preservation prevails. Four of the five required fields — ai-system-identity, jurisdictional-applicability-tag, content-type-tag, and generation-timestamp — survive anonymization unchanged. Only the declaring-authority field may transform to a controlled-vocabulary placeholder (for example, anonymized-deployer-class:product-organization).

See § 4.6.3.

The Record and Its Lifecycle

Decision record

Gloss: A single persistent, findable artifact capturing one decision and how it was made.

A decision record is a single instantiated, persistent, findable artifact that captures one decision. It carries a stable identifier, one named accountable owner, a date decided, a Charter pointer, the decision statement, context, options and rationale, inputs, assumptions, success criteria, the re-decision trigger, related decisions, a durable record location, the dispatch mode, and the current lifecycle state. The findability rule: a record not reconstructable in 30 seconds by someone not in the room is a meeting note, not a decision record.

See § 2.2.3, § 6.2.

draft → reviewed → affirmed lifecycle

Gloss: The three sequential states every decision record transits, gated on explicit human affirmation.

Every decision record progresses through three lifecycle states in order: draft (created and freely editable, no audit standing), reviewed (reviewed by at least one party other than the drafter, with comments captured and edits tracked), and affirmed (explicitly affirmed by the named decision owner via affirmative human action, then sealed). This sequential lifecycle, gated on human affirmation, is what distinguishes the Standard from a real-time telemetry or logging format.

See § 5.1, § 2.2.3.

Affirmation-and-seal

Gloss: A record reaches sealed status only when a named human affirms it; sealing happens simultaneously.

Affirmation-and-seal is the load-bearing lifecycle event: a record reaches affirmed only through an explicit, time-stamped, actor-identified affirmation by the named decision owner via signature, approval token, or equivalent human signal — never by elapsed time, absence of objection, or any passive signal. The record is sealed simultaneously, with a hash of the affirmed content computed and stored. Affirmation is an affirmative human act; nothing is promoted by default or silence.

See § 5.1, § 5.2, § 2.2.17.

seal_hash

Gloss: The cryptographic hash (SHA-256 baseline) of an affirmed record, making it tamper-evident.

seal_hash is the field storing the cryptographic hash of an affirmed decision record, computed at the moment it reaches affirmed. Computed using SHA-256 as the v1.0 baseline, it converts the affirmation event into a tamper-evident sealing of the record's content. It does not claim immutability against all attack surfaces — it is a hash, not a blockchain commitment. Corrections never modify a sealed record; they are made through the supersedes mechanism, which produces a new record.

See § 2.2.18, § 5.1.

Conformance and Its Safeguards

Conformance levels

Gloss: Three cumulative, self-declared tiers (1, 2, 3) at which a Charter meets the Standard's structural requirements.

A conformance level is the named tier — 1, 2, or 3 — at which a Charter satisfies the Standard's structural requirements, computed by the deployer's reporter from machine-readable conformance signals. The three are cumulative: Level 1 Charter-Conformant, Level 2 Mode-Disambiguated, Level 3 Continuously Auditable. A level is not certification; no third-party body grades it. Conformance levels are self-declared by the adopting organization and read by others as one input among many.

See § 2.2.9, § 7.1.

Conformance Level 1 — Charter-Conformant

Gloss: The Charter is a structurally complete artifact.

Conformance Level 1 grades the Charter as a structurally complete artifact. It is reached when the Charter has attained the fields-completed lifecycle state, mode_declaration is populated with one of three enumerated values, 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 carries a named exact trigger. It declares structural completeness only, not substantive or regulatory adequacy.

See § 7.2.

Conformance Level 2 — Mode-Disambiguated

Gloss: Records are authorship-disambiguated per-record, disclosure is attached where required, and the drift safety net runs.

Conformance Level 2 grades the Charter at the per-record altitude. It is reached when every Level 1 criterion holds and: every decision record carries its dispatch_mode field, every Mode 2 record carries a complete Article 50 disclosure block, every Mode 1 edge-case record carries a per-record disclosure block at the embed point, and the schedule-of-records sample audit returns no silent-drift findings. It is the load-bearing tier for the Standard's regulatory cross-references; the grade remains a structural fact, not a regulatory determination.

See § 7.3.

Conformance Level 3 — Continuously Auditable

Gloss: The Charter's mechanism has demonstrably run over time as declared.

Conformance Level 3 grades the Charter as it operates over time. It is reached when every Level 1 and Level 2 criterion holds and: re-decision triggers fire and produce records on the Charter's declared cadence, the escalation rule produces records when invoked, disclosure blocks carry a current last_reviewed_at per the review cadence, and the schedule of records is queryable and exportable for counsel and auditor review on demand. It converts a static artifact into a continuously auditable mechanism. Like every level, it is self-declared — no third-party body certifies it, and the grade is an input to an auditor's judgment, not an audit result.

See § 7.4.

Mode-drift four-layer safeguard

Gloss: Four independent layers that catch a Mode 1 record silently drifting into Mode 2.

The Mode-Drift Composed Mitigation sub-spec is a four-layer safeguard against silent Mode 1 to Mode 2 drift, where each layer is owned by a distinct actor and fires at a distinct detection moment. Layer 1 is independent-classifier statistical detection (post-close sampling); Layer 2 is an in-flow Substantive-Authorship Challenge at record-close; Layer 3 is a designated-peer-reviewer audit at review-required; Layer 4 is a named human attestation binding the final mode at close. No two layers share an actor or moment.

See § 4.8.1, § 7.3.3.

Governance

Steward

Gloss: The role that maintains the Standard's text but never certifies or audits any adopter.

The Steward is the role that maintains the Decision Provenance Standard. The Founding Steward (currently Yohay Etsion) holds authoring authority; Etsion Brands Ltd. holds the role institutionally as a stable home and succession backstop. The Steward's work is technical governance: accepting comments, publishing semantically versioned revisions, applying branch protection on load-bearing sections, and maintaining the trademark. The Steward does NOT certify, grade, or audit conformance, and maintains no central registry of conformant organizations.

See § 11.2, § 7.1.

Terms Flagged for Normative-Text Reconciliation

These plain-language glosses differ from the canonical phrasing or compress a multi-altitude distinction; the schema-reconciliation step should confirm the DefinedTermSet entry preserves the exact normative token.

1. dispatch_mode vs. mode_declaration — The plain gloss treats "dispatch mode" loosely, but CORE defines two paired-but-distinct fields at two altitudes: mode_declaration (Charter altitude, § 2.2.10 / § 3.4) and dispatch_mode (record altitude, § 2.2.15). Schema entries must not collapse the two; the task brief named "dispatch_mode," and this glossary defines that record-altitude field — confirm the site does not conflate it with the Charter field.

2. Article 50 disclosure block — field naming — CORE § 4.6.2 names the five fields with hyphenated tokens (declaring-authority, ai-system-identity, jurisdictional-applicability-tag, content-type-tag, generation-timestamp), while § 2.2.11 describes the block in prose with a longer list of carried attributes (jurisdictional applicability, edge-case flag, text pointer, timestamps, provenance). The five required fields for conformance are the § 4.6.2 set; the glossary uses those. Reconcile any schema entry to § 4.6.2's exact five, not § 2.2.11's prose enumeration.

3. "affirmation-and-seal" as a term — This is a composite coined for the glossary/On-Ramp register; CORE treats "affirmation event" (§ 2.2.17) and "seal" (§ 2.2.18) as two separate defined terms that co-occur at § 5.1(3). The gloss is faithful but the schema may prefer two DefinedTerm entries (Affirmation Event, Seal) rather than one composite — flag for the reconciliation owner.

4. "The firewall" as a term — CORE does not define "firewall" as a Section 2 defined term; it is the On-Ramp's name (On-Ramp "The firewall") for the load-bearing non-claim cluster at § 1.4.2. The glossary entry is grounded but is a named-concept entry, not a § 2.2 defined term — confirm acceptable as a DefinedTerm for GEO purposes.

5. Conformance level "cumulative" — The plain gloss says the three levels "build on" each other; CORE § 7.2.3 / § 7.3 / § 7.4 state this as "Level 2 satisfies every Level 1 criterion and additionally..." Verify the schema preserves the strict cumulative-criteria phrasing (a Charter not grading at Level 1 cannot grade at 2 or 3), not a looser "tiers" reading.

6. seal_hash baseline algorithm — The gloss names SHA-256 as the v1.0 baseline (CORE § 2.2.18). Because CORE provides explicit deprecation conditions and a seal_algorithm field, the schema entry should not hard-state SHA-256 as permanent; frame it as "SHA-256 baseline, deprecable per § 2.2.18."