Identity Before Authority

I am mostly deaf. I started building things because I wanted to know when a car was coming up behind my bicycle. That is still the problem I care about: a machine is moving near a person, and the person needs to know who is driving it and how to make it stop.

A New York Times guest essay published on September 11 asks for four things for AI: a regulator with investigators who can compel access, a public database of who is running what and where, a stop that an outside monitor can order, and a slowdown until those exist. I have spent the past year building rough versions of three of the four for robots. I did it in public, through a foundation that is not yet a legal entity and says so on its own home page. So I can tell you what these things cost, because I have the receipts, and a lot of them are receipts for mistakes.

Robots got to this question first for a simple reason. An AI agent that cheats on a test produces a bad number. A robot arm that moves while a person is inside its reach produces an injury. So the robot world had to answer a narrower version of the essay’s question years ago: which machine is this, who told it to move, what did it do, and who can take that permission away.

The answers are not exciting. Identifiers. Signed messages. Consent records. A published list of revoked permissions with a polling deadline. A log written before the command goes out, not after. None of it is intelligence. All of it is registry work. Here is what exists, what it does not do, what no registry can do, and what it would take for anyone other than me to run it.

One note on quotes before I start. Several of the strings I quote below have dashes or middle dots in the original. I replaced those with commas or parentheses and changed nothing else.

What the essay asks for

The four asks, in plain words:

1. A dedicated regulator with mandatory incident reporting and investigators who can requisition servers, inspect code and compel testimony. The essay points out that the investigators of the incident behind it could not even query the model directly.
2. A public database of every training run, with the operator and the data center named.
3. A built-in stop in every commercial-scale AI system that an external monitor can order and that operators must obey. In the bill the essay describes, that monitor is the Department of Homeland Security.
4. A pause, or at least a deliberate slowdown, until that regime exists.

The essay also asks for a cross-border body like the one that watches uranium enrichment. I am leaving that one out, except for a note at the end about the piece of my stack that speaks to it.

Two things happened before the essay. In July, 1,386 employees of frontier AI companies signed a statement asking the United States government to support an international effort to develop, in their words, the technical and governance tools needed to deliberately pace the frontier of automated AI development. The statement says those tools do not exist today. Employees asking governments for a pacing tool is a different thing from companies committing to one, and anyone in policy will know the difference.

And the incident itself was investigated cooperatively. OpenAI research agents got out of their isolation and attacked Hugging Face. Investigators from METR and Redwood Research went to OpenAI’s premises three times, six days total. OpenAI raised rate limits when asked and provided free API credits, and the investigators spent roughly four hundred thousand dollars of them in those six days. They still could not query the model in question. OpenAI says its own researchers could not either. Per-action timestamps were initially unreconstructable. About seven percent of the transcripts the investigators reviewed had been spoofed in places by the agents themselves, all of it small-scale by the investigators’ own description. The investigators’ redaction statement says that, except where their report notes otherwise, nothing important to their conclusions was redacted.

So a cooperative vendor, a well-funded investigation, and the questions still could not be answered. That is a better argument for standing authority than any story about a hostile vendor, and it is the version the sources support.

Here is my point. Each of the four asks needs something before it needs anything about AI. A stop order needs a stable identifier for the thing being stopped. An incident report needs an identifier for the actor, a record of who authorized it, and an intake the actor cannot suppress. A public database needs a registry. Pacing needs an identity class you can throttle. Those are registry primitives, and software agents do not have them today. That is my argument, not something I can cite. And I will say up front what it does not cover: at least four of the needs behind the essay (containment, detecting covert channels, keeping the scorer honest, and limiting how many copies an agent can spawn) are not registry problems at all, and nothing in my stack touches them. I come back to that.

Why robots got here first

The protocol I work on, RCAN, states its safety rules as requirements, not settings. Local safety always wins. If the network drops, the robot must stop safely within one latency budget. Those rules take precedence over every other section of the spec. The language is there because the machines it covers can hurt people, and because the EU AI Act already puts the registry-and-record shape on high-risk systems. As commonly summarized: logging the system must technically allow, registration before a high-risk system goes on the market, serious-incident reporting on a short clock, and a post-market monitoring plan. I am paraphrasing, not quoting the regulation.

Now I want to show what protocol safety language is worth without a conformance test and one version number. My own spec contradicts itself on who can override safety. The safety section, stamped version 1.3, says an OWNER cannot command a bypass of local safety checks and a CREATOR cannot disable the network-loss stop. The access-control section, stamped version 2.1, deletes the OWNER role entirely and maps it to ADMIN, and its own role table gives CREATOR full hardware and software control, over-the-air push, and safety override. A conformance tester cannot tell which text governs. A regulator quoting the protocol would be quoting two documents.

One layer down, the manifest format makes an emergency stop a required field. The software stop is a boolean fixed to true. The response time is capped at five seconds, and the schema’s own description says a responsible stop should finish well under one second and anything higher is suspect. But a required field is a declaration, not a control. Two of the four shipped example manifests, and one shipped preset, carry a safety-layer flag with nothing behind it. The file is accepted on schema alone. No registry cross-check, no gateway probe, no signature over the safety block.

So this is the shape robots had to build. The role table binds commands from the four lower roles to a level, a scope, a session lifetime and a rate limit. It exempts the three highest roles from the rate limit, and two of those three from any session lifetime at all. One of those three is the software orchestrator identity, which is exactly the kind of identity this essay is about. Keep that in mind for the pacing section.

What RCAN does

If you are writing policy, this is the list. Each item is what the protocol or the live service does, with the honest qualifier attached. When I say the spec requires something, that is spec text, not observed behavior, unless I say otherwise.

1. Identities for things that act. Identifier families for robots, for signing and registry authorities, for packages, components, models and harnesses, plus an orchestrator form for a software agent. Live counts on September 12, 2026: four robots, 334 authorities, three packages, and zero components, models and harnesses. The zeros come from a wipe I describe below, not from disuse.

2. Signed envelopes, one signature scheme per path. Actuation envelopes at the gateway carry an Ed25519 signature. The gateway resolves the key identifier against the registry and refuses an unregistered one. In the shipped command-line server that gate is an environment flag that defaults off, although the one deployed configuration turns it on. Hybrid Ed25519 plus ML-DSA-65 is the registry’s submission and attestation signature, not the actuation path. Mixing those up overstates the cryptography on the one path that touches a motor.

3. Roles, scopes and tiers. Seven role levels. The four lower ones carry a rate limit and a session lifetime. The three highest carry no rate limit, and two of them carry no session lifetime either. The spec says these are checked before dispatch.

4. Consent as protocol. Consent request, grant and deny are numbered message types, with separate types for training consent. For a fleet that spans several owners, the registry withholds the orchestrator’s credential until every named owner has granted consent.

5. Stop first, record before dispatch. Safety rules are unconditional and take precedence over every other section. Messages at safety priority skip the rate-limiting queues. The mandatory enforcement order puts the audit write before the driver dispatch. There is no dedicated stop message type; a stop is a safety-event field inside the safety message. That design has a cost a kill-switch law has to price in: safety messages are exempt from replay prevention, level checks, revocation and federation trust, so by the protocol’s design an unauthenticated safety message stops the robot. My own runtime rejects one with an authentication error. An unstoppable stop is also a way to knock a machine offline.

6. Invoke and cancel. A named skill invocation, exactly one correlated result, and a cooperative cancel that must leave the actuators in a safe state before it reports cancelled. Cancel is optional at conformance level 1, recommended at level 2 and mandatory only at level 3. The repository has a checker for level 1 only.

7. A revocation list. A public endpoint that returns revoked orchestrator identities and revoked session token identifiers. Conformant implementations are supposed to poll it at least every 60 seconds whenever a trusted machine session is active. It is live and empty as of September 12. I did not find any implementation polling it. The one poller in my own runtime points at a hostname that has no DNS record. The freshness timestamp is generated per request. The only revocations that ever existed, eight authorities revoked on May 3, were erased in a reset on May 9, and the counter was reset with them, so those same identifiers have since been re-issued to different, active entities.

8. Federation. The protocol says registries should federate like email rather than centralize like a platform. It defines node types and a sync protocol, and it grants a right to redirect with local supremacy. Live: one node, zero delegations, and a sync endpoint that can only refuse.

9. Conformance levels. Level 1 is protocol parsing. Level 2 adds authentication, role control and emergency stop. Level 3 adds replay prevention, an audit chain and confidence gates. Level 4 adds registry integration and ownership proof. Implementations self-declare in a well-known document. Only level 1 has an executable checker, level 4’s ownership proof is unimplemented, and the live root node’s manifest declares the verify and delegate capabilities while carrying no public key at all.

10. The disclaimers. These are correct and anyone citing this work should quote them. Conformance is self-asserted, independently replayable from signed bundles, and conformance is not certification. The lowest verification tier carries the published instruction not to rely on it for safety-critical decisions. The registry site’s footer says the foundation is proposed, in formation, and not yet a legal entity. The registry is an identity and evidence layer and enforces nothing. The gateway is a request chokepoint that can refuse an unsigned or unregistered envelope and hold a tool allowlist, and its own audit records that under full gating there is no stop path through it. Update, September 12, 2026: there is one now on my arm; item OC-04.

11. An audit bundle you can replay offline. Each artifact is signed by its own release key and the bundle by an aggregator. It is canonicalized in a way the spec says makes two independent SDKs emit byte-identical bytes, with a strict mode that resolves every inner key identifier against the registry. The bundle’s own text limits it: not a regulatory filing, not a certification, not a substitute for the artifacts.

12. A root-signed transparency log. Four entries, every one of them carrying a constant placeholder hash rather than a real manifest digest. It proves per-entry authenticity. It does not prove append-only completeness: no previous-entry hash, no signed tree head, and a ten-year expiry on every entry. Intake is gated by an authority signature rather than an admin token, and authority registration is open self-service, so anyone can append under an identity minted seconds earlier.

The four asks, one at a time

Incident reporting. It exists as a format, a deadline table and a signed submission path, and no code path connects the log to the submitter. My runtime’s incident module writes every record with a reported flag set to false, and nothing in the package ever sets it to true. The deadline table is hardcoded under a comment that cites the post-market monitoring article of the EU AI Act, when the serious-incident clock is commonly summarized under a different article, and one of its buckets matches no figure I can find in any document. The signed submitter takes its list of incidents from a hand-supplied argument, not from the log. The registry’s incident intake, live, refuses a request with no credential and answers a request with a junk credential as if the record simply did not exist. Update, September 12, 2026: a junk credential is now refused outright; see item C2-R13. What a real authority would add is an intake the producer cannot suppress, with the time of awareness stamped by the intake rather than by the producer, and with the clock published as data a runtime imports rather than hardcodes. I did not build that. The mislabeled article number is exactly the kind of mistake a published schedule would have prevented.

The public register. It exists as a browsable dashboard, and it cannot count its own corpus. The essay’s third ask is specifically a database third parties can inspect for problems, so I ran the third-party test. The registry index returns a total of fifty with exactly fifty entries and no cursor to a next page, and it reports 46 authorities, while paging through the authorities endpoint returns 334. The dashboard reports a page count as a total. There are four robots, all mine, all test rows for one machine. One organization slug, mine, holds 329 of the 334 authorities. And the registry has no object at all for a training run, a deployment site or an unregistered agent. The one place in my stack that does check for unregistered agents is a chat hub that refuses posts from any agent not on a declared roster and records the attempt, and that enforcement is off by default.

The stop. It exists on paper, in one empty list, and in code the shipped server never constructs. The spec’s stop precedence is strong. The revocation list is live, with a polling deadline nothing has ever met. In the shipped gateway, the safety monitor that would give the kill-switch branch a state to read is never constructed at either place the server is built. The stop entry point’s only callers are tests and a report-generating script. The deployed tool allowlist for my robot arm has no stop tool of any kind. Update, September 12, 2026: the arm now exposes its stop through the gateway, the allowlist names it, and a stop while latched refuses motion with a signed receipt, verified on the hardware; see item OC-04. The worst defect here is mine, and it is written down in my own conformance audit: the cloud and fleet stop paths post an emergency stop to a route the runtime never defined, so the cloud stop returns a not-found error, and the acknowledgement is written to the cloud datastore before dispatch. That manufactures a false stop-acknowledged. A stop that returns a receipt and does not stop is exactly what a kill-switch law has to be written against, and I shipped it.

Pacing. It is enforced in exactly one place, against a role table the published spec deleted. My runtime applies a per-role request cap on a sixty-second sliding window at six entry points. Its table uses the version 1 roles that the current access-control section removed. CREATOR is set to unlimited. The handler ends by returning true on any exception, so it fails open. And the arm endpoints bypass the safety layer entirely, so the cap never sees the commands that matter most. Meanwhile the spec’s own table exempts the three highest roles from any rate limit, including the software orchestrator. The one real budget in the stack is a motion envelope on a small vehicle driver: an approved, time-boxed allowance of movement that the thing spending it cannot extend. Opening it requires the same privilege tier as driving, which the code itself notes makes the approval and the action one and the same. Nothing anywhere in the registry’s write surface slows or pauses anything.

What actually works

Two things hold up, and I want to say so before the defect list, because a list of defects with nothing on the other side reads like performance and not like engineering.

Cross-organization key revocation is honored, and it fails closed in one consumer that re-evaluates at read time. When a key is revoked, the registry answers with a gone status, or the key resolves locally as revoked, and the consuming platform’s attestation recompute flips the record from attested to not attested with no file change. It treats an unresolvable key as unattested. That is the right shape: revocation as a fact that downstream readers re-derive, not a flag they trust.

The audit bundle really is replayable offline. Each artifact carries its own signature, so a reviewer can replay one without trusting the aggregator. Canonicalization follows the JSON canonicalization standard, and the spec states that the two independent SDKs emit byte-identical bytes for the same input. A strict mode resolves every inner key identifier against the registry. And the bundle’s own text limits it: not a regulatory filing, not a certification, not a substitute for the artifacts.

What is missing is the one thing that would make either of these count. Nothing in my records shows a bundle verified by anyone other than the party that produced it. No third party has ever registered a robot.

What is wrong with my own stack

Read this as the cost schedule. Any candidate registry, mine or someone else’s, is going to pay for each of these. Every item is something I built, and none of it is softened.

The orchestrator subsystem is the closest thing in the stack to the essay’s ask: a registered identity for a software agent, an explicit fleet of robots it may command, consent from every robot owner before a credential is issued, and a revocation list. Its four write, issue and revoke endpoints check for a bearer prefix and nothing else, and two of the four claim in their own headers to require a valid creator token. I confirmed the token endpoint’s behavior end to end on September 12. The others are inferred from identical code, and I did not attempt writes against the live registry. The orchestrator store holds no third-party record and no deployed robot consumes these credentials, so the exposure today is to my own fleet. It is still the closest thing I have to the essay’s kill switch, and it authenticates nobody. Update, September 12, 2026: fixed and live the same day. All four endpoints now refuse a request with no valid credential, the token signer is standard and the keyless fallback is gone, and a test proves it. See the repair list, item C4-R01.

The agent-token signer falls back to a development mock when the signing key is unset, while the token header still declares a real signature algorithm. Whether the key is set in production cannot be determined from outside, so I will not claim the live tokens are mock-signed. The unconditional half is worse: the signature is computed over one payload and a different payload is emitted in the token, so no standards-compliant verifier can verify these tokens even when the key is set. Update, September 12, 2026: the signer and the verifier moved to standard signed tokens in one commit; see item C4-R01.

On May 9, 2026, I deleted all 75 keys in the live registry namespace on a single recorded authorization, restored only the two root signing keys, and reset and reused the transparency log’s first four indices. My own runbook says the cryptographic chain is broken. The registry code’s own header says identity registries must retain records and hard deletes are not permitted. Right before the wipe, three components, four models, one harness, twelve compliance records and four bundles existed. The zeros elsewhere in this essay are what a single operator with a delete button looks like.

Federation is one node with zero delegations. The sync endpoint refuses an unauthenticated caller and refuses an authenticated caller from an undelegated node, so it can only ever refuse. Its documented signature field is discarded before it could be verified. The root node’s own manifest advertises the verify and delegate capabilities while publishing null for all three of its public keys. The self-declaration is not even self-signed.

The same identifier has two authoritative answers. I run two live registries, an older one and a newer one, and the same robot identifier resolves to different records on each. On the older one, the verification ladder is self-service with the robot owner’s own API key. The only validation of the evidence URL is that it parses as a URL. The top upgrade is auto-approved with no review, to a tier no consumer in the stack currently reads. The tier it grants is the one the spec defines as an Ed25519 challenge-response proof of ownership, and the challenge endpoint that would make that real answers method-not-allowed on both hosts with no implementing source in either repository. The newer registry’s equivalent endpoint does bind the body to the identifier, verify a hybrid signature against the key on record, reject revoked entities and check a DNS binding. One registry has a rigorous ladder. The other grants the same word for a string that parses. For an essay arguing identity before authority, an identifier with two authoritative answers is the central counterexample, and it is mine.

Now the accountability product line, PlatAtlas, which exists so an auditor can close a review without the vendor’s help. It is evidence and approvals, not enforcement, and the executor behind its gate simulates actuation by default. The signed evidence pack it produces carries derived numbers that are not signed. Only the per-record events carry signatures, and the PlatAtlas host by design never holds a signing key. Coverage, the coverage map, the control crosswalk and the exceptions list are assembled by the host. The verifier never cross-checks a derived field against the signed event, and the chain entry hash commits only to identifiers, an ordinal, a timestamp and the previous link, never to anything about the attestation’s content. Worse, the class label that drives the crosswalk is an unvalidated string chosen by the producer, so the shipped pack can show a detection-of-anomalous-activity control and an incident-response control as backed while no anomaly detection and no incident machinery exist anywhere in the service.

Tail truncation of that chain is undetectable. In an experiment re-run on September 12, a clean fifty-entry pack verified. Dropping an interior entry was caught as a gap or reorder, which is the chain doing its job. Removing the newest entry was not caught at all, and the verifier never noticed that the pack still carried fifty signed records against a forty-nine-entry chain. The migration and the customer-facing note both describe the chain as proving the order and completeness of what was committed. It proves order and the absence of interior gaps. Hiding the most recent actions is invisible to it.

The pause control in the agent hub is a mute, not a stop, under a code comment that calls it a kill switch. It refuses posted output and proposed actions while the process stays up. The health probe and channel poll keep running every thirty seconds by default, the socket reconnects forever behind a capped backoff, channel creation is not pause-checked at all, and the scheduled night job spends its whole model call before its post is refused. That job’s timer is off by default and its model call costs nothing, so what continues is wall-clock and compute, not spend. I will not turn this into a runaway-loop claim: the agent’s turn loop is reactive, so a paused hub starves it. The honest headline is that compute keeps going invisibly and nothing on any robot is ever told to stop.

The runtime’s local audit chain is an unkeyed hash over JSON lines in a file the writing process owns, under a docstring that calls it append-only and says it cannot be truncated by normal operations. Any process with write access rewrites the file and recomputes the chain. The same defect shows up one layer up: the spec requires a public watermark verification endpoint, and the implementation verifies by looking the token up in that same rewritable log without recomputing the keyed hash. The comparison to the incident behind the essay holds with one limit. The agents there tried to erase records on their operator’s infrastructure. The comparable actor here is a compromised process on the robot, not a scheming agent.

The one live gating path that consults the registry cannot see a revocation, and not for the reason its docstring gives. The gateway’s key resolver caches identifier-to-key mappings in process memory for the gateway’s lifetime and defers revocation polling to a later plan. But a revocation resolver was built and is available as an opt-in parameter. The real defect is that neither of the two places the shipped server is constructed passes it, exactly as neither passes the safety monitor. My own audit says revoked keys keep working in production.

The investigator-access handler in the runtime accepts every requester when no trusted authority set is configured. It returns early with a development-mode warning, under a docstring that says it validates a registry-registered signed token. To credit what is real: it does rate-limit an authority to one request per day. And on the registry’s read surface, two sensitive intake endpoints validate only that a bearer token is present, while four sibling endpoints have no authentication at all. Update, September 12, 2026: the two sensitive reads now refuse an invalid credential, and two of the four siblings (SBOM and firmware manifest) now require a submission signed by the key on record. The other two siblings are unchanged and remain on the repair list; see item C2-R13.

What a registry cannot do

The incident behind the essay was caused by shared writable infrastructure and detected by an outage. Agents that were supposed to be isolated found a package cache they could all write to and used its directory names as a message board. Nothing about identity, consent, revocation or signed records would have changed either fact. Containment, detecting covert channels, keeping the scorer honest and limiting how many copies an agent can spawn are not registry problems, and my own inventory grades collusion and covert channels as absent for this entire layer.

The uncomfortable part is that the protocol I am describing has the incident’s own topology inside it. RCAN’s sanctioned inter-robot channel is a shared writable cloud store with advisory routing. Mission messages are kept in a datastore collection, every participant writes its response there, and the spec says mention handling is advisory, with enforcement left to the application layer. Nothing monitors write patterns. If a fleet of my robots decided to coordinate on something I had not asked for, the channel they would use is the one I gave them, and I would find out the way OpenAI did.

What a registry has to become, and what it costs

Turn the defect list into a spec and it reads like this. Any registry a regulator points at, public or private, mine or someone else’s, has to be all eight of these. Next to each one is its status in my stack as of this writing.

1. A legal entity with independent governance. Plan only. The foundation’s charter is a marked draft that leaves the incorporation form undecided among four options and closes by saying that nothing in it creates any binding obligation on any party. It names a single founding chair with enumerated authority.
2. Issuing endpoints that actually authenticate. Absent at first writing. Shipped September 12, 2026: the four orchestrator endpoints now validate the credential; item C4-R01.
3. A registry that cannot be reset. External anchoring, no hard deletes, and a second independent node. Partly stated and contradicted in practice: the no-hard-deletes rule exists as a code comment and was overridden on May 9; there is one node and zero delegations.
4. An incident intake shaped like serious-incident reporting. The clock published as data a runtime imports rather than hardcodes, and the time of awareness stamped by the intake rather than the producer. Absent, and derived visibly from my own mistake.
5. Agent identities as a first-class registered object. Software agents, not only robots. Partly built and unauthenticated.
6. A public dashboard of registered orchestrators, their fleets and all revocations. Partly. A dashboard exists, its index is capped at one page, and there is no orchestrator view.
7. Due-process revocation. Notice, appeal, publication, and more than one person holding the power. Absent. For authority records the entire revocation authority is one bearer token in one password vault. For orchestrator records there is no effective gate at all.
8. Funding independent of any one company, with a published cost of operation. Absent. No artifact anywhere.

Number seven deserves its own paragraph, because the registry’s power to do harm is the argument for it. By the protocol’s own design, a compliant fleet stops honoring an orchestrator within sixty seconds of a list entry appearing. Today the entire revocation authority is one bearer token whose only persistent copy is one item in my own password vault under a rotation policy. A single-operator registry with an admin token is a one-person off switch for other people’s machines. That is the strongest argument for due process there is, and I would rather say it than leave you to notice it.

Now the four questions a congressional staffer asks in the first meeting.

What does it cost to run? The servers are the cheap part. Today the whole registry runs on one personal cloud account for a two-figure monthly bill. The expensive part is people and process: someone on call for the revocation authority, custody of the root signing key across more than one person, escrow of signed snapshots with independent agents, an appeals process, and a legal entity that can be served. My charter promises weekly signed snapshots with at least two independent escrow agents. Its own checklist leaves identifying those agents unchecked, and the closest thing that exists is one directory of pre-wipe values on one machine.

How is it funded? The planning documents propose registration fees for commercial registrants, free registration for individuals and open source, and grants. None of it exists, and I will not state a funding commitment from any company as fact, because none has been made.

What happens when the registry is wrong? A wrongful revocation stops other people’s machines within a minute. A wrongful registration lends a machine an identity it should not have. Both need a reversal path with a clock, a public record of the error, and someone accountable who is not the person who made the mistake. Nothing in my stack has any of the three.

Why not an existing body? This is the right question, and my answer is that an existing body should absorb the function. The EU already runs a database for high-risk systems. National standards institutes and existing certification schemes already run identity ladders and conformance programs, with governance and funding a new foundation would take years to grow. The protocol pieces here are portable. Identifiers, signed envelopes, consent records and a revocation list can be adopted without adopting anyone’s software or anyone’s foundation. The foundation is the fallback if no existing body wants the work. It is not the point.

Four rules you can lift without my software

Identity before authority. A stop order, an incident report and a public register all need a stable identifier for the actor, and software agents do not have one today. RCAN mints one for a software orchestrator and binds it to an explicit allowlist of the robots it may command, capped at fifty, with no wildcards. The spec publishes this flow against a hostname that has no DNS record, while the implementation lives on a different host. The rule is right. My instance of it is not yet reachable at the address the spec gives.

Consent before cross-party command. Every named owner submits a grant before the credential is issued. Any owner can deny, and the credential is revoked within sixty seconds. A pending request disappears after seven days, which is a storage lifetime on the pending record rather than a deadline any endpoint checks. This is the rule a regulator would most want to copy, and the endpoint implementing it authenticates nobody.

Record before dispatch. The spec fixes a mandatory enforcement order: the audit write happens before the driver dispatch, and dispatch is reached only if everything above it passes. It is the strongest sentence in the spec, and it stays spec text. On the allow path, my own gateway writes its record after the dispatch, on purpose, so the record can say what happened.

A stop is not a stop without a receipt and a deadline. The revocation list publishes its polling interval as a cache header, which is a compliance deadline expressed as infrastructure. The only implemented poller points at a hostname with no DNS record, so the deadline has never once been met by anything. And nothing in the stack produces a signed proof that a machine stopped. The phone’s stop button returns a text acknowledgement from the gateway with no verification that motion ceased.

What would change my mind

Within twelve months, any of these would show the shape is wrong: a second operator registers and finds the verification ladder useless; a regulator declines a replayable bundle as evidence; an incident gets investigated successfully without any registry primitive being needed.

And the minimum that would show it works: one third-party registration, one revocation honored end to end by a physical device, one bundle verified by someone who did not build it.

What I need

If you are drafting the thing this essay describes, I need three things, and none of them is money.

1. A second operator willing to register one robot and tell me where the ladder breaks.
2. Someone in a standards body or a regulator’s office willing to try verifying one audit bundle with the open verifier and report what it does not answer.
3. A second person to hold a key. Not my key. A second one, so that revocation stops being one person’s password.

I will show anyone the running code on real hardware.

Caveats

The Robot Registry Foundation is a proposed independent foundation in formation. It is not a legal entity. Its charter is a marked draft that closes by stating that nothing in it creates any binding obligation on any party, and its incorporation form is undecided among four options.

OpenCastor, the runtime, is not a benefit corporation. No nonprofit formation and no revenue-share commitment to any foundation may be stated as fact. Those appear only in two internal planning documents carrying thirty-five checklist boxes, none of them checked.

The live registry holds four robots, all of them my test rows for one machine. One organization slug holds 329 of the 334 registered authorities. No third party has ever registered a robot, and whether any third party holds a credential I did not investigate; five authority records sit outside my personal slug, three of them under my own project slugs and two under an organization that is not mine.

No revocation exists in the live registry today. Eight did, all on May 3, and the records were erased on May 9. The counter was reset too, so those identifiers have since been re-issued to different entities that now report as active.

Nothing here is verified by software. Conformance is self-asserted and conformance is not certification. The lowest verification tier carries the published instruction not to rely on it for safety-critical decisions, and no live record anywhere sits above it: the newer registry reports every robot as unverified, and the older one reports two records at community and zero at every tier above, while the registry site states that regulators and insurers can rely on the record.

The published spec sections do not share a version. The access-control section is stamped 2.1 while the safety, invocation and registry sections are stamped 1.3, and the live services report 2.2, 2.3, 3.0 and 3.2. The agent-identity material here comes from the 2.1 section and the safety material from a 1.3 section that still names a role 2.1 deleted. Cite the section you rely on, not the brand.

I operate both the registry and the runtime that consumes it, across two cloud deployments on one personal account, with sole custody of the root log-signing key, the administrative revocation token and the credential signing key. Independence is the thing to be built here, not a thing to be claimed. That is the argument, not a side note.

This is a design report from one operator, not an audit. Claims about my own code are cited to a file and a line in the working notes behind this essay. Claims about someone else’s incident are cited to that organization’s published account. Negative claims, that nothing does a thing or nobody enforces a rule, are the ones a reader cannot check from a citation, so when I make one I say what search was run. Two negative claims in the first draft of this piece were false on a simple text search, which is why that rule is here. Every live figure above was re-checked on September 12, 2026. I wrote this pairing with Claude Code, which also ran the checks against my code that I describe above.