ARCHITECTURE · SYSTEM OVERVIEW

One fabric, from first signal to full containment.

Every part of threatDefendr sits on a single streaming data fabric — collectors at the edge, behavioral models in the middle, response actions at the end. There are no integration seams between products because there aren't separate products.

FIGURE 1 · END-TO-END FLOW

Design principles

Five decisions shape everything else on this page. Hold them in mind as you read.

One fabric, not many products. Detection, response, intelligence, and forensics read and write the same event store. There are no connectors between threatDefendr's own components — there are no separate components to connect.
Keep the raw signal. Events are stored in their native shape and enriched additively, so a detection written tomorrow can replay events captured today without re-ingesting anything.
Evidence by default. Every decision — a detection firing, a containment action, an analyst override — is itself a signed event on the fabric. The audit trail is a byproduct of how the system runs, not a side task.
Response is reversible. Every containment action records its inverse, so it can be undone by an analyst or automatically on a soft failure.
Isolate by tenant. Each customer is a cryptographically isolated cell; the blast radius of any failure stops at one tenant.

Core concepts

Five terms recur throughout the platform and the rest of these docs.

Term	What it is
`event`	An immutable, enriched record of one observation — a process exec, a sign-in, an API call.
`entity_id`	The stable identifier for an actor or target (user, host, workload, identity) that ties events together across sources.
`detection plan`	A versioned, declarative rule — authored as code — that the pipeline evaluates against the live stream.
`case`	A correlated cluster of events, detections, and actions; the unit an analyst investigates.
`cell`	A single tenant's isolated data plane: its own keys, storage, and compute.