The Discovery pipeline in front of the CMDB, tenant isolation, core entities, background jobs, feature flags, data protection and the audit trail.

Discovery is a pipeline in front of the CMDB. Each stage has one job and hands its result to the next. The CMDB module stays the only place where CIs are created or changed: Discovery calls the CMDB services rather than writing CI data itself.

The pipeline

Stage	What happens	Result
1. Pull	A scheduled job reads the external system through its integration adapter.	Raw vendor data
2. Commission check	The run is checked against the approved scope, manifest version, allowed fields, allowed data classes and change caps.	Run opened, or source quarantined
3. Stage	Each record is normalised, fingerprinted and stored as evidence. Unchanged records only refresh their last-seen time.	Observations
4. Reconcile	Observations are matched to CIs by strong identifiers (serial, MAC, FQDN, cloud resource id, external id).	Reconciliation links
5. Precedence	For each attribute, the precedence policy decides whether this source may set the value.	Apply or review decisions
6. Apply or review	Permitted changes are written through the CMDB as a new CI version. Everything else becomes review evidence and, where it is drift, a deviation.	CI versions, review items, deviations
7. Enrich	Installed software is normalised, mapped to CPE names and correlated with CVE and end-of-life data from the EU feed mirror.	CVEs and lifecycle dates on CIs
8. Verify and attest	Confirmations from independent origins are recorded; absence is counted; the attestation folds the evidence into a report.	Verification status, tombstone candidates, attestation

Not every stage runs end to end for every source yet:

The vulnerability scanner source pulls all pages and records CVEs, but does not yet use the run ledger and the commissioning gate (stage 2).
The Microsoft Intune source pulls, stages and uses the run ledger, but its observations are not yet linked to CIs by the apply sweep (stages 4 to 6).
Software normalisation, CPE and CVE correlation and end-of-life enrichment (stage 7) are built and tested but not yet scheduled in the sweep.
Independent verification (stage 8) has its rules and staleness checks, but confirmations are not yet written by the sweep, so the attestation shows no verified CIs.

See Availability for the full status.

Tenant isolation

Every discovery table lives in your tenant's own database schema. Each request and each background job sets the tenant context before it reads or writes, so one tenant's observations, runs and deviations can never be read by another tenant. Collector traffic carries the tenant in its address and is resolved before any tenant data is touched. Every discovery API procedure checks both the permission and the tenant scope.

Core entities

Entity	Purpose	Related to
Discovery source	Registered source with kind, origin system, commissioning state, approved scope and caps	Integration, runs, observations
Discovery run	One pull; immutable once completed; carries outcome, counts and absence eligibility	Source
Discovery record and record state	Append-only observation and its current fingerprint, last-observed and last-changed times	Source, reconciliation link
Reconciliation link	Which CI an observation belongs to, with outcome	Observation, CI
Precedence rule	Tenant override of the platform default precedence for one class, attribute and source kind	CI class
CI origin	Immutable stamp of which source first created a CI (or `cmdb_manual` for CIs that pre-date discovery)	CI
Apply review item	Append-only evidence of why an attribute was not applied	Observation, CI
Deviation	Workflow object promoted from a review item: owner, severity, SLA, decision	Review item, CI
Verification claim and policy	Idempotent confirmation records; effective-dated verification window per class	CI, audit log
Absence streak and tombstone candidate	Consecutive successful runs that did not see a CI; the resulting retirement proposal	Source, CI
Apply batch	Previewed and committed production-apply plan with digest	Source, CIs
Software catalog, CPE mapping, lifecycle mapping	Normalised installed software and its links to vulnerability and end-of-life feeds	CI, CVE register
Topology observation	An observed edge between two records, waiting for a decision	CI relationship
Collector	On-premises collector identity, enrollment token hash, heartbeat, version	Source

Integration with other modules

Module	How Discovery uses it
CMDB	Creates CIs, writes new SCD Type-2 versions and retires CIs through the CMDB services. Ambiguous identities go to the CMDB Reconciliation queue — see Reconciliation and import and Versioning and history.
CMDB relationships and topology	Accepted topology links become governed CI relationships and appear in the topology graph immediately — see Relationships and impact.
CVE register and DORA detection	CVEs are recorded through the CMDB CVE service, which owns versioning, the audit row and the DORA critical-detection event — see CVEs and lifecycle risk.
EoL/EoS risk register	Lifecycle dates are written to the CI end-of-life and end-of-support fields that the daily risk check already reads.
Integrations platform	Adapters, polling scheduler, encrypted credential storage, health events and residency acknowledgement.
System health	Failed and partial discovery imports are reported on the System health page.
Audit log	Every discovery mutation writes exactly one hash-chained audit event in the same transaction.
Feature flags	Discovery is switched on per tenant; the first sealed attestation makes the flag sticky.
Controls (K4)	The Soll/Ist comparison control reads deviations and verification evidence. See Compliance for why K4 figures should not yet be presented to an auditor.

Background jobs

Job	Schedule	What it does
Integration poll	Every 5 minutes (tick); each integration keeps its own cadence, 6 hours by default for scanners	Pulls enabled pollable integrations and stages observations when discovery is on.
Discovery apply sweep	Hourly at minute 47	Reconcile, precedence, apply or review, CVE recording and promotion of new deviations.
Deviation SLA sweep	Daily at 02:15	Marks deviations whose review target has passed as SLA breached. Never changes their state.
Verification staleness	Daily at 02:15	Records when a CI's last independent confirmation has left the verification window.
Feed mirror sync	Daily at 04:00	Refreshes the EU copy of the NVD and endoflife.date feeds.

Feature flags

Flag	Default	Switches on
`discovery_sources`	Off	Everything in this section: pulls, staging, the Discovery pages and their menu entries. Listed under DORA (asset inventory). Becomes sticky when the first attestation is sealed.
`discovery_collectors`	Off	The on-premises collector enrollment and heartbeat endpoints.
`cve_detection_ui`	Depends on bundle	Recording of CVEs from scanner findings and CVE correlation.
`eol_eos_risk_register`	Depends on bundle	End-of-life enrichment and the daily EoL/EoS risk check.
`integrations_preview`	Off	Enabling integration adapters that are still marked Preview.

Flag off means invisible

With discovery_sources off, no pull runs, nothing is staged and the Discovery menu entries are hidden. Once the attestation has been sealed, switching the flag off again needs a dual-approval request.

The toggle catalog lists the platform's flags and bundles.

Data protection

Every column of every discovery table carries an explicit PII classification; the build rejects untagged columns.
Audit events contain structural facts only (IDs, keys, counts, timestamps). Discovered values and free-text review evidence are kept out of the audit payload.
Integration credentials are encrypted at rest (KMS-backed, Vault transit in production) and never logged. Configuration stores only a reference.
Enabling an integration whose vendor stores data outside the EU requires an explicit, audited data-residency acknowledgement.
Vulnerability and end-of-life feeds are read only from the EU mirror. A correlation run cannot call a US service.
Cloud inventory is planned — not yet available. Its residency rule already exists: inventory from a region outside the EU allowlist (including UK and Switzerland) requires a recorded region acknowledgement naming who accepted it, when and why. The acknowledgement register records these today, but does not yet enforce them before the first pull.
A dedicated works council and GDPR discovery package with enforced data-minimisation switches is part of the collector plan — planned, not yet available.

Audit trail

Discovery writes to the tenant audit log, which is append-only and hash-chained. Each business-relevant action produces one audit row in the same transaction:

source registration and commissioning
run start and completion, and quarantine
CI apply
deviation opening and decision
verification
tombstone decisions and topology decisions
policy changes
the sealing of the attestation

Observations, review evidence, verification claims and verification policies are append-only tables; the application role cannot update or delete them.

Technical detail for IT administrators

Source contract. Each source declares a manifest with its identity attributes in precedence order, typed as serial, mac, fqdn, cloud_resource_id or external_id and marked strong or weak. At least one must be strong, and no identity attribute may be volatile.
Fingerprint and change detection. Records are canonicalised and hashed. Per-run noise (scan IDs, last sync times, public IPs) is declared volatile and ignored, so a re-scan of an unchanged estate produces no change.
Liveness. observed_at is stamped by the server, never by the source. A one-time observation nonce per pull prevents replayed data from looking fresh.
Blocking. Matching builds one identifier index per run and compares records only within an identifier block, instead of comparing every CI with every other CI.
Identifier canonicalisation. MAC and other identifiers are normalised (for example AA:BB:CC and aabbcc match). Unknown identifier keys are namespaced by key name so two systems using the same value never collide.
Filler serials. Placeholder serial numbers such as To Be Filled By O.E.M. are filtered so that many virtual machines are not collapsed into one CI.
Collector. A single static Go binary, outbound-only over HTTPS. It enrols with a single-use token (only a SHA-256 hash is stored), receives a scoped credential, and can be revoked terminally. The collector is partially available: see Sources and commissioning.
Feeds. NVD CVE 2.0 and endoflife.date are mirrored to EU object storage with a per-artifact licence check before any byte is stored.

How it works