If you run a visa practice, you do not work the way a corporate-services firm works. Your matters are different, your documents are different, your filings are different, your deadlines are different. So the obvious question, when you look at a product like Opbox, is: is this built for my niche, or for someone else’s?
The answer Opbox gives is unusual, and it is the single idea that makes the whole thing different:
A vertical is configuration, not a different product. There is no “visa edition” and no “corporate-services edition” of Opbox. There is one substrate, and a visa practice or a corporate-services shop is that same substrate configured for the work. Nothing is a separate build, a separate code fork, or a paid-for tier you have to unlock.
This page explains what that means in plain terms, and why it matters when you are deciding whether to adopt Opbox for your own field.
The substrate gives you everything, up front
Underneath every Opbox is the same substrate: a small set of solved building blocks and the actions you can take on them. The building blocks are the things every professional-services firm actually deals in - a matter (one piece of work), a party (a person or company involved), a document, a file, a form, a bill, and a gate (a checkpoint that has to be cleared). The actions are the verbs you run against them: open a matter, advance it, draft a document, record a payment, clear a gate, and so on. See the data model for the full set.
The important part is that every primitive and every verb is present on every box. None of it is held back. There is no premium plumbing, no “matters are in the base plan but billing is an add-on,” no feature you discover you have to buy. The substrate is universal by design.
So if there is no paywall, what stops one firm’s box from doing things it has no business doing? The answer is simple and worth holding onto: a capability that a particular practice needs is present only because someone authored it for that practice. It is not switched off behind a flag - it is absent. The system’s default answer to any verb it does not recognise is a flat refusal. So the way you tailor a box is not by removing things behind locks; it is by adding the specific things that practice needs. Presence, never permission.
A “vertical” is the configuration layer on top
A vertical is the bundle of configuration that turns the universal substrate into a working version of a specific practice. It is made of a handful of pieces, all of them authored, not coded:
- Templates - the standard shape of a matter in that practice. What phases a piece of work goes through, what steps each phase contains, in what order.
- Step-types - the named kinds of step that practice deals in, each carrying a typed shape so a person or the AI assistant can read what it is and what it needs.
- A verb-pack - any specialist actions that practice needs beyond the universal core.
- Policies - the practice’s own rules: who may do what, what needs a second sign-off, what a file’s sensitivity grade requires to open.
- Knowledge - the reference material and instructions the AI assistant draws on for that field.
- Forms and boards - the intake forms and the work-tracking boards shaped for that practice.
None of this is a code change to Opbox. It is content placed on top of the unchanged substrate. Two practices running on two boxes share the exact same engine; they differ only in this configuration layer.
Example: a visa practice
For an immigration firm, the visa vertical would configure things like:
- A matter template for an application: an Intake phase (gather the client’s details and documents), an Eligibility phase (check the route and the requirements), a Preparation phase (assemble and draft the application), a Filing phase, and a Decision phase.
- Step-types the practice recognises: “collect passport and biometrics,” “confirm the immigration route,” “draft the cover letter,” “submit to the authority,” “record the decision.”
- Knowledge for the AI assistant: the routes the firm handles, the documentary requirements for each, the current fees and timelines.
- Forms for client intake (personal details, travel history, supporting documents) and a board that tracks every live application by its phase.
- Policies matched to the work - for instance, treating a client’s identity documents as highly sensitive files that only senior staff can open.
Example: a corporate-services practice (a CSP)
For a firm doing company formation, secretarial work, and ongoing compliance, the CSP vertical would configure a different shape over the same primitives:
- A matter template for an incorporation: Engagement, Due diligence / KYC, Formation, Post-incorporation (registers, share issues), and Ongoing compliance.
- Step-types like “run KYC on each beneficial owner,” “reserve the company name,” “file the incorporation,” “issue the share certificates,” “prepare the annual return.”
- Knowledge about the jurisdictions the firm forms companies in and what each filing requires.
- Forms for engagement and beneficial-ownership declarations, and a board that tracks each company through its lifecycle and flags upcoming statutory deadlines.
- Policies suited to the work - for example, requiring a second-factor step-up before a filing that costs money is submitted.
Notice what is the same across both. Both are “matters” with “phases” and “steps.” Both have “parties,” produce “documents,” collect “forms,” and raise “bills.” Both run the AI assistant over the same verbs. The substrate did not change. Only the configuration on top did.
One client is one tenant on one box
Opbox runs a separate box for each client - their own server, their own database, their own copy of the stack. There is no shared multi-tenant platform sitting above everyone. (For why, see deployment.)
That has a direct consequence for verticals, and it is the most important thing to understand about how your data is treated:
Your firm’s configuration, and every byte of your real client data, lives on your box and only your box. None of it goes back into the shared Opbox repository. The repository holds the substrate and generic, reusable verticals - the abstract visa template, the abstract CSP template - never any one client’s matters, names, documents, or bespoke rules.
So when a vertical is built, two things stay strictly apart:
- The generic vertical - the reusable, abstracted shape of “how a visa practice tends to work” - can live in the shared repository so the next visa firm can start from it.
- The specific client - their actual matters, their particular intake fields, their real documents - is one tenant that takes a generic vertical and instantiates it on their own box with their own config and data. That instance never travels back upstream.
There is a discipline that goes with this, and it is worth stating plainly because it shapes every adoption: we map your documents onto the model; we never jam your concepts into the product. When a new practice comes on, the work is to ask “how does this fit our existing matters, parties, documents, forms, gates?” - not to bolt a new bespoke subsystem onto the substrate. If your work genuinely needs a primitive the substrate does not have, that is a deliberate change to the substrate, considered on its own merits, not a private hack on one box.
Least privilege is tiers and dials, not features held hostage
Because no capability is gated for sale, you might wonder how the system keeps people and AI agents from doing more than they should. The answer is that control is about who is acting and how much room they have, not about which features are switched on. Three independent dials do the work:
- Tier - whether the actor is an external client, a member of staff, an admin, or an owner. Every action requires a minimum tier.
- Autonomy - for AI agents, how far they may go on their own, from read-only up to owner-equivalent. The level can only ever shrink as a key is handed down a chain.
- Budget - a spending cap on the consequential, metered actions.
All three are explained in detail under security. The point for verticals is the clean separation: a sensitive action (say, submitting a paid filing) is protected because it requires a senior tier, a fresh second factor, and a budget - not because it was hidden behind a tier of the product the firm did not pay for. Removing feature-gating took nothing away from safety, because feature-gating was never what kept anything safe.
How you would actually stand up a new vertical
At a conceptual level, bringing Opbox to a new field is two distinct jobs, and they happen in different places.
1. Author the generic vertical (once, in the substrate). Map the field’s work onto the existing primitives, then write the configuration: the matter templates and their phases, the step-types and their shapes, any specialist verb-pack the field genuinely needs, the policies, and the knowledge the AI assistant draws on. This is content authoring, not feature engineering - you are describing how this kind of work flows, in the shapes the substrate already understands. The result is a reusable vertical the next firm in that field can start from.
2. Instantiate it for a client (per firm, on their box). Provision the client a box, install the generic vertical, and tailor the instance to that firm: their intake fields, their branding, their people and AI agents and the tiers and budgets they hold, their actual matters. This is the client’s tenant. Their configuration and data stay there; nothing about this firm flows back into the shared repository.
The two jobs are kept apart on purpose. The repository accumulates generic knowledge - better and better templates for visa work, for corporate-services work, for whatever field comes next - while every client keeps sole custody of their own configuration and their own regulated data on their own box.
What this means if you are deciding to adopt
- You are not buying a half-finished edition for your niche. You get the full substrate, and the work is to configure it for your practice - which is authoring, not waiting on a feature roadmap.
- Nothing is held back from you behind a paywall. Every primitive and verb is present. What is missing is only what no one has authored yet for your kind of work - and authoring it is the adoption.
- Your data and your bespoke rules never leave your box. Only the abstract, reusable shape of how your field works can be contributed back, and only if you choose.
- Safety does not depend on which features you bought. It comes from tiers, autonomy, budgets, and a database that fails closed - the same on every box.
To go deeper, see the data model for the primitives a vertical configures, and security for the tiers and dials that bound what a vertical’s agents can do.