Core concepts
The six objects
Everything Tether governs is one of six records. Both doors read and write the same six, which is what makes moving between them a change of surface rather than a migration.
| Object | What it is |
|---|---|
| Tenant | The customer. Owns the keys, the catalog, the policy and the ledger. |
| User | A person inside a tenant, identified by an id you control. |
| Role | A named set of approval rights within a tenant. |
| Capability | A registered tool: name, schema, is_write, risk, eligibility. |
| Action | One proposed write against one capability, with its arguments and preview. |
| Approval | One decision on one action: who, what role, which way, why, when, from where. |
No surface introduces a seventh. If something cannot be said with these, it is not modelled.
Why this matters to you
A tenant is a credential, never a request field. Scope comes from the API key. A body
carrying organizationId is accepted and ignored — see
Tenants and scope.
A user is asserted, not authenticated. Tether does not hold your people's passwords. You
say who is acting with X-Tether-User-Id, and Tether checks that assertion against the list of
users you registered before an approval is allowed to count.
A capability is declared, not discovered. Tether never introspects your systems. What you
register is the entire universe of what it can call, and is_write is part of the declaration
— never inferred from a name, a verb or an annotation.
An action is the unit of consequence. Every write becomes one, with arguments a person can read before agreeing to them. Nothing reaches your endpoint until an approval exists.
An approval is a record, not a permission check. Both outcomes are written down — someone attempting to approve what they may not is exactly the event worth keeping.
Related
- Tenants and scope
- Tools — the capability, as registered
- Staged writes — the action, through its life