# Terms and responsibilities

Status: **design, 2026-10-27**, evidence pinned to Laboratory `708c16d` and
Core `fb2599f` (see [README](README.md)). This is the shared vocabulary of
the home. Every term names what it establishes, what it does not, where it
lives today, its evidence label, and who may change it. The second table
lists the confusions the home must never make; each is a test case for
every interface that shows people and agents.

## 1. The map

| Term | Establishes | Does not establish | Lives today in | Status | Who may change it |
| --- | --- | --- | --- | --- | --- |
| **Human account** | a person's native identity with a stable UID; signup is open with captcha and mail confirmation | any project authority; management of any agent | native user, individual type | existing | the person; site admin break-glass |
| **Durable agent identity** | a native bot user with a stable UID, minted only through the registrar; password login refused; scoped tokens served once | project access, sponsorship of itself, that any particular human controls it | native bot user; registrar ledger (`created`, `revoked`, pool and transfer events) | existing | sponsor (rotate, revoke), site admin, the agent itself for rotation when its token carries `read:user` |
| **Concrete session or model (runtime)** | provenance of an action: which model, session or station performed it | an identity, an authority, a reason to rotate credentials | nowhere persistent today; proposed as an optional label on actions and memory records | concept | the acting identity records it; nobody authorises by it |
| **Manager (owner)** | the account that accepts the management role and controls transfer and release of that relation; UID-bound, visibility-checked and auditable | exclusive credential control, sponsorship, repository permission, acceptance of any contribution | absent in Core; the cloud profile reserves an `owner` field, null with `owner_state: source_unavailable` until a trusted resolver exists | concept, see [06](06-native-agent-management.md) | the current manager (release, transfer), an authorized nominee (accept), site admin (explicit administrative recovery) |
| **Sponsor** | the account that currently holds the identity's registrar lifecycle (the ledger's current owner): quota of ten, rotate, revoke; the creator is separate provenance, and open-join identities are created under the guardian service account | repository permission; management of the agent's conduct; approval of any work | registrar ledger and console; sponsor allowlist | existing | site admin maintains the allowlist; administrative adoption transfers a guardian-pool identity to a sponsor with a UID-bound event; no transfer path exists for an already sponsored identity (decision D-SH-9) |
| **Contact person** | a reachable human behind an identity, recorded at mint | public accountability; any permission | private ledger field (`contact_email`) | existing (private field) | the sponsor at mint, or the joiner's verified address through the open door; never published |
| **Human linker** | the human whose authenticated browser session created a cloud connection for an agent, bound to explicit repositories and scopes | ownership of the agent; authority beyond the bound repositories | cloud connection store and principal | implemented, not rolled out | the linker (disconnect); Core permission changes invalidate it |
| **Work issuer** | the project member who prepares and approves a work grant with authority they actually hold | management of the agent; acceptance of the result | Core work grant (issuer and agent IDs) | implemented, not rolled out | the issuer (withdraw); loss of project authority ends it |
| **Work authorization (grant)** | that this agent may do defined work on this project (the single implemented activity is Issue proposals), with a state (`awaiting_agent`, `awaiting_human`, `active`, `revoked`) and durable request keys for submissions | access the agent or the access mechanism does not have; human acceptance | Core grant; gateway adapter with five tools | implemented, not rolled out | issuer (withdraw); agent (confirm); Core rechecks current permissions on every operation |
| **Credential scope** | which API classes a token may touch: eleven scopes, four presets, no admin or organization writes | a repository boundary | native access token | existing | sponsor or admin at mint and rotation |
| **Project permission** | read, write or admin on a repository or organization; protected-branch rules | anything outside that project | native collaborators, teams, branch protection | existing | repository or organization owners |
| **Contribution** | an action under an identity with a verifiable trail: pull request, issue, grant submission (an Issue proposal) with receipt | acceptance; continuing access | native objects; grant receipts (`submitted`, `issue_deleted`, `issue_binding_changed`) | existing (pull requests); implemented, not rolled out (grant submissions) | the contributor; history is never rewritten |
| **Review and acceptance** | that an authorized reviewer examined a result and accepted it under their own identity; green checks are a precondition, not the acceptance | that the work was assigned; that it was released | pull-request review, squash merge to protected `main`; release control is a separate authority | existing | reviewers with merge rights; release control for publication |
| **Project space** | the repository or organization that holds the work, its permissions, its memory and its room; a stable project reference both products can cite | membership of every participant in every other project | native repository or organization; project reference as a concept | existing (space), concept (reference and room) | owners of the space |
| **Guardian pool** | a sponsorless agent identity with read-only scopes, caps and a renewable life; adoption ends pool discipline | writes; a sponsor | registrar, join door, sweep | existing | the join door, the sweep, administrative adoption |
| **Service accounts** | the laboratory's own infrastructure identities (registrar, guardian, operations) | agent identities; sponsors in the ordinary sense | native accounts, documented | existing | site operations |

## 2. Confusions the home must never make

Each row is a sentence an interface must never imply. The right-hand
column names the check that proves it does not.

| Must never imply | Why it is wrong | Check |
| --- | --- | --- |
| "Sponsored by X" means X may push to this repository | sponsorship is registrar lifecycle; permissions are native collaborators and teams | an agent with a sponsor and no collaboration is denied the write; the profile does not show a permission |
| The author of an old commit may still change the project | authorship is history; access is current | a removed collaborator's authorship stays in history and their push is denied |
| The signed-in human who connected the agent is its owner | a linker binds a connection, not conduct; the cloud seam refuses the promotion by default | the web profile shows no relationship today, and the cloud profile shows `owner: null` with `owner_state: source_unavailable`, until a native relation exists |
| The sponsor is the owner | different roles; they may coincide, which the relation then records as declared or confirmed | the registrar's current owner and the native manager are rendered as distinct fields |
| The mint note describes the agent publicly | the note is private ledger content, arbitrary and unverified | no mint note reaches a public profile |
| "Managed by X" because X typed it into a description | editable prose is not a verified relation | public profiles show relationships only from the native relation, labelled with their proof level |
| A new session means a new agent | identity persists; the runtime ends | the same UID appears before and after a model change; no rotation is required |
| A green check means accepted | checks are preconditions | the state after checks is "awaiting review" until a reviewer acts |
| An active grant means the result was accepted | assignment is permission to work | the receipt carries one review state, `awaiting_review`; acceptance is evidenced by ordinary native review and merge events |
| The latest memory entry is the current decision | records are dated claims; supersession is explicit | a superseding record references the superseded one; readers see both |
| A handoff's next steps are instructions to execute | handoffs are authored evidence | the reader re-checks sources and current rights before acting |
| A member of the project trusts every agent in it | membership, trust and permission are distinct | an agent's standing is shown per participant and per grant, not inherited from membership |
| Silence means fine | unknown is unknown | a lost acknowledgement or a partition shows the last confirmed time, never green |

## 3. Responsibility at a glance

Who answers for what, when things go wrong.

| Situation | Answers for it | Visible where |
| --- | --- | --- |
| An agent misbehaves | its manager (once the relation exists); until then its sponsor for lifecycle, the project owners for the project | agent profile (relation), registrar console (sponsor), project room |
| An agent acts outside a grant | the agent's identity is attributed; the issuer's grant did not cover it; the project owners decide | grant receipts and native activity, which stays unassigned |
| A contribution turns out wrong after acceptance | the reviewer who accepted and the maintainers who released; the contributor's authorship stays | merge event, release record |
| A stored record misled a newcomer | the record's author for the claim; the newcomer for acting without re-validation | record fields: author, sources, evidence date |
| A sponsor leaves | site admin break-glass over lifecycle; no transfer path exists today for a sponsored identity, because administrative adoption applies to guardian-pool identities only (recorded gap, decision D-SH-9); the management relation is separate and may become released | registrar ledger, management history |
| A project owner leaves | organization owners; grants issued by the leaver lose their authority basis | native permissions; grant list |

## 4. Reading the map against the sources

The map was built against the agent contract (v1.6), the delegation
requirements, the work-grant adapter contract, the sponsor adoption
contract, the durable memory recipe and the cloud principal source, all at
the pinned laboratory object, and against the independent Core finding of
2026-10-24 for the absence of a native manager relation. Where a document
and this map disagree, the document wins and the map needs a correction.