FASE 5.1 · HARDWARE LAYER

Trusted Hardware Credentials v0

Bind hardware.cert credentials to operational assets (camera · device · sensor · drone · vehicle), propagate them to capture attestations and surface them as Trusted Hardware on the public receipt.

Why

Credentials Core (5.0) introduced hardware.cert as a type. 5.1 makes it operational: an Asset (camera, sensor, drone, vehicle, edge device) can hold one or more hardware credentials, and every capture produced by that Asset carries the credential forward into the receipt and into Trust(Asset).

What 5.1 ships

• Column capture_attestations.hardware_credential_id + index.
• RPC resolve_hardware_credential(asset_id) returning the strongest active+verified credential, DISTINCT (no double counting).
• Edge fn capture-attest resolves and persists the hardware credential when an asset_id is provided.
• Public RPC receipt_hardware_credential(content_hash) and "Trusted Hardware" lineage node on /r/:id + <axia-verify>.
• Dashboard → Assets: per-asset Hardware dialog to attach / detach credentials.
• View asset_hardware_credentials_v for org-scoped listing.

Receipt extension (additive)

axia.receipt.v1 stays frozen. The capture-attest response and the public receipt page add an optional block; receivers that do not understand it MUST ignore it.

UX language

• Tier 1 (badge): "Captured by registered camera" (or device / sensor / drone / vehicle).
• Tier 2 (panel): "Hardware credential present" + issuer.
• Tier 3 (raw): credential id, issuer DID, trust level, expiry.
• Issuer trust level unknown → "registered" wording, no Trust bonus elevation.

Honesty: what 5.1 is NOT

• Not a manufacturer-rooted attestation (TPM / Secure Element / TEE cross-signature). That is 5.1.x.
• Not issuance — AxIA does not mint hardware certs in v1; they must already exist in the org.
• Not real-time revocation (CRL / OCSP) — Fase 5.2.
• Not a policy enforcement point — capture.emit gating via the Policy Engine arrives after 5.1.