Applications decide
- Product UX, routes, and presentation models
- Vertical meaning and domain vocabulary
- Which persistence client binds TDb
- How operators and customers experience the system
Ontology-first runtime · SDK v0.9.0
Fabric Platform
Ontology-nativeagents.
Governed actions, identity, and an agent-native application runtime. Platform owns the mutation boundary; applications own product UX.
$ pnpm add @fabricorg/platform
- Platform runtime
- v0.9.0
- Core package
- Zero deps
- Every mutation
- One pipeline
- Shared invokeAction
- Agent-native
Fabric ecosystem
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. Apps own product UX.
People often treat Fabric Platform as another application framework. That is the wrong layer. The product surface stays in your app. Platform is the ontology-native runtime for governed actions, identity into those actions, and agent-safe contracts.
Platform decides
- How ontology actions, policies, and state machines compose
- How every mutation enters one governed pipeline
- 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 Fabric Harness. If the work is domain mutation with policy and evidence, start here. Read the architecture concepts.
When the platform earns its keep
Three failure modes side doors create.
Lead with outcomes, not a catalog of packages. Platform differentiates when agents write state, when audit is reconstructed after the fact, or when a vertical forks the core.
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 — 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
Ontology and governed mutation
are the product boundary.
CRUD tables, private agent tools, and request-scoped writes exist everywhere. Platform starts where those patterns stop: one pipeline, shared policy, and evidence that survives the request.
How it works
Declare once. Gate every write. Project the evidence.
A coherent contract from a minimal in-memory vertical to production hosts with your store, policy engine, and product UI.
- 01
Declare the ontology
Register object types, actions, policies, and state machines as a FabricModule. The platform owns mechanics; your vertical owns meaning.
- 02
Invoke through one gate
Session, signed token, or system/agent path — every mutation enters invokeAction. Policy and transitions run before handlers mutate state.
- 03
Project evidence outward
Handlers emit AssetEvents. Projections build read models. Replay rebuilds views. Product UX stays outside the mutation boundary.
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.
UI click, AI agent call, signed-token request, 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 — UI, agent, token, or 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 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 Fabric 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.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.
Fabric Platform is built and supported by TechFabric.
Contact TechFabric