Documentation embedded in this build.
Glossary of resources
The console shows a dozen different kinds of record, and it is easy to lose track of which is which — a project looks like a list of groups, an obligation looks like a mission, a grant and a request are the same thing at two different moments. This page is one paragraph per term, alphabetically, so "what is this thing again?" has somewhere to land. Each entry links to where the console shows it and where the fuller story is told.
Attribute
A name and a value on a subject's own record — or carried directly in its certificate's DN — compared against a constraint: a minimum, a maximum, an exact match, a date bound, or a set membership test. A requirement's own attribute clause and a mission's restrictions are both written in this identical grammar, checked independently of each other. See Living with your certificate.
Authority
A deployment — this one, or an upstream — that owns a record and publishes what it knows in a signed bundle another deployment can adopt. A project or a mission names its owning authority; local means this deployment owns the record itself. See the authority lens on Deployment topology (/ui/topology?lens=authority).
Entity
A person, service, or device this deployment knows about: its own distinguished name (DN), its own attributes, and — for a person or service — a certificate it can present to authenticate. A group is an entity too (it can be a member of another group), but only a person or a service can present a certificate and be evaluated against a requirement. See Enrolling with AuthBox.
Goal
A question asked of a tree: it names a set of obligations and a project, and derives every number from the obligation reports beneath it. A goal computes nothing of its own — it grants nothing, refuses nothing, and suspends nobody — and it cannot disagree with an obligation's own page, because there is no second computation to disagree with. See How missions, obligations, and goals fit together and console /ui/goals.
Grant, and Request
A request is somebody asking for a mission they do not hold. It is decided by two parties, never one: an approver assigns a window, which creates a grant — the mission held for that window and nothing yet, because a grant authorizes nothing until the requester accepts it with their own key. "Request" and "grant" are two names for the same record at two different moments: unaccepted, and accepted. See Asking for access and console /ui/requests.
Group
An entity whose members are other entities — a person, a service, another group. A group can bind a mission (every direct member holds it, for as long as the membership lasts) and can be named directly in a requirement's group clause. Membership does not roll up: a member of a subgroup does not satisfy a clause naming the parent. Console: /ui/projects draws every group you can see as the tree it is.
Invitation
A single-use token that lets one holder enrol once, under the profile the invitation names. Shown when it is created and never again. Console: /ui/invitations.
Marking, and classification
The vocabulary that decides who may know a record exists at all — not only who may hold it. A record's marking is checked before it is ever named on a listing, a reverse index, or a denial: a mission, group, or entity you are not cleared for is not merely inaccessible, it is absent, indistinguishable from one that does not exist. See docs/plans/140.
Mission
A name for a need-to-know: the purpose a decision is made for. A mission carries its own validity window and its own restrictions (attribute constraints), and a subject holds one two ways — through a group that binds it, or through a direct grant — as a union of both, never a replacement of one by the other. See How policy and missions fit together and console /ui/missions.
Obligation
A question, never a second gate: "all members of this group must satisfy these clauses," declared so an auditor can ask who is out of compliance right now, before anybody bounces off a door. The clauses are asked as a requirement through the exact evaluator a real refusal goes through, so an obligation's report cannot disagree with enforcement. Its clauses are a copy of a mission's restrictions, never a link, so the cost is drift — see How missions, obligations, and goals fit together and console /ui/obligations.
Operation, and Requirement
An operation is one API call this deployment serves — a method and a path from a shipped OpenAPI document. It carries a requirement, the x-authbox block naming exactly what a caller must be or hold: an AND of up to four clauses (public, group, attribute, mission). An operation that declares no requirement denies everything; deny-by-default is not a fallback. See How policy and missions fit together and console /ui/policy.
Project
A group whose members are groups — no new kind of record, just a group used as an organizing root. A project's admins author the project's own missions and agreements, and a project's own subtree is what an admin's authority over it is scoped to. See Your project's own missions and console /ui/projects.
Stream
An authorized flow of receipts a front door says it is carrying, reported on the same bundle-fetch cadence it already makes — never measured live by the console itself. A door that stops fetching keeps its last report, marked unreported, rather than vanishing from the list. Console: /ui/streams.