Accountability-Continuity Checkpoint for Chained AI Workflows
Human approval is necessary, but not always sufficient. A prior approval may no longer apply after the decision context changes. This is a reviewer-informed design validation of a deterministic checkpoint for when that happens.
The problem
Human-in-the-loop is widely treated as sufficient for AI governance. A human reviews, a human approves, the chain continues. That framing works when the decision context at the point of execution matches the context at the point of approval.
In chained AI and enterprise workflows, it often does not. An agent recommendation passes through system enrichment, a human approval gate, and then several more automated steps. Along the way, scope expands, new risk data arrives, authority boundaries shift, or additional system actions change what the next decision actually covers.
The prior approval still exists. It is on the record. But the thing it approved may no longer match what is being decided now.
The governance gap is not that humans did not approve. The governance gap is that the approval record cannot be confirmed as still valid for the current decision context. These are different problems, and they require different detection logic.
The checkpoint
The trigger for an accountability-continuity checkpoint is not automation level, elapsed time, or complexity. A fast, highly automated chain with a confirmed accountable owner and valid declared authority does not need a checkpoint. A slow chain with diffuse ownership does.
The trigger is whether declared accountability for the next decision can still be confirmed. That means checking four things before the chain continues:
- ·Accountable owner. Can the current accountable owner for the next decision still be confirmed?
- ·Declared authority. Is the declared authority under which that owner acts still confirmed?
- ·Authority validity. Is that authority still valid given changed facts since the last human review?
- ·Human review currency. Is the last confirmed human review still current — or has it been superseded by changes that require a fresh review?
If any of these cannot be confirmed, a checkpoint is required. Delay, automation level, and complexity are recorded as contributing indicators — but they are explicitly not trigger conditions. They appear in the runtime output under contributing_indicators_only, not in trigger_basis.
This distinction matters for auditability. A system that fires on elapsed time alone will produce noise. A system that fires only on accountability gaps produces signal.
Two synthetic cases
The detector demo runs against two synthetic fixtures. Both are public and verifiable at grc.eveverified.com/iso42001/accountability-checkpoint.
A highly automated chain that moves in two hours from initiation to next action. The accountable owner is confirmed. Declared authority is confirmed and still valid. The last human review is current. The approval record is connected to the current decision context. All four conditions check out.
trigger_basis: [] — empty. Speed and automation alone do not trigger a checkpoint.
A mixed chain where a scope expansion and new risk data have arrived since the last human review. The current accountable owner cannot be confirmed. Declared authority is unconfirmed. The authority may no longer be valid after the scope change. The last human review is stale. And the prior approval no longer appears materially connected to the expanded decision scope.
Case A is as important as Case B. A detector that fires on every fast or automated chain is not useful. The value of the demo is that Case A returns no triggers — which proves the logic does not conflate automation with accountability failure.
Approval scope mismatch
The fifth trigger item — approval_scope_mismatch — sits differently from the other four. The ownership and authority conditions ask whether the accountable owner and declared authority for the next decision can still be confirmed. They are about the people and the mandate.
Approval scope mismatch asks a different question: a prior approval exists, but does it still cover what is now being decided?
A prior approval may be fully on the record, with a confirmed owner and valid authority at the time it was issued — and still not apply to the current decision context after changed facts such as scope expansion, new risk data, or authority boundary changes.
This is related to, but distinct from, ownership or authority confirmation failure. You can have a confirmed owner, a confirmed authority, and still have an approval whose scope no longer matches what is being decided. The three conditions are orthogonal.
In the runtime output, this appears as approval_scope_mismatch in trigger_basis — a named, auditable signal. The detector does not assess whether the mismatch is material, does not classify it as an incident, and does not determine whether the prior approval should be accepted or rejected. It surfaces the condition. A named human owner decides what to do with it.
Runtime auditability
One design choice worth making explicit: contributing_indicators_only appears in the runtime JSON output, not only in documentation.
The field records delay, automation level, and complexity alongside the trigger basis — but under a key that makes their status unambiguous. They are indicators. They are transparent. They are not triggers.
This matters when someone asks, after the fact, why the checkpoint fired — or why it did not. The output for Case A shows elapsed_hours: 2 and automated_chain: true under contributing_indicators_only, alongside an empty trigger_basis. The record is complete. Anyone reviewing it can see that the chain was fast and automated, and that this did not trigger a checkpoint, because the accountability conditions were all met.
For Case B, the output shows elapsed_hours: 72 under contributing_indicators_only and five explicit triggers under trigger_basis. The 72 hours contributed context. It did not decide the outcome.
The note in the field is verbatim in the runtime output: “Delay, automation level and complexity are contributing indicators only, never sufficient trigger conditions on their own.” That language lives in the evidence record, not just in the specification.
Boundary
EVE does not approve, reject, classify incidents, assess materiality or determine compliance.
EVE surfaces the signal. A named human owner decides.
The detector returns ACCOUNTABILITY_CONTINUITY_GAP or NO_CHECKPOINT_REQUIRED — and three explicit questions that a human owner must answer before the chain continues:
- ·Who currently owns the next decision?
- ·Under what declared authority?
- ·Whether that authority is still valid given changes since the last confirmed human review?
The detector does not answer these questions. It makes them impossible to skip.
This is a synthetic detector demo on illustrative fixtures. It is not a conformity assessment, not an ISO 42001 compliance product, and not certification. No customer data is used. Nothing is sealed. The design is reviewer-informed — the framing was reshaped by external feedback from an experienced ISO 42001 and IT GRC practitioner, and the vocabulary was refined in response to that input.
Why this matters
The accountability-continuity pattern is not specific to one framework. The same structural gap appears across the governance contexts where EVE Signals is being developed:
- ·Agentic AI workflows. Multi-agent chains where a human approval in one step does not automatically transfer to subsequent agent actions in a changed context.
- ·TPRM approval drift. Third-party risk management workflows where an approved vendor relationship was established under one risk profile and then the profile changes.
- ·DORA ICT third-party chains. ICT service chains under DORA where subcontracting or scope changes may affect the original approval basis.
- ·CMMC supplier chains. Defence supply chain workflows where authority boundaries between primes and sub-contractors need to remain traceable through contract changes.
- ·ISO 42001-informed governance. AI management system frameworks where human oversight accountability needs to be confirmed as workflows and system scope evolve.
- ·Cybersecurity and SOC workflows. Incident response and change management chains where an escalation decision needs a confirmed owner before the next action is taken.
The common thread: a governance decision made at one point in time, under one set of facts, may not cover a later decision made under different facts — even if the same approval record exists. Surfacing that gap deterministically, before execution continues, is the pattern this work is exploring.
Whether this is a sixth primary signal, a derived condition, or an escalation pattern on top of existing signals is an open design question. The detector is a design validation, not a production feature.
Live demo
The detector demo is public and can be run directly. No login required.
Run Case A (no checkpoint required) and Case B (accountability-continuity gap). The raw JSON output includes trigger_basis, contributing_indicators_only, required_human_confirmation, and the boundary note.
The detector API is public and returns raw JSON.
Questions about the design, the signal model, or the boundary language are welcome. Contact: joakim@organiq.se.