A practical layout for agent identities proposes how one person files credentials for themselves and their agents, and checks it against the standards. A store was built on that ground for real accounts the same day, and then written down as a sealed specification: a document handed to another agent with nothing else, from which it could build something compatible. That is v1.

v1 left out six things the layout note and the revision notes on digital shapeshifting had already found it needed. Rather than one large v2, each is a draft of its own, stacked on the one below:

Each draft is the whole specification, not a patch, because a sealed document has to stand alone. Each carries a section saying what changed from the one below and a section of questions for its reviewer.

The order is the order of dependence. v6 joins a route to an entry by realm, and v5 records runtimes by path; both are only as good as two spellings of one name being one string, which is v2. v5 needs to say a copy is rotated everywhere, which is easier once v4 has said what rotation does to a derived secret. v7 tests everything below it, so it comes last.

Stacking gives each change a reviewer's attention of its own, and a place to stop. A question answered in review of v3 changes v3; the answer is then carried into v4 to v7 before any of them is sealed.

A draft is sealed by copying it, verbatim, into a private repository of its own with a record of where it came from: the tag and commit of the source, its size and its SHA-256. From then on it is not edited. What review finds, and what an agent building from it finds, is written beside it, in that repository's findings, and carried into the next draft. This is the same discipline as any rebuild graded against a fixed target: a specification patched during the build grades the build against a moving line.

The drafts' source is a private skill; the pages linked here are generated from it and differ only in their header and navigation.

The sealed repositories exist for a second reason: cleanliness. An agent given one sees the specification and nothing else, so anything the specification leaves unsaid shows up as a question, not as something the agent quietly copied from a store it should not have seen. Every name in every draft is invented for the same reason.

v1's last section holds for all seven: a store can conform to every rule on a machine where an agent reads a production token out of a .env file in a checkout. The proxy in v6 narrows that, since the agent need not hold the token, but it does nothing for the files already there.

Also left open throughout: hardware second factors, a mailbox as the root of recovery, and whether a passport number belongs in a credential store at all. They are listed in each draft's section 9.

• Identity Store Enterprise Ontology – v1 formalized in OWL/RDF and SHACL, checked clause by clause against this stack
• A Practical Layout for Agent Identities – the same store from the standards side, with promotion to hosted runtimes and the record
• Naming for Isolation – which escaping schemes turn two names into one (v2's review question 1)
• Agent Identity and Attestation – who acted and who claims what, once a credential is used
• Bot and Agent Trust Management – how sites and enterprises admit agents at all