Kernel capabilities and ownership
What Fabric Platform ships today, which capabilities are optional, and where the ontology-kernel uplift belongs.
Fabric Platform is already the governed runtime and exported ontology-manifest seam of the Fabric kernel. It is not a database framework, workflow engine, message bus, UI framework, or vertical vocabulary. Those distinctions are part of the public contract.
Capability status
| Capability | Status | Owner and guarantee |
|---|---|---|
| Governed action invocation | Available | @fabricorg/platform-host; durable admission, policy, state-machine, handler, adapter, event, and recovery lifecycle |
| Versioned module-manifest export | Available | @fabricorg/platform/manifest; deterministic definitions-only output identified by MODULE_MANIFEST_VERSION |
| Action parameter JSON Schema export | Available when the validator supports it | Exported as parameterSchema; Platform has no runtime dependency on Zod or another schema library |
| Saga definitions and external signals | Available, runtime-neutral | SagaImplementation and SagaContext.awaitSignal; a Host runtime supplies durability |
| Projection replay | Available | replayEvents; deterministic ordering, tenant/space scoping, snapshots, cursors, and warnings |
| Atomic domain-write and canonical-event persistence | Optional Host capability | Requires transactionWithEvents and a transaction provider bound to the same database transaction |
| Execution-time reauthorization | Available | authorizeExecution rechecks parsed durable parameters before mutation on initial execution, approval resume, and recovery |
| Durable worker recovery and leasing | Available | Recoverable Host stores claim invocations with leases and preserve adapter checkpoints |
| Agent HITL | Optional Host capability | Agent-only routing can park an invocation for an authorized approval decision |
| Typed entity schemas | Available in manifest v2 | Portable JSON Schema, qualified relations, semantic annotations, and enforcement-owned invariants |
| Versioned views | Available | Logical replay contracts and snapshot/event-version compatibility; physical stores remain adapters |
| Archetype conformance | Available in a separate pre-1.0 package | @fabricorg/archetypes; never built into Platform's vertical-free runtime |
| Compiler and generators | Available build-time packages | Deterministic consumers of exported manifests, outside runtime |
| Outbox relay and Temporal binding | Available optional Host integrations | Separately versioned operational integrations, not portable runtime behavior |
The existing manifest seam
exportModuleManifest and exportModuleManifestBundle turn live FabricModule declarations into
stable JSON without registering the modules or serializing executable functions. This is the seam
that future compiler and generator packages consume; the uplift does not introduce a parallel
definition format.
The current wire contract is manifest version 2. Consumers must check MODULE_MANIFEST_VERSION.
normalizeModuleManifest lets v2 readers accept v1 input while preserving missing fields as absent;
no down-conversion is promised.
Runtime and integration ownership
Temporal may schedule, signal, and recover governed invocations, but it is not a second mutation authority. An event-bus relay may deliver canonical events, but its delivery checkpoint is not the event source of truth. Prisma, GraphQL, and SDUI generators may consume a manifest, but Platform does not require their dependencies.
Atomicity is capability-based
transactionWithEvents is optional. A production store can claim atomic domain writes and canonical
events only when its transaction provider binds the application TDb, event sequence allocation,
event append, and invocation update to the same database transaction. Legacy stores remain supported
but cannot claim that atomicity. Merely using store.transaction() does not provide atomicity across
an unrelated application database.