How a Helix credential works.

Start with the object. Keep the evidence explicit.

An artwork is the starting use case: a creator records a work, attaches supporting files, issues a credential, and shares it with a gallery or collector. The same structure can describe another unique object when its evidence method and operating procedures are defined. Domain-specific validation is still required.

The platform combines a working studio, a portable .hlx credential, a verifier, and optional physical carriers. The studio manages issuance and custody. The package carries evidence and proofs. The verifier evaluates those proofs. A physical tag helps connect a presented object to its record.

A valid signature establishes that the signed bytes are intact under a key. Identifying the signer, checking current status, and assessing the physical object require their own evidence.

One work, from preparation to a shareable credential.

1. Describe the work. Enter its title, creator and identifying context. Add the pictures or scans that will form the evidence inventory. File-size and combined-upload checks run before submission.
2. Save and freeze the evidence. Helix saves the work and files before signing. The signed input commits to the chosen evidence and metadata. A saved work can be resumed without uploading it again; it is not presented as issued while signatures remain incomplete.
3. Issue the credential. The configured signature policy must complete. Longer signing operations advance through authenticated saved steps; the completed signature is checked before the credential becomes active. Progress describes the actual FORS or hypertree work without exposing signer state.
4. Prepare the handoff. The package includes the manifest, required proof material and declared evidence delivery. An optional tag can provide a locator or carry a commissioned token envelope. The download remains distinct from tag qualification.
5. Verify or transfer. A recipient can inspect the package and current registry state. A custody transfer requires the intended recipient to review and accept it. The resulting package can then carry the updated history.

A portable package with a stable evidence commitment.

The current evidence profile is .hlx/ie-1 under helix-auth/2.0. The container is ZIP-compatible. Its security comes from the validated inventory and signed structures inside it, rather than the ZIP file’s compression, ordering or timestamps.

EvidenceRoot excludes container-level details. A package can be refreshed with a later custody proof while retaining the same original evidence, manifest and signatures. The verifier recomputes commitments rather than trusting a displayed identifier.

Algorithm policy

Helix supports policy-selected ML-DSA and SLH-DSA signatures. Required slots and thresholds are checked, including their algorithms, keys and delegated purposes. Unsupported algorithms, empty policies, substituted keys and missing required signatures fail validation. Experimental choices, where enabled, remain identified as such.

Read the result in the context of the question.

Upload a .hlx package to inspect its contained evidence and proofs, or enter a certificate ID / scan its locator to inspect the live record. A locator retrieves a record; it does not contain the complete proof.

The overall VALID, INVALID or INDETERMINATE result applies to the named claim. It does not turn every unevaluated physical question into a positive result.

Offline and online checks

A package supports offline integrity, signature and included-proof checks. Trust still requires a root key or bundle digest obtained independently of that package. Current revocation and later custody changes require current data. An old, correctly signed checkpoint proves historical inclusion, not today’s status.

New photographs and scans

An exact-file mismatch means the supplied bytes differ. It does not, by itself, mean the object is counterfeit. Intrinsic matching needs a defined capture method, quality controls, thresholds and validation against genuine and adversarial observations.

Carry the history when the work changes hands.

Every public credential has Verification, Details and History panels. Its history includes signed lifecycle events, accepted handoffs and explicitly published provenance. Inspect event digests, copy a direct event link or download a checkpoint inclusion proof. Open the verifier and its History panel.

The current owner offers the work to an existing active customer account. The recipient’s link contains an acceptance token; the server retains its digest. The recipient signs in, reviews the work and sender, and explicitly accepts before control moves.

Acceptance appends a signed custody event, links it to the previous event and original evidence root, records transparency material, and moves platform control of the work and its tag records. Cancelled, expired or mismatched offers cannot transfer control. Retrying an already accepted offer acknowledges the existing result without adding a duplicate transfer.

Package preparation includes the new custody chain and sealed proof while preserving the original signed evidence. Previous downloads remain historical records; recipients should obtain the updated package and check freshness. Platform custody records a controlled handoff. Legal title, payment, shipping and physical delivery agreements remain separate matters.

Choose a physical link for the assurance you need.

Browser writing uses NDEF on compatible Android Chrome NFC devices. Other readers can use the exported NDEF message when their utilities support it. UHF programming, firmware flashing and secure-key provisioning need device-specific integrations. None of these actions automatically certify physical continuity.

Read the formats and validation requirements.

The public series describes encodings, trust decisions, observations and conformance requirements. These are candidate specifications and validation protocols; publication is not independent product certification. Manufacturing recipes, calibration secrets and private operational controls are outside the public series.

• HXP-001 · Core Evidence Capsule 2.0 →candidate standard · v0.1

  Canonical inventory, evidence roots, signatures, and portable .hlx/ie-1 packaging.

• HXP-002 · Physical Token Envelope & Carrier →candidate standard · v0.1

  Capacity-bounded deterministic CBOR, ML-DSA delegation, NFC, and optical commitments.

• HXP-003 · Open Verification & Trust Roots →candidate standard · v0.2

  Independent signal evaluation, pinned roots, offline freshness, and result vocabulary.

• HXP-004 · Threat Model & Security Goals →candidate standard · v0.1

  Counterfeiters, malicious manufacturers, transfer attacks, emulation, and explicit non-goals.

• HXP-005 · Intrinsic Evidence Correspondence →validation protocol · v0.1

  Controlled capture, deterministic feature templates, quality gates, and fresh observations.

• HXP-006 · Optical-PUF Enrollment & Matching →validation protocol · v0.1

  Post-manufacture enrollment, controlled observations, thresholds, FAR/FRR, and clone testing.

• HXP-007 · Tamper, Transfer & Environmental Qualification →validation protocol · v0.1

  Pre-registered removal attacks, aging, contamination, and destructive-continuity gates.

• HXP-008 · Conservation-Safe Attachment Profiles →validation protocol · v0.1

  Rigid, flexible, closure, and no-direct-adhesive fine-art profiles.

• HXP-009 · Conformance, Test Vectors & Certification →candidate standard · v0.1

  Golden vectors, package safety, physical evidence dossiers, and claim-gate advancement.

• HXP-010 · Standards Mapping, Governance & IPR →candidate standard · v0.1

  ISO 22383, ISO/IEC 20248, GS1, NIST, versioning, certification, and open-verifier licensing.

• HXP-011 · Physical Scan Binding (HSB-1) →candidate standard · v1.0

  Deterministic commitments for photos, point clouds, canonical geometry, and independently reported scan evidence.

For operational controls, threat scenarios and current assurance limits, read Security.