What the Code Said

Every company knows the gap between the status update and the truth. The update is assembled from memory, from optimism, and from the very human wish not to be the person who says the hard thing in the meeting. It is rarely a lie. It is just consistently, directionally kind to itself.

So this quarter we tried something uncomfortable: we graded ourselves by reading the code instead of asking ourselves how it was going. Then we published what it said, including the parts we did not enjoy.

The method: survey the artifact, not the memory

The rule was simple. No status could be based on what anyone believed to be true. Every claim had to be traceable to a file and a line in the actual repositories — the shipped code, not the roadmap, not the deck, not the memory of the engineer who wrote it.

We ran a read-only survey across every repository we own and forced each project into one of four buckets: live (running in production), dev only, built but disabled, or planned. That taxonomy is doing quiet, brutal work. “We have consent receipts” is a sentence that can hide any of the four. Forcing the distinction is most of the value.

What it said

The shipping core came back green, and honestly that was a relief. The consent protocol — signed tokens, fail-closed revocation, the encrypted vault — is mature, live, and well covered by tests. The professional-license verification that our directory depends on is live and refuses to run in production without a real regulatory source configured. The app people actually use is live and genuinely broad.

Most of our best work came back amber, for one consistent reason: it is built and not yet turned on. The per-user agent platform, the tamper-evident audit chain, the vault-held keys, the agent discovery card — all real, all tested, all behind a flag that says off. That is our deliberate practice (we ship dark on purpose), but it would have been very easy to describe that work in a way that implied it was live. The audit made that impossible, which is exactly what an audit is for.

And some things came back red. The one we will state plainly, because it is already public on our own posture page: we hold nosecurity certification. Not FedRAMP, not an authorization to operate, not a completed independent assessment. We have built controls to that bar and we say “in pursuit” everywhere in our code and our copy, because that is the honest word. Certification requires an external assessor and a sponsoring agency, and we have neither yet. Anyone who tells you their startup is “FedRAMP compliant” without an authorization is describing an ambition in the grammar of an achievement.

What we are not publishing, and why

Here is where radical transparency has to meet a second principle, and we would rather explain the tension than pretend it does not exist.

The audit also found ordinary security debt — the dependency backlog every real codebase carries, with the specifics of which components, which versions, and which are not yet patched. We are not publishing those specifics, and we do not think we should. A precise public list of what is currently unpatched in a system that holds personal information is not transparency. It is a map, drawn for the exact person you least want holding it.

So the line we draw is this: we will tell you, publicly and without softening, about the shapeof our weaknesses — that the debt exists, that we are resourcing it, that it is a live priority with a named owner. We will not publish the coordinates. That is not an exception to honesty. It is what honesty looks like when other people’s information is the thing at stake. When the debt is closed, we will say so, and that statement will be worth something precisely because we did not narrate the vulnerability while it was open.

Why grade yourself at all

The cynical read is that this is a performance of humility, and the cynical read is worth taking seriously, because plenty of published “transparency” is exactly that.

The practical answer is that we are building for buyers who audit for a living. A federal assessor, a bank’s risk team, a regulator — these are people whose entire profession is detecting the gap between what a system claims and what it does. They find it on day one, every time. Against that audience, the only durable strategy is to have no gap: to run the audit on yourself first, publish the result, and let the assessor discover that your self-assessment was already harsher than theirs.

The deeper answer is that a company grades itself the way it grades everything else. The habits you use on your own status report are the habits you will use on a customer’s data. If we are willing to round “built” up to “live” in a board deck, we will eventually be willing to round “probably fine” up to “secure” in an incident. The honesty is not a separate virtue from the engineering. It is the same muscle.

The number that would matter

A self-audit is cheap to publish once and worthless to publish twice if nothing moved in between. So the real test is not this post — it is the next one.

We have a list of ambers that are supposed to become greens: switches to flip, a certification path to actually start, debt to close. Ask us next quarter how many of them moved, and whether we told you plainly about the ones that did not. That number is the only proof that any of this was more than a well-written paragraph.

Our current posture is public at /one/compliance and /one/certifications— including everything we have not earned.