The Invisible Machine, explained

01 · CONCEPT

What this project is

The Invisible Machine is an interactive essay about the systems hidden under every business. The storefront surface splits open and the visitor descends through eight operational stations — acquisition, checkout, payment, inventory, fulfilment, delivery, support, revenue — following real orders through a live simulation they can stress, break and repair.

It is a portfolio piece with a thesis: understanding systems matters more than decorating them. Every number on the page is computed; nothing is a mock-up.

02 · SIMULATION

A deterministic business simulation

The core is a pure TypeScript discrete-time queueing model — eight stations with capacities, processing times, queues, error rates, stock consumption and customer abandonment. It uses no randomness and no wall-clock time: the same inputs always produce the same outcomes, which makes every claim in the experience reproducible and testable.

Six operator controls (demand, staffing, inventory replenishment, processing tempo, support capacity, automation) feed effective-capacity calculations. Three scenarios — balanced, viral spike, operational breakdown — are just different control presets; their contrasting failure modes emerge from the model, and are pinned by unit tests.

03 · INTELLIGENCE

Bottleneck detection and the decision engine

The bottleneck is computed live: the engine walks the flow path looking for sustained pressure (arrival rate vs. effective capacity) combined with a deepening queue, distinguishing pipeline constraints from support overload. The camera, warnings, scan sequence and copy all key off this computed constraint — nothing is scripted to a fixed station.

'Activate Intelligence' runs a deterministic operational decision engine that analyzes live simulation state and ranks interventions. Each rule scores itself against the current state and reports numeric evidence (backlog hours, overload ratio, trapped revenue). Applying a recommendation mutates the live controls — capacity rises, a bypass route assembles, queues drain over time — and the tradeoffs (such as operating cost) stay visible.

04 · RENDERING

Three.js / React Three Fiber architecture

The 3D machine is fully procedural — no downloaded models or texture packs. Stations share a chassis (plinth, utilisation ring, status lamp, queue rail) and carry distinct operational identities: a rotating payment verification ring, inventory stock cells that physically empty, a fulfilment gantry that sweeps at the station's real tempo, a support reservoir that fills with unresolved issues.

Rendering is a strict one-way street: the simulation ticks in a Zustand store, and the render loop reads it imperatively — zero React re-renders per frame. Orders are one instanced mesh pool; queue blocks fill each station's holding rail from a shared layout module so particles, markers and geometry can never disagree. Materials come from one shared kit, flow lanes are tube shaders whose packet speed is the feeding station's live throughput, and the scroll-driven camera uses damped poses per chapter — no scroll-jacking.

05 · RESILIENCE

Accessibility, fallbacks and failure states

The experience has a full reduced-motion path (static compositions, crossfades, no sweeps), a complete keyboard journey, ARIA labelling with live announcements, and a screen-reader system overview. Without JavaScript, the narrative still reads top to bottom.

Without WebGL — or if the scene crashes — a live 2D SVG schematic takes over, driven by the same simulation. Device capability, chosen view and runtime failure are modelled as independent state, so visitors can switch 3D ↔ Diagram freely, a runtime failure offers a real one-shot retry, and only genuine capability absence ever disables the 3D option.

06 · PERFORMANCE

Quality tiers and adaptation

The three.js bundle is lazy-loaded so the opening copy never waits for it; first-load JavaScript for the page is ~130 kB. Three quality tiers (auto-detected from device signals, user-overridable) control resolution caps, particle pool sizes and environmental detail. The simulation pauses when the tab is hidden, high-frequency readouts update the DOM imperatively, and narrow viewports get recomposed camera framing rather than a cropped desktop shot.

07 · ENGINEERING

Testing and deployment

The simulation is developed test-first: scenario dynamics, bottleneck attribution, recommendation ranking, intervention effects and the before/after comparison are covered by unit tests, with component tests over the operator console, inspector, AI panel and the view-mode state machine. Linting, strict TypeScript and the production build gate every change.

The site is a Next.js App Router application deployed on a self-managed VPS behind nginx with automated TLS — built, tested and shipped from a single source tree.

08 · HARD PARTS

Key engineering challenges

Making interventions honestly beat neglect: early versions let abandoned demand pile up forever, so 'after' could never win — modelling customer abandonment fixed the dynamics and sharpened the story. Keeping the constraint computed (not staged) meant the camera, scan and copy all had to follow the engine wherever it pointed. Separating WebGL capability from runtime state eliminated a class of false 'unsupported device' dead-ends. And keeping 60 fps meant instancing everything that repeats and letting the render loop read the store without React in the way.