Enterprise and SLA agreements

These optional task contracts are authored simulation rules. Their supplied jurisdiction label and clauses govern the task; they are not a statement of generally applicable law. Existing tasks without scenario.agreements retain their existing representation and mechanics.

An enterprise contract lists its authorized office, execution cutoff, required engineering hours, actual service window, acceptance cutoff, fee and settlement delay. Executing it earns nothing. Delivery credits only distinct, actually completed engineering commitments. One full commitment and multiple smaller commitments can both satisfy the same required hours. Starting, declaring or cancelling work cannot manufacture delivery. Cancelling an unfinished work commitment does not rescind an executed commercial obligation.

Acceptance is available after the service window closes, when both actual engineering work and the declared service test pass. The test counts only the listed customer segments and selected metric: core units or addon accesses. It enforces minimum eligible workload and uses integer basis points; exact equality satisfies the threshold. Acceptance recognizes the fee once and creates a receivable. Cash arrives only at the due date when payment is available. An optional installment cap limits collection per available day. Remaining receivables and unfulfilled executed obligations remain visible at the horizon.

An SLA lists the service window, exclusions, metric, minimum eligible work, publication delay, claim deadline, billed fee invoice, credit rate, cap and destination. The player receives contract terms from the start, but the measured SLA numerator and denominator are published only on the declared evidence date. A claim must cite that published receipt, come from an authorized office, meet the deadline, and correspond to a real billed invoice for the same vendor product. Its eligible fee cannot exceed the actual invoice face, and the immutable invoice service interval must contain the entire measured window. An optional vendor-contract productId explicitly associates the contract with its service product; an omitted association uses the contract ID as the legacy fallback. A product-scoped serviceWindow.productId measures that product alone, in its declared workload unit, so traffic from a healthy product cannot hide another product’s outage. Distinct term/invoice IDs and the immutable service interval provide the billing evidence. No unrelated addon invoice or old billing period can support the claim. A nonbreached or unmeasured service window cannot support a claim.

Credits are noncash balances restricted to future invoices for the same vendor product. They are neither a cash refund nor revenue and do not eliminate service obligations. Actual invoice face and remaining credit jointly cap each application, including when several agreements apply credits to one invoice. Repeated applications from the same agreement to that invoice are rejected. Unused credit remains a separately disclosed restricted entitlement at the horizon and contributes no face value to scored net assets. Only actual redemption reduces the matching invoice obligation. Issued vendor payables, accepted uninvoiced minimum/usage commitments, and unapplied customer cash remain liabilities; the invoice replaces its prior unbilled commitment rather than adding it twice. This credit contract explicitly does not offer rescission or cash refunds; those require a separate disclosed operation and accounting rule.

The implemented SLA eligibility rule is an all-cause eligible-work contract with explicit excluded days. It does not infer vendor blame from incident prose. More specific fault exclusions require additional independently executable rules. The public sources motivate the existence of acceptance conditions and evidence-bound credits, while the values and clauses here are authored:

• GitLab Deal Desk Handbook: feature-contingent transactions and nonstandard payment schedules.
• Amazon Compute SLA: measured availability, claim evidence, exclusions, credit caps and noncash destinations.

Verification independently reconstructs ordinary work, account membership and actual service, billed invoices, acceptance, settlement and credit balances. Rehashing false agreement events or the retained final state does not make those records valid. The final state is untrusted evidence and must agree with that reconstruction. An unmet required agreement is a valid failed outcome under agreementRequirements; missing or inconsistent proof instead makes verification invalid. Proper forecast scores remain separate from this contract constraint. Producer service summaries, requested hours, self-declared actor IDs and player-supplied invoice amounts are insufficient evidence.

The catalog composes these mechanisms into distinct operating contexts. The control manifest in src/catalog/agreements/test-manifest.ts declares units and consequential positive and negative controls. A recipe, passing unit test or source citation does not certify a new instance: protected issuance requires the matching registered feasibility certificate and independent checks described in private instances.