Skip to content
Product · ODSF

The factory that builds the products.

An AI-operated factory — and laboratory — to make, enhance and maintain software. Not a tool. A process, with the machinery to run it: a sprint orchestrator, a live board, and six checks that decide what ships.

See it on your systemHow it works
98%
Work completed
1,355 of 1,381 items closed
182/184
Features delivered
99% of the planned programme
2.64
Defects per 1,000 lines
every line shipped — within the 1–5 published for a disciplined team
17 days
To reach this scope
against a 9–18 month norm — see /results for the caveat

Position as at 2 August 2026 on a live product. Full results →

What it is made of

Three pieces. You can point at all of them.

Not a methodology and not a prompt library. Each piece is a running program with a screen you can open, and the screenshots below are that screen on our own product this week.

1 · The orchestrator

Plans the sprint, hands each ticket to the role that owns that part of the codebase, runs the implementation passes, escalates what it cannot resolve, closes the sprint. The process is source code, not a document someone is supposed to follow — so it runs the same way on the fortieth sprint as the first, and there is no version of it that lives only in somebody’s head.

2 · The board

Every number on it is recomputed from the repository and the ticket log. Nothing is typed in, so nothing can be shaded. Blocked work turns red the hour it blocks, not at the next stand-up — the gap between “stuck” and “somebody knows” is where weeks go.

3 · Six quality gates

G1 to G6. Every change clears the same six before it can merge, and the gate decides, not the author — nothing ships because someone said it was fine. The thresholds tighten as the codebase grows, because the standard that was enough at ten files is not enough at a thousand.
The Sprint Board for sprint-21: overall status GREEN with quality, schedule and incident rate beside it; a velocity chart of completed work packages for each sprint from S1 to S21; and below it the work streams, each split into ready, in progress, blocked and done columns with the tickets in them.
Our own board, this week. The header strip is the whole status report: green or not, open bugs, schedule variance, gate failures. Blocked has its own column on every stream, which is the design — a queue that hides blocked work reports progress right up until the day it cannot.
How the work is assigned

Twelve specialist roles, and each one is fenced in.

“Twelve roles” on its own is an org chart anyone can type. What makes it real is the second and third columns below: each role owns a set of paths it may write, and a set it must not touch. The Backend Engineer cannot edit the frontend. The Compliance Engineer cannot edit either.

That is the mechanism behind the claim that quality holds as a product grows. One general-purpose agent with write access everywhere degrades as the codebase passes the size a single context can hold — it starts changing things it has not read. A role that cannot reach a directory cannot break it at 3am.

RoleOwnsOff-limits
TLTechnical Lead18—
POProduct Owner1014
BABusiness Analyst914
BEBackend Engineer3924
FEFrontend Engineer3614
DEData Engineer208
MLEML Engineer1014
QAQA / DevOps Engineer3016
SESecurity Engineer1119
CMCompliance Engineer1117
IEIntegration Engineer139
UXUI/UX Designer2118

The Technical Lead has no restricted paths, which is deliberate: it is the role that reviews across boundaries, and it is also the one an escalation reaches. Counts as at 5 September 2026, read from the board.

The Roles screen listing twelve AI-team role profiles — Business Analyst, Backend Engineer, Compliance Engineer, Data Engineer, Frontend Engineer, Integration Engineer, ML Engineer, Product Owner, QA/DevOps Engineer, Security Engineer and more — each showing how many paths it owns and how many are restricted, above a folder audit reporting zero orphan directories and one checker drift mismatch.
Each role opens onto its own prompt, its file-ownership guardrails and its definition of done. Note the audit strip at the top: it checks the role definitions against the directories that actually exist and reports drift — one mismatch, shown rather than hidden, which is the only reason the numbers below it are worth anything.
The idea

Agents do the work. Gates decide what ships.

The hard part of running AI agents on real software is not getting them to write code. It is knowing which of their output is safe to keep.

ODSF answers that with checks that run on every change and block on failure, and with a process where being blocked is loud, idleness is visible, and metrics are recomputed rather than reported. The factory is designed to be honest about its own state, because a factory that is optimistic about itself produces confident nonsense at scale.

It is installed into a project by symlink rather than copied per project, so improving the factory improves every product built on it at once — and a fix is never pending in three places.

Proof

It runs on itself.

The factory is built on its own line and passes its own checks. If it did not work, this is what would break first — which is a more demanding test than any case study.

A cybersecurity platform

165,000 lines, live, analysing threat data for security teams. The build the numbers come from.

An education platform

~147,000 lines. A different industry, a different stack, documentation in another language — brought onto the line in a day, and now maintained and extended for a client.

A system you already have

Mapped in about ten minutes, without overwriting a single existing document.
The numbers behind this

See it work on a system of yours.

Every NamiQ engagement runs on this factory, operated by our team. Start by having one system mapped at no charge. The write-up is yours either way, and so is everything the factory produces after it.

Talk to us