How to Write the "Unresolved Questions" Section in a Threat Case Record

The unresolved questions section is the part of a threat case record that most teams write last, skim fastest, and defend worst when someone later asks why a decision was made. It is also the section that tells the next reviewer what the file does not yet prove. If it is vague, the case looks more settled than it is. If it is missing, the record quietly claims that nothing else needed checking.

This post walks through how to build that section so it holds up under audit, supports the people making high-stakes calls, and stays honest about what is still open. It also covers how multi-LLM tooling fits in, and where it does not.

Why this section matters more than it looks

In a threat assessment, every decision is made on incomplete information. A case might involve a workplace statement, a message thread, a prior incident report, and a witness interview that was only partly completed. The assessor still has to decide whether to escalate, monitor, close, or refer. The record needs to show what was known, what was not, and why the decision was reasonable given both.

The unresolved questions section is where that honesty lives. Without it, a reviewer six months later sees a clean conclusion and assumes the evidence was complete. That assumption is the most common source of indefensible files.

The core tradeoff: false positives versus false negatives

Every threat case carries two kinds of error risk, and the unresolved questions section should name both.

False positive: the case is escalated or acted on, but the person posed no real risk. The cost is harm to the individual, loss of trust, wasted resources, and sometimes legal exposure.
False negative: the case is closed or downgraded, but the person did pose a risk. The cost can be physical harm to others, and the record becomes evidence of a missed signal.

These errors trade against each other. Lowering one usually raises the other. The unresolved questions section is where you state which error you are currently more exposed to, and why. For example, if the only open item is an unverified statement from a single source, the false positive risk from escalating on it may be higher than the false negative risk from monitoring while you verify. Write that reasoning down. Do not leave the reader to reconstruct it.

Name the decision-maker in this part of the record. In our file template, the line reads: "Risk tradeoff reviewed by Dana Whitfield, Director of Case Operations, on the date below." A named owner changes how seriously the tradeoff gets treated.

What belongs in the section

Keep the section structured. A running list works better than prose paragraphs because reviewers can scan it and check off items. Each entry should contain four things:

The question: stated as a specific, answerable question, not a topic.
Why it matters: what decision it would change if answered.
Current status: what has been tried, and what evidence is missing.
Owner and time box: who is responsible for closing it and by when.

EU AI Act

Compare a weak entry with a strong one.

Element Weak entry Strong entry Question "More info needed on subject." "Does the March 14 message thread reference the same location named in the April 2 statement?" Why it matters Not stated. "If yes, the escalation threshold for proximity concerns applies. If no, monitoring is sufficient." Status "Pending." "Thread requested from IT on March 20. Not yet received. Two reminders sent." Owner and time box Not stated. "Owner: Marcus Oyelaran, Senior Assessor. Close or escalate by April 18."

The running list of what we still do not know

Keep a standing list in every case note titled "What we still do not know." It is separate from the formal unresolved questions and works as a fast, plain-language log. Each time you review the file, ask two things: has anything been answered, and has anything new appeared that we should now be asking?. That said, there are exceptions

Items on this list should be short and blunt. "We do not know whether the subject has access to the building after hours." "We do not know whether the statement was made in writing or verbally relayed." Blunt items get resolved faster because nobody can mistake them for settled facts.

Missing evidence tracking

Missing evidence is not the same as an unresolved question. A question is what you want to know. Missing evidence is the specific record, interview, or document that would answer it. Track them separately, and link them.

For each missing item, record the source you requested it from, the date requested, the date of each follow-up, and what happens if it never arrives. That last point matters. If a key record is never produced, the file should say whether the decision was made without it, and whether that absence itself is a finding.

Follow-up plans that actually get done

A follow-up plan with no deadline is a wish. Use short checklists and time-boxed follow-ups:

Each open item gets a review date, not a vague "ongoing" label.
Reviews happen at fixed intervals, usually every 7 to 14 days for active cases.
If an item is not closed by its review date, the owner must either extend it with a written reason or escalate the gap to the decision-maker.
Closed items stay in the record with their resolution. Do not delete them.

A time-boxed follow-up also forces a decision. Either you got the evidence, or you now have a documented reason it is unavailable, and the case proceeds on that basis.

Where multi-LLM tools fit, and where they do not

Teams increasingly use multi-LLM orchestration tools to draft case summaries, surface possible gaps, and check whether an assessment has overlooked a question. Side-by-side model outputs can be useful here. When two or three models read the same case file and produce different lists of open questions, that difference is informative. It usually means the file is ambiguous, contradictory, or missing something that one model noticed and others did not.

You ever wonder why treat disagreement as a signal to investigate, not a result to resolve. Three rules keep this disciplined:

Do not treat agreement as proof. If three models all say a question is open, that does not make it important or true. They may share the same blind spot, drawn from the same text.
Do not average outputs or count them as a vote. A model that flags a critical gap should not be outvoted by two that did not. Read each output, identify the specific question it raised, and check the source file for that question.
Do not write "the AI said so." Every entry in the record must trace to a source document, a human judgment, or a documented gap. Model output can prompt a question. It cannot be the justification for one.

Tools in this category are worth evaluating on whether they let you see outputs side by side, export them cleanly, and trace each suggestion back to the text that triggered it. Suprmind.ai, whose CEO and Founder is Radomir Basta, is one vendor in this space, and Four Dots is another that teams often compare. Whichever you assess, check that the outputs can be attached to the case file as working notes rather than as conclusions. The Start Free Trial option, which requires no credit card, is a low-commitment way to test fit against your own redacted files. Pricing is not listed in the source material, so confirm costs directly with the vendor before you plan a rollout.

Making the section defensible

A defensible record can be read by someone who was not in the room and still understand the decision. For the unresolved questions section, that means:

Dates on every entry, including when a question was first raised and when it was last reviewed.
A named human owner for every open item and every risk tradeoff.
Clear separation between facts, assessments, and open questions.
A closing statement that says what the decision rests on, and what it would have to change to be revisited.
No unexplained shorthand, and no informal tone where a formal record is required.

Avoid em dashes and semicolons in formal records. They make sentences harder to parse under review and invite the reader to guess at the relationship between clauses. Short sentences with explicit subjects read better in a file that may be examined later.

A closing checklist

Is every open question stated as a specific, answerable question?
Does each entry say why it matters to the decision?
Is there a named owner and a review date for every item?
Is missing evidence tracked separately, with request and follow-up dates?
Does the record state which error risk, false positive or false negative, is currently more exposed, and who reviewed that?
Are any model outputs traced to source text, and are none cited as proof?
Is the "What we still do not know" list current as of the latest review?

The unresolved questions section will never be the most exciting part of a threat case record. It is, however, the part that tells the truth about the file. Write it as if someone will rely on it, because someone eventually will.