[{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"the-look-ecommerce","name":"TheLookEcommerce","machines":6,"deployed_at":"2026-07-03T00:00:00Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"TheLook E-Commerce Marketplace","description":"Users browse (events) and place orders of products; orders spawn order_items that consume per-unit inventory_items minted from the products catalog.","category":"ecommerce","tags":["retail","orders","inventory","clickstream"],"domain":"ecommerce"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"claims-fnol","name":"ClaimsFNOL","machines":3,"deployed_at":"2026-07-02T21:38:09.720684508Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Claims FNOL","description":"An insurance first-notice-of-loss workflow with coverage validation, triage, and caseload-capped adjuster assignment.","context":"Models the claims workflow an agentic operations platform automates for specialty\ncarriers. A loss is reported across email/voice/text channels (FNOL), coverage is\nvalidated, the claim is triaged and assigned to a regional adjuster whose caseload\nis capped, then investigated until it settles, is denied, or is withdrawn. Entities\nare Policyholder (seeded root), Adjuster (seeded, small regional pool), and Claim\n(work item spawned by a Policyholder). A taxonomy dependency chain runs\nperil -\u003e severity -\u003e reserve_estimate. The adjuster pool is deliberately undersized\nfor coastal volume, so a triage backlog emerges in Coastal while Mountain idles --\nthe staffing-mix question the dataset answers.\n","category":"BI","tags":["Insurance","Claims","Workflow","Staffing"],"domain":"Insurance","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"sync-reveal","name":"SyncReveal","machines":1,"deployed_at":"2026-07-02T12:24:38.655043384Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Sync Reveal","description":"A minimal deterministic probe of synchronous update semantics, contrasting frozen pre-turn reads against live reads through StepTurn.","context":"Each Cell holds a self-reference. The go event sets step to 1 then emits a reveal\nmessage to itself carrying self.step as payload, and the handler copies that\npayload into revealed. Under update: sync, StepTurn snapshots every Cell before\nprocessing, so self.step reads the frozen pre-turn value (0) even though step was\njust set to 1 in the same turn, leaving revealed == 0 after one turn; under async\nthe read sees the live value, so revealed == 1. The fixture isolates this\nsnapshot-versus-live divergence for the sync-update test.\n","category":"AI","tags":["Demo","Sync","Semantics","Fixture"],"domain":"Engine","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"refusal-demo","name":"RefusalDemo","machines":1,"deployed_at":"2026-07-02T12:24:38.648941676Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Refusal Demo","description":"A minimal seed-free fixture demonstrating request semantics, where a request names an event but conditions still gate it and a failed request is a no-op.","context":"A single root Gate machine sits in locked under an all-stay probability matrix,\nso it never moves on its own and every request outcome is deterministic. wait is\nunconditional and always fires; unlock is gated by key \u003e= 1, which nothing ever\nraises, so a request for it is always refused and the Gate stays put rather than\nrolling onto another event; force_open exists only in the opened state, so\nrequesting it on a locked Gate is a wrong-state error. The scenario exercises and\npins the engine's request-versus-force semantics over the REST API.\n","category":"AI","tags":["Demo","FSM","Semantics","Fixture"],"domain":"Engine","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"single-data-table","name":"SingleDataTable","machines":1,"deployed_at":"2026-07-02T12:24:38.641732967Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Single Data Table","tagline":"One passive Person table that shows off the faker data generators.","description":"A pure data-generation scenario that emits one wide table of synthetic records, every column rendered by the faker strategy.","context":"A single passive Person machine has no events, transitions, messaging or\nreferences; its only job is to materialise one wide data table. Carrying no\nseed file, its spawn.seed count drives the engine to create that many entities,\nrendering every func: faker template fresh per row (faker only renders on entity\ncreation). Dimensions hold string faker output and measures hold numeric faker\noutput, so the scenario doubles as a living catalogue of the gofakeit\nexpressions the engine supports. One turn suffices to export the table.\n","category":"BI","tags":["Data","Faker","Generation"],"domain":"Data","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"rogozhin46","name":"Rogozhin46","machines":2,"deployed_at":"2026-07-02T12:24:38.630234884Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Rogozhin (4,6) Universal Machine","tagline":"Rogozhin's 4-state, 6-symbol universal Turing machine (1996), running on a self-growing tape.","description":"Rogozhin's 1996 small universal Turing machine (4 states, 6 symbols) running its faithful dynamics on an un-encoded tape.","context":"A single active Head moves over a tape of Cell entities that grow themselves\nthen go passive (the cell-driven, scan-free scheme of BusyBeaver3), with\nblank symbol 4. The Head runs Rogozhin's (4,6) transition table over states\nA..D and symbols 0..5. On a demonstrative tape (blank except a two-cell input\n[5,5], head starting in state A) it exercises all four states, grows in both\ndirections, then settles into a leftward march without halting. The machine\nis universal via an encoded 2-tag system, which is out of scope here.\n","category":"AI","tags":["TuringMachine","UniversalMachine","Automaton","Computation"],"domain":"Theory of Computation","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"minsky74","name":"Minsky74","machines":2,"deployed_at":"2026-07-02T12:24:38.617510176Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Minsky (7,4) Universal Machine","tagline":"Marvin Minsky's 7-state, 4-symbol universal Turing machine (1967), halting on a demo input.","description":"Minsky's 1967 small universal Turing machine (7 states, 4 symbols) running its faithful dynamics on an un-encoded tape.","context":"A single active Head moves over a tape of Cell entities that grow themselves\nthen go passive (the cell-driven, scan-free scheme of BusyBeaver3), with\nblank symbol q0. The Head runs Minsky's (7,4) transition table over states\nt0..t6 and symbols q0..q3. On a demonstrative tape (blank except a five-cell\ninput [3,1,2,3,1], head starting on the middle cell in state t1) it exercises\nall seven control states, grows the tape both directions, and HALTS after 23\nsteps. The machine is universal via an encoded 2-tag system, out of scope here.\n","category":"AI","tags":["TuringMachine","UniversalMachine","Automaton","Computation"],"domain":"Theory of Computation","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"wolfram23","name":"Wolfram23","machines":2,"deployed_at":"2026-07-02T12:24:38.599485717Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Wolfram (2,3) Universal Machine","tagline":"Wolfram's 2-state, 3-symbol machine — proved universal in 2007 — running on an infinite alternating tape.","description":"Wolfram's 2-state 3-symbol Turing machine (proved universal in 2007) running on an infinite alternating background tape.","context":"A single active Head moves over a tape of Cell entities that grow themselves\nthen go passive (the cell-driven, scan-free scheme of BusyBeaver3). Each Cell\nremembers the background digit it was born holding and gives a grown\nneighbour the opposite, so the revealed tape reads ...0 1 0 1... in both\ndirections. The Head runs machine 596440 (states A,B; symbols 0,1,2; no halt\nstate), so it never halts; the tape grows in both directions one cell per\nexcursion. This is the faithful dynamics on a chosen background, not a\nspecific universal computation.\n","category":"AI","tags":["TuringMachine","UniversalMachine","Automaton","Computation"],"domain":"Theory of Computation","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"turing-second-example","name":"TuringSecondExample","machines":2,"deployed_at":"2026-07-02T12:24:38.585305801Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Turing — Second Example","tagline":"Turing's 1936 second machine — prints growing blocks of 1s by copying the last block and adding one.","description":"Turing's 1936 second example machine, printing 0 1 0 1 1 0 1 1 1 0 ... forever on a self-growing tape.","context":"A single active Head moves over a tape of Cell entities that grow themselves\nrightward then go passive (the cell-driven, scan-free scheme of\nBusyBeaver3 / TuringFirstExample). Using a single marker symbol, the Head\nsweeps back and forth: it copies the last block of 1s, adds one more 1, then\nunmarks, so each cycle prints a block one longer than the last. It NEVER\nHALTS, producing 0, then blocks of 1s of length 1, 2, 3, ... separated by 0s.\n","category":"AI","tags":["TuringMachine","Automaton","Computation"],"domain":"Theory of Computation","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"palindrome","name":"Palindrome","machines":2,"deployed_at":"2026-07-02T12:24:38.570993467Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Palindrome Recogniser","tagline":"A decider that erases matching ends and sweeps inward — halting in Accept or Reject.","description":"A purpose-built Turing machine that decides whether its seeded input string is a palindrome.","context":"A single active Head walks a fixed, seeded strip of passive Cell entities\n(the active-head / passive-tape scheme of BusyBeaver3, but with no growth and\nno messaging — the whole tape is laid down by the seed file). Alphabet:\n0 = blank, 1 = a, 2 = b. Using the classic erase-the-ends-and-sweep\nprocedure, the Head erases the leftmost symbol, sweeps to the matching right\nend, and repeats. It HALTS: ACCEPT when the ends keep matching until empty\n(even) or one centre symbol remains (odd), REJECT on the first mismatch. The\nseeded input \"abba\" is accepted.\n","category":"AI","tags":["TuringMachine","Decider","Automaton","Computation"],"domain":"Theory of Computation","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"tiger-pomdp","name":"TigerPOMDP","machines":1,"deployed_at":"2026-07-02T12:24:38.558919842Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Tiger POMDP","tagline":"The canonical POMDP — a hidden tiger, noisy growls, a finite-memory policy.","description":"The canonical teaching POMDP — listen for noisy growls, then open a door for treasure or a tiger.","context":"The tiger problem (Kaelbling, Littman \u0026 Cassandra 1998). A tiger waits behind\none of two doors with treasure behind the other; the contestant cannot see the\ntiger and may only LISTEN for a noisy growl (correct with p=0.85, costing -1)\nor OPEN a door (+10 treasure, -100 tiger). The hidden tiger_position is sampled\nper contestant at spawn and never read by a policy decision — only by\nenvironment events — so listening's stochastic emission row crossed with\nhidden-state conditions forms the observation matrix. A two-observation history\nring buffer approximates the belief state: the policy opens only after two\nagreeing growls, the classic finite-memory approximation of the threshold policy.\n","category":"AI","tags":["POMDP","DecisionProcess","Policy"],"domain":"Decision Theory","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"cliff-walking","name":"CliffWalking","machines":2,"deployed_at":"2026-07-02T12:24:38.548561342Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Cliff Walking","tagline":"Sutton \u0026 Barto's cliff-walking gridworld — three policies, one dangerous edge.","description":"A gridworld where policy-driven walkers cross a 4x12 grid while avoiding a cliff edge.","context":"The canonical Cliff Walking gridworld. GridCell entities form a static 4x12\ngrid (loaded from grid.csv) with north/south/east/west neighbour references;\nedge cells point at a blocked sentinel cell so off-grid moves are masked out.\nEach Walker starts bottom-left and, in the Walking state, moves one of four\ndirections chosen by a per-policy movement table, then enters CheckCell to\ntest whether it fell off the cliff, reached the goal, or keeps walking.\nSafe, Cautious, and Risky policies trade proximity to the cliff against speed.\n","category":"AI","tags":["RL","Gridworld","MDP","Policy"],"domain":"Reinforcement Learning","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"game-of-life","name":"GameOfLife","machines":1,"deployed_at":"2026-07-02T12:24:38.536069551Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Game of Life","tagline":"Conway's automaton as a perfectly observable, deterministic grid world.","description":"Conway's Game of Life cellular automaton evolving on a 20x20 toroidal grid.","context":"Each grid cell is a Cell entity with 8 neighbour references (Moore\nneighbourhood, toroidal wrap) and is either in an Alive* or Dead* state.\nA generation is split into two engine turns: a notify turn where alive\ncells ping their neighbours and a machine-level handler commutatively\naccumulates a live-neighbour count, and a resolve turn where each cell\napplies Conway's survival/birth/death rules with deterministic first_wins\nevents. The evolution is fully deterministic and order-independent.\n","category":"AI","tags":["CellularAutomaton","Grid","Deterministic"],"domain":"Cellular Automata","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"recycling-robot","name":"RecyclingRobot","machines":1,"deployed_at":"2026-07-02T12:24:38.522219759Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Recycling Robot","tagline":"Sutton \u0026 Barto's recycling robot — search, wait or recharge under a battery MDP.","description":"The Sutton \u0026 Barto recycling-robot MDP, where a battery-powered robot chooses to search, wait, or recharge.","context":"The recycling robot MDP from Sutton \u0026 Barto (§3.7, example 3.3). A can-collecting\nRobot with a two-level battery (High / Low) chooses between searching (good reward,\nrisks draining the battery), waiting (small safe reward), and recharging. Each\nMDP state holds the action choice via a per-robot stochastic policy (Bold robots\nsearch aggressively, Timid robots wait and recharge early); choosing search moves\nto an outcome state whose age-0 probabilities encode the environment's stochastic\nresponse, including running flat and needing a costly rescue. Rewards accumulate\nundiscounted in counters; there is no terminal state, so this is the book's\ncontinuing infinite-horizon task and policies are compared by reward rate.\n","category":"AI","tags":["RL","MDP","Policy","DecisionProcess"],"domain":"Reinforcement Learning","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"thermostat","name":"Thermostat","machines":1,"deployed_at":"2026-07-02T12:24:38.511044717Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Thermostat","tagline":"A continuous-state HVAC MDP — real-valued temperature, threshold control, noisy dynamics.","description":"A control-loop FSM regulating room temperature with a threshold heating policy under continuous noise.","context":"Each Room entity carries a real-valued temperature (a continuous float\nmeasure) and cycles through three states per turn. Control is the agent:\na deterministic threshold policy that heats iff temperature \u003c= 20.0,\nadding a normal-distributed amount and spending energy. Weather is the\nenvironment: a fresh normal-distributed heat-loss draw each turn. Comfort\nis the reward: +1 inside the 19.0-22.0 band, -1 outside, with comfort and\nenergy tracked as separate channels for offline trade-off analysis.\n","category":"AI","tags":["Control","FSM","MDP"],"domain":"Control Systems","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"prisoners-dilemma","name":"PrisonersDilemma","machines":1,"deployed_at":"2026-07-02T12:24:38.500434301Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Prisoner's Dilemma","tagline":"Iterated Prisoner's Dilemma with truly simultaneous, synchronous moves.","description":"An iterated Prisoner's Dilemma under synchronous update, where paired players cooperate or defect each round.","context":"The iterated Prisoner's Dilemma played under synchronous update. Two Players are\npaired by a mutual opponent reference and play repeated rounds; each turn is one\nsimultaneous round. Synchronous scheduling snapshots every player at the start of\nthe turn, so a move made in round N is invisible to the opponent until round N+1,\nmaking the round genuinely simultaneous. Payoffs follow the canonical T \u003e R \u003e P \u003e S\nordering (mutual defection is the one-shot Nash equilibrium, mutual cooperation\nPareto-dominates it). A strategy taxonomy drives behaviour through condition-filtered\nevent selection: always_cooperate, always_defect, tit_for_tat (mirrors the\nopponent's last move), and random.\n","category":"AI","tags":["GameTheory","MultiAgent","Strategy","Synchronous"],"domain":"Game Theory","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"page-rank","name":"PageRank","machines":1,"deployed_at":"2026-07-02T12:24:38.491702134Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"PageRank","tagline":"PageRank as a random surfer — one six-page graph, three damping factors.","description":"The PageRank graph-ranking algorithm modelled as a random surfer over a 6-page web graph.","context":"A single Surfer entity walks a fixed 6-page web graph (pages A-F) whose\nstates are the pages and whose go_to_X events are the directed links.\nEach state uses a policy table encoding the PageRank transition\nd * uniform_outlink + (1-d) * uniform_teleport, with three damping\nvariants (0.85, 0.50, 1.00) selected per surfer via a taxonomy. The graph\ntopology lives in the event/action structure; the policy tables vary only\nthe damping factor, and the stationary visit distribution converges to the\npower-iteration PageRank ground truth.\n","category":"AI","tags":["Graph","RandomWalk","Ranking"],"domain":"Graph Algorithms","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"pac-man","name":"PacMan","machines":4,"deployed_at":"2026-07-02T12:24:38.474177759Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Pac-Man","tagline":"A self-playing arcade game — ghosts chase a flood-filled distance field.","description":"A Pac-Man maze where ghosts chase via a flood-filled BFS distance field rebuilt each turn.","context":"Pac-Man modelled as a graph of MazeCell entities, with walls represented by a\nblocked sentinel cell and edge tunnels wrapping around. Each turn PacMan emits a\nwave message into his current cell; tiered handlers flood-fill a BFS distance\nfield (pac_grad) across the maze within his step, so ghosts chase by gradient\nascent toward his true walkable position. Ghosts carry personalities via policy\ntables, power pellets set a frightened timer on the singleton GameState that\nmakes ghosts flee, and GameState watches pellets and lives to drive the terminal\nLevelComplete / GameOver states. Fixed machine ordering keeps ghost pursuit one\nmove stale, matching arcade behaviour.\n","category":"AI","tags":["GridWorld","Pathfinding","BFS","Game"],"domain":"Game AI","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"submission-intake","name":"SubmissionIntake","machines":3,"deployed_at":"2026-07-02T12:24:38.460236592Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Submission Intake","tagline":"The commercial submission-to-bind funnel — extraction, NIGO chase, referral, quote, bind.","description":"A commercial-lines submission-to-bind funnel covering data extraction, good-order review, NIGO chase, underwriter referral, and binding.","context":"Models the intake workflow an agentic operations platform automates for carriers\nand MGAs: a broker sends a submission, the carrier extracts the data (AI-extracted\nor manually keyed), reviews it for good order, chases Not-In-Good-Order (NIGO) data\npoints back through the broker, refers stubborn cases to a capacity-constrained\nunderwriter pool, and finally rates, quotes, and binds (or loses) the account.\nEntities are Broker (seeded root), Underwriter (seeded, scarce pool), and\nSubmission (work item spawned by a Broker). Exercises message round-trips (NIGO\nchase, referral accept/backlog backpressure), condition-gated events\n(handling_mode speed split, appetite gate, nigo_rounds escalation), and\nset_reference assignment.\n","category":"BI","tags":["Insurance","Underwriting","Intake","Workflow"],"domain":"Insurance","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"service-queue","name":"ServiceQueue","machines":6,"deployed_at":"2026-07-02T12:24:38.447182217Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Service Queue","tagline":"Bank-branch queueing — tellers, peak periods, and complexity-driven wait times.","description":"A retail bank branch where customers queue for tellers and move through a service session to a feedback outcome over a single business day.","context":"A bank Branch opens for the day, opening Teller windows and accepting Customers\nwho each carry a service_type, priority_class and segment. The Branch runs an\nOpen to Closing to Closed lifecycle; Tellers serve Customers through Ticket and\nServiceSession entities, recording sessions, escalations and Feedback. One turn\nis five minutes starting at the 09:00 branch open, so timestamps export as\nwall-clock times across the trading day and the queue turns over in minutes.\n","category":"BI","tags":["Queue","Banking","Service","Operations"],"domain":"Operations","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"service-desk","name":"ServiceDesk","machines":4,"deployed_at":"2026-07-02T12:24:38.4317398Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Service Desk","tagline":"SaaS support tickets through triage and a capacity-capped agent pool to resolution.","description":"A B2B SaaS support desk routing customer tickets through a triage-to-resolution lifecycle against a capacity-capped regional agent pool.","context":"A software vendor runs a support desk for its customer companies. Each\nAccount (seeded) spawns Users who file Tickets about products drawn from a\ncatalog. A ticket is triaged, set-referenced to a regional SupportAgent whose\nconcurrent open_tickets are capped, then worked through a realistic support\nlifecycle until resolved and closed, with a reopen path when a resolved ticket\nis not actually fixed. The thin agent pool forces a triage/assignment backlog,\nso the dataset answers a staffing question.\n","category":"BI","tags":["Support","Queue","Tickets","Operations"],"domain":"Support","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"programmatic-ads","name":"ProgrammaticAds","machines":7,"deployed_at":"2026-07-02T12:24:38.419810759Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Programmatic Ads","tagline":"A real-time-bidding exchange — publishers, slots, bids, impressions and clicks.","description":"A real-time programmatic advertising simulation tracing the auction, impression, click and conversion chain across publishers, advertisers and campaigns.","context":"Models a programmatic ad exchange with entities for Publisher, Advertiser,\nCampaign, AdSlot, BidRequest, Impression and Click. Publishers offer AdSlots,\nadvertisers run Campaigns that bid into BidRequest auctions; a won bid serves\nan Impression which may yield a Click and onward conversion. Device, geo\nregion and country are sampled via taxonomies (country nested under region).\nOne turn is one minute, keeping the sub-second bid/win/serve/click flow\nlegible while publisher, advertiser and campaign lifecycles accumulate, so\ntimestamps export as wall-clock columns.\n","category":"BI","tags":["Advertising","RTB","Auction","FSM"],"domain":"Advertising","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"online-shopping-events","name":"OnlineShoppingEvents","machines":5,"deployed_at":"2026-07-02T12:24:38.411298217Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Online Shopping Events","description":"The event-clock variant of Online Shopping, replacing per-turn Markov dwell with explicit sampled dwell times that the simulation jumps between.","context":"Same entities, catalog, message protocol and aggregates as Online Shopping\n(Customer and Warehouse roots; Orders of Line Items moving through\nconfirmation, shipment and delivery via Shipments), but driven by the event\nclock: instead of a geometric per-turn stay, each step arms an explicit\nsampled dwell, and the turn counter jumps straight to the next due entity\nwake or delayed message. The idiomatic pattern here is a single probability\nrow plus Age conditions for time-windowed behavior. Messages deliver\nregardless of sleep; only stepping is wake-gated, and terminal states are\npassive so the population quiesces and the clock can jump far. One turn is one hour.\n","category":"BI","tags":["Ecommerce","EventClock","Messaging","FSM"],"domain":"Retail","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"online-shopping-catalog","name":"OnlineShoppingCatalog","machines":5,"deployed_at":"2026-07-02T12:24:38.400892884Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Online Shopping Catalog","description":"The Online Shopping model with its product catalog held in an external JSONL file, the worked example of a file-backed catalog.","context":"Identical fulfilment model to Online Shopping (Customer and Warehouse roots;\nOrders composed of Line Items, advancing through confirmation, shipment and\ndelivery via Shipments, with cross-entity messaging and aggregate measures),\nbut the product catalog lives in an external catalog/products.jsonl file\ninstead of inline YAML. The scenario package is the deploy unit: the catalog\nfile travels alongside the config, its own fingerprint is pinned in the\ndeployed manifest, and field families expand per JSONL entry exactly as they\ndo per inline entry. One turn is one hour.\n","category":"BI","tags":["Ecommerce","Catalog","Messaging","FSM"],"domain":"Retail","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"online-shopping","name":"OnlineShopping","machines":5,"deployed_at":"2026-07-02T12:24:38.389826467Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Online Shopping","tagline":"Order fulfilment against live warehouse stock — confirmations, shipments and returns.","description":"An online retail simulation exercising cross-entity messaging, references and aggregates across customers, warehouses, orders, line items and shipments.","context":"Models an ecommerce fulfilment flow with five entity types: Customer and\nWarehouse are roots; an Order is placed by a Customer, composed atomically of\nmany Line Items, and progresses through confirmation, shipment and delivery\nvia a Shipment. Orders sample products from an inline catalog; Warehouses\ntrack per-product stock through field families, and the product index travels\nin message payloads so handlers update the right stock counter via bracket\nexpressions. One turn is one hour, so timestamps export as wall-clock columns.\nDemonstrates handlers, emit_message, set_reference, one-to-many associations\nand composition, aggregate count/sum measures, and first-match-wins branching.\n","category":"BI","tags":["Ecommerce","Fulfilment","Messaging","FSM"],"domain":"Retail","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"payment-processor","name":"PaymentProcessor","machines":8,"deployed_at":"2026-07-02T12:24:38.377388925Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Payment Processor","tagline":"A European processor — cross-border geographies routed onto SEPA, BACS and AUTOGIRO rails.","description":"Card and Direct Debit payments moving through authorisation, capture, settlement, refund and chargeback.","context":"A payment-lifecycle FSM. Each transaction is an entity transitioning through\nauthorisation → capture → settlement, with refund and chargeback branches.\nOne simulation turn is one calendar day, so merchant acquisition and Direct\nDebit settlement play out over days and weeks and timestamp fields export as\nrealistic wall-clock dates. Country/geo taxonomies drive cross-border issuer\nand scheme distributions.\n","category":"BI","tags":["Event","FSM","Payments"],"domain":"Payments","author":"Jon Walls","version":"0.1"},"theme":{"brand":{"50":"#fff1f2","100":"#ffe4e6","200":"#fecdd3","300":"#fda4af","400":"#fb7185","500":"#e11d48","600":"#be123c","700":"#9f1239","800":"#881337","900":"#4c0519"},"fg":"#1f1113","surface":"#fff7f8","canvas":"#fdf2f4","border":"#f3d3d9"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"turing-first-example","name":"TuringFirstExample","machines":2,"deployed_at":"2026-07-02T12:24:38.36149955Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Turing — First Example","tagline":"Turing's 1936 first machine — prints 0 1 0 1 … rightward forever, never halting.","description":"Turing's 1936 first example machine, printing 0 1 0 1 ... forever on a self-growing tape.","context":"A single active Head moves over a tape of Cell entities that grow themselves\nrightward then go passive (the same cell-driven, scan-free scheme as\nBusyBeaver3). The Head cycles through control states b, c, e, f, printing a 0\nthen a 1 on alternate written squares while marching right forever. It NEVER\nHALTS: the tape reads 0 _ 1 _ 0 _ 1 _ ..., growing one passive cell per step.\n","category":"AI","tags":["TuringMachine","Automaton","Computation"],"domain":"Theory of Computation","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"london-underground","name":"LondonUnderground","machines":2,"deployed_at":"2026-07-02T12:24:38.329933759Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"London Underground","tagline":"A live tube graph — eleven lines, hundreds of trains, platforms held as a mutex.","description":"Eleven tube lines simulated as chains of Station entities along which Trains run a service lifecycle, with platform occupancy enforcing no overtaking or co-location.","context":"Stations form per-line chains wired with per-direction next_out/next_in\nreferences; a Station represents one line's platforms at one location. Trains\nmove InDepot to Dwelling to InTransit and back, dwelling at least a turn per\nstation and laying over at termini before reversing. Each station's two\nplatform flags act as a mutex: a train may depart only when the next platform\nfor its direction is free, so two trains never share a platform and overtaking\nis structurally impossible; blocked departures are held at signal. On arrival a\ntrain and its station exchange passengers via messages. One turn is about a\nminute; seeds are generated from researched TfL route, fleet and demand data.\n","category":"BI","tags":["Transit","FSM","Mutex","Simulation"],"domain":"Transit","author":"Jon Walls","version":"0.1"},"theme":{"brand":{"50":"#fef2f2","100":"#fee2e2","200":"#fecaca","300":"#f87171","400":"#ef4444","500":"#dc241f","600":"#b91c1c","700":"#991b1b","800":"#7f1d1d","900":"#450a0a"},"fg":"#10233f","surface":"#fefdfb","canvas":"#f8f9fb","border":"#d1d8e3","logo":"https://upload.wikimedia.org/wikipedia/commons/4/41/Underground.svg"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"erp-general-ledger","name":"ErpGeneralLedger","machines":6,"deployed_at":"2026-07-02T12:24:38.314319967Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"ERP General Ledger","tagline":"A multi-subsidiary, multi-currency general ledger, generated by simulating ERP postings.","description":"A generated multi-subsidiary, multi-currency general ledger built by simulating the double-entry posting process.","context":"Models the slice of an ERP suite that feeds financial reporting: legal entities\nbooking business transactions that post by double entry into a general ledger.\nSubsidiaries (seeded roots) book Transactions each turn; a Transaction flows\nDraft -\u003e Approved -\u003e Posted -\u003e Booked, and on posting spawns one balanced\nJournalDebit and one JournalCredit line, broadcasting its amount to both legs so\ndebit total == credit total by construction. Accounts and Departments are passive\ndimensions; multi-currency consolidation is done at report time via each\nsubsidiary's fx_rate_to_base and parent chain. The dataset answers trial balance,\nincome statement, balance sheet, and consolidation queries.\n","category":"BI","tags":["Finance","Accounting","Double-Entry","ERP"],"domain":"Finance","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"jaffle-shop","name":"JaffleShop","machines":3,"deployed_at":"2026-07-02T12:24:38.298064384Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Jaffle Shop","tagline":"dbt's classic Jaffle Shop dataset, regenerated as a live simulation at any scale.","description":"A Mock Machines reconstruction of dbt Labs' \"Jaffle Shop\" dataset, regenerating its raw customers, orders and payments tables as a running simulation.","context":"A fictional ecommerce store modelled on dbt's classic tutorial dataset.\nThree entity types map to dbt's raw seed tables: Customer (raw_customers),\nOrder (raw_orders) and Payment (raw_payments). Customers sample first/last\nnames and place orders while shopping; an Order's status IS a state machine\n(placed -\u003e shipped -\u003e completed, with an optional return_pending -\u003e returned\ntail) that advances probabilistically each turn; Payments carry a sampled\nmethod and amount. One turn is one day, so order dates export as wall-clock\ntimestamps in the enriched event log.\n","category":"BI","tags":["Ecommerce","Analytics","dbt","FSM"],"domain":"Retail","author":"Jon Walls","version":"0.1"},"theme":{"brand":{"50":"#fffbeb","100":"#fef3c7","200":"#fde68a","300":"#fcd34d","400":"#fbbf24","500":"#d97706","600":"#b45309","700":"#92400e","800":"#78350f","900":"#451a03"},"fg":"#3b1f05","surface":"#fffdf7","canvas":"#fef9ee","border":"#e8d5b0"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"manufacturing-line","name":"ManufacturingLine","machines":4,"deployed_at":"2026-07-02T10:22:07.350323134Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Manufacturing Line","description":"A machine shop's order book — staggered releases, hour-by-hour production, spawned quality inspections, and rework/MRB loops.","context":"Vantage Motion Systems runs forty seeded work orders across three\nproduction lines. Each order is wired at load to its product and four\nBOM-line components (seed-cell references), waits in queued until its\nrelease — rush orders carry a higher release hazard — then produces in\none-hour turns. Reaching quality_check spawns a QualityCheck entity that\nsamples a pass/rework/fail verdict, logs defects while it inspects,\nmeasures bore diameter and surface finish from verdict-keyed normals,\nand messages the order its disposition with the defect count as payload.\nPassed orders complete and passivate; minor non-conformances loop back\nthrough the line; orders accumulating four or more defects park under a\nslow Material Review Board hold. The dataset answers WIP, first-pass\nyield, and defect-escape questions, and each order renders a\ndrawing-style Bill of Materials sheet while each inspection renders a\nstamped quality report.\n","category":"BI","tags":["Manufacturing","MES","Quality","BOM"],"domain":"Manufacturing","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"football-league","name":"FootballLeague","machines":2,"deployed_at":"2026-07-02T10:22:07.343196384Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"Football League","description":"A matchday weekend of league football — staggered kickoffs, minute-by-minute goals, and a league table kept from result messages.","context":"Twenty clubs contest a forty-fixture card over a compressed matchday weekend.\nEach Match is a seeded fixture referencing its home and away Club; it waits in\nscheduled until a staggered kickoff, then plays two 45-minute halves in\nquarter-hour turns. Goals are counter updates with per-turn hazards calibrated\nto real scoring rates (about 2.7 goals a game, home advantage included), so\nfinal scores cluster 0-4 a side. Attendance is sampled at kickoff from the\nhome venue's tier. The full-time whistle messages both clubs their goals-for,\ngoals-against and margin, and each club's first-match-wins handlers keep the\nleague table -- played, won, drawn, lost, goal difference, points -- from the\npayloads alone. The dataset answers league-table and scoreline-distribution\nquestions, and each finished fixture becomes a broadcast-style full-time\nreport document.\n","category":"BI","tags":["Sports","Football","League","Matchday"],"domain":"Sports","author":"Jon Walls","version":"0.1"},"theme":{"brand":{"50":"#fdf8e8","100":"#faf0c8","200":"#f6e49e","300":"#f4d97a","400":"#f0ce5c","500":"#e8c34a","600":"#c9a530","700":"#a38424","800":"#7d641c","900":"#4a3a10"},"fg":"#f2f4f8","surface":"#141a2e","canvas":"#0c1020","border":"#2a3352"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"policy-servicing","name":"PolicyServicing","machines":3,"deployed_at":"2026-07-02T10:22:07.338487342Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Policy Servicing","tagline":"High-volume service requests against a growing policy book and a fixed human team.","description":"A high-volume insurance policy-servicing workflow where most requests auto-resolve and the remainder escalate to a fixed service-rep pool.","context":"Models the policy-servicing workflow an agentic operations platform automates for\nspecialty carriers: high-volume service requests (policy documents, simple\ncancellations, non-premium endorsements) from policyholders, agents, and mortgagee\nteams. Most requests auto-resolve end to end; the remainder escalate to a small,\nfixed pool of human service reps. Entities are Policy (seeded root; the book grows\n~2%/turn by writing new policies), ServiceRep (seeded, fixed headcount), and\nServiceRequest (work item spawned by a Policy). The book grows while rep headcount\nstays fixed: with the ~90% auto-resolution mix the rep queue stays bounded; cut the\nauto shares and the escalation queue grows without bound -- the \"scale without\nscaling headcount\" mandate as an emergent property.\n","category":"BI","tags":["Insurance","Operations","Automation","Workflow"],"domain":"Insurance","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"gtm-sales-funnel","name":"GTMSalesFunnel","machines":5,"deployed_at":"2026-07-02T10:22:07.332594342Z","editable":false,"owned":false,"has_viz":true,"has_documents":true,"metadata":{"display_name":"GTM Sales Funnel","tagline":"Opportunities through a B2B SaaS funnel, with capacity-capped reps and solutions engineers.","description":"A go-to-market B2B sales funnel where deals progress through a 6-stage CRM pipeline and a capped staff pool serves the pipeline.","context":"A classic go-to-market sales funnel for a modern AI/SaaS company. Accounts\n(target companies) generate Deals that progress through a six-stage funnel\n(Prospecting -\u003e Qualification -\u003e Discovery -\u003e Technical Validation -\u003e Proposal -\u003e\nClosed Won/Lost) and, on a win, live on through a renewal lifecycle\n(Live -\u003e Up For Renewal -\u003e Renewed | Churned). Two capped staff pools serve the\npipeline: Sales Reps own deals against a bookings quota, and Solutions Engineers\ndeliver the POC project a qualified deal depends on to advance. Each deal samples\na product (its ARR sets deal value) and primary competitor. The small staff pools\ncreate a qualification/assignment backlog under load -- the capacity question the\ndataset answers.\n","category":"BI","tags":["Sales","CRM","Pipeline","SaaS"],"domain":"Sales","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"artisan-market","name":"ArtisanMarket","machines":5,"deployed_at":"2026-07-02T10:22:07.320776842Z","editable":false,"owned":false,"has_viz":false,"has_documents":true,"metadata":{"display_name":"Artisan Market","tagline":"A craft marketplace where every string field is generated by faker.","description":"A small online marketplace whose entities draw their string fields from gofakeit faker generators so the exported tables read like a real catalogue, CRM and shipping manifest.","context":"Models a craft marketplace with five entity types: Seller and Customer are\nseeded roots; Sellers spawn Products and Couriers, Customers place Orders.\nOne turn is one calendar day, so order ship/deliver timestamps export as\nwall-clock dates. Each entity's string fields come from a different family of\ngofakeit (faker) generators, showcasing the func: faker strategy across bare\ntokens, literal+token mixes, argument forms and pattern characters.\nPopulations are bounded: each Seller builds its catalogue once then idles,\neach Customer places two Orders then idles.\n","category":"BI","tags":["Retail","Marketplace","Faker","FSM"],"domain":"Retail","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"cliff-walking-rl","name":"CliffWalkingRL","machines":2,"deployed_at":"2026-07-01T16:54:22.548443721Z","editable":false,"owned":false,"has_viz":false,"has_documents":false,"metadata":{"display_name":"Cliff Walking RL","description":"A single-agent Cliff Walking environment driven step-by-step by external action requests for reinforcement learning.","context":"A reinforcement-learning variant of Cliff Walking with the same 4x12 grid and\nblocked sentinel cell, but exactly ONE Walker that never moves on its own. Its\nWalking state has no policy table and stays put on a plain advance, so the only\nthing that moves it is an explicit targeted move_* request: one request equals\none move equals one turn. There is no CheckCell cascade and no terminal states;\nthe engine is a pure, deterministic transition function, and RL concerns such as\nreward shaping, the cliff penalty, teleport-to-start, and episode termination are\ncomputed externally (Python-side) from the observed cell kind.\n","category":"AI","tags":["RL","Gridworld","MDP","SingleAgent"],"domain":"Reinforcement Learning","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"busy-beaver5","name":"BusyBeaver5","machines":2,"deployed_at":"2026-07-01T16:54:22.519083221Z","editable":false,"owned":false,"has_viz":true,"has_documents":false,"metadata":{"display_name":"Busy Beaver (5-state)","description":"The proven-optimal 5-state busy-beaver champion Turing machine running faithfully on a self-growing tape.","context":"A single active Head moves over a tape of Cell entities that grow themselves\nthen go passive (the same cell-driven, scan-free scheme as BusyBeaver3). The\nHead executes the Marxen-Buntrock BB(5) champion table\n(1RB1LC_1RC1RB_1RD0LE_1LA1LD_1RZ0LA), proven optimal in 2024. The full run\nhalts only after 47,176,870 steps leaving 4098 ones, so reaching the halt is\nimpractical; the machine runs the BB(5) table exactly, step for step.\n","category":"AI","tags":["TuringMachine","BusyBeaver","Automaton","Computation"],"domain":"Theory of Computation","author":"Jon Walls","version":"0.1"}}},{"lab_id":"mock-machines-test-lab","lab_name":"Mock Machines Test Lab","lab_member":false,"workbench_id":"published","access":"read-only","shared":false,"scenario":{"id":"busy-beaver3","name":"BusyBeaver3","machines":2,"deployed_at":"2026-07-01T16:54:22.506294304Z","editable":false,"owned":false,"has_viz":true,"has_documents":false,"metadata":{"display_name":"Busy Beaver (3-state)","description":"The 3-state busy-beaver champion Turing machine running on a self-growing tape that halts after 21 steps.","context":"A single active Head moves over a tape of Cell entities. Each Cell holds a\nsymbol and goes passive once settled; when the Head steps off an end it\nsends a Grow message and the boundary cell spawns its new neighbour, which\nannounces itself back and then passivates. The Head follows the BB(3)\nstep-champion table (1RB1RH_1LB0RC_1LC1LA); from a blank tape it HALTS after\n21 steps, leaving 5 ones across 5 cells.\n","category":"AI","tags":["TuringMachine","BusyBeaver","Automaton","Computation"],"domain":"Theory of Computation","author":"Jon Walls","version":"0.1"}}}]