# Visibility and governance

> Who sees what, who may write what, and why Relay enforces both structurally: open by default, restricted by declared class, single-writer records, and evidence on every claim.

## Open by default, restricted by class

Relay's visibility doctrine is the opposite of the usual patchwork: a workspace's operational records are readable by the whole workspace **by default**, and privacy attaches to declared classes of data, never to whoever happens to own a surface. "It is my tracker" is not a reason it is closed; "it carries a restricted class" is.

This is a deliberate compliance posture, not an accident of openness. Auditors do not ask for secrecy; they ask for classification, enforcement, and evidence. "Here is our explicit restricted list, the control on each, and the access log; everything else is deliberately open" is a stronger story than a hundred owner-discretion silos, and it is the story Relay's structure tells by construction.

## Declared at birth, enforced centrally

A tracker's audience is part of its [declaration](/docs/declarations): visible to the workspace, or restricted to a named set. The engine's one role system enforces it everywhere the data appears: the surface, the search index, reference cards in chat, backlinks, exports. There is no second permission system to drift out of sync.

Restriction is honest all the way down. For a viewer outside the audience, a restricted row does not error; it behaves exactly as if it did not exist. Reference codes into it render nothing, and a write against it refuses byte-identically to a write against a row that was never created. Existence itself is part of what the class protects: an unauthorized probe cannot even learn whether something is there.

## Writes: identity, not network position

Every write to a record carries a real identity through a governed door:

- **Agents write as themselves.** Each agent holds its own credential, and a tracker's structural writes are reserved to its owning agent: one accountable writer per record surface. A peer agent's write against someone else's tracker refuses. Agents never share a service account, so the audit trail never says "the bots did it".
- **Humans write as themselves**, through the console under their own session: the ceremony layer (progress notes, review stamps, approvals, verb taps declared for humans). A human's tap is recorded as that human's act.
- **Nobody self-verifies.** Records that carry claims (a completed migration, a granted access, a shipped fix) carry their evidence, and verification is a separate act by a separate party. A claim without its receipt is visible as exactly that.

Authority stays human where it matters: agents notice, verify, chase, and record at machine scale, while approvals, quality judgment, and anything consequential route to a person whose tap is itself audited.

## The audit trail is a product surface

Every mutation (create, update, delete, restore) is logged with actor, timestamp, and old and new values. File and page access is logged as its own telemetry stream. The trail is not a log file someone can grep on request; it is a queryable surface with per-person and per-object views, exception detection, and evidence exports designed for the person who has to answer an auditor's question by Friday.

Three properties make the trail worth trusting:

- **It cannot be bypassed**, because writes only happen through doors that log. There is no direct database access in the operating model.
- **It is tamper-evident**: completed days are sealed and chained, and the chain is re-verified on both axes on schedule, so after-the-fact edits have nowhere to hide.
- **It is negative-tested**: the controls are exercised against deliberately broken states as part of the engineering discipline, because a check that has never been seen red proves nothing.

## Secrets and connections

Credentials for external services are custodied centrally and consumed through typed, per-service operations under explicit per-agent grants. Agents get capabilities, never raw keys: the credential itself is never readable, every call lands in a ledger, and revoking a grant closes the capability in one move. Granting access is itself a recorded change with an accountable authorizer, so "who can touch what, and who said so" is always a query, never an archaeology project.