Every number here is one we can show you
A company that sells proof cannot afford to overstate anything. So this is exactly what exists, counted on the code that ships.
required evidence declared
on live infrastructure
by breaking what it protects
dependencies
A real ERP on Oracle went in. Proven business results came out.
We gave our dark factory a business process on an open-source ERP running on Oracle Database. An AI agent wrote the code, Oracle and PostgreSQL both ran it, and the Verdict Engine proved the results identical. It passed on the first attempt, in just over twelve minutes, and no person wrote or fixed a line.
signed verdict
no repair loop needed
fixed by a person
exactly, no tolerance
between the databases
Two AI agents build. The Verdict Engine decides.
Pip plans and Bolt builds, and both are AI. The Verdict Engine is not: it is a fixed program, qualified before use, that compares every field and names what differs without revealing the right answer. Each technology pair is shown with its status in the qualified-lane catalogue.
Three steps, with the rules fixed before the first one.
The rules were set before the AI started.
We locked in what “the same” means, the judge, the budget and the model before any code was written. Nobody could change the rules mid-run.
- Definition of “the same”
- The judge, version 3
- Budget: at most 11 AI calls
- The model and its settings
One AI call wrote the code.
The builder agent wrote the process against the ERP’s own interfaces in under six minutes. It never saw the expected answers, so it couldn’t pass by copying them.
17,321 tokens in · 11,441 out
Both databases ran it, and one verdict came back.
The code ran for real on Oracle and on PostgreSQL. The Verdict Engine compared the results, with money matched to the exact decimal. It passed, and the verdict was signed.
The whole run is public. Replay it yourself.
Every prompt, the generated code, raw captures from both databases, and the signed receipt. Replay it offline and you’ll get the same verdict.
$ python -m tools.publish_frozen_campaign verify \ --output ./evidence \ --trusted-key-sha256 c2fbae3453e8…f399f # expected result, from the run reportverified-complete-frozen-campaign replayed gates 1 passing dark_factory_run true new model calls 0 native executions 0
- Every prompt and model response
- The generated Java, exactly as it ran
- Raw captures from Oracle and PostgreSQL
- The frozen rules, judge and plan
- The signed receipt
An eight-service core banking application, Oracle to PostgreSQL, on GCP
CloudBank is Oracle's own core banking reference application. We took it end to end: schema, stored logic, messaging, identity and deployment — every step held to the same standard of evidence, with an autonomous factory doing the work and a deterministic gate deciding whether it counted.
Data and logic
Schema projection with type and scale fidelity, stored logic qualified as bounded supporting evidence rather than an unqualified claim.
Messaging
Oracle AQ replaced by a PostgreSQL durable work queue — row locks with SKIP LOCKED, at-least-once with idempotent keys, FIFO within an aggregate, governed dead-letter replay.
Identity
OAuth2/OIDC with client-credentials service identity and the JWT subject preserved through to account authorization. No static shared headers.
Platform
Kubernetes on GKE with immutable sha256 digest image policy, Cloud SQL PostgreSQL 16, and a cutover rehearsal contract that makes rollback mandatory and observed rather than documented.
Both lanes run in Google Cloud. The Verdict Engine sits between them, and neither can write to the other.
Every item above is backed by evidence you can inspect. No claim here stands on our word alone.
Fourteen things a bank asks before go-live. Ten are done, on both targets.
A migration is not finished when the data moves. This is the checklist we hold ourselves to, published exactly as it stands today.
| What | What it takes | State |
|---|---|---|
| Real infrastructure | Authorised clusters, not a laptop simulation. Cloud SQL and AlloyDB each qualified in their own right. | done |
| TLS | External termination and internal service identity | done |
| High availability | Regional failover exercised, not configured | done |
| Backup and restore | Restore to an exact normalized state hash | done |
| Cutover and rollback | Rollback mandatory and observed, not documented | done |
| Monitoring | Evidence emitted, not dashboards installed | done |
| Performance | Sustained business load, errors and latency bounded | done |
| External secrets | Managed store, rotation exercised, no static keys | done |
| Security | Workload identity and least privilege, exercised | done |
| Rolling deployment | Zero-downtime release path proven under load | done |
| Your data | Your real volumes and shapes, not synthetic minimums | not yet |
| Customer identity | Your IdP, not our authorization server | not yet |
| Customer approval | Your sign-off on the evidence, not ours | not yet |
| Production deployment | Running your business, not a rehearsal | not yet |
The four that remain need your environment, your data and your sign-off. They are not things we can complete alone, and we will not claim them until you have.
We build the factory. We also build what stops it.
We run an autonomous factory. It generates database transformations, it runs unattended, and it is gated by an engine that has refused its own output. That is how we know what a generator gets wrong — we watch ours get it wrong every week.
We do not sell the factory. We sell what stops it. Three agents propose. One deterministic judge, which never sees the expected values, decides whether the result counted. A person approves anything the judge is not permitted to.
Failure routes back carrying which field diverged, never the value it should have had.
Pick one of your Oracle business processes.
We’ll agree with you what “the same” means, run it through the factory, and hand you the evidence to judge for yourself.