Trust Requirements¶
For ARCHER's output to be actionable in a professional or enterprise environment, every investigation must satisfy all nineteen of the following requirements. These are acceptance criteria, not aspirations - a feature that doesn't serve them doesn't ship.
Evidence and Traceability¶
1. Source linkage. Every finding links directly to the raw telemetry or log entry that produced it. Not a summary. Not a synthesized description. The specific evidence, citable and reproducible by any analyst reviewing the output.
2. Chronological log. Every investigation produces a log showing what was queried, in what order, and why - enabling any analyst to independently reproduce the investigation and arrive at the same findings.
3. Reproducibility. The exact query strings, API calls, and commands used to retrieve data are exposed in the output, enabling manual reproduction without access to ARCHER.
4. Dead end documentation. Where ARCHER searched and found nothing, that absence is recorded explicitly. An investigation that reports only positive findings is incomplete. Absence of evidence is data.
5. Immutable audit trail. Every action taken or recommended is time-stamped and written to an append-only session log. Nothing in the log can be retroactively modified.
Analysis Quality¶
6. MITRE ATT&CK mapping. All identified behaviors map to specific MITRE ATT&CK techniques and sub-techniques, with the evidence supporting each classification stated explicitly - not inferred or estimated.
7. Alert correlation. Related alerts from multiple sources merge into a single unified incident view. Redundant triage is eliminated.
8. Data gap disclosure. ARCHER explicitly states which data sources were inaccessible or which logs were missing during the investigation. It does not silently omit coverage gaps.
9. Fact vs. inference distinction. Deterministic facts (file hash match, known-bad IP) are distinguished from probabilistic inferences. Confidence scores include a breakdown of the specific signals that produced them.
10. Contradiction surfacing. When different security tools produce conflicting findings during the same investigation, the contradiction is surfaced explicitly rather than resolved silently.
11. Baseline verification. Findings are verified against known-benign baselines and established gold images to filter environmental noise before being reported.
Correlation and Context¶
12. Attack chain narrative. Identity, endpoint, and network telemetry are correlated into a coherent attack chain narrative - not a list of discrete alerts.
13. Root cause analysis. Every investigation ends with automated root cause analysis identifying the initial entry point of the threat, not just the observed effects.
14. Policy correlation. Where applicable, findings reference relevant internal security policies or historical incident reports from the same environment.
Operational Output¶
15. Risk assessment. Every remediation recommendation is paired with a risk assessment of potential operational downtime. Recommendations that cause outages are not presented without that context.
16. Prioritized roadmap. Every investigation ends with a prioritized "what's next" roadmap for the human analyst - not just findings, but the recommended investigative or remediation sequence.
17. SIEM/SOAR integration. Output is formatted for direct ingestion into SIEM and SOAR platforms without manual translation. If an analyst has to reformat the output before it can be actioned, ARCHER has added a step, not removed one.
18. Regulatory reporting. On high-risk detections, generated reports satisfy NIS2 and DORA formatting requirements as output, not as a post-processing step. See NIS2 & DORA Alignment.
19. What's next. Every investigation closes with a clear statement of what should happen next - next investigative steps if the investigation is incomplete, or prioritized remediation steps if it is.
Why Nineteen Requirements¶
These requirements exist because "the AI flagged this as suspicious" is not an answer that satisfies a compliance audit, a board inquiry, or a regulatory investigation.
The answer that satisfies those audiences: here is the specific log entry, here is the query that retrieved it, here is the chain of inference, here is the timestamp of every action, here is the human who authorized each one.
That is investigative provenance. It is the minimum viable output for enterprise deployment in a regulated environment. ARCHER is built to produce it by default, not as an optional export.