The AI Proposes, A Verified Human Decides

The situation

Operations teams do not distrust automation because it is inaccurate. They distrust it because they cannot see what it did, cannot stop it mid-flight, and cannot reconstruct afterwards who allowed it. An assistant that fixes the right thing without leaving a trail is still a thing nobody will let near a database.

That makes the interesting problem a governance one rather than a modelling one. A language model can already read telemetry, correlate failures across services and suggest a remediation. What it cannot do is establish that a person agreed, that the person was who they claimed to be, and that the agreement can be shown to someone else weeks later.

So the design question is not how good the suggestion is. It is where the boundary sits between proposing and acting, whether that boundary is enforced in code or merely written in a policy document, and whether crossing it leaves something durable behind.

What it had to do

• Put the proposal and the action on opposite sides of a boundary that is enforced by code.
• Bind an approval to an identity strong enough to be worth binding it to.
• Persist every decision so it can be reconstructed by someone who was not there.
• Record the architectural decisions themselves, so the reasoning is inspectable and not just the behaviour.

What constrained it

• Nothing may write to a monitored system on the strength of a model output alone.
• An approval must be attributable to a verified identity, not to whoever held a session.
• The record of a decision has to outlive the session that made it, or it is not an audit trail.

Who built it

• Builder

The build

• 2026-08-17Repository created

Artifacts

• 

  Requirements traceability in the CoreOps Command Center

  The project's own interface, captured from the repository. Every requirement is traced to the story that fulfils it, with an enforcement state computed from the plan rather than asserted. Among them: the system must recommend actions without executing production changes, and must escalate to a human when its confidence falls below a stated threshold.

• 

  The guardrails tab, showing what is and is not enforced

  The same interface reporting its own limits: of the guardrails shown, one is enforced, one partially, one not yet. The tab labels illustrative rows as sample data rather than presenting them as measured.

What was built

The system reads telemetry from SQL Server, SSIS and SSRS, correlates failures across those services, and asks a model to reason about root cause and business impact. That half is unremarkable and is not where the design effort went.

The effort went into the guardrails directory. An ABAC evaluator decides whether an action is permissible under policy at all. A human-in-the-loop queue holds anything that would write, and holds it until a person acts. A remediation guardrail wraps the action itself. Four of the seven modules there carry their own test file, which is the difference between a boundary that is enforced and a boundary that is described.

Identity is treated as part of the boundary rather than as a login problem. One decision record commits to multi-factor authentication on the approving account; another binds an approval to a verified identity rather than to a session, so the answer to "who approved this" survives the session that produced it. An approval gate is only as strong as the identity standing behind it.

The audit trail is designed rather than logged. Separate decision records cover correlating events under a single identifier and persisting the trail, which together are what let a decision be reconstructed later by someone who was not present when it was made.

Fourteen architecture decision records sit alongside the code. That is unusual and it is the most telling artefact here: a system whose central claim is that its choices are provable after the fact has written its choices down.

The measurement

Every figure here is read from the repository at one commit and states what it was counted against.

Fourteen architecture decision records. Seven guardrail modules, four of them with a sibling test file. Forty-six test files out of 292 files in total. One hundred and thirty-two commits across eighteen days.

What these counts establish is that the governance layer exists and is tested, and that the reasoning behind it was written down as it was made. What they do not establish is how well it performs: no figure here says the remediations are correct, that any operator adopted it, or that anything downstream improved. Those need measurement this record does not have.

• 14 decision records

  Architectural decisions written down as they were made

  verified

  Baseline

  No written record, which is the ordinary case — decisions live in the code and in whoever remembers.

  Unit

  records

  Sample

  docs/ at commit d6e3db66.

  Methodology

  Counted from the repository tree at the pinned commit. Each is a named decision, not a template: transport selection, audit correlation, session authentication, serving topology, audit persistence, TOTP MFA, second-approver identity, evidence grounding, claim verification, SQL remediation safety, theming, Docker execution, Postgres remediation, and MCP roots containment order.

  Limitations

  • A written decision is not a correct decision. This counts that the reasoning was recorded, not that it was right.
  • It says nothing about whether the code still matches what the records describe.

• 7 modules · 4 with tests

  Guardrail modules, and how many carry their own tests

  verified

  Baseline

  A policy comment, which is what an unenforced boundary looks like.

  Unit

  modules

  Sample

  guardrails/ at commit d6e3db66.

  Methodology

  Counted from the repository tree. The seven are abacEvaluator, abacPolicy, auditLog, hitlQueue, remediationGuardrail, demoGovernanceEngine and demoUnsafeAction; the four tested are abacEvaluator, auditLog, hitlQueue and remediationGuardrail — which are the four that carry the boundary rather than demonstrate it.

  Limitations

  • Four of seven means three are untested, and two of those are demo modules.
  • A test proves the module behaves as written. It does not prove the policy it enforces is the right policy.

• 46 of 292 files

  Test files across the repository

  verified

  Baseline

  n/a — this sizes the test surface rather than comparing it.

  Unit

  files

  Sample

  The full repository tree at commit d6e3db66.

  Methodology

  Read from the git tree at the pinned commit, not sampled.

  Limitations

  • A file count is not coverage, and 46 of 292 says nothing about which 46.
  • The denominator includes documentation and configuration, so the ratio understates the tested share of code.

• 132 commits · 18 days

  Commits, and the span they cover

  verified

  Baseline

  n/a — this sizes the effort, it does not judge it.

  Unit

  commits

  Sample

  The default branch, first commit to the head at d6e3db66.

  Methodology

  Read from the repository at the pinned commit. Created 2026-08-17, most recent push 2026-09-04.

  Limitations

  • Commit count is the weakest measure of work and is reported only to size the span.
  • Elapsed days is not effort; nothing here says how many were working days.

What happened next

• shippedApproval boundary enforced by an ABAC evaluator and a human-in-the-loop queue

  Both modules carry their own tests. A proposed action is held until a person acts on it.

• shippedApprovals bound to a verified identity rather than a session

  ADR-006 commits to TOTP MFA and ADR-007 binds the approval to identity, so the answer to who approved something outlives the session that produced it.

• shippedAudit trail correlated and persisted

  ADR-002 unifies events under one correlation identifier; ADR-005 commits to persisting the trail.

• in_progressEvidence grounding and structured claim verification

  ADR-008 and ADR-009 record the decisions. The records exist; this case study does not establish how much of either is built.

• not_pursuedMeasuring whether the remediations are correct

  Nothing in the repository measures the quality of a proposed remediation or whether an operator accepted it. Reporting a figure would mean inventing one.