"Unit detail: identification, provenance, assignment, and storage"

What the Overview section shows

Open any single piece of equipment and Verinode opens a detail card for that one unit. Overview is the first pill inside that card, the plain paper trail on the unit itself: what it is, where it came from, whether it is matched to a real catalog product, who is currently holding it, and where it lives when nobody has it out. Nothing here is a benchmark or a stance call, those live in the card's other pills. Overview is the record.

Verinode does not ask you to type this information into a form from scratch. It reads purchase invoices, photos of tags and serial plates, and CSVs you forward or upload, and fills the fields in as that data lands. A handful of fields on this pill are editable directly (the storage location, the assignment, the unit photo), the rest are read-outs of what has flowed in. You correct the record when something is wrong; Verinode's job is to keep it complete and legible, never to guess at facts it does not have.

Where to find it

Equipment lives in the sidebar at /equipment. From the Equipment home, three common ways open a specific unit's card:

• Most recent, the bottom row on the home page, click any tile.
• All Equipment, the full roster tab inside the Equipment card slider, click any row.
• A decision tile in Take Action or the Findings grid that names a specific unit.

See Equipment: your fleet at a glance for the home page these entry points live on, and All Equipment tab: filters, views, and comparing units for the roster you can browse through to get here.

Once a unit's card opens, a hero sits at the top: the unit's class as an eyebrow next to a stance pill (KEEP, SERVICE, RETIRE, REPLACE, or WATCHING), the unit's name as the title, and four stats (Age, Calibration, Same-class units, Purchase). Below the hero, a row of section pills lets you move between lenses on this one unit: Overview, Specs, Performance, Maintenance, Alternatives, Findings, Related SOPs (only when Verinode has linked one), and Community (only when the unit is matched to a catalog product). Overview opens first. This article covers that pill only, the specs, performance, maintenance, alternatives, and findings pills each have their own read and their own article.

Identification

The first block, Identification, lays out what the unit actually is:

• Class, the equipment class Verinode has matched this unit to (for example "LGR Dehumidifier" or "Axial Air Mover"), or a dash if it has not been classified yet. Classification runs automatically when a unit is ingested, a deterministic matcher checks the unit's name and model number against the catalog, then falls back to keyword and category matching if nothing specific fits. Nothing here is AI guesswork, if the matcher cannot defend a specific class, the unit stays unclassified rather than being mis-labeled.
• Model #, the manufacturer's model number as extracted, or a dash if none was captured.
• Serial, the unit's serial number, or a dash.
• Quantity, how many identical units this one record represents. A single record can stand in for a batch, five identical air movers logged on one line read "Quantity: 5" here even though they are one row in your inventory. This is the same distinction the Equipment home draws between record count and summed quantity, see Equipment: your fleet at a glance for how that plays out at the fleet level.
• Ownership, one of Owned, Rented, Leased, or Financed. Ownership type matters beyond bookkeeping, it feeds the rental break-even math behind the unit's stance call on the hero and on the Alternatives pill.
• Condition, one of New, Good, Fair, Poor, Needs repair, or Retired. Overview shows condition as a read-out; the control that actually changes it (a row of clickable pills) lives on the Maintenance pill, alongside the calibration and service logs, because condition changes are usually logged in the same visit as a service or inspection.

Provenance

The second block, Provenance, is where the unit came from and its current standing:

• Purchase date, formatted as a plain date (for example "Jul 12, 2026"), or a dash if none is on file. This date drives the unit's age, and age is the single biggest input into the stance call on the hero, Verinode cannot reason about aging, calibration windows, or rental break-even without it.
• Purchase price, formatted as a dollar figure (amounts under $1,000 show the exact number, larger amounts round to the nearest tenth, "$4.3k" or "$1.2M"), or a dash if not captured.
• Vendor, the name of the vendor this unit was purchased or rented from, resolved from your vendor list, or a dash if no vendor is linked.
• Status, either Active or Retired. This field is a read-out, not a control. The actual toggle lives in the hero's action row as a Retire (or Restore, once retired) button. Retiring a unit asks first, "Retire {unit name}?", "The unit will be marked retired. Data is preserved, it just drops off your active equipment list," and confirms with a toast reading "{unit name} retired." Restoring asks "Restore {unit name}?", "The unit will rejoin your active equipment," and confirms with "{unit name} restored." A retired unit keeps its full history, it simply stops counting toward the fleet-health numbers on the Equipment home (average age, aging percentage, calibration rate) and drops out of active decision detection.

Catalog match

When a unit has been matched to a real product in Verinode's equipment catalog, a Catalog Match block appears with four fields:

• Product, the catalog product's full name.
• Manufacturer, the manufacturer behind that product.
• Base price, the catalog's reference price for that product new, or a dash if not priced.
• Verinode Score, the manufacturer's research-backed score on the same scale used across the platform (see The Verinode Score on vendors and entities), when Verinode's research has scored it. This field commonly reads as a dash today, research scoring is still expanding across the equipment catalog, and a dash here means coverage has not reached this product yet, not that the score is bad.

Catalog matching happens the same way class matching does, automatically at ingestion, by checking the unit's model number and name against the catalog with the same deterministic resolver. There is no manual "link to catalog" control on this pill today. If a unit has not matched, the whole Catalog Match block is simply absent from Overview, you will see the gap called out instead on the Specs pill, which explains that the full spec sheet appears once a catalog link exists.

Notes

If free-text notes have been captured on the unit (typically from an ingested document or set when the unit was first added), they render as a plain paragraph under a Notes heading at the bottom of Overview. When there are no notes, the entire block is omitted, there is no "no notes yet" placeholder, the section simply does not render.

Photo

The unit's photo sits beside the hero, not inside the Overview field grid, but it is part of the same record this pill documents. Click the photo to view it full-size in a lightbox (click outside the image, or press Escape, to close it). Underneath the photo, a small text link reads Add photo when none exists, or Change photo once one has been uploaded. Either way it opens your device's file picker.

A few rules on upload: the file must be an image, and it must be under 10 MB. Trying to upload something larger stops with "Photo must be under 10 MB" before it reaches the server. While the upload runs, the link reads "Uploading...". The photo replaces any existing one for this unit (there is no photo history), and the page refreshes automatically once the upload completes so you see the new photo without reloading yourself.

Assignment: who's holding this asset

Directly under Provenance, an Assigned block answers a specific operational question: is this unit sitting in your pool, or is a specific teammate currently holding it.

When the unit is assigned, you see:

• Member, the teammate's name, linked through to their own record.
• Role, that teammate's role, or a dash if none is set.
• Since, the date the assignment was made, or a dash.
• A Return to pool button. Clicking it asks you to confirm ("Return {unit name} to the pool?"), then clears the assignment. While it runs the button reads "Unassigning…". If the unassign fails, the reason appears as a small line of red text under the fields instead of a silent failure.

When the unit is not assigned, the block reads: "Not assigned to anyone, sitting in the pool. Open a teammate's panel and use + Assign equipment to issue this asset." That is a deliberate pointer, not a dead end: assigning equipment to a person happens from that teammate's own record, not from the unit's card. This unit's card only ever offers the return side of that relationship, because "who has what" is naturally organized around the person once it is time to hand something back.

Storage: property and location

Below Assignment, a Storage block answers a different question: where does this unit live when nobody has it checked out. This is deliberately separate from where a unit gets deployed on a job, Storage is about the warehouse, yard, or truck it is racked in day to day.

Two coordinated controls, both save automatically as you use them:

• Property, a dropdown of your operator's active properties (warehouses, yards, branches). This control only appears once you have at least one property on file. Picking a property writes the link and, unless you clear it, auto-fills the free-text location field below with that property's name, so list filters and search keep working without extra typing. Choosing "No property" clears the link without touching whatever you have typed in the location field. A hint underneath reads "Pick the warehouse / yard / branch this unit lives at. Manage properties at /properties." Saving shows a toast reading "Property assigned" or "Property cleared"; a failure shows "Failed to update property."
• Location (labeled "Where is this stored?" if you have no properties on file, or "Detail (rack / row / truck)" once you do), a free-text field for granularity a property record does not deserve its own row for, a specific rack, a specific truck. It autocompletes against every distinct location value already logged across your whole fleet, so you are not retyping "Tampa warehouse" a dozen times. It saves when you click away from the field or press Enter, with a toast reading "Storage location updated," or an error message if the save fails.

Best-practice example

Say a dehumidifier comes in through an ingested purchase invoice. Verinode matches it to "LGR 7000XLi" automatically, so Class, Model #, and the Catalog Match block populate on their own; Purchase date and Purchase price come straight off the invoice. You confirm Serial by hand from a photo of the tag, since serials rarely appear cleanly on an invoice. When the unit ships out on a truck, whoever is issuing it opens their own teammate record and assigns it there, so it shows up here as "Assigned to [name], since [date]." When it comes back, you click Return to pool on this card rather than hunting for it on the teammate's page. At rest, it lives on a Property you have already set up (say, your main warehouse), with Location narrowed to "Rack B-3" so the next person who needs it does not have to walk the whole floor.

Data sources

Related reading

• Equipment: your fleet at a glance
• All Equipment tab: filters, views, and comparing units
• Findings tab: equipment decisions grid
• Take Action: equipment decisions and empty states
• Inside a Vendor Card: The Detail View
• The Verinode Score on vendors and entities
• The decision workspace
• Connecting your data