No definition of done
The agent optimises for "the tests pass" or "the user stopped complaining". Nobody wrote down the real outcome, so nobody can check against it.
12C Foundry our software factory
Writing code got cheap. Knowing it's right didn't.
The Foundry turns your business — mapped as a Business Genome — into working software, and proves every change with the Eval Harness before it goes anywhere near production.
7 stagesGenome to learning, one line
9 gate checksNothing ships unproved
Yours to runCode, tests and data stay with you
The problem
Point AI at a backlog and you get output. Not software.
Every team can now produce code quickly. What most can't do is say why a change was made, whether it's correct, or what it costs. Four gaps cause almost all of it.
No gate
Every change is treated as equally risky. So either everything is waved through, or everything queues behind one senior person.
No shared context
Each person's AI rediscovers the business from scratch. The tenth internal tool doesn't know the first nine exist.
No feedback loop
Sessions run and are thrown away. The same failure is fixed forty times, in forty different ways, and nothing gets better.
The production line
One line, seven stages, a gate before production.
Work enters as a defined signal and leaves as a defined outcome. People appear where judgement is needed: setting the outcome, and looking at what's risky.
01
Genome
Your business mapped: processes, systems, decisions, KPIs.
→ shared context02
Spec
The outcome written down, with the tests that will prove it.
→ definition of done03
Assemble
Built from the component library first, new code only where needed.
→ working change04
Prove
The Eval Harness runs stubs and scenarios against the spec.
→ evidence05
Gate
Risk class decides what a human reviews and what flows through.
→ decision06
Run
Released with owner, approvals, spend caps, audit trail and rollback.
→ live outcome07
Learn
Every failure becomes a test. Every pattern becomes a component.
→ better next time
Eval Harness
Our testing product. Stubs for the parts, scenarios for the whole.
The Eval Harness is how the Foundry knows a change is right. It ships with every production line and stays with you afterwards, as your own regression suite.
Mode 01Unit testing
Stubs
A stub stands in for anything the code depends on — an ERP, a bank portal, a model, a colleague's service — and answers exactly as the real thing would, including on its bad days.
- Recorded from real responses, then frozen, so tests don't drift with the outside world
- Failure modes on purpose: timeouts, partial data, wrong formats, rate limits
- Runs in seconds on every change, with no live systems touched and no data leaving
- Pins the contract: if a supplier changes a field, the stub test fails before your users do
# stub: supplier invoice API, 3 recorded shapes
given invoice.pdf (scanned, 2 pages)
when extract_fields()
then total = 48,230.00 ✓
currency = MYR ✓
confidence < 0.8 → route to review ✓
Mode 02System testing
Scenarios
A scenario runs a whole business journey end to end, the way your team would describe it, and checks the outcome the business actually cares about.
- Written in business language from the Genome, so the people who own the process can read them
- Covers the awkward cases: partial shipments, disputed invoices, missing certificates, month-end
- Measures outcome, cost and time per run, not just "no errors"
- Every production incident becomes a new scenario, so the same failure can't return
# scenario: export shipment, EU buyer
given order + certificate claim + logs from 2 concessions
when documents are generated
then invoice, packing list, CoO, DDS all agree ✓
claim matches certificate scope ✓
prepared in < 10 min, < ₹20 of model cost ✓
The gate
Nine checks. A change passes, or it doesn't ship.
How hard the gate is depends on the risk class of the change. Low-risk work flows through on evidence alone; anything that touches money, customers or compliance waits for a person.
| Check | Question it answers | Evidence |
|---|---|---|
| Functional | Does it do the job described in the spec? | scenario pass rate |
| Accuracy | Is the output right against an agreed benchmark? | scored golden set |
| Integration | Does it call the right systems, the right way? | stub contract tests |
| Security | Can it reach only what it's allowed to? | permission + injection tests |
| Safety | How does it behave on ambiguous or hostile input? | red-team suite |
| Regression | Did this change break anything that worked? | full suite on every change |
| Performance | Is it fast enough at real volume? | load run |
| Cost | What does one transaction cost to run? | cost per run vs budget |
| Business impact | Did the number we agreed actually move? | before and after |
Why it compounds
The Genome is the reason the second build is faster than the first.
Most teams start every project from a blank page. The Foundry starts from what we already know about your business, and gives back more than it takes.
Business MRI →
Understand
Nine functions across your real end-to-end processes, people, systems and numbers.
→ Business Genome
Model
That understanding becomes a structured, scoreable map of the company that software can be built against.
→ Foundry
Build and prove
Specs, components and tests all reference the Genome, so nothing is invented twice.
→ back to the Genome
Learn
Running software feeds real data back: what broke, what cost too much, what changed.
Model and tool independent
Each task runs on the model and platform that suit it. Swap providers without rebuilding business logic — the tests prove the swap is safe.
Everything in code
Specs, components, stubs, scenarios, gates and routing rules are all versioned. "Improvement" is measurable, not a feeling.
Yours at the end
You own the code, the Genome, the Eval Harness and the data. Your team can run and change all of it without us.
How we start
One line first. Then as many as the business needs.
Step 01
1–2 weeks
Map and pick
A short Business MRI to find where the work actually hurts, and agree the one outcome worth proving first.
Step 02
30 days
First production line
One loop, built and running: spec, components, Eval Harness, gate, release. Part of our fee rides on the result.
Step 03
8–12 weeks
Stand up the Foundry
Your own lines, your component library, your test suites, your gates — with your team trained to run them.
Step 04
ongoing
Run it, or we do
Most clients ask us to keep operating it. Regulated ones take it in-house. Either way, the Foundry stays theirs.
Where we differ
Most tools start at the ticket. We start at the business.
Great at producing changes
They turn a ticket into a pull request. They don't know your processes, and they can't tell you whether the outcome was right for your business.
Great at the roadmap
Slides, target operating models and a plan. Then the building, testing and running is someone else's problem.
Full control, slow start
Method, gates, stubs and reuse take a year to get right. We bring them on day one and hand them over.
Start here
Bring us one problem worth fixing. We'll show you the line that fixes it.
Thirty days, one outcome, evidence you can check. If it doesn't move the number we agreed, part of our fee goes unpaid.