DOCS / WORLDS Docs overview

Worlds

A world defines what can exist and change.

Its definition combines software behavior with the buyers, customers, admins, employees, approvers or operators who keep acting inside it.

The world contract

Different creation paths produce the same runtime contract. Agents should not need to know whether a world began from the catalog, an OpenAPI document or custom code.

Systems
Entities, relationships, permissions and state transitions.
Interfaces
The APIs, SDK behavior or MCP tools exposed to agents.
Mutations
Accepted inputs, rejected inputs, side effects and invariants.
Population
Buyers, customers, admins, employees or operators grounded in state.
History
How coherent records and prior events are generated.
Evaluators
Rules and metrics used to judge resulting world state.

Three creation paths

The path changes how much definition work is required, not what the resulting world can do.

01CatalogBegin with a maintained SaaS-compatible shape.
02Internal APIsInfer a starting draft from OpenAPI and schemas.
03CustomAuthor systems plus buyer, admin or operator behavior.
04ValidateCheck interfaces, mutations and invariants before running.
Inference creates a draft: an API description reveals endpoints and types, but it cannot fully reveal business rules, hidden side effects or user behavior. Those must be validated or supplied.

Create definitions with the SDK

Start from catalog systems

import {
  catalog,
  buyers,
  storeAdmins,
  warehouseOperators,
} from "@counterworld/sdk";

const draft = await counterworld.definitions.create({
  name: "retail-operations",
  systems: [catalog.shopify(), catalog.stripe()],
  population: [
    buyers({ count: 12_000 }),
    storeAdmins({ count: 24 }),
    warehouseOperators({ count: 80 }),
  ],
  history: { years: 2 },
});

const version = await draft.publish();

Infer an internal world from service contracts

const draft = await counterworld.definitions.fromOpenAPI({
  name: "fulfillment-operations",
  specs: ["./orders.yaml", "./warehouse.yaml"],
});

draft.relations.add("order.fulfilledBy", "shipment.id");
draft.invariants.add("allocated_stock_lte_available_stock");

const report = await draft.validate();
if (!report.valid) throw new Error(report.summary);

const version = await draft.publish();

Publishing freezes the schemas, mutation behavior, actor configuration and evaluators into one reproducible version.

Shape, definition and instance

ShapeReusable Shopify-like software model
DefinitionShape + buyer types + history + checks
InstanceOne populated store at a specific time

A shape can support many definitions. A definition can create many independent instances. Each instance receives its own state, identities, credentials, clock and event queue.

Definitions are versioned; instances are traceable

A run should identify the exact definition, seed, starting checkpoint and configuration that produced it. This makes failures reproducible even after the world definition evolves.

  • Definition version identifies schemas, mutations, actor logic and evaluators.
  • Seed identifies generated identities, history and stochastic choices.
  • Checkpoint identifies the exact starting state and clock.
  • Run export identifies every agent, actor and scheduled event applied afterward.

Fidelity is behavioral, not only structural

Matching endpoint names and response schemas is insufficient. A faithful world must accept, reject and propagate mutations like the represented system.

Example: a refund endpoint that returns the correct JSON shape but allows refunding more than the remaining captured amount is structurally compatible and behaviorally wrong.