Evidence
Buying for a plant is buying down risk, and this page is where we show that the risk has been carried before. Until we have work we can verify, we are not filling the space with something else — we are publishing the standard instead.
Work with written client approval, and figures we can give together with how they were measured.
No reference is published yet. We hold no approved client text and no verified measurement, and without both a project does not enter this list.
Publication rule
We write the rule down first, because a rule written afterwards is not a rule.
The client name, the project name and every quoted sentence are published on written approval. A sentence we cannot get approved is removed, not softened.
Each number states what was measured, where, and over what period. We give no percentage without its context, and we do not write up an improvement we could not measure.
If permission to use the client name does not come through, the work is still published: the sector, the scale and the problem stay real, only the name goes. An anonymous reference beats no reference at all.
Reference structure
The order is fixed. Choosing which sections to write means leading with the part that went well, so all of them are written, always in this order.
Sector, scale of the plant, duration of the work, services used, and the systems involved.
What took how long before we began. Where nothing was measured, measuring is the first job — a result without a starting point cannot be read.
What we could not change: a line that cannot stop, an ERP no one may touch, hardware that stays, a fixed shift pattern.
Which step came in which order, what was chosen at each decision point, and why.
Architecture, integration points, data flow and access control. Written for the technical reader and not abridged.
The outcome figures, each with the method behind it. An effect we could not measure is described in the text, never in the results block.
What we built wrong first, where we backed out, which assumption did not hold. Drop this section and what is left is an advert, not a reference.
Problems we work on
These are problem statements, not claimed outcomes. If you recognise one of them in your own plant, you are on the right page.
ERP, MES and the systems on the floor each work correctly on their own and not together. The same production order sits in three places in three different states.
The shift log, a spreadsheet passed around by hand, a downtime reason relayed by phone. The data is collected but is not in reach at the moment of the decision.
The model works in the demo and not on the line. The problem is usually not the model but the data flow and the way it was put into service.
It was installed, training was given, and it is not used. The team went back to the old way because the new way slows their day down.
Anonymous reference
We designed the anonymous form up front, so we are not improvising a structure on the day permission is refused.
The card below is not real work. Its client, its outcome and its tags are placeholders; it shows the layout of an anonymous reference and nothing more.
A glass manufacturer — anonymous
The card body sums up problem and solution in two sentences. Figures do not sit here; they are given with their measurement method in the results section of the reference itself.
Until we can publish verified work, the most concrete thing to look at is how we work. Or describe a production problem directly — you will get a technical answer.