Fieldnote
Why a Semantic Space has both an RID and an RSN
A name for people and governance, an identifier for permanence
Every resource in RSM ID has one RID and may have one or more names. A Semantic Space is no exception, and Document 08 is explicit that it gets both: a canonical RSN and a permanent RID. At first this looks redundant. If the RSN rrn:451:451labs:us-ca:wellzai:space/root already names the Wellzai space uniquely, why does the space also need 451.SD27J6QHDVEF0DYY?
The answer is that the two do different work, and the space needs both kinds of work done. The RSN is a structured name: it records the realm, the issuing authority, the jurisdiction of issuance, and the namespace, and it serves as a governance address that people and registries can read. The RID is the space's identity: the one value that stays the same when everything readable about the space changes.
What changes, and what must not
Consider what a space goes through over a long life. Its administering authority may change, as in Document 08's cooperative example. It may be renamed, or registered under a different namespace after a governed transfer. Its software certainly will change. If the RSN were the space's only identity, a namespace transfer would turn every resource's "authoritative space" pointer into a pointer at a historical name. With an RID, the pointer is stable: resources point at the space's RID, and the space's current and historical names are records about that RID. This is the same bargain RSM ID makes for every resource, applied to the spaces that hold them.
The third thing a space is not
Both the name and the identifier are easy to confuse with a third thing: the deployment. A Locus process, a database, a container, or a hostname may serve a space today and something else tomorrow. Document 08 says a space "SHALL NOT be confused" with any of them. The Identity Record keeps them apart by design: its space binding distinguishes the logical authoritative space from any particular Locus process, host, deployment, or content database. Moving a space to new infrastructure updates a binding; it changes neither the RSN nor the RID.
A worked case
Suppose the Wellzai space, named by the RSN above and identified by 451.SD27J6QHDVEF0DYY, moves its Locus node to a new host, and later, after an approved transfer, is administered under a different authority with a successor RSN. The Outcome Formation Model paper never needs to be touched. Its Identity Record points to the space by RID; the registry records the new binding and the successor name with effective dates; and the original RSN stays reserved, still mapping to the same space RID.
Why not just one?
A design with only an RID would leave spaces unnamed for people and without a governance address for registries; a design with only an RSN would make the identity of a space depend on its naming history. Two constructs, each doing one job, is the smaller cost. It also keeps the rules uniform: an RSN is not a separate scheme, just an RRN whose kind is exactly space, and a space RID is just an RID. Nothing special has to be learned for spaces — which is exactly why it is worth noticing that they, too, have both.
What remains open
The specifications leave one relationship unstated that a reader may wonder about. Document 09's representative schema gives a space record its own status vocabulary — active, suspended, retired — distinct from the five identity lifecycle states its RID can hold, and neither document says how the two relate. The space RIDs used on this site are placeholders too: Document 08 writes <registered-space-rid> where a real one would go. Both will be resolved by registration and schema work; neither changes the reason a space carries a name and an identifier.