Equipment asset code or report verification link?

You are beside a hired excavator with an asset label. You also have a condition report containing a verification link. Before using either, name the task: open the asset record or check the report record. In AuditIt, those are separate actions. An asset lookup is not a report verification result, and neither action decides whether the machine is safe or who caused a change.

This guide is about choosing a record-navigation task during an equipment handover. It is not an inspection procedure. The label examples and checklist below are suggestions you can adapt, not required AuditIt fields.

Use the asset code to find the asset record

AuditIt's Scan asset page looks up a code within the active organization and opens the associated asset page. The web page describes this as opening the asset without starting an audit. Asset-record access requires sign-in; it is a separate task from the public report check.

Once the record opens, match the displayed asset reference to the item you intend to record. That is a suggested check for the person doing the job, not a claim that scanning has independently established the physical machine's identity. If the reference does not match, pause and ask the person responsible for the asset records to check the label and assignment.

The mobile asset hub can offer Continue audit for an open audit and Start audit when the current result, role and asset state allow it. Archived assets cannot start new audits. An available action describes work you can do in the record; it is not an operating clearance for the equipment.

For the subsequent condition record, the equipment checkout and return guide explains the two-stage workflow. Finding the asset and recording its condition are separate parts of the job.

Use the report link to read the report check

A report verification link answers a different question: does the report's named integrity information match the AuditIt verification record? The Valid statement names the signed manifest, report hash, PDF hash record, signature/refusal records, and persisted evidence hash metadata.

The default public view does not re-read stored PDF or original-media bytes. A separate deep-verification result must be shown before describing a stored file as having been re-read and matched at the time shown. The public report verification guide explains the individual results.

Read the result for the report you intended to check. A matching record is not a finding that every submitted observation is correct, that the equipment is safe, or that one person is responsible. Those conclusions remain outside the record check.

Name the destination beside the code

For web links, W3C's Link Purpose guidance explains how descriptive text or associated context helps a reader understand what a link is for. This is web-content guidance. The following physical-label suggestion is an editorial application of that idea, not a W3C rule for rental equipment labels or an accessibility certification.

Instead of giving both codes the same instruction, such as “Scan here,” name what each opens. Suggested wording for a clearly fictional compact excavator is:

• Asset label: “Open asset record — DEMO-48.”
• Report label: “Check report record — DEMO-RETURN-A.”

The asset and report references are invented. They do not represent a customer, a real incident or a live code. The suggestions describe two tasks; they are not screenshots of built-in labels. No real QR pattern or access link is needed to explain the distinction.

An asset-record instruction should not promise that the equipment has been “verified.” A report-check instruction should identify the report task rather than imply approval to use the machine. In AuditIt's public vocabulary, asset-code scanning and report verification have separate names.

A code correction does not rewrite earlier audits

Suppose the fictional DEMO-48 label opens a record with a different asset reference. Keep the mismatch visible to the record owner before proceeding. Do not treat a later corrected lookup as evidence that an earlier observation was recorded against the right machine.

AuditIt's Correct code assignment warning says the correction changes future scans only. Existing audits remain linked to their original asset. Correcting the code's destination therefore is not a procedure for repairing those earlier audits.

If an earlier condition record also needs attention, review it as a separate record issue. The condition-record correction guide provides the broader context. This article does not instruct you to rewrite, replace or void a particular audit.

Keep the next decision visible

Use these suggested questions before continuing:

• What task is named: opening an asset record or checking a report?
• Does the displayed reference match the asset or report you intended?
• Are you selecting an audit action, or reading a report result?
• If something is missing or mismatched, who should review it next?
• Which condition or operating questions remain outside this action?

For a condition record in AuditIt, the equipment checkout-and-return starter uses before_after for two stages. The equipment damage-report starter uses record_only for a single issue without a second comparison stage. Choose the record shape for the job; a code lookup does not turn either into a safety assessment. Templates are not a universal inspection checklist.

AuditIt creates tamper-evident, human-review-ready records. It is not legal certification and does not determine liability. If these record tasks fit your work, get started with AuditIt. Keep the asset lookup, the condition observation and the report check distinct in your team's instructions.

• equipment rental
• asset codes
• report verification
• condition records