One path in. Nothing goes back.

TRINETRA never reaches for traffic. A copy is supplied by whatever already sits on the link: a live TAP or SPAN port, a hardware data diode, an exported flow record, a historical capture, or a seeded lab generator. Every event carries the source type it arrived as, so a replayed capture is never mistaken for a live observation. A host on the monitored network chooses the domains, the SNI values and the byte counts in this data, so the source is treated as untrusted from the first byte.

• Source types9 recorded
• Event contract1.1.0
• Payload contentNever stored

Copied traffic crosses a boundary that has no path back. In the live deployment a trusted host controller provisions an unbridged receive-only interface, installs an all-protocol ingress drop on the host end while both ends are down, and then raises the pair. Sensor transmissions hit that drop. The controller reconciles the boundary every second, and the sensor reads the resulting state. This is a software enforcement demonstration on Linux — it is not physical diode certification, and the repository says so.

• Return pathNone
• Sensor capabilitiesNET_RAW only
• Reconciliation1 s

The sensor layer tails Zeek conn, dns and ssl logs correlated by uid, and publishes normalized events. A historical capture takes the same path through replay: file to Zeek to events, with no network involved at all. The live sensor holds NET_RAW for capture, drops every other capability, and cannot administer the interface it reads from. Traffic generators and attack tooling live in separate lab networks, outside the passive analysis boundary.

• ReaderZeek conn / dns / ssl
• ReplayLocal file only
• Sockets to captured hostsNone permitted

This is the trust boundary. Field names are resolved through a static alias table rather than evaluated, every value is validated with extra set to forbid, and a record that fails is rejected and counted by low-cardinality reason — never coerced into shape. Domains are length-checked and canonicalised, addresses go through IPvAnyAddress, ports are bounded, counters must be non-negative. A deterministic event id makes replay idempotent and a bounded dedup memory keeps a replayed capture from becoming a second copy of itself.

• Extra fieldsForbidden
• RejectionCounted, never coerced
• Event schema1.1.0

Validated events are published onto Redis Streams inside the enclave: raw, normalized, features, alerts, feedback and model events, each with a dead-letter stream beside it. Consumers acknowledge only after the batch is persisted, so a crash re-delivers rather than loses. A poisoned entry is claimed back with XAUTOCLAIM and, after a bounded number of deliveries, moved to the dead-letter stream and acknowledged. Streams are trimmed with approximate max-length, which is O(1); exact trimming is not.

• Streams6 + dead-letter
• AcknowledgementAfter persist
• Poison entriesBounded, then dead-lettered

The same flow is evidence of different things depending on which end you look from, so the engine keeps three keyed perspectives: the source host, the destination, and the source-to-destination pair. Each carries 1, 5, 30, 60 and 300 second windows in a single vector, together with DNS lexical and behavioural features, TLS handshake attributes, exfiltration volume and baseline comparisons. Baselines are per-entity EWMA mean and variance with a 256-sample quantile reservoir, and a cold baseline is reported as cold rather than as a large z-score.

• Windows1 · 5 · 30 · 60 · 300 s
• PerspectivesHOST · DESTINATION · PAIR
• Feature schema1.2.0

Every detector implements the same contract and returns either a result or nothing, because a benign window is the normal case and should not fill the store. One detector raising is caught, counted, and the remaining detectors still see the window. A detector without a model is not silently skipped: it reports UNAVAILABLE with a reason and returns nothing. The technique is recorded on every result, so an alert never overstates how much learned machinery was involved — rules, statistics and models are all first-class.

• Detectors9, all READY
• TechniquesRULE · STATISTICAL · SUPERVISED · HYBRID
• IsolationPer detector

A sustained flood produces one result per emit tick. The first becomes an alert; the rest bump the dedup count and advance last_seen. Corroboration is bounded and monotonic — confidence is the primary value plus 0.08 per distinct corroborating detector, capped at 0.99 — so it can be recomputed from the stored contributions rather than taken on trust. Two or more distinct threat classes on one subject within 300 seconds become an incident. One class is an alert; two is a story. Challenger results are dropped here and can never become an alert.

• Corroboration step0.08 per detector
• Confidence cap0.99
• Incident window300 s

An alert carries what was observed and what it was compared against, in two separate blocks. Observations are the measured values. Baseline comparisons are the thresholds, baselines, z-scores and percentiles they were read against. Splitting them means a reader does not need to know the feature naming convention to tell a number from a reference. Reason codes, detector contributions, the feature schema version, the detector version, the model version and the pipeline run id travel with the record, which is enough to reproduce the decision later.

• Flow references≤128 per alert
• Reason codes≤32 per result
• Decision recordAppend-only ledger

Every alert is a structured instance of one versioned schema: timestamp, first and last seen, threat class, confidence and how that confidence was derived, severity and impact, status, the subject it is attributed to, the detector and model that produced it, the evidence, the lineage and any incident it belongs to. Two internally versioned contracts govern the whole system, and an unknown schema version on an event or an alert is a validation error rather than a best-effort parse. Bumping the feature schema invalidates every model trained against the old one, and the registry refuses to load it.

• Alert schema1.1.0
• Threat classes7
• StatusesNEW → TRIAGED → CONFIRMED · DISMISSED · SUPPRESSED

The analyst surface is a REST API and a WebSocket alert stream. Readiness reports the store, the queue, the sensor and each detector separately, so a healthy process and a healthy pipeline are never conflated. Metrics are exposed in Prometheus format with label names fixed at construction — an address as a label value would be an unbounded time series and a way to take down the scrape target. Mutating routes, feedback submission, replay control and every model lifecycle action run behind an operator check first.

• Read routesUnauthenticated
• Mutating routesOperator token
• Metric labelsDeclared at construction

Everything the console shows came across the boundary read-only: alerts, incidents, flows, detector state, model governance, replays and benchmarks. The same absence of a return path that shapes the sensor shapes the interface — there is no block button, no quarantine action and no push to a device, because there is no path to carry one. The analyst's output is a decision and, when they label an alert, a training candidate.

• Operator actions on the networkNone
• Analyst outputDecisions and labels
• Full architectureOn this page, not in the console