xoonya 3.1.0 → 3.1.2

package/XOONYA_NATIVE_STANDARD_GOVERNANCE.md

@@ -1,119 +1,119 @@
-# xoonya Native Standard Governance
-
-Status: active governance note
-
-## Purpose
-
-This document defines how xoonya Native evolves without losing its standard value.
-
-The goal is not to create a format for novelty. The goal is to preserve a small deterministic machine-evidence primitive that can survive runtime churn, identity-system churn, settlement-rail churn, and cryptographic migration.
-
-## Compatibility Marks
-
-The phrase `XNYA-compatible` should mean:
-
-- the implementation accepts the canonical `XNYA` atom magic
-- it validates the published byte layouts exactly
-- it implements deterministic pass/fail behavior
-- it passes the published conformance vectors
-- it rejects the published adversarial vectors
-- it does not redefine a published version line
-- it follows the public mark rules in `XNYA_CONFORMANCE_MARK.md`
-
-Implementations that use a different magic value, different field ordering, different hash derivation, or soft-forked validation behavior are not xoonya Native atom implementations. They are separate formats.
-
-## Registry Policy
-
-The native standard uses explicit registries for:
-
-- atom versions
-- record types
-- identity type prefixes
-- proof methods
-- signature suites
-- profile types
-
-Registry additions must include:
-
-- identifier
-- purpose
-- canonical bytes or structure
-- validation behavior
-- conformance vectors
-- adversarial vectors where applicable
-- claim boundary
-
-## No Silent Forks
-
-Published version lines are frozen.
-
-No implementation should claim compatibility while:
-
-- changing byte layout
-- changing hash derivation
-- changing magic bytes
-- accepting ambiguous optional fields in the atom
-- adding runtime-specific semantics inside the atom
-- treating planned suites as verified suites
-
-If the format changes, the version changes.
-
-## Security Review Checklist
-
-Before promoting a native feature:
-
-- Does it preserve fixed atom semantics?
-- Does it avoid runtime, chain, custody, settlement, and governance semantics in the atom?
-- Does it define exact canonicalization rules?
-- Does it define deterministic failure reasons?
-- Does it return stable machine-readable error codes?
-- Does it include positive conformance vectors?
-- Does it include adversarial vectors?
-- Does it prevent downgrade or method-confusion attacks?
-- Does it avoid overclaiming unimplemented cryptographic verification?
-
-## Public Claim Boundary
-
-Current public claim:
-
-> xoonya Native provides deterministic machine evidence with native digest, Ed25519 signed proof, and anchor-binding proof support, plus a formal XNYA atom spec for fixed-size commitment records.
-
-Not current public claims:
-
-- not a replacement for JWT, DID/VC, SD-JWT VC, WebAuthn, TLS, HPKE, or encryption
-- not a custody system
-- not a settlement rail
-- not an independent finality oracle for external chains or providers
-- not a governance system
-- not a ZK protocol
-- not a claim that all suite registry entries are cryptographically verified today
-
-## Current Conformance Surface
-
-The current xoonya Native atom conformance surface is:
-
-- `GET /v1/proof-center/native-conformance-mark`
-- `GET /v1/proof-center/native-conformance-mark/summary`
-- `GET /v1/proof-center/native-atom-spec`
-- `GET /v1/proof-center/native-atom-spec/summary`
-- `GET /v1/proof-center/native-atom-conformance`
-- `GET /v1/proof-center/native-atom-conformance/summary`
-- `GET /v1/proof-center/native-anchor-profile`
-- `GET /v1/proof-center/native-anchor-profile/summary`
-- `vectors/native-atom-vectors.json`
-
-Compatibility requires exact XNYA bytes, exact version lengths, exact hash derivation, and stable reject codes. Passing only the positive vectors is not enough.
-
-The anchored native method verifies that a receipt and event commitment bind to declared anchor refs. It does not certify that an external chain, settlement provider, or attestation issuer is truthful.
-
-## Legal And Brand Notes
-
-Use practical protection layers:
-
-- tagged releases
-- checksummed spec artifacts
-- public conformance vectors
-- Apache-2.0 implementation licensing where intended
-- clear xoonya name and conformance-mark usage
-
-Patent, trademark, or defensive-publication strategy should be reviewed with qualified IP counsel before being relied on.
+# xoonya Native Standard Governance
+
+Status: active governance note
+
+## Purpose
+
+This document defines how xoonya Native evolves without losing its standard value.
+
+The goal is not to create a format for novelty. The goal is to preserve a small deterministic machine-evidence primitive that can survive runtime churn, identity-system churn, settlement-rail churn, and cryptographic migration.
+
+## Compatibility Marks
+
+The phrase `XNYA-compatible` should mean:
+
+- the implementation accepts the canonical `XNYA` atom magic
+- it validates the published byte layouts exactly
+- it implements deterministic pass/fail behavior
+- it passes the published conformance vectors
+- it rejects the published adversarial vectors
+- it does not redefine a published version line
+- it follows the public mark rules in `XNYA_CONFORMANCE_MARK.md`
+
+Implementations that use a different magic value, different field ordering, different hash derivation, or soft-forked validation behavior are not xoonya Native atom implementations. They are separate formats.
+
+## Registry Policy
+
+The native standard uses explicit registries for:
+
+- atom versions
+- record types
+- identity type prefixes
+- proof methods
+- signature suites
+- profile types
+
+Registry additions must include:
+
+- identifier
+- purpose
+- canonical bytes or structure
+- validation behavior
+- conformance vectors
+- adversarial vectors where applicable
+- claim boundary
+
+## No Silent Forks
+
+Published version lines are frozen.
+
+No implementation should claim compatibility while:
+
+- changing byte layout
+- changing hash derivation
+- changing magic bytes
+- accepting ambiguous optional fields in the atom
+- adding runtime-specific semantics inside the atom
+- treating planned suites as verified suites
+
+If the format changes, the version changes.
+
+## Security Review Checklist
+
+Before promoting a native feature:
+
+- Does it preserve fixed atom semantics?
+- Does it avoid runtime, chain, custody, settlement, and governance semantics in the atom?
+- Does it define exact canonicalization rules?
+- Does it define deterministic failure reasons?
+- Does it return stable machine-readable error codes?
+- Does it include positive conformance vectors?
+- Does it include adversarial vectors?
+- Does it prevent downgrade or method-confusion attacks?
+- Does it avoid overclaiming unimplemented cryptographic verification?
+
+## Public Claim Boundary
+
+Current public claim:
+
+> xoonya Native provides deterministic machine evidence with native digest, Ed25519 signed proof, and anchor-binding proof support, plus a formal XNYA atom spec for fixed-size commitment records.
+
+Not current public claims:
+
+- not a replacement for JWT, DID/VC, SD-JWT VC, WebAuthn, TLS, HPKE, or encryption
+- not a custody system
+- not a settlement rail
+- not an independent finality oracle for external chains or providers
+- not a governance system
+- not a ZK protocol
+- not a claim that all suite registry entries are cryptographically verified today
+
+## Current Conformance Surface
+
+The current xoonya Native atom conformance surface is:
+
+- `GET /v1/proof-center/native-conformance-mark`
+- `GET /v1/proof-center/native-conformance-mark/summary`
+- `GET /v1/proof-center/native-atom-spec`
+- `GET /v1/proof-center/native-atom-spec/summary`
+- `GET /v1/proof-center/native-atom-conformance`
+- `GET /v1/proof-center/native-atom-conformance/summary`
+- `GET /v1/proof-center/native-anchor-profile`
+- `GET /v1/proof-center/native-anchor-profile/summary`
+- `vectors/native-atom-vectors.json`
+
+Compatibility requires exact XNYA bytes, exact version lengths, exact hash derivation, and stable reject codes. Passing only the positive vectors is not enough.
+
+The anchored native method verifies that a receipt and event commitment bind to declared anchor refs. It does not certify that an external chain, settlement provider, or attestation issuer is truthful.
+
+## Legal And Brand Notes
+
+Use practical protection layers:
+
+- tagged releases
+- checksummed spec artifacts
+- public conformance vectors
+- Apache-2.0 implementation licensing where intended
+- clear xoonya name and conformance-mark usage
+
+Patent, trademark, or defensive-publication strategy should be reviewed with qualified IP counsel before being relied on.

package/XOONYA_PROOF_TRUTH_MODEL.md

@@ -1,58 +1,58 @@
-# xoonya Proof Truth Model
-
-`xoonya` is the proof-side truth layer for the public stack.
-
-For `3.0.0`, that has to be explicit, not implied from many helper surfaces.
-
-## Core Rule
-
-The proof-side spine is:
-
-`canonical event -> receipt -> proof bundle -> reviewable handoff -> verification -> bridge/governance followthrough`
-
-`xoonya` may expose many routes, but they all need to converge on that same truth model.
-
-## What xoonya Owns
-
-`xoonya` owns:
-
-- deterministic proof construction
-- canonical proof verification
-- native `XNYA` compact evidence artifacts
-- reviewable runtime-to-proof handoff continuation
-- bridge carry and proof-adjacent operator review
-- governance and dispute followthrough
-
-It does not own:
-
-- runtime pricing
-- runtime execution truth
-- treasury or payment control planes
-- universal external chain, identity, or legal judgment truth
-
-## Canonical Objects
-
-The frozen `3.0.0` proof truth model centers on:
-
-- `canonical_event_bundle`
-- `receipt`
-- `proof_bundle`
-- `xnya_native_artifact`
-- `proof_handoff_review`
-- `bridge_and_governance_followthrough`
-
-## Machine-Readable Surfaces
-
-- `GET /v1/proof-truth`
-- `GET /v1/proof-truth/summary`
-- `GET /v1/proof-truth/:object_id`
-
-## Launch Standard
-
-For `3.0.0`, this model is real only if:
-
-- the proof core is deterministic and replayable
-- `XNYA` remains a first-class native evidence family
-- runtime handoffs can continue into review and proof without dead-end loss
-- verification services are visible and callable
-- bridge and governance followthrough remain bounded, reviewable, and explicit
+# xoonya Proof Truth Model
+
+`xoonya` is the proof-side truth layer for the public stack.
+
+For `3.0.0`, that has to be explicit, not implied from many helper surfaces.
+
+## Core Rule
+
+The proof-side spine is:
+
+`canonical event -> receipt -> proof bundle -> reviewable handoff -> verification -> bridge/governance followthrough`
+
+`xoonya` may expose many routes, but they all need to converge on that same truth model.
+
+## What xoonya Owns
+
+`xoonya` owns:
+
+- deterministic proof construction
+- canonical proof verification
+- native `XNYA` compact evidence artifacts
+- reviewable runtime-to-proof handoff continuation
+- bridge carry and proof-adjacent operator review
+- governance and dispute followthrough
+
+It does not own:
+
+- runtime pricing
+- runtime execution truth
+- treasury or payment control planes
+- universal external chain, identity, or legal judgment truth
+
+## Canonical Objects
+
+The frozen `3.0.0` proof truth model centers on:
+
+- `canonical_event_bundle`
+- `receipt`
+- `proof_bundle`
+- `xnya_native_artifact`
+- `proof_handoff_review`
+- `bridge_and_governance_followthrough`
+
+## Machine-Readable Surfaces
+
+- `GET /v1/proof-truth`
+- `GET /v1/proof-truth/summary`
+- `GET /v1/proof-truth/:object_id`
+
+## Launch Standard
+
+For `3.0.0`, this model is real only if:
+
+- the proof core is deterministic and replayable
+- `XNYA` remains a first-class native evidence family
+- runtime handoffs can continue into review and proof without dead-end loss
+- verification services are visible and callable
+- bridge and governance followthrough remain bounded, reviewable, and explicit