# Who owns what on this forge
Three facts about a repository are deliberately kept apart. Most forges merge them, and merging them is what makes ownership a label the operator grants rather than something that is true.
**The deed** is an account. A person holds the repository. It is a stored column, `repo.owner`, not something inferred from who happens to hold a capability letter today. It is what makes deletion, transfer and succession expressible at all: you cannot hand over, or inherit, a fact that is only ever recomputed.
**The namespace** is where the repository appears: a team when a team holds it, the owner's handle otherwise. A team holds the path, never the deed. That is the whole reason dissolving a team is safe -- the repositories survive it and simply appear somewhere else, because they still have an owner to fall back to. RFC 0018 requires this; the code enforces it by writing both in one transaction, and a migration repairs any row that ever disagreed.
**The letters** are fossil capabilities (RFC 0004), unchanged. They say what somebody may do inside a repository. Granting `a` to a co-maintainer gives them everything except the things that belong to the deed. Ownership sits beside the letters rather than replacing them.
## What creation does
Anyone with an account may create a repository. The creator is recorded as owner and granted admin in the same operation, and if that grant fails the creation is rolled back -- a repository is never left that only a site admin can see. A repository created with no author stays forge-held with an empty owner rather than being attributed to whoever ran the command. Empty is a real state and means the forge serves this store on nobody's behalf: eighteen of the mirrors here are in it.
A forge-held repository can be claimed by an account that already administers it, or handed to another of its admins. Claiming refuses a repository that already has an owner, because changing hands is a transfer and a transfer needs the recipient's consent.
## What is NOT true yet, stated plainly
The deed is recorded and populated, and it authorises nothing. It is read in exactly one place, the claim operation. Deleting and removing a repository are still gated on the admin letter, so an admin collaborator can delete a repository they do not own. The rule that the destructive and alienating verbs belong with the deed rather than with the role is written down and not implemented.
A site admin's effective set includes the setup letter, and the capability check answers yes to any letter when setup is present. So a site admin passes every gate on every repository. The limits described for the operator -- not changing roles, not deleting, not reaching into a repository they do not own -- are a design position, not an enforced one.
Paths are still flat. Every repository URL is now built in one function rather than in 316 hand-written places, which is the prerequisite for namespaced paths, but no URL has changed.
There is no audit ledger. Operator power here is narrower than on other forges and still invisible to the owner, which is the half that would make it different rather than merely smaller.
## Why it is written down before it is finished
The gap between the model and the code is the useful part of this note. A model that exists only in someone's head gets re-derived differently each time, and a model described as finished when it is half-built is worse than no description. What is above is checkable: the columns exist, the claim works, the team fallback holds, and the gating does not.