Modules
DirectionHow a project backend repository is organized in Continual.
A Continual backend and its apps live in one pnpm workspace.
12345678910your-company-os/ continual.config.ts apps/ runtime/ migrations/ src/modules/ orders/ # interfaces, objects, tools, metrics, loops, documents, skills vendors/ order-desk/ # optional user-facing app packages/ # shared source and UIModules are complete headless business capabilities composed by the backend. A module owns its interfaces, objects, tools, metrics, loops, documents, skills, and rules. It is the vertical unit of understanding and reuse: the second operation should depend explicitly on capabilities from the first rather than copying them.
Apps are optional workspace packages that render specialized experiences over the backend. They are separate executable and delivery units, but every release records the backend and app artifacts resolved from the same source revision and contract.
The composition root lists both explicitly. Nothing is discovered by convention or loaded from a database.
Authoring model
Define each interface, object, tool, metric, and operation once. Keep its schema, metadata, and behavior together, export the resulting immutable definition, and import definitions directly where they are used.
1234567const orders = await Order.list(ctx, { filters: { status: "ready" },})
await ShipOrder.call(ctx, { orderId: orders.data[0].id,})The runtime creates ctx for each authorized invocation. It carries request and execution state; it is not a dependency container. Backend code does not resolve domain services from ctx, and a project does not maintain separate handwritten contract and implementation trees. Continual derives the backend's MCP contract, documentation, and client types from the registered definitions.
Exported definition handles use PascalCase—Order, ShipOrder, OnTimeDelivery, and Fulfillment—while records, inputs, results, and ordinary functions use camelCase. Stable wire IDs also remain lower camel case.
Continual's framework internals may use classes and constructor injection for repositories, providers, and other stable infrastructure collaborators. That machinery is not part of the customer backend API.
Compose a module
Start with a business capability, not a technical layer. Keep the objects, tools, knowledge, skills, metrics, and loops that make the capability understandable together. Let other modules depend on its public contracts rather than its private tables.
1234567export const Fulfillment = defineModule({ id: "fulfillment", objects: [Order, Shipment], tools: [ReserveInventory, ShipOrder], metrics: [OnTimeDelivery], loops: [FulfillmentLoop],})Keep boundaries explicit
Definitions are ordinary source. Export them from a clear composition root, validate them before deployment, and keep generated contracts derived from the same source revision. This makes reuse visible and changes reviewable.