No result found
This report needs a scored result to generate.
This is a static sample and does not depend on a scored result.
Back to the course page
PRAXORALAB Illustrative example · fictional company, for format reference only
AI-Assisted Monitoring & Decision Framework
Tidewater Digital Bank
Tidewater Digital Bank's example scenario: a misconfigured cloud storage bucket exposed a batch of customer KYC documents, and a misread security researcher's post triggered a fast-spreading, false ‘customer funds stolen’ rumour. The framework below sorts every incoming signal into one of three tiers by how confirmed it is and how fast it is spreading, not by how alarming it sounds on its own.
Signal TiersTier 1 — Confirmed fact
A misconfigured cloud storage bucket exposed roughly 6,400 customer KYC documents (identity scans, proof-of-address) between 02:10 and 04:45 SGT, before the bucket was sealed.
No transaction system, account balance, or payment-authorisation system was touched or reachable through the exposed bucket.
Tier 2 — Unverified, spreading fast
A claim that “customer funds were stolen” began circulating on X and in three Telegram groups at 08:50 SGT, misreading the original security researcher's post.
By 09:40 SGT the claim had been reshared over 1,200 times and picked up by two personal-finance TikTok accounts with a combined 400,000 followers.
Tier 3 — Noise, monitored only
General commentary questioning digital banks as a category, not naming Tidewater specifically.
A handful of accounts recycling older, unrelated banking-outage complaints under the same trending hashtag.
Priority: Tier 2 · the "funds stolen" claim
The false "funds stolen" claim is the one signal this framework flags for immediate correction, not the confirmed exposure itself: it is spreading faster than the confirmed-fact tier, it is checkable and false rather than merely alarming, and every uncorrected hour raises the chance a customer acts on a reason that isn't true.
The number worth sitting with on this page is not the 6,400 exposed documents, it is the fifty minutes between 08:50 and 09:40 — the time it took a misread post to become 1,200 reshares and two TikTok accounts with a combined 400,000 followers. I have watched that acceleration curve from inside a command centre more times than I can comfortably count, and it always looks the same: the true, boring fact moves at the speed of a verification process, and the false, exciting claim moves at the speed of a share button. Tidewater's three-tier structure is the right shape for that asymmetry, because it stops treating "verified" as the only category worth acting on. A framework that only escalates confirmed fact would have left this claim in an unmonitored blind spot for the entire fifty minutes it mattered most.
What I'd push back on, in a real session, is the boundary between Tier 2 and Tier 3. The framework here sorts the "digital banks as a category" commentary into Tier 3, noise, on the reasonable basis that it doesn't name Tidewater. That's correct as a snapshot. It is not correct as a rule, because category-level noise about an entire class of institution is exactly the kind of claim that can flip into a named, Tier 2 signal the moment one influential account makes the connection explicit — and by the time a human monitoring lead notices that flip has happened, the acceleration curve has already done its damage. This is precisely the problem my own doctoral research is aimed at: not building a tool that reads sentiment, but building a decision framework where the promotion rule from Tier 3 to Tier 2 is triggered by velocity and connection density, not by a person's judgement call on content alone, because a person's judgement call is always a few minutes behind the curve it's trying to catch.
The priority action on this page — correcting the false claim ahead of confirming every remaining technical detail — is the right call, and it's the one most first-time crisis teams get backwards. A false, checkable claim moving at this speed is more urgent than a true, damaging fact moving slowly, because the false claim is actively compounding while the true fact just sits there waiting to be disclosed properly. Tidewater's monitoring framework gets that priority order right on paper. The real test, which page two picks up, is whether the people named to act on it can move as fast as the claim does.
Tidewater Digital Bank is invented for this sample only, to show the shape of the output, not a real client's actual incident. No organisation named Tidewater Digital Bank is a Praxora Lab client. Every timestamp, figure and quote on this page is fictional.
PRAXORALAB Command-Centre Response Plan
Built for one live scenario brought into the room. Every decision below is assigned to exactly one named role, not left as a general policy statement: who checks what, who is allowed to speak publicly, and who has the authority to say wait.
| Role | Named owner (fictional) | Checks | Speaks publicly | Says "wait" |
|---|---|---|---|---|
| Monitoring Lead | Digital Trust & Safety Manager | The real-time signal feed — sorts incoming claims into Tier 1 fact, Tier 2 spreading claim, or Tier 3 noise. | No | No |
| Verification Lead | Chief Information Security Officer | Confirms the technical scope of the incident against system and access logs before any claim about it is called fact. | No | Yes — on technical claims only |
| Regulatory Liaison | General Counsel | Coordinates the MAS disclosure timeline and reviews legal exposure on every draft statement. | No | Yes — on regulatory statements only |
| Spokesperson | Chief Communications Officer | Nothing independently — delivers only what Verification and Regulatory have already cleared. | Yes — the one authorised public voice, on any channel | No |
| Incident Commander | Chief Executive Officer, with a named deputy | The full picture across all four other roles before a statement is released. | No | Yes — absolute, overrides all four other roles |
What I want to draw attention to on this page is not the five roles themselves — any competent crisis plan names a monitor, a verifier, a lawyer, a spokesperson and a decision-maker — it's that the "authority to say wait" is split rather than concentrated in one person below the Incident Commander. The Verification Lead can say wait only on technical claims; the Regulatory Liaison can say wait only on regulatory statements. That's a deliberate, and correct, design choice, and it comes directly out of a mistake I've seen made in the field, not out of theory. During one of the engagements I managed for a Malaysian public-health body, a communications lead who had no technical background overruled a technical hold because the political pressure to say something felt more urgent than the unverified detail did. The statement went out, the detail was wrong, and the correction did more damage than the original silence would have. Splitting the "wait" authority by domain, the way Tidewater's plan does, means the person qualified to judge a technical claim is the only one who can hold it — not the person best positioned to feel the pressure to speak.
The Incident Commander's absolute override is the one line on this page I'd flag as a genuine, unresolved tension rather than a settled design choice. Concentrating final authority in a single named person, even with the domain-specific holds beneath it, is correct for speed and accountability — a command centre where everyone can veto everyone else produces paralysis, not caution. But it is also, as page three's stress test correctly identifies, a single point of failure the moment that one person is unreachable. I'd rather see that tension named on the page, as Tidewater's plan does by sending the deputy clause to the next page, than see it papered over with an "in their absence, the team decides" line that sounds reassuring and means nothing when tested.
The Spokesperson role deserves one more comment: note that they check nothing independently. That's not a gap, it's the point. The single most common failure mode I've seen in a live command centre is the spokesperson trying to also be the verifier under time pressure, because they're the one facing the cameras and feel the pull to have an independent answer. Keeping those two jobs structurally separate, even when it's uncomfortable in the room, is what keeps a fast statement from also being a wrong one.
Tidewater Digital Bank and the named roles above are invented for this sample only, to show the shape of the output, not a real client's actual command-centre structure. In the session, this response plan is built from the scenario a participant brings, not assigned from a template.
PRAXORALAB Stress-Tested Response Plan
The command-centre plan on the previous page, pressure-tested against a deliberately sceptical, high-intensity read, one scenario at a time, for Tidewater Digital Bank's example above. What broke on the first draft, and what changed as a result.
The original plan required full CISO sign-off before any comment. Rehearsed against a scenario where the regulator's own preliminary bulletin reached a journalist first, that requirement produced roughly 40 minutes of silence while the false “funds stolen” claim kept spreading. Fixed by adding a pre-approved holding statement the Spokesperson can issue on the Monitoring Lead's confirmation alone, before technical sign-off completes.
The original plan positioned the Spokesperson to wait for full legal sign-off before any public comment. Under this rehearsal, with the claim's reshare count roughly doubling every 20 minutes, that meant hours of silence against a rumour that was demonstrably false and checkable in minutes. Revised to let a narrowly scoped correction — “no account or payment system was accessed” — go out ahead of the fuller statement.
No named deputy existed for the CEO's override authority in the original plan — a single point of failure. Rehearsed against a scenario where the CEO was mid-flight during the first two hours, the plan had no answer for who could exercise the absolute ‘wait’ authority in that window. Fixed by naming the Chief Operating Officer as standing deputy, with the same override, not a lesser one.
The original plan scripted escalation in detail but had no scripted path for retraction. Rehearsed against a scenario where an internal monitoring alert over-read a benign configuration change as a second exposure, the plan had no pre-agreed language for walking back an already-issued internal warning, so two teams kept escalating a non-event for 25 minutes. Fixed by adding a retraction step, owned by the same Verification Lead who issues the original alert.
Read together, these four stress tests tell you more about how this plan was built than any single one of them does on its own, and it's worth naming the pattern before commenting on the individual fixes. Every one of these four failures is a version of the same root cause: the original draft scripted the confident, forward-moving path — escalate, verify, wait for sign-off — and had no scripted answer for the path breaking down. That is the single most common gap I find when I stress-test a crisis plan for the first time, in this course or anywhere else, and Tidewater's plan is a realistic, not an idealised, example of it.
The first and second scenarios are really one problem wearing two faces: an assumption that full verification, or full legal sign-off, would always be available before the Spokesperson had to say anything. Under real velocity — a claim's reshare rate roughly doubling every 20 minutes, per the monitoring page — that assumption doesn't fail occasionally, it fails by default, because the sign-off process was never designed to move at the speed the claim does. You don't get to choose between fast and accurate once a false claim is already spreading; you get to choose which one fails first, and the pre-approved holding-statement fix Tidewater added is what lets "fast" fail a little less than it otherwise would, without sacrificing "accurate" on the one line that matters most, that no account or payment system was touched.
The third scenario, the missing deputy for the Incident Commander, is the most mechanically simple fix on this page and I'd argue the most dangerous gap before it was found, precisely because it's invisible until the exact wrong moment. A plan can look complete on paper with a single named decision-maker; it is only ever tested against absence, illness, or a flight, and most plans never get tested that specifically until the real thing exposes it.
The fourth scenario, the missing retraction protocol, is the one I'd bet most first-time attendees wouldn't have thought to stress-test at all, because it runs against the instinct that a crisis plan's job is to escalate. A plan that can only escalate and never walk something back will, eventually, escalate a false alarm as confidently as it escalates a real one, and that is exactly as damaging to credibility as underreacting to a genuine signal.
The four scenarios above and every timestamp within them are invented for this sample only, to show the shape of the output, not a real client's actual incident. In the session, the plan is stress-tested against the scenario a participant brings, not against a fixed set of scripted questions.
PRAXORALAB Post-Crisis Review Checklist
Run once the immediate response is over, so the plan improves after every real use, not only after the drill it was first built in. Answered here for Tidewater Digital Bank's example scenario above.
Did the confirmed-fact statement go out before the false claim's peak velocity?
Not quite. The “funds stolen” rumour's reshare rate peaked at 11:42, four minutes before the holding statement posted at 11:46. Close enough to blunt the peak, not early enough to prevent it — flagged as the one number to tighten before the next drill.
Was every public claim traceable to a named verification owner?
Yes. Both the 11:46 holding statement and the 14:20 full statement carried findings the CISO had personally confirmed against system logs; no public claim went out sourced only to “the bank” or “our team.”
Did the ‘say wait’ authority actually get exercised, and was it logged?
Yes, twice. Once to hold a draft statement pending Legal's review of a specific regulatory phrase, and once to delay a planned 13:00 follow-up post until MAS's own bulletin had cleared, so Tidewater's statement did not appear to pre-empt the regulator.
Where did the stress-tested plan hold, and where did it not?
The deputy Incident Commander clause, added after stress-testing exposed the single-point-of-failure gap, was actually invoked at 13:15 when the CEO was mid-flight — without it, the plan would have failed exactly as the rehearsal predicted it would.
What is the one change going into the next drill?
Pre-approve the narrow holding-statement template itself, not just the authority to issue one, so the first public word is available before Legal's full sign-off rather than four minutes after the rumour's own peak.
The most important number on this page is the four minutes: the holding statement posted at 11:46, four minutes after the false claim's reshare rate had already peaked at 11:42. I want to be precise about what that four minutes means, because it would be easy to read this checklist as a plan that "worked" and move on, and that's not quite what happened. Tidewater's team caught the claim close to its peak, not before it. That's a materially better outcome than the fifty-minute silence the original, unstressed plan would have produced, and a materially different outcome from the one a genuinely early catch would have delivered. Both things are true at once, and a checklist that only recorded the first without naming the second wouldn't be doing its job.
What I'd rather see, and what this checklist gets right, is naming that gap honestly rather than rounding it up to a clean win. A governance or crisis-comms checklist's real job is to survive a sceptical read from a board member or a regulator asking "did this actually work, or did you get lucky," not to survive a friendly read from a team that wants to feel good about a difficult day. "Close enough to blunt the peak, not early enough to prevent it" is the kind of sentence that survives that sceptical read. A checklist that claimed the statement was perfectly timed would not.
The deputy Incident Commander clause being invoked for real, at 13:15, during exactly the kind of absence the stress test rehearsed three items earlier, is the single most validating line in this whole four-page document, and it's worth being explicit about why. A stress test that finds a gap and proposes a fix is a hypothesis. A fix that gets used, under real pressure, in the specific scenario it was built for, is evidence the hypothesis was right. Most crisis plans never get that confirmation until the fix either works or doesn't, live, and Tidewater's fictional case gets to show both halves of that story on the same page.
The one change going into the next drill — pre-approving the holding-statement template itself, not just the authority to issue one — is exactly the right next increment, not a bigger overhaul. That's the discipline this course is built to hand a real command centre: not a perfect plan on the first pass, but a plan that gets measurably faster, one honestly named gap at a time, before the day it actually matters.
Every claim, quote, timestamp and figure on these four pages is invented for Tidewater Digital Bank, a fictional company, so the format of what a participant leaves with can be judged before enquiring. It is not a real client's deliverable, and no organisation named Tidewater Digital Bank is a Praxora Lab client. The session itself builds a command-centre plan for your own scenario, in the room, on the day.
Four hours, one session, facilitated by Kumaran Pillai.