The Decision Provenance Standard and the Frameworks It Converses With
The Decision Provenance Standard™ · v1.3 · open standard, CC-BY 4.0
Read the firewall first
The Decision Provenance Standard's records are audit-ready decision provenance: a structured record of how a decision was made, by whom, against which inputs, with what review, and sealed at what moment. Across every framework below, those records function as an input substrate — material that compliance, audit, and governance personnel use when preparing their own work product.
The Standard informs each framework without satisfying it. A record produced under the Standard may be used as input when preparing evidence; it does not satisfy, ensure, certify, or substitute for any control, requirement, or audit obligation under any framework named here. Whether a framework applies, and how its requirements are met, is for the deployer to determine. The people who do that work may include counsel, compliance officers, internal auditors, third-party assessors, and certification bodies. The Standard documents process; those people make the substantive determinations.
This sheet is grounded strictly in Companion A — Regulatory Cross-References. Each row carries that framework's own non-claim. The “What it governs” column summarizes each cited text for orientation; it is not a rule of this Standard, and whether a cited text applies to a deployer, and what it requires of it, is for the deployer to determine. Nothing here is legal advice.
AI-governance frameworks
| Framework | What it governs | What the Standard contributes (as input) | What the Standard does NOT do |
|---|---|---|---|
| EU AI Act — Article 14 (Human Oversight) | Human oversight of high-risk AI systems. | Deployer-side: Mode 1 / Mode 2 dispatch structures where oversight is exercised (at authorship vs. at review); the Charter's named accountable owner, escalation rule, and re-decision triggers supply the authority pathway and the monitoring sensitivity oversight presumes. | Does not satisfy, ensure, or certify any Article 14 or Article 26 obligation; does not opine on whether a system is high-risk, whether a deployer discharged Article 26, or whether oversight personnel have the required competence. |
| EU AI Act — Article 17 (Quality Management System) | Quality management systems for high-risk AI systems. | Bounded: the Standard's territory is the deployer side; the Charter's ai_system_identity field points at the AI system the deployer uses. |
Does not constitute, replace, or contribute structurally to Article 17 QMS documentation; whether and how Article 17 applies to a deployer that is also a provider is for it to determine. |
| EU AI Act — Article 50 (Transparency) | Transparency obligations for providers and deployers of certain AI systems. | Mode 2 dispatch is the trigger for the Standard's own disclosure block (§4.6): five fields (declaring authority, AI system identity, jurisdiction, content type, timestamp) structure the inputs the declaring authority records. | Does not discharge any disclosure obligation; does not generate, approve, or substitute for the disclosure text. Whether a given artifact falls within Article 50, and who carries any duty, is for the deployer to determine. |
| EU GDPR — Article 17 (Right to Erasure) | The right to erasure (the right to be forgotten). | The redaction-event record records the deployer's statement that named fields were removed from operational use; it does not by itself remove or erase anything. The seal keeps the historical record of what was decided, by whom, on what basis and with what review. | Does not opine on whether any erasure request applies, whether an Article 17(3) exception holds, or whether a deletion method is adequate under a given jurisdiction's interpretation. |
| EU GDPR — Article 22 (Automated individual decision-making) | Automated individual decision-making, including profiling. | The Standard's records may inform the deployer's work. Where the decision is an employment decision, the HR-side rows below apply. | Does not satisfy GDPR. Whether Article 22 applies, what it requires, and who carries any duty under it are for the deployer to determine. |
| NIST AI RMF — Manage 4.1 (post-deployment monitoring) | A voluntary U.S. framework; Manage 4.1 addresses continuous documentation of how AI risks are managed post-deployment. | The Charter's schedule of records is a continuous-documentation commitment (every decision in the class becomes a record); re-decision triggers are the structural shape of "significant performance change" sensitivity. | Does not satisfy or certify any AI RMF outcome (the framework is voluntary and imposes no obligation); does not opine on the broader program's Govern/Map/Measure/Manage maturity. |
| ISO/IEC 42001:2023 (AI Management Systems) | A certifiable international management-system standard; an accredited body audits the AI management system as a whole. | The Charter is one process artifact within an AIMS scope; the schedule of records is documented information per Annex SL clause 7.5 where the deployer chooses to integrate it. | Does not produce an AIMS or an AIMS conformance assessment; the Standard's conformance levels are not ISO/IEC 42001 maturity levels and there is no defined cross-walk. The accredited certification body issues the certificate. |
Internal-control and oversight backbone
| Framework | What it governs | What the Standard contributes (as input) | What the Standard does NOT do |
|---|---|---|---|
| Caremark / Marchand v. Barnhill (Delaware) | The subject domain of board-of-directors oversight duties under Delaware corporate law. | For board-reserved decision classes, the Charter and the sealed affirmation lifecycle produce a structured record of who held authority, on what cadence, with what triggers — material a board, its committees, and its counsel may use as input. | Does not constitute Caremark/Marchand compliance, does not satisfy a board's oversight duties, and does not characterize what the cases hold; the Standard makes no determination about legal sufficiency. |
| COSO 2013 (Internal Control – Integrated Framework) | The design, implementation, and assessment of internal control across five components and seventeen principles. | Maps at the component level: the Charter (Control Environment), re-decision triggers (Risk Assessment), the Mode dispatch state (Control Activities), the schedule of records (Information and Communication), and the continuous-by-design schedule plus conformance grading (Monitoring Activities, most distinctively Principles 16–17). | Is not, individually or in combination, an internal control system; the design and operating effectiveness of the reader's control system is for the reader to determine, not the Standard. |
| SOX § 404 (Management Assessment of ICFR) | Management's assessment of internal control over financial reporting at in-scope issuers, plus the external-auditor attestation. | Where § 404 applicability is independently established, the Charter, schedule of records, and sealed affirmation events are structured inputs to the management assessment and the auditor's audit-trail testing. | Does not constitute § 404 compliance, does not produce a management assessment or auditor attestation, and does not establish applicability; whether § 404 applies is for the deployer to determine. |
| SOC 2 Type II (AICPA Trust Services Criteria) | An independent CPA's report on the design and operating effectiveness of a service organization's controls over a period (Security, Availability, Processing Integrity, Confidentiality, Privacy). | Maps at the criterion-category level; the continuous-by-design schedule of records aligns structurally with the operating-effectiveness-over-period evaluation a Type II engagement performs. | Is not a control set and does not produce a SOC 2 Type II report; the opinion is the service auditor's, reached under the Trust Services Criteria and AICPA standards. |
HR-side regimes
The Standard's records inform the deployer's work under these laws without satisfying any of them. The Standard does not authorize, validate, certify, or recommend any deployer's use of its records as input to employment decisions under any of these regimes.
| Framework | What it governs | What the Standard contributes (as input) | What the Standard does NOT do |
|---|---|---|---|
| NYC Local Law 144 (Automated Employment Decision Tools) | Automated employment decision tools (NYC Local Law 144 of 2021). | Whether it applies to a deployer's use of the records is for the deployer to determine. | Does not satisfy NYC LL 144. What it requires, and who carries any duty under it, are for the deployer to determine. |
| State employment-AI regimes (Colorado SB 24-205, Illinois HB 3773, California ADMT proposed regs) | Risk assessment, anti-discrimination, and notice and explanation for consequential employment decisions made or substantially assisted by automated systems. | Whether any of them applies to a deployer's use of the records is for the deployer to determine. | Does not satisfy any state-level regime. |
| EU AI Act — Annex III (employment-side high-risk) | Names employment-side AI systems (recruitment, performance evaluation, work allocation, monitoring) as high-risk. | Whether it applies to a deployer's use of the records is for the deployer to determine. | Does not satisfy the EU AI Act high-risk obligations. |
| EU Platform Work Directive / UK ICO Monitoring Guidance / Israel PPL 5741-1981 | Algorithmic management; proportionality, transparency and consultation for workplace monitoring; consent, purpose limitation and data-subject rights for employment data. | The Standard's records inform the deployer's work under each regime. | Does not satisfy any of these regimes. Whether each applies, what it requires, and who carries any duty under it are for the deployer to determine. |
Across every row above: the Standard does not authorize, validate, certify, or recommend any deployer's use of its records as input to an employment decision under any of these regimes.
The discipline behind every row
The mapping is structural, not substantive. In each case the Standard's primitives are an input substrate; the conversion from a structured record into legal evidence, an audit attestation, a regulatory filing, or a board-oversight finding is performed by qualified personnel under their own professional standards. Decision provenance is upstream of those determinations — it is not the determinations themselves.
Jurisdiction assumed: U.S. federal and Delaware (primary); United Kingdom, the European Union, and Israel (named secondaries). The traditional frameworks above are predominantly U.S. in origin; for non-U.S. jurisdictions, how local analogues apply is for the reader to determine. Not legal advice.
Decision Provenance Standard™ v1.3 — Reading Edition (rev. 11). Open standard under CC-BY 4.0. Not a certified product. Founding Steward: Yohay Etsion; institutional Steward: Etsion Brands Ltd.