# HXP-010 — Standards Mapping, Governance, Versioning and IPR

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

## Purpose and current authority

A portable credential needs more than a published file format. Implementers need stable identifiers, precise versioning, understandable trust rules, and a way to distinguish a proposal from an approved profile. Users need to know who maintains those rules and what evidence supports the claims attached to them.

Helix's HXP series describes public protocol contracts and candidate validation requirements. Publication by the project does not make the series an independently adopted industry standard. Independent implementation, laboratory reproducibility, documented governance, and adoption are necessary parts of that longer process. The present articles should be read with their stated candidate or validation-protocol status.

This document explains the intended governance boundaries and the relationship to external standards. It does not invent an independent certification board, confer a license, or declare legal rights on behalf of another organization. Operational authority and the evidence for a technical claim remain separately reviewable.

## How external standards are used

| Reference | Relevant subject | Boundary of the mapping |
| --- | --- | --- |
| ISO 22383:2020 | Evaluation of authentication solutions for material goods | A relevant evaluation framework does not certify a Helix attachment or physical claim. |
| ISO/IEC 20248:2022 | Digital-signature data structures for automatic identification and capture | Helix's post-quantum envelope is not automatically a conforming implementation of that encoding. |
| GS1 Digital Signatures | Signature-based integrity and authenticity patterns for product information | Shared architectural ideas do not establish GS1 identifier or payload conformance. |
| NIST FIPS 204 | ML-DSA signature algorithm specification | Algorithm use does not by itself establish validated-module status or platform certification. |
| NIST FIPS 205 | SLH-DSA signature algorithm specification | A configured algorithm does not establish issuer authority, physical identity, or system-wide assurance. |

The references address different layers. Material evaluation, carrier data, product identifiers, cryptographic algorithms, and application trust policy should not be collapsed into one compliance label. Where Helix extends a format or uses a different encoding, the extension must be described explicitly rather than represented as conformance to an unchanged external standard.

Reference editions also matter. A future revision of an external document does not silently change the interpretation of an already issued Helix artifact. Any compatibility decision needs an identified version and supporting analysis.

## Public verification contracts

Verifier-facing schemas, signing-domain definitions, algorithm identifiers, result vocabulary, trust behavior, and conformance expectations belong in an inspectable public contract. A verifier must be able to understand what is being claimed and which evidence is required without learning a private signing key or a manufacturing recipe.

Public specification availability is distinct from source-code licensing. The fact that this article describes an algorithm or protocol does not grant permission to use every implementation, dataset, trademark, or proprietary process associated with Helix. A reference implementation can support interoperability only under the actual terms provided with that implementation. This article makes no claim that the private platform repository is publicly licensed.

The same distinction applies to thresholds and physical profiles. A qualified claim needs a defined decision rule and sufficient evidence for review. That requirement does not imply unrestricted publication of protected enrollment templates, confidential calibration controls, or raw observations containing sensitive customer information.

## Information that remains controlled

Issuance services, private credentials, key custody, manufacturing recipes, inverse-design methods, calibration controls, vendor operations, and commercial certification processes remain outside the public protocol articles. Publishing enough information to evaluate a claim does not require exposing the private mechanisms used to operate the service.

A public description should identify a boundary without revealing its secret material. For example, it can explain that an issuer signs under a scoped delegation and that the verifier must independently trust the root. It should not include live signing state, private keys, session tokens, service credentials, private storage locations, or internal connection values.

Restricted engineering and research documents remain governed by their access controls. Linking a public specification to a restricted topic does not make the restricted document public. Public article routes should expose only the explicitly designated HXP content, and future additions need the same publication review.

## Protocol versions and article editions

Protocol versions are immutable interpretations of the signed data contract. An incompatible change creates a new major protocol rather than silently changing the meaning of an existing identifier. Compatible additions use identified profiles or registry entries, with explicit rules for recognition and rejection.

An article edition serves a different purpose. Explanations, diagrams, references, and editorial corrections can improve while the described protocol version remains unchanged. The edition date on these pages identifies that explanatory revision. It should not be mistaken for a new signature algorithm, a changed acceptance threshold, or a retroactive update to an older credential.

| Kind of change | Appropriate treatment |
| --- | --- |
| Clearer explanation of an existing rule | New article edition with the rule preserved |
| Compatible optional profile | Identified profile and compatibility review |
| Different mandatory interpretation | New incompatible protocol version |
| Security correction | Published erratum and explicit affected-version behavior |
| New physical performance claim | Evidence review and the applicable qualification gate |

Readers should be able to identify both the artifact's governing version and the explanatory document they are using to interpret it.

## Profile approval and registry discipline

A profile proposal should explain its purpose, data contract, dependencies, allowed claims, compatibility behavior, test vectors, and validation status. Review should examine both positive behavior and rejection behavior. A profile that adds a new field but leaves unsupported readers unsure how to treat it is not operationally complete.

Identifiers need stable meaning. Reusing an existing identifier for a changed extractor, threshold, physical assembly, or signing rule can make historical evidence ambiguous. A new identifier or revision should be used where the change alters the interpretation relevant to verification.

HelixAuth currently retains project authority over its profile approval and certification marks. That project authority should be stated accurately. It is not equivalent to an independent standards-development process, and it does not establish that an external laboratory has validated a profile. Any future expansion of governance should identify participants, decision procedures, conflicts, and appeal or correction mechanisms in a published record.

## Trust roots and lifecycle policy

A verifier's trust policy determines which authority it recognizes for a particular claim. A key bundled with an artifact is evidence to inspect, not sufficient authority to trust itself. Root distribution, delegation scope, algorithm requirements, and status interpretation therefore belong in the public trust contract even though private key operations remain confidential.

Key rotation and revocation require careful historical interpretation. A current status observation and a historical signature answer different questions. The governance record should explain the applicable policy rather than retroactively erasing evidence or presenting an old observation as current. [HXP-003](/standards/open-verifier) details that separation.

No editorial change to these pages modifies production roots, grants new authority, or changes the configured signing policy. Such changes require their own technical and security review, with compatibility and recovery evidence appropriate to the affected boundary.

## Errata and responsible correction

Errors should be corrected through an identifiable record of affected versions, the corrected interpretation, and the practical consequence. A wording correction may need only an article update. A verifier flaw or a weakened physical claim may require changes to acceptance behavior, status communication, and the associated evidence dossier.

Historical packages should remain historical packages. Corrections can add context and current policy without rewriting the original signed evidence. This preserves the distinction between what was issued, what was known at the time, and what a present verifier is justified in concluding.

Sensitive reports should be handled through an authorized private process while a remedy is evaluated. Public communication should explain affected claims and mitigations at an appropriate level without disclosing private credentials, personal data, or operational exploit instructions. This article does not assert the existence of an external vulnerability-disclosure program or response-time commitment that has not been separately published.

## Intellectual property and review status

Specifications, software, datasets, physical designs, trademarks, and certification marks are different subject areas. Their permissions should be stated in the applicable published terms. An informative reference to a standard or an implementation is not a license grant, a patent-clearance opinion, or permission to use another organization's mark.

Technical openness should be described precisely: which contracts are public, which implementation materials are available under which terms, and which operational details remain proprietary. This precision helps collaborators build compatible systems without relying on assumptions about rights or access.

The HXP articles are project-authored technical documents. Detailed rendering, references, and internal consistency checks do not constitute external peer review. Any future peer review, independent implementation, or laboratory assessment should be identified by its actual scope and result. [HXP-009](/standards/conformance) describes the evidence needed for stronger qualification statements.

## Primary references and related articles

Reference links reviewed for this article edition:

- [ISO 22383:2020](https://www.iso.org/standard/50285.html), authentication solutions for material goods.
- [ISO/IEC 20248:2022](https://www.iso.org/standard/81314.html), digital-signature data structures for automatic identification and data capture.
- [GS1 Digital Signatures](https://www.gs1.org/standards/gs1-digital-signatures/current-standard), the published GS1 specification family.
- [NIST FIPS 204](https://csrc.nist.gov/pubs/fips/204/final), ML-DSA.
- [NIST FIPS 205](https://csrc.nist.gov/pubs/fips/205/final), SLH-DSA.

For the Helix contracts themselves, begin with [HXP-001](/standards/core-capsule), continue with [HXP-002](/standards/token-envelope) and [HXP-003](/standards/open-verifier), then consult the relevant capture or physical profile. The articles explain the public boundaries of the platform; stronger claims depend on the evidence and governance described here.