Executive KPI
Where are we against the scorecard, and what has held critical for months?
BuiltPart one
The thinking.
Before any of this was software it was a management problem and a way of working through one. This part is the argument the system is built on.
MT/01/The management problem
MT-01
The problem was never the data. It was the absence of a shared management view.
Analysis existed. It was produced by every function, on its own cadence, in its own file. What did not exist was a way to turn that operational information into a shared management language, a shared performance reference, and a management rhythm that spent its time on the business rather than on the pack.
| Function | Cadence | Format | What it holds |
|---|---|---|---|
| Production | Daily | Spreadsheet | Output by line, shift notes |
| Quality | Weekly | Spreadsheet | Complaint register |
| Finance | Monthly | Slide deck | Cost centre summary |
| Procurement | Ad hoc | Price changes, quotations | |
| People | Monthly | Spreadsheet | Overtime hours |
The question that crosses all five
What did a unit cost last month, why did it move, and what would it take to move it back?
Four connected problems, each one making the next harder to solve · open each one
01Scattered analysis Production, quality, finance and procurement each held one part of the picture.
Each view was complete on its own terms. The relationships between them were the part nobody held — and those relationships were where the business questions lived. Cost per unit is a finance number, a production number and a quality number at once. Manufacture Terminal brings the signals together and synthesises them into one management view.
Scattered analysis→
Synthesis→
Cross-functional insight→
Management decision
02No common language Reports could be technically correct and still hard to read outside the function that wrote them.
This was never only a data problem. A technical reader understands the metric immediately; management needs what sits around it. The Terminal presents operational metrics with the context, the driver and the business implication attached, which makes the same evidence readable outside the function that produced it. It does not write the narrative — it makes the material board-ready.
Metric→
Context→
Driver→
Business implication
03No shared reference Nothing answered "how good are we?" the same way twice.
Without a shared performance reference, each function optimises against its own metrics and its own priorities. The Terminal puts the business metrics that matter in one place — what matters, where performance stands, what is improving, what is deteriorating, where attention is required. A shared reference can help anchor behaviour around business priorities; it does not change behaviour on its own.
Visibly measured→
Understood→
Attended to→
How the organisation works
04Preparation time Management time went into building the pack rather than discussing the business.
Four steps of preparation stood in front of every discussion, and the discussion inherited whatever the pack happened to contain. The Terminal becomes the shared reference during the meeting itself: open it, look at the evidence, discuss the drivers, decide.
Before
Collect data→
Build report→
Update deck→
Prepare meeting→
Discussion
Now
Live business information→
Manufacture Terminal→
Management discussion→
Decision
| Before | Manufacture Terminal |
|---|---|
| Function-specific reports | One unified management view |
| Technical language | Board-ready context |
| "What happened?" | "What does it mean?" |
| Individual metrics | Shared business priorities |
| Prepare, present, discuss | Open, explore, decide |
| Reporting as an activity | Performance as a way of working |
From scattered reporting to a shared management system.
MT/02/The management logic
MT-02
Data, performance, diagnosis, decision, action.
Manufacture Terminal is designed around a management decision loop, not around dashboards. Each stage is a question the system has to be able to answer, and each question has a precondition. If the precondition is missing, the stage is decoration.
Most reporting stops at performance. Everything after it is where the work actually is, and that is where this system is aimed.
Five stages · open a stage for what has to exist before it can be answered
01Data Is this figure trustworthy?
What has to exist
One source per number, stated. A figure whose origin cannot be named is not evidence, it is a rumour with a decimal point.
02Performance Against what?
What has to exist
A target, a prior period, or a peer. A number on its own is not performance — performance is a comparison. This is where most reporting stops.
03Diagnosis What drove the change?
What has to exist
A decomposition that reconciles. If the parts do not add back to the whole, the explanation is a story rather than a diagnosis.
04Decision What are the options?
What has to exist
Scenarios and constraints — and what each option costs. An option without a cost attached is a preference.
05Action Who owns it and what happens next?
What has to exist
An owner and a next date. Without both, the loop does not close and the next period starts from the same place as this one.
Part two
What is built.
Ten modules in use today, and one of them opened up to show how a module gets designed in the first place.
MT/03/Current system
MT-03
Ten modules, each answering a management question.
Not ten dashboards. Ten questions someone actually has to answer, each with a place to go and look. What a module displays matters less than the decision it makes possible.
Built
MT/04/A module in detail
MT-04
A module starts from a decision, not from a dashboard.
Every module begins with the management decision it has to enable, and works backwards from there to the data. Manufacturing Finance is the fullest worked example: its framework is the most developed in the system, and its decomposition reconciles exactly.
The design framework · Manufacturing Finance
- 01Business problem Cost per unit was known as a monthly total. When it moved, nobody could say which component moved it, by how much, or whether the movement was real cost or a change in volume.
- 02Management need A cost per unit that can be defended component by component, and a comparison between any two periods that reconciles rather than approximately agrees.
- 03Data need Finance cost separated into the four components that make up a unit — material, labour, overhead and water — with production volume for the same period on the same basis, so the numerator and the denominator agree. Bill-of-materials data is deliberately excluded: it does not reconcile with finance material cost, so the two are never combined.
- 04Digital workflow Cost centre data is extracted, mapped to the four components, and embedded in the module alongside the matching volume — one file, one period definition, no live query to disagree with itself mid-review.
- 05Analysis Cost per unit decomposed into material, labour, overhead and water; a bridge between any two months attributing the movement to each component; and product-level economics where volume supports it. The bridge reconciles to the rupiah.
- 06Decision Which component to act on, and whether a movement in unit cost is a mix effect, a volume effect, or a genuine change in cost.
- 07Action A cost conversation starts from an agreed number rather than from whose spreadsheet is open, because the decomposition can be walked back to its components in front of the person challenging it.
The logic underneath
A cost per unit that moved is not yet a finding. It moved for three different reasons, and only one of them is a cost problem. Separating them is the whole job.
Part three
How it is architected.
Two architectures that describe the same system — one in management terms, one in technical terms — and the point where ten modules become one answer.
MT/05/Two architectures, one system
MT-05
The technical architecture exists to support the management architecture.
Not the other way round. Every layer on the right is there because a stage on the left needed it — and nothing on the right is there for its own sake.
Management architecture
- M1
Data
Is this figure trustworthy?
- M2
Performance
Against what?
- M3
Diagnosis
What drove the change?
- M4
Decision
What are the options?
- M5
Action
Who owns it and what happens next?
Technical architecture
- T1
Source data
Operational records, extracted from the systems that already hold them.
- T2
Extraction
Figures are pulled, reconciled and embedded into each module ahead of time — so a review never waits on a query, and two people looking at the same period see the same number.
- T3
Cloudflare Worker
The application layer: serves each module and handles the API, with verified identity already attached.
- T4
Cloudflare D1
SQLite at the edge, alongside rather than in front — it holds what people record into the system, so a saved decision is shared rather than a copy on one laptop.
- T5
Modules
Ten self-contained modules, each answering one question.
- T6
Control Tower
Where the ten answers are read across, not down.
- T7
Management output
An executive report, and a decision with an owner against it.
MT/06/Technical and security architecture
MT-06
Identity is verified before the application is reached.
Manufacture Terminal is deployed behind Cloudflare Access using a Zero Trust access model. The current authentication flow uses email-based One-Time PIN authentication.
Those are two different things, and the distinction matters. Zero Trust is the access model — every request evaluated on identity rather than on network location. One-Time PIN is the authentication method operating inside that model, and it can be changed without the model changing.
User access
User→
Cloudflare Access→
Zero Trustaccess model→
Email OTPauthentication method→
Authorised user
Application
Cloudflare Worker→
Application logicAPI
Data written back
D1 binding→
Cloudflare D1what people record into the system→
Shared records
Intelligence
Modulesfigures embedded ahead of time→
Control Tower
Management
Management→
Decision
Open any component for what it does
C1Cloudflare Access
Sits in front of the application and decides who may reach it. Nothing arrives at the Worker until Access has made that decision.
C2Zero Trust access model
The access model. Every request is evaluated on verified identity rather than on where it came from — there is no trusted interior, and being on a particular network grants nothing.
C3Email one-time PIN
The authentication method operating inside that model: a single-use code sent to an invited address. There is no password for the application to store, reset, or leak — and the method can change without the model changing.
C4Cloudflare Worker
The application layer. Serves each module as a static asset and handles API requests, with the verified identity Access supplied already attached.
C5Application logic · API
Where a saved record is validated and stamped with who made it, without the application ever having handled a credential.
C6D1 binding
The Worker's declared connection to the database. No connection string travels with a request.
C7Cloudflare D1
SQLite at the edge. It holds what people record into the system rather than the reported figures, which are embedded in each module ahead of time. So a decision saved by one person is the same record everyone else sees — not a copy on somebody's laptop — and a published figure cannot drift between two people reading the same period.
A
No application framework
A lightweight, platform-native architecture without a conventional frontend framework or a dependency-heavy runtime.
- Fewer abstraction layers
- No build step · one-command deploy
- Fewer dependency upgrade cycles
- Modules stay portable
- Direct use of platform primitives
Not inherently better — a deliberate choice fitted to this system's size and rate of change.
B
Self-contained modules
Each module has clear boundaries and joins the shared Terminal architecture without coupling its internals to unrelated modules.
- Clearer boundaries
- Lower coupling
- Easier maintenance
- Module-level development
- Expansion without core change
C
Access control at the edge
Identity is verified before the application is reached, so access decisions do not live inside application code.
- No password for the system to hold
- Verified identity arrives with the request
- Access granted and revoked outside the app
- Records stamped with who made them
D
Worker and D1 as separate layers
The Worker is the application and business-logic layer. D1 is the structured data layer. The separation keeps them independent.
- Logic and data evolve separately
- Shared state, not local copies
- Data outlives any one module
Note
Deliberately conceptual.
Account identifiers, database identifiers, bindings configuration, environment values and internal URLs are not published here. What this section demonstrates is the shape of the architecture, not its configuration.
MT/07/The Control Tower
MT-07
The synthesis layer, not another dashboard.
The ten modules produce specialised analysis. The Control Tower is where those signals are read together — a production change, a quality change, a material cost change and a procurement change are four reports in a functional structure, and one business event when read as one.
- It derives rather than displays. Cost per unit decomposes exactly into material, labour, overhead and water — the bridge reconciles to the rupiah.
- It compares. Unit margin, the cost bridge between any two months, the performance matrix.
- It surfaces pressure. What is critical, what is repricing, what is constrained.
- It ends in an output. A full executive report for any period — month, quarter, half, year to date, full year or a custom range — assembled entirely in the browser as a Word document, with every chart drawn on the page and embedded into it. Nothing is rendered on a server.
The Control Tower is the synthesis layer where specialised module analysis becomes one management view. In the product it resolves to six: factory state, unit economics, cost bridge, product economics, performance matrix, and where the pressure is.
Modules→
Specialised analysis→
Synthesis→
Cross-functional relationships→
Business insight→
Management decision
Executive KPI
Market Int.
Prod. Capability
Quality Int.
Mfg Finance
Procurement
Forecasting
Overtime
OEN
Plant Map
Control Tower · synthesis
- Performance
- Trends
- Variance
- Drivers
- Alerts
- Reporting
Executive report · .docx
Management · decision
Part four
How it scales.
Where additional capability attaches without the core being rebuilt, and where the current data foundation stops.
MT/08/Scalable architecture
MT-08
Additional capability can be introduced when the business needs it.
The system is designed so that new capability attaches to shared data, shared logic and a shared point of convergence, without the core being rebuilt. The eleventh module requires no change to the first ten.
New modules are built against a written brief rather than against the core, so extending the system does not mean reopening it.
The stack is what makes that true: capability attaches at a defined layer rather than being threaded through the ten modules that already exist.
The contract that makes this true
Scalability is a claim. This is the seam that supports it — inspectable rather than asserted.
A module supplies
- One self-contained HTML file
- Its data in a declared payload tag
- A name, a group, and a one-line description
It receives, without core changes
- Registration on the homepage, with status control — live, beta, maintenance or offline
- The Terminal chrome and back navigation, injected
- Inclusion in the report extractor, which fails loudly if the module changes shape
- A database binding, if it needs to store anything
Current modules
Shared data
Shared business logic
Shared intelligence
Control Tower
Additional capabilities
MT/09/Current architectural limits
MT-09
What the current data foundation can and cannot support.
Analysis is bounded by the data the source systems actually capture. Where a source system does not record something, the current architecture cannot produce a reliable figure from it — and the system does not produce an unreliable one instead.
Everything outside that boundary is absent from the system, and is not presented as fact anywhere in it.
A number that cannot be defended is worse than a gap, because a gap is honest.
Current data foundation
Current architecture
Supported analysis
Outside the boundary