In a week that was mostly the messy middle of several big things, 2026-04-30 had one clean landing. Consent and approvals, per subject, reached its sign-off and shipped that day. We want to walk through what actually shipped, because the design has a property worth stealing: it makes consent a single, signed, per-subject fact rather than a scattering of ad-hoc permission checks.

What "per subject" means

Most permission systems are organized around the actor — the thing doing something. "Can this user do this action?" That's the question a typical access-control check answers, and it's a fine question. But consent is a subtly different idea, and this work takes the difference seriously.

Consent is organized around the subject — the thing being consented about. Whose data is this? Who is the person or entity whose permission is the one that matters here? When you grant a friend access to a slice of your memory, the subject is you and that slice — and the consent fact belongs to that subject's record, not floating loose in some global table. The work routes consent through the identity it concerns, so that each grant or revocation lands against the specific subject rather than a generic permission bucket.

The payoff is that "who has consented to what about me" becomes a question with one authoritative answer, located in one place — the subject's own record — instead of something you have to reconstruct by scanning every actor's permissions and inferring. Consent is a property of the subject, and the data model treats it that way.

One write API, one emit-site

Here's the part we find most quietly important, because it's the kind of thing that doesn't show up in a demo but determines whether the system stays honest over years.

Before this work, consent events could be written from more than one place in the code. A "consent granted" here, a "consent revoked" there — duplicate writers, each its own little path. That is a correctness time bomb. Every place that writes is a place the rules can drift: one path remembers to sign the event, another forgets; one writes the subject correctly, another fudges it; one enforces a valid state change, another skips it. Multiply by the number of places permission can change and you have a system where "what consents exist" depends on which code path happened to run.

The work collapsed that. It eliminated the duplicate writers, arriving at a single place where a consent event is written and a single public way to write one. Every grant and every revocation now goes through one door.

Why that's the load-bearing decision: when there is exactly one place consent can be written, there is exactly one place to enforce everything that must be true about a consent change. One place to sign it, so every consent event is cryptographically attributable and tamper-evident. One place to validate the state change, so you can't, say, revoke something that was never granted, or reactivate a consent that the rules say is dead. One place to route it to the correct subject. The single door isn't a tidiness preference — it's the only way to guarantee a rule always holds, because a rule enforced in one of three writing-places is a rule that doesn't hold.

Consent has a lifecycle, not just an on-off switch

A grant isn't binary forever. Consent gets given, suspended, reactivated, revoked — and a real system has to model those transitions explicitly, or it ends up with states it can't reason about. The same day's work pulled exactly this into the single write path: suspend, reactivate, and tier-defined all became consent events written through the one door.

So a consent isn't just present-or-absent. It can be suspended — paused without being destroyed, with the history of why intact — and later reactivated. It can have a tier defined, so "consented" isn't one undifferentiated grant but can carry the scope of what was agreed to. Putting all of these through the same door means the lifecycle is enforced as a real state machine, not as a scatter of booleans that can contradict each other. You can't suspend something that isn't active; you can't reactivate something that was revoked. The transitions are the rules, and they live in one place.

And because each transition is a signed event on the subject's record, the consent state isn't just a current value — it's an auditable history. You can answer not only "is this consented right now" but "when was it granted, was it ever suspended, who revoked it, when" — each step a tamper-evident fact, not a log line you have to trust.

Why this was the clean landing

We called it the week's clean landing, and we want to be precise, because the same week had several things that were emphatically not clean — restructures that broke imports fleet-wide, claims of done that hadn't earned it, a calling feature we refused to celebrate. Against that backdrop, the consent work is the one we can point at without a caveat: it reached sign-off, it was formally signed off as complete, and the whole set of milestones shipped on 2026-04-30. Verified, not asserted.

What made it land cleanly is, we think, exactly the discipline above. The design didn't add a feature so much as remove ambiguity — collapsing many emit-sites to one, scattering permission checks into a single per-subject signed record with an explicit lifecycle. Ambiguity is what makes a feature drag on, because every ambiguous path is a place a bug can hide until celebrate day. Take the ambiguity out first and the landing gets clean almost as a side effect.

That's the model worth stealing: consent is a per-subject, signed fact, written through exactly one door, with a real lifecycle. Not a permission flag you check in a dozen places and hope they agree.

Related: A River Is Whole and Still Has Banks · Recording a Call, With Consent You Can Take Back.

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