Regulatory, compliance and securitisation reporting for a Tier-1 bank — where the hardest problem was never a requirement.
The engagement was fixed price. Thirty-four people across two organisations. Regulated data, where being wrong isn't embarrassing — it's reportable.
And there was no agreed answer to a basic question: how does something get from "the bank wants this" to "it's live and we can prove it does what was asked"? Different people gave different answers. The timeline was already moving.
On fixed-price regulated work, ambiguity is not a communication problem. It's the thing that eats the margin and the deadline.
So before I wrote a single requirement, I built the machine that requirements would travel through — then spent longer than that getting the client to adopt it while they were pushing on dates.
Engineering, testing, DevOps, solution architecture and partner leadership on one side; product owner, principal engineer, design and the bank's own analysts on the other. Every requirement I wrote had to survive both.
A closed-loop traceability matrix, so that every change could be traced forward from the business rule that asked for it and backward from the evidence that proved it. In a regulated workflow that isn't documentation overhead — it's the only mechanism that can answer "show me this control works" without a week of archaeology.
Six links, and the sixth returns to the first. Break any one of them and you can no longer prove a change did what the regulation asked — which on a fixed-price engagement is also the moment you lose every scope argument you were going to have.
BRD to PRD to epics to features to user stories to acceptance criteria. Every level owned end to end, so nothing arrived at engineering as an opinion.
Functional impact assessed against the originating requirement before anything moved forward — validating behaviour, not reading every line of code.
The harder half. A process nobody follows is a document. Selling it to a client under timeline pressure took longer than designing it.
Nothing reached the bank's business users because someone decided it was probably fine. Every change crossed four gates, each with a different question and a different signatory.
Securitisation pool files, records entered by the bank directly, and compliance documentation — three shapes of truth that had to become one reported figure. I owned the mapping and the data-quality validation across all of it.
The forward path is the easy half. The violet return path is where the work was — proving that the figure a business user reads is the same figure the source system reported, at every layer in between.
This is the part of my background that looks least like AI work and turns out to be the most transferable. The control questions don't change when the thing being controlled starts generating text — only the evidence you produce for them does.
On a release: a requirement traced to a signed-off business need. On a model: a documented purpose, a named owner, and a stated limit on what it may be used for.
On a release: a test case mapped to that requirement. On a model: an evaluation set with a metric, a sample size, and a threshold agreed before anyone sees the result.
On a release: a named approver at each of four stages. On a model: a person approving every weight and prompt change — which is precisely the gate I later built into my own product.
On a release: rollback, and an impact assessment naming everything it touches. On a model: a defined degraded state and a fallback that doesn't leave the user staring at a blank panel.
Most people arriving at AI product work have to learn this vocabulary from a framework document. I spent two years being held to it by people whose job was to fail me on it — and I've since applied all four to a system I built myself.
I fought for traceability and release gating after the engagement had already started — which meant negotiating them under timeline pressure, with a client who had every commercial reason to say no. I won that argument, but it cost weeks I didn't have and goodwill I'd rather have spent elsewhere.
On fixed-price regulated work, these aren't overhead you introduce once things get messy. They're what makes the price defensible in the first place. I'd put them in the statement of work now, before anyone signs — and price the engagement accordingly.