DEV Community: Ken W Alger

The Contract Discovery Bottleneck

Ken W Alger — Thu, 10 Sep 2026 16:44:00 +0000

AI can generate the code. We can verify the behavior. But who decides
what correct means?

I wrote recently about a coding agent that built me a password reset
flow with a reset link that worked more than once.

The bug survived because nobody had written down that a reset link
should be single use. It was obvious right up until it wasn't.

My argument was that as AI makes implementation cheaper, verification
becomes the bottleneck. The feature request said "build password reset."
The agent built password reset. The happy path worked. The tests passed.
The implementation looked finished.

What nobody had asked was whether the same reset link should work twice.

So I added an independently written behavioral specification. The agent
implemented against it. The verifier rejected the reusable token. The
agent fixed the implementation. The verifier passed it.

That seemed like a useful pattern:

Then I published the article, and the comments started finding things my
specification didn't say. That exposed a harder problem.

The specification wasn't finished either

One reader asked what would happen if two password reset requests using
the same token arrived at the same time.

I hadn't tested that. My test covered sequential reuse:

But concurrent reuse is different:

Both requests check the token while it is still unused. Both proceed.
If validation and consumption are not a single atomic operation, "single
use" can still produce two successful resets.

The original invariant was incomplete.

That doesn't make the specification useless. It makes the specification
provisional.

The interesting part is where the new knowledge goes.

Once somebody discovers that "single use" also means competing attempts
cannot both succeed, that should stop being knowledge held by the person
who noticed it. It belongs in the durable definition of correct
behavior.

The specification changes.

Which means the loop is really closer to this:

That is messier than the first diagram.

It is also much closer to engineering.

Separate tests can share the same mistake

Another reader described an integration builder where an agent wrote
both a connector and the tests for that connector.

Everything passed.

Both were wrong.

The connector and its tests encoded the same incorrect assumption about
OAuth token refresh. The mistake only surfaced when a customer's token
expired during a live session.

The implementation and test suite were separate artifacts. They were not
independent in the way that mattered.

They shared an assumption.

That distinction matters because "independent verification" can sound
like an organizational property:

different file
different test suite
different agent
different step in the pipeline

None of those necessarily provides independence.

If the implementation and verifier derive their definition of correct
behavior from the same incomplete prompt, they can agree perfectly and
still be wrong.

The student is no longer literally grading the same exam.

Two students have simply studied from the same incorrect answer key.

Generating more tests doesn't discover the missing rule

Another commenter asked whether property-based testing or giving an
agent an adversarial security persona might do a better job uncovering
these unstated constraints.

I think both are interesting, but they expose the same boundary.
Property-based testing can explore a stated invariant extremely well.

If I tell a framework:

A successfully consumed reset token must never produce another successful reset.

it can generate combinations and sequences I would never think to
hand-author.

But it cannot tell me that single use was a requirement if nobody
expressed it.

An adversarial agent has a similar problem. Asking a model to "try to
break this" may produce better tests than asking it to "write tests for
this feature." But if the adversary shares the same context, model
assumptions, and incomplete understanding of the requirement, how
independent is it really?

The question starts shifting from who writes the tests? to a more
difficult one: where does the definition of correct behavior come
from?

The verifier can be wrong too

One of the most interesting examples in the discussion came from a
verification harness rather than generated application code.

A capability test timed out.

The harness recorded the result as a failure.

But a timeout did not establish that the capability failed. It
established that the harness did not obtain a result within the allotted
time.

Those are different claims.

FAILED

and

NOT TESTED

are not interchangeable.

The verifier had turned an observation failure into an assertion about
capability.

That's a useful warning for any architecture built around deterministic
verification: deterministic does not mean correct.

A verifier can enforce the wrong invariant with absolute consistency.

So can a specification.

The goal isn't to replace an unreliable agent with an infallible
verifier. There is no infallible verifier.

The goal is to make the definition of correctness explicit enough that
it can be inspected, challenged, tested, and revised independently of
the implementation.

So who writes the contract?

This was the question that pushed the argument furthest for me.

If humans have to write complete behavioral specifications before agents
can implement anything, haven't we simply moved the bottleneck back to
humans?

Probably.

And worse, the concurrency example demonstrates that humans don't
necessarily know the complete specification beforehand either.

So "humans write the contract" isn't much of an answer.

An agent could propose it.

That sounds circular at first. If the agent proposes the implementation
and proposes the contract, aren't we back to the student grading the
exam?

Only if proposing the contract and accepting the contract are the same
operation.

They don't have to be.

An agent might generate a candidate operating contract:

reset token:
  may be used once
  competing attempts cannot both succeed
  expires after N minutes
  cannot authorize a different account

A human, another system, or some combination can then challenge that
much smaller artifact.

The question being reviewed becomes:

Is this an adequate definition of correct behavior?

rather than:

Is this entire implementation correct?

That doesn't solve the trust problem, but it reduces its surface area.
Reviewing four lines is a different activity than reviewing four hundred.
One is a conversation about intent. The other is an audit.

But this runs straight back into the answer key problem.

If the same model that will implement the feature also proposes the
contract, they share assumptions. An agent that doesn't know single use
matters won't propose single use as an invariant. It will produce a
confident, well-formatted contract with the same hole in it, and now the
hole has been written down and approved.

So accepting a contract has to do more than approve it. It has to
introduce something the proposing agent didn't have.

That might be a person who has debugged this class of bug before. It
might be a genuinely different model, though I'm unsure how much
independence that buys. It might be a checklist derived from past
incidents, which is really institutional memory in a form an agent can
read. For a reset token, somebody's list somewhere already says: single
use, expiry, no account substitution, no concurrent success, session
invalidation.

The value comes from the independence of the source, not from the
ceremony of the review.

That may be a more tractable thing to build tooling around than
verification itself.

Maybe verification isn't the deepest bottleneck

This is where the comments changed my framing.

I started with:

I'm less sure that's where it stops.

Once implementation is cheap and verification is increasingly
automatable, the harder problem may become discovering the invariants
worth verifying.

Call it contract discovery.

The requirement says:

Reset my password.

Somebody has to discover:

The link works once.

Then:

Two concurrent attempts cannot both succeed.

Then perhaps:

The token cannot authorize a different account. A token issued before another successful reset may no longer be valid. A reset invalidates existing sessions.

Some of those are product decisions. Some are security properties. Some
are implementation-independent behavioral invariants. Some may not apply
at all.

The difficult work is deciding which ones belong to the definition of
correct.

AI can help propose them.

Property-based testing can explore them.

Deterministic systems can enforce them.

Production incidents will unfortunately discover some of them for us.

But none of those eliminates the need to decide which claims actually
define correctness.

This gets harder when agents start acting

There is another reason I think this matters beyond generated code:
agents don't just write things anymore. They call things.

An agent calls an API. The response is 200. The agent moves on.

But a 200 says the request was processed. It doesn't say the
constraint the agent's plan depended on was enforced. Maybe the call
timed out after the write succeeded, so the retry performed the effect
twice. Maybe the operation was legitimate the first time and should have
been rejected the second.

That second one should look familiar. It's the reset link, one layer
out.

A bad implementation leaves an artifact somebody can inspect later.

A bad tool call already happened.

It sent the email. Charged the card. Revoked the access. Posted the
message.

There is no diff to read.

This is where the contract-discovery problem becomes more consequential.
The system needs some definition of what the agent is permitted to cause
and what evidence would establish that the intended effect actually
happened.

I don't think I have the architecture for that yet, but one boundary is
becoming clearer:

The specification can be agent-readable without being agent-owned.

The agent should be able to see the invariant. Withholding the
requirement only makes the work guesswork.

But the agent shouldn't be able to quietly redefine the invariant when
satisfying it becomes inconvenient.

Whatever accepts, stores, and evaluates the contract needs some
independence from the reasoning that produced the implementation or
action.

Where that boundary belongs remains a harder question.

The specification is durable because it can change

Calling the specification a durable artifact can sound like calling it
an immutable one.

I don't mean that.

A durable specification should change when we learn something about what
correct behavior actually requires.

What makes it durable is that the knowledge survives the implementation
that taught us the lesson.

The reset implementation may be rewritten next month.

The framework may change.

The agent may change.

The database may change.

But once we've established that two competing reset attempts cannot both
succeed, that invariant should survive all of them.

The same applies to an integration. Once a production failure teaches us
what token refresh must guarantee, that knowledge should not remain
attached to the incident report or the engineer who debugged it.

It should become part of what "correct connector" means.

The implementation may be disposable. The accumulated definition of
correctness is not.

I still don't think this is solved

There are plenty of uncomfortable questions left.

How independent does a verifier have to be?

Can two agents using different prompts but the same underlying model
provide meaningful independence?

Who accepts an agent-proposed contract?

How do you distinguish a genuine product invariant from an
implementation detail that shouldn't survive the current code?

What happens when two valid invariants conflict?

How do contracts evolve without quietly weakening previous guarantees?

And how do we verify effects in external systems where state is delayed,
partially observable, or distributed?

I don't have good answers to all of those. That's partly why I don't
think the answer is simply "write better tests." The tests are
downstream of the harder question.

Write down what you mean by correct

The original password-reset bug happened because a rule existed in
someone's head and nowhere else.

The comments on that experiment showed the next problem: writing down
one rule doesn't mean you've found all the others.

That's fine. The specification doesn't have to arrive complete. It has
to provide somewhere for discovered invariants to go, and that somewhere
has to be a place with a history: versioned, reviewable, and attached to
the behavior rather than to the incident that revealed it.

Maybe an agent proposes them. Maybe a human notices them. Maybe
property-based testing exposes them. Maybe an independent reviewer asks
the annoying question nobody else asked. And sometimes production will
teach us the expensive way.

The important part is that each discovery makes the durable definition
of correct behavior better.

AI is making it remarkably cheap to turn an instruction into working
code.

Verification asks whether the code did what we said. Contract discovery
asks whether we said enough. I'm starting to think that's the harder
problem.

Why User Provisioning Matters for Enterprise AI

Ken W Alger — Thu, 10 Sep 2026 12:44:00 +0000

Offboarding a user is not enough when the credentials they leave behind can still spend money and invoke tools.

An orphaned SSO account is inert. Nobody logs in, nobody clicks anything, and eventually someone notices it during an access review.

An orphaned AI credential is different.

A virtual key can still have a budget, provider and model access, and perhaps permission to invoke MCP tools against other systems. The person it belonged to may have left six months ago while the credential continues doing exactly what it was authorized to do, with nobody attached to it and nobody wondering why its usage still appears on the bill.

That is why user provisioning for enterprise AI is not simply another implementation of the joiner, mover, leaver problem IAM teams have managed for decades. The identity lifecycle is familiar. The consequences of getting it wrong are not.

How Should Enterprise AI Provision New Users?

The joiner case is the easy one, which is precisely why it should not get much attention.

The previous post looked at how roles and access profiles connect human authorization to runtime policy. With Bifrost user provisioning, an identity-provider group can map a user to a role, the role supplies its default access profile, and that profile issues governed access when the user arrives. Providers, models, budgets, rate limits, and tool access have already been decided. The new employee inherits policy instead of inventing it.

That is the ideal state: nobody files a ticket for an API key or remembers which model Marketing may use. Organizational intent was encoded before the employee arrived, so provisioning mechanically applies a decision already made.

Joiners are the flattering part of lifecycle management. Movers are where exceptions accumulate.

Why Are Role Changes Dangerous for Enterprise AI Access?

Imagine the acquisition from the first post six months later. One engineer initially joins the migration team, later moves to the platform group, and eventually transfers into an internal agent project.

Each move is legitimate. Each requires new access. The dangerous question is what happened to the old access.

Role-based provisioning can replace assignments that originated from a role default. But a profile assigned directly to a user represents an explicit exception, so it survives the role change. The system can distinguish a role-derived assignment from a direct assignment; it cannot determine whether the reason behind that exception still exists.

Combine that with the role behavior from the previous post: when someone holds multiple roles, permissions resolve upward rather than to their intersection. The result is a familiar enterprise failure with an AI-specific blast radius. People gain access at every transition and shed it at none.

Three teams into someone's tenure, their effective authorization may resemble the union of all three jobs they have held. That can mean access to models approved for a previous team, a larger budget, different logs, or tools their current role has no reason to invoke.

Movers therefore need more than synchronization. They need reconciliation. Bifrost's user provisioning model reflects role and team changes when users are reconciled against the identity provider, but lifecycle management still has to account for exceptions outside those inherited defaults. Automation is good at applying known rules and poor at deciding whether an exception created fourteen months ago still has a business justification.

The question is not simply, "What access should this person's new role add?" It is also, "What access no longer has a reason to exist?" Who owns this key, why does this direct assignment still stand, and would the organization grant the same access today if asked fresh? Those are governance questions rather than provisioning mechanics, and no synchronization job will answer them.

In practice, reconciliation is a scheduled comparison rather than an event handler. Once a quarter, list every access profile assignment that did not come from a role default, along with who created it, when, and against which stated justification. Anything without a justification on record is the finding. Anything with one is a question for the person who owns that team, and the question is not whether the access is being used but whether it would be granted again today.

That distinction matters because usage is a misleading signal here. An unused grant is not evidence of safety; it is a capability sitting idle until an incident or an automation reaches for it. A budget that has never been spent still authorizes the spending.

What Should Happen to AI Access When a User Leaves?

Leavers expose the difference between identity management and AI lifecycle management most clearly.

The obvious response to a departing employee is deletion: remove the account, revoke credentials, clean up the objects, and leave the system tidy. The second post in this series discussed why an expired virtual key should instead fail closed without disappearing. During offboarding, that distinction becomes critical.

By the time someone leaves, the system may hold an identity, roles, access-profile assignments, a virtual key, budget counters, model permissions, rate limits, tool grants, and a record of requests made under that authority. Some must stop working immediately. Some must survive.

Event	Identity	Role	Access profile	Virtual key	MCP credentials	Record
Joins	Created on first login	From IdP group	Role default applies	Issued automatically	Authorized per user	Created
Moves	Unchanged	Replaced	Role defaults swap; direct assignments persist	Reissued	Persist separately	Retained
Leaves	Deactivated	Removed	Copy retained	Fails closed	Revoked separately	Preserved

The last row is the architecture: fails closed, record preserved.

Suppose Security investigates an event six months later. The useful questions are historical: which models could this person reach, what budget applied, did they have MCP tool access, and was that access inherited or directly assigned?

Deleting lifecycle objects because the employee left makes those questions harder precisely when their answers matter most. This is a write-side custody problem as much as an identity problem. The system should preserve enough state to explain what happened rather than reconstructing it later from an IdP, billing export, deleted credential, and today's configuration.

Offboarding therefore has two obligations that pull against each other: end the authority, and preserve the evidence. A leaver should become incapable of causing new actions without becoming invisible to the historical record.

That distinction matters most with tools, and there is a second object hiding here. Where an MCP server uses per-user OAuth, the departing employee holds credentials that are separate from their virtual key and have to be revoked separately. Bifrost exposes a sessions view for inspecting and revoking those per-user MCP credentials, which is easy to miss in an offboarding checklist designed before agentic AI entered the enterprise stack.

It is worth being precise about why that is three operations rather than one, because they fail independently.

Deactivating the identity stops someone logging in. It does not reach anything already issued under that identity. An offboarding process that ends here has closed the front door and left every key that was cut from it in circulation.

Invalidating the virtual key stops the requests. This is the operation most teams think of as revocation, and it is the one that actually severs runtime authority. It should fail closed while remaining inspectable, for the reasons above.

Revoking per-user MCP credentials is the one most likely to be missed, because the credential is not entirely yours. Per-user OAuth means the employee authorized an external service directly, and the resulting grant lives at that service. Invalidating their virtual key stops requests flowing through the gateway. It does not, on its own, tell the external provider that the authorization behind those requests should end. That grant has to be revoked where it lives, which is why a sessions view exists as a separate surface rather than as a checkbox on the user record.

The practical consequence is that "we deactivated their account" answers only the first of three questions, and the third one is the one nobody thinks to ask.

The exposure is conditional rather than automatic, and the condition is the interesting part. By default Bifrost does not execute tool calls on its own; a model returns suggestions and the application has to call the execution endpoint explicitly. But a workload running in agent mode with auto-approval configured has no such pause. A forgotten SaaS login is dormant until somebody uses it. An orphaned key attached to an autonomous workload is already being used, and the human whose authority justified those tool grants left two quarters ago.

An orphaned SSO account is inert.

An orphaned virtual key is an actor.

And there is a question sitting underneath all of this that the series has not answered. The record survives the person, but six months later, what does that record actually prove, and who should be allowed to read it? Removing access is only half of offboarding. The other half is being able to explain what happened while that access still existed.

One practical distinction before designing around any of this. Bifrost itself is open source, including the gateway and the core governance around virtual keys, budgets, routing, and MCP tool filtering. The user provisioning and identity lifecycle discussed here are Enterprise capabilities, and the documentation is the better place to check that boundary than a blog post.

What Happens to AI Credentials That Never Had a User?

There is one uncomfortable limit to this model: lifecycle management assumes a lifecycle.

None of it helps with an identity the system never knew about. A contractor handed a key directly. A shared service account nobody quite owns. A credential minted for a pipeline in 2024 by someone who has since left. These may be the most consequential actors in the environment, because they run continuously, spend consistently, and often hold broad permissions on the theory that automation is inconvenient when it fails. Unlike a person, they never transfer teams and never trigger an offboarding workflow. You cannot deprovision an identity that never existed.

The only workable answer is to give them the lifecycle events they will never generate on their own. Every non-human credential needs a named human owner, not a team alias, and a review date on the calendar. The owner is who gets asked when the credential appears in an incident. The review date is the substitute for the HR event that will never arrive. Expiry helps here more than it does for people: a workload credential that has to be renewed annually forces someone to state, once a year, that the thing still needs to exist. Most of the credentials that worry security teams would not survive that question.

That leaves enterprise AI with a harder question than joiners, movers, and leavers: how do you govern actors that were never people in the first place? An agent does not join a team, does not sit in a reorganization, and does not have a last day. It has an owner who may or may not remember creating it, a budget nobody reviews, and a set of tool grants that made sense on the afternoon they were issued.

That is where the lifecycle problem stops being about users and starts being about workloads.

This article was commissioned by the Bifrost team. The link to the Sovereign Systems Specification points to my own work. The architectural perspective and conclusions expressed here are my own.

The Verification Bottleneck in AI-Generated Software

Ken W Alger — Wed, 09 Sep 2026 14:32:00 +0000

AI can generate code faster than ever. That doesn't mean we're shipping correct software faster.

Recently, I asked a coding agent to build a password reset flow. It produced the route, the token handling, the email integration, and the UI in about five minutes.

The implementation had a bug. The reset link worked more than once. Use it to set a new password, then open the same link again, and it still worked.

The feature request hadn't explicitly said that a reset link should be single use. It wasn't in the feature request, because it's the kind of thing that goes without saying right up until the moment it doesn't. Every path a person would click through by hand worked perfectly. A code review might have caught it. A demo would not have.

That gap is what I want to talk about.

Code generation is no longer the expensive part

Traditional software development has an obvious constraint: humans have to write the software. We think about the requirement, design the implementation, write the code, run it, discover that it doesn't work, debug it, and repeat until we're sufficiently convinced.

AI coding agents compress parts of that loop dramatically. The agent can often produce an implementation faster than I can thoroughly review what it generated, which creates an inversion. For a long time, writing code was expensive and checking it was comparatively cheap. What happens when writing becomes cheap?

Verification becomes proportionally more valuable.

Suppose an agent implements a feature in five minutes, but determining whether the implementation is correct requires another 45 minutes of manual testing and code review. We haven't created a five-minute development process. We've created a 50-minute development process with a very fast implementation stage.

And the verification half is harder than it used to be, because you're now auditing code you didn't write.

Generating more code doesn't solve that. We need a better feedback loop.

The specification is becoming the durable artifact

Here's the shift I think matters most, and it goes well beyond testing.

If an agent can rewrite a component cheaply, we become less attached to any particular implementation. Implementations are becoming disposable. Six months from now the routes change, the framework changes, the DOM changes, the internal architecture changes.

The user requirement doesn't:

A user who resets their password must subsequently be able to authenticate with the new password, must no longer be able to authenticate with the old one, and must not be able to reuse the reset link.

In an era of inexpensive code generation, the thing worth maintaining is increasingly the specification rather than the implementation. Which means it's worth writing the specification first, deliberately, as an artifact in its own right rather than as documentation of something already built.

Start with behavior, not implementation

I tested this with a small web application, Claude Code, and testRigor.

The application was deliberately ordinary: authentication, user accounts, login behavior, the kind of functionality in countless business applications. I wasn't interested in whether an agent could produce something visually impressive. I wanted to answer a different question. Can we define expected behavior first, let an agent implement it, and use independent end to end verification to determine whether the agent actually succeeded?

Consider the password reset feature. The implementation involves a route, form handling, token generation, validation, password hashing, database updates, session behavior, error handling, and UI changes. An agent generates all of it quickly.

None of those implementation details are what the user cares about. The user cares whether they can request a reset, receive the email, set a new password, log in with it, and whether the old password and the used link both stop working.

Those are observable outcomes. That makes them a useful boundary between what we asked the agent to build and what the agent actually built.

Executable specifications

This is where testRigor became interesting to me.

testRigor expresses tests as English-like behavioral instructions rather than requiring the test author to work primarily in selectors and automation code. A test describes what a user does and what they expect to see.

That creates an opportunity when combined with AI-assisted development, because the behavioral test can function as an executable specification.

Instead of telling an agent to "add password reset," we provide a behavioral contract. The application must email a reset link. The link must lead to a form. The new password must work afterward. The link must not work a second time.

Now there are two artifacts with two responsibilities. The coding agent is responsible for figuring out how to implement the behavior. The behavioral test is responsible for determining whether the behavior exists.

That separation is the point.

Don't let the student grade the exam

AI coding tools are increasingly capable of generating their own tests, and that's useful. I use it. But there's a problem when the same system interprets the requirement, creates the implementation, creates the test for that implementation, and then announces that everything passes.

The system can make the same mistaken assumption in multiple places. If the agent misunderstands the requirement, it produces code consistent with that misunderstanding and tests that validate the same misunderstanding.

Everything is green, and everything is also wrong.

This is exactly what happened with the reset link. An agent asked to write its own tests for the feature it just built would have tested the happy path, because the happy path is what it understood the requirement to be. It would have passed.

The single use check existed only because a specification written before the code asked a question the feature request never raised. That's the whole value: not that the test is in English, but that it was written by someone thinking about the requirement rather than about the implementation.

Independent behavioral verification asks a different question:

Regardless of how you implemented this, does the software exhibit the behavior we specified?

That's closer to the question a user actually cares about.

Closing the loop

The part of this that interests me most isn't the testing tool. It's the feedback loop.

Once an end to end test produces a deterministic pass or failure, that result becomes input to the coding agent. The agent implements the feature, the behavioral test runs, and if the test fails, the failure returns to the agent. The agent examines the implementation, makes another change, and verification runs again.

" width="800" height="1373">

In my case the full cycle ran three times. Red against the baseline, because the feature didn't exist yet. Red again after generation, on the reused link. Green after the failure text went back to the agent as context. About twenty minutes of wall clock end to end, most of it unattended.

The failure text mattered more than I expected. It wasn't a stack trace. It was a step in the behavior, in plain English, that didn't happen. That's readable by a person and readable by an agent, which is what let the loop close without me translating between them.

The agent now has something more useful than "try again." It has evidence that a specific expected behavior was not observed.

Spec-First Verification for AI-Generated Code

The video is rough around the edges, which is probably appropriate for an experiment. The interesting part isn't production quality. It's watching the loop operate.

Generation and authority are different jobs

This reinforced something I've been thinking about more broadly in AI system design. Probabilistic systems are extraordinarily useful for proposing things: generate this implementation, interpret this requirement, suggest a fix, explain this failure, determine which files probably need to change.

But there are places where I want something else to have authority. Did the build succeed? Did the API return the expected response? Does the database contain the expected state? Can the user complete the specified workflow? Did the test pass?

Those questions can be answered deterministically, which gives a useful architectural separation:

AI proposes. Deterministic systems verify.

It doesn't eliminate mistakes. A badly written test verifies the wrong thing. An incomplete specification leaves important behavior uncovered. A test environment can differ from production. Verification itself needs engineering.

But separating generation from verification means we stop treating the model's confidence as evidence that the implementation is correct.

Behavioral tests aren't magic

Working with an English-like testing system reinforced another lesson: plain English does not mean no learning required.

Tools still have semantics. You need to understand how the system identifies elements, interprets instructions, manages state, handles authentication, and responds when the application doesn't behave as expected. There were several moments where I had to learn testRigor's particular vocabulary before a seemingly obvious instruction did what I expected. My spec assumed the application would land on a login form after a successful reset. It didn't. That's a gap in my specification, not a bug in the application, and finding it took a run I hadn't budgeted for.

That isn't a flaw unique to testRigor. Abstractions don't eliminate complexity. They move it.

SQL didn't eliminate the need to understand databases. High level languages didn't eliminate the need to understand software. Natural language testing doesn't eliminate the need to understand testing.

What changes is who can express the behavior, and how tightly that behavior is coupled to implementation details. That part is genuinely interesting.

What we should be optimizing

Much of the excitement around AI-assisted development has focused on productivity. How much faster can developers write code? How many tasks can an agent complete? How many tokens did it use?

Those metrics aren't useless, but they aren't the outcome. Software exists to behave correctly enough to solve a problem.

If an agent generates 10,000 lines in ten minutes and we spend the rest of the day figuring out whether any of it works, those lines aren't evidence of productivity. They're inventory awaiting inspection.

The metric worth tracking is correct functionality delivered per unit of time. That includes generation, but it also includes verification. As generation approaches zero marginal effort, the second half is where the remaining cost lives.

Coding agents are going to get better. They'll generate larger changes, operate longer without supervision, understand more complex repositories, and handle more of the implementation process autonomously. That makes verification more important, not less. Greater autonomy without independent evaluation doesn't produce a better development system. It produces a faster source of unverified output.

The opportunity is to build verification into the architecture rather than bolting it on afterward. The specification defines the destination. The coding agent proposes a route. Verification tells us whether we actually arrived.

Not generating code faster. Shipping working software faster.

Context Hydration: When Memory Becomes Voice

Ken W Alger — Tue, 08 Sep 2026 14:41:00 +0000

Part 7 of the Building the AI Memory Stack series

Back in Part 1, I made a promise: memory eventually becomes voice.

Up to this point, we've built the architecture that makes trustworthy memory possible.

The Context Window executes work.

Active Working Memory assembles the state required for that work.

Durable Memory preserves knowledge worth keeping.

The Reasoning Ledger explains how decisions were made.

Write-Side Custody ensures only trustworthy information becomes institutional memory.

Forensic Receipts make that memory provable.

All of that effort leads to one inevitable question:

How does cold, trustworthy memory become useful reasoning again?

The answer is Context Hydration.

Notice that Context Hydration is not another layer. It is the transition that lifts stored memory back into active reasoning, the arrow rather than the box.

Memory That Never Returns Isn't Very Useful

Imagine an engineering handbook containing thousands of Architecture Decision Records. Every decision has provenance, every revision has history, and every document was validated before it entered long-term storage. It's a remarkable archive.

Until an AI agent needs to answer a question.

At that moment, none of that durable knowledge matters until some of it is restored into working memory. Stored knowledge is inert. Reasoning requires living context.

Hydration Is More Than Retrieval

Traditional retrieval systems ask one question:

"Which documents are relevant?"

Context Hydration asks a different one:

"Which verified knowledge deserves to consume tokens for this task?"

Those questions sound similar, but architecturally they are very different.

Retrieval finds. Hydration restores.

The Hydration Boundary

The Sovereign Systems Specification calls this transition the Hydration Boundary.

Before information crosses that boundary, the system asks:

Has this information been verified?
Is it still authoritative?
Does this task actually require it?
Is there a cheaper representation?
What is the token cost of restoring it?

Hydration is not a bulk export. It is deliberate reconstruction.

Verification Before Expansion

One subtle architectural decision matters enormously: the system should verify memory before expanding it into prompts. Verification is cheap; context windows are expensive. Hydrating untrusted information wastes both compute and attention.

The cheapest token is the one you never have to generate.

Hydrate Only What the Task Needs

One of the biggest misconceptions in agent design is that bigger context automatically produces better answers. Usually it produces more distraction.

Every additional document competes for the model's attention.

Every unnecessary paragraph increases the Context Tax.

Every observation collected "just in case" contributes to the Observer's Tax.

Good hydration isn't about restoring everything. It's about restoring enough.

Latency Is Part of the Architecture

Hydration has a cost. Verification, retrieval, expansion, and serialization all take time, and every layer adds latency.

That doesn't make hydration a bad idea. It makes it an architectural tradeoff rather than an implementation detail.

The question isn't "Can we hydrate this?" The better question is:

"Is this memory worth paying to restore?"

When Memory Becomes Voice

This is the promise we began with. Memory has no value sitting on disk. It becomes valuable only when trusted knowledge crosses the Hydration Boundary and becomes reasoning once again.

That is the moment memory becomes voice.

Looking Ahead

We've now assembled the complete AI Memory Stack. The final two articles zoom out.

The next explores the hidden economic costs of prompt-centric architectures: the Prose Tax, the Retrieval Tax, and the broader fiscal architecture of modern AI systems.

Because building trustworthy memory is only half the challenge. Operating it efficiently is the other half.

Can Rust Make Unsafe AI Agent Actions Unrepresentable?

Ken W Alger — Sun, 06 Sep 2026 11:29:00 +0000

I went looking for a better runtime check and found a different way to think about the problem.

I have spent a lot of time recently thinking about what an AI agent should be allowed to do.

Reading data is one thing. Writing durable state is another. Sending an email, approving a refund, changing a production configuration, or deleting a record moves farther along the same spectrum.

The usual answer is to put a guardrail in front of the dangerous operation.

" width="549" height="1216">

That makes sense, and I have built examples that work exactly this way.

Then I started looking at how I might implement the same kind of boundary in Rust.

Rust asked a more interesting question:

Why does the dangerous function accept an unchecked action in the first place?

Runtime Checks Are Still Checks

The complete runnable example is on GitHub if you want to make the compiler angry yourself.

Consider a simplified AI agent that can write information into durable memory.

The agent proposes a write:

struct ProposedWrite {
    key: String,
    value: String,
    authority: String,
}

Somewhere else in the application we have a function that persists it:

fn persist(write: ProposedWrite) {
    // write to durable storage
}

Obviously we should validate the write first.

fn validate(write: &ProposedWrite) -> bool {
    // validate provenance
    // evaluate authority
    // apply policy
    true
}

Then our application does this:

if validate(&write) {
    persist(write);
}

Perfectly reasonable.

It also means persist() will happily accept a ProposedWrite that has never been validated. We are relying on every caller to remember the protocol.

That is not necessarily a problem in a small example. In a large agentic system with multiple tools, services, developers, and execution paths, it becomes a much more interesting assumption.

What happens when somebody adds this six months later?

persist(write);

The compiler sees nothing wrong. The type is correct. The application is wrong.

Make the State Part of the Type

Rust gives us another option. Instead of treating "proposed" and "approved" as metadata attached to the same object, we can make them different types.

struct ProposedWrite {
    key: String,
    value: String,
    authority: String,
}

struct AdmittedWrite {
    key: String,
    value: String,
    authority: Authority,
}

Now persistence accepts only the second one:

fn persist(write: AdmittedWrite) {
    // write to durable storage
}

This seemingly small change alters the boundary. An agent can produce a ProposedWrite. It cannot produce an AdmittedWrite directly, provided we control how that type is constructed. Something trusted has to perform the transition.

The persistence layer no longer asks:

Has somebody remembered to validate this?

Its API says:

Give me something that has already crossed the admission boundary.

That is a much stronger contract.

This has a name in Rust circles: the typestate pattern, encoding a value's state in its type so that only valid transitions type-check. It is the type-level cousin of a principle Alexis King named "parse, don't validate". Instead of checking a value and handing the same type onward, hoping every later caller re-checks, you transform it into a new type whose very existence proves the check already happened. The check is not something you remember to run. It is something the type system will not let you skip.

The Compiler Becomes Part of the Boundary

The phrase "provided we control how that type is constructed" is doing all the work in the previous section, so let us actually deliver that control. This is where the earlier version of this article was too loose, and where Rust rewards precision.

mod custody {
    use super::ProposedWrite;
    // Authority, Rejection, and validate_authority are defined in this module.

    pub struct AdmittedWrite {
        key: String,
        value: String,
        authority: Authority,
    }

    impl AdmittedWrite {
        pub fn key(&self) -> &str {
            &self.key
        }
        pub fn value(&self) -> &str {
            &self.value
        }
        pub fn authority(&self) -> &Authority {
            &self.authority
        }
    }

    pub fn evaluate(write: ProposedWrite) -> Result<AdmittedWrite, Rejection> {
        let authority = validate_authority(&write.authority)?;

        Ok(AdmittedWrite {
            key: write.key,
            value: write.value,
            authority,
        })
    }
}

The important detail is what is not marked pub. The struct is public, so other modules can name the type and accept it in their signatures. Its fields are private.

That distinction is the whole boundary. In Rust, a struct literal like custody::AdmittedWrite { key, value, authority } requires every field to be visible at the construction site. Because the fields are private to the custody module, no code outside that module can write that literal. And there is no other public constructor. The only way to obtain an AdmittedWrite from outside is to hand a ProposedWrite to evaluate and have it succeed.

So the persistence layer, which lives outside custody and reads the data through the accessor methods, cannot be handed a value that skipped evaluation. Not because a reviewer will catch it, but because the code that would skip evaluation does not compile.

Here is the shortcut a tired developer might reach for six months from now:

let proposed = ProposedWrite {
    key: "refund_policy".into(),
    value: "Refunds under $100 do not require manager approval.".into(),
    authority: "policy".into(),
};

persist(proposed);

And here is what the compiler says about it:

~\Rust_AI_Actions is 📦 v0.1.0 via 🦀 v1.98.1
❯ cargo build
   Compiling unrepresentable v0.1.0 (~\Rust_AI_Actions)
error[E0308]: mismatched types
   --> src\main.rs:128:13
    |
128 |     persist(proposed);
    |     ------- ^^^^^^^^ expected `AdmittedWrite`, found `ProposedWrite`
    |     |
    |     arguments to this function are incorrect
    |
note: function defined here
   --> src\main.rs:95:4
    |
 95 | fn persist(write: AdmittedWrite) {
    |    ^^^^^^^ --------------------

For more information about this error, try `rustc --explain E0308`.
error: could not compile `unrepresentable` (bin "unrepresentable") due to 1 previous error

The mistake never reaches review, staging, or production. It stops at the one place a mistake is cheapest to fix, on the machine of the person who made it, the moment they made it.

The state machine is no longer sitting in a comment:

// IMPORTANT: call validate() before persist()

It is represented by the program.

One honest caveat for larger teams: private fields close the door from outside the module, but code inside custody can still build the struct with a literal. If you want to forbid even that, give AdmittedWrite a private field of a private zero-sized type, a construction token that only evaluate can mint. Then the blessed function is the single point of construction anywhere, inside the module or out. Whether that is worth the ceremony depends on how much you trust the inside of your own boundary.

This Doesn't Make the Agent Safe

This is where I need to resist making the argument bigger than it is.

Rust does not know whether the policy is good. It does not know whether Authority::SecurityTeam actually represents the security team. It does not know whether the provenance supplied to the custody boundary is genuine. And it certainly does not solve prompt injection because I changed a struct.

If this function is wrong:

fn validate_authority(value: &str) -> Result<Authority, Rejection>

then Rust will very efficiently enforce the wrong rule.

Types can constrain which states the program represents. They cannot determine whether our model of the world is correct. That distinction matters.

Witnessed Is Another State

The exercise gets more interesting when provenance enters the picture.

Suppose the agent says:

{
  "key": "refund_policy",
  "value": "Refunds under $100 do not require manager approval.",
  "authority": "policy",
  "source": "internal_policy"
}

Should the agent be allowed to decide that its own source is an internal policy? Probably not. The system that retrieved the source is in a much better position to make that claim.

So perhaps our states are not merely:

Proposed → Admitted

They are closer to:

A ProposedWrite contains what the agent claims. A WitnessedWrite adds evidence established outside the agent. An AdmittedWrite represents a write that has been evaluated against policy.

struct ProposedWrite {
    key: String,
    value: String,
    claimed_authority: String,
}

struct WitnessedWrite {
    proposal: ProposedWrite,
    source: WitnessedSource,
}

struct AdmittedWrite {
    key: String,
    value: String,
    authority: Authority,
    source: WitnessedSource,
}

Now different parts of the system accept different states:

fn witness(write: ProposedWrite) -> Result<WitnessedWrite, WitnessError> {
    // establish source evidence outside the agent
}

fn evaluate(write: WitnessedWrite) -> Result<AdmittedWrite, Rejection> {
    // apply policy to the witnessed write
}

fn persist(write: AdmittedWrite) {
    // write to durable storage
}

Each step accepts only the output type of the step before it. There is no signature anywhere that accepts a ProposedWrite and persists it, so the shortcut is not something you have to remember not to take. It is not expressible. The types are the protocol; nothing else has to announce it.

What Rust Changed for Me

I started this experiment thinking about how to implement an AI safety boundary in another language. The more interesting lesson was that Rust made me reconsider where the boundary should live.

In many systems, we encode state like this:

{
  "status": "approved"
}

Then every downstream consumer has to inspect status and behave correctly.

Rust encourages another question:

If these states permit fundamentally different operations, why are they represented by the same type?

That question matters for AI agents because agentic systems cross consequential boundaries constantly.

A model proposes a tool call. A runtime authorizes it. A tool executes it. A result becomes memory. Memory later becomes context. Context influences another action.

At each transition, we can either carry another flag saying what happened, or change what the next component is capable of accepting. Those are not equivalent designs.

Invalid States Versus Invalid Reality

There is an important limit here.

Suppose a write was legitimately admitted yesterday because Alice had authority to approve it. Alice leaves the company today. The AdmittedWrite type does not magically expire. Likewise, a policy can be superseded, a credential revoked, or evidence later discovered to be wrong.

The compiler can enforce:

This value crossed the required transition.

It cannot establish:

Everything that justified that transition remains true forever.

That still requires runtime governance, lifecycle management, revocation, and revalidation.

So I would not claim Rust makes unsafe AI actions impossible. What it can do is make certain classes of architecturally invalid transitions harder to express accidentally.

That is narrower. It is also much more believable.

Could I Do This in Another Language?

Of course.

You can model state transitions in Go, Java, TypeScript, Python, C#, or plenty of other languages. You can build wrapper types, sealed classes, discriminated unions, private constructors, capability objects, and carefully designed APIs. Rust does not own the idea, and the typestate pattern predates it.

What I found useful is that Rust keeps pushing the design conversation in this direction. Ownership asks who controls a value. Visibility asks who can construct it. The type system asks what operations are valid for it. Result makes failure part of the function signature.

None of those concepts exists specifically for AI safety. Together, though, they provide an unusually direct vocabulary for designing agent boundaries, and the defaults nudge you toward making the boundary structural instead of remembered.

The Bigger Lesson

A lot of AI safety architecture is necessarily dynamic. Policies change. Users have different authority. Tools expose different capabilities. Context changes what an action means. We are never going to compile all of that uncertainty away.

But not every invariant is dynamic.

If an unwitnessed write must never be persisted, perhaps persist() should not accept unwitnessed writes. If an unevaluated tool call must never execute, perhaps execute() should not accept unevaluated tool calls. If a rejected action must never cross a boundary, perhaps rejection should produce a state for which crossing that boundary is not an available operation.

That is what Rust changed in how I think about this problem.

I started by asking:

How do I check that the agent is allowed to do this?

Rust made me ask:

Why does this function accept something the agent is not allowed to do?

That is a much better question.

Forensic Receipts: From Trusted to Proven

Ken W Alger — Thu, 03 Sep 2026 13:14:00 +0000

Part 6 of the Building the AI Memory Stack series

At the end of the last article, I left one question unanswered.

Can you prove this record is exactly what was written?

Write-Side Custody decides which writes are trustworthy enough to become memory. But a decision to trust something is not the same as being able to prove it later.

Picture that deployment record one more time. Custody examined it, judged it authoritative, and let it become institutional memory. Six months on, an auditor asks a harder question: how do you know it hasn't changed since?

"We only accept trustworthy writes" is a policy.

It is not proof.

Trust Is a Claim. Proof Is Evidence.

Custody and receipts answer two different questions.

Write-Side Custody asks: should this be trusted?

A Forensic Receipt asks: can this be proven?

The first is a judgment made at the moment of the write. The second is a piece of evidence that outlives the judgment, so that anyone, later, can verify the record for themselves without having to trust the system that stored it.

With that, the stack reaches bedrock. Every layer above now rests on a foundation that can be verified independently.

What a Forensic Receipt Is

The Sovereign Systems Specification calls this evidence a Forensic Receipt.

It is not a log entry. Log entries can be edited, reordered, or quietly rewritten. A Forensic Receipt is a cryptographic fingerprint of a record, captured and signed at the moment the record is written.

Change one character of the record, and the fingerprint no longer matches. The tampering isn't hidden. It's mathematically obvious.

In practice, a receipt might look like this:

forensic_receipt:
  record: reasoning_ledger/deploy-2026-03-14
  content_hash: sha256:3af9c1...e07b
  signed_at: 2026-03-14T09:22:07Z
  signature: ed25519:9d4a...c2
  signed_by: sovereign-node-07
  prior_receipt: sha256:8b21...44a

Two fields do most of the work.

The content hash binds the receipt to the exact bytes of the record. Nothing can be altered without breaking it.

The prior receipt links each record to the one before it, forming a chain. You cannot quietly remove or reorder history without every downstream receipt failing.

That is chain of custody, expressed as mathematics rather than as a promise.

Why Logs Aren't Enough

Most systems already keep audit logs.

The problem is that an audit log is only as trustworthy as whoever controls it. If someone can write to the log, they can usually rewrite it, and a log that can be rewritten proves nothing about the past.

A Forensic Receipt inverts that. It doesn't ask you to trust the operator, the database, or the backups. Verification depends on cryptography, not on authority, so the evidence speaks for itself.

That distinction is the whole point.

Custody earns trust. Receipts remove the need for it.

The Cost of Proof

None of this is free. Every receipt is a hash computed and a signature generated at write time, which is real work, paid on the write path, exactly where this series has argued trust belongs.

But the alternative is worse. A system that cannot prove its own memory is asking you to take its word for everything it claims to remember.

Proof is the price of being believed later.

The Stack Is Now Trustworthy and Provable

Step back and look at what the six layers guarantee together.

The Context Window executes. Active Working Memory assembles. Durable Memory preserves. The Reasoning Ledger explains. Write-Side Custody decides what to trust. Forensic Receipts prove it.

Execution, assembly, preservation, explanation, integrity, and evidence.

That is a complete architecture for trustworthy institutional memory.

Looking Ahead

We've built memory that is durable, explained, trustworthy, and provable.

But it is still sitting in cold storage.

None of it matters until it can return to active reasoning: verified, on demand, and paid for deliberately.

That is where the next article takes us, and where the promise from Part 1 is finally kept. It is the moment memory becomes voice.

Your Hiring Process Needs HTTP Status Codes

Ken W Alger — Wed, 26 Aug 2026 15:14:00 +0000

Because "we'll be in touch" is not an observable state.

I submitted a job application recently.

It was one of those applications where you actually put in the effort. I read the job description carefully, tailored the resume, wrote a cover letter specifically for the organization, and answered the optional questions rather than pretending they were optional.

Then I clicked Submit and got... nothing.

No confirmation email. No "we received your application." No indication that a candidate record had been created. Just a browser page telling me the submission had succeeded and the vague hope that somewhere, deep inside an applicant tracking system, my carefully assembled application had not been written directly to /dev/null.

As a developer, I find this troubling. Not because I expect an interview, or because I think every recruiter owes me personalized feedback. I just want a status code.

And I think that's a smaller ask than it sounds like, for a reason I'll come back to at the end: the states already exist. Somewhere in that ATS, my application is in one. The decision not to show me which one is a product decision, not a privacy constraint.

The Web Solved This Problem Decades Ago

When software sends a request to another system, we generally consider it useful for the receiving system to say what happened. Did it work? Is it still processing? Was the request malformed? Is the resource gone? Did something catch fire on the server?

HTTP gives us an entire vocabulary for this.

Hiring systems, meanwhile, have developed their own protocol:

POST /careers/applications

[no observable response]

This is sometimes followed, anywhere from three minutes to six months later, by:

After careful consideration...

Instead of inventing vague candidate statuses like "Under Consideration," perhaps hiring systems could adopt something developers already understand.

The 2xx Family: Success, Allegedly

`200 OK`

A human being has reviewed your application.

Nothing else is implied.

Honestly, this alone would be revolutionary.

`202 Accepted`

Your application has been received and accepted for processing.

This is the most important status code in the entire hiring protocol. The candidate does not need the hiring manager's notes or a walkthrough of the internal workflow. They need:

202 APPLICATION_ACCEPTED

Now we know the thing exists.

`204 No Content`

Your application was successfully received.

We have chosen not to acknowledge this in any way.

The 3xx Family: You Have Been Redirected

`302 Found`

We found an internal candidate.

Thanks for playing.

`304 Not Modified`

Your application has been "Under Review" for 47 days.

There has been no change since the last time you checked, or the 23 times before that. There will be no change the next time either. Please consider caching this response locally.

`410 Gone`

The position existed when you applied. It no longer exists. No additional information is available.

At least 410 would be useful. The current discovery mechanism is noticing that your bookmarked job posting has started redirecting to the careers homepage.

The 4xx Family: This One's On You

`401 Unauthorized`

You must create an account before applying.

Your password must contain at least 14 characters, uppercase and lowercase letters, a number, a symbol, and one ancient Sumerian glyph. It cannot match any password you have used since 1997.

You will then manually enter every field from the resume you just uploaded.

You will never use this account again.

`403 Forbidden`

You have the required experience and qualifications.

Unfortunately, you live 37 miles outside the geographic boundary within which we have determined this Zoom meeting can occur.

`404 Not Found`

Hiring manager not found. Recruiter not found. Job posting not found.

Nobody knows who owns this requisition.

`408 Request Timeout`

After seven weeks without communication, the candidate has accepted another position.

The hiring team will contact them tomorrow to schedule the second interview.

`409 Conflict`

The position requires 12 years of production experience with a technology introduced six years ago.

The conflict cannot be resolved.

`417 Expectation Failed`

You expected the phrase "we'll be in touch" to imply future communication.

It did not.

`422 Unprocessable Content`

Your experience is relevant, but your career path does not fit cleanly into the predefined boxes in our applicant tracking system.

Human intervention may be required.

Human intervention is unavailable.

`425 Too Early`

You applied 14 minutes after the job was posted.

LinkedIn reports 612 applicants.

We have questions too.

`451 Unavailable For Legal Reasons`

Your qualifications are not the issue.

The issue is a background check vendor, a non-compete of uncertain enforceability, or a sponsorship question nobody wants to be the one to ask about.

The 5xx Family: It Was Never You

`500 Internal Server Error`

Something has gone wrong internally. Your recruiter left, the headcount was frozen, the hiring manager changed, Finance reconsidered the budget, the organization restructured, or the position was posted by accident.

We will communicate all of these possibilities using the same message:

We have decided to move forward with other candidates.

`502 Bad Gateway`

The recruiter says they are waiting for the hiring manager.

The hiring manager says recruiting owns the next step.

Your request cannot be routed.

`503 Service Unavailable`

Your recruiter is no longer with the company.

Their calendar link remains active.

`504 Gateway Timeout`

"We expect to have a decision by Friday."

Friday has passed. The specification does not define which Friday was intended.

Candidates Don't Need Distributed Tracing

There's a serious point hiding under all of this. Hiring has an observability problem, and it's usually mistaken for a communication problem.

Companies understandably cannot expose everything happening inside a recruiting process. Candidate evaluations are private. Interview feedback may be sensitive. Hiring managers need room to compare people and make decisions.

That's fine. Nobody is asking for:

GET /hiring-manager/private-thoughts/about-me

But there is an enormous amount of territory between exposing confidential deliberations and providing no information at all.

A hiring pipeline already has states. An application was received. It entered review. Someone reviewed it. An interview was requested. The requisition was paused. The position was filled. The position was canceled. The candidate was declined.

Those state transitions already exist in the system. They are already recorded, timestamped, and reportable, because that's how recruiting teams measure their own funnel. The candidate is the one participant in the process who cannot see the record they're in.

Give Us the Boring Version

Imagine an applicant portal that reported nothing more than this:

202  APPLICATION_RECEIVED     Mar 04
200  REVIEWED                 Mar 19
304  NO_CHANGE                Apr 02
304  NO_CHANGE                Apr 30
410  POSITION_CLOSED          May 12

That's not radical transparency. It's barely transparency at all. But it tells you the system is functioning.

It removes the need to wonder whether an application disappeared. It reduces pointless portal refreshing. And it prevents candidates from reading silence as information, when silence might mean anything from "the hiring manager is on vacation" to "the requisition was canceled two weeks ago."

Mostly, it treats applicants like participants in a process rather than packets transmitted into an undocumented endpoint.

`200 OK`

I don't expect every application to result in an interview. I've submitted enough of them to have considerable empirical evidence supporting that position.

I don't expect detailed rejection feedback either. I understand why companies are reluctant to provide it. I don't even particularly mind 403 REQUIREMENTS_NOT_MET or 410 POSITION_FILLED. Those are answers.

What makes modern hiring uniquely frustrating isn't rejection. It's uncertainty about whether anything is happening at all.

Software engineers have spent decades building systems around a simple principle: when one system asks another to do something, the response should carry enough information to understand what happened.

Candidates aren't asking for distributed tracing of your recruiting infrastructure.

We'd settle for a status code.

Your AI Agent Shouldn't Be Allowed to Write Whatever It Wants

Ken W Alger — Tue, 25 Aug 2026 19:11:50 +0000

Building a Write-Side Custody gate in Go

AI memory systems spend most of their design budget on retrieval. Which vector database? How should we chunk? Which embedding model? What should top_k be?

Those are useful questions, but they all arrive after something more consequential has already happened: the system decided that some piece of information deserved to become memory.

Consider an agent researching vendors for regulated workloads. It finds this statement:

Vendor X is approved for regulated workloads.

The source is Vendor X's own marketing site.

The statement might be true. It might even be current. But the source does not have the authority to establish organizational security policy. If our agent writes it directly into durable memory, better retrieval will not save us. We have only made questionable evidence easier to find.

The problem is not storage. It is admission.

I've been calling the architectural boundary responsible for that decision Write-Side Custody. Let's build a small one in Go.

What Write-Side Custody Does

A storage API answers a mechanical question:

Can I persist this object?

Write-Side Custody asks a different set:

Who is trying to write this?
Where did the information come from?
What authority is being claimed?
Is that source allowed to establish that authority?
Does policy permit this class of information to become durable?
What evidence should survive the decision?

Only after those are answered should storage become involved.

Note that the Reasoning Ledger does not make the decision. Custody enforces. The ledger witnesses. That separation matters a great deal once these systems have to be examined later.

Start With the Proposed Write

Go gives us a useful property for this experiment: we can make the things crossing our boundary explicit.

type ProposedWrite struct {
    Content          string
    Source           string
    ProducedBy       string
    ClaimedAuthority string
}

Our research agent might produce:

write := ProposedWrite{
    Content:          "Vendor X is approved for regulated workloads.",
    Source:           "https://vendorx.example.com/why-vendorx",
    ProducedBy:       "research-agent-run-4471",
    ClaimedAuthority: "security-policy",
}

Nothing in this structure says the statement is false, and that's intentional. Write-Side Custody is not a universal truth detector. It determines whether a proposed write satisfies the rules governing this particular memory system.

For this system, a vendor marketing page cannot establish internal security policy. So we need policy.

Make Authority Explicit

First, two types. Authorities and source classes are different kinds of thing, and there is no situation in which we want to accidentally use one where the other belongs:

type Authority string
type SourceType string

Now we can define which source classes may establish which authorities:

type Policy struct {
    AuthoritySources map[Authority][]SourceType
}

var policy = Policy{
    AuthoritySources: map[Authority][]SourceType{
        "security-policy": {
            "internal-security-policy",
            "security-authority",
        },
        "user-preference": {
            "user",
        },
        "application-state": {
            "application",
            "runtime",
        },
    },
}

In production this comes from a policy service or configuration layer rather than a Go literal. The important part is that the relationship exists independently of whatever the agent claims. The agent does not get to decide that a marketing page constitutes security authority simply because it found one saying something useful.

Give the Gate a Verdict

type Verdict string

const (
    Allow Verdict = "ALLOW"
    Deny  Verdict = "DENY"
)

type CustodyDecision struct {
    Verdict   Verdict
    Reason    string
    Timestamp time.Time
}

Now the gate itself:

func EvaluateWrite(
    write ProposedWrite,
    sourceType SourceType,
    policy Policy,
) CustodyDecision {
    allowedSources, ok :=
        policy.AuthoritySources[Authority(write.ClaimedAuthority)]

    if !ok {
        return CustodyDecision{
            Verdict:   Deny,
            Reason:    "unknown claimed authority",
            Timestamp: time.Now().UTC(),
        }
    }

    for _, allowed := range allowedSources {
        if sourceType == allowed {
            return CustodyDecision{
                Verdict:   Allow,
                Reason:    "source may establish claimed authority",
                Timestamp: time.Now().UTC(),
            }
        }
    }

    return CustodyDecision{
        Verdict:   Deny,
        Reason:    "source cannot establish claimed authority",
        Timestamp: time.Now().UTC(),
    }
}

Two decisions in there are worth surfacing.

The first is that conversion on the map lookup. ProposedWrite holds plain strings because that's what arrives over the wire, deserialized from JSON we did not write. Authority(write.ClaimedAuthority) is the moment an untrusted string becomes a term in our governance vocabulary, and it happens inside the gate rather than at the edge of the process. That's the right place for it. Custody is precisely the layer where foreign input earns domain meaning.

The second is that sourceType is a separate parameter. It is not a field on ProposedWrite.

That is deliberate. Source classification is a judgment about the write, not a property the writer gets to assert about itself. If sourceType lived on the struct, our agent could label its own marketing page internal-security-policy and the gate would cheerfully agree. The classifier belongs to the custody layer, or to a runtime component that can independently observe where the content came from.

Small signature choice. Most of the security property.

Our vendor claim now reaches the boundary:

decision := EvaluateWrite(write, "vendor-marketing", policy)

fmt.Println(decision.Verdict)
fmt.Println(decision.Reason)

And receives:

DENY
source cannot establish claimed authority

The statement never becomes durable memory. We did not store questionable evidence and hope retrieval would eventually sort things out. We governed the write while the evidence and its provenance were still in hand.

The full gate, the policy, and a table-driven test suite covering the cases above are in memory-stack-patterns. Standard library only, so go test ./... and go run ./cmd/demo work on a clean checkout with nothing to install.

Don't Throw Away the Rejection

Rejecting a write does not make the decision useless.

Imagine someone asks six months later:

Why doesn't the system remember that Vendor X was approved?

"I don't know" is not a satisfying answer, and in a regulated environment it isn't an acceptable one either.

The custody decision is observable system behavior, which makes it a candidate for a Reasoning Ledger record:

type LedgerEntry struct {
    ID               string
    Timestamp        time.Time
    Actor            string
    Action           string
    Verdict          Verdict
    Reason           string
    Source           string
    ClaimedAuthority string
}

Our gate emits:

entry := LedgerEntry{
    ID:               newID(),
    Timestamp:        decision.Timestamp,
    Actor:            write.ProducedBy,
    Action:           "durable-memory-write",
    Verdict:          decision.Verdict,
    Reason:           decision.Reason,
    Source:           write.Source,
    ClaimedAuthority: write.ClaimedAuthority,
}

(newID is a few lines over crypto/rand, which keeps the whole example dependency-free.)

This entry is deliberately simplified. A ledger you would actually rely on needs a canonical serialization, a hash chain linking each entry to its predecessor, and some defense against tail truncation, because an append-only log that anyone can quietly shorten is not append-only.

Even the timestamp is less innocent than it looks. time.Now() gives you whatever precision the host clock offers, and JSON drops trailing zeros, so two entries can serialize at different widths. Hash a chain over a non-deterministic encoding and you have hashed nothing. The repo linked above truncates to a fixed precision and formats with a fixed-width layout for exactly that reason.

The Python implementation in the Sovereign Systems SDK does all three, which is part of why the Go exercise interests me. The hard parts are already solved somewhere. The open question is what happens to the boundary when it moves.

What matters here is the shape of what survives. The rejected statement still doesn't enter memory. What persists is evidence that a write was proposed, evaluated, and rejected under a named rule. That is a different kind of information than the claim itself, and it's the kind that answers questions later.

The Agent Doesn't Get to Grade Its Own Homework

There's a further boundary hiding in the payload. Suppose our agent sends:

{
  "content": "Vendor X is approved for regulated workloads.",
  "source": "https://vendorx.example.com/why-vendorx",
  "claimed_authority": "security-policy",
  "retrieval_method": "fresh",
  "policy_verified": true
}

Should we believe the last two fields?

There is an epistemic difference between:

The agent says it performed a fresh retrieval.

and:

The runtime that performed the HTTP request witnessed a fresh retrieval.

The same distinction applies to tool execution, timestamps, approval events, and policy versions. A stronger custody boundary therefore doesn't only ask whether a record may be written. It asks:

Is this writer authorized to assert this particular kind of claim?

The agent legitimately owns claims about itself: its decision, the alternatives it considered, its confidence, the unknowns it identified. The runtime should mint the facts it can independently witness. Custody should not promote the former into the latter merely because both arrived in valid JSON.

This is the same principle as the sourceType parameter, applied one level up.

Why Do This at Write Time?

You could defer all of this to retrieval. Store everything, attach metadata, and let the reader decide what governs.

But then every questionable write becomes something every future reader has to reason around. It consumes storage. It becomes eligible for retrieval. It competes for context. It can be summarized, embedded, and propagated into records that no longer carry its provenance. And once provenance is gone, a future system may not have enough information to work out why the record was questionable in the first place.

A bad write today becomes bad context tomorrow.

Write-Side Custody puts the decision at the moment the system has the best possible view of what it is admitting.

Why Go?

None of this architecture requires Go, which is partly why I wanted to build it in Go.

A custody gate is a boundary service, and Go fits that role: explicit data structures, unremarkable HTTP services, small deployable binaries, and a type system strong enough to make the important distinctions visible without taking over the implementation.

The Authority and SourceType declarations we needed earlier are the clearest example. They cost one line each, and in exchange the compiler now refuses to let a source class be used where an authority belongs. That distinction would otherwise have lived in a variable name and a hope.

The same move applies elsewhere:

type Verdict string
type ActorType string

At which point the function signatures start expressing the vocabulary of the governance system rather than just its plumbing. EvaluateWrite doesn't take three strings. It takes a proposed write, a source classification, and a policy, and no caller can shuffle them by accident.

Go didn't create the architecture. It made the contracts hard to leave implicit.

Memory Begins Before Storage

Vector databases are very good at answering questions about similarity. They cannot tell us whether something deserved to become memory.

That's an architecture decision, and by the time retrieval surfaces the problem, the questionable record may already have shaped dozens of others.

Give the proposed write provenance. Give the boundary policy. Give the decision evidence. Then let storage do what storage is good at.

Store what survived.

One thing I keep turning over: this boundary shouldn't depend on Go. If Write-Side Custody only makes sense inside one language, it isn't much of an architectural boundary. I'm curious what it would look like elsewhere. Would Rust's type system make an invalid custody decision impossible to construct rather than merely inconvenient? Would Pydantic and FastAPI make the policy check feel so natural you'd stop noticing you were doing governance at all? If you've built something like this in your stack, I'd like to hear how the boundary changed shape.

Disclosure: I maintain the Sovereign Systems specification and SDK, which is where the vocabulary in this post comes from. The Go code here is a reference implementation written to test whether the idea travels, not a product.

Write-Side Custody: Trust Begins Before Memory

Ken W Alger — Tue, 25 Aug 2026 13:30:00 +0000

Part 5 of the Building the AI Memory Stack series

The previous articles introduced the Reasoning Ledger and then worked through what a single ledger record should contain. Together they answered a hard question: why did this decision happen, and how do we design a record that can be trusted to say so honestly.

That raises the question underneath all of it. A record is only as good as what was allowed to become one in the first place.

Imagine reviewing an AI-assisted deployment six months later, the same approval the Reasoning Ledger recorded earlier in this series. The ledger says it was approved. The evidence looks complete, the timestamps make sense, everything appears correct. Then you notice that one of the "authoritative" policy records the decision relied on was written by a tool run that no one had authorized, from a source that should never have been treated as governing.

Nothing was tampered with after the fact. The record is faithful. The problem is earlier than that: a write that should never have been accepted became institutional memory, and every decision downstream inherited it.

At that point the problem is no longer memory. It is admission.

Memory Alone Cannot Create Trust

Throughout this series we have gradually separated the responsibilities of an AI system. The Context Window enables execution. Active Working Memory assembles context. Durable Memory preserves knowledge. The Reasoning Ledger explains and records decisions.

None of those layers decides whether a given piece of information deserved to enter the system at all. Knowing what happened is valuable. Ensuring that only trustworthy information became part of what the system knows is what makes the rest of it worth trusting.

The Landfill Problem

Organizations rarely fail because they cannot remember enough. They struggle because they cannot distinguish trusted institutional knowledge from accumulated noise.

This is the failure mode that should motivate everything else in this article. A durable memory that accepts every write eventually becomes a landfill: technically complete, searchable, and useless, because the trustworthy records and the junk are indistinguishable once they are all sitting in the same store with the same retrieval priority. Every low-quality write does not just take up space. It becomes a candidate for future retrieval, future reasoning, and future decisions. A bad write today is bad context tomorrow.

The instinct is to fix this on the read side, with better ranking and filtering. That helps at the margin and loses the war, because by the time a bad record is competing for retrieval, it already looks like everything else. The cheaper and more durable fix is not to accept it in the first place. That decision has to happen at the boundary, before the write becomes memory.

Trust Begins Before Storage

A common architectural assumption is that integrity can be added later. Encrypt the database, protect the backups, restrict access. Those are all worthwhile, and they are also too late. By the time information reaches storage, the most important decision has already been made: whether this write should have been accepted at all.

The Sovereign Systems Specification calls the responsibility for that decision Write-Side Custody. It sits before information becomes durable memory, and it asks a different question than a storage layer does. A storage layer asks whether this can be persisted. Custody asks whether it is legitimate.

Instead of "can this be stored," custody asks whether the information is authoritative, whether the source is trusted, whether the supporting evidence was preserved, whether the write violates policy, and whether this should become institutional knowledge at all. The answers determine whether the write is accepted, rejected, or accepted with qualification.

What a Custody Decision Looks Like

Principles are easy to nod along to and hard to picture, so here is a concrete one.

An agent finishes a tool run and tries to write a new record into durable memory:

proposed_write:
  content: "Vendor X is approved for regulated workloads."
  claimed_authority: security-policy
  source: web-fetch:vendor-x-marketing-page
  produced_by: research-agent-run-4471

At the boundary, custody evaluates it rather than storing it:

custody_decision:
  accepted: false
  reason: authority-mismatch
  detail: >
    Record claims security-policy authority, but the source is an
    external marketing page, not the security team's policy service.
    A regulated-workload approval cannot be granted by the artifact
    it would benefit.
  action: discard
  recorded_to_ledger: true

The write never reaches durable memory. The content might even be true, and it still fails, because custody is not judging whether the claim is plausible. It is judging whether this source is allowed to establish that claim as governing knowledge. An approval that arrives from the thing being approved does not get to become institutional memory, no matter how confident the text sounds.

Notice the last field. The rejection did not vanish. It became an event the Reasoning Ledger preserves, which is the point of the next section.

Custody Enforces. The Ledger Witnesses.

There is an apparent contradiction here worth resolving directly, because a reader following the series will feel it.

The Reasoning Ledger, by design, does not enforce. It witnesses. Its records stay examinable precisely because the ledger cannot block anything. Write-Side Custody, by contrast, exists to enforce. It rejects writes. So which is it, do these layers block things or not?

Both, and that is the whole architecture. Custody is the enforcement boundary. The ledger is the witness that records what the boundary decided. When custody rejects the vendor-approval write, custody makes the decision and stops the write, and the ledger records that a write was proposed, evaluated, and rejected, along with the reason. Neither layer does the other's job. The enforcer never becomes the historian, and the historian never gets a veto. That separation is exactly why each one can be trusted at what it does: an enforcer that also wrote the only account of its own decisions would be unauditable, and a witness that could block actions would stop being a neutral record.

This is the same "separate custody, one interface" principle from earlier in the series, seen from the write side. Different responsibilities, deliberately kept in different layers, cooperating at a boundary.

Every Write Is a Governance Event

Traditional applications treat writes as database operations. Agentic systems should treat them as governance events, because in an agentic system a write is not just data at rest. It is a future participant in reasoning.

Every accepted write influences future retrieval, shapes future reasoning, and becomes a candidate for future decisions. That is a much larger claim than "this row was inserted." It means the moment of admission is the cheapest and most powerful place to protect everything downstream. A policy check at the boundary is worth more than a great deal of read-side cleverness later, because it prevents the bad record from ever competing for attention in the first place.

Custody is what keeps durable memory intentional rather than merely persistent. It is the mechanism that slows the entropy from trusted knowledge toward landfill, one admission decision at a time.

Looking Ahead

Write-Side Custody decides what is allowed to become memory. It does not, on its own, prove that an accepted record is still byte-for-byte what was written.

Suppose someone asks a harder question six months later: not "should this have been accepted," which custody answers, but "can you prove this exact record has not been altered since." That is a different guarantee, and it needs more than an admission policy. It needs evidence that survives independent of the store that holds it.

That is where Forensic Receipts enter the architecture, and where the next article takes us.

Designing a Reasoning Ledger Record

Ken W Alger — Sat, 22 Aug 2026 06:23:00 +0000

A companion to Part 4 of the Building the AI Memory Stack series. Part 4.5 of the series.

Part 4 argued that agentic systems need a Reasoning Ledger: a layer that preserves why a decision happened, not just what was decided. The comment thread that followed turned into something more specific and more useful, a working design conversation about what a single ledger record should actually contain. This piece consolidates that. Several of the strongest ideas below arrived from other people, and I have tried to credit them where they land.

The easy version of this article is a schema. Here are the fields, copy them, done.

I want to resist that, because the field list is the least durable thing I could hand you. Implementations differ, field names drift, and a record shape copied without its reasoning becomes cargo-cult structure that nobody maintains. The useful thing is the set of design tensions that decide what belongs in the record and what does not. Get those right and you can derive the fields yourself. Get them wrong and no schema will save you.

So this is principles first, record second. At the end there is a worked record and a field reference, tagged for what is core and what is genuinely optional.

A Starting Point

Here is the baseline record from Part 4. It is a reasonable start and, as the thread quickly established, incomplete in instructive ways.

reasoning_ledger:
  decision: "Approve deployment"
  timestamp: 2026-03-14T09:22:00Z
  evidence:
    - artifact: ADR-014
      authority: architecture-review
      version: 3
    - artifact: security-policy
      authority: security-team
      version: 7
  tools:
    - GitHub
    - CI pipeline
  approvals:
    - release manager
  outcome: approved

Every principle below is, in effect, a thing this record does not yet say.

Principle 1: The Ledger Witnesses, It Does Not Enforce

The first tension is architectural, and it is the one I would defend hardest. A reasoning ledger must not be able to block, veto, or gate the action it records. Its job is to preserve what happened and what evidence surrounded it. The moment the ledger can prevent an action, it stops being an independent witness and becomes part of the mechanism it is supposed to describe, and its own records stop being examinable as neutral fact.

This came up when pm25coder noted, correctly, that a ledger that only narrates can quietly become fiction, and that trust comes from being able to gate rather than merely describe. I agree with the diagnosis and draw the boundary one step earlier: enforcement is real and necessary, but it belongs at the policy and tool boundary, not inside the witness. The ledger preserves that the boundary was evaluated and what it returned. The boundary decides whether the action proceeds.

The practical consequence for the record: a ledger entry can contain a policy_evaluated result showing that a check ran and what it concluded, but it never contains the enforcement decision as its own authority. It reports; it does not rule.

Core. This is not a field, it is a constraint on the whole design.

Principle 2: Supersession Is a New Event, Never a Rewrite

A superseded decision should become a new record that points back at the old one. It should never overwrite the original. "We decided A, and later decided B instead" is two events with a relationship between them, not one field that changed value.

This matters because "wrong now" does not mean "was never decided then." If you rewrite the March record when you change course in August, you have destroyed the ability to answer whether the March decision was reasonable given what was known in March. The noisier history is the correct trade. Compaction can always produce a clean current-state projection later, but once you have rewritten the historical evidence, you cannot reconstruct it.

This is the same append-only discipline that makes Forensic Receipts useful: preserve what was decided under which evidence and authority, then record the superseding decision as its own event with its own receipt.

Core.

Principle 3: Record How the Authority Was Obtained, Not Just Which One

The baseline record says version: 7. That tells a future reader what supposedly governed. It does not tell them how the system established that version 7 was authoritative at decision time, and those are very different trust claims.

Self-Correcting Systems and pm25coder arrived at this from opposite directions and met in the middle: a policy version fetched fresh from its authority at 09:22, a version read from a five-minute cache, and a version inherited from session state can produce identical version: 7 fields while supporting completely different claims about what the system could reasonably have known. The fix is to treat the authority fetch itself as a recorded event. The record should say which source was consulted, when, what came back, and whether cached state was involved.

This also exposes the sharpest failure mode in the thread, the one an otherwise perfect ledger cannot catch on its own. If the external authority moved to version 8 an hour before your decision and nothing in your system observed that change, the record faithfully captures version 7 and stays perfectly self-consistent. It is a flawless account of a decision that was already wrong when it was made. The record cannot flag this, because there is no edge to preserve; nothing inside the system ever saw the change. Recording how the version was obtained at least lets a later examiner distinguish "we checked and got stale data" from "we never checked."

Core for the fact of how evidence was obtained. The revalidation mechanism that catches silent version drift lives outside the record, and Principle 7 covers it.

Principle 4: Relationships Need Two Clocks

If you ever want to reconstruct what the system could have known at a past moment, every relationship in the ledger needs two timestamps, not one. This is standard bitemporal modeling, and Giulio D'Erme named exactly why it is not optional here.

Valid time is when a fact was true in the world. Transaction time is when your system asserted or learned the relationship. If a supersession edge carries only a single date, replaying last March will show March's decision annotated with August's supersessions, and the decision-maker will look like they ignored a policy that did not yet exist. You will have judged a past decision using knowledge that arrived in the future, which is the precise thing a reasoning ledger exists to prevent.

So a supersession or correction relationship carries both valid_time (when the new state became true) and asserted_at (when the system recorded the edge). Reconstruction filters on asserted_at to see only what was knowable then.

Core for any ledger whose purpose includes reconstructing historical decision context. If you genuinely only ever query current state, you can defer this, but that is a smaller ambition than most of these systems have.

Principle 5: Preserve What Lost, Not Just What Won

A ledger that records only the evidence supporting the final decision is a post-hoc justification engine wearing an audit trail. You can reconstruct why the decision looked reasonable, and you have quietly lost what competed with it, what failed a threshold, and what stayed unresolved.

GnomeMan4201 made this case from the investigation side, and it reframed the record for me. An immutable ledger can preserve history perfectly and still preserve a biased history if the losing evidence never gets written. The distinction between "we chose A because of X" and "we chose A because of X, rejected B because of Y, and could not resolve Z" is enormous when someone later asks whether the decision was defensible given what was actually known.

The fields this implies: alternatives_considered with a rejection_reason for each, disconfirmed_by for evidence that actively cut against the chosen path, and unknowns or scope_limitations for what the system could not resolve at decision time.

A scoping note, in answer to Kartik N V J K, who asked whether to capture rejected branches: capture the alternatives that were explicit parts of the decision process, not an exhaustive reconstruction of every path the model internally considered. If the agent evaluated three tools and rejected two on policy grounds, those rejections are observable decision evidence and belong in the record. The model's private deliberation does not. Observable reasoning is architecture; private reasoning belongs to the model.

Optional, escalating to Core with stakes. For a low-consequence decision, surviving evidence may be enough. For anything a human will later audit, defend, or be held accountable for, treat these as required. The higher the stakes, the more the losing evidence matters.

Principle 6: The Trigger Is a First-Class Field

pm25coder offered the most immediately practical field in the thread, from running a live decision ledger: the thing people actually read first, months later, is not the outcome. It is what provoked the decision. A timestamped complaint, an incident, a threshold breach, a human request. When every record carries its trigger, "why did we change this" becomes a search rather than an archaeology project, and the audit trail starts writing itself.

It is easy to bury the trigger inside an evidence list. Do not. Promote it to its own field, because it is the field that makes the record findable by the question a future reader will actually bring to it.

Core. Small field, disproportionate value.

Principle 7: Some Things Belong Outside the Record

Two mechanisms the thread kept reaching for are real and necessary, and they do not go in the ledger entry. Naming them keeps the record honest about what it is.

The first is revalidation. A ledger cannot observe a change in the outside world that never entered the system, so something outside the ledger has to periodically re-fetch referenced authorities and emit a fresh observation. pm25coder described this as a periodic "still current" or "stale" marker, which is a clean way to put it. The important framing: the revalidation job runs outside the ledger, and its result becomes a new event the ledger preserves. The ledger never claims continuous authority between checks, only that authority was observed at particular moments.

The second is retrieval. Giulio D'Erme and arun rajkumar converged on the point that a ledger gets read at exactly one moment, when someone is about to change the thing the reasoning was about, and that nobody goes looking for a constraint they have never hit. A well-structured record that is never surfaced is not much better than no record. The fix is to make the decision history an obligation on retrieval rather than an obligation on the reader: when a query surfaces the artifact a decision governed, the decision rides along, asked for or not.

That is what I have started calling separate custody, one interface. The ledger stays independently governed, so it cannot be edited in the same operation that changes what it witnesses. But the retrieval layer reunites the artifact and its decision history when the relationship becomes relevant, so no one has to know the ledger exists to benefit from it. Both properties matter, and they pull in opposite directions, which is exactly why they belong to different layers.

Core as principles, external as mechanisms. Neither is a field in the record.

A Worked Record

Applying the core principles to the baseline, a fuller record looks closer to this. The optional fields from Principle 5 are included and marked, since this is the kind of consequential decision where they earn their place.

reasoning_ledger:
  decision_id: dep-2026-03-14-0922
  decision: "Approve deployment"
  decided_at: 2026-03-14T09:22:00Z

  trigger:                                 # Principle 6
    type: incident
    ref: INC-2291
    observed_at: 2026-03-14T08:55:00Z

  evidence:
    - artifact: ADR-014
      authority: architecture-review
      version: 3
      obtained:                            # Principle 3
        source: adr-service
        method: re-derived
        retrieved_at: 2026-03-14T09:21:40Z
    - artifact: security-policy
      authority: security-team
      version: 7
      obtained:
        source: policy-cache
        method: cached
        retrieved_at: 2026-03-14T09:21:41Z
        cache_age_seconds: 240

  policy_evaluated:                        # Principle 1 (reports, does not rule)
    - check: dirty-tree-guard
      result: pass

  alternatives_considered:                 # Principle 5 (optional, stakes-dependent)
    - option: "Defer to next window"
      rejection_reason: "Incident severity exceeded defer threshold"
  disconfirmed_by: []
  unknowns:
    - "Downstream cache warm state not verified"

  relationships:                           # Principle 4 (two clocks)
    - type: supersedes
      target: dep-2026-02-02-1130
      valid_time: 2026-03-14T09:22:00Z
      asserted_at: 2026-03-14T09:22:00Z

  approvals:
    - release-manager
  outcome: approved

Field Reference

For quick use, here is the same thing as a reference, tagged.

Core fields. decision_id, decision, decided_at, trigger, evidence (with per-item authority, version, and an obtained block recording source, method, and retrieval time), outcome, and, for any relationship, both valid_time and asserted_at.

Optional fields, escalating to core with stakes. alternatives_considered with rejection_reason, disconfirmed_by, unknowns, scope_limitations.

Optional, context-dependent. confidence assessments, tools used, and policy_evaluated results where a boundary check ran. Useful, but not every decision needs them, and an empty one is worse than an absent one.

Not fields at all. Enforcement decisions, revalidation jobs, and integrity guarantees. These are mechanisms that surround the ledger, not contents of the record.

The Honest Limit

It is worth ending where the design genuinely runs out, because pretending otherwise is how ledgers get oversold.

A perfect record can tell you exactly what the system knew and did. It cannot retroactively give the system knowledge it never acquired. If the world changed and no observation of that change ever crossed your boundary, the ledger will contain a flawless, self-consistent account of a decision that was already wrong. Revalidation narrows that gap. It does not close it. Auditability is a property of what was observed, not a guarantee that everything relevant was.

That is not a reason to skip the record. It is a reason to be precise about what the record proves. It witnesses observation, not omniscience.

Looking Ahead

This piece is about what a record should contain and the principles that decide it. It has deliberately said almost nothing about whether the record can be trusted not to have been altered after the fact. That is a separate problem with its own answer, Write-Side Custody, and it is where Part 5 goes next. Designing the record and guaranteeing its integrity are different jobs, and keeping them apart is itself one of the design principles.

With thanks to the commenters whose contributions shaped this: GnomeMan4201 on disconfirming evidence, pm25coder on the trigger field and authority-fetch-as-event, Giulio D'Erme on two clocks and retrieval as an obligation, Self-Correcting Systems on provenance of the version, arun rajkumar on where the record lives, Tae Kim on evidence chains under audit, and Kartik N V J K on rejected branches. The record is better for the argument.

Your Memory API Is Lying to Your Agent

Ken W Alger — Thu, 20 Aug 2026 22:33:17 +0000

The memory store may know the truth. The interface may be throwing it away.

This piece grew out of a conversation on Edward Izgorodin's post Agent Memory: Everything It Remembers Has the Same Authority, and That Is the Bug. Several of the sharpest points below have names attached, and I have tried to attach them.

Imagine an AI agent asks its memory system a straightforward question:

What database does the production application use?

The memory API returns:

[
  {"content": "The production database is PostgreSQL.", "score": 0.94},
  {"content": "The production database is MongoDB.", "score": 0.91}
]

Retrieval worked. It found two highly relevant memories, scored them, ranked them, and returned them. The agent picks PostgreSQL.

The production application migrated to MongoDB four months ago.

Nothing failed in retrieval. The PostgreSQL record may genuinely be more semantically similar to the query. But semantic relevance was never the question the agent needed answered. The store knew more than it returned: PostgreSQL governed from January 2025 until April 2026, when MongoDB superseded it under a newer architecture decision. Somewhere between storage and the agent, that relationship disappeared.

The API returned the records and threw away the relationship between them. That is a very different kind of memory failure, and it is the one this piece is about.

The Storage Problem Is Mostly Solved

Before going further, it is worth being honest about what is actually new here, because part of this problem was solved before agents existed.

Separating when a fact was true from when the system learned it is bitemporal modeling, standardized in SQL:2011 as application-time and system-versioned tables. Edward raised this in the thread, and he is right that the database world has handled "this was true then, this is true now" for over a decade. A well-built store can close a fact's validity window instead of overwriting it, and the past stays explicable.

So the interesting problem is not storage. If your store still deletes on update, fix that first, and the literature is waiting for you. The problem this piece is about starts one layer up: even when the store preserves all of it, the retrieval interface usually hands the agent a flat ranked list and throws the structure away. The store solved the problem. The API un-solves it on the way out.

A Ranked List Has Nowhere to Put an Edge

That phrase is Edward's, from the thread, and it may be the sentence that breaks the whole abstraction. Once you sit with it, the rest follows.

Most AI memory interfaces inherited a familiar retrieval shape: give the system a query, get back a ranked list of relevant things. There may be metadata attached, a timestamp, a document id, a source, a confidence value. The fundamental abstraction stays the same. Memory is a bag of items, and retrieval returns the best-matching items.

That works well when the problem is finding things. Agentic systems increasingly need memory to do something harder: represent what the system currently knows, what it previously knew, where that knowledge came from, whether it still governs, and how apparently contradictory records relate. A ranked list is a poor representation of that world, because the relationships between records are part of the knowledge, and a list has nowhere to put them.

Consider two records: customer refunds require manager approval, and customer refunds under $100 do not. Maybe the second is a correction, because the first was entered wrong. Maybe it superseded the first, because policy changed. Maybe both are true in different jurisdictions and the first simply no longer governs this transaction. Those are not variations of one operation. They make different claims about history.

At the storage layer, all three can look like an update. At the audit and retrieval layers, they are fundamentally different events.

"No Longer True" Is Not "Never True," and Neither Is "No Longer Governs"

CRUD trained us to think in one verb, UPDATE, but durable memory needs at least three, and the third is the one that gets missed.

Supersession says the world changed. Policy A was true, Policy B is true now, and A is not wrong, it is closed. Correction says our record was wrong, including during the window an agent may have relied on it, so A was never true. Invalidation is the one worth slowing down for, because it is not a truth claim at all. It is an authority claim. A record can be perfectly true and no longer govern.

That distinction is the load-bearing one. A store that collapses these into a single value change can still answer "what is true now" cleanly, and will quietly fail the moment anyone asks "why did the agent approve that transaction on March 17." The answer to that question may depend on a record that is closed, or corrected, or stripped of authority, and that store no longer knows which.

Availability Is Not Usage, Even for a Schema

Here is the part that should make anyone building this check their own system before writing another feature.

Giulio D'Erme read the original thread, then went and counted his own corpus: zero of 152 memos in his memory store, and zero of 59 documents in his docs, declared a validity window or a supersession edge. The engine could read those keys. Nothing that wrote memories ever wrote them. As he put it, availability is not usage, and it applies to schema as much as to tools.

This is the failure mode hiding behind every rich schema. You can ship the read path, document the fields, and watch a live API serve a dead feature, because the thing that writes memories, a prompt or a template or another agent, was never taught the keys. A supersession column that nothing populates is not preservation. It is a column.

Tae Kim described the same shape from production trade data: the same company surfacing as different nodes depending on whether you asked before or after an acquisition, with the store silently picking one. Stamping the connections with time ranges and returning both versions helped. The part that bit later was that the agent's choice between them still vanished without a trace, which is the next problem.

Relevance Is Not Authority

The PostgreSQL example exposes the assumption underneath ranked retrieval. A similarity score answers, roughly, "how relevant is this record to the query." It does not answer "which record currently governs." Those correlate, but they are not the same. PostgreSQL might score 0.94 because it contains the exact terminology in the query, while MongoDB scores 0.91 because the migration decision is phrased differently. Retrieval did its job. The agent still gets the wrong answer, because 0.94 > 0.91 quietly became conflict resolution, and semantic similarity never established anything about authority.

This is why I have come to think of Memory as Infrastructure rather than memory as a database feature. Once memory participates in consequential decisions, retrieval quality is only one property of the subsystem. Provenance, authority, lifecycle, temporal validity, and correction semantics matter too. The closest memory is not necessarily the memory that governs.

Contradiction Is Information

Memory systems often treat conflicting records as a retrieval-quality problem: delete the older one, rank the newer one higher, filter one out with metadata. Sometimes that is right. Sometimes the contradiction is the most important thing memory knows.

Consider a record from Procurement saying Supplier X is approved for regulated workloads, and one from Security saying Supplier X is prohibited. Both may be inside their validity windows. No supersession may exist. The correct response is not to silently decide which wins. It is to report that the records conflict, where each came from, which authority issued each, and that resolution is required.

If the store knows the conflict exists but the API returns two ordinary ranked hits, the disagreement disappears at exactly the moment it mattered most.

The Response Type Is Part of the Architecture

This is why the fix is harder than adding a metadata column. If memory contains relationships, the response type has to be able to carry relationships. A richer interface might conceptually return something like:

{
  "records": [
    {"id": "A", "content": "Production uses PostgreSQL."},
    {"id": "B", "content": "Production uses MongoDB."}
  ],
  "relationships": [
    {
      "type": "supersession",
      "from": "A",
      "to": "B",
      "effective_at": "2026-04-15T00:00:00Z"
    }
  ]
}

The precise schema is not the point, and I am not proposing that JSON as a standard. The conceptual change is that the response is no longer a list of memories. It is a representation of a knowledge state, one that can carry contradiction, supersession, correction, invalidation, provenance, and authority as first-class content. Once those relationships affect agent behavior, they cannot stay trapped in the storage layer.

Two honest problems come with that, and both surfaced in the thread and then got worse the more Edward and I pushed on them.

The first is budget, and it turns out to be deeper than allocation. A ranked list is impoverished, but it is cheap, and top_k is a clean way to decide what to drop. The moment a response carries facts, relationships, authority, provenance, and prior decisions together, the problem stops being ranking and becomes allocating a finite context budget across different kinds of knowledge. A lower-ranked authority edge may matter more than the next highly relevant fact, and dropping a supersession relationship can change the meaning of the records that survive.

The tempting fix is to select the edges after ranking, as a post-filter on whatever top_k returned. Edward's counter is the part that reshaped my thinking: to know whether a supersession edge is worth carrying, you already have to be holding the record it supersedes. Edge hydration therefore cannot be a post-filter. It has to influence which candidates are considered in the first place, which means the allocation happens before ranking rather than after it. That is a far deeper change to a retrieval stack than adding a field to a response, and it is the point at which "improve the store" stops being the fix.

The second is addressing, and it needs to be more precise than "give the conflict an identity." My first instinct was to key the disagreement on the pair, A conflicts with B. Edward's refinement is better: pairs are unstable, because the moment a third record arrives, "A conflicts with B" is no longer the same object, and yesterday's decision now points at a conflict that no longer exists in that shape. Key on the subject the records argue about instead, the question, not the pair, and the decision stays addressable however many records pile up under it over time.

What Did the Agent Do Last Time?

That second problem points at a relationship that matters once agents repeatedly hit the same knowledge. Suppose yesterday's agent encountered records A and B in conflict, determined that B governed because Security had authority over regulated workloads, and acted on B. Today another agent hits the same conflict. If the system stored only A and B, today's agent resolves it from scratch. If yesterday's decision lives only in an audit log somewhere else, it exists but is unavailable at the moment it could prevent a repeat.

This is where a Reasoning Ledger becomes operationally interesting, and where I want to hold a line rather than blur one. I still think durable memory and the decision record deserve different custody. Knowledge can be superseded; a decision record cannot, because it has to keep saying what was believed at the time even after the belief is retracted. That separation belongs at the storage layer.

It should not survive into retrieval. Mike Czerwinski put the risk plainly in the thread: if the agent's choice between conflicting records is not logged, silent resolution just relocates from the store to the inference step, the same bug at a harder-to-find address, because now the store looks honest. Tae Kim started writing those choices back as events only because a client asked about a strange output and there was nothing to point at. Audit pressure, not architecture taste, is usually what makes the field real.

So the shape I would argue for is not memory + ledger presented as two things. It is separate systems of record behind one interface that can return facts, relationships, authority, and relevant prior decisions together. Separate custody, one interface, is the shortest way I have found to say it.

Different subsystems may have very different storage requirements, retention policies, and security boundaries. The mistake is assuming those implementation boundaries must decide what the agent is allowed to know at retrieval time. Storage boundaries do not have to be retrieval boundaries.

The API Is Making Claims

Every interface decides what survives abstraction. A memory API that returns only content and similarity scores is implicitly telling the agent that records are independent items and ranking is the only meaningful relationship among them. That was a reasonable claim when memory meant fetching passages to stuff into a prompt. It becomes a dangerous one when memory carries policy, organizational decisions, historical state, authority, and evidence for autonomous agents.

Here is what can vanish when a rich memory system is flattened into a ranked list:

Store knows	API returns
B superseded A	A and B
A was corrected by B	A and B
A remains true but no longer governs	A and B
A contradicts B	A and B
A and B share the same provenance	A and B
B governed the previous decision	A and B
A's authority expired	A and B

From the API's perspective, nothing is wrong. From the agent's perspective, almost everything important is gone.

We have spent enormous effort improving retrieval: better embeddings, hybrid search, rerankers, metadata filters, graph retrieval, larger context windows. All of it helps systems find relevant information. Finding the right records and understanding what they mean in relation to one another are different problems, and agentic systems are pushing memory hard toward the second. If the store preserves that structure but the interface discards it, improving the store will not help. The API has become the lossy boundary.

A memory API that knows A was superseded by B but hands the agent [A: 0.94, B: 0.91] has not merely dropped some metadata.

It has changed the meaning of the memory.

The thread that produced this piece has already moved the problem past where I started it. "A ranked list has nowhere to put an edge" was the right first cut, and it is a statement about the response shape. The sharper version, the one I am chasing now, is that some edges need durable identities, and something has to decide which edges are worth hydrating, before ranking rather than after. That is no longer a claim about the shape of the response. It is a claim about the shape of retrieval itself. Which is a longer conversation, and, I suspect, the next one.

With thanks to Edward Izgorodin, whose post started this and whose "nowhere to put an edge" framing anchors it, and to Giulio D'Erme, Tae Kim, and Mike Czerwinski, whose thread contributions are cited above. Different directions, same wall.

The Reasoning Ledger: Remembering Decisions, Not Just Data

Ken W Alger — Thu, 20 Aug 2026 14:03:00 +0000

Part 4 of the Building the AI Memory Stack series

After finishing the previous article, I looked at the repository a little differently. The specifications were still there. The Architecture Decision Records were still there. The glossary entries were still there. The project's durable memory had done exactly what it was supposed to do: preserve the knowledge that deserved to survive.

But something was missing. I could see what existed, but I couldn't always see why it existed.

Memory tells you what. Reasoning tells you why.

That distinction turns out to matter.

Durable Memory Isn't the Whole Story

In the previous article, I argued that Durable Memory decides what knowledge deserves to outlive the task that created it.

That remains true. But imagine opening an Architecture Decision Record six months later and asking:

Why was this decision made?

The document gives you the conclusion, but it may not give you the path that produced it. Perhaps the decision came from competing specifications, several tool invocations, human review, rejected alternatives, or a policy constraint that no longer exists.

The final artifact survives. The reasoning process often does not.

Another Layer in the Stack

Layer	Primary Question	Preserves
Reasoning Ledger	Why did this happen?	Decisions
Durable Memory	What should survive?	Knowledge
Active Working Memory	What matters now?	Working set
Context Window	What can the model see?	Current tokens

Software Already Solved Part of This

Git repositories preserve more than source code. They preserve commit history, pull requests, code reviews, issues, and discussion. Together they explain how software evolved.

Imagine if Git only stored the latest version of every file. The software would still exist, but understanding it would become dramatically harder.

Git doesn't exist because developers forget what their code looks like. It exists because developers eventually ask:

Why did we change this?

Agentic systems deserve the same architectural capability.

The Missing Layer

Most AI systems optimize retrieval, but far fewer preserve the observable decision process surrounding an inference. If someone asks months later:

Why did the system recommend this?

can we answer?

If the only answer is "because the model said so," then the system hasn't preserved enough information to be trustworthy. We've preserved knowledge but lost understanding.

The Reasoning Ledger

The Sovereign Systems Specification calls this architectural layer the Reasoning Ledger.

It deliberately avoids recording private chain-of-thought.

It records the observable architecture surrounding a decision.

A ledger may capture:

Evidence consulted
Tool invocations
Policy evaluations
Human approvals
Timestamps
Confidence assessments
References to durable artifacts
Links to Forensic Receipts

In practice, a single record might look like this:

reasoning_ledger:
  decision: "Approve deployment"
  timestamp: 2026-03-14T09:22:00Z
  evidence:
    - artifact: ADR-014
      authority: architecture-review
      version: 3
    - artifact: production-health-metrics
      observed_at: 2026-03-14T09:20:00Z
    - artifact: security-policy
      authority: security-team
      version: 7
  tools:
    - GitHub
    - CI pipeline
  approvals:
    - release manager
  outcome: approved

Notice that the ledger does not merely record that a security policy was consulted. It can preserve which policy, which version, and which authority governed the decision at that moment. That distinction matters because evidence can remain perfectly retrievable long after the world that made it authoritative has changed.

The Reasoning Ledger is therefore a historical record, not a promise of continuing authority. It tells us what governed the decision then. Determining whether the same evidence still governs a future decision belongs elsewhere in the architecture.

The goal is not to reconstruct what happened inside the model. It is to preserve the externally observable evidence, authorities, policies, tools, approvals, and outcomes that allow someone to examine the decision later.

Observable reasoning is architecture. Private reasoning belongs to the model.

Memory Preserves Knowledge. Reasoning Preserves Decisions.

Memory is fundamentally a write problem, while reasoning is fundamentally an accountability problem. Memory preserves knowledge. Reasoning preserves decisions.

Both are required for trustworthy AI systems.

Looking Ahead

A Reasoning Ledger explains the observable path that produced a decision.

But how do we know those records themselves have not been altered?

That is where Write-Side Custody begins, and where Part 5 will take us.