You cannot govern what you have not mapped
Most discovery tools begin by copying your estate into their own catalog to look at it, which turns a mapping exercise into a data-movement project, and a new copy of the data to secure. The sources that most need mapping are exactly the ones an organization will not duplicate into a vendor’s store to do it.
So the scan goes to the data. A connector reads the structure of a source in place, and only signed metadata about its shape leaves the boundary. The output is an inventory you can verify after the fact, not a second copy of the estate you now have to defend.
Scan in place, sign the result
The pipeline reads a source where it lives, normalises the finding, signs it, and checkpoints, so the inventory is tamper-evident and the scan survives being interrupted.
| Stage | What happens |
|---|---|
| A source, where it lives | The scan reaches the source in place, a warehouse, an open-format share, an object bucket, a plant historian. The data is not moved, copied or staged into System9 to be catalogued. |
| Scan kernel | A connector-driven kernel reads the structure of the source and persists inventory objects and relationships. Only metadata about the shape of the data crosses the boundary; the rows stay put. |
| Universal Semantic Model | What the scan learns is normalised into one intermediate representation (the same model whether the source was SQL DDL, a JSON schema or a CSV) so downstream reasoning does not care where a field came from. |
| Signed leaf entry | Each finding is written as an Ed25519-signed entry folded into a merkle root, so the inventory is tamper-evident and a reader can verify a claim about the estate without trusting the scanner that produced it. |
| Restart-safe checkpoint | The scan checkpoints as it goes. A kernel that is killed part-way (a link drops, a device is powered down) resumes from its checkpoint rather than starting the estate again from zero. |
| Inventory | The result is a signed, hash-chained inventory of the estate that can be verified after the fact, not a snapshot you have to take on trust. |
One semantic model
SQL DDL, a JSON schema or a CSV all normalise into one intermediate representation, with translators for the dialects an estate actually contains, so what is downstream does not care where a field came from.
Signed and restart-safe
Every finding is an Ed25519-signed entry folded into a merkle root, and the scan checkpoints as it goes. A kernel that is killed part-way resumes from its checkpoint rather than starting the estate over.
Findings become deliverables
Diagrams, an assessment scorecard with findings, best-practice analysis and signed deliverable versions, generated from the inventory, and rendered as unavailable rather than faked when the backing data is not there.
Converge over a thin link, not a fat one
Every device holds a catalog leaf of its own signed findings. Leaf and trunk compare merkle roots and move only the entries that differ, so a sync costs bandwidth in proportion to how much has changed, which is what makes discovery usable at the far end of an intermittent link.
| Element | What it does |
|---|---|
| Leaf catalog | Every device runs an in-process catalog leaf holding its own signed findings under a merkle root. A leaf can also propose a candidate source it discovered locally, for central review before it is scheduled for rescan. |
| Compare merkle roots | Leaf and trunk exchange merkle roots to find where they disagree, rather than shipping the whole catalog to compare it. |
| Move only what differs | Only the entries that actually diverge are transferred, so the bandwidth a sync costs is proportional to how much has changed, not to the size of the catalog. This is what makes the model usable over a thin or intermittent link. |
| Trunk catalog | The trunk verifies each entry's signature against a key registry, converges the divergent entries, projects them into rows and advances a watermark, then emits canonical updates back down to the leaves. |
| Owed, cross-cell convergence | Leaf-to-trunk convergence is live. Converging one catalog across separate cells is not yet: the cross-cell identity gap is still open. We state it as owed rather than implying a single estate-wide catalog exists today. |
What the scanner can reach
A catalog of 55 discovery connectors spans the source families an estate actually contains, and the same discovery works over a network link or across an air gap.
Connector-driven, in place
A catalog of discovery connectors spanning relational databases, object stores, BI tools, SaaS applications, streaming systems and file shares. Each reaches a source where it lives. Nothing is staged into System9 to be catalogued.
Cloud enumerators, including government
Least-privilege enumerators for the major clouds, with sovereign and government variants, the isolated and assured regions a commercial-only scanner cannot see. They read the shape of an account without provisioning inside it.
Carried across an air gap
For a disconnected estate, findings move as PGP-signed sneakernet bundles: exported to removable media, carried by hand, and imported as verified frames. Discovery is not a network-only capability.
A catalog is a measure of reach, not of ingest. A connector in the catalog is not a promise that any particular source will map cleanly; treat it as the surface the scanner can address, and verify an individual source before you rely on it.
What is live, and what is owed
Scan-in-place, the signed restart-safe inventory, candidate sources proposed by a leaf for central review, and leaf-to-trunk convergence are live. A device discovers locally; the trunk verifies, converges and projects.
Converging one catalog across separate cells is not yet live: the cross-cell identity gap is still open. We state that as owed rather than imply a single estate-wide catalog exists today, because a mapping product that overclaims its own coverage has undone the one thing it is for.