Scion Address

A compound DID of the form did:repo:<sha1>/<repo-relative-path> that identifies a specific node within a specific DeepContext graph. The <sha1> is the graph's own DID — derived from its Open Integrity inception commit and therefore stable across any git host — and the path segment uses the W3C DID-URL path syntax rather than any git-forge's URL convention, so a Scion Address does not embed /blob/main/ or other host-specific segments.

Concrete examples on this repository:

A Scion Address is not a URL. Browsers today do not resolve did:repo: — the Scion Address sits as a canonical identifier waiting for a resolver that walks from the DID to one or more host URLs (GitHub, GitLab, Radicle, self-hosted). Two places in this graph already emit Scion Addresses in anticipation of such resolvers:

```markdown See the Open Integrity inception specoi-readme for the canonical ceremony.

```

Both live in the same markdown element; the URL works today, the Scion Address waits for tooling. Neither depends on the other being present.

The Scion Address differs from the plain did:repo:<sha1> in scope: the plain form identifies a repository-as-whole (the graph), while the Scion Address identifies a specific node within that graph. When [[Adopt Scion Publication Model]] says a scion "carries one DID across any git host," that DID is the plain form; when a node needs to be cited at page granularity, the Scion Address is the form.

Limitations are named rather than hidden. A Scion Address uses the file's current path; if the file is renamed or moved, the old address no longer resolves to the file at its new location. For most references this is acceptable because paths are stable in practice, but a rename-survives form would need to use the file's blob SHA1 rather than its path. The graph does not commit to that more principled form today; if rename fragility becomes a real problem, the Address syntax may extend.

Relations