Authoring companies

The public catalog contains 24 product-specific companies and 349 task configurations: 156 original specifications, 169 playable mechanism candidates, and 24 composable growth tasks. The decision candidates cover 42 mechanisms across at least four company contexts each. The catalog includes 7-, 30-, 35-, 40-, 60-, 90-, 180- and 365-day tasks. Company IDs and names remain stable. Candidate counts do not establish admitted-task counts.

Each company has eight departments with enforced work capacity and recurring costs, a reproducible age distribution for opening customers, a declared mixture of monthly and annual core contracts, dated obligations, earned receivables, and two to four paid addon products. Addons use the same economic customer identities, with independent monthly billing, capacity and dependency graphs. Department payroll and company overhead are separate; their total preserves the authored operating budget.

These are synthetic company states. Public evidence supports mechanism design, financial distinctions and operating prerequisites. It does not estimate every population size, salary, adoption rate, failure probability or joint event rate. All current splits are public, including the split named test.

Files and boundaries

• data/companies.json defines the original company seeds and stable IDs.
• data/operating-companies.json explicitly defines department shares, product prices/costs/capacities and dependencies, runway, annual-contract shares and collection delays for each company. Optional onboarding settings select customer segments, actual setup work and delayed activation observations.
• data/tasks.json retains the 144 company-specific briefs and their existing IDs.
• data/operating-recipes.json maps 24 recipes to intended capabilities and accepted source-mechanism candidates.
• data/mechanism-contexts.json selects existing company contexts for the additional decision recipes in src/catalog/playable-mechanisms. Task-scoped onboarding settings avoid changing the other tasks for a company.
• src/catalog/scenario-events.ts and scenario-actions.ts instantiate the typed engine contracts; task compilation adds assessments and stability windows.
• data/evidence/manifest.json binds the public source corpus. The existing data/evidence/sources.json remains the original source catalog; new packages are merged by their stable source IDs, with quarantined claims excluded.

The original compileCompanies and compileTasks functions remain available for legacy fixtures. The default registry applies the operating compilers and adds the short tasks and explicit decision-mechanism candidates. Exported packages contain complete executable specifications, so a new company does not need to inherit the built-in recipe list.

Optional collections, vendor commitments and workforce coverage and enterprise/SLA agreements add typed task facilities with public terms and independent reconstruction. Their authored parameters and sources must remain explicit when composing them with growth, staffing and service events.

Create and validate a company package

bun run worldseq catalog export --task clearbeam.incident-week --out my-worlds.draft.json
# Edit the company/task specifications in my-worlds.draft.json.
bun run worldseq catalog prepare --file my-worlds.draft.json --out my-worlds.json
bun run worldseq catalog check --file my-worlds.json
WORLDSEQ_CATALOG_PATH=/absolute/path/my-worlds.json bun run dev

Run these commands from the worldseq package directory.

Start from one task and its company; omit --task to export the entire catalog. Packages contain declarative JSON, never downloaded executable plugins. Keep department hours reconciled to the company staff total, product dependencies acyclic, financial identities unique, and task deadlines inside the declared horizon. Every financing choice needs a dated principal/interest obligation. Cash from borrowing does not increase net assets. Opening receivables were earned before the episode; collecting them cannot recognize the revenue again.

catalog prepare recalculates every dependent task’s configuration signature and checks the entire package, including operating constraints and supported source mechanisms. It writes a new output file and leaves the draft untouched. Existing outputs are never overwritten. Preparation acknowledges the new configuration; it does not provide behavioral admission. Renaming companies, products, actions or events does not create a new executable problem.

Use an absolute WORLDSEQ_CATALOG_PATH: the development launcher changes its working directory. A custom package replaces the built-in catalog. It may define new companies and tasks using existing primitives, but JSON metadata cannot add new engine primitives or source mechanisms. Preserve public action/question IDs when reusing a built-in reference policy; a new task needs a compatible policy and its own admission evidence.

Set the same catalog path for evaluation, verification, submission commands and admission in other terminals as well. A path passed to the development server does not configure a separate CLI process. Keep the exact prepared package with its results: changing it invalidates the original execution binding.

Keep edits in a separate draft. If a terminal already points WORLDSEQ_CATALOG_PATH at an invalid edited file, unset it for preparation with env -u WORLDSEQ_CATALOG_PATH bun run worldseq catalog prepare --file draft.json --out worlds.json. The CLI validates a configured catalog before dispatching commands.

For a new mechanism, add short attributed claims and limitations to the evidence corpus first. Reuse existing engine primitives when they faithfully represent the causal path. If a missing primitive is necessary, implement and verify it before claiming that the source mechanism executes. A cited source alone cannot make an unsupported workflow realistic.

Events, interventions and assessments

Events can start on a reproducibly jittered date, follow another event, or react to a measured business condition. They can also follow a completed action, expire a protective control or target specific customer segments. Shared root causes do not multiply duplicate losses. Independent causes can overlap, constrain different products or departments, and recover separately. Customer and accounting consequences remain after the initiating event ends.

Work consumes its owning department’s capacity. Completion can change staffing, payroll, overhead, product adoption, procurement readiness, financing or recovery. Hiring, payroll reductions and alternative recovery routes have different costs and delays. Current addon renewal penalties are authored response assumptions; they are not calibrated customer behavior. Addons cancel on a failed renewal; core billing retains its own retry rules.

The built-in short-task compiler scales work, reporting and assessment clocks to fit the horizon. Editing horizonDays in an exported package does not regenerate those dates; authors must keep them consistent. Recovery objectives require both service delivery and paid customer/product continuity, so an empty customer population cannot count as a successful recovery. Stability windows cover the closing part of the episode, not the incident’s first day when recovery is still physically impossible.

The built-in paid-product continuity target is 45% of expected opening addon MRR. Adoption is conditional on paid prerequisites: a product’s contribution includes its own adoption probability and every unique ancestor’s probability. Shared ancestors count once, including in diamond-shaped dependency graphs. Multiply that joint probability by opening paid customers and monthly price, sum products, then round the final target. The realized opening amount varies by scenario.

Diagnosis tasks include collection causes that are observationally equivalent; their accepted groups prevent scoring an arbitrary hidden label as knowable. Other tasks offer a paid investigation that distinguishes plausible causes. Forecasts target their declared financial, service or cohort quantity; the grader reconstructs the outcome independently. Counterfactual forecasts use separate trusted intervention branches and expose no player reset or answer oracle.

Experiment tasks have beneficial, null and harmful treatment settings. A pilot draws from a separate simulated sample population. After results are published, rollout-control and rollout-treatment apply the corresponding authored conversion probability to future real customer trials. This is a consequential information-and-action loop; it is not empirical validation of a real SaaS RCT.

Behavioral admission

bun run worldseq catalog admit clearbeam.incident-week --out checks/incident

The output directory must be new. For a custom package, set its absolute WORLDSEQ_CATALOG_PATH and replace the example ID with one of its task IDs. The command executes idle and a public-information reference under two common public scenarios. Decision-mechanism tasks add their declared mechanism-specific control. It independently checks every complete trajectory, checks the reference against actual cash and continuity constraints, and measures the declared business outcome or assessment-loss contrast. Failed or inconclusive references remain unadmitted. It writes canonical behavior.json evidence and an admission.json report.

For registered --file or --all batches, Ctrl-C or SIGTERM pauses new launches and lets active tasks finish. Resume the same output with --resume; completed and failed attempts stay unchanged. Existing runtime and storage limits still apply while pausing. A successful pause means the checkpoint was retained, not that every task was admitted.

The witness also uses canonical support and reliability commitments to maintain the base service. These consume the normal capacity and project budgets. Financing considers the published cash floor and upcoming obligations; its repayment remains a liability. Proposed work must fit available cash after existing reservations.

The report binds the exact company/task, source mechanisms, evidence corpus and execution files. Source changes during a probe make its result inconclusive. The disclosed reference witness receives the public agent input. It is still a task-aware feasibility strategy, not a model-comparison baseline. A passing task probe establishes reproducible mechanical examples, not statistical power, strategy diversity, generalization or empirical calibration. Use the registered validation campaigns for those separate questions.

Catalog checks separate task inventory, structures with names and numeric parameters removed, represented source candidates and intended capability groups. The additional 169 decision candidates each declare a mechanism-specific business outcome or assessment-loss contract. Structure counts do not measure strategic diversity; matching frozen admission evidence must establish feasibility and the advertised mechanism’s consequence in every context that counts toward release coverage.

The separate mechanism validation cases exercise bounded source-grounded causal paths with explicit paired assertions. They are not published as ranked tasks: a mechanical fixture’s assertion is different from a useful CEO task objective. Candidate representation, executable certificates, empirical calibration and model performance remain separate claims.