opbox

An addon is a specialist line of work bolted onto the universal substrate: billing and invoicing, the equity cap table, the corporate-services pack, the performing-arts visa pack, ESOP, accounting. Each one is a verb-pack plus the configuration that surrounds it. The thing that makes Opbox different is what an addon is not: it is not a premium feature held behind a paywall and switched off until you pay. Every primitive is present on every box. A specialist capability is present on your box only because it was authored for your practice, and absent everywhere it was not. Presence, never permission.

What it does

A vertical is configuration, not a separate product. There is no “billing edition” or “visa edition” of Opbox. There is one substrate, and a practice is that substrate configured for its work: matter templates, step-types, a verb-pack, policies, knowledge, forms, and boards, all authored on top of the unchanged engine. Two practices on two boxes share the exact same kernel and differ only in this configuration layer. See Building a vertical for the full account.

Specialist verbs sit in the Vertical tier. Every verb sits in one of four tiers, and the Vertical tier is exactly the addon surface: the actions that belong to a specialist line of work and are present only when that work has been set up. The largest addon is equity, a full cap-table and share-register engine. Billing is the next: invoices, payments, credit notes, refunds, themes, and accounting sync. These are powerful, domain-specific actions, not the everyday create-get-list verbs. They are offered to the AI assistant only on the boxes where the line of work exists.

Absent, not denied. The system’s default answer to any verb it does not recognise is a flat refusal (INV-11). So you do not tailor a box by removing features behind locks; you tailor it by adding the specific things a practice needs. An addon that was never authored for this box does not exist as a verb here, which is why there is no flag to flip on by accident and no hidden second system to discover. Removing feature-gating took nothing away from safety, because tiers, autonomy, and budgets are what keep a sensitive action protected, not a tier of the product you did not buy.

Billing as a worked example. The bill.* pack is a self-contained addon. It raises invoices and drives them through a code-enforced lifecycle (draft, submitted, authorised, paid, partially paid, voided, overdue), records payments, issues credit notes and refunds, holds the firm’s branding themes and defaults (base currency, number prefix, due days), and reconciles against an external ledger such as Xero or Stripe. Money is held throughout as exact integer minor-units, never floating-point cents, and a sensitive transition mis-states a regulated financial record, so it is gated accordingly. A lighter charge.* family records billable charges in the everyday Core flow even where the full billing addon is not installed.

Each addon carries its own audited verbs. Whatever the addon, every action in it is a named kernel verb that passes through the one front door: permission-checked, scope-checked, and audited before it runs. An equity transfer, a billing refund, and a matter advance are governed identically. The addon does not get a side door of its own.

How you use it

Author the generic vertical once. Map a field’s work onto the existing primitives, then write the configuration: the matter templates and phases, the step-types and their shapes, any specialist verb-pack the field genuinely needs, the policies, and the knowledge the assistant draws on. This is content authoring, not feature engineering. The result is a reusable vertical the next firm in that field can start from. See the Setup Authoring Console for the authoring surface.

Publish and adopt the pack onto a box. A vertical setup is defined as a bundle, published as a pinned version, and adopted onto a tenant’s box. Adoption is the consume side of publishing: it installs the bundle and reconciles the live org from the manifest’s pinned versions, so the box gains exactly the verbs and configuration the bundle declares and nothing more.

Use the addon’s verbs like any other. Once the pack is present, its verbs are the same shape as the rest: drive them by chat, from the screens, or on the command line. Raise an invoice and move it through its lifecycle, record a payment, issue a refund, set the firm’s billing defaults, or read the cap table and model a round. The assistant can reach the Vertical-tier verbs on the boxes where the line of work exists, bounded by its autonomy and grant.

Retire a pack without losing the record. Withdraw a bundle from new adoption by archiving it, reversible only by publishing a new version. Existing records stay immutable: an archived billing theme is withdrawn from new selection while every invoice keeps its pinned theme, and nothing is ever deleted out from under a record that already references it.

The kernel verbs behind it

Each goes through the kernel’s one front door, permission-checked and audited before it executes. These are the verbs most specific to the billing addon, plus the lifecycle verbs that install and retire a pack.

The billing pack:

Installing and retiring a pack:

  • setup.define - draft a vertical-setup bundle.
  • setup.publish - publish a pinned bundle version that boxes can adopt.
  • setup.adopt - install a published catalogue bundle onto this tenant’s box.
  • setup.apply - reconcile the live org from the manifest’s pinned versions.
  • setup.archive - withdraw a bundle from new adoption (reversible only via a new version).

A representative second pack (equity):

See the full sets in the billing, setup, and equity verb references.