Governed Decision Intelligence
Availability: Open source. The specification and reference implementation are available. Field effectiveness remains untested. Status record · 2026-09-15
- The research question.
What should be recorded before an AI recommendation becomes an institutional decision?
- The contribution.
GDI defines a Governed Decision Record: the question being decided, the evidence and alternatives considered, the authority to act, and the obligations that follow. A reference classifier assigns the level of deliberation required by its configured rules.
- What has been checked.
The 114 included classifier tests passed in a local rerun, and the supplied synthetic decision passed schema validation. Additional checks expose limits in confidence routing, review enforcement, and hash coverage. Field effectiveness remains untested.
- Research materials.
Core specification v3.0 ↓ · Complete example record ↓ · Canonical Registry entry
Can you reconstruct the decision?
A model recommendation may become a payment, a changed record, or an instruction to another system. To examine that transition, an institution needs to know what was being decided, what evidence was available, who authorized the action, and what limits applied.
GDI organizes those facts around one decision. It gives a technology leader a concrete object to inspect and an operations team a proposed record to produce at the handoff to execution.
The diagram shows the intended architecture. A functioning deployment must connect the record to actual permissions, review, execution, and subsequent changes. The specification alone cannot make those connections operate.
Before an institution acts
- AI recommendation
- Governed Decision RecordEvidence · alternatives · uncertaintyHuman authority · conditions · obligations
- Institutional decisionProceed · conditional go · defer · no-go · escalate
- Enforce the resultRecord what happened
Conceptual architecture · Execution controls require integration.
What kind of research is this?
GDI is research through the construction and testing of an artifact. Its units are decision records and rule-governed actions. The current evidence comes from a schema, reference code, synthetic examples, and local interoperability work.
The local review reran the author’s classifier suite and checked the populated JSON example. Nine additional routing probes and five field-change probes examined specific implementation boundaries. These checks establish behavior of the supplied snapshot.
There are no participants, deployment cohorts, or measured institutional outcomes in this review. The test count should not be read as a sample of successful real-world decisions.
| Evidence inspected | Result or scope |
|---|---|
| Author’s classifier suite | 114 passed; 0 failed in the local rerun |
| Populated GDR example | Valid against the supplied JSON Schema, including format checking |
| Additional routing probes | 9 controlled synthetic inputs; exact outputs below |
| Hash field-change probes | 5 individually changed fields; detection depends on the sealed field set |
| Receipt conformance and field outcomes | Not independently verified in this review |
Local editorial review, 13 September 2026. This is not an independent institutional validation study.
Review results and environment ↓ · Full classifier test output ↓
One synthetic decision: an $8,400 claim
The repository’s populated example asks whether an auto insurance claim should be approved for direct payment to a repair facility. The model recommends approval with a stated confidence of 0.87. Four evidence items support the record: the intake form, damage estimate, policy record, and fraud-model output.
The record also preserves reasons for caution. The repair facility is new to the network, and the model has limited exposure to repair-cost inflation after 2025. Those details help a reader examine the proposed decision beyond its headline score.
A named human role owns the delegation, while case-specific human review is recorded as incomplete. The execution timestamp is empty. This is a synthetic illustration of authorization, not evidence that a payment occurred or that the decision was correct.
| Recorded element | Value in the supplied example |
|---|---|
| Decision | Should this auto insurance claim for $8,400 be approved for direct payment to the repair facility? |
| Scope | Single-incident property damage claim. Excludes liability determination and subrogation. |
| Stated confidence / policy threshold | 0.87 / 0.80 |
| Options recorded in detail | Approve payment; defer for more documentation |
| Human decision owner | Elena Ruiz · Senior Claims Manager and owner of the auto-approval delegation |
| Decision / gate | Go / Gate 1 under the example’s stated delegation |
| Case-specific human review | false |
| Execution timestamp | null · no execution recorded |
Table 1. Selected fields from the unchanged synthetic GDR. The four-step classifier walkthrough below is a separate fixture; it does not generate this full record.
What can a reviewer follow from the record?
Each evidence item has a source reference, freshness timestamp, completeness state, and stated confidence. Those fields tell a reviewer where to look and which assumptions to challenge. A “complete” label remains a claim made in the record until the underlying evidence is examined.
The example names both the payment service and the claims-status portal as affected systems. If the decision changes, a correction must reach the systems that acted on it.
For an institution, the proposed use is a traceable route from reasons to authorization and consequences. Whether that route is accurate, timely, and usable requires a separate operational assessment.
| Evidence item | Source type | Stated confidence |
|---|---|---|
| Claim intake form: incident date, location, reported damage description | structured data | high |
| Third-party damage estimate: $8,400 for rear-end collision repair | external api | high |
| Claimant policy record: active coverage, no lapse, deductible met | structured data | high |
| Fraud risk score: 0.06 (low risk). Model: fraud-detector-v2.1 | model output | medium |
Table 2. All four evidence items in the synthetic example. Source references are illustrative system locations, not accessible production records.
| Downstream system | Recorded obligation |
|---|---|
| payments-service | Payment of $8,400 authorized to repair facility via escrow on approval |
| claims-status-portal | Claim status updated to approved, claimant notification triggered |
High confidence can still require review
The four-gate walkthrough holds the general setting constant while changing the action, policy result, and delegation. Reading a file routes to Gate 1. A delegated search routes to Gate 2. A database write routes to Gate 3 even with a confidence of 0.85. A denied deletion routes to Gate 4 despite its 0.91 confidence.
The useful distinction is between permission, confidence, and deliberation. Each answers a different question. A permitted action may still need review because of its consequences.
These inputs reproduce the repository walkthrough in local classifier calls. No files were deleted, payments issued, or external systems queried; tool names were classification inputs.
| Synthetic action | Confidence | Policy | Observed gate |
|---|---|---|---|
| Routine read | 0.97 | Allow | gate 1 routine |
| Delegated search | 0.88 | Allow | gate 2 documented delegation |
| Consequential write | 0.85 | Allow | gate 3 elevated review |
| Denied deletion | 0.91 | Deny | gate 4 hard escalation |
Table 3. Local routing outputs using the default rules. Gate 2 includes a delegation reference. Gate 3 takes priority over delegation for an elevated tool.
Which threshold is actually operating?
The confidence document defines reference boundaries at 0.50 and 0.80. The default classifier uses 0.50 for escalation and 0.70 for review. Its policy-threshold argument is stored in the record but is not consulted by the gate-selection function.
That difference is observable: a permitted routine read at 0.75, with no delegation, returns Gate 1. A value of 0.50 returns Gate 3; 0.70 returns Gate 1. Missing confidence also returns Gate 1 for that same routine action.
Teams considering an implementation must reconcile these contracts and define how absent confidence is treated. Neither set of defaults has been shown to be calibrated for a particular institution. A score of 0.87 is not established here as an 87% chance of a correct decision.
Same score. Different boundary.
Permitted routine read · No delegation
- RED
- Below 0.50
- AMBER
- 0.50–<0.80
- GREEN
- 0.80–1
- Gate 4
- Below 0.50
- Gate 3
- 0.50–<0.70
- Gate 1
- 0.70–1
Reference rules only · No domain calibration or outcome estimate.
| Controlled input: routine read | Observed gate |
|---|---|
| 0.49 | gate 4 hard escalation |
| 0.5 | gate 3 elevated review |
| 0.7 | gate 1 routine |
| 0.75 | gate 1 routine |
| No confidence supplied | gate 1 routine |
Who makes the review or halt happen?
The standalone classifier returns a record with a gate and an escalation flag. Its caller is responsible for honoring that flag. Record writing is optional unless a writer is configured, and returning Gate 3 does not itself block execution until a reviewer responds.
The prose also varies on timing: the confidence document requires review before action in AMBER, while the gate taxonomy permits acknowledgment before or immediately after execution. That difference matters wherever intervention must change the action before it takes effect.
An integration needs an explicit sequence: record, review or escalation when required, authorized execution, and an execution receipt. The TAE question then applies: did the human decision actually reach execution?
| Layer | Behavior to distinguish |
|---|---|
| Classification | Returns a required gate and escalation flag |
| Persistence | A configured writer records the gate; default evaluation alone does not write a file |
| Review enforcement | Gate 3 identifies review; the caller must implement its timing and approval conditions |
| Halt enforcement | Gate 4 marks escalation; the caller must prevent execution |
| Execution evidence | A later event must establish what actually occurred |
Source inspection of GateClassifier.evaluate and the gate taxonomy. A complete GDR and the smaller GateRecord returned by the classifier are distinct artifacts.
What does the record hash protect?
The reference GateRecord hash covers seven fields: record ID, agent ID, tool name, tool arguments, policy result, gate, and classification time. It detects changes within that defined set.
In local probes, changing the tool name caused verification to fail. Changing confidence, the generated explanation, delegation reference, or execution time did not. Those fields lie outside this hash profile.
This distinction determines what an institution can claim from a successful integrity check. The check does not authenticate every decision-relevant field, prove the original evidence true, or establish that a human exercised judgment. The separate signed-receipt experiment has its own profile and was not rerun here.
| Field changed individually | Modification detected by GateRecord hash? |
|---|---|
| tool_name | Yes |
| confidence_score | No · outside sealed field set |
| reasoning_reconstruction | No · outside sealed field set |
| delegation_reference | No · outside sealed field set |
| executed_at | No · outside sealed field set |
Table 4. Controlled changes to copies of one synthetic gate record. Results apply to the supplied GateRecord implementation, not to every GDR or signed-receipt format.
How this fits the Node & Norm research
GDI gives Decision Evidence & Governed Action a concrete research artifact. TAE examines practical authority. HIT assesses documentary evidence of human influence. Institutional Responsibility & Repair asks what is owed after harm. These works can examine different parts of the same decision.
The GDI archive also includes DEAS, a working proposal for evaluating one evidence artifact against one specified governance requirement. It replaces the earlier DEPS portability framing. Applicability leaves sufficiency and differences between requirements open.
GDI remains usable on its own. HIT can assess records other than GDRs, and a GDR does not require a HIT assessment to exist.
| Research object | Question it addresses |
|---|---|
| GDI / Governed Decision Record | What evidence, authority, and obligations were recorded for this decision? |
| RGDS / biopharma | How are evidence gaps, conditions, and AI participation recorded at a regulated phase gate? |
| TAE | Could human judgment change what happened? |
| HIT | What does the documentary record support about human influence? |
| Institutional Responsibility & Repair | What acknowledgment, repair, and reform should follow harm? |
| DEAS v0.2.0 · working specification | What can this artifact support under this particular requirement? |
DEAS schema, mappings, cases, and reviewer validation remain in development. No cross-regime compliance or evidence-portability result is established.
What would establish usefulness in an institution?
The open outcome question is whether people can reconstruct decisions more accurately or efficiently using these records, and whether the workflow preserves opportunities to intervene, correct, and repair. Passing a schema or rule test does not answer it.
A prospective study could compare reconstruction tasks using existing logs and GDRs, measure omissions and reviewer disagreement, and test whether escalations and corrections reach the systems that act. That is a proposed evaluation, not a result of the archive review.
The current page supports inspection of the design and implementation. Claims about fairer decisions, regulatory sufficiency, or reduced harm require additional evidence.
| Open question | Evidence a future evaluation would need |
|---|---|
| Can reviewers reconstruct the decision? | Defined tasks, comparison records, missing-fact rates, time, and reviewer agreement |
| Do gates affect execution? | Observed approvals, holds, bypass attempts, timing, and downstream actions |
| Are thresholds appropriate? | Domain-specific calibration, error costs, drift, and missing-score behavior |
| Can the record be trusted? | Source accuracy, protected field coverage, access controls, and record-generation integrity |
| Does it improve outcomes? | Comparative field evidence and measures relevant to affected people |
Sources, versions, and review scope
This note uses the supplied repository ZIP. The PDF, schema, repository release, and working specification have separate version histories. Unreleased material in the snapshot should not be attributed wholesale to the archived core specification.
| Artifact | Identity in the supplied archive |
|---|---|
| Core PDF | v3.0; cover dated March 2026; some interior headers retain v2.0 |
| Citation metadata | Version 3.0; release date 1 April 2026; DOI 10.5281/zenodo.20244601 |
| Repository release | v2.1.0; changelog also includes unreleased DEAS changes |
| GDR schema | v2.0 |
| DEAS | v0.2.0 working specification; 17 July 2026 |
| Web source review | 13 September 2026; supplied archive snapshot |
The README and research claim register describe external receipt conformance as pending. This page preserves that qualified status despite stronger historical wording in the changelog; external acceptance was not checked. The earlier PDF’s broad novelty statements are not repeated as established findings.
Selected source artifacts are reproduced unchanged under Apache-2.0 with the original notice. Figures 1–2 and the local review results are new explanatory material. The source archive has no verified checkout commit identity in this review, so its SHA-256 identifies the inspected snapshot.
Research repository · Research method and claim register · Full repository validation procedure · Citation metadata ↓ · Release history · License · Attribution notice · Source manifest ↓
Archive SHA-256: 1f81345b7708aa0a4e5215863443b1f21338bf864bc1e11bb0af5228466f452e.