Human approval and execution lineage
Human approval is part of an execution record. This playbook explains what to capture before an action, when a reviewer decides, and after execution.
Payment execution
Submission accepted
Payment requested
Submit supplier payment · €420,000
Treasury payments agentApproval required
Amount exceeds the €250,000 threshold
Payment limits · version 3Treasury approved
Invoice and approval scope confirmed
Treasury reviewerTool accepted submission
Submission accepted; settlement not shown
Payment tool
What to capture at each stage
An agent requests a payment above the review threshold. The policy requires approval. The evidence needs to connect that request to the review and the eventual execution result.
- 1
Capture the request
Record the agent, proposed action, relevant inputs, and request identifier.
- 2
Keep the policy decision
Record the policy version, evaluated context, outcome, and reason.
- 3
Attach the human decision
Keep the reviewer identity, decision, rationale, time, and relationship to the original request.
- 4
Record what executed
Connect the permitted action and its result to the same request. A rejected request must remain distinguishable from a completed action.
- 5
Prepare the review artifact
Collect the records and supporting material with a manifest and integrity information.
The useful unit is the full decision: request, rule, reviewer, result, and supporting evidence. Lineage Explorer and Evidence Room provide the investigation and review surfaces for that work.
Verification checks and limits
A Sealed Evidence Bundle gives the reviewer an artifact to inspect. Verification checks its cryptographic structure against the supplied material and trust configuration.
Authenticity needs an out-of-band key check. The SEK, TEK, and receipt signatures are all checked against the keys the bundle embeds in keys/jwks.json, so offline the bundle proves only that it is internally consistent. To prove it came from KLA, pin those keys against a KLA-published JWKS or key fingerprint.
The OpenTimestamps Bitcoin anchor is trusted offline. Confirming its block height compares the proof against the live Bitcoin chain, and a pending calendar receipt stays pending until a calendar upgrade.
The immudb ledger anchor's proof is present and parses offline. Confirming its inclusion against the ledger's signed state needs a networked check.
- Manifest signature
- The manifest canonicalizes (RFC 8785 / JCS) and its digest recomputes. The detached JWS carries valid SEK and TEK ES256 signatures over that digest, checked against the public keys the bundle embeds in keys/jwks.json.
- Merkle inclusion
- Every artifact re-hashes (SHA-256) to the digest the manifest declares, each artifact's inclusion proof reaches the sealed root, and the recomputed Merkle root equals the manifest value.
- Receipt signatures
- Every governance receipt chain verifies: each receipt's ed25519 signature checks against a key embedded in the bundle, and each step's prevReceiptHash links to the prior step, genesis to last.
- Ledger hash chain
- Every exported ledger record re-hashes to its stated hash, and consecutive records link through previousHash end to end.
- OpenTimestamps anchor
- timestamp.ots parses under the strict OpenTimestamps rules and commits to the recomputed manifest digest. When the receipt is Bitcoin-attested the verifier reports its block height; a pending calendar receipt is accepted as pending Bitcoin confirmation.
Regulatory precedents
These references describe different recordkeeping contexts. Use them to examine the evidence question in each regime and follow the source for its scope.
SOX
Recordkeeping practice
COSO framework: 17 principles, 87 focus points, 40% Big 4 audit deficiency rates
MiFID II
Recordkeeping practice
100 microseconds UTC divergence (HFT), WORM storage, 5-7 year retention, 72-hour reconstruction
GDPR
Recordkeeping practice
2FA now expected (Haga Hospital fine), documented access procedures required
MDR
Recordkeeping practice
IEC 62304 audit trails, complete version control, traceability from requirements to tests
Source: Regulation (EU) 2024/1689. Review the requirements applicable to your system with the people responsible for its legal and operational assessment.
Questions and details
Does Article 12 explicitly require cryptographic integrity?
No, but the pattern from MiFID II, SOX, GDPR, and MDR is unambiguous: principles-based text becomes prescriptive practice within 2-4 years. Auditors and notified bodies will interpret "automatic recording" to mean tamper-evident logging.
What retention periods apply to AI logs?
Article 12 specifies 6 months minimum for automated logs, but sector-specific requirements often override this. Financial institutions should expect 5-7 years. Technical documentation must be retained for 10 years after the system is placed on the market.
When will harmonized standards be published?
prEN ISO/IEC 24970 (logging standard) is in Draft International Standard ballot. prEN 18286 (QMS standard) entered public enquiry in October 2025. Final standards expected Q4 2026, but auditor expectations are forming now.
What access will notified bodies have?
Under Annex VII, notified bodies can require full API access to training, validation, and testing datasets. They may conduct direct tests if unsatisfied with provider evidence. Dataset access logs will themselves become audit targets.
How should we handle ML model auditability?
Thresholds for extensive logging remain unclear, but auditors will likely expect: model version tracking, hyperparameter changes, training run metadata, and decision traceability for high-risk outputs.