AI Agent Accountability Framework

One-Line Summary

The AI Agent Accountability Framework is a governance layer for agentic AI systems: a manifest protocol, accountability interface and decision record model designed to turn human-in-the-loop approval into genuine, auditable human oversight.

Why This Project Exists

Most human-in-the-loop AI systems look safer than they are.

The agent proposes something. A human clicks approve. A log entry is created. Everyone feels a little better.

But when the same person is approving dozens of proposals a day through the same interface, with no meaningful distinction between routine and consequential decisions, approval becomes a reflex. The organisation has evidence that a button was clicked. It does not necessarily have evidence that a decision was made.

That is the rubber-stamp problem.

The core question behind this project:

What would an AI governance interface look like if it was designed for decision quality, not approval throughput?

The Problem

Existing AI observability tools are strong, but they are mostly built for engineers debugging pipelines.

That leaves a gap for the people who actually approve agentic AI proposals in operational contexts: procurement leads, operations managers, compliance owners and business stakeholders.

They need to understand:

What the agent proposed.
Why it proposed it.
What context applied.
Whether the decision is routine or consequential.
What happens if they approve, override or dismiss it.
What record will exist afterwards.

The gap is not observability. The gap is accountability.

The Framework

The framework has three connected parts.

Manifest Protocol

A structured markdown document, version-controlled under git, that captures the governance context agents should reason against: strategic priorities, active risks, supplier constraints, approval thresholds, authority tiers and escalation rules.

The manifest is not a config file. It is a living governance document.

Accountability Interface

A Next.js interface built with IBM Carbon where proposals are classified, reviewed and decided.

The interface is designed around one principle: do not let consequential decisions look routine.

Decision Record

A structured record created from every approval, override or dismissal. It captures what the approver saw, what they decided, why they decided it, what was executed and what happened afterwards.

The record is not a log. It is an accountability artefact.

Key Design Decisions

Classify Proposals Outside The Agent

The agent should not decide how much scrutiny its own proposal deserves.

Classification is applied by the accountability interface using rules from the governance manifest. The agent can express confidence. It cannot mark its own homework.

Make Approve, Override And Dismiss Equal

Approve is not the goal. A good decision is the goal.

The interface gives Approve, Override and Dismiss equal visual weight so the user is not quietly nudged towards the fastest path.

Gate Consequential Approvals

For CONSEQUENTIAL proposals, Approve is disabled until the user opens the context block.

This is not a checkbox theatre moment. It creates evidence that the approver engaged with the context before committing the action.

Hide Confidence From The Header

Confidence score lives inside the reasoning disclosure, not in the card header.

A visible confidence percentage can become a decision proxy. The system should show confidence as context, not as a recommendation.

Capture The Brief As Presented

The decision record stores an immutable snapshot of the proposal exactly as it appeared to the approver.

That matters because audit questions are about what the human knew at the time, not what the system knows after later corrections.

What I Built

The first phase covers five core components:

Proposal Card: classification, summary, context, reasoning and equal decision actions.
Override Panel: first-class override flow with editable action fields and mandatory rationale.
Dismiss Panel: lightweight dismissal without treating dismissal as a failure state.
Decision Summary: read-only post-decision state linking to the full record.
Manifest Diff View: special review gate for proposals that modify governance context.

The framework is designed to connect first to TX-1, with SS-1 and Swarm Lite following as additional proposal sources.

Architecture Snapshot

Frontend: Next.js App Router and TypeScript.
Design system: IBM Carbon.
Backend: Python FastAPI.
Persistence: SQLite.
Manifest versioning: markdown under git using GitPython.
Initial integration: TX-1 supply chain scenario.

What This Demonstrates

This project demonstrates AI/UX product architecture for enterprise accountability.

It shows:

Governance as an interface problem, not only a policy problem.
Human oversight designed into the product surface.
Manifest-driven context for agentic systems.
Decision records that answer audit questions.
Enterprise design-system judgement.
A reusable accountability layer across multiple AI systems.

What It Does Not Claim

This is not claiming to solve every AI governance problem.

It does not make agents infallible. It does not remove organisational responsibility. It does not turn compliance into a button.

It provides a product architecture for making oversight more meaningful, more visible and more defensible.

Why It Matters

As high-risk AI governance requirements tighten, organisations will need more than logs.

They will need to show that qualified humans understood what they were approving, had access to relevant context, could override the system, and left behind a defensible record.

That is a design problem as much as a legal or technical one.

Companion Articles

Three companion articles unpack the public argument behind this framework:

The Oversight Illusion — why "human in the loop" is not the same as meaningful oversight.
The Context Problem — why agents need a governance manifest, not just more data.
What A Real Decision Record Looks Like — the three layers that turn a log entry into a defensible record.