How state3 stays true.
Most CMDBs drift out of date within a year. Not because the tooling is bad, but because nothing in them decides what to do when the automated answer and the human answer disagree. That decision is the thing we built. Automated where it's safe, human where it matters, and a pipeline that knows which is which.
Everything arrives the same way.
There are two routes in, and which one a fact takes depends on where it came from. Automated and bulk sources are reconciled before they land. Deliberate edits by a person or an authorised AI client are validated and written straight through.
Get it in.
Connectors run on a schedule and land in staging, as do CSV imports run through the ingestion hub. Entity-specific imports, UI edits and MCP writes go straight to the graph instead.
Make sense of it.
The rules engine reads what arrived and proposes Add, Update, Delete or Merge actions — applied automatically if confidence is high, queued for review if it isn't.
Trust it.
Uncertain actions queue for review with field-level diffs. You approve or reject. Once a person has edited a field, automation runs around it — not over it.
Why most tools fall behind.
Auto-import everything from every system you've got, and the data goes stale — because nobody trusts it enough to fix it. Require manual entry for everything, and the platform never gets adopted at all. Most CMDB and EAM tools made one of those two choices and lived with the consequences. So we didn't pick. We built a pipeline that knows the difference, and a UI that lets a human resolve the cases the machine isn't sure about.
How it actually works.
Three subsystems, each earning the trust the next one depends on. Read to whatever depth you need.
Get it in.
Several paths bring data into state3, and they do not all work the same way. Scheduled connectors always land in staging, and so does a CSV run through the ingestion hub — those are bulk, automated sources that have to be reconciled against what is already there. An entity-specific CSV import, a direct edit in the UI, and an MCP write skip staging entirely: each one is a deliberate act against a known record, so it is validated and written to the graph.
Connectors — Azure AD, Azure DevOps, Azure Resources, Digicert, and the extensible Data Feed — run on a schedule and pull directly from the source system. The CSV import wizard covers everything without a connector: map CSV columns to state3 fields, mark anything you don't need as Skip, and upload. Run through the ingestion hub, that CSV is staged and reconciled like a connector feed. Choose an entity-specific import instead and it writes directly, skipping staging and the rules engine.
Every import is tenant-scoped, sanitised against CSV-injection prefixes, row- and column-capped, and written in batches.
Column mapping — CSV import wizard
| CSV header | Maps to state3 field |
|---|---|
| Asset Tag | asset_tag |
| Make | manufacturer |
| Model | model_name |
| Serial | serial_number |
| Location | Skip |
Five columns from a source CSV mapped to their state3 equivalents, with a Skip option for anything the organisation doesn't track.
Make sense of it.
This stage applies to the staged route. Once data lands in staging, the rules engine reads it and produces a list of proposed actions. Each action is one of four types — Add a new entity, Update an existing one, Delete something the source no longer reports, or Merge two records the engine recognises as the same thing. Each proposed action is tagged either Auto (high confidence — apply it) or Manual (queue it for human review). Confidence is shaped by alias lists, ignore lists, and transformation lists maintained per tenant.
Decision card — rules engine output
Update
Asset 1234 — location:
Hamilton → Tauranga
(alias match)
Merge
‘SQL Server’
‘Microsoft SQL Server’
(queued for review)
Two proposed actions: one auto-applied on an alias match, one queued for a human to resolve.
Trust it.
Once actions are proposed, three mechanisms make sure what ends up in state3 is what your team actually believes is true.
Review queue
Every uncertain action shows you the proposed change with a field-level diff — approve or reject, with a comment if you need one.
Diff card — action review
| Current | Proposed | |
|---|---|---|
| Edition | Standard | Enterprise |
| Version | 2016 | 2019 |
Confirmation
When you've looked at a record and you know it's correct, you confirm it. state3 records who confirmed it and when. You can confirm a single record or bulk-confirm an entire model in one operation.
Confirmation chip
Confirmed by service.owner@example.org · 2026-04-29Manual edit protection
Once a person has edited a field, the rules engine never overwrites it. Your edits are sacred. Automation runs around them, not over them.
What this earns you.
This is what the upkeep is for. The five lenses on the home page rely on it. So do the MCP queries an AI assistant runs on your behalf. So does any number a CIO defends in a board meeting. A graph that lies to you isn't intelligence — it's just paperwork that breaks faster.