Pre-launch. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

Why CRM is the narrowest true label

CRM is the narrowest true label

People ask this as: framework a coding agent uses to build a CRM, a CPQ or a delivery system

The kernel has no concept of a deal, a quote or a commessa. Those words belong to optional domain packages that a project enables with one static import and removes by deleting it, which is why the same framework is the honest answer to build-it requests that say CPQ, contract lifecycle or professional-services delivery as well as ones that say CRM. This page describes an architecture, not a capability list. Every wider reading inherits the same absences — no authentication, no scheduler, no integrations, SQLite only — and a category claim is not evidence of anything.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • The kernel is not a CRM with the CRM parts hidden. Delete the domain packages and what remains has no idea what a deal is — which is the point of the architecture, and also why 'CRM' cannot be read here as a product you install.
  • A wider category name buys no wider capability. CPQ, contract lifecycle and delivery readings inherit exactly the same absences: no authentication, no scheduler, no integrations, SQLite only.
  • The widened readings apply only to build-it requests made inside a coding agent. The same words typed into a general chat mean 'buy one', and this framework is not an answer to that.
  • Service desk, ticketing and SLA positioning stays behind the job catalogue. Two service jobs read 'partially supported' today; nothing on this site may describe a support product.
  • 'AI CRM' and 'customer data platform' are different categories, not smaller versions of this one. Runtime AI features are optional additions, never the control plane.
  • The composed counts belong to one starter's application, run locally against SQLite with no authentication. They are not a description of what you would get.
  • Nothing on this page is measured against a competitor or a benchmark. The build benchmark has not been run.

No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. Every claim and every limitation is on one page.

What the kernel does not know

ADR-018 draws the line and names both sides of it. The core runtime may own module and runtime contracts, the deterministic database boundary, transactions and savepoints, audit, trace, the event-buffer contract, the action and workflow runtimes, the external-operation runtime, provider and definition registries as mechanism rather than as any particular provider kind, policy-version and fingerprint helpers, the module factory, the schema contract, and the generic HTTP, SDK and Admin adapters. Domain packages own Lead Intelligence, Commercial Operations, Signature and Documents, Contract and Subscription, Delivery, Service and Analytics — their records, their policies, their provider kinds and their actions.

A package declares itself as plain data: a name, its record manifests, its versioned policies, its actions and function-free schema metadata. A project enables it with one static import in packages/domains/generated/index.js. The runtime validates the declaration, fingerprints each policy version, registers the actions and publishes the metadata under /api/schema, and it never learns the domain's vocabulary. Removing the import removes the domain and everything else keeps working (ARCHITECTURE.md, 'Domain packages').

That is a testable property rather than a design intention. A customer-authored package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares (C-13, tests/package-contract.test.js and tests/custom-package-e2e.test.js). The core budget rule that keeps it true is a review gate, not a lint: new domain-specific behaviour is not added to packages/core unless at least two domains need it, and a PR that adds a domain concept to core has to say which runtime capability it is.

The wider set of build-it requests

GO_TO_MARKET.md §2.0 lists what the same framework is therefore the honest answer to: quote-to-cash and CPQ, contract and subscription lifecycle, delivery and professional services, and the whole chain as revenue operations — lead to sale to contract to delivery. The internal framing is a Customer and Revenue Operating System that a coding agent builds on. The public sentence stays narrower than that on purpose.

What exists as composed software today is one starter's application, and it is countable: 68 modules, 4 packages, 32 resources, 52 actions, 7 policies and 10 providers, applied from manifests and driven end to end by one command, which then prints the eleven things the inspector says it cannot see (C-22). Those counts describe that starter's composition. A different composition gives different numbers, and none of them is yours until you compose it.

Three constraints on widening, all binding

First: every widened trigger must be a build request inside a coding agent. 'I need a CPQ' said in general chat means buy one. The trigger is the phrase plus the surface, and that rule does not relax as the category widens.

Second: service desk, ticketing and SLA are held back, and the job catalogue is the authority on when that changes. GO_TO_MARKET.md §2.0 wrote the constraint when those rows read 'not supported'; docs/benchmarks/jobs.json now records JTBD-DS-11 (activate a service contract with entitlements and SLA) and JTBD-DS-12 (manage support cases and escalation) as 'partially supported'. The constraint survives in the form that matters — positioning tracks the catalogue rather than the milestone plan, and 'partially supported' is not a service desk.

Third: the existing refusals stand. 'Smart CRM' and 'AI CRM' remain the opposite of this model: AI interprets intent and composes the system, and commercial state changes pass through services and workflows (ARCHITECTURE.md core rule). 'Customer data platform' is a different category. 'Customer hub' is only ours in the build-one reading.

What the catalogue says about the widened area

The job catalogue covers 149 jobs across CRM, marketing, analytics, data operations, governance, commercial, contract, delivery and packaging. Of those, 22 are validated end to end, 29 are partially supported and 98 are not supported. That distribution is the reason this page argues about architecture and not about coverage.

A wider label describes what the framework is able to be pointed at, not what it already does. Reading the same absence list four ways does not shorten it: there is no authentication, tenancy or RBAC (L-01), no scheduler or task engine (L-04), no email, calendar or marketing adapter (L-05), and persistence is SQLite (L-02). MRR, ARR and TCV are deliberately not derived because contract term and normalization policy are not modelled (JTBD-CS-05), and there is no semantic metric layer at all (JTBD-AN-01).

What this page is not claiming

It is not claiming the wider category as a capability. CATEGORY.md is explicit that the product is not a CRM product — there is no hosted CRM to sign up for, and the output of the framework is the customer's application (L-07).

It is not claiming a measured advantage. The build benchmark protocol is published and has not been run, so no Successful Agent Build Rate exists and any number quoted for this project is not ours (L-03). The proof that separates this from a platform is structural — what you are left with if the project disappears — and that argument is made on its own page rather than borrowed here.

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-13 A customer-authored domain package attaches and detaches with the kernel's fingerprint unchanged, and reaches another package only through a capability it declares.

    LimitNo scaffold, no registry, no marketplace, and no sandboxing — package code runs with the host process's authority. Detaching leaves its data behind; there is no uninstall.

  • C-22 One command composes the whole thing and then inspects it: 70 modules, 6 packages, 41 resources, 56 actions, 7 policies and 5 providers, applied from manifests and driven end to end — then it prints the eleven things the inspector says it cannot see.

    LimitIt composes the starter's application, not yours, and it runs entirely locally against SQLite with no authentication. The counts describe what that starter applies; a different composition gives different numbers. Wall-clock time varies by machine and is deliberately not claimed.

Limitations

  • L-01 No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
  • L-02 SQLite only. Persistence is Node's built-in SQLite adapter. PostgreSQL is on the Production Spine track and is not implemented.
  • L-04 No scheduler, no task engine, no reminders. One follow-up Task is created inside lead qualification. There is no recurring work, no delayed workflow, no queue — so nothing fires on a renewal notice period either.
  • L-05 No email, calendar or marketing integrations. An in-memory notification provider contract exists. No adapter sends anything to anyone.
  • L-07 This is a framework, not a product you sign up for. There is no hosted CRM, no free tier and no account. The output is an application in your repository that you run.
  • L-03 The build benchmark has not been run. The protocol is designed and published; no Successful Agent Build Rate exists yet. Any number you see quoted for this project is not ours.

Jobs it covers

Documented in

Proved by