Governed composable framework
Build the capability once, ship it in every vertical
The kernel under an enterprise composable architecture. Capabilities publish once as versioned contracts, every mutation passes one governed pipeline, and surfaces render from view contracts they cannot write behind.
- Role in the family
- Governed composable framework
- Databricks surfaces
- Lakebase / PostgresUnity CatalogDatabricks Apps
- Status
- Published on npm as @fabricorg/platform. Every other accelerator on this page consumes it.
- Documentation
- platform.techfabric.com
The problem
In most enterprise systems, a row changes and nothing explains why. Audit means reading application logs and guessing. When an AI agent is one of the actors, that gap stops being an inconvenience and becomes a governance failure.
How it works
Every domain change passes through one mutation pipeline: Actor, Action, Policy, State Machine, Handler, Adapter, Event, Projection. No exceptions and no bypasses. The event log is authoritative and read models are derived from it, so state is replayable.
What it does
One auditable entry point
Every state change goes through invokeAction. There is no second path into the domain.
Policies at every checkpoint
Code, data, or hybrid policies evaluated before a transition is allowed, not inside a prompt.
Declarative state machines
Illegal transitions are structurally impossible, so handler code has nothing to defend against.
Agent-equivalent governance
An AI actor passes exactly the same gates as a human one. Same pipeline, same policies, same audit trail.
Your auditors get an answer that holds. Every state change carries the actor, the policy that allowed it, and the event that explains it, so an audit becomes a query instead of a reconstruction. Teams adopting it stop building a bespoke approval and audit layer for every application.
Composable, until the first hard deadline
Every enterprise has decided that the parts each line of business needs get built once and reused. The decision is real. What is usually missing is anything that enforces it, and it shows up in three places.
Three teams, three customers
Party, agreement and settlement were supposed to be shared. Each business unit now holds its own version, and reconciling them is a quarterly project nobody owns.
The screen decides what it may write
Authorization drifts into the compositor. A new surface gets a slightly different rule, and who may do a thing now depends on which screen you came from.
Governance is a document
The policy exists. Whether a given write obeyed it is answered by reading application logs and inferring, which is not an answer an auditor accepts.
All three trace to the same thing. The rules live in review and convention rather than in a mechanism, and a rule nothing enforces lasts until the first quarter somebody is late.
The shift
Three ways to build for many verticals. Two of them fork.
Every enterprise picks one of these, usually without deciding to.
A codebase per vertical
Fast to start, and it multiplies
A shared library nobody enforces
Correct on paper
One kernel, meaning in the packs above
One mechanism, many verticals
Four planes, and only one of them is ours
The framework separates four planes. Each has a different owner, a different rate of change, and a different answer to whether a business unit can change it without asking anyone.
Platform kernel
Actions, policy, state machines, events, projections, tenancy and durable hosts. The part that has to be the same everywhere, and the only plane we own.
Shared capabilities
The modules an organisation publishes once: party, offering, agreement, settlement, compliance. Changed by publishing a new contract version, never by editing a live one.
Vertical packs
Industry meaning. Origination, refinance, collections, encounters, repair orders. Changed freely, and without a second write path or a forked kernel.
Experience tier
How a surface is assembled: promotion, scoped plans, cached templates, design tokens, renderers. Free to move, inside the view contract it was given.
Capability contracts
What a shared capability promises, versioned, with compatibility checked in CI rather than in review. A consumer depends on the contract instead of the source.
View contracts
What a surface may render and which intents it may raise, as data. An intent resolves to an action policy already gates, so no authorization decision lives above the seam.
6
Products on one kernel, none of them forking it
Six of our own products are built on it
Platform is not a reference architecture we drew. Airlift, Runway, Radar, Experiments, Harness and Tower are all built on the same kernel, which is what makes the composition bar checkable: two unlike verticals compose and render with no kernel change and no compositor change. It is published on npm as @fabricorg/platform under Apache-2.0.
FAQ
TechFabric Platform, answered
Do we have to adopt the whole platform to use it?
No. It is a library you register inside your own application, not a system you migrate onto. You start by routing one domain's mutations through it and expand from there.
How is this different from an audit log?
An audit log records that something changed. This makes the change impossible unless a policy allowed it, and the event that explains why is emitted as part of the same transaction. You audit by running a query.
Does it work for AI agents as well as people?
That is the reason it exists. An agent actor passes exactly the same policy and state-machine gates as a human one, with the same audit trail. There is no separate, weaker path for automation.