opbox

Glossary

The Opbox vocabulary - matter, party, gate, workspace, verb, autonomy, and the rest, in plain terms.

A plain-language dictionary of the words you meet across these docs. Each entry is a short definition, with a link to the fuller page when there is one. Skim it, or jump to a term.

The entries are grouped so that related ideas sit together: first the shape of the work (matter, step, document, party, and the rest), then the machinery (the kernel, verbs, the front door), then who can do what (tiers, autonomy, tokens, security), and finally a few technical words that recur. Within each group it is roughly alphabetical.

The shape of the work

These are the things a piece of work is actually made of. They are covered in full on The data model.

Matter. One unit of work with a beginning and an end: a case, a company incorporation, a visa application, an estate. It is the spine everything else hangs off, and it is also a privacy boundary - a confidential matter is only reachable by people allowed to see it. See The data model.

Matter step (step). One ordered thing that has to happen inside a matter - a single item in its workflow, like “Collect ID” or “Draft engagement letter”. At most one step is active at a time, so there is always a clear “what now”. See The data model.

Step type (step kind). The kind of a step, which carries a small typed shape describing what that step needs and produces. A FORM step knows it collects a form; a DOCUMENT step knows it produces a document; TASK is the plain fallback. New kinds are added as configuration, not new code. See The data model.

Board. The reusable template of phases and steps for a kind of work (“this is how we do an incorporation”). You author it once, publish a version, and every new matter of that kind is stamped out from that published version. See The data model.

Document. Structured rich text that Opbox owns and understands - a draft letter, a witness statement, a contract. It can be edited in place, versioned, generated from a template, rendered to PDF or DOCX, and tracked (redline). See The data model.

File. A binary blob Opbox holds intact - an uploaded PDF, a scanned passport, a signed agreement. Opbox keeps it safe (encrypted at rest) but does not treat it as editable text. In short: a document is something Opbox can rewrite; a file is something it holds whole. See Files & storage.

Party. Anyone or anything a matter is about - a client, the opposing side, a company, a director, a shareholder. One primitive with two kinds: a natural person or a legal entity. Sensitive identity details (passport numbers, KYC) live in a separate encrypted compartment. See The data model.

Form. A template that collects data - an intake questionnaire, an onboarding form. A filled-in form is a submission, and a submission can create a matter (the intake walks straight in as new work). See The data model.

Bill / invoice / charge. The money path. An invoice is a numbered billing document with line items; “paid” is computed from what was actually received, never set by hand. A charge mints a hosted pay-now link through a payment rail (Stripe and similar). All amounts are whole numbers of minor units (pence, cents), so totals are exact. See The data model.

Gate. A propose-then-approve checkpoint. Someone (or an agent) proposes a change; a human reviews it; only on approval is the change applied. Note that approved and applied are two separate, recorded facts. It is the single primitive behind every “needs sign-off” moment. See The data model.

Entity edge. A typed, directed link between two things - this file is attached to that matter, this party is linked to that matter. Rather than a different “link” mechanism per primitive, Opbox keeps one graph of edges, and you can only link things you are allowed to see. See The data model.

The machinery

How every one of the things above is actually stored and acted on.

Kernel. The single Rust binary at the centre of Opbox and its trust boundary - the one place the rules live. It is both the opbox command-line tool and the HTTP/MCP server. Nothing reaches the data except through it. See The kernel.

Verb. A single named action the kernel can perform - matter.create, file.put, gate.approve. Every capability in Opbox is a verb (roughly 400 of them), and every verb is permission-checked and audited before it runs. See The kernel and the full verb reference.

Front door / dispatch. The small, fixed set of routes that take a request into the kernel - chiefly POST /v/<verb>, which runs (“dispatches”) one verb. The command line, the web app, and the AI agent all come in through the same front door and run the same verbs; there is no second, hidden way in. See The kernel.

Render-schema. The contract that lets one verb output drive two views. Each verb returns its data plus a small “render descriptor”, and from that single instruction sheet the app produces both a compact chat card and a full GUI panel - so the chat and the screen can never tell you different stories. See The front end.

Render descriptor. The small instruction sheet that rides along with a verb’s output, saying how to display the data: which shape to use (record, table, timeline, doc, form, or cards), which fields are important enough for the small chat card, and which action buttons point at which verbs. It is what makes the render-schema work. See The front end.

Actor. Whoever is acting in the system right now - a human staff member or an AI agent. An actor holds a tier and an autonomy level, which together decide what they may do. See Security & permissions.

Workspace. The wall around a single client’s matters, documents, files, bills, and parties. One client lives in one workspace, and nothing inside one workspace can be seen from another. The wall is built into the database itself, not just the application. See Security & permissions.

Organisation. The layer above the workspace. An organisation can hold several workspaces (for example, a firm with more than one practice area, each walled off). Being in the organisation and being able to work inside a particular client’s workspace are two separate grants. See Security & permissions.

Tenant. One client on its own box. The substrate repository holds the substrate and the generic verticals; a client is a single tenant that instantiates a vertical with its own configuration and data on its own server (server-per-client). The tenant’s own data never enters the substrate repository.

Portal. The separate, hardened screen for clients (EXTERNAL tier). A client arrives with a link carrying a scoped token, and sees only what has been shared with them - nothing more. If they try to reach something not shared, they get the same flat “no” every time, with no hint about what exists. See The front end.

Audit log / hash chain. The append-only record of who did what, when, in which workspace. Every action writes exactly one line. The lines are hash-chained - each carries a fingerprint computed from the one before, like a wax seal across every two pages - so any later tampering breaks the chain and is detectable. See Security & permissions.

Who can do what

The locks that decide every act of seeing and doing. All covered on Security & permissions.

Tier. The level of standing a person or agent holds inside a workspace, on a ladder from least to most powerful: EXTERNAL (a client on the portal, the narrowest), MEMBER (everyday staff work), ADMIN (senior staff, money and oversight), and OWNER (the principal and trusted automation, the whole estate). Your tier must be at least the tier an action requires, or the action is refused. See Security & permissions.

Autonomy level (L0-L3). How much an AI agent may do on its own, a dial from 0 to 3: L0 read-only, L1 ordinary changes, L2 sensitive actions, L3 owner-equivalent (money and destruction). The level an agent actually gets is the lower of its own standing and the ceiling on the key it is using - power can only shrink as it passes down the chain. See Security & permissions.

Token (bearer token). The credential something presents to act in the system, like a key card. Every data verb needs one. A token is not an all-areas pass: it can be cut narrowly. See Security & permissions.

Capability scope. The narrowest fence on a token: a list of the exact verbs it is allowed to call, and nothing else. (A token can also be bound to one resource - a client’s portal link works only for that client’s portal, which is the anti-enumeration fence.) This is why least-privilege in Opbox is *tier + autonomy

RLS (row-level security). The Postgres feature that builds the workspace wall into the database itself. When a request comes in, the database is told it is acting for one workspace only, and from then on it physically refuses to return any row belonging to another - even a direct query that “forgot” to filter sees nothing across the fence. It fails closed: no workspace stamped means no data, never all data. See Security & permissions.

Sensitivity grade. The label on each file that decides who may read its actual bytes: NORMAL, SENSITIVE, CONFIDENTIAL, or RESTRICTED. A more sensitive file requires a more senior tier to open. Someone may be allowed to see a file’s name in a list without being allowed to open it. See Files & storage.

MFA step-up (second factor). The fresh re-proof a senior user must pass before money or destruction. Even an already-signed-in senior must re-prove themselves with their authenticator within a short window before the system lets the money move - a stale session is not enough. See Security & permissions.

Egress. Data leaving the box for the outside world. Egress is locked down and runs through a chokepoint, and an egress policy can cap, per outbound rail, the most sensitive grade of data allowed to leave (regulated data, never by default; the policy can only be tightened). See Security & permissions.

Fail closed. The principle under every lock above: when the system is unsure, it denies. An unrecognised action, a request with no clear identity, a connection with no workspace, a decryption that does not perfectly check out - each resolves to “no”, never to a best-effort “yes”. See Security & permissions.

Agents

MCP. The Model Context Protocol - the door (POST /mcp) the AI agent uses to call kernel verbs. It is the agent door; ordinary HTTP is the human door, and a human identity is denied over MCP. The agent gains no special powers: its only path to data is the same verbs a human would call. See Agents & MCP.

Caged agent. An AI agent run with its hands tied: no terminal, browser, web, file, or code-execution access, and egress locked. Its only tools are the kernel verbs over MCP. This is what makes it safe to use a commodity reasoning engine - the substrate stays owned while the engine is swappable. See Agents & MCP.

Vertical. A line of professional work (e.g. the visa vertical, the company-secretarial vertical) expressed as configuration - templates, knowledge, and a verb-pack - not as a gated product tier. The substrate provides every primitive to everyone; a vertical’s verbs are present if authored, never withheld behind an add-on flag.

A few technical words

Idempotent. A verb that you can safely call twice with the same effect as once. A retried request carrying the same Idempotency-Key returns the first call’s answer instead of running again - so a durable orchestrator can retry without double-doing anything. See The kernel.

Encryption at rest. The bytes of files and personal data are stored as unreadable ciphertext (AES-256-GCM), and each encrypted blob is bound to its own row and workspace, so a stolen blob pasted into a different record simply fails to decrypt. Tokens and passwords are kept only as one-way hashes. A stolen backup is not a breach of contents. See Security & permissions.

Submission. A filled-in form. It keeps an immutable snapshot of exactly what was sent, has its own short lifecycle (OPEN → REVIEWED → APPROVED/REJECTED), and can open a new matter. See The data model.

Provided primitive (solved primitive). One of the building blocks Opbox ships ready-made - matter, step, document, file, party, form, bill, gate, entity edge - so nobody rebuilds the same plumbing. Your effort goes into the specialist work on top; the data structure is the product. See The data model.

Where to go next