Business OS decision logic

Start with the decision

A Business OS is not a collection of screens. It is a governed path from operational state to a decision, an action, and reconstructable evidence. Every workflow worth putting on the platform can be described that way — and if a workflow cannot be described that way, automating it only produces faster ambiguity.

This page is the worksheet we apply before any rollout, integration, or agent workflow. It is deliberately plain: six questions, answered in writing, before anything is built.

The decision worksheet

For each workflow, document:

1. Decision: what must an operator determine or approve? Not "what does the dashboard show" — what is actually decided, and how would you know the decision improved?
2. Record: which shared facts support that decision? If the same fact lives in three systems with three values, name the one that will become authoritative. See data fabric orientation for how sources are mapped onto the shared record.
3. Owner: who is accountable for the current state and its exceptions? A workflow without a named owner routes its exceptions to nobody, which is worse than routing them slowly.
4. Boundary: which brand, location, department, or role may act? Boundaries here are the same ones the platform enforces — see multi-tenant architecture.
5. Gate: what policy or human approval applies before execution? Classify by consequence: reads and reversible writes move fast; irreversible actions sit behind a named gate. Approval gates covers the classification.
6. Evidence: what must be retained so the outcome can be reviewed a year from now — by you, or by counsel reading the record cold?

From worksheet to platform

A completed worksheet maps directly onto platform machinery: the record lands on the shared ledger, the boundary becomes explicit grants, the gate becomes operator-visible policy, and the evidence requirement becomes entries in the audit trail. Nothing in the worksheet is aspirational — each answer names a control that already exists.

The worksheet is also how rollouts stay honest. The pilot rollout checklist turns it into a sequence: one bounded workflow, proof criteria written down first, expansion decided on evidence.

A worked example

Take "approve a location-level refund above a threshold." The worksheet resolves it in one pass:

1. Decision: does this refund leave the building? The threshold defines which refunds need a human decision at all.
2. Record: the original transaction, its brand and location context, and the member's standing — one shared record, not three exports.
3. Owner: the location's manager owns the queue; finance owns the threshold policy.
4. Boundary: the manager's grant names the brand and the location; the refund cannot touch another location's ledger.
5. Gate: the refund class is irreversible, so policy routes it to a named approver — and the decision is recorded either way.
6. Evidence: proposal, policy result, approver, and outcome persist as linked entries, reconstructable a year later.

Notice what did not appear: a new system, a spreadsheet, a message thread. The workflow runs on controls the platform already has — the worksheet's job is making that mapping explicit before the first refund, not during the first dispute.

Where the worksheet fails people

The two failure modes are skipping question one (a workflow with no real decision is a reporting requirement wearing automation's clothes) and answering question three with a team instead of a name. Teams do not own exceptions; people do. If the honest answer is "ownership is unclear," that is the pilot's first finding — and it costs a worksheet, not a migration.

Public and authenticated surfaces

Public documentation explains the pattern and helps teams prepare. It does not expose live records or resolve current operating state. The authenticated console remains authoritative for workflow status, approvals, exceptions, and evidence.