opbox

Stand up a vertical

Turn the substrate into your practice - templates, step types, policies, and a verb-pack.

This is the recipe for turning the universal Opbox substrate into your practice - a visa shop, a corporate-services firm, whatever you run. The thing to hold onto before you start: a vertical is configuration, not a new product. You are not writing a new app or unlocking a paid tier. You are authoring content - templates, step types, policies, knowledge - that sits on top of the unchanged substrate. For the why behind that, read Building a vertical first; this page is the how.

There are two jobs, and they live in two different places:

  1. Author the generic vertical - once, as reusable configuration (the abstract “visa practice” or “CSP” shape). This can live in the shared repo so the next firm in that field starts from it.
  2. Instantiate it for a client - per firm, on their own box, with their own intake fields, people, and real data. That instance never travels back upstream.

Keep them apart the whole way through. Client config and real client data never enter the substrate repo - only the abstract, generic shape does, and only if you choose.

Before you start

You need:

  • A clear picture of how the practice’s work actually flows - the phases a matter goes through and the named steps inside each. Sketch it on paper first.
  • The substrate primitives in your head: matter, party, document, file, form, bill, gate, and the verbs that act on them. See the data model.
  • The discipline rule, stated plainly: map the practice’s documents onto the model; never jam the practice’s concepts into the product. Ask “how does this fit our existing matters, parties, gates?” - not “what new subsystem do I bolt on?” If the work genuinely needs a primitive the substrate lacks, that is a deliberate, governed change to the substrate, not a private hack on one box.

Honest status. The substrate primitives and the authoring verbs below are built and live (setup.*, steptype.*, policy.*, form.*, matter.*). The polished click-through authoring consoles - the Setup Authoring Console, the Policy Rule Engine UI - are v2-native surfaces that are still emerging. Today the dependable path is the verbs (over chat or CLI); the consoles are the friendlier face arriving over them. The guide below is written against the verbs.

1. Define the matter templates and step types

Start with the shape of the work. A matter template is the standard arc of a matter in the practice - its phases, in order, and the steps each phase contains. A step type is a named, typed kind of step, so a person or the AI assistant can read what a step is and what it needs without a prose description (see Structure over prose).

  1. List the phases. For a visa application that might be Intake -> Eligibility -> Preparation -> Filing -> Decision. For an incorporation: Engagement -> KYC -> Formation -> Post-incorporation -> Ongoing compliance.
  2. Register the step types the practice recognises, each with its typed shape. Use steptype.register - for example “collect passport and biometrics,” “confirm the immigration route,” “run KYC on each beneficial owner,” “file the incorporation.” A step with no special shape falls back to a plain TASK.
  3. Compose those step types into the template’s phases. The template is the reusable skeleton; an actual matter is one instance of it. See Matter Management for how a live matter runs the steps.

Authoring tip: the step-type registry and the template bundle are exactly the kind of generic, reusable content that belongs upstream. Keep them abstract - “collect identity documents,” not “collect Acme Ltd’s 2024 passport scan.”

2. Author the policies

Policies are the practice’s own rules layered over the universal security model. They do not gate features (nothing is gated for sale); they set who may act, what needs a second sign-off, and what a file’s sensitivity grade requires to open. See Security for the three dials - tier, autonomy, budget - that policies tune, and the Policy Rule Engine for the surface.

  1. Sensitivity. Grade the documents the practice handles. A visa firm’s identity documents are highly sensitive - author a policy so only senior staff can open them.
  2. Review / sign-off. Decide which actions need a second pair of eyes. A paid filing might require a senior tier and a fresh second factor and a budget before it submits - that is a policy, not a paywalled feature.
  3. Retention. Set how long each class of record is kept, matched to the practice’s regulatory floor.

Author these with policy.* verbs. Keep generic rules (“identity documents are SENSITIVE”) in the generic vertical; keep firm-specific thresholds with the client instance.

3. Add the knowledge - and a verb-pack only if needed

Knowledge is the reference material the AI assistant draws on for the field: the routes a visa firm handles and their documentary requirements, the jurisdictions a CSP forms companies in and what each filing needs, the current fees and timelines. Load it through the Knowledge Base so the assistant can retrieve it.

A verb-pack is the specialist actions a practice needs beyond the universal core - and most verticals need none. Reach for one only when the field genuinely deals in a verb the substrate does not already cover. The rule that makes this safe is worth stating: a verb is present only because someone authored it - present-iff-authored. It is not switched off behind a flag; an un-authored verb is absent, and the system’s default answer to any verb it does not recognise is a flat refusal. So you tailor a box by adding the specific verbs the practice needs, never by unlocking hidden ones.

A verb-pack that touches a trust boundary (anything SENSITIVE or above, any external tier, any new token or capability) is not a quiet authoring choice. Design it carefully and review it against the security model before you ship it.

4. Build the forms and boards

These are how people and matters actually flow into the configured practice.

  1. Intake forms. Build the forms that collect the practice’s structured information - personal details and travel history for a visa applicant, beneficial-ownership declarations for a company formation. Each field is typed, so answers come back validated and clean, and a submission can open a matter and hand it the data so the work starts already populated. See Forms & submissions.
  2. Boards. Set up the work-tracking board shaped for the practice - every live visa application by its phase, or every company through its lifecycle with statutory deadlines flagged. See Boards sync admin.

Forms and boards are projections over the same primitives, so the board reflects the real matter state from the single source of truth - never a stale parallel copy.

5. Instantiate on a client box and seed config

With the generic vertical authored, bring it to a client. Opbox runs a separate box for each client - their own server, database, and copy of the stack (server-per-client). There is no shared multi-tenant platform above everyone.

  1. Provision the box and found it. Run the founding ceremony so the fresh box has principals: the owner, the Chief of Staff, and the bounded chat-agent. See Genesis for the one-shot ceremony and The stack for the compose stack and its secrets.
  2. Install the generic vertical. Adopt the published vertical bundle onto the box with setup.adopt, then reconcile the live org from it with setup.apply. The Setup Authoring Console covers the define / publish / adopt / apply cycle.
  3. Tailor the instance. Add the firm’s own intake fields, branding, people, and the AI agents - each with the tier, autonomy, and budget they hold. Mint every additional principal in-app within the granted authority; never re-run Genesis.
  4. Bring in real matters. The firm’s actual matters, parties, and documents live on this box and only this box.

This instance is the client’s tenant. Its configuration and its real data stay there. Nothing about this firm flows back into the shared repository - the repo accumulates only better and better generic templates for the field.

What you have built

  • The practice’s work, expressed as templates and typed step types the substrate already understands.
  • The practice’s rules, as policies tuning tier / autonomy / budget - not as paywalled features.
  • The knowledge the assistant needs, and (only if the field demanded it) a small, authored, governed verb-pack.
  • Intake forms and a board that drive matters into the configured practice.
  • A client tenant on its own box, seeded from the generic vertical, holding its own config and data.

None of this was new code or an unlocked tier. It was configuration on top of the one substrate - which is the whole point. To go deeper, see Building a vertical, the data model, Security, and Genesis.