The estate

The estate is ISE’s knowledge base of your infrastructure: what exists, how it connects, and what you know about it that no integration can tell you. It is the join spine — the thing that turns “a DataDog alert” and “a Kubernetes observation” into two views of one workload.

Three registers

The estate holds three kinds of knowledge, distinguished by who owns the truth and how it is maintained:

Structural — what exists and how it connects. Entities (services, clusters, databases, hosts, namespaces, zones, users…), the aliases each integration knows them by, and typed directed edges between them: runs-on, depends-on, hosted-on, routes-to, part-of. Mostly discovered and continuously refreshed — existence and placement are facts about the world, not opinions.

Contextual — local human knowledge that changes how ISE reads what it sees. Free-form annotations hung off an entity: “Kora is the CRM, business-critical”, “expect transient nodes here — this cluster runs Karpenter.” Authored, sticky, and loaded as narrative context whenever an investigation reaches that entity.

Tuning — how loud a signal should be here. The scoped severity overrides and ignores described in signals & incidents, which can be scoped right down to a single entity.

The entity id is the join key

Every integration that knows the same real thing carries an alias — the native key it uses. datadog:service:checkout and k8s:g5/shop/deploy/checkout both resolve to one entity id, and that id — not a per-integration name — is what a signal’s affected-entity link, an evidence query’s target, and your annotation all point at.

This is what makes investigation directed: resolve the affected entity, walk its edges, and hand the AI a bounded evidence plan — the blast radius — instead of an open-ended licence to go exploring.

An entity is not the same thing as a system (a configured integration instance). Entities live across and inside systems: one service is seen by both DataDog and Kubernetes; one cluster contains many workloads. The alias is the seam between the two vocabularies.

Identity resolution

Deciding that two native keys are the same thing happens in three tiers, cheapest and most-trusted first:

1. Harvest shared keys automatically. Where two integrations already carry a common key — a Kubernetes deployment labelled with its DataDog service — ISE creates the alias itself. No model, no human, no cost.
2. AI-proposed candidates, human confirms. Where no shared key exists, a heuristic may propose that two entities are the same. It is a candidate, surfaced for you to accept or reject. ISE never merges two entities on a guess — a wrong merge corrupts every downstream investigation.
3. Human-asserted aliases. You state it directly. Top of the trust ladder, and it does not decay.

Where discovered and authored knowledge disagree, authored wins and the conflict is surfaced rather than silently resolved.

Relationships and impact

Edges are what turn an inventory into an answer to “what does this affect?”. Some are harvested deterministically (a pod runs on a node; a service routes to a workload), some are AI-proposed for you to confirm, and some you assert yourself. Traversing them gives the blast radius that an incident’s impact view and every directed investigation depend on.

Lifecycle: entities retire, they don’t disappear

Discovery stamps last_seen_at on everything any source reports. When nothing has reported an entity for its retirement window, it becomes retired: still a full entity — its id resolves, its tags, edges, annotations, and signal history all intact — but known to be gone from the world and hidden from the estate by default. A returning entity un-retires.

Retirement windows are per entity type, because a Karpenter node missing for an hour is dead while a namespace missing for an hour means the cluster connector had a bad afternoon. Short windows for churning kinds (hosts, workloads), long ones for structural kinds (clusters, namespaces, databases, services).

Long-retired entities carrying nothing anyone needs are eventually pruned — pure housekeeping so the table doesn’t grow without bound. Nothing still in use is ever deleted; signals, tags, and audit records hang off entity ids and must keep resolving.

Documents and repositories

Two registers extend the estate with what your infrastructure is supposed to be: knowledge sources (scraped documentation, linked to entities by tags rather than manual wiring) and the repository register (IaC, manifests, workflows — comprehended once and searched on demand). Both present their age openly rather than hiding it, and both flag a source that has disappeared instead of quietly forgetting it.

Next

• Tags — the estate read by classification instead of identity.
• Signals & incidents — what attaches to these entities.
• The core loop — how a directed investigation uses all of this.