FAQs

“Verified” within AutoID™ means the record has been created under a declared scope with structured inputs, and its consistency is checked according to the AutoID™ framework rules. It does not mean “approved for sale” or “legally compliant”. Verification in AutoID™ is about identity integrity: scope clarity, traceable references and versioned status.

The ecosystem has valuable tools, but they are fragmented:

• VIN is a static identifier, not a technical identity profile.
• Safety tests provide a limited performance snapshot and do not function as a cross-domain identity layer.
• Homologation focuses on minimum legal thresholds and is not designed for transparent lifecycle visibility.
• Manufacturer declarations vary in structure and comparability.

AutoID™ is designed to unify these elements into a clear identity and traceability layer — without creating new authority.

AutoID™ is defined and governed within the IAF programme structure. Issuance follows the AutoID™ rules: scope declaration, evidence structuring, integrity checks and lifecycle logic. Over time, issuance can be supported by designated technical service workflows and controlled submission paths — but always under the same principles: neutrality, transparency and clear separation from market access decisions.

AutoID™ is designed to avoid unbounded “everything” claims. A record covers only what is declared in scope. If deeper coverage is required, it can be represented through additional scoped records (e.g., a vehicle variant record plus a battery record), each with its own boundaries and evidence references.

AutoID™ is not designed to judge commercial quality, brand value, or market competitiveness. It also does not replace legal compliance decisions or act as enforcement. It focuses on identity, traceability, evidence logic and lifecycle status — within declared boundaries.

AutoID™ is evidence-based, meaning it relies on structured references aligned to scope. Whether those references include physical testing, documentation, third-party reports or other traceable inputs depends on the scope rules and the maturity stage of the programme. AutoID™ itself does not claim to be a test regime; it is a framework for identity and traceability.

Yes. If scope is unclear, evidence references do not align, or integrity checks fail, a record can be paused for clarification or rejected until the submission meets scope and structure requirements. This protects credibility and comparability.

These are lifecycle labels designed to keep records understandable:

• Current: active reference representing the present verified state
• Updated: adjustments applied while keeping continuity
• Superseded: replaced by a newer version while history remains visible
• Expired: no longer valid under framework conditions or scope rules

Exact triggers depend on scope and framework rules.

Without versioning, identity becomes confusing and trust becomes narrative-based. Versioning protects traceability, prevents silent change, and enables consistent interpretation.

Full evidence may include confidential technical detail, IP-sensitive documentation or restricted third-party reports. AutoID™ prioritises clarity and traceability: public summaries can indicate the nature of evidence references, while access layers protect sensitive content.

Homologation/type approval is a legal mechanism for market entry and compliance. AutoID™ does not make those decisions. It complements the ecosystem by providing a neutral identity and traceability layer that can improve clarity and comparability beyond minimum legal thresholds.

Safety ratings provide performance snapshots focused on safety. AutoID™ is not a safety score; it is an identity and traceability layer. AutoID™ can coexist with safety results by referencing them as evidence where relevant to scope — but it is broader and structurally different.