The Decision Lifecycle

There is a meeting most engineering teams will recognize. The same architecture argument, replayed once a quarter, with the same positions and a slightly different cast. Nobody can say precisely what was decided last time, or on what evidence, so the question gets reopened by default. The organization recorded the outcome (the system did, in fact, get sharded by region) but not the verdict: what was chosen over what, on what basis, and what would have to change to reopen it. The decision never became an object. There is nothing to point at, nothing to reinforce, nothing to supersede. So it gets relitigated by whoever happens to be in the room.

A staff engineer I'll call Marcus (name changed) once described his team's architecture-decision-record directory as a write-only graveyard. Decisions went in and were never touched again. A good number were quietly violated by the codebase within a year, and nobody could say which ones without reading the code. The records were durable. They just had no lifecycle. A decision you can write down but never challenge, reinforce, or retire is not a memory. It is a plaque.

Last week I argued that a decision is a different kind of memory than a fact: a commitment with a shape, not a claim about the world. This essay is about the consequence of that difference, which is that decisions age by a completely different mechanism than facts do, and a memory system that wants agents to act on commitments has to implement that mechanism, not just the storage.

Facts rot. Decisions are challenged.

A fact ages against the world. It was true, the world moved, and now it is stale. That is the failure I wrote about in the essay on time, and the defense is temporal: know when a fact was true, know when you learned it, notice when the world has moved past it.

A decision does not age that way, because a decision was never a claim about the world. It ages against evidence and challenge. A decision stands until something contests it: an outcome that contradicts it, a premise that got superseded, a better alternative that arrived, a deliberate act of retraction. Which means the age of a decision, by itself, tells you almost nothing. An old decision that has been reinforced every time it was tested can be the most trustworthy object in the entire store. A fresh one that has already been contradicted twice should be up for review. Time is the wrong axis. Challenge history is the right one.

That single observation drives everything a decision lifecycle needs.

Born with lineage

A decision enters the store linked to what produced it. The evidence it was derived from, the trace that generated it, the prior memories it stands on. In SmartMemory these are explicit edges written at creation time, not annotations someone hopes to add later. The reason is the question you will eventually need to ask: based on what? If a decision cannot answer that with a query, it is folklore, and folklore is exactly the Friday deploy freeze from last week: a commitment whose reasons are no longer on file.

Some decisions are also born waiting. A commitment can exist before it is in force: decided, pending an approval, pending a fact that has not arrived yet. Organizations live in this state constantly, and a memory system that can only represent "active" and "gone" cannot represent it at all. So a decision can be created pending, carrying the explicit requirements that block it, and it activates when those requirements resolve. Decided and in-force are different states, and conflating them is how agents act on commitments that were never actually cleared.

Challenge without deletion

Evidence does not stop arriving just because the verdict landed. The lifecycle has to absorb what comes next, and there are exactly two honest moves.

When new evidence agrees, the decision is reinforced, and the reinforcement is recorded as an event, not smeared into an updated score. When new evidence disagrees, the decision is contradicted, and here is the part most systems get wrong: contradiction does not delete. A contradicted decision keeps standing, wearing its contradiction where the next reader can see it. Deleting a commitment the first time evidence pushes back is as wrong as ignoring the evidence entirely. The first is amnesia, the second is dogma, and a real decision record needs to be capable of neither.

This matters because the challenge history is the trust signal. A decision reinforced five times and never contradicted has earned something. A decision contradicted three times that nobody has gotten around to superseding is a known problem the store is honestly representing. Flatten both into a current-state boolean and you have thrown away the difference between them, which was the only thing worth knowing.

One number cannot hold what you know

Most systems that track decision confidence at all track a single scalar, and the scalar has a failure mode worth naming precisely. A confidence of one-half can mean two entirely different things. It can mean we have almost no evidence either way. It can also mean we have a great deal of evidence and it disagrees with itself. Those states demand opposite responses. The first says go gather more. The second says stop and reconcile, because something in the world or the store is genuinely contested.

SmartMemory models decision confidence as bounds rather than a point. Belief is the committed floor (what the accumulated evidence actually supports). Plausibility is the ceiling (what the evidence fails to rule out). The gap between them is honest ignorance, and contestedness is exposed as its own signal instead of being laundered into a lower number. The evidence-fusion rule is chosen deliberately so that head-on conflict decays the decision toward uncertainty, never toward false certainty. When strong support and strong contradiction collide, the system's answer is "we do not know anymore," not a coin flip weighted by whichever evidence arrived last.

I will not pretend the math is casual reading, but the behavioral contract is simple to state: a heavily contested decision should look less settled, not differently settled. Any confidence scheme that cannot distinguish ignorance from contest will eventually hand an agent a contested commitment wearing a confident face.

Superseded, not overwritten

Eventually a decision is replaced. The replacement writes an explicit supersedes link to the old one and the old one is kept, status changed, history intact. This is the same discipline the rest of the memory store follows (facts supersede facts the same way), and for decisions it carries an extra obligation: the audit question. When something goes wrong, the question is never only "what is the current policy." It is "what was in force at the moment the agent acted." That is a bi-temporal question, and it is only answerable if superseded decisions survive with their dates.

And some endings are not replacements. A decision can be retracted (we were wrong to commit), completed (the commitment was discharged), failed, or abandoned. These are different endings with different meanings for anything derived from them, and a lifecycle that collapses them all into deletion is discarding exactly the history an agent needs to avoid recommitting to something that already failed.

The inverse question

The lifecycle machinery pays off hardest in one query that has nothing to do with any single decision.

When a fact is superseded, the fact is handled: linked, dated, retired. But the decisions derived from that fact are now standing on ground that moved. Last week I called these zombie decisions, and the only systematic defense is the inverse lookup: given this memory, which standing decisions have it in their lineage? Because decisions carry derived-from edges from birth, that is a graph query, not an investigation. Change a fact, sweep its dependents, flag the survivors for review. Without the edges, that sweep is impossible, and every fact update quietly strands an unknown number of commitments.

The same machinery surfaces conflicts between standing decisions themselves, ranked by how contested each one already is. Two active commitments that contradict each other are a fork in the agent's behavior waiting for a prompt-ordering accident to resolve. The store should find them first.

What to do if your decisions are write-only today

Give decisions a challenge history, not just a status. Reinforcements and contradictions as recorded events. The history is the trust signal.
Never delete on contradiction. Mark it, display it, let it accumulate. Amnesia and dogma are both bugs.
Track ignorance and contest separately. One scalar cannot distinguish "little evidence" from "contested evidence," and those demand opposite responses.
Supersede with links and keep the prior. "What was in force when the agent acted" must stay answerable forever.
Represent pending. Decided and in-force are different states. Conflating them clears commitments nobody actually cleared.
Build the inverse lookup. When a fact changes, you need every standing decision that depends on it, as a query. That requires lineage edges written at creation, because you cannot add provenance retroactively.

Next week closes the arc: why any of this machinery exists. Decisions are the object that turns a memory system from a description of the world into a participant in it, and that transition (from memory to agency) is where the expertise layer stops being a metaphor.

I'm building SmartMemory, the expertise layer for AI agents: provenance-tagged, bi-temporal, graph-backed memory that knows not just what's true, but what to do, and when it stopped being true.

Try it: pip install smartmemory (docs) · hosted beta (private): smartmemory.ai/signup