Applications decide
- Product UX, routes, and presentation models
- Vertical meaning and domain vocabulary
- Which capabilities an organisation publishes, and when
- Which persistence client binds TDb
Composable kernel · SDK v1.5.1
Composable, and enforced.
An enterprise composable architecture says a capability is built once and reused everywhere. TechFabric Platform is what makes that stick: capabilities publish contracts, every write passes one governed pipeline, and surfaces render from view contracts they cannot write behind.
$ pnpm add @fabricorg/platform
platform · the governed pipelineevidence at every step
- 01
ACTOR
Session, signed token, system or agent: one caller model
- 02
ACTION
Every mutation enters through invokeAction
- 03
POLICY GATE
Checkpoints pass, warn, or block with reasons
- 04
HANDLER
State machines constrain transitions before side effects
- 05
EVENT
AssetEvents feed projections and the audit trail
- Platform runtime
- v1.5.1
- One kernel
- Four planes
- Every mutation
- One pipeline
- The experience seam
- JSON contracts
Runs on
One platform · portable foundations
Zero-dependency runtime contracts that bind to your persistence client, policy engines, and vertical modules without rewriting product UX.
TypeScriptTDb-boundOPA-readyEvent-sourcedAgent-nativeBYO store
The 30 second answer
Platform owns the mutation boundary. Everything above it composes.
People reach for TechFabric Platform as another application framework, which is the wrong layer to put it at. Your product surface stays yours. What Platform owns is the kernel the composable planes sit on: governed actions, the identity that reaches them, and the contracts a capability or a screen is held to.
Platform decides
- How ontology actions, policies, and state machines compose
- How every mutation enters one governed pipeline
- What a capability contract promises, and when it has to version
- What a surface may render, and which intents it may raise
- How agents and humans share invokeAction without side doors
- How events, evidence, and projections stay reconstructable
If you need durable agent sessions, sandboxes, and portable runtimes, pair with TechFabric Harness. If the work is domain mutation with policy and evidence, start here. Read the architecture concepts.
Enterprise composable architecture
Four planes, and only one of them is ours.
Composable is an operating decision before it is an architecture: the parts every line of business needs get built once and reused, and everything above them is configuration. The decision is only real if something enforces it, because a framework that relies on discipline forks the first time a deadline is tight.
Experience tier
How a surface is assembled. Promotion, scoped plans, cached templates, design tokens, renderers.
Can a business unit change it alone? Freely, within the view contract it was given.
Vertical packs
Industry meaning. Origination, refinance, collections, encounters, repair orders.
Can a business unit change it alone? Freely, and without a second write path or a forked kernel.
Shared capabilities
The FabricModules an organisation publishes once. Party, offering, agreement, settlement, compliance.
Can a business unit change it alone? By publishing a new contract version, never by editing the old one.
Platform kernel
Mechanism. Actions, policy, state machines, events, projections, tenancy, durable hosts.
Can a business unit change it alone? No. This is the part that has to be the same everywhere.
The bar the design has to clear is that two unlike verticals compose and render with no kernel change and no compositor change. The long version, with the certification fixtures that hold it to that, is on the framework page.
The seam
Contracts in both directions.
A plane boundary that is only a diagram is a boundary that moves. These two are data, they are versioned, and CI fails when one drifts.
When the platform earns its keep
Four ways a composable programme quietly stops being one.
Every one of these starts as a reasonable local decision under time pressure. None of them announces itself, and all four are only preventable by something that fails a build rather than by something written down.
Every vertical rebuilds the same capability
Three business units each hold their own idea of what a customer is. The shared capability was a slide, nothing enforced it, and the second deadline forked it.
With Platform. A capability publishes a versioned contract that CI checks. A consumer depends on the contract rather than the source, and a change ships as a new version instead of an edit to a live one.
The screen decides what it may write
Authorization drifts into the compositor. A new surface gets a slightly different rule, and now the answer to who may do this depends on which screen you came from.
With Platform. The experience tier talks in JSON contracts. An intent resolves to an action the policy already gates, so no authorization decision lives above the seam.
Agents bypass the product
A model gets a raw SQL tool or a private API. Mutations skip product policy, leave no audit trail, and nobody can reconstruct what changed.
With Platform. Agents call the same invokeAction surface as the UI. Policy, state machines, and evidence attach before side effects land, with no special AI endpoint.
Governance is bolted on later
Handlers write state first. Compliance asks for proof. You scrape logs and hope the critical path left a breadcrumb.
With Platform. Policies evaluate at checkpoints. AssetEvents are immutable evidence. Projections rebuild read models; audit is not a retrofit.
Verticals leak into the runtime
Lending vocabulary, Prisma drivers, and product routes entangle the platform. The next vertical rewrites half the core.
With Platform. Platform stays vertical-agnostic and TDb-parameterized. Boundary tests reject domain words and concrete database clients in the core.
The product boundary
Composable is a promise.
A kernel is what keeps it.
Reference architectures, capability catalogues and shared-service mandates all describe the same intent, and they hold for about as long as the next deadline. Platform starts where the intent stops being enough, with one pipeline, versioned contracts, and evidence that survives the request.
How it works
Declare it once, and every write goes through the same door.
The same shape holds from a minimal in-memory vertical to production hosts running your store, your policy engine and your own product UI.
- 01
Declare the ontology
Register object types, actions, policies and state machines as a FabricModule. The platform owns mechanics, and your vertical owns meaning.
- 02
Publish the capability
The module ships a versioned contract. Every vertical that needs a customer, an agreement or a settlement consumes that rather than writing its own.
- 03
Invoke through one gate
A session, a signed token or a system path: every mutation enters invokeAction, and policy and transitions run before a handler touches state.
- 04
Render from a contract
Handlers emit AssetEvents and projections build read models. The experience tier reads those through a view contract and raises intents back through the same gate.
Call paths
Three ways in. No fourth path.
Every mutation reaches invokeAction through one of three paths, each with its own auth model, all with the same policy gate.
The Platform difference
Ontology and governed mutation are the product boundary.
Agent loops and CRUD APIs exist in many stacks. Platform differentiates where domain writes must stay policy-bound, agent-safe, vertical-portable, and reconstructable from evidence.
Ontology, not CRUD tables
Object types, actions, events, policies, and state machines are first-class. Product screens are projections of that vocabulary.
One mutation pipeline
UI clicks, agent tools, magic links, and scheduled workers share invokeAction. There is no fourth path and no silent write.
Policy before effect
Checkpoints evaluate before handlers and adapters run. Outcomes pass, warn, or block with reasons that survive the request.
Events as evidence
Immutable AssetEvents record what happened. Projections derive views; replay rebuilds them without losing source truth.
Portable core contracts
Zero runtime dependencies, no embedded ORM, TDb-parameterized persistence, and CI boundary tests against vertical leakage.
Complete runtime
Everything around the mutation boundary, in one coherent contract.
The differentiators are ontology, one pipeline, and agent-native governance. The package also ships the registries, host contracts, and patterns needed to bind a real vertical.
Action pipeline
A single entry point for mutation from trigger to projection.
- Triggers and call paths
- Policy evaluation
- State machines
- Handlers and sagas
- Adapters
- Projections
Ontology and entities
Structure the domain without burying invariants in handlers.
- Object types
- Entity invariants
- Built-in contracts
- Vertical extensions
- Module manifests
Governance
Treat policy as part of the runtime, not a later compliance layer.
- Policy model
- Enforcement modes
- Audit trail
- External effects
- BYO policy engines
- Compliance patterns
Agent contracts
Make agents first-class callers of the same governed surface.
- Agent-native architecture
- Agent API
- HITL approvals
- Credential scopes
- Platform Host gateway
Events and evidence
Keep every state change reconstructable and attributable.
- AssetEvent envelopes
- Event schema
- Projections
- Replay
- Evidence packs
Runtime guarantees
Stay portable across persistence clients and verticals.
- Zero runtime dependencies
- TDb parameterization
- Boundary tests
- No vertical vocabulary
- Host and worker stores
Workloads
Built for governed business systems
Use the same runtime for product backends, agent-facing domains, vertical modules, compliance planes, and event-sourced read models.
The one-line invariant
Every mutation. One governed pipeline.
A UI click, an AI agent call, a signed-token request, a scheduled worker: every domain mutation travels the same path. There are no exceptions and no side doors.
- Policy checkpoints before handlers and adapters
- State machines constrain legal transitions
- AssetEvents are immutable evidence
- Agents and humans share invokeAction
mutation-pipeline.ts
// Every domain mutation, from a UI, an agent, a token or a worker,
// enters through the same governed path.
Actor
→ ActionInvocation
→ PolicyEvaluation
→ StateMachine
→ Handler / Saga
→ AdapterInvocation
→ AssetEvent
→ Projection
// Agents and humans both call invokeAction.
// Policy treats them by capability, not by caller type.What @fabricorg/platform is
Portable. Boundary-tested. Yours to bind.
The package is a set of contracts and a pipeline, not a full-stack product. It stays portable because the boundary is enforced by tests, not convention.
- 01
Zero dependencies
The runtime core ships with zero runtime dependencies.
- 02
No database client
No ORM, no driver, no persistence opinion in the core.
- 03
No vertical vocabulary
Domain words never leak into platform contracts.
- 04
Parameterised persistence
Every contract is parameterised by TDb so you bind your own client.
- 05
Boundary-tested in CI
Vertical names, Prisma, and concrete database imports fail CI if they leak in.
FAQ
Straight answers to the boundary questions
Use these when someone asks what Platform owns, how agents fit, or how this relates to Harness.
What is an enterprise composable architecture?
It is the decision that the parts of a business every line of business needs, such as who a customer is, what they agreed to and how value moved, get built once and reused, with everything above them treated as configuration. The architecture is the part that makes the decision survive contact with a deadline. The long version is here.
Is TechFabric Platform a composable framework, or the thing underneath one?
Underneath. Platform is the kernel: actions, policy, state machines, events, projections and tenancy, plus the contracts a capability or a surface is held to. It ships no catalogue of business capabilities, renders no screens and knows no industry vocabulary. Your capability packages and your applications carry that meaning.
What is a view contract, and is this server-driven UI?
A view contract declares what a surface may render and which intents it may raise, as data rather than as code. It is the SDUI idea with the authorization question removed from the client: an intent resolves to an action policy already gates, so no screen decides what it is allowed to write. View contracts.
What stops a business unit forking the kernel when a deadline is tight?
Boundary tests that fail the build. The core rejects domain vocabulary and concrete database clients, capability contracts are compatibility-checked in CI, and the composition bar is that two unlike verticals render with no kernel change and no compositor change. A rule nothing enforces is a rule that lasts until the first hard quarter.
What does Platform own versus my application?
Platform owns ontology contracts, governed mutations, identity binding into
invokeAction, events as evidence, and agent runtime contracts. Your application owns product UX, routing, presentation models, and vertical meaning. See ontology-based design.How do agents relate to the mutation pipeline?
Agents do not get a private write path. They call invokeAction with credential scopes. Policy, state machines, handlers, adapters, and events treat them like any other authorized actor.
Does Platform replace my database or ORM?
No. The core has zero runtime dependencies and no embedded driver. Contracts are parameterized by TDb so you bind your own persistence client and projection store.
How is this different from TechFabric Harness?
Harness owns durable agent control, sessions, tools, sandboxes, recovery, and portable runtimes. Platform owns the ontology-native application mutation boundary those agents (and humans) call into. They compose; neither replaces the other.
Can I bring my own policy engine?
Yes. Platform defines the evaluation contract and checkpoint model. You can attach code policies or external engines such as OPA. See BYO engine.
Where should I start?
Run the quickstart or clone
examples/minimal-vertical to walk one action through policy, state, handler, event, and projection.Contact
Talk to the team behind TechFabric Platform.
Evaluating Platform for a regulated vertical, or looking for a governed mutation boundary underneath your agents? Send a note and an engineer replies.
TypeScript runtime · portable contracts
Bind your ontology. The pipeline is already governed.
Define an entity, register an action, and watch the invocation travel policy, state, handler and projection, with evidence emitted at every step.
Enterprise Composable Framework →Questions? Talk to the team →
TechFabric Platform is built and supported by TechFabric.
Contact the team