Concepts
Evidence custody
Custody means every conclusion in the console stays attached to the telemetry and decisions that produced it. If an operator cannot walk from claim → finding → event → raw source, the product has failed its own design — regardless of how polished the UI looks.
Why custody is a first principle
Most SOC consoles optimize for volume and speed: more panels, denser scores, more automated summaries. That style collapses disagreement. When identity risk says one thing and endpoint process ancestry says another, a single opaque “risk score” erases the conflict instead of exposing it.
1000 Beacons inverts that pressure. Correlation and recommendation are allowed. Erasing provenance is not. Raw vendor payloads stay available beside normalized fields. Source table names and connector kinds stay attached. Entity identifiers used for linking stay inspectable. Confidence stays separate from severity so “urgent” never silently becomes “certain.”
Custody also governs evaluation and failure modes. Synthetic records carry synthetic provenance. A failed live API call must surface as empty or unavailable — never as a silently substituted demo tenant that looks healthy.
What every event is expected to preserve
Inbound telemetry is accepted as a TelemetryEnvelope shared across the TypeScript contracts package and the Python API. Writers and readers are expected to preserve at least the following fields. Missing pieces do not get invented by the UI.
- Stable event id plus source event id / revision for deduplication across sync cycles
- Source connector kind (for example microsoft_sentinel) and source table name (for example SecurityAlert)
- observedAt (when the source saw it) and ingestedAt (when Beacons accepted it)
- tenantId that must match the authenticated tenant on write
- entityIds and often sourceEntityIds for graph attachment and case linking
- severity as a vendor or rule-facing field — never merged into confidence
- confidence as a separate field so operators can weigh uncertainty
- raw object (source-native) plus normalized object — raw is never overwritten by normalized
- provenance: real, synthetic, replay, or test
Where custody appears in the console
Incidents expose investigation tabs that keep the case tied to evidence: Route (how entities relate), Evidence (source-linked events), Replay, Response, Automation, and Custody. Hunt Ledger findings cite the check that produced them and, when a case was opened, the incident id. Automation runs snapshot an immutable playbook version and keep step receipts so later readers know exactly which published definition executed.
Domain workbenches (EDR, Email, SaaS, Identity, Cloud) can show a source custody panel describing which telemetry families and detection rules apply to that domain. They do not create a second private alert store. If a domain page cannot explain its evidence links, treat the conclusion as an inspectable recommendation — not settled truth.
What custody forbids
These rules are operational, not decorative. Breaking them creates exactly the class of SOC failure the product is trying to avoid: confident UI over uncertain or invented data.
- Presenting evaluation or synthetic records as live connector output
- Collapsing confidence and severity into one number or one color
- Letting detection or hunt engines silently contain, disable, revoke, or block without human gates
- Destroying raw payloads after normalization
- Cross-tenant reads that leak another organization’s events or cases
- Substituting evaluation fixtures when a live control-plane fetch fails
If a feature cannot explain its evidence links under these rules, it should ship only as an inspectable recommendation — never as a finished, silent conclusion.