Verification methods
What worldseq verifies, what the evidence establishes, and where the model has limits.
A convincing plan is not enough. worldseq checks what happened to the company: which work finished, what customers received, where the money went, and whether the required constraints held.
The simulator and its evaluation code are tested separately from the agents that play it. An agent’s success rate cannot establish that an environment is correct. The release checks report the evaluated scope and results.
Three separate questions
Is success possible? For a protected graded instance, an author retains a legal sequence of player commands that reaches an eligible outcome within the gameplay budget. A separate check replays and verifies that path. Other successful plans remain valid; the evaluator does not match a player’s decisions against the author’s plan.
Could the player know what was required? Information reviews examine the observations available before a required answer’s deadline. If the available evidence cannot distinguish two causes, a mandatory conclusion must allow that uncertainty. A feasible path chosen with private author knowledge does not answer this fairness question.
Was the outcome judged correctly? The finalizer replays accepted commands, reconstructs business outcomes, checks constraints and assessments, and verifies any required causal branches. A corrupted or incomplete verification cannot become a successful grade.
What the checks cover
| Area | What is checked | Example of a failure the check must catch |
|---|---|---|
| Money and contracts | Cash, invoices, collections, liabilities, earned revenue, and paid-through service | Collecting the same invoice twice or counting borrowed cash as free wealth |
| Work and capacity | Dependencies, delays, funding, cancellation, and shared resources | Finishing work before its prerequisite or allocating the same capacity twice |
| Policies | Required conditions throughout their declared windows | Recovering cash at the end after breaching an earlier reserve requirement |
| Evidence and answers | Observation timing, required conclusions, and eligible answer revisions | Demanding a hidden cause that the public evidence cannot identify |
| Randomness | Replay and the stability of unrelated event draws | Changing future outcomes merely by reading another report |
| Growth experiments | Assignment populations, costs, offer terms, matured outcomes, and rollout | Dropping nonconverting prospects from the denominator |
| Finalization | Registered inputs, accepted journals, retained artifacts, and recovery | Treating missing verifier evidence as a participant failure or a pass |
The accounting and work checks reconstruct facts from primitive records rather than accepting a final dashboard total. Replay supplies an additional check against the registered starting conditions and randomness. These approaches address different failure modes; agreement between two copies of the same faulty calculation would not be enough.
Checking the checkers
The release process deliberately changes selected verification rules and requires the tests to notice. Each semantic mutation has an ordinary passing control and a targeted failure. A compilation error, timeout, or generic source-hash rejection does not count as detecting the intended defect.
Release 0.1.0 passed 31 such controls. They cover intermediate cash floors, objectives, assessments, duplicate payments, invoice periods, shared capacity, prerequisites, causal prefixes, seed bindings, retained evidence, and additional contractual and usage rules.
A separate lifecycle test compares the engine with a small independently written model. It exhausts the declared traces through six transitions across 648 configurations, then checks a shared-dependency diamond. That is bounded evidence about this lifecycle, not a proof over arbitrary companies, graphs, or horizons. The mathematical notes explain the scope.
A result has more than one status
A completed run can have valid accounting and still miss its objective or a required answer. It remains a recorded, ineligible result. If evaluator evidence is missing or verification fails, finalization is inconclusive and eligibility is unset.
Worker activity, gameplay progress, certification, and finalization are separate facts. Seeing a worker finish or a progress bar reach the end does not establish a verified outcome.
What the model does not establish
The companies are fictional. Public incident reports, operating write-ups, and billing documentation support the modeled mechanisms. They do not measure every customer-response coefficient or the probability of overlapping events. Authored values and sensitivity settings should be read as assumptions, with their units and sources, rather than industry forecasts.
The evidence does not establish universal solvability, measured real-world predictive accuracy, or immunity to every exploit. It also does not prove that a named model produced a submitted trajectory. Protecting evaluations describes the player boundary and trusted components; Evidence and licensing explains the source limits.
Inspect or reproduce the work
- Release qualification explains the gates, commands, and retained receipts.
- Private instances explains exact registrations, legal witnesses, and independent checking.
- Quality controls describes contributor checks and their assumptions.
- Evaluations and submissions explains replay verification and result exchange.
Implemented checks describe the system’s behavior. Passing evidence belongs to the particular inputs and execution identity recorded with it; it does not automatically transfer to later code or new realizations.