# HXP-009 — Conformance, Test Vectors and Certification

Status: Candidate Standard 0.1
Public article edition: 2026-09-09

## Conformance is evidence for a named claim

Conformance asks whether an implementation behaves according to a particular specification and version. Qualification asks whether the evidence supports a stated performance claim under defined conditions. Certification would add a documented approval process and the authority to make a particular certification statement. These are related activities, but one does not automatically establish the others.

Helix separates digital safety from physical performance. A correct signature check can establish an important property of a credential while providing no experimental evidence about a carrier's resistance to copying or transfer. Similarly, a convincing physical demonstration cannot compensate for a verifier that accepts an untrusted key or an altered package.

This candidate standard defines the evidence structure and claim gates. It does not announce an independent certification program or assert that every gate has been passed. Public reports should identify actual test results and unresolved work rather than infer completion from an interface, a codebase, or a vendor proposal.

## Digital conformance coverage

Digital evaluation includes canonical JSON and CBOR golden vectors; every signing domain; evidence-root mutation; token capacity; signature, key, root, and profile substitution; replay; duplicate commissioning; interrupted saga recovery; malicious ZIP archives; and legacy v1 compatibility. Each category tests a distinct boundary in the system.

| Test family | Required observation |
| --- | --- |
| Encoding and commitments | Equivalent permitted inputs reproduce the expected bytes and digest; meaningful changes do not silently preserve the commitment. |
| Signatures and authority | Invalid, missing, duplicated, or substituted required evidence is rejected under the declared policy. |
| Package processing | Unsafe structure, unsupported mandatory content, and resource-limit violations fail before an authenticity claim is accepted. |
| Issuance recovery | Interruptions preserve identity and committed inputs without publishing partial success. |
| History and freshness | Ordering, references, signatures, checkpoints, and observation scope remain distinguishable. |
| Compatibility | Historical formats retain their explicit capabilities and limitations. |

Passing a happy-path example is necessary but insufficient. The verifier's behavior on malformed or adversarial input is part of conformance, not an optional security supplement.

## Test vectors should be independently usable

A golden vector specifies inputs, the relevant profile and version, expected canonical representation where applicable, expected digest or signature outcome, and the expected result classification. Its purpose is to let another implementation detect a disagreement without relying on the original service's assertion that its own output is correct.

Vectors should use synthetic or explicitly public fixtures. Live signing keys, real session material, protected enrollment templates, and private customer evidence do not belong in a public test package. A test key must be clearly identified as such and must never be promoted into a production trust root simply because it appears in a passing example.

Negative vectors need the same precision as positive ones. “Invalid” is more useful when the test identifies the relevant reason and boundary: a missing required signature, wrong signing domain, substituted delegation, malformed inventory, or unsupported profile. An implementation that rejects an input accidentally for an unrelated reason may still contain the vulnerability the test was intended to examine.

## Recovery and operational behavior

Resumable signing requires evaluation across interruptions, repeated requests, and completion boundaries. A saved intermediate step is not an issued credential. Tests should establish that the same authorized request resumes its existing operation and that changed committed inputs cannot reuse that identity unnoticed.

A completed package must satisfy the configured signing policy and include the required committed evidence. Failures during persistence or final assembly should not produce a public success result for incomplete material. Tests of these cases need realistic state transitions, not only a mock response that always reports completion.

Operational drills answer questions that ordinary unit tests cannot. Backup restoration, recovery of required artifacts, and behavior under the actual deployment resource limits need their own evidence. A passing local suite should not be described as a completed restore drill or a signed-in production acceptance test unless those activities were actually performed and recorded.

## The five claim gates

| Gate | Scope | Evidence needed to advance |
| --- | --- | --- |
| G0 | Digital safety | Reproducible format, policy, signature, package, and recovery checks with the applicable trust boundaries reviewed |
| G1 | Carrier and destructive continuity | Evaluated carrier behavior and the named attachment's transfer-detection evidence |
| G2 | Optical PUF and controlled reader | Qualified unit correspondence, controlled observations, and statistical performance evidence |
| G3 | Material, environment, and field pilot | Supported service envelope, host compatibility, and representative use evidence |
| G4 | Independent conformance and inter-laboratory reproducibility | Documented independent evaluation and reproducible results across the declared implementations or laboratories |

The gates organize evidence requirements. They are not an automatic progress meter driven by the number of features implemented. A simulation, supplier quotation, or generated tag image cannot advance physical qualification. An earlier gate also does not eliminate the need to examine interactions introduced at a later stage.

## Contents of a physical dossier

A physical dossier links a profile version to preregistration, unit and lot sampling, reader calibration, raw observations, analysis code, false-acceptance and false-rejection results, indeterminate outcomes, confidence bounds, transfer attacks, environmental exposure, failures, and independent review. Readers should be able to understand what population and conditions the claim covers.

The raw evidence may include protected enrollment material or proprietary production details. Public transparency does not require publishing every sensitive input. It does require an honest, sufficiently detailed summary of methods, sample selection, exclusions, outcomes, and limitations, together with a controlled path for appropriate independent review.

A dossier digest identifies a particular dossier version. It helps detect substitution when that dossier is obtained, but it does not prove that the experiment was well designed or that the conclusions are correct. The quality of the evidence and the independence of review remain substantive questions.

## Statistical reporting and reproducibility

Report denominators alongside rates. A zero-event result from a small study and one from a large representative study support different levels of confidence. Repeated measurements from the same unit, reader, or manufacturing lot may be correlated; treating every comparison as independent can overstate the strength of the result.

False acceptance, false rejection, and indeterminate outcomes describe different failure modes and should remain separate. Excluding unreadable samples can make the accepted subset appear better while hiding an unusable overall workflow. The report should state both the decision rule and the population to which the stated rate applies.

Reproducibility includes method identity, frozen thresholds, software versions relevant to the analysis, and clear treatment of exclusions. A second evaluator should be able to distinguish disagreement in canonical computation from disagreement caused by measurement conditions or a different specimen population. The appropriate response is to investigate the boundary, not average incompatible results into one reassuring number.

## Publication and certification statements

A certified implementation, if and when approved under a documented program, would publish its profile identifiers, verifier compatibility, evidence-dossier digests, permitted claims, limitations, and expiry or requalification rules. The identity and scope of the approving organization must be explicit. Internal maintainer review should not be described as independent laboratory certification.

An implementation may accurately state that a named software test suite passed at a particular revision. It should not translate that statement into universal security, physical authenticity, or standards certification. The public language needs to match the evidence actually collected.

The same discipline applies to publication quality. A detailed technical article can be reviewed for internal consistency and supported by references without having undergone external peer review. Review status should be stated precisely instead of borrowing the authority of a journal or standards body that has not evaluated the work.

## Changes, regressions, and requalification

A new release should identify which evidence remains applicable and which changes need fresh evaluation. Altering a signing domain, parser, trust rule, profile meaning, reader method, attachment material, or threshold may affect different parts of the conformance case. Passing unrelated interface tests does not resolve those changes.

Compatibility requires explicit treatment of older credentials. A new verifier should not silently reinterpret an older claim or erase a historical limitation. Security errata can explain corrected behavior while preserving the original artifact and the fact that it was issued under an earlier policy.

Physical requalification is similarly scoped. A new lot process, reader revision, or substrate substitution may require additional evidence even when the digital format is unchanged. The review should explain the affected assumptions and why a retained claim remains justified.

## How to read a Helix validation statement

A useful statement answers five questions: which version was evaluated, which claim was tested, under what conditions, with what result, and with what remaining limitations. A test count alone answers none of those questions. It can summarize activity, but the mapped evidence is what makes the result assessable.

Read [HXP-003](/standards/open-verifier) for verification outcomes, [HXP-004](/standards/threat-model) for adversary boundaries, [HXP-006](/standards/optical-puf) for candidate optical targets, and [HXP-010](/standards/governance) for versioning and governance. This standard keeps implementation progress, measured performance, and approval status distinct so the platform can make useful claims without overstating assurance.