From a brownfield discovery to a checked design

Reconciliation tools can tell you how a running plant differs from a design. But when there is no design yet, that’s the wrong direction. What you need first is to run the scan the other way: from the observed plant into a starting model you can edit, zone and check. That’s build-from-discovery.

The asset export gives you what’s on the network and, crucially, each device’s Purdue level. The comm baselines give you who actually talks to whom. Together they’re enough to stand up a first model.

Pick the asset export (required) and, optionally, the comm baselines, then Build model. Synapse reads each observed asset and places it: the Purdue level drives which zone it lands in — level 3.5 into the OT DMZ, level 2 into supervisory, level 1 into control, level 0 into the grid interface — and it draws the conduits between adjacent zones for you. IP addresses from the scan become interface addressing, grouped into subnets.

The comm baselines aren’t guessed at: each observed conversation becomes a data flow between the two matched assets, with the protocol mapped from what the monitor saw. Where the walkdown builder would infer likely flows, discovery uses the real ones.

A scan usually knows a device’s vendor and model even when it can’t tell you its role. Synapse uses that: when an observed string matches its device library — a Siemens SIMATIC S7-1500, an ABB RET630, a Palo Alto PA-5410 — the catalog is authoritative. The asset comes in with the right type, a sensible default criticality, and the interfaces that device speaks, rather than a generic guess from a keyword.

That device identity pays off immediately elsewhere. Open the Vulnerabilities view and the matched kit already carries its known CVEs, tagged as a device match rather than a fuzzy one. Export a Cyber Twin manifest later and each device realizes through its own catalog entry, not a stand-in.

Nothing from a scan should be taken as gospel, and Synapse doesn’t pretend otherwise. Every discovered asset and flow is marked assumed: you’ll see a small dot on each inferred node, amber where the classification is worth a second look, slate where it’s routine. No percentages, no loud badges — just an ambient nudge toward what needs your eyes.

Click {n} to confirm in the top bar to open the review queue. It lists the inferred assets, the ones flagged for review first. Click a row to focus it on the canvas and open its properties, correct anything the scan got wrong, and confirm it — or Confirm all once you’ve satisfied yourself. Confirming is one edit, so it sits on the undo stack like everything else.

With the inventory confirmed, open the Check tab. Alongside the findings you’ll see a Guidance section — forward-looking suggestions that aren’t violations, just improvements worth considering. If the scan dropped a controller into the wrong trust domain, guidance offers to move it to the tier its type belongs in. Where a zone’s assigned security level sits below what its consequence and exposure imply, it offers to raise the SL-T to the risk-derived level.

Hover a suggestion to highlight what it touches on the canvas; click Apply to accept it. These are hints you opt into, kept separate from the hard compliance findings so the two are never confused.

No scan sees everything. When you know about kit the monitor missed, you don’t have to start over. Use Import in the canvas build toolbar to merge a CSV of extra assets into the current model — they’re classified the same device-aware way and land in the right zones, ready to confirm. Or drag devices straight from the library onto a zone.

And when you’d rather begin from nothing at all — a true green-field design — the start screen’s New blank site gives you the five Purdue tiers as empty zones with conduits already drawn, so you can build up by dragging devices in. Same engine, either direction.

• Scan in, model out: an asset export plus comm baselines becomes a zoned, addressed, flow-connected model — Purdue level drives zoning, observed conversations become flows.
• Devices, not guesses: recognised vendor/models resolve to catalog devices, so type, criticality, CVEs and range realization all come from the catalog.
• Inferred, then confirmed: everything from a scan is marked assumed; the review queue is where a hypothesis becomes a design you’ll sign.
• Guidance is opt-in: zone-placement and SL-T suggestions sit apart from compliance findings — accept the ones you agree with.
• Either direction: merge a CSV of what the scan missed, or start from a blank Purdue canvas — the same builder.

From here a confirmed, checked design is ready for the rest of the loop — evidence, a firewall schedule, or a Cyber Twin. See the rest of the guides.