How SPL Treatments turns 800 aerospace standards into a 2-minute decision

A century of judgment, held by one person

SPL Treatments has been finishing aerospace parts in Sheffield since 1926. Anodising, electro deposition, chemical conversion, passivation, non-destructive testing: the surface engineering that keeps components flying for Rolls-Royce, Airbus, Collins Aerospace, BAE Systems and Moog. It is precise work, and it is unforgiving.

None of it starts until somebody decides how a part should be treated. A customer sends a purchase order for a component SPL has never processed. Referenced inside it are the aerospace specifications that govern how that component may be finished, and those specifications are rarely short and almost never self-contained. One can run to 60 pages and point at 3 others, which point at more. SPL keeps an internal library of over 800 aerospace standards for exactly this reason.

Reading that chain and turning it into a treatment route is the whole job. Get it right and the part moves. Get it wrong and it is not a cosmetic problem. SPL holds Nadcap accreditation for chemical processing and for non-destructive testing, and works to AS9100. A miscalled route is a non-conformance event, with a customer like Rolls-Royce at the other end of it.

At SPL, that call sat almost entirely with Grant Riley, who runs operations and owns the technical decision on every new part that comes through the door.

An hour a part, 5 or 6 times a day

The old process was not complicated to describe. It was slow, and it ran through one person’s diary.

A new part arrived as a purchase order. Grant read it, worked out which specifications it referenced, and pulled them. Then he read those, found the specifications they in turn referenced, and pulled those as well. Each one had to be checked against SPL’s own library of standards to establish what the customer’s requirement translated to on SPL’s shop floor: which process, in which sequence, to which revision. Only then could he write the follower card, the route sheet that travels with the part through every tank and every inspection stage.

Each first-time part took him around an hour, and more often the top of that range than the bottom. SPL sees 5 to 6 parts it has never processed before on a normal day, and has seen 11 on a busy one. On the arithmetic alone, introducing them could swallow most of a working day, and it was work only one person in the building could do.

Behind it sat a second queue. A 3-person booking team handles repeat orders, up to a hundred purchase orders a day at roughly half an hour each. Those orders were not the bottleneck, but they showed how much of SPL’s day was spent reading documents and copying decisions out of them.

The knowledge was the deeper problem. A century of learning how to read a customer specification and pick the right route had been passed on through mentoring, not written down anywhere a system could reach. It existed. It just was not accessible to anyone who did not already hold it.

The system of record had no way in

SPL’s ERP is a legacy desktop system. No API, no import route, no browser layer. Anything built around it has to treat it as read-only from the outside, which ruled out the obvious shape of a solution: something that writes finished treatment routes straight back into the system of record.

That constraint decided the design. Back office automation had to work around the ERP rather than through it, produce an output a person could put into it by hand, and save enough time upstream that the manual step at the end did not cancel the gain.

This is an ordinary situation in industrial operations. The system of record is decades old, works well enough that replacing it is a multi-year commitment, and offers nothing to integrate with. Treated as a blocker, it ends the project. Treated as a constraint, it changes what gets built.

Now the specs are read before anyone opens one

Lleverage rebuilt new-part introduction as a decision pipeline with 3 inputs: the customer purchase order, the specifications it references, and SPL’s library of more than 800 aerospace standards. By the time a person looks at a first-time part, the reading, the cross-referencing and the first draft of the route are already done.

Two pieces of work carried most of it. The first was making the library readable by something other than a person. Lleverage built an indexing workflow that ingests SPL’s specifications, splits the long ones into searchable pieces and tags them, so the agent can retrieve the right section rather than the right document. Roughly two-thirds of the significant specs are indexed and the rest is in progress. This is the step that moves institutional knowledge out of one head and into something the team shares.

The second was deciding what the agent does when it is not sure. In a Nadcap-regulated process, a confident wrong answer is worse than no answer. So the agent flags gaps instead of filling them: a missing spec reference, an ambiguous tensile requirement, 2 sections that conflict. Grant reviews the flag and makes the call, and the correction feeds back into the system. That was not a compromise found later. It was the requirement that made an agent usable inside a regulated process at all.

In use, the workflow reads the purchase order, matches it against the indexed specifications, walks the dependencies between them, and drafts the follower card with every recommendation cited back to the section it came from. Grant reads the citations rather than the source documents and corrects what needs correcting. The confirmed route is then keyed into the ERP by hand, because the ERP has no other way in.

Corrections are the fuel. Each result carries a thumbs up or thumbs down, and what Grant marks down is what the agent learns from next. In practice the binary is a blunt instrument for output this close to right, which is a good problem to have.