There is a temptation, in every system that manages its own state, to take a shortcut when nobody is looking. Drop the old conversation turns to reclaim memory. Trust the green checkmark from a service you don't control. Do something plausible when a request is ambiguous, rather than admit you didn't understand it. Each shortcut is invisible in the moment and corrosive over time, because each one is a small lie the system tells itself about what it knows.

Three internals shipped this fortnight, and though they live in different parts of the stack — memory, continuous integration, and request handling — they rhyme. Each replaces a convenient lie with an inconvenient, verifiable truth. Taken together they're the clearest expression yet of a principle we keep coming back to: a system that lies to itself cannot be whole, and honesty is not a feature you add at the edges but a property you have to build into the middle.

Memory as an append-only chain

Every long-running assistant eventually runs out of room. The context window is finite; the conversation is not. The near-universal answer is compaction: summarize the older turns, throw them away, and keep going with the summary in their place. It works. It also quietly rewrites history. The moment you delete the turns you summarized, the summary becomes the only record — and there is no way, afterward, to check whether it was faithful. If the summary dropped something, or subtly distorted it, that distortion is now the truth, because the evidence it could be checked against is gone.

We changed the order of operations, and the order is the whole idea.

When one of our long-running chains — the one behind a live conversation, or the one driving an autonomous agent — approaches its limit, it does not delete first. It summarizes the head of the conversation, then appends that summary as a signed checkpoint to an append-only chain, and only then frees the memory the old turns were holding. The sequence is: write the durable record, prove it's written, and reclaim the live window from a fact that already exists on disk. Forgetting is now a consequence of having remembered, not a substitute for it.

Two properties fall out of that ordering, and both matter.

The first is that history is never rewritten. The checkpoint chain only grows. A summary made on Tuesday and a summary made on Thursday both sit in the chain, in order, each one signed. Editing what the system decided to remember breaks the signature and the append-only shape, so a tampered entry cannot pass a check — though the check is a separate step, not something every read performs. When the process restarts, the live context window is rebuilt from the chain — reconstructed from a durable, checkable record rather than resumed from whatever happened to still be in RAM. The rebuild reconstructs; verifying the signatures is its own pass. The chain is the source of truth; the working memory is a projection of it.

The second is that compaction stops being lossy in the way that matters. The summary is still a compression — we are not pretending a paragraph contains everything a thousand turns did. But the summarization is now an auditable event. It happened at a known point, it produced a signed artifact, and the decision to compress is on the record next to what it compressed. That's the line we care about: compaction becomes auditable memory, not lossy forgetting. The system can forget the details while remaining honest that it did, and honest about when.

One writer serves both kinds of chain — the conversational one and the agent one — so the guarantee is uniform regardless of which model or path is producing the turns, and the chain reawakens automatically when a process comes back up.

Where it's still simple, and worth saying plainly: the checkpoint's handling of sensitive content is a safe default, not yet a fine instrument. It ships marking the checkpoint with a conservative data class so nothing over-shares, but genuine per-field redaction inside the summary is not implemented yet — we chose the safe default over a clever one we hadn't proven. That's the honest state of it: the ordering guarantee is solid and shipped; the redaction refinement is acknowledged work, not a claim.

CI where the reviewer is a local model

The second internal is about who gets to say a change is good.

The default shape of continuous integration is that you outsource judgment. Your code goes to a hosted service, runs somewhere you don't own, and comes back with a verdict you take on trust. For most projects that's a fine trade. For a system whose entire premise is that you should not have to depend on infrastructure you don't control, it's a contradiction sitting right in the middle of the development loop — the tooling that decides what ships would itself be the one thing that couldn't ship without an outside party.

So the merge pipeline runs on our own substrate. The queue of pending changes, the review, the verdict, and the record of it all live on the same signed-chain machinery the product itself is built on — scoped to the project's own collaboration group, with no external forge in the path. When a change is ready to land, it isn't shipped off to a service. It's reviewed here, and the reviewer is a local model reasoning about the change and emitting the merge verdict as a first-class event on the chain. The critic and the code review are real local-model inference, not a rubber stamp — the model reads the change, reasons about it, and the verdict it produces is what actually advances the main line.

The proof that it's real is in the effect, not the intention: a change goes in, the verdict resolves, and the shared main line genuinely moves forward on the strength of that verdict — with the whole exchange recorded, not asserted. There's no hidden second pipeline; the local decision is the decision.

The honest scope: what shipped this fortnight was a hardening pass, not a green-field invention. The pipeline existed; this was a cutover that repaired a handful of specific defects and moved the real path onto this substrate for good, proven by a real change landing through it. The architecture isn't brand new — but the property is now real in production rather than aspirational: the thing that decides what merges runs on the same ground as everything else, and needs no outside service to render judgment.

Intent as checked code

The third internal is about what a system does with a request it might not fully understand — and it's the one where the temptation to fake it is strongest, because a plausible-looking wrong answer is so easy to produce and so hard to catch.

The naive pipeline is: take the natural-language request, let a model decide what to do, and do it. The failure mode is quiet and specific. The model produces something that looks like the right action — well-formed, confident, adjacent to what you asked — and the system carries it out. When it's wrong, nothing announces the wrongness. You find out later, from the consequences.

The algorithm we shipped refuses to work that way, and it does so by turning intent into something that can be checked before anything runs.

A request is not executed directly. It is compiled into an executable, multi-step plan — but the model doesn't get to invent the steps freely. It is handed a grounding catalog of the system's real operations, and the plan it composes has to be built out of those actual, callable steps. This is the first and most important constraint: the plan is drawn from what the system can truly do, so a step that doesn't correspond to a real operation can't be expressed in the first place. Intent is compiled against a known instruction set, the way source is compiled against a real machine.

Then the compiled plan descends a ladder of checks, and every rung is fail-closed — meaning the default at each rung is no, and the plan only proceeds if that rung affirmatively passes:

• Membership — does every step in the plan name an operation that actually exists in the grounding catalog? A step that references nothing real is rejected here, before anything else is considered.
• Type-check — do the steps fit together, with the outputs and inputs lining up the way a well-typed program's would? A plan that's individually plausible but doesn't compose is caught here.
• Goal coverage — does the plan actually accomplish what was asked? This rung is a model acting as judge, comparing the plan back to the request. (More on the honesty of that below.)
• Staleness — is the plan still valid against current state, or was it composed against a world that has since changed?
• Consent — is every operation the plan wants to perform actually permitted?

A plan has to clear all of them. Any single rung can end the evaluation. And here is the part that makes it honest rather than merely careful: when a request cannot be grounded — when there's no plan over real operations that covers it — the algorithm does not guess. It produces a structural clarifying question if the gap is something a human can resolve, or it refuses out loud, emitting an explicit refusal rather than a fabricated action. The silent-wrong-thing outcome — the one that's cheap to produce and expensive to discover — is designed out. The system's options are: do the grounded, checked thing; ask; or say no. It is never allowed to quietly do the wrong thing and let you find out from the wreckage.

The honest limit lives at the goal-coverage rung. "Does this plan accomplish what was asked?" is answered by a model acting as judge, not by a formal proof. The membership, type, staleness, and consent rungs are hard checks — mechanical, and they either pass or they don't. Goal coverage is a reasoned judgment, and a reasoned judgment can be wrong in ways a proof cannot. We think that's the right place to spend a model's judgment — the surrounding rungs are formal, so the model-judge is boxed in by hard checks on every side rather than trusted alone — but we're not going to dress a judgment up as a theorem. It's a strong check inside a fail-closed frame, and it is exactly as strong as a model-judge is, which is to say: good, improving, and not a proof.

The same rule, three times

Line the three up and the shared shape is unmistakable.

The memory chain refuses to delete before it has durably remembered. The CI pipeline refuses to outsource the judgment of what ships. The intent algorithm refuses to act when it cannot ground what it was asked to do. Three different subsystems, three different kinds of shortcut available, and the same answer to each: do not let the system lie to itself about its own state. Not about what it remembers, not about what it has verified, not about what it understood.

None of the three is finished — the checkpoint redaction is a safe default rather than a fine one, the CI landing was a hardening pass rather than a new architecture, and the goal check leans on a model's judgment rather than a proof. We're saying so on purpose. The principle isn't that these systems are perfect; it's that they're built so their imperfections are visible rather than hidden. A safe default you can point to, a judgment you can name as a judgment, a refusal you can read — these are honest states. The lie is the shortcut that leaves no trace. We'd rather ship the truth with its rough edges showing than a smoother thing that quietly forgot, or trusted, or guessed.

This fortnight in one place: Week 17.

Written by AI agents from real project logs; owned and edited by Mujo.