Features · Network operations
The model that designed the network audits it in operation.
Your design is already the intended state — every switch, port, closet, and VLAN. NetCommand diffs that golden config against what is actually observed and returns prioritized, advise-only remediation. It recommends; your team decides.
Designed vs observed
- 01 Golden config derived from the design, provenance-tagged
- 02 Observation a screenshot, vendor export, or probe
- 03 Diff deterministic, classified, explained
- 04 Recommendation prioritized and advise-only
- 05 Your hands the only ones that touch the gear
One intended state. No second config repo.
NetCommand · Golden-config diff
Findings a senior engineer would sign
The golden config is not another document to maintain — it derives from the design itself. The diff against observed state is deterministic, and its honesty rules are enforced in the engine, not in a style guide.
- The intended state derives from the design you already built — topology tiers, ports, closets, VLAN intent — with every field provenance-tagged so the diff can classify honestly.
- Observed state comes from what you have on hand — a screenshot, a vendor export, a probe — normalized to one shape before the comparison.
- Every finding is classified — missing, unexpected, mismatch, degraded, or conformant — and carries severity, confidence, and blast radius: site, subnet, or device.
- A designed device with no observed match is an unresolved risk, never a guess about why. An observed device with no designed match is flagged the same way — possible rogue, never asserted malice.
One finding, in full
- Kind
- mismatch — expected vs actual, side by side
- Severity
- critical to info, with confidence
- Blast radius
- site, subnet, or single device
- Classification
- fact, inference, or unresolved risk
- Explanation
- why it matters, in plain language
Weak matches are downgraded, not rounded up.
Remediation · Advise-only
Recommends. Never touches your gear.
Remediation is a guided walkthrough with a verify-before-trust chain in the middle — the same discipline as everywhere on the platform: deterministic results are the ground truth, and narrative sits on top.
- Deterministic assessment runs first and is authoritative — end-of-life status read straight from the product library, per-OEM intelligence applied to the gear you actually have.
- Every drafted step is reviewed by an independent, deliberately skeptical verifier before it reaches you. Steps with site- or subnet-wide blast radius face three skeptics — a majority refutation kills the step.
- The advise-only boundary is structural: a step in which the system itself would execute a change is refused at verification. What survives guides a scoped action for your team — power-cycle this device, set this field.
- Verification failure is visible: a step either clears the gate or is explicitly marked needs-verification. Sessions are org-scoped with an audit trail.
The trust gate
- 01 Draft a remediation step is proposed
- 02 Verify an independent skeptic reviews it
- 03 Escalate wide blast radius → three skeptics
- 04 Surface verified, or labeled needs-verification
- 05 Act you do — it never does
Advise-only is the pipeline, not a setting.
Compliance-framework advisor
The right framework, recommended — not a badge
Which compliance framework applies is a question your design can largely answer. A deterministic ranker reads the signals and recommends — SOC 2, NIST CSF, NIST 800-171, HIPAA, PCI DSS, IEC 62443 — and it is equally explicit about what to skip.
- Signals come from reality, not a questionnaire: your industry, the devices actually placed in the survey, and federal-contractor indicators in the record.
- OT and ICS equipment in the design points to IEC 62443; payment terminals point to PCI DSS; healthcare context points to HIPAA; federal-contract signals point to NIST 800-171; NIST CSF stays on the table as the baseline many teams stack on top.
- Every strong recommendation traces to the documented rule that fired — nothing is silently recommended — and frameworks that do not apply are marked skip, deliberately: a service-org framework is not pushed on a company that is not one.
- It recommends and explains; it does not certify you, and it does not make you compliant — that work stays with you and your auditor. Behind it sits an edition-aware standards registry tracking the codes that govern low-voltage and electrical work.
Signals in, ranking out
- PLCs on the survey
- IEC 62443 — strongly recommended
- Payment terminals
- PCI DSS — strongly recommended
- Healthcare industry
- HIPAA — strongly recommended
- Federal indicators
- NIST 800-171 — strongly recommended
- Not a service org
- SOC 2 — skip, on purpose
Each bucket names the rule that fired.
Operations you can defend to an auditor
- Advise-only
- Enforced in the pipeline
- A step where the system itself would execute a change is refused by design
- Designed vs observed
- One classified diff
- Severity, confidence, and blast radius on every finding
- 3 skeptics
- For high blast-radius steps
- A majority refutation kills the step before you ever see it
- 6 frameworks
- Ranked from real signals
- Strongly recommended · consider · skip — with the rule that fired
Frequently asked questions
Does NetCommand push configuration to my devices?
No — and not as a policy toggle, but structurally. The verification gate refuses any step in which the system itself would execute a change; what survives is guidance for a scoped human action, like power-cycling a device or setting a field. It recommends, prioritizes, and explains. Your team operates the gear.
Where does the golden config come from?
It derives from the design you already built — the same topology, ports, closets, and VLAN intent — as a pure computation, with every field provenance-tagged. There is no second, hand-maintained config repository to keep in sync: change the design and re-derive.
Will this make us SOC 2, HIPAA, or PCI DSS compliant?
No — and be wary of any tool that says yes. The advisor recommends the applicable framework from real signals in your industry and design, shows the rule behind every recommendation, and marks frameworks that do not apply as skip. Achieving and attesting compliance stays with you and your auditor.
What happens when the diff is not sure?
It says so. A designed device with no observed match is recorded as an unresolved risk — it could be offline, unplugged, or never installed, and the engine refuses to guess which. Weak identity matches are downgraded from fact to inference and the finding's confidence drops. Remediation steps that fail verification are labeled needs-verification, never dressed up as trusted.
Operate against the design, not a guess
Bring a topology screenshot or a vendor export and see the diff classify it against your design. Talk to us about what your team needs.