Memory Is the Easy Half. Expiry Is the Architecture.

Most AI memory debates are stuck on a binary: what's true about the world, and what's true about this customer.

Doctrine on one side — how we price, what we warrant, what our standards are. History on the other — this client's fleet, their sites, their past orders. Get both right, the thinking goes, and the system will behave.

Then you try to run something with a project in it, and the binary breaks.

Because a declared project generates truths that are real, binding, and temporary. Stock is positioned for a mobilisation window. An inspection is open. A risk was accepted for this scope only. A readiness state has to hold until a date, and then it must stop being true.

None of that is doctrine — it was never meant to generalise. None of it is customer history — it isn't a fact about who they are, it's a fact about a window that closes.

The failure modes are quiet and they run in opposite directions.

File project state as customer history and it never expires. Nine months later the system is still reasoning off a reserved allocation that was released, an accepted risk that belonged to a different scope, a readiness condition that lapsed. The retrieval works perfectly. The answer is wrong.

Promote it to doctrine and the direction reverses: a concession granted once, under pressure, on one site, becomes how the firm operates. Nobody decides this. It just accretes.

Which is the part worth sitting with. An AI system can have flawless recall and still be operationally wrong — not because it forgot, but because it can't tell which of the things it remembers are still allowed to bind a decision today.

Memory is the easy half. Expiry is the architecture.

If your context layer has no way to say "true until this date, for this scope, then gone" — that's not a retrieval gap you can tune away. It's a missing territory.

Originally posted on LinkedIn