Vista Platform 5.0.0 — full list of changes¶

Covers 5.0.0 through its release candidates. The release summary — highlights, what to do before installing, what each edition includes, and how to verify the signatures — is in CHANGELOG.md. This page is the complete, per-change record behind it.

5.0.0 is the DCIM release and a fresh install: there is no upgrade path from 4.x. It adds the DCIM object model (sites, racks, device types, interfaces, IPAM, cables, circuits, virtualisation, VPN and wireless) on a re-baselined database schema. Removed routes and renamed concepts are listed under Removed and Changed below.

Entries are grouped by kind, as they were recorded while the release was built.

Changed¶

Tenant navigation now treats DCIM as the Infrastructure workspace. The former Inventory section is grouped by Assets, Facilities, Network & Connectivity, Compute, Organization, Catalog & Data, Cryptography, and Lifecycle. Operational records and catalogs move out of Settings; Scopes and Audit Log move to Risk & Compliance, and notification delivery history moves to Remediation. Existing /settings/* bookmarks redirect to the new routes.
Settings → Locations is replaced by Settings → Sites (row 2.1). A location is now a place inside one site; the 4.x location types (region, country, data centre, cloud region, office, site, colo, building, floor, rack) are gone. An asset's free-text site is replaced by its Site; an import's site name is matched to the site of that name or creates it. The /api/v2/inventory-service/locations routes are removed (use /dcim/locations and /dcim/sites), and the operational summaries are per site: /operational/sites-summary, /operational/sites/{id}/environments[/{env}/assets] replace the /operational/locations… routes.
The database schema is re-baselined for 5.0.0 (asset-inventory ADR-0010 D11). scripts/database/schema.sql carries every object's final shape in its one definition: each later ADD COLUMN folded into its CREATE TABLE, each enum ADD VALUE into its CREATE TYPE, every RLS policy defined once, and the 4.x data backfills, retired-object drops and the whole POST-MIGRATIONS tail removed (25,789 lines to 22,519). A fresh install builds a database identical to 4.6's, proved by a normalised pg_dump diff (scripts/database/tools/schema-normalised-dump.sh). Applying the 5.0 schema over a 4.x database is not supported. The unused POST /api/v2/inventory-service/network-segments/migrate-from-spaces route is removed.
Cloud networks are prefixes, not assets (5.0.0 DCIM build, row 1.5f; asset-inventory ADR-0009 amendment). A cloud discovery no longer creates Virtual network or Subnet assets: an AWS VPC, Azure VNet or GCP network and its subnets appear in Inventory → Networks as prefixes, each naming the network it belongs to, and an instance's network is the prefix its address falls in. The two classes are removed from the class taxonomy, the contains edges from a VPC to its subnets and instances are no longer written, and the cloud.vpc_id / cloud.subnet_id facts are retired (rows already stored are unchanged). A cloud resource imported as a finding is no longer placed in a per-VPC network segment; it is placed in its region's location.
SNMP devices no longer get a net.interfaces fact either (row 1.5d): the SNMP collector's interface list is stored as interfaces and addresses (see Added). Facts it wrote before are unchanged.
Hosts no longer get a net.interfaces fact. The device agent's interface list is stored as the host's interfaces and IP addresses instead (see Added); the fact key is marked retired in the fact registry, which gains a status: retired state with a required reason. Facts other collectors already wrote are unchanged, and a query on fact.net.interfaces still parses. Since row 1.5b the same holds for everything a UniFi controller reports: its devices' and clients' interface lists and the site's networks are stored as interfaces, IP addresses, prefixes and VLANs, and no UniFi net.interfaces or net.vlans fact is stored. UniFi ports are now named by number (Port 3), not by the label set in UniFi. A UniFi controller reached at an IP address that is none of the site's UniFi gateway's is no longer made the gateway of the site's networks.
Palo Alto, Cisco, FortiGate and F5 BIG-IP no longer get net.interfaces / net.vlans facts, and no longer teach network segments. Their interfaces, addresses, connected prefixes and VLANs are stored as objects instead (see Added). Interrogations of these devices no longer create network segments or claim the device as a segment's gateway; the prefixes they record take that role as segments retire (row 1.6). Until then, a finding at a public address no registered segment covers lands on the interrogated device rather than as a separate asset.
A network segment's auto-approve covers sensor discoveries only. The segment editor's "Cloud discoveries" source never took effect (the cloud intake did not evaluate rules) and is removed; a rule that scopes on a segment and names the cloud source is refused. Cloud resources are auto-approved per account (see Added).

Added¶

Inventory → Cabling, the asset faceplate, Connect, the bulk cable editor, cable tracing and the port crypto overlay (5.0.0 DCIM build, row 3.4). Every cable in one lens with both ends as asset:port, type, status (proposed cables from LLDP show as "Proposed"), length, colour, site and rack; a row opens the cable drawer. The asset page's Ports tab draws the device's ports as a faceplate in the device type's template order; a port opens Connect (site › rack › asset › port, or a circuit end, with incompatible pairs explained inline), Disconnect and Trace, a hop-by-hop diagram through patch panels and circuits with the far end highlighted and "Copy as text". "Edit cables as table" takes rows pasted from a spreadsheet and applies them one by one with a result per row. The crypto overlay tints each port by the weakest cipher or protocol version measured behind it (GET /dcim/assets/{id}/interface-posture).
Cables, terminations and cable paths (5.0.0 DCIM build, row 3.2; asset-inventory ADR-0010 D6). A cable joins two component ends (interface, console, front/rear port, power, circuit termination); the compatibility matrix refuses impossible pairs; paths are materialised through patch panels so /{kind}/{id}/trace answers from either end. A far end that is not yet in the inventory is an unresolved termination, never an invented object. The Interfaces and Ports tabs gain a Cable column with Connect and Disconnect.
Console ports, console server ports, front and rear ports, device bays, power ports and outlets (5.0.0 DCIM build, row 3.1). Instantiated from the device type's templates; front ports map to rear ports by position; the asset page gains a Ports tab.
Modules, module bays, inventory items and virtual chassis (5.0.0 DCIM build, row 2.4). Applying a device type creates its module bays; installing a module type creates the module's interfaces and ports with {module} resolved to the bay position, adopting any port a collector already measured; removing a module deletes only what it created and carries no measured data. SNMP (entPhysicalTable) and Cisco (show inventory, show switch) report inventory items, modules and stack membership; a person's values are never overwritten. The asset page gains a Hardware tab; Settings → Module Types.
Inventory → Racks and rack elevations (5.0.0 DCIM build, row 2.5). Racks of every site with their utilisation; the rack page draws the front and rear elevation, places devices by drag (the overlap rule is enforced server-side), and tints each device by its crypto posture using the shared rating bands.
Circuits (5.0.0 DCIM build, row 4.1; NetBox circuits/*). Providers, provider accounts and networks, circuit types, circuits and their A/Z terminations on a site or an interface; Inventory → Circuits lens; Settings → Circuit Providers.
Virtualisation (row 4.2). Cluster types and groups, clusters with their hosts, virtual machines as assets, virtual disks; Inventory → Clusters lens; Settings → Cluster Types & Groups; the asset page's Virtualization card.
VPN tunnels and IKE/IPsec policy (row 4.3). Tunnel groups, tunnels and terminations, IKE and IPsec proposals, policies and profiles, L2VPNs; every algorithm in a proposal is scored through the algorithm catalogue, so a weak IKE group or hash is a crypto finding like any other. Inventory → Tunnels lens; Settings → VPN Policies.
Wireless LANs and links (row 4.4). WLAN groups, WLANs with their authentication type and cipher scored through the catalogue, point-to-point wireless links. Settings → Wireless.
Cloud as DCIM (row 4.6; asset-inventory ADR-0009). One enumeration per account with a per-region outcome; a resource that disappears is a lifecycle event, not a deletion; Tier-1 classes and collectors across AWS, Azure and GCP with security groups as assets; Inventory → Cloud lens faceted by class, provider, account and region; cloud accounts, regions and VPCs in the Placement and topology hierarchy.
Custom fields (row 5.1). Tenant-defined fields on assets, interfaces, prefixes, VLANs, circuits and the other DCIM objects, validated on every write, queryable as cf.<name>; Settings → Custom Fields; a Custom Fields panel on each object.
Inventory → Changes (row 5.2). The substrate's change record as a lens: per-object diffs, related-object changes, retention; a Changes tab on every DCIM object.
Config contexts (row 5.3). Weighted JSON contexts assigned by site, role, platform, business unit or tag, merged and rendered per asset; Settings → Config Contexts.
Saved filters per object kind (row 5.4) and export templates (row 5.5) — text formats (a hosts file, a config snippet, an XML feed) rendered from any object list; Settings → Export Templates.
NetBox sync for circuits, virtualisation, VPN and wireless (Enterprise; row 4.5). Twenty-two further NetBox object kinds sync both ways on the same engine as Business Units, IPAM and interfaces, each class behind its own switch (off by default on existing connections). Pre-shared keys are reduced to a "key is set" flag on read and never pushed. Virtual machines, VM interfaces and virtual disks are not yet synced.
Device42 import (Enterprise; row 5.6). Settings → Integrations → Device42 (import): customers, buildings, rooms, racks, hardware models, devices with their rack position, ports, cables, subnets, IPs, VLANs and circuits, planned in a dry run per class and applied in dependency order; a cable whose far end is not imported parks as an unresolved termination.
Sites, regions, site groups and locations (5.0.0 DCIM build, row 2.1; asset-inventory ADR-0010 D4). Settings → Sites builds the Region › Site group › Site › Location tree (create, edit with each object's Changes and Journal, delete; a site holding assets is deleted only by choosing where its assets go). An asset has a Site and a Location inside it, chosen on the asset form (the location list is the site's) and shown under the asset's name as Site › Location. Inventory → Sites lists the sites; each opens a site page with its address, time zone, counts, locations, findings by environment and change log. A connected cloud account gets a site of its own, its regions become locations of it, and its networks are scoped to their region. New query fields site, site.id, site.group, site.region and location; the Site facet shows site names. API: /api/v2/inventory-service/dcim/{regions,site-groups,sites,locations} (dcim.read / dcim.manage). Bulk CSV import and export gain a Sites kind, and the Locations kind now names each location's site and its path inside it (and needs dcim.manage).
Contacts, contact roles and image attachments (5.0.0 DCIM build, row 2.8). Contacts (a person or a team, optionally grouped under another contact), contact roles (owner, technical, billing, on-call and NOC built in) and assignments of a contact in a role to any object, under /api/v2/inventory-service/dcim/{contacts,contact-roles,contact-assignments} and /dcim/objects/{kind}/{id}/contacts. Image attachments on any object: multipart upload (PNG, JPEG, WebP or SVG, at most 5 MB, type decided from the bytes, scripted SVG refused), kept in object storage (dcim_images, or the service's local disk until enabled) and served through the API; a device type's front and rear image are set by uploading with slot=front|rear. Settings -> Infrastructure -> Contacts manages contacts and roles; the asset Overview has Contacts and Images sections. See docsv4/core/inventory/contacts.md.
Bulk CSV import and export (5.0.0 DCIM build, row 2.7). Settings -> Infrastructure -> Import takes a CSV for one object kind (business units, sites, locations, manufacturers, device roles, platforms, device types, assets, interfaces, RIRs, aggregates, VRFs, VLAN groups, VLANs, prefixes, IP ranges, IP addresses), shows every row as create / update / unchanged / error with the reason, and applies it on your confirmation. The template download gives the header and an example row. Export buttons on the Networks and VLANs lenses and Business Units download the rows you are looking at; an export re-imports to no change. Needs the permission to edit the kind. See docsv4/core/inventory/import-export.md.
Device catalogue: manufacturers, device types, module types, device roles, platforms (5.0.0 DCIM build, row 2.2; asset-inventory ADR-0010 D4). NetBox-shaped catalogue tables with their nine component-template kinds (interface, console, console server, front and rear port, module bay, device bay, power port, power outlet), under /api/v2/inventory-service/dcim/{manufacturers,device-types,module-types,device-roles,platforms} and /dcim/device-types/{id}/<kind>-templates. Platform rows are readable by every tenant and refused on write (403 read_only); a tenant adds its own. One device role is seeded per hardware and virtual asset class. An asset gains a device type, device role, platform (OS), serial and asset tag (/dcim/assets/{id}/hardware); POST /dcim/assets/{id}/device-type assigns a type and creates its interfaces, merging by name with the interfaces collectors already measured (never duplicating them, never overwriting a measured MAC, speed or status). The query language gains device_type, device_type.manufacturer, device_role, platform, serial and asset_tag. The hardware classes' asset_tag attribute is now the asset_tag column.
Racks, rack reservations and rack placement (5.0.0 DCIM build, row 2.3; asset-inventory ADR-0010 D4). Settings → Racks lists each site's racks with their location, role, status, utilisation and device count; a rack is created or edited there (an optional rack type supplies its height, numbering and width), its Reservations tab reserves units for someone, and deleting a rack takes its devices out of it. The asset page's Placement card shows Site › Location › Rack › U · Face and places an asset in a rack (site, location and rack selects, a half-unit position, front or rear). A device spans its device type's height (1U without one), a full-depth device takes both faces, and a placement or reservation over units a device or reservation already holds is refused, naming what is in the way — two people placing into the same units at once cannot both succeed. Five rack roles are seeded (compute, network, storage, patching, power). The site page counts racks, the asset CSV export gains Site, Location, Rack, U and Face columns, and the query language gains rack, rack.id, rack.site, rack.role, position and face. API: /api/v2/inventory-service/dcim/{rack-roles,rack-types,racks,rack-reservations}, /dcim/racks/{id}/elevation and /dcim/assets/{id}/placement (dcim.read / dcim.manage).
A seeded device-type catalogue and a library import (row 2.2). Every install now carries 154 device types from the NetBox community device-type library (CC0-1.0) — Cisco Catalyst 9200/9300/9500 and Nexus 9300, Arista 7050/7280, Juniper EX4300/EX4400/QFX5120/SRX, FortiGate 60F–600F, Palo Alto PA-220–PA-3400, F5 BIG-IP i-series, Ubiquiti UniFi, Dell PowerEdge, HPE ProLiant, Supermicro and APC PDUs — with their interface, console, power and port templates, and the OUI registry's vendors as manufacturers. POST /dcim/device-types/import takes library YAML (one or many documents) and creates the tenant's own types for anything the catalogue lacks. tools/devicetype-import regenerates the subset from a library checkout.
Settings → Device Types, Manufacturers, Device Roles and Platforms (OS), and an asset's Hardware (row 2.2). Browse the device catalogue by manufacturer and search, open a type to see its interfaces and ports, import types from the device-type library by pasting or uploading their YAML, and create your own. The asset form gains Device type, Device role, Platform (OS), Serial and Asset tag; the asset page's Hardware card shows them and Apply templates creates the type's interfaces, merged with the ones discovery measured. See docsv4/core/inventory/device-types.md.
Network devices report their interfaces, addresses, prefixes and VLANs (5.0.0 DCIM build, row 1.5c; asset-inventory ADR-0010 D3). Interrogating a Palo Alto, Cisco (IOS / IOS-XE / IOS-XR / NX-OS / ASA), FortiGate or F5 BIG-IP now fills the device's Interfaces tab: ports with their type from the media they report, state, MTU and speed; switch ports in access or trunk mode with their VLANs; port-channels, aggregates and trunks with their member ports; sub-interfaces and VLAN interfaces under their parent; each address with its length, in the VRF of a non-default virtual router, VDOM or route domain. The device's connected prefixes and VLANs appear in Inventory → Networks, and the device's record address is its primary IP. Cisco collection adds show interfaces status and show interfaces trunk; FortiGate adds monitor/network/arp; F5 adds net/trunk, net/route-domain and net/arp and reads VLAN members. Their ARP tables follow the SNMP rule: an address already in the inventory gains the MAC it answered with, an unknown one is kept aside for 30 days, and nothing is created. A device's own serial and interface-MAC updates no longer move one of its addresses to another of its interfaces.
Cloud instances, NetBox devices, spreadsheet rows and hand-added devices carry their interfaces (5.0.0 DCIM build, row 1.5f; asset-inventory ADR-0010 D3). A cloud discovery records each EC2 instance's ENIs (and each Azure VM's and GCE instance's network interfaces) as interfaces on its Interfaces tab with their private addresses at their subnet's prefix length, and an ENI's public address as the instance's NAT outside addresses. A NetBox import declares each device's interfaces and their active addresses, linked to their NetBox records for the sync. The spreadsheet import takes optional Interface, Prefix length and VLAN columns beside the IP and MAC columns, shows each row's interface in the preview and offers a template CSV; and Discovery → Devices → Add device takes the MAC and interface the address is on when a device is added by hand. An interface with no name is named by the platform.
Sensors report interfaces and addresses (5.0.0 DCIM build, row 1.5e; asset-inventory ADR-0010 D3). A sensor's own host now shows its real interfaces by name on its Interfaces tab, each with its MAC and addresses with their prefix length, and the interface the sensor captures on is named in the asset's discovery details. A device the sensor (or an uploaded PCAP) only watched keeps its MAC and address on one observed-1 interface, and each address now records how it was last seen — DHCP for a lease, ARP, or Passive. A DHCP acknowledgement's subnet mask becomes a DHCP-managed network in Inventory → Networks, pending approval.
NetBox bidirectional sync for Business Units, IPAM and Interfaces (Enterprise; 5.0.0 DCIM build, row 1.9; asset-inventory ADR-0010 D7). A NetBox connection can now sync Business Units, RIRs, prefix roles, VRFs, route targets, aggregates, ASNs, VLAN groups, VLANs, prefixes, IP ranges, FHRP groups, IP addresses and interfaces in both directions, field by field: Settings → Integrations → NetBox → Sync shows the last plan per object kind, runs a dry run or applies, edits who wins each field (observed here, declared here, NetBox, merge, newest change) and the schedule. Two sides that disagree inside their authority become a conflict in Discovery → Approvals (keep ours, take NetBox's, ignore until changed); a delete on either side is only ever a proposal. Objects keep a stable round trip through a hidden vista_id custom field the sync creates in NetBox. Diode push is a setting that is not built yet. The import and Drift stay read-only.
The device agent reports each host's interfaces (5.0.0 DCIM build, row 1.5a; asset-inventory ADR-0010 D3). A host with the device agent now shows its real network interfaces on its Interfaces tab — name, MAC, addresses with their prefix length, MTU, link speed (Windows) and up/down state — with a VLAN sub-interface (bond0.100) under its parent carrying its VLAN, and a bond's member NICs under the bond. Container, loopback and tunnel interfaces are left out. The address the agent reports for itself is the host's primary IP. Linux collection now runs ip -d -j addr (adds each link's kind and VLAN id). This is the first of the intake changes that make every discovery source write interfaces and IP addresses; network devices, SNMP, the sensor and cloud follow.
UniFi interrogation records interfaces, VLANs, prefixes and client addresses (5.0.0 DCIM build, row 1.5b). Interrogating a UniFi controller now fills in, on each managed device's own asset, its Interfaces: a switch's ports (Port N, typed from the medium, with speed, state and access/trunk VLANs) and link aggregations (LAG N), an access point's radios (one wireless interface per SSID, typed by band, with its BSSID) and the gateway's bridge interfaces with its address on each network and its WAN address. The site's networks become prefixes (with VLAN, DHCP and purpose) and VLANs in Inventory → Networks, and each client's MAC and address land on the client's own asset. Each device's management address is its primary IP. SSID passphrases, port authentication keys and WAN credentials are never kept.
Generic SNMP devices report their interfaces, addresses and VLANs (5.0.0 DCIM build, row 1.5d; asset-inventory ADR-0010 D3). A switch, router or appliance interrogated over SNMP now shows every port and virtual interface on its Interfaces tab: name in the vendor's long form, type (from IF-MIB ifType and speed; a LAG is lag, a VLAN or loopback interface virtual), MAC, MTU, speed, administrative and operational state, the addresses on it with prefix length and static/leased origin, the LAG a port belongs to, a sub-interface's parent, and — where the device answers the Q-BRIDGE tables — each port's native and trunked VLANs and the VLANs themselves. The device's management address becomes its primary IP. The ARP cache is supporting evidence only: an address another asset holds gains its MAC, an unknown one is parked until a device with that MAC appears, and ARP never creates an asset. The community string is removed from anything the device echoes back (sysDescr, contact, location) and a port's free-text description is not collected.
Discovered addresses live on interfaces (5.0.0 DCIM build, row 1.4; asset-inventory ADR-0010 D3). Identification now reads an asset's addresses from its interfaces and IPAM: every address discovery reports is an IP address on one of the asset's interfaces (shown on the asset's Interfaces tab and in Inventory → Networks), and a MAC on any of an asset's interfaces — including a further MAC added by hand — identifies it. A value whose source named no interface lands on an observed-1-style interface that is renamed when the device reports the real name. Each asset gets a primary IPv4/IPv6 address by rule, and a service's endpoint links its IP address. Address scoping and the DHCP rule follow IPAM prefixes (DHCP managed on a prefix) before network segments; auto-approval rules and probe consent can scope on a prefix (network.prefix_id, read before segment rules), and a prefix marked sensitive or active-probes-disabled is never probed automatically. Merge proposals in Discovery → Approvals name the interface a matching MAC or address is on. Searching by IP (ip.address:, id.ip_address:, free text) finds interface addresses.
MCP read tools for interfaces, IPAM and Business Units (5.0.0 DCIM build, row 1.10). An AI assistant connected through the MCP server (now 32 tools) can list interfaces across your assets or for one asset (find which asset owns a MAC address), browse prefixes with their utilisation and free space, list IP addresses and VLANs, ask "what holds 10.1.2.3?", list Business Units, and read the recorded change history of any one object. All read-only; the platform applies your own DCIM and IPAM permissions to every call. The interface operations in the inventory-service OpenAPI document now declare 401, and the assigned_kind and scope_kind filters declare their values.
Interfaces (5.0.0 DCIM build, row 1.2; asset-inventory ADR-0010 D3). An asset now has Interfaces — one list for physical and virtual interfaces alike: name, type (the NetBox interface-type list), enabled, management-only, MAC addresses, speed, duplex, MTU, 802.1Q mode with untagged and tagged VLANs, LAG membership, parent and bridge. Open an asset → Interfaces tab to add, edit and delete them; LAG, parent and VLAN-mode rules are enforced (a LAG member must point at a LAG on the same asset; tagged needs tagged VLANs; tagged-all takes none). Names from different sources (Gi1/0/24, GigabitEthernet1/0/24) fold to one interface. API: /api/v2/inventory-service/dcim/interfaces (dcim.read / dcim.manage), filterable by asset, name, type, MAC, LAG and VLAN. Search the inventory by interface with interface:( … ), e.g. interface:(mac_address:"00:11:22:33:44:55"). Discovery populates them through the intake rows (the device agent first, see above).
Inventory → Networks and VLANs, and Settings → IPAM (5.0.0 DCIM build, row 1.3, part 3). Networks shows one VRF's prefixes as a tree with utilisation, status, role, VLAN and counts; a prefix's panel lists its child prefixes, free prefixes and addresses, IP ranges, IP addresses and the asset holding each, with its change log and journal, and pending discovered prefixes and addresses can be approved there. Find says which prefix, address and asset hold an address in every VRF. VLANs lists VLAN groups and VLANs with the prefixes each carries. Settings → Infrastructure → IPAM maintains VRFs, aggregates, RIRs, prefix roles and ASNs. The inventory query language gains ip., prefix., vlan. and vrf. fields (ip.address:10.10.0.0/24, vlan.vid=10). See docsv4/core/inventory/networks.md.
IPAM API (5.0.0 DCIM build, row 1.3, part 2). /api/v2/inventory-service/ipam/ serves list, create, edit and delete for RIRs, aggregates, VRFs, route targets, prefix roles, prefixes, IP ranges, IP addresses, VLAN groups, VLANs, FHRP groups and their assignments, and ASNs (reads need ipam.read, writes ipam.manage; every write is in the change log). A prefix's page carries its parent, depth, direct children, utilisation and the free prefixes and addresses inside it; /ipam/prefixes/tree returns a VRF's prefix tree and /ipam/find?address= says which prefix, address and asset hold an address in each VRF. Addresses are unique within a VRF that enforces it, except anycast and virtual-IP roles. The Networks and VLANs pages that use it follow.
IPAM tables and address arithmetic (5.0.0 DCIM build, row 1.3, part 1). The schema gains RIRs, aggregates, VRFs and route targets, prefix roles, prefixes, IP ranges, IP addresses, VLAN groups and VLANs, FHRP groups and ASNs (NetBox 4.x-shaped, tenant-isolated by row-level security), a per-prefix utilisation cache, and primary_ip4_id, primary_ip6_id, oob_ip_id on assets and ip_address_id on endpoints. RIRs and prefix roles are seeded. shared/dcim/ipam computes containment, the prefix tree, available prefixes and addresses, utilisation and longest match within a VRF, following NetBox's rules. Nothing writes the tables yet; the API and the Networks and VLANs lenses follow.
Business Units (5.0.0 DCIM build, row 1.1; asset-inventory ADR-0010 D2). Assets now point at a Business Unit (a NetBox tenant) instead of carrying free text. Settings -> Organization -> Business Units manages a tree of units (four levels deep), with delete-and-reassign; the asset form, bulk edit and imports assign them; the Inventory facet shows unit names. business_unit in the query language is now object-valued (business_unit.id, and business_unit.parent to include every descendant). A NetBox import maps each device's tenant onto a unit. API: /api/v2/inventory-service/dcim/business-units; assets.business_unit and network_segments.business_unit became business_unit_id, and the asset's business_unit is now {id, name, slug}.
Internal: DCIM scale fixture (shared/testdb/dcimfixture, BUILD_PLAN row 0.7): a deterministic, phase-aware generator for DATA_MODEL §12's tenant, a budget helper, and make test-dcim-scale; test infrastructure only.
The cloud account is an asset, and cloud resources are auto-approved per account (5.0.0 DCIM build, row 0.5; asset-inventory ADR-0009 D1, D5). Adding a cloud integration declares its AWS account, Azure subscription or GCP project as an approved Cloud Account asset; every resource any cloud collector records hangs off it with a hosted_on relationship, so the account's Relationships tab lists what it hosts and the map draws the stored edge instead of a synthetic account box. Each integration's Auto-approve resources switch (Discovery → Cloud, on by default) approves the resources discovered in its account through the same auto-approval rules as everything else (source:cloud and cloud.account_id="…", a new observation field). The integration card shows the account, the switch and the last run's per-type outcomes. Contested identities still go to Approvals as merge proposals, and removing an integration keeps the account asset.
Interface, port and cable type registries (5.0.0 DCIM build, row 0.4). standards/interface-types.yaml and standards/cable-types.yaml hold the interface, console, front/rear port, power port/outlet, cable and wireless-channel choice lists (taken from NetBox v4.3.5) and the cable termination compatibility matrix. make generate emits them as Go constants (shared/dcim), TypeScript unions (@vistasecurity/primitives/dcim) and the InterfaceType, CableType, PortType and ConsolePortType OpenAPI enums; make audit fails on drift. Nothing reads them yet; the interface and cable pages that offer these choices ship later in the 5.0.0 build.
A product vocabulary registry and guard (5.0.0 DCIM build, row 0.1). standards/vocabulary.yaml is now enforced: make generate emits the ObjectKind enum for Go (shared/dcim), TypeScript (@vistasecurity/primitives/dcim) and the inventory-service OpenAPI contract, plus a customer glossary at docsv4/core/concepts/vocabulary.md; make audit fails on generated-file drift, on a retired synonym in UI strings, OpenAPI names, schema identifiers or customer docs, and on a table that carries the object substrate with no registry row. Retired words are enforced phase by phase (after_phase), so the guard is green on today's wording.
Permissions for the 5.0.0 infrastructure-mapping programme. The tenant permission catalogue gains dcim, ipam, circuits, virtualization, vpn and wireless (each read · manage) plus business_units.manage and custom_fields.manage. Tenant Administrators and Security Administrators hold the six families in full, Viewers hold read, and the last two are Tenant Administrator only. No route uses them yet; they ship ahead of the pages that will, and the inventory-service gateway prefix already covers the new route groups.
A change log, journal and tags for every infrastructure object (5.0.0 DCIM build, row 0.3). The asset page gains a Changes tab — the change log (who changed what, from where, which fields) and a journal of dated notes — and a tag editor under the asset's name backed by one organisation-wide tag list. Underneath, every DCIM object shares the same substrate: object_changes (monthly partitions kept ahead and expired by audit-service's partition job, following the audit retention policy), journal_entries, tags / object_tags, image_attachments and unresolved_terminations, all tenant-isolated. Changes are recorded by the service that makes them, with the person and the request id, and secret-named fields are redacted from the before/after images. Reading needs dcim.read; writing needs dcim.manage.

Removed¶

Network segments are retired; the tenant's networks are prefixes (5.0.0 DCIM build, row 1.6). The network_segments and network_spaces tables, the /network-segments routes (list, create, bulk, edit, delete, claim) and Settings → Network Segments are gone. A network is an IPAM prefix in Inventory → Networks, which now carries what a segment did: network type, environment, DHCP posture (three-valued: yes, no, unknown), auto-approval of sensor discoveries, active-scan exclusion, the sensitive flag, its gateway, the sensor that reaches it, the FHRP groups (VRRP, HSRP, …) whose virtual address is in it, and Claim as ours on a prefix learned from a device. Auto-approval rules, scan consent, Discover Assets targets, automatic scans, DHCP-lease rules, gateway links, asset placement (prefix_id replaces network_segment_id), the map, the topology tree, the inventory facet (prefix) and the spreadsheet import all read prefixes. A bookmark to /settings/segments lands on Inventory → Networks. Domain and IP-range segments have no successor: a name scopes to the tenant. Two cloud networks with the same CIDR are two prefixes, told apart by the network they belong to. A device's own sighting records the prefixes it reports before its addresses are scoped, so under enforced identity admission a switch, firewall or controller admits itself and its neighbours on the networks it teaches. The internal source-import route is /internal/sources/prefixes, and NetBox run summaries count prefixes_created / prefixes_matched / prefixes_skipped_duplicate.

Fixed¶

FortiGate discovery accepts the credential FortiOS actually supports. Add Device now asks for a read-only FortiGate REST API token and sends it as a bearer token, whether the platform connects directly or a device agent does. Identity is read from the current monitor/system/status endpoint, with the older CMDB endpoint retained for compatible appliances.
HBOM no longer labels an unclassified address as hardware without hardware evidence. An unknown_host appears in the HBOM only when a collector measured a hw.* fact for it; it remains visible in the full inventory. When several sources report the same fact value, the export emits that property once and keeps source-qualified duplicates only for genuine disagreement.
Deleting a DCIM object no longer strands its polymorphic references. Tags, journal entries, contacts, images, L2VPN/tunnel terminations and parked terminations are swept when their object is gone; dangling scopes and assignments on prefixes, VLAN groups, clusters, addresses, inventory items and circuit terminations are cleared. The sweep is tenant-scoped, idempotent and runs daily. power_feed and power_panel, which had no backing tables, are no longer advertised as object kinds until power infrastructure ships.
The admin console's update check and one-click update work against a chart mirror signed by a private CA. maintenance-service's registry client, its cosign verify and the update Job's helm upgrade all used the image's public trust store, so an internal registry (Harbor behind an organisation CA, an air-gapped mirror) failed every one of them with x509: certificate signed by unknown authority. The service now honours EXTRA_TRUSTED_CA_PATH — the variable monitoring-service already reads for its synthetic checks — by adding the CA to the public store (never replacing it), passing a combined bundle to cosign as SSL_CERT_FILE, and the chart renders backends.maintenance-service's extraEnv / extraVolumes / extraVolumeMounts into the update Job as well, whose script exports the same bundle before helm runs. Documented under "Signature verification, mirrors and credentials" in the maintenance guide.
Backups and the one-click update work in the commercial (obfuscated) maintenance-service image. The build obfuscated the Kubernetes client libraries too, which register their API types by reflected name, so every backup or update Job the service tried to create failed with no kind "…" is registered for version "batch/v1" (the Core image, which is not obfuscated, was unaffected). Obfuscation is now scoped to Vista Platform's own code for that service, and the Dockerfile guard refuses a Kubernetes-client consumer's release build without that scope.
The one-click update no longer fails at render time on every install. The chart's render-time validations told "no cluster" from "genuinely missing" by looking up the kube-system Namespace, a cluster-scoped read the console updater's namespace-scoped Role can never be granted, so helm upgrade from the console stopped with namespaces "kube-system" is forbidden before touching anything. The probe now reads the release namespace's own default ServiceAccount first and falls back to kube-system only when the namespace does not exist yet (a cluster administrator's first install), and the cert-manager prerequisite check runs at install only. A chart test refuses any other cluster-scoped lookup.