node&norm

An Institution Acts. What Can It Explain?

A recommendation becomes an action. The institution needs an account of the evidence, authority and obligations that carried it there.

Conceptual illustration: evidence traces pass through a citron decision boundary and continue toward separate consequences.

From the research of Mark Julius Banasihan

Essay draft · Opening scenario is hypothetical. The insurance record is a synthetic repository example.

Imagine a service team about to send a customer an approval. An AI system has checked the file, produced a recommendation and supplied a confident explanation. The proposed action is permitted. Everything on the screen appears ready. Then the customer asks which version of their request was considered, and the team discovers that the explanation does not identify it.

The recommendation might still be sound. Yet the institution cannot answer a question about the basis on which it is preparing to act. Someone now has to find the source material, determine whether the missing distinction changes the decision and decide whether the action should wait. That work requires access and authority that a fluent explanation cannot supply.

This hypothetical moment reveals a larger demand on institutions using AI. Once a recommendation becomes an approval, a payment or a changed record, people need an account of the institution’s decision. They may need to question the evidence, identify who could intervene or discover where a correction must go. An explanation becomes useful when it gives them something they can examine and a route through which the answer can change.

When a recommendation becomes a responsibility

A model’s output and an institution’s action have different authors. The model may estimate, rank or recommend. The institution decides what authority that output can exercise: whether a person must approve it, whether a prior delegation covers it, and which conditions require a pause. Those arrangements determine whose judgment can affect the result.

Mark Bovens’s conceptual account of accountability locates it in a relationship: an actor must explain and justify conduct to a forum able to question, judge and potentially impose consequences. Applied here, that directs attention to who can demand an answer and what can follow from it. A generated explanation supplies only part of that relationship.

Delegation can be reasonable. Requiring a fresh human signature on every familiar, reversible action can consume attention without adding useful scrutiny. The harder question is whether the institution can recognize when an action has moved beyond the circumstances its delegation covered. A changed document, a disputed fact or a consequence that is difficult to reverse may require a different route.

To recognize that change, a reviewer needs more than the final answer. They need to know the question being decided, the material available at the time, the alternatives considered and the limits of the permission to act. They also need time and relevant expertise. A record assembled for inspection after release may help reconstruct events, while arriving too late to support an intervention that had to occur beforehand.

Governed Decision Intelligence proposes a record organized around that transition. Its Governed Decision Record brings the decision question, evidence, alternatives, uncertainty, human authority and downstream obligations into one inspectable account. It is a specification with a reference implementation. Whether that account helps people reconstruct decisions or exercise control in a working institution remains an open empirical question.

What the record preserves

The repository’s synthetic insurance example asks whether an $8,400 claim should be approved for direct payment to a repair facility. The model recommends approval with a confidence score of 0.87. The record identifies four evidence items: the claim intake form, a damage estimate, a policy record and a fraud-model output. A reader can begin to see what the recommendation rests on.

The W3C PROV model provides an established vocabulary for describing the entities, activities and agents involved in producing information. It helps distinguish a document from the process that created it and the people responsible. That is a useful reference for the provenance problem; the comparison does not establish GDI’s conformance to PROV.

The same example records reasons for caution. The repair facility is new to the network. The model has limited exposure to repair-cost inflation after 2025. Approval and deferral are set out with their stated advantages and disadvantages. These entries make the proposed decision available for scrutiny beyond its headline score. They remain assertions in a synthetic record, whose underlying system references do not identify accessible production evidence.

A human role is named as the owner of the delegation, but case-specific human review is recorded as incomplete. The execution timestamp is empty. The example therefore illustrates how authorization can be described without establishing that a person reviewed this particular claim or that a payment occurred. Reading those fields together prevents the account from acquiring an outcome it does not contain.

This is a useful discipline for anyone receiving an institutional explanation. “Approved,” “reviewed” and “paid” describe different events. The evidence required to establish each will differ. An institution that preserves the distinctions can identify which question it has answered and which record it still needs to obtain.

Reading the synthetic example

An authorization.
An outcome still unrecorded.

  1. The proposed decision

    Approve an $8,400 claim. Four evidence items and reasons for caution are recorded.

  2. The authority named

    A Senior Claims Manager owns the delegation. Case-specific review is incomplete.

  3. The systems affected

    The payment service and claims-status portal are identified as downstream systems.

  4. The execution record

    The timestamp is empty. The example supplies no evidence that a payment occurred.

Selected fields from the repository’s synthetic GDR v2.0 example. The illustrated authorization is not a deployment result, an observed payment or a finding that the decision was correct.

Confidence does not settle permission

A number can make a recommendation feel ready. In the example, 0.87 sits above a stated policy threshold of 0.80. That relationship explains part of the recorded rationale. It does not establish an 87 percent chance that the decision is correct. The meaning of a confidence score depends on how it was produced and whether it has been calibrated for the task and circumstances in which it is used.

Chuan Guo and colleagues’ research on neural-network calibration demonstrated that predictive accuracy and reliable confidence estimates can diverge. Their experiments support checking calibration separately. They do not establish the meaning of the synthetic example’s 0.87, whose calibration evidence is absent from that record.

GDI distinguishes permission from the deliberation an action requires. Its reference classifier can route a permitted action toward elevated review because of the tool involved, even when the confidence score is high. A denied action receives hard escalation. These are configured rules governing a proposed action; their operation does not establish that the rules are appropriate for a particular institution.

The published materials also expose a boundary that an implementer would have to resolve. The confidence document places its upper reference boundary at 0.80, while the default classifier uses 0.70 as its review threshold. A permitted routine read with a score of 0.75 and no delegation falls into the document’s middle zone but routes to routine execution under the code’s defaults. The code stores a supplied policy threshold in the record without consulting that argument when selecting the gate.

That discrepancy is valuable to an examiner because it identifies a concrete question: which rule is actually governing the action? A policy statement, a configuration and an executable decision can diverge. An institution needs to reconcile them before treating the recorded explanation as an account of the rule that operated. An absent confidence score also needs an explicit policy; the routine reference path does not automatically treat its absence as a reason to escalate.

A pause needs practical force

A required review becomes consequential only through the system that carries it out. The standalone classifier returns a gate and an escalation flag. Its caller is responsible for honoring that flag, and persistence depends on a configured writer. Returning a classification does not itself establish that execution stopped or that a reviewer examined the material.

The documentation also differs on review timing. The confidence document requires review before action in its middle zone; the gate taxonomy permits acknowledgment before or immediately after execution for elevated review. An institution cannot leave that difference unresolved when a person’s intervention must precede release. A later acknowledgment may support reconstruction while arriving too late to change the original effect.

Return to the customer’s missing document version. In our hypothetical service, a designated reviewer would need to receive the objection, locate the relevant versions and determine which one governed the recommendation. If that uncertainty warrants a hold, an authorized mechanism must prevent the affected action from proceeding while the review takes place. The record should preserve the reason, the instruction and the response of the system expected to honor it.

If the action has already occurred, the task changes. The institution must determine which consequences remain reversible and who can correct them. The GDI example’s payment service and claims-status portal illustrate why identifying downstream systems matters: changing one record cannot establish that every dependent process changed with it. Execution receipts, corrected entries and delivery records would need to show what happened in each relevant place.

An intact record can still be wrong

A record can become more difficult to alter without becoming more accurate. Hashing compares the contents of a defined set of fields with an earlier value. It can reveal a change within that set. It cannot determine whether the original source was reliable, whether a reviewer understood it or whether an explanation was written to justify an outcome already chosen.

The reference classifier makes the field boundary concrete. Its smaller GateRecord hashes seven fields, including the tool name, tool arguments, policy result, gate and classification time. Confidence, the generated explanation, the delegation reference and execution time fall outside that profile. A successful check therefore supports a claim about the sealed fields. It leaves other decision-relevant content outside that check.

The GateRecord is also distinct from the full Governed Decision Record and from a separately signed receipt. Treating them as interchangeable would obscure which facts each artifact preserves. A person investigating a disputed action needs the identity and scope of the record, its source and its relationship to the event, alongside whatever integrity check has been performed.

More documentation carries costs too. Records can contain sensitive material, personal information and details that are unnecessary for a particular reader. Access, retention and redaction need to serve the inquiry without exposing everything to everyone. The person affected may need a clear explanation and a correction route; an internal investigator may need additional evidence. A machine-readable record is a resource for those accounts, not a substitute for deciding what each audience must be able to understand.

An account that can change

The public research record reports that 114 included classifier tests passed in a local rerun and that the supplied example passed schema validation. Those checks concern the supplied implementation and its representation of a decision. They are not 114 real-world decisions, and they do not establish that institutions using GDI make fairer choices, prevent harm or provide more effective remedies.

The version boundaries remain part of that account. The core specification is v3.0, the example follows the GDR v2.0 schema, and the repository identifies its release as v2.1.0. The research repository provides the specifications, reference implementation and release history needed to examine these versions. External receipt conformance and field effectiveness remain unestablished in the reviewed account.

A future evaluation could ask people to reconstruct decisions from existing logs and from GDRs, then compare omissions, disagreement and the time required. A separate operational inquiry could test whether required holds and corrections actually reach execution. These are proposed ways to examine usefulness. The current specification cannot supply their results.

Inioluwa Deborah Raji and colleagues’ framework for internal algorithmic auditing similarly places documentation within an organizational process extending across development and deployment. Its contribution is a proposed auditing framework. It gives a wider basis for asking how records enter review and responsibility, while leaving GDI’s effectiveness to be tested on its own evidence.

The institution in the opening example still owes the customer an answer about the document it used. A useful record would let the reviewer find that basis, identify who authorized the action and determine whether new information requires a change. If the account is incomplete, it should say what remains unknown and who can investigate. If the decision changes, the institution must follow the correction through to its effects. An explanation earns confidence by remaining open to examination at precisely the point where the institution would prefer the matter to be settled.