xoonya 3.1.0 → 3.1.2

package/XNYA_CONFORMANCE_MARK.md

@@ -1,78 +1,78 @@
-# XNYA Conformance Mark
-
-`XNYA-compatible` is the compatibility mark for implementations that preserve the xoonya Native atom, payload, proof-envelope, and vector behavior exactly enough for deterministic machine evidence to remain portable.
-
-The mark is not an identity, auth, custody, transport-security, settlement, chain-finality, or external-provider truth claim.
-
-## Required Meaning
-
-An implementation may claim `XNYA-compatible` only when it can show:
-
-- the native atom magic is exactly `XNYA`
-- atom versions and fixed sizes match the published spec
-- payload and identity hash derivation match the published vectors
-- required native methods either verify or are explicitly declared unsupported
-- adversarial vectors fail with stable error codes
-- `algorithm: "none"` is rejected for production proof
-- anchor binding does not claim independent external chain or provider truth
-
-## Required Artifacts
-
-The following artifacts define the current conformance floor:
-
-- `XOONYA_NATIVE_PROOF_FORMAT.md`
-- `XOONYA_NATIVE_ATOM_SPEC.md`
-- `XOONYA_NATIVE_STANDARD_GOVERNANCE.md`
-- `XNYA_CONFORMANCE_MARK.md`
-- `vectors/conformance-vectors.json`
-- `vectors/adversarial-vectors.json`
-- `vectors/native-atom-vectors.json`
-- `vectors/native-payload-profile-vectors.json`
-
-## Required Checks
-
-At minimum, a compatible implementation must pass equivalent checks to:
-
-```bash
-xoonya first-run --verify-native --pretty
-xoonya conformance --json
-npm run verify:release-candidate
-npm run verify:service
-```
-
-Non-JavaScript implementations should publish deterministic pass/fail output against the same vector IDs, byte layouts, and error-code expectations.
-
-## Allowed Claim Classes
-
-`xnya_atom_compatible` means the implementation preserves `XNYA` atom bytes, lengths, versions, record types, hash derivation, and reject codes.
-
-`xnya_payload_profile_compatible` means the implementation preserves the `XNYP` binary payload profile: typed fields, canonical ordering, fixed-width integers, explicit unknown-field policy, and no loose JSON or float semantics.
-
-`xnya_native_proof_compatible` means registered native methods verify through the declared suite registry, reject `algorithm: "none"`, and keep signatures, anchors, and external references outside the atom core.
-
-`xnya_external_interop_compatible` means external proof envelopes are bound to canonical xoonya receipts without claiming issuer, DID, JWT, SD-JWT, chain, or partner-provider truth unless an external verifier is declared and bound.
-
-## Forbidden Claims
-
-Do not claim the mark if:
-
-- `XNYA` magic, fixed sizes, version semantics, or atom layout are changed
-- `algorithm: "none"` verifies as production proof
-- happy-path vectors pass but adversarial vectors are skipped
-- PQ/hybrid support is claimed without validators, vectors, downgrade tests, and deterministic error codes
-- external issuer, chain, finality, custody, or provider truth is claimed as xoonya-verified without a declared external verifier
-- the mark is used to imply login, session, wallet, custody, payment, transport, or regulatory compliance behavior
-
-## Extra Evidence Gates
-
-PQ/hybrid native verification requires non-experimental validators, suite-specific public-key rules, positive conformance vectors, adversarial downgrade vectors, and deterministic error codes.
-
-Live external framework-provider compatibility requires real external endpoints, auth boundaries, health checks, failure behavior, latency evidence, and live execution checks.
-
-New signature suites require suite-specific validators plus wrong-key, wrong-method, tamper, and downgrade vectors before they can move from registry/planned status to implemented status.
-
-## Governance
-
-The mark should stay tied to concrete artifacts, not brand aspiration. New public mark claims require docs, vectors, deterministic error codes, release-candidate checks, and service surfaces before public use.
-
-The reference implementation ships inside the `xoonya` npm package until external adoption or governance pressure justifies a separate standards repository.
+# XNYA Conformance Mark
+
+`XNYA-compatible` is the compatibility mark for implementations that preserve the xoonya Native atom, payload, proof-envelope, and vector behavior exactly enough for deterministic machine evidence to remain portable.
+
+The mark is not an identity, auth, custody, transport-security, settlement, chain-finality, or external-provider truth claim.
+
+## Required Meaning
+
+An implementation may claim `XNYA-compatible` only when it can show:
+
+- the native atom magic is exactly `XNYA`
+- atom versions and fixed sizes match the published spec
+- payload and identity hash derivation match the published vectors
+- required native methods either verify or are explicitly declared unsupported
+- adversarial vectors fail with stable error codes
+- `algorithm: "none"` is rejected for production proof
+- anchor binding does not claim independent external chain or provider truth
+
+## Required Artifacts
+
+The following artifacts define the current conformance floor:
+
+- `XOONYA_NATIVE_PROOF_FORMAT.md`
+- `XOONYA_NATIVE_ATOM_SPEC.md`
+- `XOONYA_NATIVE_STANDARD_GOVERNANCE.md`
+- `XNYA_CONFORMANCE_MARK.md`
+- `vectors/conformance-vectors.json`
+- `vectors/adversarial-vectors.json`
+- `vectors/native-atom-vectors.json`
+- `vectors/native-payload-profile-vectors.json`
+
+## Required Checks
+
+At minimum, a compatible implementation must pass equivalent checks to:
+
+```bash
+xoonya first-run --verify-native --pretty
+xoonya conformance --json
+npm run verify:release-candidate
+npm run verify:service
+```
+
+Non-JavaScript implementations should publish deterministic pass/fail output against the same vector IDs, byte layouts, and error-code expectations.
+
+## Allowed Claim Classes
+
+`xnya_atom_compatible` means the implementation preserves `XNYA` atom bytes, lengths, versions, record types, hash derivation, and reject codes.
+
+`xnya_payload_profile_compatible` means the implementation preserves the `XNYP` binary payload profile: typed fields, canonical ordering, fixed-width integers, explicit unknown-field policy, and no loose JSON or float semantics.
+
+`xnya_native_proof_compatible` means registered native methods verify through the declared suite registry, reject `algorithm: "none"`, and keep signatures, anchors, and external references outside the atom core.
+
+`xnya_external_interop_compatible` means external proof envelopes are bound to canonical xoonya receipts without claiming issuer, DID, JWT, SD-JWT, chain, or partner-provider truth unless an external verifier is declared and bound.
+
+## Forbidden Claims
+
+Do not claim the mark if:
+
+- `XNYA` magic, fixed sizes, version semantics, or atom layout are changed
+- `algorithm: "none"` verifies as production proof
+- happy-path vectors pass but adversarial vectors are skipped
+- PQ/hybrid support is claimed without validators, vectors, downgrade tests, and deterministic error codes
+- external issuer, chain, finality, custody, or provider truth is claimed as xoonya-verified without a declared external verifier
+- the mark is used to imply login, session, wallet, custody, payment, transport, or regulatory compliance behavior
+
+## Extra Evidence Gates
+
+PQ/hybrid native verification requires non-experimental validators, suite-specific public-key rules, positive conformance vectors, adversarial downgrade vectors, and deterministic error codes.
+
+Live external framework-provider compatibility requires real external endpoints, auth boundaries, health checks, failure behavior, latency evidence, and live execution checks.
+
+New signature suites require suite-specific validators plus wrong-key, wrong-method, tamper, and downgrade vectors before they can move from registry/planned status to implemented status.
+
+## Governance
+
+The mark should stay tied to concrete artifacts, not brand aspiration. New public mark claims require docs, vectors, deterministic error codes, release-candidate checks, and service surfaces before public use.
+
+The reference implementation ships inside the `xoonya` npm package until external adoption or governance pressure justifies a separate standards repository.

package/XNYA_REFERENCE_IMPLEMENTATIONS.md

@@ -1,157 +1,157 @@
-# XNYA Reference Implementations
-
-`XNYA-compatible` needs independent implementations, not only one JavaScript package. This document defines how xoonya treats reference implementations without overclaiming maturity before vector parity exists.
-
-## Current Reference
-
-The current canonical reference implementation ships inside the `xoonya` npm package:
-
-- `proof_sdk.js` contains the canonical JavaScript helpers, validators, proof builders, and pack generators.
-- `vectors/` contains the positive and adversarial conformance inputs.
-- `bin/xoonya.js` exposes first-run and conformance checks.
-- `bin/xoonya-release.js` exposes public release and standardization artifacts.
-- `server.js` exposes the proof-center JSON surfaces.
-
-Required checks:
-
-```bash
-npm run verify:release-candidate
-npm run verify:all
-xoonya conformance --json
-xoonya first-run --verify-native --pretty
-```
-
-## Planned Independent References
-
-Python and Rust reference implementations are planned, but they are not public compatibility claims until they pass the same vector floor independently.
-
-Candidate names:
-
-- `xoonya-native-python`
-- `xoonya-native-rust`
-
-Each candidate must implement its own byte parser and verifier. Wrapping the JavaScript runtime is useful for demos, but it is not an independent reference implementation.
-
-Promotion evidence is checked separately from scaffold parity:
-
-```bash
-npm run verify:reference-promotion-gate
-```
-
-That verifier proves a complete candidate promotion packet can pass validation, while incomplete packets fail with deterministic rejection codes. The gate requires repository/package evidence, all required vector sets, deterministic error-code parity, independent parser evidence, native signature-suite crypto parity, cross-language round-trip evidence, conformance-mark review, forbidden-claim review, and no secret material.
-
-## Python Candidate Scaffold
-
-The Python candidate scaffold lives in `reference/python`.
-
-It currently covers:
-
-- XNYA atom v1 and v2 creation
-- XNYA atom parsing and verification
-- native atom adversarial reject codes
-- XNYP payload profile encoding and parsing
-- line-rate frame checksum verification
-- canonical event hash parity
-- receipt emission for external assertion, native digest, legacy OP_RETURN, and native anchored methods
-- proof-bundle build/verify parity for non-signed native methods
-- adversarial reason parity for non-signed proof-bundle checks
-- bounded hybrid-method awareness without yet claiming independent PQ/hybrid validator parity
-- optional Ed25519 native signed verification when the Python `cryptography` package is available
-- deterministic `native_signature_crypto_dependency_missing` when the optional crypto dependency is absent
-
-Run:
-
-```bash
-npm run verify:reference-python
-```
-
-This is vector-parity progress, not a full reference promotion. Python does not yet claim always-on native signature-suite cryptographic verification, secp256k1/P-256 parity, external method import, independent PQ/hybrid signature parity, or all native signed proof-bundle round-trip behavior.
-
-Optional Ed25519 crypto check:
-
-```bash
-npm run verify:reference-python-crypto
-```
-
-This command creates an isolated temporary Python virtual environment, installs `reference/python/requirements-optional.txt`, runs the same vector verifier, and requires `verified_signature_suite_count = 1`.
-
-Without the optional dependency, the default verifier still passes by proving the explicit dependency boundary.
-
-## Rust Candidate Scaffold
-
-The Rust candidate scaffold lives in `reference/rust`.
-
-It currently covers:
-
-- source-only package boundary for `xoonya-native-rust`
-- fixed-size `XNYA` atom constants
-- v1/v2 atom byte-length checks
-- deterministic atom parser error codes
-- `publish = false` until vector parity and promotion gates exist
-
-Run:
-
-```bash
-npm run verify:reference-rust-scaffold
-```
-
-This is a packaging and boundary guard only. It does not compile Rust in the
-current release path, does not run positive/adversarial vectors, and does not
-claim `XNYA-compatible` status for Rust.
-
-## Required Vector Floor
-
-An independent implementation must pass:
-
-- `vectors/conformance-vectors.json`
-- `vectors/adversarial-vectors.json`
-- `vectors/native-atom-vectors.json`
-- `vectors/native-payload-profile-vectors.json`
-
-The implementation must also produce stable reject reasons equivalent to the published deterministic error codes.
-
-## Required Behavior
-
-An implementation may claim `XNYA-compatible` only when it:
-
-- parses `XNYA` atoms exactly by byte layout and fixed size
-- preserves `XNYA` atom v1 and v2 domain separation
-- parses `XNYP` payload profiles without loose JSON, floats, or implicit type coercion
-- rejects unsupported or malformed native atoms with deterministic errors
-- rejects `algorithm: "none"` as a production proof method
-- verifies only implemented signature suites with suite-specific validators
-- treats PQ/hybrid methods as independently unverified until that runtime has its own validators and vector parity
-- binds external proof formats without claiming external issuer truth
-- binds anchor references without claiming external chain or provider finality truth
-
-## Promotion Gates
-
-Independent references become public reference implementations only after:
-
-1. A package or repository exists with public source, license, docs, and test commands.
-2. The candidate passes all positive and adversarial vector sets.
-3. The candidate emits deterministic errors that match the JavaScript reference.
-4. The candidate can generate artifacts verified by the JavaScript reference.
-5. The JavaScript reference can generate artifacts verified by the candidate.
-6. The candidate satisfies the `XNYA-compatible` mark without forbidden claims.
-7. The candidate passes `npm run verify:reference-promotion-gate` with promotion evidence that does not contain private keys, access tokens, credentials, or authorization material.
-
-## Non-Claims
-
-The reference implementation plan does not claim:
-
-- PQ or hybrid runtime validation
-- live external provider execution
-- identity, authentication, custody, transport, or settlement security
-- Rust vector parity or full Rust reference status
-- external issuer truth for JWT, DID/VC, SD-JWT VC, signed-envelope, or partner proofs
-- external chain or provider finality truth
-
-Those claims require separate validators, policies, and evidence.
-
-## Service Surface
-
-The machine-readable pack is exposed at:
-
-- `GET /v1/proof-center/native-reference-implementations`
-- `GET /v1/proof-center/native-reference-implementations/summary`
+# XNYA Reference Implementations
+
+`XNYA-compatible` needs independent implementations, not only one JavaScript package. This document defines how xoonya treats reference implementations without overclaiming maturity before vector parity exists.
+
+## Current Reference
+
+The current canonical reference implementation ships inside the `xoonya` npm package:
+
+- `proof_sdk.js` contains the canonical JavaScript helpers, validators, proof builders, and pack generators.
+- `vectors/` contains the positive and adversarial conformance inputs.
+- `bin/xoonya.js` exposes first-run and conformance checks.
+- `bin/xoonya-release.js` exposes public release and standardization artifacts.
+- `server.js` exposes the proof-center JSON surfaces.
+
+Required checks:
+
+```bash
+npm run verify:release-candidate
+npm run verify:all
+xoonya conformance --json
+xoonya first-run --verify-native --pretty
+```
+
+## Planned Independent References
+
+Python and Rust reference implementations are planned, but they are not public compatibility claims until they pass the same vector floor independently.
+
+Candidate names:
+
+- `xoonya-native-python`
+- `xoonya-native-rust`
+
+Each candidate must implement its own byte parser and verifier. Wrapping the JavaScript runtime is useful for demos, but it is not an independent reference implementation.
+
+Promotion evidence is checked separately from scaffold parity:
+
+```bash
+npm run verify:reference-promotion-gate
+```
+
+That verifier proves a complete candidate promotion packet can pass validation, while incomplete packets fail with deterministic rejection codes. The gate requires repository/package evidence, all required vector sets, deterministic error-code parity, independent parser evidence, native signature-suite crypto parity, cross-language round-trip evidence, conformance-mark review, forbidden-claim review, and no secret material.
+
+## Python Candidate Scaffold
+
+The Python candidate scaffold lives in `reference/python`.
+
+It currently covers:
+
+- XNYA atom v1 and v2 creation
+- XNYA atom parsing and verification
+- native atom adversarial reject codes
+- XNYP payload profile encoding and parsing
+- line-rate frame checksum verification
+- canonical event hash parity
+- receipt emission for external assertion, native digest, legacy OP_RETURN, and native anchored methods
+- proof-bundle build/verify parity for non-signed native methods
+- adversarial reason parity for non-signed proof-bundle checks
+- bounded hybrid-method awareness without yet claiming independent PQ/hybrid validator parity
+- optional Ed25519 native signed verification when the Python `cryptography` package is available
+- deterministic `native_signature_crypto_dependency_missing` when the optional crypto dependency is absent
+
+Run:
+
+```bash
+npm run verify:reference-python
+```
+
+This is vector-parity progress, not a full reference promotion. Python does not yet claim always-on native signature-suite cryptographic verification, secp256k1/P-256 parity, external method import, independent PQ/hybrid signature parity, or all native signed proof-bundle round-trip behavior.
+
+Optional Ed25519 crypto check:
+
+```bash
+npm run verify:reference-python-crypto
+```
+
+This command creates an isolated temporary Python virtual environment, installs `reference/python/requirements-optional.txt`, runs the same vector verifier, and requires `verified_signature_suite_count = 1`.
+
+Without the optional dependency, the default verifier still passes by proving the explicit dependency boundary.
+
+## Rust Candidate Scaffold
+
+The Rust candidate scaffold lives in `reference/rust`.
+
+It currently covers:
+
+- source-only package boundary for `xoonya-native-rust`
+- fixed-size `XNYA` atom constants
+- v1/v2 atom byte-length checks
+- deterministic atom parser error codes
+- `publish = false` until vector parity and promotion gates exist
+
+Run:
+
+```bash
+npm run verify:reference-rust-scaffold
+```
+
+This is a packaging and boundary guard only. It does not compile Rust in the
+current release path, does not run positive/adversarial vectors, and does not
+claim `XNYA-compatible` status for Rust.
+
+## Required Vector Floor
+
+An independent implementation must pass:
+
+- `vectors/conformance-vectors.json`
+- `vectors/adversarial-vectors.json`
+- `vectors/native-atom-vectors.json`
+- `vectors/native-payload-profile-vectors.json`
+
+The implementation must also produce stable reject reasons equivalent to the published deterministic error codes.
+
+## Required Behavior
+
+An implementation may claim `XNYA-compatible` only when it:
+
+- parses `XNYA` atoms exactly by byte layout and fixed size
+- preserves `XNYA` atom v1 and v2 domain separation
+- parses `XNYP` payload profiles without loose JSON, floats, or implicit type coercion
+- rejects unsupported or malformed native atoms with deterministic errors
+- rejects `algorithm: "none"` as a production proof method
+- verifies only implemented signature suites with suite-specific validators
+- treats PQ/hybrid methods as independently unverified until that runtime has its own validators and vector parity
+- binds external proof formats without claiming external issuer truth
+- binds anchor references without claiming external chain or provider finality truth
+
+## Promotion Gates
+
+Independent references become public reference implementations only after:
+
+1. A package or repository exists with public source, license, docs, and test commands.
+2. The candidate passes all positive and adversarial vector sets.
+3. The candidate emits deterministic errors that match the JavaScript reference.
+4. The candidate can generate artifacts verified by the JavaScript reference.
+5. The JavaScript reference can generate artifacts verified by the candidate.
+6. The candidate satisfies the `XNYA-compatible` mark without forbidden claims.
+7. The candidate passes `npm run verify:reference-promotion-gate` with promotion evidence that does not contain private keys, access tokens, credentials, or authorization material.
+
+## Non-Claims
+
+The reference implementation plan does not claim:
+
+- PQ or hybrid runtime validation
+- live external provider execution
+- identity, authentication, custody, transport, or settlement security
+- Rust vector parity or full Rust reference status
+- external issuer truth for JWT, DID/VC, SD-JWT VC, signed-envelope, or partner proofs
+- external chain or provider finality truth
+
+Those claims require separate validators, policies, and evidence.
+
+## Service Surface
+
+The machine-readable pack is exposed at:
+
+- `GET /v1/proof-center/native-reference-implementations`
+- `GET /v1/proof-center/native-reference-implementations/summary`

package/XOONYA_DEFAULT_PATH_MODEL.md

@@ -1,63 +1,63 @@
-# xoonya Default Path Model
-
-`xoonya` should feel immediate from the surface the caller already uses.
-
-For `3.0.0`, the public proof story cannot only live across scattered review routes and helper commands.
-
-It needs one frozen answer to:
-
-- how a caller brings proof-side input in
-- how they review it
-- how they verify or run proof followthrough
-- how they emit durable proof artifacts
-- how bridge and governance followthrough remain attached
-
-## Core Rule
-
-All supported proof entry surfaces must converge on one spine:
-
-`receive -> review -> run/emit -> verify -> inspect/governance`
-
-Surface-specific ergonomics are allowed.
-Surface-specific proof truth models are not.
-
-## Supported Surface Families
-
-The frozen `3.0.0` default-path model covers:
-
-- CLI and terminal
-- direct API
-- carried handoff review
-- native proof loop
-- service-to-service and embedded review
-
-## What Changes Across Surfaces
-
-What may change:
-
-- the first entrypoint
-- whether the caller starts from a handoff review, a proof loop, or a verification command
-- whether output is returned as CLI JSON, API JSON, or embedded review state
-
-What must not change:
-
-- proof truth
-- review posture
-- verification posture
-- bridge carry
-- governance followthrough
-
-## Machine-Readable Surfaces
-
-- `GET /v1/default-path`
-- `GET /v1/default-path/summary`
-- `GET /v1/default-path/:surface_id`
-
-## Launch Standard
-
-For `3.0.0`, this model is considered real only if:
-
-- each listed surface has a callable first path
-- each listed surface can review or verify before claiming completion
-- each listed surface converges into the shared proof truth model
-- each listed surface can preserve bridge and governance followthrough where needed
+# xoonya Default Path Model
+
+`xoonya` should feel immediate from the surface the caller already uses.
+
+For `3.0.0`, the public proof story cannot only live across scattered review routes and helper commands.
+
+It needs one frozen answer to:
+
+- how a caller brings proof-side input in
+- how they review it
+- how they verify or run proof followthrough
+- how they emit durable proof artifacts
+- how bridge and governance followthrough remain attached
+
+## Core Rule
+
+All supported proof entry surfaces must converge on one spine:
+
+`receive -> review -> run/emit -> verify -> inspect/governance`
+
+Surface-specific ergonomics are allowed.
+Surface-specific proof truth models are not.
+
+## Supported Surface Families
+
+The frozen `3.0.0` default-path model covers:
+
+- CLI and terminal
+- direct API
+- carried handoff review
+- native proof loop
+- service-to-service and embedded review
+
+## What Changes Across Surfaces
+
+What may change:
+
+- the first entrypoint
+- whether the caller starts from a handoff review, a proof loop, or a verification command
+- whether output is returned as CLI JSON, API JSON, or embedded review state
+
+What must not change:
+
+- proof truth
+- review posture
+- verification posture
+- bridge carry
+- governance followthrough
+
+## Machine-Readable Surfaces
+
+- `GET /v1/default-path`
+- `GET /v1/default-path/summary`
+- `GET /v1/default-path/:surface_id`
+
+## Launch Standard
+
+For `3.0.0`, this model is considered real only if:
+
+- each listed surface has a callable first path
+- each listed surface can review or verify before claiming completion
+- each listed surface converges into the shared proof truth model
+- each listed surface can preserve bridge and governance followthrough where needed