AI Governance Keeps Reinventing the Log

Jay Kreps wrote a foundational distributed-systems article in December 2013: The Log: What every software engineer should know about real-time data's unifying abstraction.

His thesis was unfashionable at the time and obvious in retrospect. He defined the primitive at its simplest:

"A log is perhaps the simplest possible storage abstraction. It is an append-only, totally-ordered sequence of records ordered by time." -- Jay Kreps

And he made a claim about its reach: "You can't fully understand databases, NoSQL stores, key value stores, replication, paxos, hadoop, version control, or almost any software system without understanding logs."

The architectural consequence Kreps drew is the part that matters here: "The log is the record of what happened, and each table or index is a projection of this history into some useful data structure or index." The log is the source of truth. Everything else is a computed read.

The same abstraction is now quietly underneath every coherent attempt at AI governance. Different vocabulary, same primitive.

The Vocabulary AI Governance Reaches For

Listen to what the conversation keeps grasping at:

• "Contemporaneous evidence captured at the moment of action."
• "An audit trail that survives 90 days of memory loss."
• "Decision provenance that can be reconstructed independently."
• "A queryable record of what each agent and service account actually did."

These are not new requirements. They are the log primitive, surfaced under different terminology, applied to a different consumer class.

The Consumer Shift

Where Kreps' log served stream processors, application replication, and database internals, the AI governance log serves auditors, claims adjusters, board NEDs, and regulators reading representation letters months after the decision.

That consumer shift -- from machines that read in milliseconds to humans evaluating evidence months later -- changes what the log has to record. The structure is similar. The properties are different.

What Changes When the Consumer Is an Evidence-Bearing Human

Four architectural shifts:

Identity is first-class at every entry. Operational logs typically do not bake in named-human-authorizer, agent, or service-account identity. They record what the application did. Evidence logs have to record who acted, under what authority, and with what scope -- preserved at every entry, not reconstructed by correlating across systems later.

Authority and scope are recorded, not inferred. The question is not "what was this agent allowed to do in general." It is "who authorized this specific action, under what scope, with what conditions holding at that moment." Captured at write time, not reverse-engineered at audit time.

Read patterns flip. Operational logs are read in near-real-time, by the application that wrote them, inside the trust boundary of the producing system. Evidence logs are read months later, by parties who were not in the room when the decision bound, and who do not necessarily trust the producing system to be honest about what happened.

The consumer cannot trust the producer. This is the structural difference most architectures miss. An application log lives inside a single trust boundary. If the application says "we did X," that is also the record of what happened. An evidence log has to satisfy a third party who is, by definition, evaluating whether the producer is being honest.

The Quiet Foundation of "We Did Not Know"

This is where many organizations will resist the architecture.

A producer-controlled log -- one where the system whose actions are being evaluated also owns the record of those actions -- is the quiet foundation of every "we did not know" defense. When the audit trail is owned by the team being audited, ambiguity is preserved. Reconstruction becomes forensic. Memory becomes the load-bearing element. And memory is fragile.

An evidence log makes that defense harder to sustain. The record is contemporaneous, independent of the producer, and queryable months later without the producer's continued cooperation.

That is the whole point. It is also why some organizations will prefer the architecture not exist.

That resistance is informative. It tells you which seats inside an organization carry personal exposure (and benefit from the architecture) and which seats benefit from the ambiguity (and will quietly oppose it). The audit committee, the CFO/COFO signing the representation letter, the NED on the board, the chief compliance officer -- these seats benefit from independent evidence. The teams whose decisions are being recorded may not.

The Six Properties of an Evidence Log

For the substrate to function across these consumer classes, the record has to satisfy six properties simultaneously:

1. Contemporaneous. Written at the moment of the decision, not reconstructed afterward.
2. Actor-identified. Which agent, which service account, which vendor-deployed system -- preserved even if that vendor is later disabled or replaced.
3. Cross-system. Spans the participating internal systems and vendors, not siloed in each one's operational log.
4. Tamper-evident. A later change is detectable, not just rare.
5. Independent of the certifier. The system whose output is being vouched for cannot be the sole keeper of the record vouching for it.
6. Reproducible without good faith. A third party reconstructs the conditions that held without trusting that the certifier's log is complete.

Standard application logs satisfy zero of these. Cloud audit logs satisfy maybe two -- contemporaneous, partial tamper-evidence -- and fail the rest. They were built for operational telemetry, not evidentiary record. The gap is structural, not a tooling-maturity problem.

The Architectural Lineage

This is the architectural lineage of what MIR records: the log primitive, specialized for governance consumers rather than stream processors.

MIR is not a stream-processing platform. It is not a SIEM. It is a participation history substrate that records what entities -- humans, employees, contractors, AI agents, service accounts -- have done over time, with the conditions under which each action happened. The substrate is queryable by consuming systems (audit, compliance, risk, the claims adjuster, the subrogating carrier, the regulator) independently of the producing system.

The Kreps log primitive, specialized for evidence consumers, applied to the AI accountability problem. That is the architectural shape.

The Architectural Homework Already Exists

If you are designing for AI accountability and you have not re-read Kreps lately, the homework already exists.

The next decade's winners will be the teams that recognize they are building an evidence log, and treat it with the same architectural seriousness Kafka treated the streaming log. The teams that try to bolt evidence onto producer-owned operational logs will discover, when consequence attaches, that they built the wrong primitive.