Case study 02 · Operating Picture

One engine. Two different businesses. Zero code changes.

Most companies don't have a data problem. They have no shared model of themselves. The Operating Picture is the reusable core we build client systems on, so client ten gets a deployment instead of a rebuild.

53tests passing

0runtime dependencies

2unrelated businesses on one engine

−44.8%hidden margin found on one "healthy" job

The problem

Leads, jobs, people and cash each live in a different tool

Nobody can see how one moves the other. So the owner becomes the integration layer, and the real operating picture lives in their head. Every consultancy that builds a custom system for this starts from zero, and the client pays for the rediscovery every time.

The idea

The business model is data, not code

A client is described in one declaration file: the objects that matter (jobs, machines, customers, invoices), how they link, what is calculated from them, and which actions are allowed. The engine reads that and produces everything else.

objects: Job · Machine · Operator · MaterialIssue · TimeLog · Rejection links: Job → Machine, Job → Operator, Rejection → Job derived: totalCost = material + labour + machine + costOfQuality margin = quoted − totalCost actions: closeJob (blocked if no time logged) · flagRework · reprice

Switching to a different business means writing a new declaration, not new software. A software studio's projects, timesheets and expenses run on the exact same binary.

Prove

The job that looked fine

In the manufacturing demo, job J-1004 was quoted and running like any other. Nothing in any single register looked wrong. Once material, labour, machine time and rejects were costed against it, the picture changed:

Job Customer Quoted Actual cost Margin J-1001 Shakti Auto 450,000 314,800 30.0% J-1002 Meridian Pumps 280,000 193,640 30.8% J-1003 Shakti Auto 620,000 300,000 51.6% J-1004 Deep Valves 95,000 137,590 −44.8% Worst: J-1004 Material 48,000 Labour 14,760 Machine 48,600 Cost of quality 26,230 Margin −42,590

That is the whole argument for an operating picture in one table: the loss was always there, it just had no place to show up until the objects were connected.

Keeping it realThe figures above are demo data we wrote to exercise the engine, not a client's books. The point is the mechanism: connect the objects and the hidden loss becomes visible.

Engineering that matters

Built to be trusted with real operations

Derived values chain safely. Margin depends on total cost, which depends on four inputs. The engine resolves the graph and refuses a circular definition instead of hanging.
Bad definitions fail at load, not in a report. A missing link or a wrong field is reported before any number is shown.
Actions can't corrupt state. Preconditions run first. A blocked action changes nothing, and every allowed one records before, after, who and when.
Reuse is enforced by a test. The suite fails if the engine ever mentions an object from a specific business.

What isn't built yet, stated plainly: persistence beyond memory, an HTTP API, a web interface and per-user access control. Those get added per client, on top of the same core.

What it means for you

Your diagnostic becomes your system

The objects we map in your Leak Diagnostic are the declaration file. So the diagnosis isn't a report that goes in a drawer. It's the first version of the software that runs your operating picture.

You don't pay for us to rediscover how a business works. You pay for what's specific to yours.

Previous case study

App Factory: 7 apps live in 58 days

Read it Start here

Take the free 3-minute diagnostic and see what your business can't see

Run the diagnostic