Industrial AI engagement briefs.

Each brief describes a real delivery context: the operating problem, the evidence that was available, the architecture chosen, the constraints that shaped it and what the client team owned at handover. They are written to be useful to someone scoping similar work, not to advertise a result.

They are anonymized. Client names, sites and commercially sensitive figures are withheld unless a client has approved publication. Where a number is not published, it is because permission and a stated baseline do not yet exist — not because the number is unavailable to us.

They avoid universal claims. An outcome achieved in one plant, on one data history, with one team's process discipline, is not a benchmark for yours. Where a brief describes an improvement, read it alongside the stated scope and limitations rather than as a figure to expect.

They record what was hard. Data gaps, integration constraints, acceptance disagreements and the conditions under which a system was allowed to fail safely are included deliberately. Those are usually the parts that transfer to another site; the model architecture often is not.

If a brief is close to a problem you are scoping, the useful next step is a working session against your own workflow, evidence and constraints rather than an assumption that the same approach applies.