How would you build a compliance review into your normal development process?

Ferrocode's ticket board is where sixty engineers plan and ship every feature, including the AI assistant they're now building into it. Solene Kabeya is the product manager who owns that ticket board itself, the shared tool every engineer opens first each morning.

How to answer this, stage by stage

The ticket board is the artifact here. Point at it early, before the framework, before anything else.

Let's learn

Say a dev-tools company builds an AI assistant into its own project-management platform, and engineers ship it the same way they ship every other feature: no separate process, no dedicated step, just the normal design-build-test-merge loop.

In Ferrocode's early days, that was fine. The whole engineering team was eight people who sat near each other, and someone would casually mention a new feature to their one legal contact before it shipped, almost as a courtesy.

As the team grew past eight, then past twenty, that casual habit didn't get replaced with anything. It just quietly stopped happening, because nobody owned it and nobody was tracking whether it still occurred.

At its worst: a new engineering hire, three weeks in, asks their manager mid-sprint when the team actually checks whether a feature is legal to ship. The manager pauses, then says something about "usually legal reviews the big stuff," which isn't really an answer at all.

What I would leave alone: internal tooling changes, refactors, test infrastructure, genuinely don't need this gate. Adding it there would just teach people to click through gates without reading them.

The lesson: a habit that depends on a small team's closeness isn't a process. It's a coincidence that happens to look like one until the team gets big enough to prove it wrong.

Now here is the same thing as a story

The short version above is what you'd say pitching this to engineering leadership. Read this one for how Adaeze actually found the gap.

Solene Kabeya has owned Ferrocode's ticket board for four years, since before the company had its own AI assistant to worry about at all. Back then, "flag for legal" was a literal label on the board, and engineers used it without being told to.

The team doubled, then doubled again. The label stayed on the board for a while, technically available, used less and less, until a routine tooling cleanup quietly removed it, alongside a dozen other unused labels nobody would miss.

Five steps, and the second one used to exist as a small label nobody thought twice about, until it didn't.

Nobody noticed for a long stretch, because nothing broke. Then a new engineer, three weeks into the job, asked her manager a plain question in a planning meeting: when do we actually check if something we're building is legal to ship? The manager didn't have a real answer, and repeated the question to Adaeze that same afternoon.

A question this simple had never had a real home on the board at all.

Adaeze pulled the last quarter's AI-touching tickets and found what she expected: almost none had any compliance step attached, and the ones that did had it added after a manager happened to remember, not because the board asked for it.

A checkbox alone only works if everyone always reads it the same way. It never does.

She designed the fix around the one place every engineer already looks: the ticket template itself. A required field, answered before anyone can start work, plus a scanner reading the actual code diff as a second, independent check.

Four parts, and the old label was, at best, a rough sketch of just one of them.

The scanner wasn't optional for long. A pilot without it caught nothing the honest checkbox hadn't already caught.

Rolled out fully, the gate now adds real time to a sprint, but far less than it did on day one, as the team learns the shape of what actually triggers it.

The old board asked engineers to remember a courtesy that used to come naturally in a small team. The new one asks the same question of every single ticket, whether anyone remembers to or not.

I let a low-usage label get cleaned off the board because it genuinely looked like clutter at the time. It took a new hire's plain, unembarrassed question, not an incident, to see that low usage had been the whole problem quietly making itself worse.

SPARK, close upNot a policy rollout. SPARK is what forces you to name one concrete anchor, then prove it survives being wrong.

Cutting these on purpose is what kept the first version shippable at all.

The recap, one line per letter: situation is the optional courtesy ping that quietly disappeared, payoff is a normal scoping habit instead of a special process, anchor is the required field plus the merge-blocking task, risk is the scanner catching an honest wrong answer, and keep out is skipping the gate on internal tooling and skipping a full dashboard for now.

And if you want to be sure it really works, try it somewhere elseSame five letters, a secondhand-goods marketplace instead of a dev-tools board. This time the gate lives inside a listing-moderation queue, not a sprint ticket.

Reloop Marketplace runs an AI feature that auto-approves resale listings against a set of banned-item rules. Dashiell Pruitt owns the internal moderation queue trust and safety uses to manage that feature.

Mapped onto SPARK: situation is that trust and safety currently reviews a random sample of auto-approved listings each week, with no fixed rule for which new rule changes get a compliance look before shipping. Payoff is getting the team to treat "does this rule change affect a regulated category, alcohol, firearms parts, prescription items" as a normal question before any rule ships, not an afterthought. Anchor is a required field on every rule-change ticket, answered before it can be deployed, that auto-routes a "yes" to a named compliance reviewer with a 48-hour service level. Risk is a rule change that seems purely cosmetic, like a new search filter, quietly changing which banned items surface more often; a nightly scan of newly-surfaced listings against the banned-item list catches that even when the honest answer was "no." Keep out is not gating minor UI copy changes with no rule logic behind them at all.

A different board, a different kind of ticket, and the same three branches deciding who gets the gate.

Swap the trigger and it still runs.
Speed: an interviewer caps you at a minute. Say "put the question inside the ticket template itself, and back the honest answer with an automatic scanner," and stop.
Cost: leadership says a full scanner is a quarter's build. Ship the required field alone first, since it's nearly free and already beats the courtesy-ping status quo.
The model gets better, for real: if the AI assistant's own quality improves, that's still no reason to skip the gate. A better assistant that touches people's data without review is still touching people's data without review.

Where people run it wrong.
They build a compliance process that lives in a separate tool nobody opens during a normal sprint.
They trust the honest checkbox answer alone, with no independent check on the actual code.
They gate everything equally, which teaches people to click through the gate instead of actually reading it.

How to use it live. When this question comes up, name the one tool people already open every day, and put the question there. A process that lives anywhere else is a process people will eventually forget exists.

Flashcards (tap any card to flip it)

Check yourself Score: 0 / 0