Relationship matrix

All 92 stable entity relationships, including 88 current invariants and four explicitly future Device and encryption relationships.

This matrix is exhaustive by design. It gives coding agents one stable page per entity pair, including deliberate no-direct-edge invariants that prevent the wrong ownership or authorization model from creeping into code.

88 rows describe current implemented behavior or a deliberate current no-edge invariant.
4 rows describe target-only durable Device and application-encryption architecture. They are not current product behavior.
Read the machine-readable relationship index.

Verification is still in progress

Status classifications were reconciled before migration. Public code-anchor verification is pinned to Nautilo 4b3ea604 and must close before these pages become release-canonical.

Stable ID	Entities	Status	Audited invariant or evidence
`REL-ACT-AGT`	Actor ↔ Agent	`implemented`	Agent-kind Actor mirror and `actors.agent_id` back-pointer are current.
`REL-ACT-CAP`	Actor ↔ Capability	`implemented`	Capability authority is resolved through human/agent policy, not a direct Actor edge.
`REL-ACT-CHN`	Actor ↔ Channel	`implemented`	Channel is Room-edge vocabulary; Actor participation is deliberately indirect.
`REL-ACT-CON`	Actor ↔ Connection	`implemented`	Connection ownership resolves through user/agent identity, not generic Actor.
`REL-ACT-DEV`	Actor ↔ Device	`implemented`	No canonical Actor–Device edge exists; current client/session identities are deliberate runtime concerns.
`REL-ACT-GRP`	Actor ↔ Group	`implemented`	Group membership uses user/agent principals rather than generic Actor.
`REL-ACT-HUM`	Actor ↔ Human	`implemented`	A user-kind Actor belongs to one Human and supplies that Human’s participant identity.
`REL-ACT-NSP`	Actor ↔ Namespace	`implemented`	Namespace access is derived through user/agent policy rather than Actor FK.
`REL-ACT-RLY`	Actor ↔ Relay	`implemented`	Relay identity resolves to user/session context; no direct Actor edge is required.
`REL-ACT-RMS`	Actor ↔ Room	`implemented`	`room_members.actor_id` is the direct Actor-to-Room participation edge.
`REL-ACT-ROL`	Actor ↔ Role	`implemented`	Roles bind principals through groups/policy, not generic Actor.
`REL-ACT-SRV`	Actor ↔ Server	`implemented`	Actors are local to the deployment today; foreign-origin federation stubs remain future scope.
`REL-ACT-TOL`	Actor ↔ Tool	`implemented`	Tool execution receives resolved principal context rather than an Actor relationship.
`REL-AGT-CAP`	Agent ↔ Capability	`implemented`	Agent authority is resolved through policy and grants; no direct capability join is required.
`REL-AGT-CHN`	Agent ↔ Channel	`implemented`	Agent participation in channel-like Room edges is current and indirect.
`REL-AGT-CON`	Agent ↔ Connection	`implemented`	Vault records, Agent scope, readable Namespaces, and Tool Connection requirements are current; per-Namespace derived keys remain future security design.
`REL-AGT-DEV`	Agent ↔ Device	`implemented`	Agent work reaches clients through sessions/Relay; a direct Device edge is intentionally absent.
`REL-AGT-GRP`	Agent ↔ Group	`implemented`	Agent group membership and resulting authority are current.
`REL-AGT-HUM`	Agent ↔ Human	`implemented`	Profile ownership and `manage_agents` authority form the current Human-to-Agent relationship.
`REL-AGT-NSP`	Agent ↔ Namespace	`implemented`	Agent-readable and shared Namespace behavior is current; “ownership” terminology needs owner review.
`REL-AGT-RLY`	Agent ↔ Relay	`implemented`	The Relay registry and capability-matched execution are current; the supported implementations are the ones present in the pinned source tree.
`REL-AGT-RMS`	Agent ↔ Room	`implemented`	Agent Room membership, routing, and conversational participation are current.
`REL-AGT-ROL`	Agent ↔ Role	`implemented`	Agent authority is mediated through group/role policy rather than a per-Agent role table.
`REL-AGT-SRV`	Agent ↔ Server	`implemented`	Agents are deployment-local current entities.
`REL-AGT-TOL`	Agent ↔ Tool	`implemented`	Agent tool execution and catalog filtering are current runtime behavior.
`REL-CAP-CHN`	Capability ↔ Channel	`implemented`	Channel-like behavior is governed through Room/policy context, not a direct edge.
`REL-CAP-CON`	Capability ↔ Connection	`implemented`	Connection use is gated through policy and scope, not a Capability FK on each secret.
`REL-CAP-DEV`	Capability ↔ Device	`implemented`	Device/client permissions are runtime/session concerns; no direct durable edge is current.
`REL-CAP-GRP`	Capability ↔ Group	`implemented`	Group roles aggregate capabilities through the current RBAC joins.
`REL-CAP-HUM`	Capability ↔ Human	`implemented`	Human capabilities are derived from group-role membership.
`REL-CAP-NSP`	Capability ↔ Namespace	`implemented`	The no-direct-edge invariant is current; obsolete shared-memory capability slugs are absent from the catalog.
`REL-CAP-RLY`	Capability ↔ Relay	`implemented`	Current Relay capability snapshots describe executor features; they are distinct from Human authorization Capabilities.
`REL-CAP-RMS`	Capability ↔ Room	`implemented`	Room actions consume resolved policy; no per-Room capability join is required.
`REL-CAP-ROL`	Capability ↔ Role	`implemented`	Role-capability joins and the canonical role ladder are current.
`REL-CAP-SRV`	Capability ↔ Server	`implemented`	Capability definitions and grants are server-local.
`REL-CAP-TOL`	Capability ↔ Tool	`implemented`	Tool availability is dynamically filtered by resolved policy and runtime context.
`REL-CHN-CON`	Channel ↔ Connection	`implemented`	Connection use occurs through tools/Room context, not a Channel secret edge.
`REL-CHN-DEV`	Channel ↔ Device	`target`	No canonical Channel–Device relationship exists; MLS/device fan-out belongs to the future security model.
`REL-CHN-GRP`	Channel ↔ Group	`implemented`	Channel-like Room access is mediated by Room membership and policy.
`REL-CHN-HUM`	Channel ↔ Human	`implemented`	Human participation in channel-like Rooms is current.
`REL-CHN-NSP`	Channel ↔ Namespace	`implemented`	Channel is vocabulary over a Room already bound to a Namespace.
`REL-CHN-RLY`	Channel ↔ Relay	`implemented`	Relay can surface Room communication without a durable Channel edge.
`REL-CHN-RMS`	Channel ↔ Room	`implemented`	Channel is an attribute/interaction shape of Room, not a separate stored entity.
`REL-CHN-ROL`	Channel ↔ Role	`implemented`	Channel actions use resolved Room/server policy rather than channel-specific roles.
`REL-CHN-SRV`	Channel ↔ Server	`implemented`	Channel-like Rooms are deployment-local current behavior.
`REL-CHN-TOL`	Channel ↔ Tool	`implemented`	Tool use occurs in Room/session context; no Channel–Tool join is needed.
`REL-CON-DEV`	Connection ↔ Device	`implemented`	Secret access is mediated through authenticated user/agent runtime context, not a durable Device edge.
`REL-CON-GRP`	Connection ↔ Group	`implemented`	Group policy may authorize use, but vault scope is not modeled as a direct Group relationship.
`REL-CON-HUM`	Connection ↔ Human	`implemented`	Vault metadata now records `authored_by_user_id`; routes supply the session user.
`REL-CON-NSP`	Connection ↔ Namespace	`implemented`	User, Agent, and Namespace-scoped `ConnectionScope` behavior is current.
`REL-CON-RLY`	Connection ↔ Relay	`implemented`	Connection brokering through Relay/tool execution is current without exposing stored values in catalog metadata.
`REL-CON-RMS`	Connection ↔ Room	`implemented`	Room access resolves indirectly through its Namespace and active execution context.
`REL-CON-ROL`	Connection ↔ Role	`implemented`	Policy gates Connection operations; no direct Role join is necessary.
`REL-CON-SRV`	Connection ↔ Server	`implemented`	Each deployment owns its Vault backend; per-Namespace derived-key claims remain future crypto design.
`REL-CON-TOL`	Connection ↔ Tool	`implemented`	Tool catalog entries can declare Connection requirements and runtime tooling resolves them.
`REL-DEV-GRP`	Device ↔ Group	`implemented`	Current session/client identity does not require a durable Device–Group join.
`REL-DEV-HUM`	Device ↔ Human	`target`	Installation and workstation identities exist, but a unified durable multi-user Device entity does not.
`REL-DEV-NSP`	Device ↔ Namespace	`implemented`	Namespace access follows authenticated principal context rather than Device ownership.
`REL-DEV-RLY`	Device ↔ Relay	`target`	Relay tokens bind user and installation and sessions bind Relay identity; the canonical Device ontology is still future work.
`REL-DEV-RMS`	Device ↔ Room	`target`	Durable per-Device Room/MLS membership is future application-encryption work.
`REL-DEV-ROL`	Device ↔ Role	`implemented`	Authorization belongs to the principal, not the client device.
`REL-DEV-SRV`	Device ↔ Server	`implemented`	Auth sessions, installation identity, and Relay binding provide the current runtime association; durable Device remains target-only.
`REL-DEV-TOL`	Device ↔ Tool	`implemented`	Platform/client constraints filter tool availability at runtime.
`REL-GRP-HUM`	Group ↔ Human	`implemented`	Human group membership is current.
`REL-GRP-NSP`	Group ↔ Namespace	`implemented`	Namespace authority is derived through group-role policy rather than a direct Group FK.
`REL-GRP-RLY`	Group ↔ Relay	`implemented`	Relay operations use authenticated principal policy rather than Group ownership.
`REL-GRP-RMS`	Group ↔ Room	`implemented`	Room access and membership are distinct from server-wide Group membership by design.
`REL-GRP-ROL`	Group ↔ Role	`implemented`	The many-to-many group-role join is current.
`REL-GRP-SRV`	Group ↔ Server	`implemented`	Groups are server-local current entities.
`REL-GRP-TOL`	Group ↔ Tool	`implemented`	Tool policy is derived through roles/capabilities, not a direct Group–Tool join.
`REL-HUM-NSP`	Human ↔ Namespace	`implemented`	Namespace readability queries and grants are current; normalize the file-and-symbol citation format.
`REL-HUM-RLY`	Human ↔ Relay	`implemented`	Relay tokens bind `user_id` and installation identity, giving current Relay sessions a persistent Human association.
`REL-HUM-RMS`	Human ↔ Room	`implemented`	Human Room membership through user-kind Actors is current.
`REL-HUM-ROL`	Human ↔ Role	`implemented`	Human roles are derived through group membership.
`REL-HUM-SRV`	Human ↔ Server	`implemented`	`users.server` records current deployment locality; foreign-user stubs belong to future federation.
`REL-HUM-TOL`	Human ↔ Tool	`implemented`	Per-user policy, activation, posture, and context filter tool use dynamically.
`REL-NSP-RLY`	Namespace ↔ Relay	`implemented`	Relay execution receives scoped context without a durable Namespace–Relay join.
`REL-NSP-RMS`	Namespace ↔ Room	`implemented`	Every Room has a Namespace; universal top-level 1:1 uniqueness is an application convention, not a schema guarantee.
`REL-NSP-ROL`	Namespace ↔ Role	`implemented`	Namespace access combines scoped grants and server policy; no direct Role FK is required.
`REL-NSP-SRV`	Namespace ↔ Server	`implemented`	Namespaces are deployment-local through their current Room and data relationships; there is no `namespaces.owner_id` column.
`REL-NSP-TOL`	Namespace ↔ Tool	`implemented`	Namespace-aware tool envelopes and execution context are current.
`REL-RLY-RMS`	Relay ↔ Room	`implemented`	Relay participates in Room work through authenticated sessions and tool/browser execution.
`REL-RLY-ROL`	Relay ↔ Role	`implemented`	Relay actions inherit principal policy and capability snapshots.
`REL-RLY-SRV`	Relay ↔ Server	`implemented`	Relay registration and endpoints are scoped to the deployment.
`REL-RLY-TOL`	Relay ↔ Tool	`implemented`	Relay capability advertisement and proxy execution are current.
`REL-RMS-RMS`	Room ↔ Room	`implemented`	Parent Room, thread-root, Room-kind, and inherited Namespace behavior define the current Subthread relationship.
`REL-RMS-ROL`	Room ↔ Role	`implemented`	Room actions use resolved server policy and membership rather than per-Room roles.
`REL-RMS-SRV`	Room ↔ Server	`implemented`	Rooms are server-local current entities; cross-server/federated Rooms remain future scope.
`REL-RMS-TOL`	Room ↔ Tool	`implemented`	Room/session context participates in current tool availability and execution.
`REL-ROL-SRV`	Role ↔ Server	`implemented`	Roles are server-local, Groups carry them through the many-to-many `group_roles` join, and the canonical ladder is seeded per deployment.
`REL-ROL-TOL`	Role ↔ Tool	`implemented`	Tool authorization is indirect through `Role → Capability → Tool`; no direct Role-to-Tool join is required.
`REL-SRV-TOL`	Server ↔ Tool	`implemented`	Tool catalog, activation, policy, and runtime availability are deployment-scoped.