Test
\n \n\n```\n````\n\n### Output\n\n```html\n\n\n \n \nTest
\n \n\n```\n\n## List Types\n\n### Ordered List\n\n#### Syntax\n\n```markdown\n1. First item\n2. Second item\n3. Third item\n```\n\n#### Output\n\n1. First item\n2. Second item\n3. Third item\n\n### Unordered List\n\n#### Syntax\n\n```markdown\n- List item\n- Another item\n- And another item\n```\n\n#### Output\n\n- List item\n- Another item\n- And another item\n\n### Nested list\n\n#### Syntax\n\n```markdown\n- Fruit\n - Apple\n - Orange\n - Banana\n- Dairy\n - Milk\n - Cheese\n```\n\n#### Output\n\n- Fruit\n - Apple\n - Orange\n - Banana\n- Dairy\n - Milk\n - Cheese\n\n## Other Elements: abbr, sub, sup, kbd, mark\n\n### Syntax\n\n```markdown\nGIF is a bitmap image format.\n\nH2O\n\nXn + Yn = Zn\n\nPress CTRL + ALT + Delete to end the session.\n\nMost salamanders are nocturnal, and hunt for insects, worms, and other small creatures.\n```\n\n### Output\n\nGIF is a bitmap image format.\n\nH2O\n\nXn + Yn = Zn\n\nPress CTRL + ALT + Delete to end the session.\n\nMost salamanders are nocturnal, and hunt for insects, worms, and other small creatures." }, { "id": "using-mdx", "type": "writing", "title": "Using MDX", "description": "Lorem ipsum dolor sit amet", "date": "2024-06-01T00:00:00.000Z", "category": null, "tags": null, "url": "https://ryansnowden.com/writing/using-mdx/", "content": "This theme comes with the [@astrojs/mdx](https://docs.astro.build/en/guides/integrations-guide/mdx/) integration installed and configured in your `astro.config.mjs` config file. If you prefer not to use MDX, you can disable support by removing the integration from your config file.\n\n## Why MDX?\n\nMDX is a special flavor of Markdown that supports embedded JavaScript & JSX syntax. This unlocks the ability to [mix JavaScript and UI Components into your Markdown content](https://docs.astro.build/en/guides/markdown-content/#mdx-features) for things like interactive charts or alerts.\n\nIf you have existing content authored in MDX, this integration will hopefully make migrating to Astro a breeze.\n\n## Example\n\nHere is how you import and use a UI component inside of MDX. \nWhen you open this page in the browser, you should see the clickable button below.\n\nimport HeaderLink from '../../components/layout/HeaderLink.astro';\n\n\n Since when do you tell the enemy you have won?\n \n\n
Stable, reliable baseline operating within standard procedures.
\nTesting novel approaches and localized variations.
\nVisible to risk/compliance officers, lacking evidence to justify itself.
\nActively suppressed by risk management or audit controls.
\nShielded from compliance shutdown by leadership sponsorship.
\nAccumulated enough evidence to become an accepted new practice.
\nTrauma from past failed initiatives. Highly sensitive to new change.
\nLost all functional capacity; abandoned or broken process.
\nWhen executives mandate a hype trend across the company without real proof or local testing, it spreads like wildfire — disrupting core work until teams burn out and operations break down.
\nScarred by past failed projects, the organization panics at the slightest change. Compliance officers overreact, surrounding teams with red tape until normal work grinds to a halt.
\nLeaders demand innovation, but teams have seen too many short-lived initiatives fail. Everyone pretends to participate while secretly waiting out the mandate until things return to normal.
\nTeams play it safe and never try anything new. To avoid scrutiny, they stick strictly to outdated methods — until hidden technical debt builds up and entire departments quietly collapse.
\nA small mistake triggers an overreaction. Fear from past failed projects causes compliance rules to snowball, eventually shutting down healthy teams doing normal work.
\nThe company looks healthy on the surface, but underneath, years of avoiding risk have created fragile workarounds. A sudden market shock at tick 300 reveals the hidden weakness, causing widespread collapse.
\nAn R&D team is isolated behind a protective barrier (amber line). The lab succeeds in its bubble, but because its learnings never reach the main company, an external crisis at tick 400 eventually drags the whole enterprise down.
\nGrassroots connections (cyan threads) allow teams to share proven ideas directly across silos. By routing around bureaucratic blockers, good ideas gain traction far faster than through top-down mandates.
\nEight scenarios showing different setups of the AI-accelerated design process.
\n\nThe ideal state. Fast AI build paired with active design produces steady throughput, high coherence and stronger cost efficiency. Designers guide fast-moving engineering rather than gatekeeping.
\nThe old world. Everything queues for vision (upfront spec), build is slow (no AI), and design reviews everything. Throughput is low but coherence is perfect. The cost is time.
\nEngineering adopts AI but design does not adapt. High throughput at first, but the kill rate climbs because shipped work is incoherent. It can look efficient until rework and wasted output push the real cost up.
\nAdds a deliberate discovery phase before vision. Slower to start but higher quality input. Lower kill rate, better outcomes. Shows why framing the problem well matters even in a fast loop.
\n\"Move fast and break everything.\" Items fly through but nobody understands the code. Watch the vibe debt rings grow with each loop. The output looks cheap at first, then rework and low coherence make each useful ship more expensive.
\nRunning many AI agents without coordination. Individual speed is fast but conflicts dominate. More agents means more merge conflicts, and the extra burn can outweigh the parallel speed gains.
\nStarts well. But as WIP grows and the codebase gets larger, AI build speed degrades. Items that took 1x now take 3x. Meanwhile, the team gets comfortable trusting AI output and stops checking carefully.
\nThe compounding nightmare. Each time an item loops back, its processing time grows. Meanwhile, coherence drops, making future design work slower. Watch cycle time accelerate over the simulation's runtime.
\nThe simulation models two modes that designers move between:
\n\nLook 3 to 6 months ahead and define what the product should feel like. The output is a working prototype or narrow \"north star\" flow, not a slide deck. It constrains and aligns the AI-driven experiments teams are running.
\nSit with engineers while they use AI to build flows. Continuously correct layout, interaction, states, copy, and hierarchy. Enforce patterns, design system usage, and accessibility. Do last-mile fixes yourself in code.
\nFigma remains key for parallel exploration and high-fidelity craft. The difference is weight and timing: instead of dominating the process, Figma explorations sit inside shorter cycles, with fewer big speculative flows and more targeted problem-solving.
\n\nWhere 60 to 70% used to be mocks and prototypes, that is now about 30 to 40%. Another 30 to 40% is pairing with engineers. A meaningful slice is implementing front-end code and polish directly. The old practices are not gone. Their relative weight has shrunk inside a faster, code-first loop.
\n\n This simulation shares a thesis with Maggie Appleton's \"One Developer, Two Dozen Agents, Zero Alignment\" talk from GitHub Next. Both arrive at the same conclusion from different directions:\n
\n\n\n “Speed without alignment produces waste, not value.”\n\n
\n The collapse of implementation time reveals that alignment was always the real work. The old slow process incidentally created alignment through its friction. When implementation collapsed, the alignment infrastructure went with it.\n
\n\n This simulation shows it mechanically: when you speed up AI Build and strip out design, you don't get faster output, you get faster waste. \n Appleton states it directly: \"The hard question is no longer how to build it. It's should we build it.\"\n
\n\n The Agent Swarm scenario and Productivity Paradox mechanic model this quantitatively. \n Appleton calls it \"nine women make a baby in one month\" logic. More individual output makes coordination problems worse.\n
\n\n The Vision Mode and Execution Mode loop in this simulation is a continuous cycle, not sequential phases. \n Appleton says the same: \"Planning and building are no longer separate phases. They're a continuous cycle.\"\n
\n\n Run the Vibe Coding scenario and watch throughput spike, then watch the kill rate climb and coherence drop. \n Appleton: \"It's very easy to prompt your way to the wrong thing or to add tons of unnecessary, unhelpful features.\"\n
\n\n The AI + Design Partnership scenario outperforms raw-speed scenarios on cost efficiency. \n Appleton: \"In a world of fast, cheap software, quality becomes the new differentiator. Craftsmanship is what will set you apart from the vibe-coded slop.\"\n
\n\n Models the internal states of a single team's workflow. How ideas flow through stages, where friction accumulates, and what breaks. The solution is a better process with design guardrails.\n
\nMisalignment compounds. Bad alignment doesn't just waste units of work, it makes all future work harder.
\n\n Zooms out to the infrastructure. PRs and Issues are the wrong primitives for the agentic era. The solution is a better environment where alignment happens naturally.\n
\n\"Human context is not in the codebase.\" No amount of code context can replace sharing the \"why\" early.
\n\n The valuable friction was never the implementation friction. It was the thinking friction. This simulation answers what happens when alignment breaks; Appleton answers what infrastructure we need to prevent it from breaking.\n
\nSix properties that model real failure modes in AI-driven engineering:
\n\nAI generates code that looks correct but is wrong. Items pass through AI Build, appear done, but get caught during Learn/Adjust and loop back. The faster you build without design review, the more bad output slips through.
\nMultiple AI agents working on overlapping areas produce conflicting code. A build server gets blocked while conflicts are resolved, taking 3x normal time. Conflict probability scales with the number of busy servers.
\nSome ideas hit the boundary of what current AI models can do. These items (amber, larger circles) require manual engineering and take 4x longer. They look the same entering the pipeline but reveal themselves mid-processing.
\nAs the system accumulates work in progress, AI tools lose context and output quality drops. Build speed degrades as the codebase grows beyond the AI's context window. This is a simplified model of a real and well-documented limitation.
\nItems built fast with AI, but nobody understands the code. Each time an item loops back, its debt increases, adding a multiplier to future processing time. Visible as red dashed rings growing around dots. By the 3rd loop, processing time has nearly doubled.
\nWhen items ship without going through Design, the global coherence score drops. As coherence falls, all Design work takes longer because the team is fixing inconsistencies instead of doing proactive work. Skipping design makes future design harder.
\nFour friction mechanics based on published cognitive and behavioral research. These model what happens to teams, not just to code. Each is toggleable in the simulation's AI Friction panel.
\n\nWhen AI does most of the work, the team gradually loses the ability to do it themselves. The simulation slows down build and design servers over time in proportion to how little design involvement there is.
\nBased on a 2026 Anthropic study where AI-assisted developers scored 17% lower on comprehension tests. Vibe coding research documents progressive skill loss when AI handles all code generation. This is a simplified model. In reality, skill loss varies by individual and task. The simulation approximates the trend.
\nAfter a string of successful ships, the team gets comfortable and stops checking AI output carefully. The simulation makes hallucinations harder to catch after each consecutive successful ship. Catching a hallucination resets the streak.
\nBased on a Google study of 76 software engineers that found automation trust increases over time. Separate research found that as AI gets better at writing code, humans get worse at reviewing it. The effect is well-documented in automation research going back 75 years.
\nEvery time an item skips design review, it adds to a global slowdown. The team's ability to solve problems erodes because they are not exercising it. The simulation makes all rework and iteration processing slower as cognitive debt accumulates.
\nBased on research documenting the systematic erosion of problem-solving ability when developers rely heavily on AI. Developers stop reading documentation, debugging skills dull, and error messages become unfamiliar. The simulation models this as a global multiplier. The real effect is more nuanced but the direction is consistent across studies.
\nAdding more AI agents does not produce proportionally more output. Beyond 2 active agents, each additional agent adds coordination and review overhead that slows everyone down. The simulation applies a logarithmic overhead multiplier to all build servers.
\nBased on a randomized controlled trial of experienced open-source developers that found AI tools actually increased completion time by 19%. This contradicted developer predictions of 20% time savings. The simulation models the overhead simply, but the finding is robust: more AI assistance does not always mean faster results.
\nThree designer types that thrive in this new loop:
\n\n80th percentile or above across several core skills: product thinking, UX, visual, some coding. They flex between PM, design, and engineering-adjacent work as roles blur, and they are the most valuable in fast-moving teams where nobody can stay in one lane.
\nTop-tier in something that sets products apart: visual systems, iconography, or technical design and implementation. Their depth creates advantages that AI cannot easily match and generalists cannot replicate.
\nEarly-career designers who are humble, learn fast, and are unburdened by legacy process. They actively build things with new tools rather than clinging to old methods. Not knowing how it \"used to be done\" is their advantage.
\nDesigners must let go of gatekeeping and instead guide fast-moving engineering. This means explaining design principles, teaching the design system, and raising the overall design ability of the team rather than trying to own every pixel. Implementation literacy is increasingly baseline. You may not need to be a full-stack engineer, but you do need to work effectively with AI coding tools and make last-mile UI changes yourself.
\nCircles inside AI Build and Design zones represent processing capacity:
\nFour scenarios represent distinct topological configurations that AI companies must navigate.
\n\nClinicians are at their breaking point with paperwork. Ambient AI reduces documentation workload so doctors spend less energy taking notes and more time with patients. But if the AI requires too much manual double-checking, clinicians revert straight back to old dictation habits.
\nStrict regulation (like the EU AI Act) turns loose guidelines into strict law. High-risk AI products without compliance certification hit a brick wall — the energy cost to operate non-compliant tools becomes impossibly high.
\nHospitals run on razor-thin margins. AI tools that don’t tie directly to official billing codes (CPT codes) get starved of budget. If a tool doesn’t generate clear reimbursement, adoption drops to zero.
\nWhen an AI model makes a confident clinical mistake, trust plummets instantly. Rebuilding clinical trust takes months of flawless performance. A single high-profile error traps the product in a liability risk zone.
\nConstructors transform input states to output states without undergoing net change themselves.
\n\n| Constructor | \nFunction | \nScenario | \n
|---|---|---|
| Ambient Scribe | \nReduces cognitive friction by transforming conversation → SOAP note | \nAmbient Capacity | \n
| Compliance Audit | \nEnables crossing regulatory walls via audit trail | \nRegulatory Phase Shift | \n
| CPT Enabler | \nExtends revenue tether radius via new billing codes | \nReimbursement Tether | \n
| Trust Anchor | \nSlows trust decay, aids linear recovery via verification | \nHallucination Event | \n
These buttons add overlays to help you understand what's happening in the simulation.
\n\n #### Cynefin Overlay\n\n The Cynefin framework helps you understand how predictable different parts of the system are. When you click **Cynefin**, the simulation area gets colour-coded into four zones:\n\n - **Clear (Green)**: These areas are predictable. Cause and effect are obvious. Best practices work here. Think of well-documented procedures that always give the same result.\n\n - **Complicated (Blue)**: Still predictable, but you need expertise to understand what's going on. An expert can analyse the situation and figure out the right approach. Think of a specialist diagnosing a known problem.\n\n - **Complex (Purple)**: Cause and effect only make sense in hindsight. You can't predict outcomes because too many things interact. The best approach is to try small experiments and see what happens.\n\n - **Chaotic (Red)**: No clear cause and effect. Things are unstable and you need to act first, then figure out what's happening. Think of a crisis where you stabilise first and ask questions later.\n\n The simulation calculates which zone each area belongs to based on two factors: how volatile the area is (the right edge is more volatile), and how close to constraints an area is (more constraints means more structure).\n\n ---\n\n #### Network Topology\n\n Click **Net** to see the invisible relationships between agents. The simulation draws purple lines between agents that are close enough to influence each other.\n\n This shows you the social network forming in real-time. Agents that are near each other can share information and copy each other's behaviour. The lines get stronger (more visible) when agents are closer together.\n\n You can use this to spot clusters forming, identify isolated agents, and see how information might spread through the group. The total number of connections is shown at the bottom of the screen.\n\n ---\n\n #### Wardley Map\n\n Click **Wardley** to overlay strategic positioning axes onto the simulation.\n\n Wardley Mapping is a strategy tool that plots components based on how evolved they are and how visible they are to users. The overlay adds:\n\n - **X-Axis (Evolution)**: Shows how mature something is. The left side is \"Genesis\" (new, experimental ideas). Moving right, you pass through \"Custom Built\" (one-off solutions), then \"Product\" (off-the-shelf options), and finally \"Commodity\" on the far right (utilities everyone uses like electricity).\n\n - **Y-Axis (Visibility)**: Shows how visible a component is to end users. Things at the top are user-facing and obvious. Things at the bottom are invisible infrastructure that users never see.\n\n The labels change depending on which scenario you're viewing. In healthcare scenarios, the evolution stages might be labelled differently to match the domain (for example, \"Research\" to \"Standard of Care\").\n\n This overlay helps you think strategically about where things are positioned. Volatile areas (left side) suit experimental work. Stable areas (right side) suit commodity services.\n\n ---\n\n #### VSM Roles (Viable System Model)\n\n Click **VSM** to see how the simulation maps to Stafford Beer's Viable System Model, a way of understanding organisations as living systems.\n\n The overlay highlights four levels:\n\n - **System 1 Operations (Green)**: The agents themselves. These are the things that actually do the work. In an organisation, this would be the front-line teams delivering products or services.\n\n - **System 2 Coordination (Yellow)**: The constraints. These dampen oscillations and stop parts of the system from fighting each other. They're the rules, schedules, and standards that keep things running smoothly.\n\n - **System 3 Control (Blue)**: The constructors. These allocate resources and monitor performance. They make sure the operational units have what they need and are working effectively.\n\n - **System 5 Policy (Red)**: The boundary of the entire system. This is identity and purpose. It defines what the system is and what it's not. The red border around the simulation area represents this.\n\n This overlay helps you think about organisational design. A viable system needs all five levels working together. If you only have operations (System 1) without coordination (System 2), you get chaos. If you have too much control (System 3) without operational freedom, you get stagnation.\nThe current implementation is primarily Agent-Based Modelling (ABM) with continuous physics. These enhancements map organizational complexity theories to specific simulation mechanics.
\n \nAgents form groups that compete as units, creating selection pressure at both individual and group levels.
\nReplaces spatial proximity with network connections using power-law degree distributions for realistic organizational structure.
\nAgents carry strategy genotypes subject to mutation, crossover, and selection.
\nConstraints modify the energy required to move actants through the healthcare terrain.
\n\nModeled using Hooke's Law with a failure point. When cognitive load exceeds the yield point, the workforce snaps back.
\nStep function where energy approaches infinity for non-compliant actors.
\nCost is zero inside CPT code scope, infinite outside.
\nTrust decays exponentially after errors but recovers linearly, requiring far more work to rebuild.
\nThis simulator introduces two physics models not present in the standard Estuarine Mapping sims, designed specifically for modelling healthcare trust dynamics and volatile zone behaviour.
\n\nIn the volatile zone (right edge), agents follow the **Langevin equation** (a stochastic differential equation that models proper Brownian diffusion rather than uniform noise).
\nWhere ∇V is the energy gradient (gradient descent toward lower energy), and σdW is Gaussian noise from a Wiener process.
Used in: All scenarios (volatile zone behaviour)
\nTrust dynamics follow a **hysteresis loop** where falling into a liability well is fast but climbing out is slow. This models the asymmetric energy cost of reputation damage.
\nT *= exp(-0.05)T += 0.002Visual feedback:
\nUsed in: Confident Hallucination scenario (dark constraints)
\nVisualising the feedback loops and hierarchical structures driving the simulation.
\n\nHow agents make decisions: combining flocking rules with cognitive biases under constraints.
\nMapping Estuarine entities to Stafford Beer's cybernetic tiers.
\nThe reinforcing cycle of burnout and the balancing loop of Ambient AI.
\n| Type | \nMetaphor | \nDynamics | \n
|---|---|---|
| Elastic | \nRubber Band | \nStretches with pressure, snaps back at yield point (Burnout). | \n
| Rigid | \nConcrete Wall | \nFixed boundary. Infinite energy cost to cross (Compliance). | \n
| Permeable | \nMesh Fence | \nPassable with friction. Filters agents by cost (Workflow). | \n
| Tether | \nDog Leash | \nZero cost within radius, infinite outside (Reimbursement). | \n
| Dark | \nGravity Well | \nAttracts agents. Easy to enter, hard to leave (Liability). | \n
\n Unlike a delta's unidirectional flow, an estuary is defined by Bidirectional Flow, which is the turn of the tide.\n
\n\nStrategic momentum flows inward. Energy costs increase as you push against established structures. The system resists change.
\nStrategic windows open. Energy costs decrease. Small interventions can achieve disproportionate movement as the system naturally shifts.
\nBehind the visual simulation sits a mix of physics, behavioural economics, and complexity theory. You don't need a PhD to use the map, but here is how those theories power the mechanics under the hood.
\n\n\n What this means in practice: Traditional planning asks \"What will happen in Q4?\" Constructor Theory asks \"What transformations are physically and socially possible right now, and what tools do we need to enable them?\"\n
\n\n What this means in practice: Organisations have history. A team that spent five years under rigid bureaucracy won't suddenly become agile overnight just because you launched a new slide deck. Systems get trapped in \"deep wells\" (attractors) of past habits, a phenomenon known as hysteresis.\n
\n\n The Math: Strategy succeeds when doing the right thing (the Energy Cost of Virtue,
\n What this means in practice: People don't act like rational computing units. They resist change, seek safety in crowds, and prioritize immediate relief over long-term gains. The blue dots (agents) in the simulation model three core human behaviors:\n
\nConstraints are not merely limitations, they are boundary conditions that allow order to emerge.
\n\n| Type | \nCharacteristics | \n
|---|---|
| Rigid | \nImmovable sea walls. Core safety regulations, legal requirements. High energy cost to move or work around. | \n
| Elastic | \nStretches under pressure but snaps back. Crunch-time overtime, temporary workarounds. Oscillates with the tide. | \n
| Tether | \nFreedom within a defined radius. Bounded flexibility: can move, but not escape. Employee autonomy within KPIs. | \n
| Permeable | \nSelective membranes. Informal social networks that cross organisational silos. Agents may or may not pass through. | \n
| Phase Shift | \nTipping points. Near bifurcation thresholds where small changes cause sudden, qualitative shifts in system topology. | \n
| Dark | \nInvisible forces. Shadow IT, informal hierarchies. Detectable only through their \"gravitational\" influence on flow. | \n
The tide cycles through three distinct states, each affecting system behavior differently.
\n\nLeadership intent is modeled as directional vectors applied to actants. Vectors create local \"winds\" that alter energy flow, visualized as arrows emanating from Constraints and Constructors.
\n\nWhen a vector opposes the natural tidal flow, Turbulence appears as an orange glow around the actant, visualizing leadership friction.
\nActants don't exist in isolation; they're connected through invisible bonds that create emergent organisational dynamics.
\nPurple animated tethers representing hidden coupling between nodes.
\nCyan dashed lines representing If-Then causal links between actants.
\n| Type | \nFunction | \nVisual | \n
|---|---|---|
| Entanglement | \nConstraint-Distance Spring coupling | \nPurple curved tether with glow | \n
| Signal | \nIf-Then conditional effect propagation | \nCyan dashed line with traveling pulse | \n
Real-world strategic situations modeled through the estuarine lens.
\n\nParticles represent strategic initiatives (product launches, R&D bets) and the tidal ocean represents broader market forces (economic cycles, technology shifts, competitor moves).
\n \nWhen disruption hits, it arrives like a spring tide, which is a powerful, external surge that floods your strategic landscape. Watch how:
\nHere, particles represent digital projects such as cloud migrations, new platforms, and process automations, while the Rigid Constraints represent legacy ERP systems that cannot easily move or change. This is the classic enterprise transformation dilemma.
\n \nLegacy systems create energy wells, consisting of deep basins of attraction that trap projects. Digital initiatives must either:
\nThis scenario showcases Entanglement Bonds:
\nParticles represent individual employees (career trajectories, loyalty) and the tidal ocean represents the job market (economic conditions, industry trends, competitive offers).
\n \nPeople are not resources to be \"managed\"; they flow like water, seeking the path of least resistance toward their goals. Watch how:
\nThis scenario demonstrates the highest Social Proof coefficient:
\nHere, particles represent organisational processes such as workflows, procedures, and data handling practices, while the tidal ocean represents the regulatory environment: new frameworks (GDPR, SOX, AI governance) that arrive with the force of a spring tide, reshaping the landscape.
\n \nRegulation doesn't ask permission. It arrives, and organisations must adapt or face consequences. Watch how:
\nOrganisations exhibit three distinct responses to regulatory pressure:
\nControls the amplitude of bidirectional flow. Higher values create stronger strategic windows but also more turbulence.
\nHow strongly agents resist moving to higher-energy states. Range 1.0–3.0. Higher values create more \"sticky\" organisational inertia.
\nCluster detection range for herding behavior. Larger values cause agents to form bigger clusters. Varies by scenario.
\nMultiplier for strategic vector influence. Higher values make leadership intent (arrows) more forceful on nearby agents.
\nVisualizes the energy landscape. Green = low cost of change. Yellow = moderate. Red = high resistance zones.
\nShows the current tidal velocity field. Arrows indicate direction and strength of flow at each point.
\nClick any Constraint or Constructor to access individual settings:
\nHow far the actant's strategic vector affects nearby agents. Shown as a dotted circle.
\nN/S/E/W compass control. Combine axes (e.g., NW) for diagonal intent. Affects agent acceleration within influence radius.
\nIntegrates principles from behavioral economics, cognitive psychology, physics, and complexity science.
\n\n\n Where
\n Nearby agents (
\n Separation: Avoid crowding neighbors (inverse-square falloff).\n
\n```typescript\n// Flocking Behavior (Boids)\nconst cohesion = this.steerToward(averagePosition);\nconst alignment = this.steerToward(averageHeading);\nconst separation = this.avoid(neighbors);\n\n// Sum of vectors with weights\nthis.acceleration.add(cohesion.mult(0.01));\nthis.acceleration.add(alignment.mult(0.05));\nthis.acceleration.add(separation.mult(0.1));\n```\n\n Agents descend the energy landscape, seeking \"basins of attraction\" (stable low-energy states). The gradient
\n Where
\n Agents older than
\n When cluster inductance exceeds
\n Agents adopt properties (inductance, loss aversion) of nearby successful neighbors with higher flow rates.
\n Entanglement bonds apply spring forces when stretched beyond their rest length
\n Where
\n Organisations display path-dependency: the sequence of past decisions constrains future options. This is why certain \"attractor basins\" (e.g., bureaucratic stagnation) are difficult to escape once entered.\n
\n```typescript\n// State depends on history\n// Once trapped in a basin, small fluctuations can't escape\nif (isInBasin && inputForce < escapeThreshold) {\n this.state = \"TRAPPED\"; // Remains trapped even if force > 0\n} else {\n this.state = \"flowing\";\n}\n```\n\n The goal of strategic design is to ensure
\n “比目中路析。”\n
\n “Eyes once paired, but now parted midway.”\n \n
RuleDistributionGraph dependency from the sidebar.\n “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.”\n \n\n
| Suppliers 🚚 | \nInputs 📥 | \nProcess (High-Level Steps) ⚙️ | \nOutputs 📤 | \nCustomers 👤 | \n
|---|---|---|---|---|
\n
| \n \n
| \n \n
| \n \n
| \n \n
| \n
Bins are lightly stocked with plenty of clean, available space. Stowers face no conflict between accuracy and speed, allowing hourly targets to be met comfortably without taking shortcuts.
\nBins approach working limits. While the floor appears controlled on paper, the margin for error is thin. Finding correct placements takes longer, forcing workers to choose between speed and compliance.
\nHigh target pressure combined with crowded bins leads to visual disorganization. Workers prioritize job security over bin hygiene, causing shortcut stows to proliferate rapidly [4].
\nStorage complexity quantifies how difficult it is for a stower to find an open, legal home for an item. As slot scarcity and bin messiness rise, complexity increases non-linearly.
\nStow pressure represents the psychological drive to take shortcuts when hourly rate targets exceed realistic floor capacity.
\nThe probability that a stower follows proper placement procedures. Organizational rule support serves as the strongest positive factor counteracting rate pressure.
\nProcess Efficiency tracks the percentage of total operational work that is value-add (compliant stows and clean picks) versus non-value-add rework generated by shortcut stows and search drag.
\n```typescript\n// Process Efficiency - model.ts:computeMetricSnapshot\nconst wasteRate = casesProcessed === 0\n ? 0\n : clamp(ruleBreakingRate * 0.5 + nonNeatBinShare * 30 + (100 - Math.min(100, pickerKpi)) * 0.2, 0, 100);\nconst processEfficiency = clamp(100 - wasteRate, 0, 100);\n```\n\n Amazon, \"Inside Amazon's fulfillment centers: What you can expect to see on a warehouse tour,\" About Amazon, 11 Mar. 2019.\n aboutamazon.com\n
\n\n Amazon Technologies, Inc., \"System and method for stow management of similar items,\" U.S. Patent US8341040B1, 1 Jan. 2013.\n patents.google.com\n
\n\n A. Delfanti, \"Machinic dispossession and augmented despotism: Digital work in an Amazon warehouse,\" New Media & Society, vol. 23, no. 1, pp. 39-55, 2021.\n
\n\n E. J. Cheon and I. Erickson, \"Fulfillment of the work games: Warehouse workers' experiences with algorithmic management,\" Proc. ACM Hum.-Comput. Interact., vol. 9, no. CSCW, Art. no. 228, 2025.\n
\n\n R. Mannion and J. Braithwaite, \"When a measure becomes a target, it ceases to be a good measure,\" BMJ Quality & Safety, vol. 30, no. 3, pp. 263-267, 2021.\n
\n\n J. W. Treem, P. M. Leonardi, and B. van den Hooff, \"Coping with Goodhart's law in an era of digitisation and datafication,\" Journal of Computer-Mediated Communication, vol. 28, no. 4, 2023.\n
\n\n A. C. Edmondson, \"Psychological safety and learning behavior in work teams,\" Administrative Science Quarterly, vol. 44, no. 2, pp. 350-383, 1999.\n
\n\n S. Kim, S. B. Choi, and K. Kim, \"The influence of corporate social responsibility on safety behavior: The mediating role of psychological safety and organizational commitment,\" Frontiers in Public Health, vol. 10, 2022.\n
\n\n W. Qian, J. Horisch, and S. Schaltegger, \"Using a balanced scorecard to manage corporate social responsibility,\" International Journal of Management Reviews, vol. 22, no. 2, pp. 185-208, 2019.\n
\n\n R. S. Kaplan and D. P. Norton, The Balanced Scorecard: Translating Strategy into Action. Boston, MA, USA: Harvard Business School Press, 1996.\n
\n\n A. Kohn, Punished by Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes, 25th anniversary ed. Boston, MA, USA: Houghton Mifflin Harcourt, 2018.\n
\n\n T. M. Jones, \"Ethical decision making by individuals in organizations: An issue-contingent model,\" Academy of Management Review, vol. 16, no. 2, pp. 366-395, 1991.\n
\n\n H. Mintzberg, The Structuring of Organizations: A Synthesis of the Research. Englewood Cliffs, NJ: Prentice-Hall, 1979. (See also H. Mintzberg, \"Structure in 5's: Designing Effective Organizations,\" Management Science, vol. 26, no. 3, pp. 322-341, 1980).\n doi.org/10.1287/mnsc.26.3.322\n
\n\n Core scientific principles:\n
\n\n\n In Simulation: Nodes have a Cognitive Load capacity. As a node's load exceeds 80%, its processing speed drops according to a cubic decay curve
\n In Simulation: The WIP (Work In Progress) metric tracks L. Users can observe that increasing Frequency (λ) without increasing node speed results in an explosion of Lead Time (W), which is similar to a traffic jam forming when cars enter a highway faster than they exit.\n
\n```typescript\n// L (WIP) = λ (Arrival Rate) * W (Lead Time)\n// In simulation, we track L directly as the number of active items\nconst L = workItems.length;\n\n// Lead time (W) accumulates as items wait in queues\nif (blocked) {\n this.timeWaiting++;\n} else {\n this.timeActive++;\n}\n```\n\n In Simulation: The Coordination Penalty increases automatically as you add Value Units (nodes). This adds a global \"noise\" factor to the system, simulating the friction of alignment in larger groups.\n
\n```typescript\n// Metcalfe's Law / Brooks' Law derivative\n// Coordination Penalty ∝ N(N-1)/2\nconst pairs = (nodeCount * (nodeCount - 1)) / 2;\nconst penalty = pairs * 0.0015;\n\n// Applied as 'noise' to every action\nconst totalNoise = config.noiseLevel + penalty;\n```\n\n In Simulation: The System Entropy metric analyses the spatial distribution of work items. Low entropy indicates structured, predictable pulses of work. High entropy indicates scattered, unpredictable jitter, which is a hallmark of unstable systems.\n
\n```typescript\n// Calculate Shannon Entropy H(X) = -Σ P(x) log P(x)\nlet entropy = 0;\nworkItems.forEach(w => {\n // distribution of work items across links\n const idx = links.indexOf(w.link); \n if (idx > -1) distribution[idx]++;\n});\n\ndistribution.forEach(count => {\n if (count > 0) {\n const p = count / workItems.length;\n entropy -= p * Math.log(p);\n }\n});\n```\n\n In Simulation: When enabled, the Prediction Layer (represented by a cyan dashed ring) attempts to 'chase' and estimate the true Cognitive Load (the solid ring), filtering out stochastic jitter. It visually demonstrates the difficulty management faces in distinguishing \"signal\" (true capacity issues) from \"noise\" (random fluctuations).\n
\n```typescript\n// 1. Predict (Time Update)\nlet predNext = this.kfEstimate;\nthis.kfErrorCov = this.kfErrorCov + this.kfProcessNoise;\n\n// 2. Update (Measurement)\nconst K = this.kfErrorCov / (this.kfErrorCov + this.kfMeasureNoise);\nthis.kfEstimate = this.kfEstimate + K * (measuredLoad - this.kfEstimate);\nthis.kfErrorCov = (1 - K) * this.kfErrorCov;\n```\nIn Simulation: When Psychological Safety is low, errors are hidden (purple dots). These have a 50% chance of being rejected at the end of the line and sent back to the start, consuming capacity without generating value.
\n```typescript\nif (Math.random() < errorChance) {\n if (Math.random() < config.psychSafety) {\n // High Safety: Stop the line (Visible Error)\n this.blockTimer = 40; \n return false;\n } else {\n // Low Safety: Hide the error (Latent Defect)\n workItem.isDefect = true; \n return true;\n }\n}\n```\nThese controls model the soft-skills/psychological dimension of the system.
\n\n\n Definition: The belief that one will not be punished or humiliated for speaking up with ideas, questions, concerns, or mistakes (Amy Edmondson).\n
\nDefinition: The total amount of mental effort being used in the working memory (John Sweller).
\nMechanism: Represented by the coloured ring around a node. Work items add load; time decays it. High load triggers the Kingman effect (slowdown) and increases the probability of error generation.
\nDefinition: Transient variability in judgement or performance caused by external factors (mood, weather, interruptions) (Daniel Kahneman).
\nMechanism: Adds random \"jitter\" to particle movement speed and increases the base probability of gate failure, independent of structural design.
\nThese controls model the structural architecture of the organisation.
\n\nRepresents teams, departments, or servers. Increasing nodes increases capacity but incurs the Coordination Penalty (Brooks's Law).
\nRepresents approval steps, handovers, bureaucracy, or middleware.
\n\n Cells interlinked within cells interlinked\n
\n Within one stem. And dreadfully distinct
\n Against the dark, a tall white fountain played.\n\n What does this mean?\n
\n \n
The realm of innovation. You can see this as the future in all directions. The best opportunities are hidden out there in the fog.
\nThe safe, stable \"cell\" where the company currently operates, optimized for its current metrics.
\nThe Product Managers, R&D Engineers, and Individual Contributors exploring the grid, trying to find high-value ideas.
\nThe corporate forces—such as Finance (CFO), HR, and Compliance—hunting down highly visible or expensive experiments and shutting them down to protect the core business.
\nSmall, cheap, and low-risk experiments (e.g., a two-week design sprint, a user interview, a cheap prototype). They stay closer to the safe cell, innovating in minor ways. Because they are small, they often fly under the radar of the Cost Controllers, gradually building evidence and proving their value.
\nLarge, highly visible leaps into the unknown (e.g., massive reorgs, multi-year IT transformations, or \"bet the company\" product launches). They quickly attract the Risk Management teams and are usually killed or severely compromised before they can succeed.
\nYou can explore different organisational environments using the controls to see how the innovation teams fare against the corporate immune system (roles like Finance, HR, Compliance, and Operations).
\n\nA savage killing ground governed by rigid metrics. Here, the Cost Controllers (Finance/CFO) and Compliance Teams (HR/Legal) are highly sensitive to any deviation. Extremely hostile to anything new, big bets are immediately vetoed or defunded, and even small probes struggle to survive the constant scrutiny. You'll see Immune Cells aggressively swarm and destroy almost all Probes and Bets before they can gather any evidence.
\nThere is plenty of experimental activity, but the company fails to learn from it. Lots of money is spent, but evidence is ignored. Lots of probes are sent out by enthusiastic teams, but Middle Management fails to capture the learnings. You'll see a swarm of Big Bets and Quiet Probes that wander aimlessly without turning into Safe Zones or expanding the Core, eventually dying out.
\nA senior leader (e.g., the CEO or Head of R&D) provides a \"shield\" around an innovation team. A small team is shielded from the rest of the company, blocking the usual oversight from Finance and Operations. Bolder and riskier ideas have a chance to survive without being prematurely killed for lack of immediate ROI. You'll notice Probes surviving for long periods, slowly exploring the landscape without triggering Immune responses.
\nA healthy balance where the grid landscape of ideas is much greater. Executive Leadership intentionally lowers the immune response from Risk Management for small, reversible experiments. Highly tolerant of new ideas, projects have a safe space to fail and learn. Over time, you'll see Quiet Probes survive long enough to gather evidence and turn into Safe Zones, expanding the Core.
\nThe Board and Executive Team act as if the unpredictable future is totally predictable. The environment is complex and unpredictable. They repeatedly mandate large, expensive bets (e.g., massive acquisitions or \"bet the company\" product launches) that fail spectacularly when they eventually clash with reality and internal Operational Constraints. You'll see massive, highly visible Big Bets being launched, but failing to find peaks and getting killed off before they can succeed.
\n\n The simulation uses an **NK fitness landscape** combined with an **immune-response threshold** model to govern how innovation is detected and suppressed.\n
\n\nThe environment is modeled as an NK landscape, representing genuine uncertainty rather than calculable risk.
\n\n Big Bets have high visibility and structural novelty, nearly guaranteeing detection. Quiet Probes minimize these factors to stay below the detection threshold.\n
\nThe OII provides a unified metric representing the hostility of the corporate environment to new ideas. It is calculated as a weighted sum of key environmental parameters:
\nOII bands: Adaptive (0-24), Guarded (25-49), Defensive (50-74), and Autoimmune (75-100).
\nThe mathematical core of successful innovation in the model relies on a compounding spatial feedback loop:
\n\n In uncertain environments, standard corporate controls are tuned to reject anything different. By protecting low-cost, quiet experiments, a company can create information. That information builds legitimacy, and legitimacy finally permits confident investment.\n
\nScenarios demonstrating Queueing Theory and Theory of Constraints principles.
\n\nDemonstrates the Theory of Constraints. Increasing speed upstream (local optimisation) without addressing the bottleneck downstream only generates \"inventory\" (WIP), which is a form of waste. The QA queue will grow indefinitely, increasing lead time and defect risk.
\nShows that flow is destroyed not just by volume, but by friction. Servers appear \"busy\" (high utilisation), but they are working on \"failure demand\" or waiting, resulting in extremely low Flow Efficiency (<15%).
\nDemonstrates Kingman's Formula approximation. As system utilisation approaches 100%, queue times rise exponentially towards infinity. It proves that a system running at \"maximum efficiency\" effectively ceases to flow.
\nIllustrates the damage caused by large batch sizes or inconsistent ticket sizing. One large task blocks a server for a long duration, causing smaller tasks (\"Guppies\") to pile up behind it, drastically increasing the average wait time for the entire system.
\nPush vs. Pull is key to flow efficiency.
\n\nWork is **pushed** downstream the moment it's complete, regardless of whether the next stage is ready. This is how most organisations operate by default.
\nWork is **pulled** by downstream stages only when they have capacity. This is the Toyota Production System model.
\nThis simulation models a Push system to demonstrate failure modes. The growing queues are \"invisible inventory\" often missed by traditional metrics.
\nGuide to visual elements.
\n\nThe horizontal bar under each stage shows queue depth. When it fills up, work is piling up faster than it can be processed. A full bar indicates a bottleneck.
\nEach circle represents a \"server\" (developer, tester, or machine). When a server is processing work, it's filled. When idle, it's empty. Multiple servers process in parallel.
\nHow frequently new work items enter the system. Higher values simulate high-demand periods or sprints with aggressive commitments.
\nNumber of parallel workers in Stage 1 (Development). More servers = more throughput capacity, but only if downstream can absorb it.
\nNumber of parallel workers in Stage 2 (QA/Deploy). Often the bottleneck in real organisations due to specialisation and handoff friction.
\nHow quickly each server processes work. Represents team velocity, tooling efficiency, or automation level.
\nProbability that a completed item blocks downstream (e.g., integration failures, environment issues, merge conflicts). Creates cascading delays.
\nProbability that a completed item is rejected and sent back to the start. Represents bugs found in QA, failed code reviews, or requirement misunderstandings.
\nWhen enabled, a percentage of work items arrive as \"whales\": tasks that take 5x longer than normal. This simulates:
\nAbstracts human behaviour, mapping directly to real organisational patterns.
\n\nHigh blocking percentages often correlate with poor psychological safety. When teams fear blame for integration failures, they add more review gates and approval steps, which *increases* blocking probability. The simulation shows why \"more process\" often makes things worse.
\nRework represents the \"hidden factory\": capacity consumed by fixing defects that should have been caught earlier. High rework rates indicate poor requirements, insufficient testing, or rush-to-deploy pressure.
\nManagement often optimises for **utilisation** (keeping people busy), but the simulation shows this destroys **flow**. At 90%+ utilisation, queue times explode exponentially. The counterintuitive truth: slack capacity is essential for flow.
\nEach stage boundary represents a handoff: context lost, waiting for availability, re-explanation. The simulation's two-stage model is a simplification; real organisations often have 5-10+ handoffs, each multiplying delay and error probability.
\n\n Based on Queueing Theory and Lean management principles. These mathematical laws govern flow systems, whether physical manufacturing lines or digital software development. They explain why \"common sense\" management (like 100% utilisation) often fails mathematically.\n
\n\n\n What this means in practice: A standard mathematical formula for how lines form. It models work arriving unpredictably (like user stories landing in a sprint) being handled by a fixed set of workers (developers or QA testers).\n
\n\n What this means in practice: Software tasks aren't uniform. Most tickets take a normal amount of time, but occasional \"iceberg\" tasks take 5x longer. This distribution creates realistic real-world variance.\n
\n\n In Simulation: Used to generate randomized arrival times for new work items and the duration of service (work) for each server, ensuring the simulation reflects realistic variability rather than static averages.\n
\n```typescript\n// Generate random values following an Exponential distribution\n// Used for arrival times (Poisson process) and service durations\nconst getExponential = (rate: number) => {\n return -Math.log(1 - Math.random()) / rate;\n}\n\n// Generate next arrival time\ndata.nextArrivalTime = getExponential(params.arrivalRate) * 1000;\n```\n\n What this means in practice: If your team is flooded with work, the *only* way to make individual features ship faster (without hiring more people) is to stop starting new things and reduce Work in Progress (WIP).\n
\n\n In Simulation: Validates the statistical metrics displayed in the dashboard. It proves that if you cannot change the arrival rate (
\n In Simulation: Provides the \"Theoretical\" baseline for wait times. Comparison between this theoretical baseline and the \"Actual\" simulation results highlights the extra friction caused by factors Erlang-C doesn't account for, such as blocking and rework.\n
\n```typescript\n// Calculate Erlang-C probability that an item must wait\nconst calcErlangC = (lambda: number, mu: number, c: number) => {\n const rho = lambda / (c * mu); // Traffic intensity\n \n // Calculate sum of geometric series for P(0)\n let p0_inv = 0;\n for (let i = 0; i < c; i++) {\n p0_inv += Math.pow(lambda / mu, i) / factorial(i);\n }\n p0_inv += (Math.pow(lambda / mu, c) / factorial(c)) * (1 / (1 - rho));\n \n // Theoretical average queue length (Lq)\n return (Math.pow(lambda / mu, c) * rho * (1 / p0_inv)) / \n (factorial(c) * Math.pow(1 - rho, 2));\n};\n```\n\n In Simulation: Calculated dynamically by tracking the exact milliseconds an entity spends being \"serviced\" (Active Work) versus \"waiting\" or \"blocked\". It visualises how high server utilisation can coexist with terrible flow efficiency.\n
\n```typescript\n// Track value-added time vs total lead time for every item\nif (Math.random() < 0.1) { // 10% sampling rate for UI updates\n const flowEff = data.metrics.totalSystem > 0 \n ? (data.metrics.totalValueAdded / data.metrics.totalSystem) * 100 \n : 0;\n \n setSimState(prev => ({ \n ...prev, \n flowEfficiency: flowEff \n }));\n}\n```\n\n Client: Autonomé\n
\n\n Role: Consultant, Experience Designer, Product Strategy\n
\n\n Status: In Progress 👍🏻\n
\n