Frequently asked questions

InspectAssets is an inspection operations and asset-evidence platform. It brings together asset records, inspection templates, evidence capture, coverage, unresolved limitations, corrective actions, compliance obligations, reports, decision records, and enterprise administration so teams can move from field activity to governed operational decisions in one system.

No. Inspections are a core workflow, but the platform also maintains asset evidence and history, tracks corrective work, exposes unresolved inspection uncertainty, supports compliance obligations, produces decision and audit outputs, and provides enterprise controls for organisational structure, access, and integrations.

Yes. InspectAssets supports multi-site operations and separates physical sites from legal entities and billing relationships. This allows organisations to model where assets operate, which entity owns or manages them, who pays, and which users have access to each operational scope.

The platform supports field inspectors, site and facility teams, operations managers, asset managers, reviewers and approvers, compliance teams, leadership, and authorised external reviewers. What each person can see and do is controlled by role, permission, and scope.

No. Continuous Condition Evidence is optional. InspectAssets can receive machine-condition evidence from registered devices, gateways, or approved external sources where your operation uses them, but tenants and assets without IoT continue to use the inspection platform normally and machine evidence remains Not Applicable unless an authorised policy explicitly requires it.

Templates can standardise required fields, evidence, assessment states, and review expectations while still being assigned to the appropriate sites, asset types, and operational contexts. This gives governance teams consistency without treating every inspection programme as identical.

The inspector records an explicit state such as Inaccessible, Unable to Test, Not Inspected, Pending, or Not Applicable. The relevant reason and evidence remain attached to the inspection record, so an unassessed component does not silently become 'no defect found'.

No. InspectAssets separates Asset Health, Inspection Coverage, and Evidence Confidence. Asset Health describes observed condition; Coverage shows how much of the intended scope was actually assessed; Evidence Confidence reflects how strongly the conclusion is supported. A healthy result therefore cannot hide incomplete scope.

Yes. Inspection templates can require evidence and other fields according to the workflow. The pre-submission review can expose missing mandatory evidence, unknown states, failures, and coverage gaps before the inspector submits.

It is the final review of inspection completeness before submission. It brings together inspected scope, failures, unknowns or limitations, not-applicable items, and evidence requirements so the inspector can see what remains unresolved before the record enters review.

It remains visible instead of disappearing into free-text notes. Depending on workflow and permission, reviewers can request clarification or reinspection, reject the submission, or record an accepted limitation or risk decision with the relevant context and review expectations.

Yes. The Inspection Operations and limitations view is designed to surface open uncertainty across inspections, including ownership, age, reason, and verification path, so management can see unresolved inspection scope as an operational issue in its own right.

Yes. Prior unresolved limitations remain part of the inspection context rather than being forgotten when a new inspection begins. Where verification is required, the workflow can prevent unresolved prior issues from being treated as silently cleared.

The Asset Evidence Passport brings together the asset's identity, lifecycle context, criticality, condition, inspection history, documents, limitations, compliance evidence, and decision context. It is intended to give users a durable evidence record around the asset rather than a collection of disconnected inspection files.

Decision Readiness reflects whether the available asset and inspection evidence is sufficient for the intended operational or management decision. It keeps the question of 'do we have enough reliable evidence to act?' separate from the asset's condition itself.

Yes. Asset criticality and consequence context can be used alongside condition and inspection evidence so teams can distinguish a low-impact issue from one that carries greater operational significance.

Yes. Inspection and asset history are retained so users can review previous records, evidence, findings, limitations, actions, and changes over time rather than working only from the latest form submission.

Findings can move into corrective actions with ownership, due dates, status, completion evidence, and verification. This preserves a traceable path from the original inspection finding to the work completed in response.

The platform supports proof-of-fix and verification so closure can be supported by evidence rather than relying only on a status change. The exact evidence and approval requirements depend on the configured workflow and user permissions.

It allows organisations to model compliance requirements with details such as requirement codes, frequencies, due dates, applicable assets, expected evidence, and coverage. This helps connect compliance obligations to the assets and operational evidence that support them.

Yes. Obligations can include recurring frequencies and due-date context so teams can see upcoming or overdue evidence requirements rather than managing recurring obligations in separate spreadsheets.

Yes. Evidence coverage is part of the compliance model, allowing teams to distinguish a recorded obligation from an obligation that is actually supported by the expected operational evidence.

InspectAssets supports role-aware reporting and exports including inspection reports, decision-oriented PDFs, audit or evidence packs, and structured data exports where enabled. Different report types remain distinct so an operational inspection record is not confused with a management or decision output.

Yes. The reporting model separates inspected results, failed findings, unknown or unresolved assessment states, and not-applicable items. This prevents 'not inspected' from being reported as though the component passed.

Yes. Management uncertainty is deliberately kept separate from Asset Health. A healthy observed condition can therefore sit beside incomplete coverage or unresolved limitations without one cancelling out the other.

Where enabled, external evidence portals allow selected assets, inspections, and permitted evidence to be shared through controlled, time-limited access. This avoids giving an external reviewer general access to the tenant environment.

The platform preserves actors, timestamps, approval and review decisions, reasons, evidence provenance, action history, and related records so accountability can be reconstructed after the operational event.

Access is permission- and scope-aware. Users are shown the capabilities and records permitted by their role, assigned sites, and operational scope rather than receiving the same application view regardless of responsibility.

A site represents the operational location, while a legal entity represents the registered organisation that owns or operates within the structure. Billing accounts and tax profiles describe the payer and tax relationship. Keeping these concepts separate avoids using a site's geography as a substitute for legal or commercial ownership.

Yes. Subscription allocation is designed to let organisations assign available capacity where it is needed rather than treating every site or legal entity as an unrelated subscription relationship.

Enterprise identity capabilities include SSO configuration where enabled, alongside role and scope controls inside the tenant. Availability can depend on the organisation's plan and configuration.

The platform supports integration patterns including tenant API keys, webhooks, and structured exports where enabled. Access is controlled so integrations can be scoped rather than relying on unrestricted tenant credentials.

White-labelling and custom-domain capabilities are available where enabled, allowing enterprise deployments to align selected user-facing surfaces with organisational branding and domain requirements.

Rollout depends on the number of sites, templates, roles, data sources, and governance requirements. A practical implementation normally starts by defining organisational structure, user scope, inspection templates, evidence requirements, and a pilot workflow before expanding across additional sites or teams.

Existing inspection content can be reviewed and translated into InspectAssets templates and governance rules. The objective is not simply to copy old forms, but to preserve the fields that matter while making evidence, assessment states, approvals, and follow-up behaviour explicit.

No. InspectAssets uses a 1-month free trial on the paid plan you select. Signup may use a small payment-method verification charge, and subscription billing begins after the trial according to the payment method and terms shown during registration.

The marketing pricing experience uses the same public plan catalogue as the registration flow. Plan names, prices, visibility, ordering, limits, and returned features are therefore sourced from the platform rather than maintained as a separate marketing-only list.

Because pricing is sourced from the public plan catalogue, active public plan changes are reflected by the marketing and registration experiences without maintaining a separate hardcoded plan definition in the marketing site.

InspectAssets supports structured exports and report outputs according to the relevant feature and permission. Enterprise integrations can also use approved API access where enabled.