Concepts
An Atlas Labs sandbox is one fictional company, Atlas Print Works & Co., split into a Factory and a Head Office that hold separate data behind separate keys. Records cross between them only over the bridge, which the platform runs for you in auto mode and your code runs in manual mode.
Factory and Head Office
| System | Key prefix | Owns |
|---|---|---|
| Factory | lab_fac_ | Work orders, print runs, the press, inventory, requisitions, the dock, shipments, timesheets |
| Head Office | lab_off_ | Sales orders, contracts, requisition approvals, suppliers, purchase orders, invoices, payments, the market, the ledger, HR |
A Factory-scoped route rejects a Head Office key and vice versa, with a 403 wrong_system error that names the key you actually need. A misconfigured integration therefore fails loudly and early, not with a confusing empty result.
The bridge
The simulation always knows the ground truth. What the bridge controls is whether your code has to notice a change and post it across, or whether the platform copies it for you.
- Head Office to Factory: an accepted sales order becomes a work order (
POST /factory/work-orders). - Factory to Head Office: a requisition, a goods receipt, a shipment, or timesheets (HR).
Supplier deliveries always reach the Factory dock automatically, because the supplier already knows the purchase order number, so purchase orders never need bridging.
In bridge: "auto" mode the platform copies each record across within one tick and emits the same events a manual post would, so you can automate one side and still see the whole loop. In bridge: "manual" mode, nothing crosses unless you post it: you are the integration. Posting a record whose source doesn't exist returns 404 source_not_found; a mismatched quantity or reference returns 422 bridge_mismatch with the differences listed; posting the same source twice returns 409 already_bridged.
Autopilot
automate is office, factory or both. Whichever side you don't automate is run by an NPC, after a short in-sim “thinking” delay, so its actions show up as ordinary events and writes rather than teleporting. Switch sides mid-session with PATCH /labs/api/v1/sandbox; the side you take over stops its autopilot immediately.
The sim clock
Every response carries meta.sim_date. At pace: "normal" one sim day passes roughly once a minute, which is fast enough to watch live and slow enough to read. At pace: "slow" a sim day takes longer, which suits polling-only tools. At pace: "manual" nothing advances until you call POST /sandbox/tick, which suits CI and deterministic tests.
HR module
HR is off by default. Turn it on with modules.hr and staffing starts to matter: fewer press operators slows the press, a missing forklift driver blocks goods receipts, staff occasionally call in sick or ask for leave, and payroll has to run on time from the timesheets bridged into the Head Office, or morale drops for everyone. With HR off, staffing is assumed perfect and the HR endpoints return 404 module_disabled with a hint on how to turn it on.
Continents and scoring
Every sandbox joins one of six continent teams (assigned from your network location; only the continent is ever stored, never a country or IP address), plus an opt-in “Antarctic Research Press” for anyone who picks it deliberately. Continent standings on the world map are computed per factory-hour, so a continent with few active sandboxes can outrank a busier one, and need a handful of active factories before they're shown ranked at all. The map shows each continent's factories, atlases shipped and Major Order progress as plain totals.
Missions
Missions are detected from the events your sandbox actually produces, never from a flag you set: reading your sales orders, accepting one, bridging a shipment, reacting to a webhook, and so on. List them with GET /labs/api/v1/missions; each one names the endpoints it needs.