Mechanism authoring

The catalog composes source-grounded mechanisms into distinct full-company contexts, alongside ordinary operating tasks and composable growth experiments. Task counts describe authored coverage, not causal calibration or model superiority. Controlled mechanism fixtures are a separate, narrower collection and must not be relabeled as playable company tasks.

Changing company terms, task requirements or executable mechanics changes the relevant identities. Preserve old results and qualify the new bindings; a completed historical release does not admit an unseen composition.

Authoring contracts

src/catalog/playable-mechanisms separates task composition, family-specific recipes, public reference policies and admission contracts. data/mechanism-contexts.json selects complete existing company specifications. Each recipe constructs a new task with a decision fork, operating events, named choices, public evidence, mechanism-specific objectives or assessment questions, and explicit limitations. The small builders only construct existing engine primitives.

The mixed contexts are Riff, Lucent, Stratum and Convene. They differ in channel, usage and seat billing, independent versus dependent product portfolios, procurement rules, opening cohorts and department allocations. Dependency tasks use Marlow, Meridian, Bastion and Tempo, including diamond, chain and branching product dependencies. Procurement tasks use Anvil, Stratum, Bastion and Cinder; their independent, chain and differently sized branching portfolios coexist with different operating stages and staffing. Names and numeric coefficients are removed before checking at least four distinct context structures. The platform dependency mechanism also uses Almanac as a distinct context; adding a context does not replace or erase a rejected result in another company.

Task IDs have the form <company-id>.decision-<mechanism-id>. Every recipe uses the normal company acquisition, churn, service costs, product subscriptions, dated liabilities and customer segments. No recipe substitutes the noise-free companies used by controlled reference fixtures. Staffed onboarding is a hashed task-level setting, leaving other tasks for the same company unchanged.

Public reference plans and admission

playableReferenceIntent(input, mode) receives the ordinary public agent DTO. It reads published notices, dated reports, commitments, pilot results, questions and offered financial terms. It has no engine state, event schedule, hidden effect, answer key or seed. The shared reference planner checks funding, recurring cost, department availability and prerequisites before accepting its proposed work. Ordinary maintenance remains active in both reference and mechanism-control runs.

playableAdmissionContract(company, task) is a pure function. It rejects missing or mismatched decision contracts rather than silently falling back to legacy admission. A business contract declares the outcome, direction, minimum meaningful difference and rationale before execution. Its control omits or changes the specific mechanism decision, retaining the same public maintenance procedure. Examples include withholding access restoration, retaining expired backup checks, choosing the stale snapshot, or retaining an unnecessary payroll commitment.

Five information mechanisms use independently graded forecasts: cash versus recurring value, annual prepaid service, billing units, opening-cohort denominators, and gross retention. Their controls keep operating decisions unchanged and apply an explicit public misconception. This prevents unrelated recovery or support work from being counted as evidence of financial or causal understanding. These forecasts are simple disclosed reference estimates; they are not fitted to seeds or guaranteed to beat their controls.

The denominator question names the report effective day 7. Both policies read that same original public report; the reference follows its exact dated correction, while the control retains the as-issued denominator. Missing required evidence leaves the forecast unsubmitted. The shared public input retains the latest 64 reports, enough to keep this original and its correction through the day-20 deadline. The paired policies share the forecast scale, outcome date, operating actions and declared admission threshold. This tests an authored reporting error and correction workflow, not the empirical frequency or magnitude of real reporting mistakes.

The gross-retention recipe includes an authored 20% future-renewal list-price proposal, paid approval and reconciliation work, and the existing addon offer. Both forecast policies apply the same quoted price once its approval notice is public; only their use of gross or net retained revenue differs. Actual paid renewals change recurring revenue, while fixed per-unit platform fees and existing paid entitlements remain intact. The task declares a day-40 submission cutoff, day-45 outcome, day-90 horizon and 0.01 loss-improvement threshold. Company response coefficients and addon adoption apply equally to both policies. The authored price proposal is not a calibrated effect or a promised admission; annual contracts reprice only at their real renewals.

Service reports separate each customer segment’s requested and failed core usage units from requested and failed paid-addon accesses. Their sum matches the existing service-shortfall measure; segment counts alone or core usage estimates do not describe that complete workload. These are completed-day receipts carried through the ordinary reporting delay, not current hidden availability. The exposure-priority reference waits for both public incident notices and a dated report covering them, then restores the group with more observed failed work first; its control reverses the same measured ordering. Both use the same scoring thresholds and company coefficients. A one-day observation is not a guarantee of future workloads.

Pilot tasks compare the evidence-selected arm with the other offered arm. That establishes prospective decision consequence if the retained results pass; it does not establish superiority over a realistic model baseline. Harmful or uninformative pilot outcomes can leave an admission inconclusive or rejected.

The non-renewal task requires actual customer contracts to receive approved exceptions. The independently reconstructed renewalExceptionsApplied metric prevents increased revenue from ignoring customer requests from satisfying the task. Paid-through entitlements and later invoices remain independently checked.

Verification and limitations

Structural checks require the declared mechanism inventory, distinct context coverage, complete source references and valid executable scenarios. Unit regressions check specification stability, context identity invariance, pure admission contracts, delayed public evidence, malformed pilot results, assessment controls and actual pending commitment cancellation. They do not simulate trajectories or admit tasks.

Development admission compares reference, mechanism-control and idle policies, retains every result, verifies primitive ledgers, and checks the declared contract and published objective windows. These comparisons test consequential mechanics. Release certification separately requires a legal feasibility witness and information fairness for every registered realization; a particular reference agent need not solve it. Failed witnesses, exhausted verification budgets and inconclusive results remain visible. Existing campaigns retain their original hashes and cannot certify a changed inventory.

Use catalog admit --all --out checks/catalog for the entire catalog. A bounded selection can use catalog admit --file admission.json --out checks/selection:

{
  "taskIds": [
    "draftlight.decision-cash-versus-recurring-revenue",
    "quiet-signal.decision-cash-versus-recurring-revenue"
  ],
  "workers": 2,
  "maxRuntimeSeconds": 3600,
  "maxStoredBytes": 1073741824
}

The task selection, two public seeds and resource limits are frozen before any trajectory starts. --resume continues an unchanged checkpoint; it cannot replace failed attempts or change the registered inventory. Reports describe only their selected tasks. Admission does not run model providers or submit results remotely.

Public evidence supports the named operational relationships. Work times, response rates, incident sizes, adoption, readiness windows and financial stress levels are authored. Communication handoff is staffed reactivation, not actual message delivery or estimated trust. Backup loss uses explicit work units, not database bytes. Pilot and live customers are separate synthetic populations. Existing parameter ensembles apply only when their exact runtime selectors are supported; a shared source label cannot make an incompatible task binding valid.