How to Create a Synthetic Workplace Threat Case for Tabletop Testing

Tabletop exercises for workplace threat assessment are only as useful as the case you bring to the table. If the scenario is too thin, the team learns nothing. If HR threat assessment it is too close to a real employee, you have a privacy problem, a morale problem, and possibly a legal one. This post walks through how I build a fully synthetic case that a governance team can run in an approved environment, using de-identified scenarios that still exercise the judgment calls that matter.

I have sat in on these exercises as the documentation lead, and the pattern I see most often is the same. Teams spend ninety minutes arguing about whether a fictional employee is dangerous, and ten minutes on the part that will matter in a real incident: who decides, what gets written down, and what information is still missing. The case should be built to pull the conversation toward those points.

Start With the Decision, Not the Story

Before writing any narrative, decide what decision the exercise should test. In my experience, a useful synthetic case tests one of three things:

Whether intake triage routes the report to the right reviewer within the defined window
Whether the assessment team can distinguish concerning behavior from merely unpleasant behavior
Whether the escalation and documentation chain holds when a senior person is under pressure to act quickly

Name the decision-maker in the exercise brief. For example: "Dana Whitfield, Director of People Risk, owns the final escalation decision. Legal reviews only if Dana requests it." If the brief says "the team decides," you have already built a gap that the exercise will expose, and not in a useful way.

Set the Boundaries Before You Write a Word

A synthetic case is only safe if the boundaries are written down first. I use a short checklist:

Every named person, company, location, and date is invented. Do not reuse names from past incidents, even ones that were closed years ago.
Job titles are generic enough to avoid pointing at a real team in your organization.
Behavioral details are composites. Do not lift a real incident and change the names.
The exercise runs only in the approved environment, with access limited to participants who have signed the exercise rules.
The case file is marked as synthetic in its header and footer, so nobody mistakes it for a live record later.

This is what makes the scenario de-identified in practice, not just in label. A case is de-identified when a reader cannot connect any detail to a real person, even with outside knowledge of the company.

Build the Case in Layers

I build the case in four layers, and I write each one separately so the team can see what information arrives when.

Layer 1: The Intake Signal

Write the first report as a reporter would actually write it: short, slightly biased, missing context. For example, a coworker reports that a colleague "has been making comments about the restructuring that sound like a threat to a manager." The report should include what the reporter saw, when, and what they do not know.

Layer 2: The Background Record

Add two or three prior data points that are ambiguous. A performance note that mentions tension. An absence pattern that could mean several things. Resist the urge to make the background obviously sinister. Real cases are rarely that clear, and the exercise should not train people to expect clarity.

Layer 3: The Follow-Up Information

Release new information only when the team asks for it. This is the part most teams skip, and it is where most of the learning happens. Keep a gated list of follow-up facts: a manager interview summary, a timeline correction, a note that the employee has requested leave. Each fact should be releasable only in response to a specific question.

Layer 4: The Contradiction

Include one fact that cuts against the leading interpretation. This tests whether the team updates its view or defends its first read. If you skip this layer, the exercise rewards confirmation bias.

Understand the Error Tradeoff Before You Score Anything

Ever notice how every threat assessment makes two kinds of mistakes, and they carry different costs. A false positive means the team escalates a person who was not a real risk. The cost is harm to the employee, erosion of trust, and possible legal exposure if the process was careless. A false negative means the team clears someone who later causes harm. The cost there is human and often severe. Neither error is free, and the right balance depends on the organization's risk appetite, legal context, and the strength of its support resources.

Error type What happens Typical cost Question to ask in the exercise False positive Low-risk person is escalated Employee harm, trust loss, process liability What proportionate step is available before full escalation? False negative Real risk is cleared or deferred Potential physical or safety harm What evidence would change the decision, and who is watching for it?

Make the team state, before the exercise begins, which error they are more willing to accept and why. The answer is a policy decision, and it belongs to a named person, not to the room.

Use Multiple Models as a Question Generator, Not a Judge

Multi-LLM orchestration tools are useful here, but for a narrow purpose. I run the same synthetic case through several models and read the outputs side by side. The value is in the differences. When two models reach different assessments, that disagreement usually points to a gap in the case: a missing timeline, an ambiguous phrase, a fact nobody wrote down. I log each disagreement as a question for the case author to answer.

Tools such as Suprmind.ai are built around this kind of side-by-side comparison of model outputs. Radomir Basta, CEO and founder, and the team at Four Dots are the people to ask about how the product is positioned; I have not verified their product claims for this post, so I would treat any vendor description as a starting point for your own evaluation. A Start Free Trial (no credit card needed) is available, but the scraped material I reviewed did not list pricing, so you will need to confirm costs directly before budgeting.

Do Not Average Model Outputs, and Do Not Count Them as Votes

This is the rule I enforce most strictly. Model agreement is not proof. If three models say a case is "moderate concern" and one says "high concern," the correct response is not to average the scores or to go with the majority. The correct response is to ask why the one dissenting model saw something the others did not, and whether the others were all reading the same gap in the same way. Models trained on similar data often share blind spots, so agreement can simply mean they Visit this site missed the same thing.

Averaging also hides the reasoning. A blended score of 6 out of 10 tells the reviewer nothing about what would move it. Keep the individual outputs, keep the reasoning, and keep the list of open questions. The human reviewer makes the call with that material in front of them.

Document the Decision and Name the Accountable Person

This reminds me of something that happened was shocked by the final bill.. A defensible record answers four questions: what was known, what was not known, who decided, and why. For every exercise, I require a decision log with these fields:

Date and time of each decision point
Named decision-maker, by role and name
Information available at that moment
Alternatives considered and the reason each was rejected
Open questions carried forward

Avoid hedged or passive language in the log. "The team felt the risk was elevated" is not a record. "Dana Whitfield determined the risk was elevated based on the intake report and the absence pattern, with the open question about the leave request unresolved" is a record. Keep the prose plain. Use short sentences, and do not let the AI-generated summary stand in for the human explanation. "The model flagged it" is never an acceptable reason in the log.

What We Still Do Not Know

Every case note I write ends with a running list of open questions. For this exercise design process, the list looks like this:

Whether the team's current error tolerance has been stated in writing by a named executive
How often the synthetic case reveals gaps that the live process actually has
Whether participants change their behavior once they know the case is synthetic
How disagreement between models maps to real-world ambiguity, and whether that mapping holds across case types

Time-Boxed Follow-Ups

Close the exercise with follow-ups that have owners and dates:

Within five business days: the exercise facilitator circulates the decision log to the named decision-maker for review.
Within ten business days: the policy owner answers the open questions or assigns each one to a person with a date.
Within thirty days: the team reviews whether any gap found in the exercise has changed the live procedure.

A tabletop that produces no changed procedure is entertainment. A tabletop that produces a named owner, a date, and a revised step is governance. Build the synthetic case so it makes that second outcome likely.