Turning a signed order into a contract and a subscription

What it models

plan-activation is read-only and safe for an agent: it reports what activation would create and writes nothing at all — no domain record, no business audit, no event. activate-contract then does everything in one transaction: the activation run, the contract, its immutable version, one line per order component, the subscription and its lines, and one pending delivery or service obligation per component that owes something beyond the money.

Identity is enforced by the database rather than by a check-then-write, so two concurrent activations — in one application or across two connections — produce exactly one contract. The Order is never modified; activation only sets its managed contract link. And the contract reads independently forever after: deactivate every offer, rewrite live component prices, publish a new catalog revision, rename the customer, and the contract and its lines do not move, because every value was copied from the Order and the customer name came from the Order's own party snapshot.

Recurrence is not a classification

The tempting rule — recurring becomes a subscription, one-time becomes delivery — is wrong in a way that silently mis-files real money. Annual premium support is recurring money and future service work at the same time; a single exclusive label has to drop one of them, and the first implementation dropped the subscription line, removing real recurring revenue from the Subscription.

So the policy answers two independent questions per component. The commercial axis returns subscription, non_subscription or ambiguous; the obligations axis returns any combination of delivery and service, an explicit empty list, or ambiguous. Every order component still becomes exactly one contract line whatever the answers are, and no obligation type is ever created twice for one component.

An empty obligations list is a decision. ambiguous is the absence of one, and it blocks activation until a human resolves that one axis of that one component with a stated reason. The single coherence rule the domain enforces regardless of policy or override: a subscription line must recur, so overriding a one-time charge into a subscription is 409 CLASSIFICATION_INCOHERENT — recording a one-time fee as a recurring right would put a false amount into every future recurring figure.

What the framework refuses

Only a user actor may activate; an agent is 403 HUMAN_APPROVAL_REQUIRED. A plan is not an authorization token — activation recomputes the whole classification inside the transaction from the Order, so a plan that looked activatable a minute ago does not make an activation succeed unless the same decisions are supplied again.

The client never supplies an amount, a product, a tier or a source hash. The only client inputs are the policy identity, three calendar dates and their required reason, two recorded renewal flags, and human overrides. Everything commercial is copied from the Order snapshot.

Activation refuses anything it cannot prove, each with a stable code: an order that is not accepted, an order with no completed signature evidence, an envelope, artifact and order that do not belong together, a disagreement on the signed document hash, a snapshot missing lines, components or totals, an order already activated, and a term that ended before the activation.

A policy that returns a Promise, an unknown type, an unbounded reason or that throws is a 500 and nothing is activated. Dates are validated by round-trip, so 2026-02-30 and 2026-13-01 are refused rather than normalized into a different day; autoRenew must be a strict boolean and a notice period requires it, because a notice against a renewal that cannot happen is a clause that can never apply.

How a coding agent builds it

This is the first domain built outside the kernel. Everything lives in an optional package: remove the single static import that registers it and the domain disappears while the kernel, the API, the SDK and every earlier milestone behave identically. The kernel gained one generic registry seam, one generic input type and an injectable clock, and a test scans the core sources and the static import graph to prove no contract, subscription or obligation concept entered it.

The activation policy is a versioned fingerprinted definition that decides from the component key, the SKU and the offer identity the Order already recorded — never from label text and never from recurrence alone. Its context is a deep-frozen structural clone of the Order snapshot, so a policy cannot mutate what it is classifying and never sees the live catalog. Config is inside the fingerprint, versions are published rather than edited, and v2 is how a decision changes while v1's historical activation still explains itself.

Both answers survive on the contract line: what the policy said, what applies, whether it was overridden, the override reason and who overrode it, on both axes. An activation is explainable years later without re-running anything.

Where it stops

Schema metadata publishes an explicit notModeled list, the plan payload carries its own, and the Admin prints it on the screen. The list is long on purpose: billing, invoicing, payment, usage rating, proration, ramps, minimum commitments, tax, FX, revenue recognition, MRR, ARR, TCV, amendments, seat changes, renewal, cancellation, and every downstream execution concept that later packages add.