Capabilities

This page is the plain-language tour of everything Opbox can do. Each capability is an action the system calls a verb (a short name like matter.create or doc.generate). The verbs are the real, user-facing actions: the chat assistant calls them, the buttons in the app call them, and the command line calls them. They are the vocabulary of the product.

There are ~360 verbs in all, organised into roughly 40 areas. That sounds like a lot, but most of them are the ordinary verbs you would expect of any area: create, get, list, edit, archive. The sections below group them by area and explain, in plain words, what each area is for and what you can do with it.

The two rules that apply to everything

Two things are true of every single verb, with no exceptions:

1. One front door. Whether the action comes from you typing in chat, clicking in the app, or a script on the command line, it goes through the exact same single entrance and the exact same checks. Nothing gets a side door. See the kernel.
2. Checked and recorded. Before anything happens, the system checks who is asking and whether they are allowed, and then it writes a permanent, tamper-evident record of what was done. Nothing happens silently and nothing happens unchecked. See security.

Tiers: which verbs are on hand, and which are off-limits to the AI

Every verb sits in one of four tiers. This is about what is offered to the AI assistant by default, not about hiding features from people.

• Core (~68 verbs) — the everyday actions, always available to the assistant. This is what opbox list shows.
• OnDemand (~57 verbs) — less common actions the assistant can pull in when a task actually needs them.
• Vertical (~80 verbs) — actions that belong to a specialist line of work (billing, share registers). They are present only when that line of work has been set up.
• AdminOnly (~153 verbs) — sensitive administration and infrastructure actions. These are never offered to the AI. A human operator runs them through the command line or the admin interface, and even then the permission check still applies.

So when you read “AdminOnly” below, it means: real, working capability, reachable by an authorised person, but deliberately kept out of the assistant’s hands.

Matters — the unit of work

A matter is one piece of work for one client: a visa application, a company formation, a dispute. It moves through steps on a defined path, and it can have sub-matters for work that branches off. Matters are the spine that everything else hangs on.

What you can do

• Open a new matter on a chosen workflow, and check its current state.
• Move it forward a step, jump to a specific step, or skip / reopen / reject a step.
• Put a matter on hold, have it wait for something, cancel it, or hand a slice of it to someone with controlled access.
• Spawn a child matter for a side-thread of work.

Key verbs

• matter.create — start a new matter · matter.get / matter.list — look one up, or see them all
• matter.advance — move to the next step · matter.goto — jump to a named step
• matter.hold / matter.cancel / matter.await — pause, stop, or wait
• matter.spawn — branch off a sub-matter · matter.attach — attach something to a matter · matter.share — give someone scoped access
• step.activate / step.list / step.skip / step.reopen / step.reject — manage the individual steps

The board — seeing the work

The board is the human-facing view of the matters: a live, kanban-style picture of what is where. It is generated from the matters themselves, so it always reflects reality rather than a copy that drifts.

What you can do

• Create and edit a board, choose what it shows, and publish it.
• Set the rule that decides when a card moves between columns.
• Refresh or stop the board’s projection, and (where an external issue tracker is linked) sync the two.

Key verbs

• board.create / board.edit / board.get / board.list / board.publish — the basics
• board.step.condition.set — define when cards advance · board.regenerate / board.stop-projecting — rebuild or detach the live view
• board.issue.sync / board.sync.status — keep an external tracker in step (admin-side plumbing for the inbound webhook lives here too)

Documents & files — drafting, rendering, storing

Two related areas. Documents are the things you draft, generate from templates, and have signed. Files are the stored bytes (uploads, exports, scans) with retention and sensitivity controls. Templates let a document be produced from a matter’s data rather than typed by hand.

What you can do with documents

• Draft a document, generate one from a template filled with a matter’s facts, and render it to PDF.
• Pull data back out of a document, share it, and accept or reject tracked changes.
• Register, version, and publish the templates that documents are generated from.

What you can do with files

• Upload a file and fetch it back, export a rendered copy.
• Mark a file’s sensitivity, put a legal hold on it, set retention, and let the system sweep out files that are past their keep-by date.

Key document verbs

• doc.create / doc.get / doc.list / doc.edit — the basics · doc.generate — produce one from a template · doc.render — turn it into a finished PDF · render.export — export a rendered copy
• doc.share — share it · doc.annotate — add notes · doc.track.accept / doc.track.reject — resolve tracked changes (admin-side) · doc.extract — read data out (admin-side)
• doc.template.register / doc.template.publish / doc.template.list — manage the templates · acroform.fill / bundle.compile — fill a PDF form and bundle documents (admin-side)

Key file verbs

• file.put — store a file · file.get / file.list — fetch / browse
• file.setSensitivity / file.hold / file.releaseLegalHold — sensitivity and legal hold · file.policy.setRetention / file.retain.sweep — retention rules and the clean-up sweep (admin-side)

Parties — the people and companies

A party is anyone or anything a matter involves: a client, a counterparty, a company, a regulator. The area also handles the relationships between them and the “know your client” checks.

What you can do

• Add a person or company, look them up, and keep their details current.
• See and manage how parties relate to one another.
• Run a KYC review, build a richer profile, and (for admins) merge duplicates or suspend a party.

Key verbs

• party.create / party.get / party.list / party.update — the basics
• party.relationship.list — see who relates to whom · party.kyc.review — run a know-your-client check · party.profile / party.facet.set — enrich the record
• party.merge / party.suspend / party.archive — clean up and lifecycle (admin-side)

Billing — money in and out

The billing area produces invoices, records payments, issues credit notes and refunds, and keeps themes (the look of an invoice) and defaults. It is a specialist area, present when a tenant does billing. A separate, smaller charge family records billable charges in the everyday Core flow.

What you can do

• Raise an invoice, fetch it, list invoices, and move one through its lifecycle (draft, sent, paid).
• Record a payment, issue a credit note or a refund, and sync with the accounting system.
• Manage invoice themes and your billing defaults.
• In the everyday flow, register a billable charge and list charges on a matter.

Key verbs

• bill.invoice / bill.invoice.get / bill.invoice.list / bill.invoice.transition — the invoice lifecycle · bill.payment.record — log a payment · bill.creditnote / bill.refund — adjustments
• bill.sync — reconcile with accounting · bill.theme.upsert / bill.defaults.set — appearance and defaults
• charge.register / charge.list — the lightweight, always-on charge capture
• cost.record / cost.query / cost.budget.check — internal cost tracking and budget guard-rails

Forms — collecting structured input

Forms are how structured information is gathered from a person and turned into facts the matter can use. The form is generated, the person fills it in, and the answers are ingested.

What you can do

• Generate a form for a matter or step.
• Take in a completed submission and fold the answers into the matter.
• Look back at what was submitted.

Key verbs

• form.generate — produce a form · form.ingest — take in a completed one
• submission.get / submission.list — review what came back · capture.list / capture.ingest — the broader capture intake

Facts, search & knowledge — what the matter knows

These three areas hold and surface knowledge. Facts are the structured truths about a matter (a name, a date, a number) — one source of truth that documents and forms both read from. Search finds things across everything. Knowledge is the reusable, reviewed know-how (guidance, precedents) the assistant can draw on.

What you can do

• Set a fact on a matter, list the facts, and resolve the current value of one.
• Search across matters, documents, and parties.
• Look up a piece of knowledge, list what is available, and (with review) propose, publish, or retire knowledge entries.

Key verbs

• fact.set / fact.list / fact.resolve — the single source of truth per fact
• search.query — find anything · knowledge.get / knowledge.list — read the know-how · knowledge.publish / knowledge.propose / knowledge.retire — curate it (publishing and curation are gated)

Conversation & inbox — talking and being told

The conversation area is the chat threads attached to work; the inbox and notify areas are how people are told something needs them.

What you can do

• Start a conversation, post to it, read it back, and archive it.
• Read your inbox, list items, and mark them done.
• Send a notification and see the catalogue of notification types.

Key verbs

• conversation.create / conversation.post / conversation.get / conversation.list / conversation.archive — the threads
• inbox.get / inbox.list / inbox.mark — your inbox · notify.send / notify.taxonomy — outbound notices

Signing & envelopes — getting things signed

An envelope is a document (or set of documents) sent out to be signed by named recipients. The signing area covers the e-signature flow and the tamper-evident chain that proves who signed what.

What you can do

• Create an envelope, look it up, list envelopes, and sign one.
• (Admin-side) place signature fields, set recipients, send, remind, void, or handle a decline and the provider’s callback.
• Verify the signing chain to prove the signatures are intact.

Key verbs

• envelope.create / envelope.get / envelope.list / envelope.sign — the everyday flow
• envelope.send / envelope.remind / envelope.void / envelope.field.place / envelope.recipient.set — orchestration (admin-side)
• signing.chain.verify — prove the signatures have not been tampered with

Portal — the client-facing window

The portal is the hardened, outside-world surface a client logs into to see their matter, exchange messages, complete tasks, and access shared items, without ever touching the internals.

What you can do

• Create a portal, share it, set what is visible, and manage who can reach it via links.
• Attach items to it, post messages, and assign or complete tasks for the client.
• Start a portal session and walk (traverse) what the client is allowed to see.

Key verbs

• portal.create / portal.get / portal.list / portal.share / portal.set-visibility — set one up
• portal.message.post / portal.task.assign / portal.task.complete — client interaction · portal.object.attach / portal.object.list — what is shared
• portal.session.start / portal.traverse — the client’s view · portal.link.add / portal.link.revoke — access links

Reviews & gates — human checks in the loop

These two areas are the brakes. A review is a human-in-the-loop checkpoint someone must clear; a gate is a proposed change held until it is approved or reverted. Together they make sure the important things get a human’s eyes.

What you can do

• Claim a review, work it, and resolve it; see the queue and set the policy that decides when a review is required.
• Propose a gated change, apply it, get it, list gates, and revert one.

Key verbs

• review.claim / review.resolve / review.list — work the queue · review.policy.set / review.policy.get — when reviews fire
• gate.propose / gate.apply / gate.revert / gate.get / gate.list — held changes and their resolution

Agents & the org — the AI workforce and its chain of command

Opbox runs AI agents under a real org chart with a chief-of-staff at the top. The agent area convenes and runs them; the org and team areas define the roster, who reports to whom, and what each is allowed to do. Crucially, an agent’s power is bounded by an autonomy level and a grant (a per-agent allow-list), not by trust. agenttask is the work-queue the agents pull from.

What you can do

• Convene an agent or a panel of agents for a task, set an agent’s autonomy and its grant, and attach a skill.
• (Admin-side) create an agent in the org, move it in the chart, promote, disable, or remove it.
• Set org membership, freeze or lock down the org in an incident, and read the org’s audit feed.
• Manage the task queue the agents work from.

Key verbs

• agent.convene / agent.convene.panel — bring agents to a task · agent.autonomy.set / agent.grant.set — bound their power · agent.skill.attach — give them a capability
• org.agent.create / org.agent.move / org.agent.promote — the roster (admin-side) · org.membership.set / org.freeze / org.lockdown — membership and incident controls (admin-side)
• team.create / team.member.add — teams · agenttask.create / agenttask.claimNext / agenttask.escalate — the agent work-queue (mostly admin-side)

Runs & triggers — automation that fires on its own

A run is one execution of an automated flow; a trigger is the rule that starts work on a schedule or in response to an event. This is how the system does things without someone clicking.

What you can do

• Start a run, check its status, and cancel, retry, or resume it.
• Create and test a trigger, enable or disable it, and list what is wired up.

Key verbs

• run.start / run.status / run.list / run.cancel / run.retry / run.resume — manage executions
• trigger.upsert / trigger.test / trigger.enable / trigger.disable / trigger.list — schedule and event rules · flow.event.poll / webhook.ingest — the event plumbing (admin-side)

Policy & audit — the permanent record

Policy defines the rules that decide what is allowed; audit is the permanent, tamper-evident record of everything that happened. Together they are how the rules of the house are applied consistently and provably.

What you can do

• Evaluate, read, and (with publishing rights) author the policies that decide what is allowed.
• Query and follow the audit feed, and verify the audit chain is intact.

Key verbs

• policy.evaluate / policy.get / policy.list — apply and read the rules · policy.create / policy.publish — author them (admin-side)
• audit.query / audit.feed / audit.chain.verify — inspect and prove the permanent record

Identity, access & sessions — who is who, and what they can touch

These areas decide who is acting and what they may reach. Actors are the people and agents; sessions and tokens are how they are authenticated; auth, mfa, and credentials secure the sign-in; acl and workspace.access grant fine-grained reach. Preferences round it out.

What you can do

• See your session, switch workspace, set your avatar and preferences.
• Enrol and verify multi-factor authentication, and set credentials.
• (Admin-side) invite, deactivate, or set the role of an actor; mint, list, and revoke tokens; grant or revoke access to specific things.

Key verbs

• session.get / session.workspace.switch — your session · actor.avatar.set / pref.set / pref.get — personalise · mfa.enroll / mfa.verify / auth.credentials.set — sign-in security
• actor.invite / actor.setRole / actor.deactivate — manage people (admin-side) · token.mint / token.revoke / token.list — bearer tokens · acl.grant / acl.revoke / workspace.access.grant — fine-grained access

Data tables — the spreadsheet-style store

Alongside matters, Opbox has a structured tables store (tables, columns, rows, cells) for list-shaped data, with import tooling. Most of these editing actions are admin-side, with read access available on demand.

What you can do

• Create and shape a table, add and retype columns, and hide or reorder them.
• Add, patch, list, and bulk-load rows; set or lock individual cells.
• Preview an import and then commit it.

Key verbs

• table.create / table.list / column.add / column.retype — shape the table (admin-side) · column.hide — adjust the view
• row.create / row.patch / row.list / row.bulk — the data (admin-side) · cell.set / cell.lock — individual cells · import.preview / import.commit — bring data in

Specialist verticals — equity and share registers

A vertical is a specialist line of work that ships as a verb-pack and is present only when set up. The largest is equity: a full cap-table and share-register engine (grants, vesting, pools, rounds, conversions, and an Open Cap Table import/export). These are powerful, domain-specific actions, not everyday verbs.

What you can do (equity)

• Maintain a cap table: issue and transfer shares, set authorised capital, reclassify, subdivide, and consolidate.
• Run a grants and vesting programme: create, lapse, terminate, exercise grants; schedule and materialise vesting; manage option pools.
• Model financing rounds and conversions, and import or export the register in the Open Cap Table standard.

Key verbs

• equity.captable.get / equity.transfer / equity.grant.create / equity.vesting.schedule — the core register and grants
• equity.pool.create / equity.round.model / equity.convert — pools, rounds, conversions · equity.ocf.import / equity.ocf.export — the Open Cap Table interchange

Operations & infrastructure — running the box

Behind the product sits the machinery that runs a tenant’s box: provisioning, backups, disaster recovery, connections to outside systems, secrets, and host health. Nearly all of this is AdminOnly — real, working capability, run by an operator, never offered to the AI.

What you can do (operator-side)

• Deploy, suspend, resume, upgrade, back up, and restore a tenant.
• Define and apply a setup blueprint, export and import it, and roll it back.
• Create and test connections to outside systems, rotate secrets and credentials, and check host health and disaster-recovery status.

Key verbs

• tenant.deploy / tenant.backup / tenant.restore / tenant.upgrade — run the box · setup.define / setup.apply / setup.rollback — setup blueprints
• connection.create / connection.check — outside systems · credential.rotate / secret.rotate — secret hygiene · host.doctor / dr.status / system.health — health and recovery

In short

The point of all this is that the capability is the verb, and the verb is the same everywhere. There is no hidden second system: the chat assistant, the app, and the command line all reach for the same ~360 named actions, every one of them checked against who is asking and written into a permanent record. The everyday ones are on hand; the sensitive ones are kept for authorised people and out of the AI’s reach. See the kernel and security for how that single front door and its checks work.