How to read
a verdict trace
For every verdict, the Threat Correlator keeps a record of what it looked at, which tools it called, and what evidence led to its conclusion.
We don't have real run records to publish yet, so this page explains how the record is structured and reads one example from start to finish.
What goes into one trace
Reading top to bottom follows the order in which the verdict was built.
A verdict has several steps, and each step bundles an observation, tool calls, evidence and reasoning.
| Field | Contents | What to check when reading |
|---|---|---|
| input_hash | SHA-256 of the entire input bundle that went into the verdict | Use it to confirm a replay used the same input |
| sources | Where the input came from (EDR, mail gateway, proxy and so on) and the time range | If a source is missing, the verdict's coverage is that much narrower |
| steps[].observation | The facts that stood out at that step | It summarizes raw logs, so check it against the evidence below |
| steps[].tool_call | Tool called, arguments, and a summary of the result | Check that arguments such as time range and hostname are right |
| steps[].evidence | Evidence ID, location in the raw data, hash | Includes the result of the automatic check that the cited log really exists in the raw data |
| steps[].reasoning | Why the evidence led to the conclusion, and the ATT&CK technique ID | Every reasoning statement must point to an evidence ID |
| verdict · confidence | Verdict label, severity, confidence, and the reasons confidence was lowered | Check that a low confidence comes with its reasons |
| recommended_actions | Recommended actions and whether each needs approval | Host isolation and account lockout always need approval |
| approval | Approver role ID, approved/modified/rejected, timestamp, comment | Time to approval also comes from here |
| versions | Model version, prompt template version, policy version | A change to prompt wording alone is a change in verdict criteria |
| replay | Result of a later rerun under the same conditions, and how it differs from the original verdict | Wording may differ. Check that label and severity match |
Reading one example trace from the top
Example record · not real customer data or a real run. We built this record by chaining together early-stage ransomware techniques documented in MITRE ATT&CK (phishing attachment, PowerShell execution, shadow copy deletion). Hostnames, accounts, times and confidence values are all for illustration, and domains and IPs use values reserved for documentation (.example, 203.0.113.0/24).
Where to look first
Start with why confidence on the verdict line stopped at 0.91. In this example the trace notes that no file encryption had been observed yet and that the hash of the downloaded executable had no match in threat intel. If a trace shows high confidence with no reasons for any reduction, that's the one to be more suspicious of.
Next is the approval line. By policy, host isolation never runs automatically. The trace also shows that the analyst took a little over two minutes after the verdict to read the evidence and approve.
Step by step
- Email received (step 1). The mail gateway log shows a message from
billing@invoice-notice.examplewith the attachment견적서_1021.docm("quote_1021" in Korean). The AI pulled the original message metadata withmail.search(message_id=…)and the domain details withintel.domain_whois("invoice-notice.example"). The result: the domain was three days old. The reasoning statement reads "Macro-enabled Office attachment plus newly registered domain, possible T1566.001" and points to evidence E1 and E2. No verdict was issued on this step alone. - PowerShell execution (step 2). Sysmon Event ID 1 (process creation) shows a line with parent
WINWORD.EXEand childpowershell.exe -NoP -W Hidden -enc JABjAD0A…. The AI got the process tree withedr.process_tree(host="fin-ws-0412", from="09:12", to="09:20"), decoded the encoded command, and confirmed it downloadshttps://203.0.113.45/u.ps1. Abaseline.parent_child(host, 30d)lookup showed that no Office app on this host had launched PowerShell in the previous 30 days. The reasoning cites T1059.001, with evidence E3 and E4. - Shadow copy deletion (step 3). Sysmon Event ID 11 (file creation) shows
C:\Users\user01\AppData\Local\Temp\upd.exebeing created, and a little over 20 seconds later Event ID 1 recordsvssadmin.exe delete shadows /all /quietwithupd.exeas the parent.intel.hash_lookupcame back with no match. The reasoning cites T1490 (Inhibit System Recovery), and the ATT&CK entry for T1490 lists several ransomware families that delete shadow copies before encrypting. - Verdict. True positive, ransomware staging, severity CRITICAL, confidence 0.91. Two reasons for lowering confidence are recorded: "no mass file changes observed" and "no threat intel match for upd.exe hash."
- Recommended actions and approval. Isolate the host from the network (approval required), recall emails carrying the same attachment hash, and block the sending domain and 203.0.113.45. analyst-07 approved the isolation at 09:17 with the comment "Please check SMB sessions to the file server." The two blocks fell within the automated response policy agreed with the customer, so they ran without approval.
- Replay. The next day, a rerun with the same input_hash, model version and policy version gave the same label and severity, a confidence of 0.89, and some differences in the wording of the reasoning. Wording isn't compared, so the result is recorded as a "match."
The same trace in raw form
This is a shortened version of the example above in the record format. Field names are for illustration. We'll document the actual export format at launch.
// Example record · not real customer data or a real run
{
"trace_id": "VT-EXAMPLE-0001",
"input_hash": "sha256:9f3a…c21e",
"sources": [
{"type": "mail_gateway", "range": "09:00~09:20"},
{"type": "edr_sysmon", "host": "fin-ws-0412", "range": "09:00~09:20"}
],
"steps": [
{"n": 1,
"observation": "Macro-enabled attachment (견적서_1021.docm), sender domain registered 3 days ago",
"tool_calls": ["mail.search(message_id=…)", "intel.domain_whois(\"invoice-notice.example\")"],
"evidence": [{"id": "E1", "ref": "mailgw/2026/10/21/09.log#L2207", "sha256": "1c0d…7be2", "verified": true},
{"id": "E2", "ref": "intel/whois/invoice-notice.example", "verified": true}],
"reasoning": "E1+E2: possible spearphishing attachment", "attack": ["T1566.001"]},
{"n": 2,
"observation": "WINWORD.EXE → powershell.exe -NoP -W Hidden -enc …",
"tool_calls": ["edr.process_tree(host=\"fin-ws-0412\", from=\"09:12\", to=\"09:20\")",
"baseline.parent_child(host=\"fin-ws-0412\", window=\"30d\")"],
"evidence": [{"id": "E3", "ref": "sysmon:EventID=1 RecordID=884213", "verified": true},
{"id": "E4", "ref": "baseline/fin-ws-0412/parent_child", "verified": true}],
"reasoning": "E3: Office app ran encoded PowerShell, E4: no precedent in 30 days",
"attack": ["T1059.001"]},
{"n": 3,
"observation": "upd.exe created, then vssadmin.exe delete shadows /all /quiet",
"tool_calls": ["edr.process_tree(…)", "intel.hash_lookup(\"sha256:3b7e…a19f\")"],
"evidence": [{"id": "E5", "ref": "sysmon:EventID=11 RecordID=884240", "verified": true},
{"id": "E6", "ref": "sysmon:EventID=1 RecordID=884251", "verified": true}],
"reasoning": "E6: recovery options deleted, assessed as pre-encryption stage", "attack": ["T1490"]}
],
"verdict": {"label": "true_positive", "severity": "critical",
"summary": "Ransomware staging",
"confidence": 0.91,
"confidence_notes": ["No mass file changes observed", "No threat intel match for upd.exe hash"]},
"recommended_actions": [
{"action": "isolate_host", "target": "fin-ws-0412", "requires_approval": true},
{"action": "recall_mail", "match": "attachment_sha256", "requires_approval": false},
{"action": "block", "targets": ["invoice-notice.example", "203.0.113.45"], "requires_approval": false}
],
"approval": {"action": "isolate_host", "by": "analyst-07", "decision": "approved",
"at": "2026-10-21T09:17:40+09:00", "comment": "Please check SMB sessions to the file server"},
"versions": {"model": "correlator-model-x.y", "prompt_template": "triage-vNN", "policy": "auto-response-YYYY.MM"},
"replay": {"at": "2026-10-22T10:05:12+09:00", "same_input_hash": true,
"label_match": true, "severity_match": true, "confidence": 0.89,
"text_diff": "Some wording in reasoning differs"}
}
verified is the result of the automatic check that a cited log really exists in the raw data store. If any one is false, the verdict is held and passed to an analyst. How we count these checks is described under fabricated output detection on the AI verdict quality page.
What the receiving side does with a trace
Verdict traces aren't internal logs that only Genox reads.
We build them on the assumption that customer security teams and auditors will open them directly.
Audit response
When an audit or incident investigation asks "Why was this host isolated?", one trace answers it. What was seen is in evidence, who approved is in approval, and which model and policy were running is in versions. Evidence is kept as locations and hashes, so you'll need to align your raw log retention period with your verdict trace retention period.
False positive analysis
For a verdict confirmed as a false positive, find the step where it went wrong. Following the steps one by one usually shows whether a tool call argument was wrong, a baseline lookup came back empty, or the reasoning went further than the evidence. When we include false positive cases in the monthly report, we attach these traces as they are.
Rule tuning
If verdicts keep losing confidence for the same reason, you can see where collection scope or detection rules need work. In the example above, file server audit logs weren't in sources, so lateral movement couldn't be checked. After changing a policy, rerun past verdicts on the new policy version and check the differences.
We'll publish real traces
as they're ready
We're reproducing publicly documented attack techniques in the isolated Research Lab environment and collecting the verdict traces the Threat Correlator produces. Once we have run records with no customer data mixed in, we'll post them here unedited. Until then, every trace on this page is an example.
Rules we'll follow when publishing
- Traces with wrong verdicts go up alongside the correct ones
- Each comes with the technique IDs and the procedure used to reproduce it
- Each records its model and policy versions, and when a version changes we add the rerun results
- Hostnames and accounts in the isolated environment are created so they don't overlap with any real customer environment
Related pages
How we measure AI verdict quality
How we use verdict traces to measure accuracy, false positives and negatives, missing evidence and replay consistency.
See the methodsThreat Correlator
The engine that groups alerts into incidents and records evidence, reasoning, verdict, recommended actions and confidence.
Threat CorrelatorPlatform
See how Vulnerability Scanner, Behavioral Analyzer, Threat Correlator and Research Lab connect.
See the platformReferences
- Phishing: Spearphishing Attachment (T1566.001), MITRE ATT&CK
- Command and Scripting Interpreter: PowerShell (T1059.001), MITRE ATT&CK
- Inhibit System Recovery (T1490), MITRE ATT&CK
- Sysmon, Microsoft Sysinternals (Event ID 1 process creation, 11 file creation)
- vssadmin delete shadows, Microsoft Learn
- RFC 5737 IPv4 Address Blocks Reserved for Documentation, IETF
- RFC 2606 Reserved Top Level DNS Names, IETF