Evidence and licensing

worldseq ships a public, authored simulation corpus. It does not ship a recovered history of a real SaaS business, a validated causal model of SaaS customers, or a confidential test set. The data supports testing diagnosis, causal reasoning, resource allocation, recovery and plan revision inside stated business mechanics with delayed feedback. Real-world predictive validity remains unestablished.

The source registry records publisher URLs, retrieval method, checked dates, population, period, reuse status and claim-specific limitations. The corpus manifest binds source packages, mechanism claims, reference chronologies and authored parameter ensembles. Loading a source does not establish engine admission or causal calibration. Public access is not permission to redistribute the website or its underlying records.

What the evidence supports

Examples of bounded incident facts: Buffer’s AWS postmortem describes roughly 15 hours 38 minutes of disruption with login, publishing and analytics effects; the Bluesky postmortem reports roughly 22 hours, 707 affected organizations and about 2,000 failed posts. These are individual operational episodes. They justify plausible causal chains and recovery work, not independent random draws with invented empirical frequencies.

Startup archetypes and representativeness

The 24 public companies span six SaaS families, with discovery, growth, resilience and transition variants in each family. These are recognizable operating contexts, not a representative sample of all startups or reconstructed company histories.

The source registry and table above identify the grounding. In particular, PostHog’s analytics pricing describes recurring free usage; it should not be inferred from the public developer-tool worlds’ trial mechanics. The separately distributed Moraine overview describes a different usage-billing model. Public access to that overview does not expose its private tasks or validate their coverage.

Company descriptions provide business context. A story about connecting channels, installing tracking or inviting teammates does not by itself imply separate state for those actions. Generic onboarding improvements change conversion behavior; explicit customer delivery work is modeled only where an onboarding specification is configured. Likewise, eight named departments do not imply eight equally detailed organizational simulations. The challenge tags identify implemented challenge categories across each company’s tasks.

Opening cash, staffing, response rates, costs and incident schedules are authored. Stage labels do not establish realistic unit economics or profitability. Many tasks share operating recipes and incident structures, so company and task counts should not be interpreted as counts of independent business models. The benchmark is best read as evidence about decisions within these SaaS operating constraints. It does not establish product-market fit discovery, founder performance or real-world startup success. Cross-world comparisons should declare their family and task weighting; see scoring and interpreting results.

The committed billing fixture

data/fixtures/billing-v1.json contains selected rows from Analytics Engineering’s SaaS Subscriptions v1.0.0, distributed under CC BY 4.0. The original license and attribution are retained beside the fixture. The publisher explicitly describes the data as synthetic educational material containing no real people or organizations.

The full CSV archive was downloaded and inspected. Its SHA-256 is dbd94a4439c6025d64b8576efa392351393ecf8240ea27109186aa94bc49bbed. It contains 5,000 accounts, 5,000 subscriptions, 85,448 invoices, 87,287 payment attempts and four plans. The selected fixture contains eight accounts, eight subscriptions, eighteen invoices, twelve attempts and all four plans. It preserves all payment attempts for each selected invoice, including a failed attempt followed by success, and preserves account/subscription/plan references.

Run from the worldseq package root:

python3 data/import_fixture.py --check

The script downloads at most 10 MB into memory, verifies the pinned archive hash and source row counts, checks the license, repeats the deterministic selection and compares the committed result. --write intentionally regenerates the selection. The full archive is not added to the repository. Tests parse the fixture through a strict Zod schema and check identity, referential and chronological integrity. Invoice amount is not treated as collected cash; failed attempts do not increase collections.

This fixture is useful for accounting and ingestion tests. Its apparent churn, conversion, seat distributions and payment failure frequency are not industry calibration targets. The source schema lacks the historical detail needed to reconstruct every upgrade, usage event, reactivation and entitlement transition.

Overlapping conditions and replay

The current kernel supports demand shifts, service outages, reporting delays, staff absences, payment outages and support surges. Events can target customer segments, follow a completed action, expire a preventive control or depend on another event. Task configurations combine these effects into shared-root chains and overlapping recovery work. The same root can produce a service effect and delayed visibility. Duplicate descriptions of the same root/effect must not apply the physical effect twice.

Condition placement and bounded severity variation are deterministic functions of the company’s executable mechanics and the task mechanism. Renaming a company does not create a different operating problem. The task configuration fixes its exogenous scenario; the episode seed governs the engine’s addressed customer and payment draws. Paired agent comparisons must use the same company, task, engine version and seed. Changing a policy must not consume a global random stream and shift unrelated future draws.

The timing windows, severity ranges, joint occurrence, feedback coefficients and response delays are authored scenario priors. They are not empirical distributions inferred from public aggregate metrics. Public incident reports motivate the causal structure; they do not establish a quantitative churn response. The family and template data expose the assumptions so a later calibration study can replace them without hiding a behavior change behind a company name.

Admission and extension

Configuration validation checks strict schemas, source references, unique identities, segment consistency, staff-hour reconciliation, opening capacity, cash floors, milestone order, declared resources, delayed evidence, overlapping conditions and executable coverage signatures. Operating packages also receive the same business-constraint and accepted-source-mechanism audit when checked as files or loaded as the active catalog. A rename or prose change does not produce a new signature. A changed price, budget, population or operating condition invalidates the old signature. This is a content-integrity check, not a human review signature.

Catalog metadata records structural validation separately from human review, causal validity and baseline feasibility. A passing configuration check does not silently promote those claims. Behavioral admission executes paired reference and control trajectories, independently reconciles their ledgers, and checks declared outcomes and constraints. Task admission, strategy diversity, adversarial robustness, sensitivity and model comparisons remain separate measurements; their retained reports determine what can be claimed. The source repository exposes all three splits, so these are useful organizational partitions rather than protected holdouts. A confidential evaluation needs a separate, access-controlled package and development process.

compileWorldPackage(raw) validates a JSON package containing formatVersion: 1 and complete companies, tasks and sources arrays. Company and task entries use the same {spec, profile} and {companyId, spec, metadata} wrappers as the built-in catalog; custom packages need not match the built-in inventory size. After a deliberate edit, catalog prepare --file draft.json --out worlds.json refreshes dependent task signatures, checks the complete package and writes a new file without overwriting the draft. Preparation validates configuration; it does not grant behavioral admission.

Set an absolute WORLDSEQ_CATALOG_PATH to select the prepared package. It replaces the built-in catalog rather than appending to it. Set the same path in every server, evaluation, verification and submission terminal, and retain that exact package with the results. Package loading executes no user-provided code.

New companies and tasks can reuse the current six families and execution primitives through JSON. A genuinely new product mechanic requires an engine extension with its own contracts and validation; adding a descriptive resource name alone does not implement it. Source claims are part of the package content hash and must travel with the executable definitions.

For calibration, use an identified real population’s aggregate metrics only as marginal checks with recorded denominators and dates. Fit on a development period, reserve later periods and different company populations for evaluation, and retain parameter uncertainty. Use controlled interventions or suitable quasi-experimental evidence for causal coefficients. Keep synthetic billing data out of behavioral fitting. Report sensitivity sweeps and baseline comparisons until there is enough evidence for stronger validity claims.

Load and check

From the application directory or the unpacked source distribution:

bun -e 'import {loadEvidenceCorpus,checkEvidenceCorpus} from "./src/evidence"; console.log(checkEvidenceCorpus(await loadEvidenceCorpus()))'
bun test ./tests/evidence-corpus.test.ts

The small public API exports parseEvidenceCorpus(input), loadEvidenceCorpus(directory?), checkEvidenceCorpus(corpus) and their strict Zod schemas and types. The directory loader reads the declared JSON files with a 2 MiB per-file limit. Manifests cannot reference parent directories or repeat files. It performs no network calls and executes no package code.

The check report includes a content hash, counts, capability/domain coverage and quarantined claim IDs. Its assurance is source_grounded_candidates_only, with engineAdmittedMechanisms: 0. The hash binds claim text, source locations, limitations, reference assertions and authored parameter ranges. Subsequent engine certificates must separately bind implemented mechanics and their tests.

Evidence and capability coverage

Domain tags cover finance, billing, sales, marketing, product, engineering, infrastructure, support, customer success, people, legal, security, partnerships, strategy, procurement and data. These tags identify candidate coverage; they do not claim complete departmental replicas. Tax calculations, legal advice and unobserved customer or employee responses remain outside the source claims.

Source packages and permitted use

Each document records its source URL, inspection date, locator, reuse basis and access limitations. Published dates are nullable when not verified. The corpus redistributes short attributed factual excerpts, not complete reference documents or personal employee/customer records. Public accessibility does not imply a blanket document or dataset redistribution license. Linked internal GitLab systems and restricted study microdata are not included.

The Buffer June financial report prints **$915m** net revenue while also reporting approximately$1.05m expenses and a $133k loss. The literal$915m claim is retained as quarantined, with no permitted uses. It cannot support a mechanism, reference assertion or parameter. The checker does not silently replace it with $915k.

Synthetic billing claims permit only ingestion_fixture. Aggregate and operating rule claims cannot be promoted to causal_calibration. Even identified effects in this corpus are used as design evidence; their population-specific coefficients are not transferred into generated companies.

Reference cases and uncertainty

Reference cases retain ordered chronology entries and numeric assertions. Numeric assertions must exactly match an accepted source claim’s value and unit. Their measurement definitions retain distinctions such as upper bounds, reported lower bounds, targets and rounded values. Known timestamps must be chronological; unknown timestamps remain null rather than being invented. An ordered inspection of a static report is identified as such and is not a historical company journey.

Parameter ensembles contain low, middle and high authored alternatives. Members are unweighted sensitivity settings, not estimated probability distributions. Source citations explain why the parameter matters; they do not make every selected value empirical. Complete, unique assignments, bounded values and accepted provenance are mandatory. Engine execution and statistical analysis remain separate checks.

Tests exercise complete inventory loading, contradictory-value quarantine, synthetic/calibration boundaries, altered facts/units/chronology, invalid ensembles, strict parsing, content hashes and safe manifest paths. They verify the evidence contract, not real-world forecasting accuracy.