Vendor profiles

A vendor profile captures how a particular network OS behaves, so the collector can talk to every device of that type consistently. One profile per OS drives collection end to end — CLI/SSH session handling and the default collection settings for gNMI, NETCONF, and SNMP — instead of those details being hard-coded or repeated on every device.

Profiles are schema-validated: each field has a defined type and allowed values, and the form only saves a valid document.

What a profile drives

• CLI / SSH sessions — prompt patterns, error patterns, a clean-shell flag, and auto-responses. Patterns are validated as regular expressions when you save or import the profile.
• gNMI defaults — default encoding and path origin.
• NETCONF defaults — default port.
• SNMP — the compiled version matching used during collection (changes take effect on save, without a restart).

How defaults are resolved

For any setting a profile can supply, the collector applies this precedence:

1. An explicit value set on the device (or mapping) wins.
2. Otherwise the vendor-profile default is used.
3. Otherwise the collector's built-in default applies.

This means a profile sets sensible defaults for a whole OS family while any individual device can still override them.

Built-in profiles

The collector ships with built-in profiles for common vendors, seeded from its proven CLI drivers, so collection works out of the box. Built-ins are kept current automatically on upgrade — but any profile you have edited is never overwritten.

Using profiles on a device

On the device form, the Network OS field offers your enabled profiles as a picklist (free text is still allowed). If you enter an OS that has no matching profile, the collector warns you but still lets you save (warn-but-allow), and flags the device with a "no profile" badge.

Manage profiles

From the vendor-profiles page you can:

• Create / edit a profile with a structured form (text inputs, enum dropdowns, and add/remove chips for list fields). The OS identifier is fixed once a profile exists.
• Create from scratch a brand-new profile.
• Export a single profile or all profiles as JSON or YAML.
• Review history — every change is versioned. View a diff between revisions and restore an earlier one.

Cross-vendor mapping compare

When one model is mapped for several vendors, the model's Test tab has a Compare Vendors view that runs each mapping against a device and diffs the parsed fields side by side, so you can confirm the different platforms land under the same field names and values.

Each field is classified and colour-coded so you can tell a real problem from a harmless difference:

• Consistent — the same values on every vendor. Nothing to do.
• To review (soft) — a difference that is usually cosmetic: case- or whitespace-only mismatches, a sampling gap (the vendors share the same value vocabulary, one simply observed fewer values in this sample — no normalisation needed), or a possible unit mismatch. When numeric values differ by roughly 1000× or more across vendors, the field is flagged Check units (for example kbps vs bps) as an advisory — it is never auto-changed.
• Divergent (hard) — the vendors use genuinely different value vocabularies (or an integer-vs-text type mismatch). These are the ones that call for value transforms to normalise.
• Missing — the field is absent on one vendor (often because that value is the row key rather than a leaf).

Each vendor column shows its first few distinct values with a record count (×N) and how many devices/records it came from, so you can see how much data each observation is based on rather than a single sample. Where a vendor returns multiple records, a field expands into a per-record sub-table keyed by the real row identifier (for example the interface name), including keys that live only in a gNMI path.

Safe auto-fix

An Auto-fix safe issues button applies only the lossless field transforms — lowercase, uppercase, trim whitespace — for case- and whitespace-only mismatches. It never collapses distinct values, so real divergences are left untouched for you to review deliberately.

For those, the per-field fix panel suggests value transforms, but with a guard: a suggestion that would merge two values a vendor actually emits — losing a real state — is flagged as destructive and requires explicit confirmation before it is applied. This replaces the old blanket "normalise all" action, which could silently collapse distinct states into one.

REST API

Vendor profiles have a full REST API under /api/v1/vendor-profiles, covering CRUD, import/export, and revision history (list, diff, restore). See the API reference for details.