The owed disclosure

A questionnaire arrives from somebody outside the system, and two bad instincts arrive with it. The first is to say as little as can be said without sounding evasive, on the theory that every disclosed fact is a hostage. The second is to answer generously, sending schemas and field names and diagrams of the whole apparatus, on the theory that openness is a virtue and more of it is more virtuous. Both instincts answer a question nobody asked. The person outside is not trying to learn what the system is made of. They are trying to learn what they can build on, and whether the sentence they are about to repeat to their own board will still be true a year from now.

What a system owes the people outside it is an honest account of its own claims. Which parts are guarantees and which are merely the current shape. Which constraints are checked and which are only requested. What the claim excludes, said by the claimant rather than discovered later by the reader. That document is harder to write than either the evasion or the data dictionary, and it is the only one of the three that survives contact with a second year.

A guarantee and a shape are not the same sentence

Start with the distinction that does the most work, because getting it wrong is the most expensive mistake in the set and the least visible while you are making it. A guarantee is a promise about what will remain true. Identity is stable. A constraint is enforced. An export is complete. A shape is how the thing currently happens to be arranged: the object model, the schema, the storage layout, the names of the fields. Both are facts about the system. Only one of them is a promise. The test that separates them fits inside a single question you can ask of every sentence before you publish it, which is whether the person reading it would have to change their own work if the fact stopped being true. If the answer is no, the sentence is machinery, and publishing machinery converts an implementation choice into a contract nobody signed.

Hyrum Wright’s observation, folded into Google’s engineering canon as Hyrum’s law, is the mature form of this. With a sufficient number of users of an interface, all observable behaviors of your system will be depended on by somebody, whatever the written contract promises. The contract is not the boundary. Observability is the boundary. Anything a counterparty can see, somebody eventually builds on, and the moment they do, your freedom to change it is gone whether or not you ever agreed to keep it.

Two engineering cultures have paid this bill in public. The Linux kernel treats it as an obligation, holding that a change which breaks a working user program is a defect in the kernel rather than in the program, a position Linus Torvalds has restated for three decades in language nobody misremembers. Windows treats it as an operating cost, shipping application-specific compatibility shims so that programs relying on behavior no document ever promised keep running across releases. Both responses are honorable and neither is free, and both are the price of observable shape becoming load-bearing without anyone deciding that it would. Disclosure is where that decision gets made deliberately, once, by you.

Checked, or requested

For every constraint a system names, there is a second fact that matters at least as much as the constraint itself, which is whether anything checks it. A rule enforced by a gate that runs on every path is one kind of object. A rule enforced by a runbook step nothing blocks is another. A rule with a name, a rationale, and no mechanism at all is a third, and it is the one most likely to be written in the same confident voice as the first.

The web has run this experiment twice, in public, with opposite results. The Robots Exclusion Protocol has been in use since 1994 and was finally standardized as RFC 9309 in 2022, and it is advisory by construction: a robots file states rules a crawler is asked to follow, and nothing in the protocol enforces any of them. Everyone in the field knows this, the ecosystem functions anyway, and the reason it functions is that the request has always been honest about being a request. Do Not Track ran the other way. A browser header announced a preference, nothing checked it, the header looked from the outside exactly like a control, and the distance between the look and the fact was wide enough that the W3C closed its Tracking Protection Working Group in 2019 without the Do Not Track header ever becoming an enforced standard. Two nearly identical architectures, two opposite reputations. The variable was never the enforcement. It was the candor about the enforcement.

Our own version of that candor is a governance document in the database canon that labels every principle it states with the enforcement that principle actually has: a guard runnable locally, a guard that needs a live database, a runbook step nothing blocks, and a fourth label meaning the principle is stated and no mechanism exists at all. It goes further and carries a register of its own unenforced rules, ranked by priority, at the bottom of the file. That register is the reason to trust the rest of the document, and it earns that trust through exactly the property that makes it look worse. Saying requested where requested is the truth earns more than silence, because silence inside a disclosure never reads as neutral. It reads, correctly, as evasion.

An honest claim publishes its own exclusions

The strongest working example we have of this is a list that forbids our own marketing from using certain words. A privacy threat model in the platform documentation carries a section telling anyone writing copy what the product may not be called. Not zero knowledge. Not fully client-held confidentiality. Not local-only. Not universal end-to-end encryption. An architecture document alongside it carries a companion list of phrases to avoid in presentation copy, each entry a sentence that would flatter the system and is not true at the maturity the system has reached, with the truer sentence supplied next to it.

Neither list is modesty and neither is legal caution. They are a specification of what the claim excludes, written by the people who know precisely where the sealing stops, and handed to the people whose job is to make the thing sound good. The same instinct appears in a single sentence in a sync design note, where the system states that it does not claim to eliminate the window in which already-synced data sits on a device after access is revoked. The window is inherent to every offline-capable system, which is why the sentence generalizes past us. Naming it costs a paragraph and buys the only credibility that compounds, because a reader who finds one limit you volunteered stops auditing you for the ones you hid.

At consumer scale the same shape is now ordinary. Apple publishes a table of iCloud data categories saying which are protected end to end and which are held under standard protection, so the boundary of the encryption claim appears in the vendor’s own documentation rather than in someone else’s disclosure. A claim that publishes its exclusions does something a bare claim cannot, which is to bound what a reader is entitled to infer from it.

Limits are content

There is a difference between a limit that exists and a limit that is presented, and it is a design difference before it is an ethical one. Two systems in our own estate arrived at the same sentence from opposite directions. A readiness protocol in the atelier, which turns a claim about transformation into a reviewable packet, carries an output rule instructing renderers to show limits as first-class packet content rather than footnotes, and a readiness check that flags a packet with no recorded limit before it goes to external review. A brand document for one of our sites, written by people who never read that file, states as a strategic principle that honesty is the brand and that disclosures are designed content rather than fine print. One is machinery and one is positioning, and they converge because the underlying fact is the same. A limit rendered in six-point grey at the bottom of the page has been disclosed and not communicated, and everyone involved knows the difference.

The field has already built a form for this. Model cards, proposed by Margaret Mitchell and colleagues in 2019, make intended uses and out-of-scope uses a required section of a model’s public documentation rather than a caveat appended at the end. The move is small and structural. Give the limits a slot in the template, and an author has to fill it or leave a visible hole, which is a much better failure than a document that reads as complete because the missing part was never allocated any space.

Which way the failure falls

The last piece of an honest disclosure is a claim about what happens when the system is wrong, and here two of our own design documents look at first like they contradict each other. One argues that a projection engine denies by default: a recipient matching no rule receives nothing, a capability referenced but not registered is a denial rather than a passthrough, and a synthesis capability was deliberately left unregistered so a placeholder could never be served by accident. The other argues that a conversational assembler never refuses. A missing phase, an unknown label, an empty blueprint, and the system renders what it can rather than aborting a live turn mid-sentence.

Read them together and the contradiction dissolves into a single rule with a direction. Failure falls toward removing capability and never toward removing presence. The engine that denies is withdrawing authority: permission to disclose, permission to act on someone’s material, permission to speak in a voice that was never built. The assembler that degrades is preserving presence: the persona and the safety boundaries are precisely the parts that survive every degradation path, so that what a person meets at two in the morning is a simpler system rather than an error. Strictness belongs at authoring time, in the tools that help a builder construct something valid. Grace belongs at the moment of contact, in the machinery a person is standing in front of.

That direction is not ours and it is not new. Airbus fly-by-wire aircraft degrade through named control laws that withdraw envelope protections as sensor data becomes unreliable while leaving the pilot flying the aircraft. Life safety codes require electrically locked doors on an egress path to release when power fails, so a building under failure secures its perimeter and never its occupants. In both cases the system loses authority and keeps the human being. Disclosing which way your own failures fall tells a counterparty more about what you are than any architecture diagram, because it is the one claim that cannot be made retroactively.

Put the four together and the owed disclosure turns out to be a short document rather than a long one. Here is what we guarantee and here is what is merely how we currently do it. Here is what is checked, here is what is asked, and here is the list of things we say and do not yet enforce. Here is what our claim excludes, including the words we forbid ourselves. Here is the direction our failures fall. None of it requires publishing the machinery, which is the discovery that makes the whole practice affordable: candor and confidentiality were never opposed, because everything a counterparty actually needs lives at the altitude of promises rather than the altitude of implementation. A boundary stated plainly is not a wall between you and the person outside. It is the first thing you have said that they can safely build on, and the beginning of the only kind of trust that survives being checked.