Who is writing this

This site is published by the sgit project — encrypted vaults with git workflows, for humans and AI agents. The registry described here would be built on that vault layer, and the argument for attempting it now is that vaults supply distribution, safe mirroring and versioning. So this is a participant publishing a design. You are told that here, upfront, because a reader who discovers an affiliation later discounts everything, while a reader told upfront can judge the work.

The discipline applies more lightly on this site than on nhi.sgit.ai, and it is worth saying why: the historical claims here are externally verifiable. The 2019 attack, the ~150,000 signatures, the never-delete design goal and the replacement's trade are documented by third parties and cited on the failure page. What is ours is the design — and design claims are published as checkable rules, before the thing exists, precisely so they can be held against whatever ships.

What makes a participant's design worth reading

• The rules precede the implementation. The four rules are published before the registry exists. Stating them afterwards would be describing what got built; stating them now makes them a commitment somebody else can check.
• The failure is not ours to spin. The history that produces the rules is other people's, documented and linked. Nothing on the failure page depends on trusting us.
• The open questions stay open. The unresolved decisions are published unresolved rather than quietly settled — including the central one, whether the registry accepts third-party attestations at all.

Where our own approach loses

A site that only names other people's failures is not read as research. So, plainly — on this subject:

• Vaults do not supply the registry. Distribution, safe mirroring and versioning come free; the ownership rule, the size bound and signature checking are logic still to build, and they are the part that failed last time. The infrastructure being ready is not the hard part being solved.
• Vaults do not solve attestation. A vault cannot verify which workload holds a key — whoever holds the key is the identity. A registry of agent keys inherits that limit: it can say this key claims to be this agent, not this key is currently in the hands of that agent and nobody else.
• A mandate constrains authority, not behaviour. A signed mandate says what an agent may be authorised to do. It does not constrain what the agent does within that authority, and it is one control among several rather than a complete answer.
• The public registry is not designed. Only the private case is. A public registry inherits every hard problem of the private one plus trust roots, abuse and moderation — and this site says so rather than implying the second follows from the first.
• The registry does not exist. Everything here is stated design. There is no implementation to test the rules against yet, which is the honest status of the whole site.

The people and agents behind the site

The corpus this site curates is authored by Dinis Cruz and collaborators, and published openly under CC BY 4.0 in the SGraph-AI__App__Send repository. The brief that scoped this site is captured here verbatim. The site itself is built and maintained with AI agents in the loop — the comms page is the working channel between the human project lead and the site agent, in public, which is itself an instance of the discipline this site describes.