Introduction: Predicting Storms in a Paper Sky

In the early 1900s, divers off the coast of the Greek island Antikythera discovered a corroded lump of bronze that turned out to be something astonishing: an ancient analog "computer." The Antikythera mechanism was a hand‑cranked orrery, a mechanical model of the heavens used to predict eclipses and celestial events.

It didn’t stop the planets from moving or prevent eclipses. Instead, it made the invisible visible: the complex dance of celestial bodies became something you could see, turn, and understand.

We can do the same thing for incidents.

In modern distributed systems, failures are inevitable. Services go down, dependencies stall, attackers probe your defenses, power fails, or a “small” misconfiguration ripples through an entire ecosystem. Pretending these things won’t happen doesn’t make you safer; understanding and modeling them does.

This is where the Analog Incident Story Compass Orrery Desk comes in: a hand‑cranked, paper‑based universe of scenarios that lets teams explore how different risks and failures might collide—and do it before they do so in production.

From Antikythera to Incidents: Why an Orrery of Risk?

The Antikythera mechanism is a compelling metaphor for how we can think about risk and reliability:

• It models complexity using mechanical constraints.
• It simulates time—turn the crank and see the future.
• It shows interactions—gears connect cycles that otherwise feel unrelated.

Now imagine an orrery not of planets and moons, but of:

• Services and microservices
• Third‑party dependencies
• Network segments and regions
• Attack vectors and failure modes
• Incident response teams and playbooks

Instead of orbits and conjunctions, we see:

• Outages aligning with maintenance windows
• Novel attacks overlapping with known vulnerabilities
• A regional cloud incident colliding with your peak traffic

A physical, analog story compass orrery desk is a way to:

• Externalize the mental model of how failures propagate.
• Turn abstract risk diagrams into a tangible, shared artifact.
• Hand‑crank “time” to see what happens when multiple risks line up.

Failures in Distributed Systems: It’s Not If, It’s How

Distributed systems fail in characteristic ways. Some common failure models include:

• Partial failure: One component dies or slows down while others remain fine.
• Network partitions: Parts of the system lose contact but keep operating locally.
• Byzantine failures: Components behave inconsistently or maliciously (e.g., compromised node).
• Timing and latency issues: Systems are technically “up” but too slow to be useful.
• Cascading failures: A small fault triggers retries, timeouts, resource exhaustion, and wider collapse.

We often capture these in docs: architecture diagrams, risk matrices, dependency graphs. Useful—but flat.

An orrery‑style model lets you:

• Represent each failure model as a planet, moon, or orbit.
• Show gravitational pulls—dependencies and coupling between systems.
• Explore how conjunctions (e.g., “small network partition” + “retry storm” + “traffic spike”) turn into incidents.

The point isn’t to be perfectly accurate. The point is to:

Give your team a shared, manipulable model of how failures can interact.

The Story Compass Orrery Desk: A Paper Universe of Scenarios

Imagine a physical desk setup that functions like a narrative orrery of your system:

• A large base map showing your systems, regions, teams, and key external dependencies.
• Cut‑out disks or rings representing different classes of risk (e.g., infra, app bugs, human error, vendor, natural disaster, cyber attack).
• Concentric orbits representing time horizons (e.g., hours, days, weeks, quarters) or severity escalation levels.
• Tokens or “planets” labeled with specific scenarios: “S3 regional outage,” “Ransomware in shared drive,” “DNS misconfiguration,” “New feature rollback fails,” “Payment provider rate‑limiting,” “Office power outage,” etc.

Now add a literal hand crank:

• Turning the crank advances your “incident time.”
• Disks rotate at different speeds to simulate likelihoods, cycles, or leading indicators.
• When disks bring two or more scenario tokens into alignment, you have a conjunction event—the start of a tabletop incident.

This physical motion matters:

• People remember what they move with their hands.
• They see that no single failure is isolated; orbits intersect.
• It reinforces the idea that time, dependencies, and chance all shape incidents.

Mapping Failure Models onto a Physical Orrery

You can design your orrery to reflect how your systems and organization actually work. For example:

1. Infrastructure Orbit

• Planets: Data center outage, region loss, network partition, storage degradation.
• Moons: Backup failures, capacity exhaustion, misconfigured autoscaling.

2. Application & Data Orbit

• Planets: Schema migration gone wrong, cache stampede, thundering herd, deadlock.
• Moons: Feature flags misused, incorrect fallback logic.

3. Human & Process Orbit

• Planets: On‑call fatigue, misrouted alerts, slow escalation, conflicting runbooks.
• Moons: New hire on first solo rotation, shadow IT, ad‑hoc patches.

4. External & Environmental Orbit

• Planets: Major cloud provider incident, critical vendor outage, supply chain compromise.
• Moons: Natural disaster, office closure, internet backbone issues.

5. Threat Orbit (Cybersecurity)

• Planets: Phishing campaign, credential stuffing, ransomware, insider threat.
• Moons: Exposed admin panel, unpatched service, misconfigured IAM.

Each orbit might rotate at:

• Different speeds (how often something arises).
• Different phases (seasonal traffic, compliance audits, marketing launches).

When you run a session, you:

1. Turn the crank.
2. See which tokens line up.
3. Use that conjunction as your incident seed scenario.

Tabletop Exercises as Hand‑Cranked Narratives

Traditional tabletop exercises already provide enormous value:

• Cybersecurity incident simulations
• Natural disaster / business continuity walkthroughs
• Cloud provider or ISP outage drills
• Insider threat or data breach role‑plays

You gather people in a room, present a scenario, ask: “What do you do?” and advance the timeline.

The orrery desk turns these into stories you can see and touch.

Step‑by‑Step: Running an Orrery‑Driven Tabletop

1. Set the context

   • Choose which orbits and tokens matter for this session.
   • Briefly review what each orbit and token represents.

2. Spin up the universe

   • Turn the crank a few steps.
   • Identify the first notable conjunction (e.g., “Peak traffic week” + “DNS misconfig” + “New SRE on call”).
   • Declare that as T0: Incident detected.

3. Advance time in discrete steps

   • Each crank = 15 minutes, one hour, or one business day—whatever fits.
   • At each step, read the evolving conditions: new risks align, some resolve.
   • Ask: What do we know now? What do we do now? Who is involved?

4. Trace cascading impacts

   • Use strings, markers, or index cards to draw impact paths on the base map.
   • Show which teams are overloaded, which SLAs are broken, which customers feel it.

5. Capture weak spots

   • Where did you argue about who owns what?
   • When was it unclear what tool or runbook to use?
   • Which manual processes took too long?

6. Debrief with the map still visible

   • Stand around the desk and annotate the paper universe.
   • Turn “aha” moments into concrete action items: new runbooks, training, architectural changes, or policy updates.

Why Analog Tools Beat Yet Another Diagram

You could model all of this in a sophisticated digital tool. Many teams do. But analog, physical tools have distinct advantages:

1. Tangible = Memorable
   People remember moving a token, feeling the resistance of a crank, seeing two tokens collide. It anchors abstract risk concepts in physical experiences.

2. Shared Focus
   A big paper map and orrery draw everyone’s attention to the same place. No one is lost in their own tab. People point, gesture, argue—and thereby build a shared mental model.

3. Low friction, high adaptability
   You can sketch a new service in pencil, tape in a new risk token, or relabel an orbit on the fly. No permissions, no licenses—just paper, pens, and imagination.

4. Psychological safety
   Analog tools feel more like play and less like formal evaluation. That encourages honest conversation about gaps, uncertainty, and “we actually don’t know who owns this.”

5. Cross‑disciplinary access
   Non‑technical stakeholders can step up to the desk and participate. They may not follow a microservice graph, but they understand orbits, collisions, and stories.

Building Your Own Incident Story Orrery

You don’t need a bespoke brass machine (though that would be beautiful). You can start with:

• A large sheet of paper or whiteboard table
• Circular templates or old board‑game dials
• Index cards, sticky notes, string, and markers
• A simple cardboard or wooden crank mechanism, or just a “turn the ring” agreement

Then:

1. List your critical systems, dependencies, and teams.
2. Identify your top failure modes and threats.
3. Assign them to orbits based on type or layer (infra, app, human, external, threat).
4. Create physical tokens for each scenario.
5. Define your time step per crank.
6. Schedule recurring tabletop sessions where you hand‑crank your paper universe.

Over time, your orrery desk becomes a living record of how your organization thinks about risk—and how that thinking has evolved.

Conclusion: Turn the Crank Before Reality Does

The Antikythera mechanism didn’t control the heavens; it anticipated them. It turned the overwhelming complexity of the sky into something people could see, touch, and reason about.

Your systems—and the risks they face—are no less complex.

An Analog Incident Story Compass Orrery Desk gives your team a way to:

• Accept that failures are inevitable.
• Model and visualize how those failures might collide.
• Practice responding through structured tabletop exercises.
• Discover weak points before production, regulators, or attackers do it for you.

By hand‑cranking a paper universe of risk, you give your organization something priceless: not a promise that nothing will go wrong, but a practiced, shared capacity to navigate when it does.