MANUFACTURE TERMINAL EXPLORE THE SYSTEM Sign in →
> Explore the system

Built today.Designed to scale.

Manufacture Terminal is a modular manufacturing management architecture that connects operational data, intelligence and executive decision-making.

This page explains why the system exists, how its management logic works, what it contains today, how it is architected, how that architecture scales — and where its current data foundation stops.

Every figure on this page is synthetic. The system is real and in daily use behind authentication. The numbers shown here are not its numbers.

Start at the problem
Part 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.

01

The management problem

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.

Four connected problems, each one making the next harder to solve.

Production · daily · spreadsheet
Output by line, shift notes
Quality · weekly · spreadsheet
Complaint register
Finance · monthly · slide deck
Cost centre summary
Procurement · ad hoc · email
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?

no single owner · no shared cadence · no file that holds it
Fig. 01 — five records, one unanswered question
Four connected problems · 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
BeforeManufacture 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
Synthesis
From scattered reporting to a shared management system.
02

The management logic

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.

Data
Perfor­mance
Diag­nosis
Decision
Action

The loop
closes here

Fig. 02 — action feeds the next period's data. Amber closes the loop.
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.

03

Current system

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 In use behind authentication · all ten

BuiltExecutive

Executive KPI

The question it answersWhere are we against the scorecard, and what has held critical for months?

BuiltExecutive

Market Intelligence

The question it answersWhat outside the plant is moving against us?

BuiltOperations

Production Capability

The question it answersWhat can each line actually run, and what is the binding constraint?

BuiltOperations

Quality Intelligence

The question it answersWhat escaped, at what rate, and did the fix hold?

BuiltFinance

Manufacturing Finance

The question it answersWhat does a unit cost, and what moved it? Opened up in full below →

BuiltSupply chain

Procurement Intelligence

The question it answersWhich inputs are repricing, and by how much?

BuiltSupply chain

Forecasting Studio

The question it answersWhat will demand be, and how wrong have we been?

BuiltPeople

Overtime Analytics

The question it answersWhere is overtime concentrating, and is it value-adding?

BuiltPeople

OEN

The question it answersHow does the organisation actually collaborate, versus the org chart?

BuiltFacility

Plant Map

The question it answersWhere is everything?

04

A module in detail

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
01 Business 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.
02 Management 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.
03 Data 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.
04 Digital 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.
05 Analysis 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.
06 Decision 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.
07 Action 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.
Screenshot slot · 01 Manufacturing Finance, running 1600 × 1000 px (16:10) · synthetic data · supply at 2× for retina
Fig. 03 — the module in use. Placeholder until the screenshot is supplied at integration.
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.

05

Two architectures, one system

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

  1. DataIs this figure trustworthy?
  2. PerformanceAgainst what?
  3. DiagnosisWhat drove the change?
  4. DecisionWhat are the options?
  5. ActionWho owns it and what happens next?
Supports

Technical architecture

  1. Source dataOperational records, extracted from the systems that already hold them.
  2. ExtractionFigures 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.
  3. Cloudflare WorkerThe application layer: serves each module and handles the API, with verified identity already attached.
  4. Cloudflare D1SQLite 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.
  5. ModulesTen self-contained modules, each answering one question.
  6. Control TowerWhere the ten answers are read across, not down.
  7. Management outputAn executive report, and a decision with an owner against it.
Fig. 04 — the same system described twice. Read across, not down.
06

Technical and security architecture

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.

Fig. 05 — user access, application, what is written back, intelligence, management. Reported figures are embedded in each module ahead of time; the database carries what people record into the system. Conceptual. Open any component for what it does
Cloudflare Access
Sits in front of the application and decides who may reach it. Nothing arrives at the Worker until Access has made that decision.
Zero 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.
Email 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.
Cloudflare Worker
The application layer. Serves each module as a static asset and handles API requests, with the verified identity Access supplied already attached.
Application logic · API
Where a saved record is validated and stamped with who made it, without the application ever having handled a credential.
D1 binding
The Worker's declared connection to the database. No connection string travels with a request.
Cloudflare 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.

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.

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

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

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

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.

07

The Control Tower

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 — generated in the browser as a PDF.

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 · PDF
any period · 12 sections · methodology + limits
Management · decision
an owner, and a next date
Fig. 06 — specialised analysis becomes one management view
Screenshot slot · 02 The Control Tower 1600 × 1000 px (16:10) · synthetic data · supply at 2× for retina
Fig. 07 — the tower in use. Placeholder until the screenshot is supplied at integration.
Artefact · download A real generated executive report Built on synthetic data, produced by the system itself. Stated methodology, explicit limits. This is the proof, in place of a live demo. PDF File pending
Part four

How it scales

Where additional capability attaches without the core being rebuilt, and where the current data foundation stops.

08

Scalable architecture

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 below is what makes that true: capability attaches at a defined layer rather than being threaded through the ten modules that already exist.

Current modules ten, built and in use
Shared data one source per number
Shared business logic one set of definitions
Shared intelligence derivation, comparison, decomposition
Control Tower the convergence point
Additional capabilities when needed
Fig. 08 — where new capability attaches. The dashed layer is deliberately empty.
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
The contract

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
09

Current architectural limits

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.

Current data foundation what the source systems actually capture
Current architecture what can be derived from it and reconciled
Supported analysis what the system is willing to state
Outside the boundary not derivable from current data — so not stated
Fig. 09 — analysis is bounded by what is captured, not by what is wanted

Six of them, named.

These are the specific analyses the system refuses to produce, and the reason in each case. They are stated inside the executive report itself, not only here.

No OEE decomposition

No downtime or loss-event record exists, so overall equipment effectiveness is reported as the single figure the scorecard carries — never split into availability, performance and quality.

No process capability

The quality evidence is the customer complaint register: escaped defect, what reached a customer and came back. There is no in-process, laboratory or first-pass-yield data, so capability is not claimed.

No cost of poor quality

Complaints record the units affected, never the value of the failure — no replacement, freight or goodwill cost. So no COPQ figure is derived.

No supplier risk score

The procurement register holds prices only. Without delivery performance, lead time or quality history there is nothing to score, so no score is invented.

No exposure derived from price

The bill of materials does not reconcile with finance material cost — one product overstated by a factor of twenty-four. Price movement and material cost are therefore reported as separate evidence and never multiplied together.

No invented targets or owners

No target, owner, deadline, action or forecast appears unless a source system already holds it. A blank is shown as a blank rather than filled with a plausible number.

Data discipline
A number that cannot be defended is worse than a gap, because a gap is honest.