The answer is the Blast-Radius Replay: we take the environment’s real service-dependency graph — the same one the resolver reads — and animate the incident moving across it, turn by turn. Red spreads down the dependencies that fell. Cyan lights up what your decision saved. The run opens with the blast spreading from the origin and, turn by turn, contracts as your moves contain it — from 46% of the criticality-weighted estate on turn one down to 10% by turn three. Same engine that scores you, now drawing you a map of the damage.

The number says you were better off. The replay shows you which services you saved, and which call did it.

The resolver is a graph cascade, and that’s the whole trick

Every environment in IncidentGym is a service-dependency graph — nodes are services, edges are “depends on,” and each node carries a criticality weight. When an incident lands, the resolver propagates the decision through that graph: starting at the compromised node, the cascade walks the dependency edges to everything downstream that is now exposed. Sum the criticality weights over what’s affected, normalize against the whole environment, and you get the criticality-weighted blast radius — the headline number.

Your moves are graph operations on that cascade. Contain cuts downstream dependencies: a contained service stops propagating, so the subtree hanging off it drops out of the exposed set on the next turn. That pruning is exactly what the animation renders as a node going from red back toward cyan. The resolver doesn’t have a separate “score formula” bolted onto a separate “visualization” — the blast radius is a property of how far the cascade reaches, and the replay is that same cascade drawn over time. One source of truth, two faces.

From that cascade, the engine reports three scoring axes — technical, speed, and riskMitigation. How fast you contain the right node and how much criticality-weighted capacity stays up across the incident come straight off the turn-by-turn cascade. Contain the right node early and recovery moves in your favor; chase a low-criticality service while a payments dependency burns and it doesn’t. The axes aren’t vibes about your judgment — they’re arithmetic over the graph you actually changed.

Why “pure” is the load-bearing word

The resolver is pure in the engineering sense: no hidden randomness, stable ordering, same inputs always produce the same outputs. I keep saying it because almost every nice property in this post falls out of that one constraint.

The most obvious payoff is auditability — a CISO can put the score in front of a board and an auditor can re-derive it. But purity buys something I didn’t fully appreciate until we shipped the debrief: you can re-run the engine over hypotheticals for free. If the function has no side effects and no hidden randomness, then evaluating “what if I had contained the database instead of failing over the gateway” is just another call with different arguments. No new game, no new LLM turn, no write to Aurora. Those counterfactual re-runs happen in-memory inside the serverless function — zero writes back to Aurora, zero LLM API calls. The engine is a function, so the debrief gets to ask it questions.

The debrief asks the questions you didn’t

That’s where the counterfactuals come from. When you finish a turn, the debrief re-runs the resolver over the moves you did not make and surfaces the best alternative for that turn — the single decision that would have contained the most criticality-weighted blast. Not an LLM speculating about what a better responder might have done; the actual deterministic engine, scoring the road not taken with the same arithmetic that scored you.

Paired with that is the “why each number moved” causal chain: for every metric that changed turn-over-turn, the debrief traces it back to the graph operation that caused it. Blast dropped because the contain cut a high-criticality subtree out of the cascade. Recovery improved because the failover kept a dependency online. It reads like a diff for your incident.

Here’s the contained run as a readout — the three turns the replay animates:

And the part that matters for trust: every one of those numbers, every counterfactual, every causal-chain entry is computed on read. The debrief is not loading stored verdicts the LLM wrote earlier. It re-derives them from the persisted decisions and the topology pinned to that session — each session pins its topology at start, so reopening it reproduces the debrief identically even if the live environment graph has since changed. No model is in the loop, nothing is written back. The ledger in Aurora persists the committed per-turn facts — the action you took, the metrics, the causal effects per turn, scoped to your org by the composite-FK invariant from Log 003 (Turn(sessionId, orgId), cross-tenant write rejected as Postgres 23503). The counterfactuals and the replay frames are not stored; they’re re-derived on read as a pure projection of those persisted facts.

Determinism makes the whole debrief reproducible

The last piece is determinism end to end. Because the resolver has no hidden randomness and produces the same outputs from the same inputs, the entire debrief — your run, the best-alternative counterfactual, the causal chain, the frame-by-frame blast values the replay animates — reconstructs with zero model calls. Because each session pins its topology at start, reopening the same session tomorrow runs the resolver over the identical inputs and the replay draws the identical cascade. Hand the same pinned inputs to a teammate and they reconstruct your exact debrief on their own machine. Reproducing a finished incident review costs a graph walk, not an API bill.

And it doesn’t have to be a person in the seat. Point an autonomous responder at the same incident and the engine scores its run, replays its blast radius across the same graph, and shows the better move it left on the table — the same reproducible evidence, whether the responder is a human or a bot. The more of the response that gets automated, the more that’s the line between trusting an agent and measuring one.

That’s the line we’ve been holding since the start of this build, restated for the debrief: the LLM writes the story — the situation, the CEO and security-lead and payments-lead personas in the room, the pressure. The engine owns the numbers, and now it owns the picture of the numbers too. The replay is the deterministic engine’s output made visceral, and because the engine is pure, the most persuasive thing in the debrief — here’s the better move you didn’t make, and here’s exactly why your score moved — costs nothing and reproduces forever.

A computed score is the honest foundation. Rendering it on the real dependency graph is what finally makes someone feel the distance between the blast that spread and the blast you contained.

Live demo: https://incidentgym.redoubtlabs.dev

This log is about how we made cross-tenant isolation a structural property of the schema instead of a discipline we have to maintain in application code — and how that lets us put a button in the product that proves it, live, in front of an auditor.

The failure mode we refused to ship

The default way to do multi-tenancy is: stamp every row with an orgId, and add where: { orgId } to every query. It works right up until the moment one query doesn’t. The enforcement lives entirely in code you have to remember to write, on every read and every write, forever, including in code that doesn’t exist yet. The guarantee is therefore exactly as strong as your least careful future diff. “We’re isolated” really means “we’re isolated as long as nobody forgets,” which is not a sentence you want to say to a security buyer.

There’s a second, sneakier version of the same hole. Even if every top-level query is scoped, child rows can still drift. A Turn belongs to a GameSession. If you write a Turn with sessionId pointing at session S but stamp it with the wrong orgId — through a bug, a confused caller, a malicious request that lies about its tenant — a naive schema is perfectly happy to store it. Now you have a row that claims to belong to org A while hanging off a parent owned by org B. The application-code check that “should” have caught it is, again, just code someone wrote and someone else might not.

I didn’t want to be one forgotten clause away from that. So we moved the invariant down a layer.

Make the relationship carry the tenant

The core idea is small and, once you see it, almost obvious: don’t let a child row reference a parent by id alone — make it reference the parent by (id, orgId) together.

Concretely, in our Prisma schema:

• Every tenant-owned table carries an orgId column. Nothing is tenant-ambiguous.
• Every parent table declares a composite unique key on @@unique([id, orgId]). The id is already unique on its own; this extra key exists purely so the pair (id, orgId) is a thing a foreign key can point at.
• Every child table binds (sessionId, orgId) as a composite foreign key into that parent’s (id, orgId).

Concretely:

model GameSession {
  id    String @id @default(cuid())
  orgId String
  turns Turn[]

  @@unique([id, orgId]) // the composite key a child FK can point at
}

model Turn {
  id        String      @id @default(cuid())
  sessionId String
  orgId     String
  // composite FK: a Turn can only attach to a session in the SAME org
  session   GameSession @relation(fields: [sessionId, orgId], references: [id, orgId])

  @@unique([id, orgId])
}

That last line is the whole game. The relationship from Turn to GameSession is no longer “this sessionId exists” — it’s “a session with this id and this orgId exists.” Which means child.orgId == parent.orgId is no longer something application code asserts and hopes for. It’s something Postgres checks on every insert and update, because it’s the referential-integrity rule the constraint encodes.

A cross-tenant write isn’t a missed code review anymore. It’s a foreign-key violation — Postgres error 23503 — raised by the database before the row ever lands.

Try to write a Turn for session S (owned by org B) while stamping it with org A’s id, and there is no row GameSession(id = S, orgId = A) for the composite FK to satisfy. The insert is rejected. Not flagged in a linter, not caught in review, not maybe-caught in a test — rejected, at the storage layer, deterministically, every time, including in code paths none of us have written yet. The guarantee stopped depending on anyone’s memory.

Belt, suspenders, and one place to decide tenancy

The composite FK is the floor — the thing that holds even when everything above it is wrong. But we still build the layers above it correctly, because defense in depth means each layer assumes the others might fail.

The first layer is query scoping. We don’t sprinkle where: { orgId } by hand and pray. Every application query path goes through db.scoped(orgId), which injects the orgId filter onto every query it issues. There’s one place where scoping is decided, not hundreds of call sites where it can be forgotten. A reader can’t accidentally see another tenant’s rows because the scoped client won’t emit an unscoped query in the first place.

The second layer is the one I care about most on the write path: the finalize step is exactly-once and idempotent. When a turn is scored and committed, scoring and persistence happen as one resumable operation, so a refresh or a second tab can’t double-advance or double-charge a turn. And if a write ever tried to land a child row whose tenant disagreed with its parent’s, the composite FK underneath is waiting to reject the mismatch anyway. The structural guarantee doesn’t lean on the finalize logic being perfect — it’s there precisely for the case where it isn’t.

Here’s the same idea stated as before/after, because the shift is the whole point:

The bottom-right cell is what turns this from an architecture decision into a demo.

Provable, live, in the audit console

A guarantee you can only describe is a claim. A guarantee you can trigger on stage is evidence. So the CISO-facing audit console has a one-click isolation proof, and it does exactly what a skeptic would do if you handed them a psql prompt: it attempts a cross-tenant write — a child row stamped with the wrong tenant — and shows you what the database says back.

The database rejects it with foreign-key error 23503 on the Turn_orgId_fkey constraint, surfaced right there in the console. It’s a live demonstration that the isolation boundary is real and is enforced where we say it is: in Aurora, not in a slide. You don’t have to take “we scope everything” on faith — you can watch Postgres refuse the write.

And because the boundary lives in the schema, it doesn’t weaken in the public demo. The live deployment runs in single-org mode — a shared demo org, no sign-in — so judges can click straight in without signing up, but the same composite-FK scoping is in force. The same composite-FK constraints are active either way. The demo isn’t a watered-down version that “would” be isolated in production. It’s the same wall, with one door open for visitors, and the proof works either way.

Why this was worth the schema care

Composite foreign keys cost something. You have to add the redundant @@unique([id, orgId]) to every parent, thread orgId through every child relation, and resist the urge to take the easy single-column FK. It’s more schema to hold in your head than where: { orgId }.

But it buys the one property an application-code check can never have: it’s true even when the code above it is wrong. The whole pitch of a security product is that you’ve thought about the failure where you are the adversary’s path in — the forgotten clause, the confused write, the next engineer who doesn’t know the rule. Pushing tenant isolation into a referential-integrity constraint means that path is closed by the database, not by vigilance. And a constraint doesn’t get tired, doesn’t miss a clause at 1 a.m., and doesn’t care whether the request testing it is a confused service or an adversary probing at machine speed — it either satisfies the rule or it’s rejected. That matters more, not less, as attacks get faster and more automated. The strongest thing I can say about IncidentGym’s tenancy isn’t “we’re careful.” It’s: a cross-tenant write is a Postgres error, and there’s a button that’ll show you.

Live demo: https://incidentgym.redoubtlabs.dev

So we drew a line straight through the middle of the product, and everything else is downstream of it: the LLM writes the story; a pure function writes the score.

What the LLM is allowed to do

Plenty, actually — just not the thing that decides whether you pass. The language model owns the narrative: it sets the scene, escalates the situation as the clock runs, and plays the cast of AI advisor personas in the room with you — the CEO who wants a customer statement, the security lead pushing for containment, the payments lead worried about the cutover, the comms officer drafting the holding line. That’s real work, and it’s work LLMs are genuinely good at: producing fluent, in-character, situation-aware text under pressure. When you isolate a service or escalate or fail over, the advisors react, the world moves, and it feels alive.

What the model never touches is the number. It doesn’t see a rubric it can be argued into. It doesn’t get to decide that a confident-sounding answer “deserves” a higher technical score. The story it writes is flavor and pressure and texture — and flavor, by design, has no vote.

What a pure function does instead

The score is computed by a pure, deterministic graph-cascade resolver, and the word that matters there is pure. No LLM call. No clock. No randomness. It takes two inputs: your decision, and your organization’s environment — a service-dependency graph with criticality weights, read from the database as a fixed input to the computation. It propagates the decision through that graph and computes concrete outcomes: blast radius — criticality-weighted blast radius = (sum of criticality weights of impacted services) ÷ (sum over all services) — which services were impacted, what recovered, and a causal trace of exactly what your choice changed. From those it derives the score’s deterministic axes: technical, speed, and riskMitigation.

Because the resolver is pure over those inputs, it has a property an LLM grader can never have: the same inputs produce the same score. Run the same decision against the same topology a thousand times and you get the same number a thousand times. There’s no temperature, no seed drift, no “the model was in a mood.” The number isn’t an opinion that happened to land near the truth; it’s a computation, and you can re-run the computation.

A score you can re-derive isn’t a grade. It’s a receipt.

That distinction — grade versus receipt — is the whole reason the line exists. A grade is what someone gives you. A receipt is something you can hand to an auditor and they can check it themselves.

The one axis we couldn’t make pure — and what we did about it

Honesty time, because a build log that only lists wins is just marketing with line numbers. One axis genuinely needs language understanding: communication. Whether you told the right stakeholders the right thing at the right moment is a judgment about text, and you can’t compute it from a dependency graph. So communication is the one axis where an LLM assists the evaluation.

We didn’t hide that. We did the opposite — we fenced it and labeled it. Communication is the only LLM-assisted axis in the score, and the split is explicit by design: technical, speed, and riskMitigation come out of the pure resolver; communication is the one with a model in the loop. The fence is the point. Instead of one undifferentiated “AI score” where you can’t tell signal from vibes, you get three axes you can re-derive and one axis that is openly marked as model-assisted. The buyer decides how much to trust the labeled one. We don’t launder it through the deterministic ones.

That’s why this carries a warn flag and the other two carry ok. It’s a real caveat, stated plainly, in the place a skeptic would look.

The split, in one table

Here’s the line, stated as a table so it’s hard to misread:

One dependency worth naming for the skeptic: the deterministic path needs the topology to be there. The turn it’s scoring — Turn(sessionId, orgId) — has to resolve to an organization whose environment graph exists, because that graph is the input the resolver runs on. No topology, no deterministic computation. The three deterministic axes are only ever computed against a real environment graph, never conjured.

Why “auditable + reproducible” is the pitch, not a footnote

It would be easy to file all of this under engineering hygiene — nice internals, move on. But for the buyer we care about, it is the product. Picture a CISO putting a readiness number in front of a board, or an auditor asked to sign off on it. The first question either of them asks is the same: where did this number come from, and can you show me?

If the answer is “a language model read the team’s answers and felt they were about an 81,” the conversation is over. That number can’t be defended, can’t be reproduced, can’t be distinguished from a number the model would have given to confident nonsense. But if the answer is “three of the four axes are computed by a pure resolver from your own environment, here are the inputs, run it yourself and you’ll get the same number — and the fourth axis is explicitly marked as model-assisted” — now you have something a regulated buyer can actually stand behind. The deterministic line isn’t there to make the demo look rigorous. It’s there because auditable and reproducible is what a security score has to be, and an LLM-judges-the-prose grader is structurally incapable of being either.

The whole architecture follows from that one refusal at the start. The LLM makes the incident feel real. The pure function makes the score real. We kept them on opposite sides of a line we can point to — and the one place they had to touch, we fenced, labeled, and put a warn on so nobody has to take our word for it.

And the same property reaches past the people in the seat. The day an autonomous IR agent runs the response instead of a human, you hit the same question — is it any good? — and the same trap: you can’t grade one model’s output with another model and call it evidence. A deterministic ruler is the only honest answer, which is why this split isn’t internal hygiene; it’s what lets you benchmark an agent on a number it can be held to, exactly the way you’d benchmark a person. (We run that same bet in a different domain — disaster response — over at Aftershock.)

That’s the line. The story is written by a model. The score is written by a function. And only one of those gets a vote on whether you passed.

Live demo: https://incidentgym.redoubtlabs.dev

Why this matters now: the attack side is speeding up

The case for measuring readiness instead of feeling it gets sharper every quarter, because the other side is accelerating. The UK’s National Cyber Security Centre assessed that AI will almost certainly increase the volume and heighten the impact of cyber attacks — lowering the barrier for less-skilled actors and sharpening reconnaissance and social engineering. And it isn’t only a forecast: in late 2025 Anthropic reported disrupting the first documented AI-orchestrated espionage campaign, in which an agentic system ran reconnaissance, vulnerability discovery, exploitation, and data exfiltration across roughly thirty organizations — with the AI doing an estimated 80–90% of the hands-on work.

Whatever you make of the exact figures, the direction is hard to argue with: incidents are getting faster and more frequent, and the gap between “something’s off” and “it’s everywhere” is compressing. That’s the world an annual tabletop can’t keep up with — and, with no small irony, a strange moment to let plausible-sounding AI prose be the thing that tells a security team it’s ready. The faster the attack, the more a readiness number has to be real.

The first break: training that’s episodic

Most IR rehearsal is a tabletop. A consultant flies in once a year, walks your team through a scenario over an afternoon, and leaves you a slide deck and a warm feeling. It’s not worthless — it surfaces gaps, it gets people in a room. But it tells you almost nothing about whether your team is ready today. Readiness isn’t a thing you have on the day of the workshop and keep for twelve months; it drifts as people leave, as the environment changes, as the runbook quietly goes stale. An annual snapshot of a moving target is not a measurement. It’s a memory.

What a CISO actually needs is continuous and comparable: a way to drill regularly and watch a number move, so “are we more ready than last quarter?” has an answer instead of an anecdote.

The second break: graded on vibes

The newer wave of tools fixes the cadence problem by putting an AI in the loop — drill any time, get instant feedback. Good instinct. But look closely at how a lot of them score you: you write your response in prose, and a language model judges how plausible that prose sounds. The grade is a measure of how convincing your writing is.

For most domains that’s a fine approximation. For a security product it’s a credibility hole, because the whole job of an attacker is to make the wrong thing look right.

Plausible prose is not a contained breach.

A confident, well-structured paragraph about isolating the affected service can score beautifully and still describe a move that, in your actual environment, would have taken down the payment path it depended on. The model grading you doesn’t know your dependency graph. It’s rewarding fluency. And a readiness score built on fluency is exactly the score an auditor — or an attacker — should not trust.

What we’re actually building

IncidentGym is incident-response training that’s continuous, measurable, and above all defensible. The design goal, stated as plainly as I can: produce a readiness score a CISO can put in front of the board, and an auditor can’t wave away.

The thing that makes that possible isn’t a better prompt or a sterner AI judge. It’s a different architecture for where the number comes from. The outcome of a decision in IncidentGym is computed — propagated through a model of your environment’s service dependencies — not graded. When you isolate a service, fail over, or escalate, a deterministic engine works out what would happen in a model of your environment: what cascades, what’s contained, which criticality-weighted services you saved and which you lost. Same decision, same environment, same score, every time. That reproducibility is the entire point. A number you can re-derive is a number you can audit; a number that depends on a model’s mood that afternoon is not.

So the honest “why us” is not “we added another chatbot to incident response.” There’s a language model in IncidentGym, and it does real work — it narrates the unfolding incident, it voices the advisor personas you argue with under pressure, the CEO and the security lead and the comms officer in the room. But it does not own the score’s deterministic core — the axes a board and an auditor can re-derive. (One axis, communication, is model-assisted; we fence it and label it openly, and a later dispatch shows exactly how.) The story is generated; the defensible score is computed. Keeping that line clean — narrative on one side, deterministic resolver on the other — is the part I’m proudest of, and it’s what makes the readiness number mean something.

What the next dispatches go deep on

This is the opener, so I’m framing the bet, not unpacking the machinery. Three threads run through everything that follows, and each one gets its own dispatch:

• The LLM narrates, but it never judges. The split between the model that tells the story and the pure engine that scores the decision is the spine of the product. A future log walks through exactly where that boundary sits and why “same inputs, same score” is non-negotiable for a security tool.
• Tenant isolation enforced by the database, not by hope. IncidentGym is multi-tenant, and we didn’t want isolation to be a where clause someone could forget. It’s a composite foreign-key invariant in the schema, so a cross-tenant write is rejected by PostgreSQL itself — a database error, not a passed application check. A dispatch covers how that turns “trust us” into something you can demonstrate live.
• The blast-radius replay over the real dependency graph. The debrief doesn’t just hand you a number. It animates the incident spreading and being contained across your environment’s service-dependency graph, turn by turn — red along the dependencies that fell, cyan for what you saved — next to the counterfactual showing what a different call would have done. It’s the deterministic engine’s output, made visceral. That one earns a full post.

Where this is today

A field log that blurs shipped and not-shipped isn’t worth much, so: today you drill solo against a set of built-in, fictional environments — the dependency graphs are ours, not yet yours. Two things are in testing and not live: bring-your-own-topology, so you can drill on a model of your real estate instead of a stand-in, and team-vs-incident multiplayer, so a whole response team can run the same authoritative engine together. When they ship, this log keeps the receipts.

The forward bet

Here’s the part I’m most willing to be held to. Because the scoring is deterministic and grounded in a topology rather than in a model’s opinion, the same engine doesn’t only have to grade people. Point it at an autonomous IR agent and it answers a question the industry is about to need badly: how good is our agent, on our environment, against this incident? As response gets more agentic, “is the bot any good?” needs a reproducible answer, and a ruler that’s already environment-grounded and auditable is the natural place to get one.

And this isn’t hypothetical for us. It’s the same conviction behind a sibling project — Aftershock — where a society of AI agents responds to a simulated disaster and is scored on a deterministic, reproducible ruler instead of graded on how good its plan sounds. Different domain (a disaster in a simulated town, not a breach in your estate), same refusal: if an agent is going to run the response, you measure it with a number you can re-derive.

That’s the wager this whole field log is here to test in public. The dispatches that follow keep the receipts — what shipped, what we got wrong, what we walked back. If there’s one line that justifies building another incident-response tool, it’s this: don’t grade the prose, compute the outcome.

Live demo: https://incidentgym.redoubtlabs.dev