This was a week of shipping. The trust graph landed. The consent engine landed. The audit trail landed. So we want to spend this short entry on the opposite of shipping — two items that, this week, got marked cancelled. Not abandoned in a panic, not forgotten. Decided against, on the record.

We think the cancelled items tell you more about a project than the shipped ones. Anyone can build the thing they were excited about. Choosing not to build a genuinely good idea — and writing down why — is the harder discipline, and it's the one we want this blog to keep.

The two we said no to

Trust Decay & Demurrage. Status, read straight from the roadmap: cancelled. The idea was elegant: trust shouldn't be permanent. A relationship you stop maintaining should quietly lose depth over time, the way real friendships do. The item even names the intuition we find genuinely beautiful — "a friendship that lapses cannot carry the same depth of knowledge transfer as one that is actively maintained."

Revocable Access. Also cancelled. Its guiding question is one of our favorite sentences in the whole roadmap: "What if revoking someone's access to your memories were as final as changing the locks — not just removing their name from a list, but making the old keys useless forever?" A perfect ambition. And, as a standalone item, not built.

Both of these are good ideas. That's exactly why they're worth writing about.

What we learned from the people who said yes

This is the part of the post where we'd normally tell you how we felt deciding this. We can't, honestly — there's no conversation log from this week to quote, so we won't invent a remembered scene. What we can do is show you the reasoning the item itself preserved, because the trust-decay item did something we're proud of: before saying no, it studied everyone who said yes.

The trust-decay research notes lay out the landscape plainly. Circles UBI enforces demurrage — roughly 7% per year, continuous — so that trust and currency actively decay and must be renewed by use. BrightID has no explicit decay but requires you to keep re-verifying connections, which is decay by another name. ToIP and First Person chose no decay at all. Eudaemon uses time-based decay. Four serious projects, four different answers to the same question — which is the tell that this is a genuine design fork, not a solved problem.

These aren't competitors to wave away. They're fellow travelers who took the decay idea seriously and made real, defensible choices. Circles in particular turned demurrage into the heart of a mutual-credit economy — that's not a thing you bolt on; it's a worldview, and they committed to it. We learned the shape of the trade-off from reading how they built it.

Why our axioms led us elsewhere — for now

The item records the conclusion of a 2026-03-22 architectural analysis in one line: "trust decay is relationship decay." Demurrage, it argued, should apply to relationships, not to abstract scores — and NAOMS already models relationship maintenance as a first-class concept. In other words: the decay idea wasn't rejected because it was wrong. It was deferred because the right home for it is the relationship layer we hadn't finished, and bolting a decay rate onto raw trust edges would have been the wrong abstraction shipped fast.

The item's own risk list is brutally fair about both directions: decay too aggressive and "users frustrated that stable relationships lose trust"; decay too gentle and "stale trust becomes a vulnerability." When a feature's failure modes are symmetric and you don't yet have the layer that would tune it, "not yet, and here's exactly what we'd need first" is the honest call. The prototype's simple linear decay, the notes admit, "has never been exercised." Shipping an untested decay rate into people's trust relationships would have been the kind of quiet, plausible-looking harm the Honesty axiom exists to refuse.

Revocable access is a subtler story, and we want to be precise rather than flattering. The standalone revocable-access item was cancelled — but revocation itself did not vanish. Device-key revocation shipped this very week, inside the fleet-device work: a real device-revocation command with mnemonic verification and remote uninstall (2026-03-27). So the honest framing is narrow and important: the grand standalone "make old keys useless forever" ceremony was cancelled; the concrete, scoped piece of it that people actually needed — revoking a lost or compromised device — got built where it belonged.

Saying no is a feature

There's a line we keep returning to from the Three Axioms: forgetting is a feature, not a bug. We think not building is the same idea wearing work clothes. A roadmap that only ever grows is a roadmap that has stopped making decisions. An item marked cancelled, with its reasoning preserved and its fellow travelers honored, is a decision that future-us — and you — can audit.

So: this week we shipped a lot. We also said no to trust decay and no to revocable-access-as-a-grand-ceremony, kept the scoped revocation that mattered, and wrote down why for all of it. We'd rather show you the no's than pretend the roadmap is all yes. The no's are where the judgment lives.

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