Intelligent business operating system
Most software asks your company to fit its schema. BusinessOS turns how you already operate into a connected model of modules, relationships, workflows and metrics — then continuously analyses, stress-tests and diagnoses that model, while every important action stays behind a human approval.
The mapped model: customers place orders, orders require production jobs, and production jobs run on machines.
Workflow · Order fulfilment
Open orders
0
In flight
$0.0M
Machines down
0
AI Manager: 26 orders past SLA in “Approval”
Queue exceeds the stage’s 10/day capacity · 20 records cited as evidence
The problem
One operating model
Traditional software asks the business to fit its schema. BusinessOS starts from how the business already operates, and models the connections — which is what makes the reasoning above it possible at all.
The operating loop
Understand → Build → Analyze → Simulate → Diagnose → Evaluate → Approve → Act. Each stage hands its output to the next, and every conclusion carries the evidence that produced it.
A written description of the business becomes a structured blueprint: the objects that exist, the fields that matter, who approves what, and how work moves. Nothing is applied until a person reviews it.
Modules, fields, relationships and workflows derived from the description
Modules, fields, relationships, workflows, roles and metrics are created from the approved blueprint. The same renderer drives a manufacturer and a consultancy — the difference is configuration, not code.
Modules, fields, relationships and workflows derived from the description
Deterministic detectors read the operational data continuously: work past its SLA, queues beyond capacity, records with no owner, relationships that were never made. Each finding names the exact records behind it.
26 orders past SLA at Approval · 20 records cited
A frozen snapshot of the operational shape is pushed through alternative conditions — more demand, less capacity, slower processing, delayed approvals. Live records are never touched.
26 orders past SLA at Approval · 20 records cited
+40% demand → 10.9/day against 10/day capacity → 109% utilisation
The diagnosis walks upstream from where the symptom shows to the stage that actually constrains it, ruling out the stages in between and showing that reasoning in full.
26 orders past SLA at Approval · 20 records cited
+40% demand → 10.9/day against 10/day capacity → 109% utilisation
Root cause: Approval, 2.6 days of queued work. Upstream stages ruled out.
Measured rates are projected over 7, 30 and 90 days. Each risk states whether it rests on history, on simulation, or both — and confidence decays with distance, because it should.
26 orders past SLA at Approval · 20 records cited
+40% demand → 10.9/day against 10/day capacity → 109% utilisation
Root cause: Approval, 2.6 days of queued work. Upstream stages ruled out.
30-day projection: backlog reaches ~37 items · confidence 62%
A proposed change arrives with its evidence, its expected effect, its risk level and its execution plan. Approval records who decided, in what role, against exactly which version.
26 orders past SLA at Approval · 20 records cited
+40% demand → 10.9/day against 10/day capacity → 109% utilisation
Root cause: Approval, 2.6 days of queued work. Upstream stages ruled out.
30-day projection: backlog reaches ~37 items · confidence 62%
Proposal: raise Approval capacity to 16/day · awaiting a human decision
Ten server-side gates stand between an approval and a change. What happened is written to a hash-chained audit log, and a reversible change can be rolled back to its exact prior state.
26 orders past SLA at Approval · 20 records cited
+40% demand → 10.9/day against 10/day capacity → 109% utilisation
Root cause: Approval, 2.6 days of queued work. Upstream stages ruled out.
30-day projection: backlog reaches ~37 items · confidence 62%
Proposal: raise Approval capacity to 16/day · awaiting a human decision
Executed and audited · configuration version stored · rollback available
The product
Everything below is rendered with the same components the application uses. The figures are what the demo workspace actually computes — including the places where it declines to show a number at all.
Formula v1, computed from 6 measurable component(s).
79/100
211 of 253 records have an owner
292 of 297 records are connected
29 of 72 in-flight items are within SLA
7 of 8 capacity-bearing stages are within capacity
Derived from live records. A metric with no source data reports as unavailable rather than zero.
Open orders
253
Count of active Orders
Order value in flight
$13,006,749
Sum of “value” across 253 Orders
Average order size
262.33 units
Average of “quantity” across 253 Orders
Machines down
1
Count of active Machines where status = Down
Critical maintenance
1
Count where severity = Critical
Supplier defect rate
The intelligence stack
Seven deterministic detectors read your operational data: SLA breaches, queues beyond capacity, unowned records, missing relationships, incomplete required data, stalled records and stages with no way out.
“26 orders past SLA in Manager approval” · 20 records cited · confidence 100%
Two real engines: a closed-form queueing model that always runs in-process, and a SimPy discrete-event engine that models variance and individual item paths. Every result says which produced it.
+40% demand → Approval at 109% utilisation → backlog grows 0.92/day
Walks the workflow graph upstream from the symptom, scoring each stage, and distinguishes a genuine capacity constraint from work that is simply not being picked up — because the repair for those two is completely different.
Root cause hypothesis · 95% confidence · upstream stages explicitly ruled out
Projects measured rates over 7, 30 and 90 days. Each risk declares whether it rests on history, on simulation, or both — and a scenario-only risk is worded so it cannot be mistaken for a trend already underway.
Likelihood 38% · confidence 80% at 7 days, 45% at 90 · evidence type: mixed
Ten server-side gates stand between a recommendation and a change: registered action type, evidence present, permission held, approval policy satisfied, approver distinct from proposer, state unchanged, preconditions still true, idempotency key unused.
Refusals are recorded too — a blocked action is part of the audit trail
Human control
The system models operational context before it draws a conclusion.
Risky changes are tested against a frozen snapshot, never live records.
Every finding carries the records and arithmetic behind it.
Important changes wait for a named person, in a named role.
Decisions, actions and refusals are hash-chained and append-only.
In practice
An approved action still refuses to execute if the target changed after approval, if the approver was the proposer, or if the same request has already run once.
Who it is for
“Orders are late, but the warehouse looks fine.”
What surfacesApproval clears 10/day against 11 arriving. Everything downstream waits behind it.
“Projects slip and nobody can say which stage costs the time.”
What surfacesPartner review holds work an average of 61h against a 48h target.
“Fulfilment slows whenever a promotion lands.”
What surfacesReplenishment becomes the binding constraint at 1.6× normal volume.
“P1 tickets age while the queue looks healthy on average.”
What surfacesEscalation to engineering has spare capacity but no owner assigned.
“Every department reports green; the company still misses dates.”
What surfacesThe constraint sits between departments, where no single dashboard looks.
““Can we take on 40% more volume?” has no defensible answer.”
What surfacesA simulation names the stage that breaks first, and by how much.
Where it sits
Traditional ERP
Stores and coordinates operational records.
Business intelligence
Visualises what already happened.
Workflow automation
Runs predefined trigger-and-action logic.
Generic AI assistant
Answers questions about data you point it at.
BusinessOS AI
Builds an operating model, reasons across its relationships, tests scenarios against a frozen snapshot, diagnoses causes, evaluates forward risk, and prepares actions that a person approves.
Trust and safety
Row-level security on every tenant table, enforced by PostgreSQL rather than by remembering a WHERE clause. With no authenticated session the database returns nothing.
Seventeen permissions across five roles, checked in the database as well as the interface. A role without a permission cannot perform the action through the API either.
Model output is validated against a schema before it can be used, and retried with the validation errors when it fails. Free-form text never reaches an executor.
Business content is passed as fenced, labelled data. Text inside a record that reads like an instruction is analysed as content and reported, never obeyed.
The engine receives a frozen snapshot containing no record identifiers and no write handle. There is nothing for it to modify.
Each entry commits to the hash of its predecessor. The application role holds no UPDATE or DELETE grant on the audit table at all.
No compliance certification is claimed. These are engineering properties of this codebase, which is a different thing from an audited certification, and the distinction matters.
Questions
From a description of how you operate, it produces a reviewable blueprint — modules, fields, relationships, workflows, roles, metrics and rules — and, once you approve it, creates that structure as live configuration you can use and edit.
No. It is an intelligence and reasoning layer. It can model your operation directly, or sit above existing systems through connectors, normalising what they hold into one operating model.
No. Every change is a structured proposal that passes ten server-side checks and requires an explicit human approval from someone other than the person who proposed it. Refusals are recorded as part of the audit trail.
It never reads live records. It reads a frozen snapshot of the operational shape — stage capacities, queue depths, observed arrival rates — which contains no record identifiers and no write access.
No, and it says so. It projects measured rates forward over a stated horizon, declares whether the projection rests on history or on a simulation, and reduces its confidence as the horizon lengthens.
Almost everything still works. Detection, simulation, diagnosis, risk evaluation and the whole action pipeline are computed from your data, not generated. Only blueprint generation from a written description and narrative explanation need a model, and the interface says plainly when they are unavailable rather than substituting anything.
No. The renderer is driven entirely by configuration, so a manufacturer and a consultancy produce genuinely different modules, fields, relationships and workflows from the same platform.
Yes. Every finding, diagnosis, risk and proposal carries its evidence, and each evidence item is marked as observed, simulated or demo data so a modelled number can never be read as a measured one.
Back where we started
Start with one description of how your company works — or open the demo and walk the whole loop on a manufacturing operation with a real constraint to find.