EU AI Act Article 14 — human oversight receipts

Article 12 (automatic logging) is solved by recording an agent receipt. Article 14 (meaningful human oversight) demands something more: cryptographic evidence that a specific named person saw the agent’s recommendation, with documented context, and took a specific action — with the final outcome traceable back to that human decision.

Marturia’s /api/marturia/v1/oversight endpoint records that evidence as a normal Marturia receipt with a special payload shape. It lives in the same hash chain as the agent decision it reviews, signed by the same tenant Ed25519 key, anchored to the same Merkle root, and verifiable offline through the marturia-verify wheel.

What gets recorded

Article 14 specifies five outcomes a human reviewer might take. Marturia records all five plus the supporting context regulators will probe for.

Field	What it proves
`reviews_receipt_seq`	The agent decision being overseen — provable causal link
`reviewer.id` + `reviewer.role`	Identifies the natural person responsible (anonymous reviews rejected)
`review_context.fields_shown`	Proves what information the reviewer actually saw on screen
`review_context.alternatives_presented`	Proves the reviewer was shown options, not a forced yes/no
`review_context.warning_messages`	Proves the system surfaced relevant risk signals
`action`	The Article 14 outcome: `approve`, `override`, `reject`, `interrupt`, or `no_action`
`rationale`	The documented reasoning Article 14 requires (rejected if empty)
`final_outcome`	What actually executed — may differ from the agent’s recommendation
`review_timing.duration_ms`	Guards against automation-bias claims — sub-second “reviews” are rejected

Record an oversight event

Same authentication as /v1/receipts — X-Marturia-Key header. The endpoint validates the action enum, looks up the parent receipt in your tenant’s chain, enforces override semantics (action=override means the final_outcome.decision must differ from the parent’s recommendation), and signs the oversight receipt into your chain.

curl

curl -X POST https://marturia.dev/api/marturia/v1/oversight \
  -H "X-Marturia-Key: mtu_live_" \
  -H "Content-Type: application/json" \
  -d '{
    "reviews_receipt_seq": 12345,
    "reviewer": {
      "id": "user_42",
      "role": "compliance_officer",
      "tenant_user_email": "[email protected]"
    },
    "action": "override",
    "rationale": "Vendor has 3 prior disputed invoices in last 12 months. Despite 0.91-confidence approve recommendation, prior pattern warrants manual review.",
    "final_outcome": {
      "decision": "manual_review",
      "execution_external_ref": "JIRA-7890"
    },
    "review_timing": {
      "started_at": "2026-05-10T20:14:33Z",
      "completed_at": "2026-05-10T20:15:11Z",
      "duration_ms": 38000
    },
    "review_context": {
      "ui_version": "v3.2",
      "fields_shown": ["agent_recommendation", "input_data", "confidence", "alternatives"],
      "alternatives_presented": [
        {"action": "approve", "score": 0.91},
        {"action": "dispute", "score": 0.08},
        {"action": "manual_review", "score": 0.01}
      ],
      "warning_messages": ["Vendor has prior disputed invoices."]
    }
  }'

Response:

{
  "id": 213,
  "tenant_id": 12,
  "project_id": 7,
  "receipt_seq": 12347,
  "signing_kid": "t12-v1",
  "receipt_hash": "6dad2810cd391e1a59311e0fe588b627861dc9d8fd3ebc9d6a852b9ba03c8e1a",
  "kind": "human_oversight",
  "reviews_receipt_seq": 12345,
  "reviews_receipt_hash": "86d31627a721565f40a22b22d99cc3e5c029a0e226cc8f937d81e7e6d55aa552",
  "action": "override",
  "verify_url": "https://marturia.dev/v1/verify/12/213"
}

The five Article 14 actions

Action	Meaning
`approve`	Reviewer accepted the agent’s recommendation as-is
`override`	Reviewer changed the decision — `final_outcome.decision` must differ from the agent’s recommendation (enforced)
`reject`	Reviewer blocked the action entirely — no execution
`interrupt`	Reviewer used the “stop button” on a running multi-step agent
`no_action`	Reviewer was presented with the decision but the review window timed out without an explicit choice

Verify oversight receipts offline

marturia-verify v0.2.0 and later recognize the oversight receipt kind. Pass --oversight-summary to render a regulator-friendly report alongside the chain verification:

$ pip install --upgrade marturia-verify
$ marturia-verify --chain chain.json --pubkey-hex <hex> --oversight-summary
VALID: chain valid: 2 receipt(s), seq 168..169

Receipt #169 — Human oversight of #168
  Reviewer:   alice (compliance_officer) — [email protected]
  Action:     override
  Final:      manual_review  (differs from agent recommendation)
  Duration:   38.0s
  UI:         v3.2
  Shown:      agent_recommendation, input_data, confidence, alternatives
  Rationale:  Vendor has 3 prior disputed invoices in last 12 months...

The verifier knows whether the human overrode the agent or just accepted its recommendation, because it walks the parent receipt in the same chain. The summary is regulator-friendly — the exact format an EU AI Act conformity assessment or ISO 42001 audit would accept as evidence.

Compliance posture matrix

Framework	Requirement	How oversight receipts satisfy it
EU AI Act Article 14	Meaningful human oversight with documented reasoning	Cryptographically-signed record of reviewer identity, context shown, action, rationale, and final outcome
ISO/IEC 42001 Annex A.6	Operational evidence that AIMS controls are working	Tamper-evident receipts demonstrating each oversight control fired as designed
NIST AI RMF GOVERN-1.6	Mechanisms to operationalize incident response	`action=interrupt` receipts record human stop-button usage with chronological proof
SOC 2 CC7.2	Monitor system anomalies; effective response	Oversight receipts where `action=override` document material control overrides

What we deliberately don’t do (yet)

v1 trusts your application to record the reviewer identity correctly. The receipt is signed by the tenant key, not the reviewer’s personal key. This satisfies ISO 42001 and EU AI Act (the audit is against tampering by external parties; the deployer is presumed accountable). For high-assurance contexts (financial decisions, healthcare), a future v2 will add per-reviewer Ed25519 keys with the reviewer co-signing the oversight payload before the tenant key signs the receipt. Reach out if you need it sooner.

Next: Verifying receipts offline or full API reference.