Ship something new
Launch a product in a regulated vertical
Build the application on a kernel that already knows about policy, approvals and evidence, so the compliance work is architecture rather than a phase at the end.
The compliance work always arrives last
The product gets built, and then somebody asks the questions that decide whether it can ship.
Audit is a reconstruction
Who changed what, under whose authority, is answered by reading application logs and inferring. That works until somebody with a regulator behind them asks.
Approvals are a convention
The rule exists. Whether a given write obeyed it depends on whether the person writing that code knew about it.
The second vertical forks the first
Vertical two starts as a copy, diverges within two quarters, and now there are two products with one name and two teams.
Each of those is cheap to design in and expensive to retrofit, and they are always retrofitted, because they are invisible until the quarter they are not.
The shift
Three ways to build something a regulator will look at
The difference shows up eighteen months in.
Build it, then bolt governance on
Ships first, stalls later
Governance by policy document
Written down, not enforced
Governance as the kernel
Designed in, and provable
What we build
The application, on a kernel that carries the parts every regulated product needs.
One mutation path
Every domain change enters through the same gate. There is no second way in, which is what makes the guarantees mean anything.
Policy before effect
Checkpoints evaluate before a handler runs. An illegal transition is structurally impossible rather than caught in review.
Events as evidence
The event explaining a change is written in the same transaction as the change. Audit becomes a query rather than a forensic exercise.
Capabilities as contracts
Party, agreement, settlement published once and versioned, so vertical two consumes them rather than copying them.
Human approval in the runtime
The actions that need a person stop and wait, durably, and resume where they stopped.
The product itself
The interface, the API and the workflows, built by the same team, because a governed kernel with a bad product on top is still a bad product.
6
Products on one kernel, none of them forking it
Six of our own products sit on it
Airlift, Runway, Radar, Experiments, Harness and Tower are all built on the same kernel and none of them forked it. That is the bar the design has to clear, and it is checkable rather than asserted.
Clients we have done this for
Automotive / Fintech
SWBC
TechFabric rebuilt SWBC's LOSExpress platform for credit unions: the user experience, the design system, and the front-end architecture.
Automotive / Fintech
Location Services
Location Services moved off Synapse and SQL Server onto Databricks Lakehouse and Lakebase, converted with TechFabric Airlift and cut over in reversible waves. The rules engine that validates a repossession assignment on arrival now runs against governed lakehouse data.
FAQ
Governed product launch: common questions
Do we have to adopt the whole framework?
No. It is a library you register inside your own application rather than a platform you migrate onto. Most engagements route one domain's mutations through it and expand from there.
Which verticals has this been used in?
Automotive finance, lending and supply chain are where our published work sits. The kernel holds no industry vocabulary, which is the point: the meaning lives in packs above it.
Can we run it ourselves afterwards?
That is the intent. It is published on npm under Apache-2.0, the documentation is public, and the engagement ends with your team owning it.
If your problem is shaped differently
Build an agentic software factory
Take the AI demo to production
Move off the warehouse without a Friday night
Make the estate answer for itself
Modernise the estate that outgrew itself
Keep people in charge of the agents you already run
Leave your team able to do it without us
See what production is doing, and be allowed to act