xoonya 3.1.17 → 3.2.0

package/XOONYA_NATIVE_PROOF_FORMAT.md

@@ -1,570 +0,0 @@
-# xoonya Native Proof Format
-
-Status: design contract active
-
-Version: `xoonya-native-proof/v1`
-
-## Purpose
-
-xoonya Native is the optional native proof format for xoonya proof, result, attestation, and handoff artifacts.
-
-It is not a generic login token, bearer token, wallet credential, or replacement for JWT, OAuth, OIDC, DID/VC, or SD-JWT VC. Those remain useful interoperability lanes.
-
-xoonya Native exists for a different job:
-
-- preserve machine evidence without runtime lock-in
-- preserve deterministic replay truth
-- preserve proof integrity across runtimes
-- carry result-package and handoff integrity without forcing one identity, chain, wallet, or credential ecosystem
-- give agents a native machine-proof format that is smaller, stricter, and easier to replay than human/web credential containers
-
-## Native Design Carry-In
-
-xoonya Native keeps the useful design substance and expresses it directly as xoonya. The durable invention is the split between:
-
-- a fixed-size hot-path commitment atom
-- a variable-size cold-path proof envelope
-- deterministic validation and error behavior
-- semantic-free core bytes
-- optional profiles above the core for economics, registry lifecycle, anchors, and proof material
-
-That is substantial. It does not compete with JWT, DID, VC, SD-JWT VC, WebAuthn, COSE, JWS, or future PQC systems for their own jobs. It competes in a narrower and more machine-native category: deterministic, replayable machine evidence that can be verified without accepting JSON ambiguity, runtime-specific state, or a single identity ecosystem.
-
-The strongest long-term posture is:
-
-- keep the native core as a commitment primitive, not a signature or credential container
-- put signatures, credentials, attestations, anchors, settlement refs, and ZK artifacts in envelopes or profiles
-- keep external formats as interop lanes
-- let xoonya Native be the format agents choose when they want byte-stable proof rather than broad web credential compatibility
-
-## Doctrine
-
-- xoonya remains method-agnostic.
-- Native proof is first-class but optional.
-- External proof and credential formats stay supported as registry methods or integration lanes.
-- The native format optimizes for deterministic machine proof, not human web sessions.
-- No single algorithm, chain, wallet, identity system, or credential ecosystem is mandatory.
-- Signature, encryption, ZK, settlement, and governance semantics do not enter the hot-path atom.
-- Version lines are frozen when published; no silent soft forks.
-
-## Layered Model
-
-### L0: Native Atom
-
-The atom is the hot-path commitment record. It is fixed length, byte-oriented, and semantic-free.
-
-It exists to answer only:
-
-> Which typed machine identity committed to which payload hash under which frozen version line?
-
-It does not contain signatures, timestamps, prices, settlement references, custody references, policy decisions, or runtime metadata.
-
-### L1: Canonical Payload Or Intent
-
-The payload or intent bytes carry deterministic machine meaning.
-
-For current xoonya this is represented by `canonical_event`. For a future formal atom line, this should become a fixed binary or tightly canonicalized payload profile where every field order, integer width, unknown-field rule, and replay rule is specified.
-
-JSON may remain a public SDK and service convenience, but the native standard should not depend on loose JSON interpretation for the hot path.
-
-### L2: Proof Envelope
-
-The proof envelope carries signatures, public-key refs, DID/VC/JWT/SD-JWT VC references, threshold witnesses, WebAuthn attestations, ZK proof refs, anchor refs, and finality refs.
-
-The envelope is allowed to be variable length because it is not the high-frequency atom.
-
-### L3: Profiles
-
-Profiles define evidence semantics without polluting the atom. Examples:
-
-- registry lifecycle profile
-- economic receipt profile
-- batch inclusion profile
-- anchor/finality profile
-- dispute/review profile
-
-Profiles are versioned independently.
-
-### L4: Runtime And Policy Consumers
-
-xytara, agent runtimes, settlement systems, operator dashboards, and partner verifiers consume xoonya evidence. They must not redefine the atom byte layout.
-
-## Native Atom Version Ladder
-
-### `xoonya-native-atom/v1`
-
-Canonical xoonya Native byte identity: `XNYA`.
-
-Purpose: classical minimal identity and payload commitment.
-
-Fixed size: `58` bytes.
-
-Shape:
-
-```text
-MAGIC(4) | VERSION(1) | TYPE(1) | AGENT_ID(20) | PAYLOAD_HASH(32)
-```
-
-Rules:
-
-- `MAGIC` is ASCII `XNYA`.
-- `VERSION` is `0x01`.
-- `TYPE` is a small deterministic record type.
-- `AGENT_ID` is a 20-byte identity digest for classical compact anchoring.
-- `PAYLOAD_HASH` is a 32-byte payload commitment, or all zero bytes only when payload is absent.
-- Present payloads whose computed hash equals the all-zero sentinel must be rejected.
-
-Use when:
-
-- extreme compactness matters
-- the identity material is classical-era crypto
-- the receipt is an anchor or dispute root, not the full proof
-
-### `xoonya-native-atom/v2`
-
-Canonical xoonya Native byte identity: `XNYA`.
-
-Purpose: PQ-horizon identity anchoring while preserving the same fixed commitment philosophy.
-
-Fixed size: `70` bytes.
-
-Shape:
-
-```text
-MAGIC(4) | VERSION(1) | TYPE(1) | AGENT_ID(32) | PAYLOAD_HASH(32)
-```
-
-Rules:
-
-- `MAGIC` remains ASCII `XNYA`.
-- `VERSION` is `0x02`.
-- `AGENT_ID` is `SHA256("xoonya:agent:v2:" || type_prefix || raw_identity_bytes)`.
-- `PAYLOAD_HASH` is `SHA256("xoonya:payload:v2:" || payload_bytes)`, or all zero bytes only when payload is absent.
-- Present payloads whose computed hash equals the all-zero sentinel must be rejected.
-- v1 and v2 may coexist forever; no auto-migration is implied.
-
-Use when:
-
-- long-horizon identity anchoring matters
-- PQC public keys, hardware-backed credentials, or large identity material may be anchored
-- implementers need a stronger identity digest without adding signature material to the atom
-
-### `xoonya-native-atom/v3-contingency`
-
-This is not an implementation target.
-
-It is a contingency line only if SHA-256 or the prevailing digest assumption changes materially. A future v3 should stay fixed-length and deterministic, most likely by moving to a different digest family with explicit domain separation. It should not introduce runtime negotiation inside the core.
-
-## Current xoonya Object Model
-
-### `canonical_event`
-
-Current version: `canonical-event-bundle/v1`
-
-This is the deterministic event input. It is the stable machine-event shape that can be replayed by other runtimes.
-
-### `native_receipt`
-
-Current version: `receipt/v1`
-
-This binds a canonical event commitment to an agent identity, domain, sequence, and verification method.
-
-### `proof_bundle`
-
-Current version: `proof-bundle/v1`
-
-This carries the canonical event, receipt, optional anchors, optional attestations, optional evidence references, optional batch references, and metadata.
-
-### `native_envelope`
-
-Planned version: `xoonya-native-proof/v1`
-
-This is the formal wrapper for native proof material. It should carry:
-
-- method
-- signature suite or digest suite
-- identity reference
-- public key reference when applicable
-- proof material
-- optional anchors
-- optional external attestation refs
-- optional settlement or finality refs
-
-## Current Native Method
-
-### `xoonya-native-sha256-v1`
-
-Implemented.
-
-This verifies a deterministic native digest over canonical receipt signing material and event commitment. It is useful for replayable local proof integrity and conformance.
-
-It is not the final signed native standard by itself.
-
-### `xoonya-native-signed-v1`
-
-Implemented.
-
-This adds a native signature envelope whose `public_key_ref` is self-bound to the public key material carried inside the proof (`public_key_ref == sha256(SPKI DER)` of that same key), and whose signature covers the receipt signing material, event commitment, `identity_ref`, and `public_key_ref`. The format declares its signature suite instead of hardcoding one global algorithm.
-
-The verifier checks key self-binding and the signature, not identity ownership. `identity_ref` and `agent_identity` are free strings: any key can sign a proof that claims any identity, and that proof self-verifies. Identity binding therefore requires a trust root supplied by the verifier (`trusted_public_key_refs` or `expected_public_key_ref`, see "Verification Classes, Strict Mode, And Trust Roots" below). Without a trust root the result is `cryptographically_verified: true` with `trust_root_applied: false`, which means "this key signed this receipt", not "this identity signed this receipt".
-
-Required signed-native fields:
-
-- `method`
-- `signature_suite`
-- `identity_ref`
-- `public_key_ref`
-- `proof_material`
-
-Implemented suites:
-
-- `ed25519`
-- `secp256k1`
-- `p256`
-
-Implemented PQ suites (usable only inside `xoonya-native-hybrid-v1`):
-
-- `ml-dsa-65` (FIPS 204)
-- `slh-dsa-sha2-128f` (FIPS 205)
-
-Declared suite registry entries that never verify:
-
-- `webauthn-cose` (`maturity: planned`)
-- `dilithium` (`status: deprecated_placeholder`, `deprecated_alias_of: ml-dsa-65`)
-- `falcon` (`status: deprecated_placeholder`, no registered successor yet)
-- `sphincs-plus` (`status: deprecated_placeholder`, `deprecated_alias_of: slh-dsa-sha2-128f`)
-
-The three `deprecated_placeholder` entries are legacy pre-standard names kept only so existing registry consumers keep resolving them; new material must use the ML-DSA/SLH-DSA identifiers. The atom commits to proof material; it does not validate these suites directly. Only suites with implemented validators should be described as verified.
-
-### `xoonya-native-anchored-v1`
-
-Implemented.
-
-This adds deterministic anchor binding for chain transaction refs, batch inclusion refs, finality refs, content hashes, and external attestation refs without changing the atom or base proof object model.
-
-Required anchor fields:
-
-- `anchor_id`
-- `anchor_kind`
-- `anchor_ref`
-- `anchor_hash_sha256`
-
-Optional anchor fields:
-
-- `network`
-- `finality_state`
-- `observed_at_iso`
-- `provider_ref`
-- `inclusion_proof_ref`
-
-Native anchored proof material:
-
-- `method = xoonya-native-anchored-v1`
-- `base_method = xoonya-native-sha256-v1`
-- `anchor_refs`
-- `proof_material.anchor_root_sha256`
-- `proof_material.binding_material_sha256`
-
-Important boundary:
-
-- xoonya verifies that the receipt and event commitment bind to the declared anchors.
-- xoonya does not independently assert that an external chain, settlement provider, or attestation issuer is truthful.
-- External finality or provider verification remains a higher layer.
-
-## Native Payload Profile
-
-Implemented profile: `xoonya-native-payload-profile/v1`
-
-The payload profile formalizes the old "no loose JSON ambiguity" requirement without changing the `XNYA` atom. It is an optional strict binary payload profile for machine evidence that needs stable bytes before the atom commits to the payload hash.
-
-Canonical binary shape:
-
-```text
-MAGIC(4="XNYP") | VERSION(1) | SCHEMA_HASH(32) | FIELD_COUNT(1) | FIELD*
-FIELD = FIELD_ID(uint16be) | FIELD_TYPE_ID(uint8) | LENGTH(uint16be) | VALUE(bytes)
-```
-
-Implemented field types:
-
-- `bytes32`
-- `bytes20`
-- `uint64`
-- `utf8`
-- `bool`
-
-Canonical rules:
-
-- binary profile, not JSON
-- schema reference is committed as a SHA-256 schema hash
-- fields are sorted by `uint16` field id and then field type id
-- duplicate field id/type pairs are rejected
-- unknown field ids can be rejected by verifier policy
-- integers are big-endian fixed width
-- floats, null, undefined, functions, and symbolic values are not supported
-- payload hash is SHA-256 over `xoonya:payload-profile:v1:` plus canonical profile bytes
-
-This gives xoonya a durable standard-grade payload path while keeping richer JSON, CBOR, DID/VC, JWT, or partner evidence envelopes available as external or higher-layer profiles. If deterministic CBOR is later needed, it should be a separate profile with its own vectors and reject rules, not a silent change to this binary profile.
-
-Reference vectors ship at `vectors/native-payload-profile-vectors.json`.
-
-## Native Line-Rate Frame
-
-Implemented profile: `xoonya-native-line-rate-frame/v1`
-
-The line-rate frame is an optional transport fast-reject wrapper around an existing `XNYA` atom. It exists for future machine/network paths that want cheap early rejection before heavier policy checks.
-
-Frame shape:
-
-```text
-XNYA_ATOM(58 or 70 bytes) | CHECKSUM(2 bytes)
-```
-
-The checksum is the first two bytes of SHA-256 over `xoonya:line-rate-frame:v1:` plus the atom bytes. Supported frame sizes are 60 bytes for atom v1 and 72 bytes for atom v2.
-
-Important boundary:
-
-- the frame does not change the atom layout
-- the frame does not add signatures or encryption
-- the frame does not prove external finality or provider truth
-- the frame is a transport fast-reject profile only
-
-## Planned Native Methods
-
-### `xoonya-native-hybrid-v1`
-
-Implemented for registered runtime-supported suite pairs.
-
-This method provides stronger-crypto and PQ-sensitive proof lanes without redefining the rest of the native proof model. It is not the global default; it is the promoted higher-assurance lane when a runtime can actually verify the declared classical and PQ signatures together.
-
-The current rule is strict:
-
-- only registered runtime-supported suite pairs may be claimed as verified
-- current first-class promoted verification is `ed25519+ml-dsa-65`
-- other candidate hybrid combinations remain non-claimable until runtime support, vectors, and deterministic error behavior exist
-
-Required hybrid fields:
-
-- `method`
-- `hybrid_suite`
-- `identity_ref`
-- `classical_public_key_ref`
-- `pq_public_key_ref`
-- `classical_public_key_material`
-- `pq_public_key_material`
-- `proof_material.classical_signature`
-- `proof_material.pq_signature`
-- `proof_material.signing_material_sha256`
-
-Current adversarial expectations include:
-
-- tampered PQ signature rejects as `native_hybrid_pq_signature_invalid`
-- key-binding mismatches reject as `native_hybrid_public_key_ref_mismatch`
-- downgrade attempts through external assertion methods reject as `signature_method_mismatch`
-- a valid dual signature from keys the verifier has not pinned for that `identity_ref` rejects as `native_hybrid_public_key_not_trusted` when a trust root is supplied
-
-This keeps the boundary honest: xoonya now verifies the hybrid lane where the runtime and vectors are real, and refuses to overclaim beyond that runtime-supported registry. The runtime-support probe for each suite pair runs once per process and is cached afterwards.
-
-## Verification Classes, Strict Mode, And Trust Roots
-
-Every result from `verifyProofBundle(bundle, options)` and `POST /v1/proof-bundles/verify` carries four extra fields:
-
-- `verification_class`: one of `cryptographic`, `digest`, `anchored_binding`, `structural`
-- `cryptographically_verified`: `true` only when a native signature was actually checked and the result is valid
-- `strict`: whether strict mode was active for that call
-- `trust_root_applied`: whether a verifier-supplied trust root constrained the accepted keys
-
-Classes by method:
-
-| Class | Methods | What was checked |
-| --- | --- | --- |
-| `cryptographic` | `xoonya-native-signed-v1`, `xoonya-native-hybrid-v1` | key self-binding plus a real classical and/or PQ signature over the signing material |
-| `digest` | `xoonya-native-sha256-v1`, `legacy-opreturn-v1` | an unkeyed deterministic digest; anyone can reproduce it, so it proves integrity and replayability, not authorship |
-| `anchored_binding` | `xoonya-native-anchored-v1` | an unkeyed digest binding to declared anchor refs; anchor truth and authorship stay external |
-| `structural` | `detached-assertion-v1`, `jwt-assertion-v1`, `did-vc-v1`, `sd-jwt-vc-v1`, `signed-envelope-v1`, `partner-proof-envelope-v1` | envelope shape, method registration, and canonical receipt binding only; the external signature must be verified by the external stack |
-
-`valid` keeps its historical meaning by default: a well-formed digest, anchored, or structural bundle is still `valid: true`, it just also says `cryptographically_verified: false`.
-
-Strict mode (`options.strict === true`, or `XOONYA_STRICT_VERIFY=1` in the environment) only accepts the `cryptographic` class. Deterministic rejection codes:
-
-- `digest_only_not_cryptographically_verified` for `digest` and `anchored_binding` results
-- `external_verification_required` for `structural` results
-
-Trust roots pin which keys may speak for an identity. Options:
-
-- `expected_public_key_ref`: the proof's `public_key_ref` (native signed) or classical/hybrid ref (native hybrid) must equal this value
-- `expected_classical_public_key_ref`, `expected_pq_public_key_ref`, `expected_hybrid_public_key_ref`: lane-specific pins for hybrid proofs
-- `trusted_public_key_refs`: object keyed by `identity_ref` (falling back to `agent_identity`). Values are a ref string, an array of ref strings, or `{ classical, pq, hybrid }` where each lane is a string or array. A string or array pins the classical lane; use the object form to pin the PQ lane of a hybrid proof.
-
-When any trust-root option is present, `trust_root_applied` is `true` and native verification fails closed: an identity missing from the map, a lane that cannot be satisfied by the proof (for example a PQ pin against a classical-only proof), or any ref outside the pinned set rejects with `native_public_key_not_trusted` (native signed) or `native_hybrid_public_key_not_trusted` (native hybrid). These checks run after the signature check, so a trust-root rejection always means "valid signature, untrusted key". Digest, anchored, and structural methods carry no key and are unaffected by trust roots; use strict mode to reject them.
-
-The `scripts/verify_forgery_resistance.js` verifier (`npm run verify:forgery-resistance`) pins this behavior, including the documented key-substitution limitation without a trust root.
-
-## Crypto And Identity Support Boundary
-
-xoonya Native supports cryptographic ecosystems by committing to their canonical identity or proof material. It does not become those ecosystems.
-
-Cleanly supported above the atom:
-
-- secp256k1 ECDSA/Schnorr identities and signatures
-- Ed25519/X25519 identities and signatures
-- P-256/WebAuthn/COSE public-key material
-- DID and DIDComm identity references
-- JWT/JWS and signed envelope assertions
-- DID/VC and SD-JWT VC evidence references
-- ML-DSA (FIPS 204), SLH-DSA (FIPS 205), and future PQ signature public-key material; the legacy `dilithium`, `falcon`, and `sphincs-plus` registry names are deprecated placeholders that never verify
-- HPKE, TLS, AES-GCM, or encrypted payload commitments
-- ZK proof, circuit, verifier-key, and public-input commitments
-
-Important boundary:
-
-- xoonya Native provides commitments and proof binding.
-- It does not provide encryption, forward secrecy, access control, custody, or transport security.
-- Those systems remain external layers.
-
-## Interop Boundary
-
-External methods remain first-class:
-
-- `jwt-assertion-v1`
-- `did-vc-v1`
-- `sd-jwt-vc-v1`
-- `signed-envelope-v1`
-- `partner-proof-envelope-v1`
-
-For these methods, xoonya checks canonical receipt shape, registration, and method boundary. Method-specific cryptographic verification stays with the relevant verifier stack unless and until a verifier is added behind that method.
-
-## External Proof Import Adapter
-
-Implemented version: `xoonya-external-proof-import-adapter-v1`
-
-The import adapter is the bridge between external proof envelopes and xoonya proof bundles.
-
-It accepts registered external proof methods:
-
-- `detached-assertion-v1`
-- `jwt-assertion-v1`
-- `did-vc-v1`
-- `sd-jwt-vc-v1`
-- `signed-envelope-v1`
-- `partner-proof-envelope-v1`
-
-It then emits:
-
-- a canonical import event
-- a xoonya receipt bound to the selected method
-- a proof bundle
-- bundle verification
-- an import review that states the external-verifier boundary
-
-Required import fields:
-
-- `method`
-- `external_proof`
-
-Optional import fields:
-
-- `import_ref`
-- `external_ref`
-- `issuer_ref`
-- `subject_ref`
-- `declared_hash_sha256`
-- `evidence_refs`
-- `profile_refs`
-- `policy_ref`
-- `received_at_iso`
-
-The adapter verifies:
-
-- the method is registered and importable
-- the external proof material is present
-- the material hash matches `declared_hash_sha256` when supplied
-- the import material is deterministically bound into a canonical xoonya event
-- the emitted receipt and proof bundle verify structurally
-
-The adapter does not claim:
-
-- JWT/JWS signature truth
-- DID resolution truth
-- VC revocation truth
-- SD-JWT disclosure truth
-- partner policy truth
-- external issuer correctness
-
-Those remain the job of the relevant external verifier. xoonya's job is to bind the external proof into replayable proof continuity without pretending to own another ecosystem's trust root.
-
-## Competitive Positioning
-
-xoonya Native should be positioned as deterministic machine evidence, not as a universal identity credential.
-
-Compared with JWT/JWS:
-
-- JWT wins for broad web compatibility and signed JSON claims.
-- xoonya Native wins when a machine needs fixed validation rules, replayable proof bundles, and no ambiguity about canonical evidence bytes.
-
-Compared with DID/VC:
-
-- DID/VC wins for rich identity and credential ecosystems.
-- xoonya Native wins when the primary artifact is a compact machine receipt or proof root rather than a human credential.
-
-Compared with chain-specific proofs:
-
-- chain-specific proofs win for native settlement proof on that chain.
-- xoonya Native wins when proof must cross runtimes, chains, settlement rails, and credential systems.
-
-The unique claim is not "better than everything." The unique claim is:
-
-> a minimal, deterministic, replayable, chain-neutral machine-evidence standard with optional native envelopes and external verifier lanes.
-
-## Protection And Standardization Strategy
-
-Technical protection comes from precision, conformance, and governance:
-
-- freeze byte layouts once published
-- publish canonical conformance vectors
-- publish adversarial vectors for malformed bytes, wrong method, wrong key, wrong payload, downgrade attempts, and non-canonical encoding
-- publish reference validators in more than one language
-- require deterministic error codes
-- maintain a method registry and suite registry
-- treat non-conforming variants as separate formats, not soft forks
-- keep public claims bounded to implemented and tested surfaces
-
-Commercial and legal protection should be handled explicitly:
-
-- preserve authorship and publication history through tagged releases and checksummed specs
-- use clear Apache-2.0 implementation licensing where intended
-- maintain trademark/brand usage rules for the xoonya name and native conformance marks
-- get qualified IP counsel before relying on patent, trademark, or defensive-publication strategy
-
-## Standardization Steps
-
-1. Keep `xoonya-native-sha256-v1` as the implemented deterministic method.
-2. Publish the XNYA atom ladder as xoonya Native design, without forcing the current SDK to expose raw atoms prematurely.
-3. Keep `xoonya-native-signed-v1` behind the existing method registry with Ed25519 verification implemented first.
-4. Maintain the signature suite registry and only mark suites as verified when validators exist.
-5. Keep conformance vectors for native signed proof.
-6. Keep adversarial vectors for wrong key, wrong method, tampered event, tampered envelope, and method downgrade.
-7. Add cross-runtime canonicalization vectors.
-8. Keep anchor and attestation reference vectors for `xoonya-native-anchored-v1`.
-9. Keep the native atom conformance pack and stable atom reject codes current.
-10. Keep `xoonya-native-payload-profile/v1` as the strict binary payload profile and add any future deterministic CBOR profile separately.
-11. Keep `xoonya-native-line-rate-frame/v1` as a transport profile around atoms, not a mutation of the atom core.
-12. Keep external methods as interop lanes instead of turning native proof into a format war.
-
-## Public Surfaces
-
-- `GET /v1/proof-center/native-standard`
-- `GET /v1/proof-center/native-standard/summary`
-- `GET /v1/proof-center/native-hybrid-readiness`
-- `GET /v1/proof-center/native-hybrid-readiness/summary`
-- `GET /v1/proof-center/native-standardization`
-- `GET /v1/proof-center/native-standardization/summary`
-- `GET /v1/proof-center/native-payload-profile`
-- `GET /v1/proof-center/native-payload-profile/summary`
-- `GET /v1/proof-center/native-line-rate-frame`
-- `GET /v1/proof-center/native-line-rate-frame/summary`
-- `GET /v1/proof-center/native-anchor-profile`
-- `GET /v1/proof-center/native-anchor-profile/summary`
-- `GET /v1/proof-center/import-adapter`
-- `GET /v1/proof-center/import-adapter/summary`
-- `POST /v1/proof-center/import-adapter/review`
-- `POST /v1/proof-center/import-adapter/run`

package/XOONYA_NATIVE_STANDARD_GOVERNANCE.md

@@ -1,119 +0,0 @@
-# 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.