Support entitlements and SLA tracking, activated from a contract

What it models

A coverage moves planned to active to ended. Activating consumes the contract's pending service obligations and writes an immutable activation run naming which obligations were consumed under which policy version, plus one immutable entitlement per obligation saying what that obligation entitles the customer to — categories, priorities, channels, targets and limits.

A support case is recorded against an entitlement and moves over a declared table: new, in progress, waiting customer, resolved, closed. Case activity is append-only — notes, transitions, recorded replies and escalations. A first response is stamped exactly once. An SLA evaluation is an immutable judgement about an instant, storing the instant and the input values it used so it is never mistaken for current truth, and an escalation is an immutable record that a human escalated something.

Ten actions cover the path, and only two of them are readable by an agent: planning an activation, which writes nothing at all, and previewing an SLA. Every write requires a user actor.

The SLA contract, stated exactly

First response is due at the case opening plus the first-response target in minutes; resolution is due at the opening plus the resolution target. That is elapsed wall-clock time against an injected UTC clock, which is what makes a run reproducible.

There is no business-hours calendar, no holiday table, no timezone interpretation and no paused clock. Waiting on the customer does not stop it — not because pausing is wrong, but because a half-implemented pause understates a breach, and understating a breach is the one failure mode an SLA feature cannot have.

The Admin renders current SLA and recorded SLA as two separate blocks, and says on the screen that an SLA state here is elapsed wall-clock time rather than a contractual or legal determination. Previewing writes nothing.

What the framework refuses

An activation policy may answer ambiguous, and that is the interesting case: an obligation it cannot classify refuses activation until a human supplies an override with a stated reason, because a defaulted support tier is a promise nobody in the business made.

Entitlement is enforced server-side, not in the UI. An uncovered category, an uncovered priority, a coverage that is out of date or a full open-case limit is refused — and exceeding a limit bills nothing, because there is nothing to bill with. The Admin is state-aware in both directions: before activation it offers planning and nothing else, while any obligation is undecided there is no coverage form and no activation control at all, and after activation there is no second activation path. A case shows exactly the transitions the declared table allows for its current state, a first response is offered until it is stamped and never again, and a closed case shows no transition control and says why.

The screen carries the claims a reader would otherwise make on the framework's behalf: that a coverage is operational evidence and amends no commercial record, that a listed channel does not mean a provider is connected, that no notification was sent.

Why it is coverage and not a contract

Three shapes were compared before this was built. Hanging support off the Commercial Contract would mix a mutable operational lifecycle into a record whose entire value is that it does not move. A second legal ServiceContract would be a claim the framework cannot support: this repository has exactly one signature path, producing exactly one signed Order and one Commercial Contract, and a second contract nobody signed — with no envelope, no signer and no artifact — would invite the question which one is authoritative, which neither could answer.

The name is the trap. Anything called Contract here will be read as signed, so the concept is Service Coverage and the first paragraph of every document about it says what it is not.

How a coding agent builds it

Service is the third domain package and the second that depends on another. It declares one capability against the contracts package and imports nothing from that package's source and nothing from the kernel's. Removing the single static import removes the domain and everything else keeps working — including the capability contracts goes on providing to nobody.

The Admin section is package-scoped rather than package-owned, and this is published as a limitation rather than smoothed over: the framework has no seam for a package to contribute an Admin extension, so the file lives in the Admin app and renders only while the schema publishes the service domain. Remove the package and the section disappears instead of degrading into a broken control.

The activation policy is versioned and fingerprinted like every other policy in this framework: config is inside the fingerprint, versions are published rather than edited, and a recorded activation explains itself later without re-running anything.

Where it stops

An upgrade suite proves a project shipped before this package existed can adopt it over live obligations, and the starter runs the full journey from a pending obligation to a closed case with the commercial rows fingerprinted before and after. What it does not do is a long list, published in the schema and printed on the screen, and it starts with billing and ends with a scheduler.

Common questions