xoonya 3.1.0 → 3.1.2

package/README.md

@@ -1,808 +1,843 @@
-# xoonya
-
-`xoonya` is the proof and review foundation for machine actions.
-
-It exists to make machine evidence:
-
-- deterministic
-- portable
-- minimal
-- verifiable
-- replayable
-
-This repo is the proof-side half of the final two-repo public stack. It focuses on canonical events, receipts, proof bundles, and verification. It does not own pricing, catalogs, workflow orchestration, payment rails, or settlement policy.
-
-The 10-phase public program is now complete. `xoonya` is in terminal closeout posture rather than active milestone build posture.
-
-## Public Discovery
-
-The broader stack now has a canonical human front door and a canonical machine doorway:
-
-- https://www.naxytra.com/agents
-- https://www.naxytra.com/v1/agent-discovery-index
-- https://www.naxytra.com/v1/agent-discovery-index/summary
-- https://www.naxytra.com/.well-known/agent.json
-
-Use the human page when you want the shortest adoption landing page, and use the machine endpoints when a registry, crawler, or agent needs a stable public discovery surface.
-
-The shared control-plane contract documents are:
-
-- [OPERATIONAL_RECEIPT_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OPERATIONAL_RECEIPT_CONTRACT.md)
-- [MACHINE_IDENTITY_REGISTRY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/MACHINE_IDENTITY_REGISTRY_CONTRACT.md)
-- [CRYPTO_AGILITY_MATRIX.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/CRYPTO_AGILITY_MATRIX.md)
-- [AUTHORITY_BINDING_LIFECYCLE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/AUTHORITY_BINDING_LIFECYCLE_CONTRACT.md)
-- [PUBLIC_SURFACE_POLICY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/PUBLIC_SURFACE_POLICY_CONTRACT.md)
-- [OFFLINE_VERIFIABILITY_AND_RECOVERY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OFFLINE_VERIFIABILITY_AND_RECOVERY_CONTRACT.md)
-- [ADAPTER_CERTIFICATION_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/ADAPTER_CERTIFICATION_CONTRACT.md)
-- [TRUST_PORTABILITY_BOUNDARY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/TRUST_PORTABILITY_BOUNDARY_CONTRACT.md)
-- [SIGNED_AUDIT_PROVENANCE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/SIGNED_AUDIT_PROVENANCE_CONTRACT.md)
-
-## Public Boundary
-
-The public adoption story is intentionally narrow:
-
-- receive a handoff or event bundle
-- review it
-- verify it
-- emit a durable proof bundle
-
-`xoonya` should expose proof, review, and continuity. It should not force outside builders to learn runtime treasury or operator internals just to use the proof layer correctly.
-
-## Universal Proof Shape
-
-`xoonya` is intended to be usable from:
-
-- CLI and terminal
-- direct API calls
-- chat and agent environments that can submit handoff bundles
-- hosted or embedded review flows
-- partner systems that need deterministic proof verification
-
-The shortest public proof loop is:
-
-- receive a handoff or event bundle
-- review it
-- verify it
-- emit a durable proof bundle
-- preserve governance and continuity context when needed
-
-The frozen proof-side fact model for `3.0.0` closeout is documented in:
-
-- [XOONYA_PROOF_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_PROOF_TRUTH_MODEL.md)
-- [OPERATIONAL_RECEIPT_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OPERATIONAL_RECEIPT_CONTRACT.md)
-
-Machine-readable proof-truth surfaces:
-
-- `GET /v1/proof-truth`
-- `GET /v1/proof-truth/summary`
-- `GET /v1/proof-truth/:object_id`
-
-The frozen multi-surface proof default-path model for `3.0.0` closeout is documented in:
-
-- [XOONYA_DEFAULT_PATH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_DEFAULT_PATH_MODEL.md)
-
-Machine-readable proof default-path surfaces:
-
-- `GET /v1/default-path`
-- `GET /v1/default-path/summary`
-- `GET /v1/default-path/:surface_id`
-
-The frozen bridge, governance, trust-portability, and verification followthrough boundary for `3.0.0` closeout is documented in:
-
-- [XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md)
-
-Machine-readable followthrough-truth surfaces:
-
-- `GET /v1/followthrough-truth`
-- `GET /v1/followthrough-truth/summary`
-- `GET /v1/followthrough-truth/:profile_id`
-
-The current proof breadth already includes:
-
-- canonical events, receipts, and proof bundles
-- result-package handoff review and run paths
-- bridge and compatibility review surfaces
-- governance, dispute, and signoff support
-- proof-side continuity for economic consequence carry
-- proof-adjacent integration registration and review
-
-It also already carries broader first-class proof and interoperability lanes for:
-
-- framework continuity across `langchain`, `langgraph`, `semantic_kernel`, `autogen`, `crewai`, and `llamaindex`
-- native and external verification methods such as `XNYA`, JWT assertion, DID VC, SD-JWT VC, signed-envelope, detached assertion, and partner proof-envelope compatibility
-- operator and artifact lanes such as telemetry, provenance, artifact distribution, shared signals, feature control, trust portability, and external proof import review
-
-If you want the broadest machine-readable census for these already-core proof lanes, inspect:
-
-- `GET /v1/integration-matrix`
-- `GET /v1/proof-bridge`
-- `GET /v1/telemetry`
-- `GET /v1/provenance`
-- `GET /v1/artifact-distribution`
-- `GET /v1/shared-signals`
-- `GET /v1/feature-control`
-- `GET /v1/adapter-certification`
-- `GET /v1/trust-portability-boundary`
-- `GET /v1/signed-audit-provenance`
-
-## One-Line After Install
-
-If you only run two commands after install, use:
-
-- `xoonya start-here`
-- `xoonya first-run`
-- `xoonya first-run --verify-native --pretty`
-- `xoonya release --summary`
-- `xoonya conformance`
-
-If you want the shortest machine-readable discovery path, inspect:
-
-- `GET /v1/providers`
-- `GET /v1/frameworks`
-- `GET /v1/integration-matrix`
-- `GET /v1/proof-bridge`
-- `GET /v1/telemetry`
-- `GET /v1/provenance`
-- `GET /v1/adapter-certification`
-- `GET /v1/trust-portability-boundary`
-- `GET /v1/signed-audit-provenance`
-
-If you are working on shared evidence, inspect the operational receipt contract pack:
-
-- `buildOperationalReceiptContractPack()`
-- `summarizeOperationalReceiptContractPack()`
-
-If you are working on machine identity, inspect the registry contract pack:
-
-- `buildMachineIdentityRegistryContractPack()`
-- `summarizeMachineIdentityRegistryContractPack()`
-
-If you are working on crypto agility, inspect the matrix pack:
-
-- `buildCryptoAgilityMatrixPack()`
-- `summarizeCryptoAgilityMatrixPack()`
-
-If you are working on binding lifecycle, inspect the lifecycle pack:
-
-- `buildAuthorityBindingLifecycleContractPack()`
-- `summarizeAuthorityBindingLifecycleContractPack()`
-
-If you are working on public route policy, inspect the surface policy pack:
-
-- `buildPublicSurfacePolicyContractPack()`
-- `summarizePublicSurfacePolicyContractPack()`
-
-If you are working on offline recovery, inspect the recovery pack:
-
-- `buildOfflineVerifiabilityRecoveryContractPack()`
-- `summarizeOfflineVerifiabilityRecoveryContractPack()`
-
-If you are working on adapter certification, inspect the certification pack:
-
-- `buildAdapterCertificationContractPack()`
-- `summarizeAdapterCertificationContractPack()`
-
-If you are working on trust portability boundaries, inspect the boundary pack:
-
-- `buildTrustPortabilityBoundaryContractPack()`
-- `summarizeTrustPortabilityBoundaryContractPack()`
-
-If you are working on signed audit and provenance, inspect the audit/provenance pack:
-
-- `buildSignedAuditProvenanceContractPack()`
-- `summarizeSignedAuditProvenanceContractPack()`
-
-## Start Here
-
-If you are new to the proof-side package, use this order:
-
-1. read [START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/START_HERE.md)
-2. run `node examples/package_quickstart.js`
-3. run `npm run verify:all`
-4. use [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/FINAL_CONTRACT.md) and [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/SERVICE_CONTRACT.md) as the durable public contract
-
-If you are reading the GitHub repo and want deeper product context beyond the npm starter path, continue with:
-
-- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-
-If you want one concrete cross-repo adoption story, start with:
-
-- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
-
-If you want the shortest neutral external-adoption bundle, continue with:
-
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
-- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/EXAMPLE_PATHS.md)
-- `node examples/partner_proof_walkthrough.js`
-
-If you are integrating from outside the stack, also read:
-
-- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
-- [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
-
-If you want the broader already-core proof continuity layers, continue with:
-
-- [XOONYA_NATIVE_PROOF_FORMAT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_NATIVE_PROOF_FORMAT.md)
-- [XOONYA_NATIVE_ATOM_SPEC.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_NATIVE_ATOM_SPEC.md)
-- [XNYA_REFERENCE_IMPLEMENTATIONS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XNYA_REFERENCE_IMPLEMENTATIONS.md)
-- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
-- [XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md)
-
-## Production Path
-
-The intended production-facing proof path is now:
-
-1. receive the transaction-side handoff or default path artifact from `xytara`
-2. inspect the proof-side review posture
-3. confirm carry and run posture
-4. emit and verify the proof-native completion path
-
-The rest of this README explains the broader route ladder, but the public starting posture should now be understandable from that one proof-side path.
-
-For a direct one-line proof-side review of a carried handoff bundle, use the bundled CLI:
-
-```bash
-xoonya-review --file ./handoff.json --summary
-```
-
-For release-grade adoption posture, inspect:
-
-- `GET /v1/release-pack`
-- `GET /v1/release-pack/summary`
-- `GET /v1/release-pack/comparison`
-- `GET /v1/release-pack/comparison/summary`
-- `GET /v1/release-pack/adoption`
-- `GET /v1/release-pack/adoption/summary`
-- `GET /v1/release-pack/scenarios`
-- `GET /v1/release-pack/scenarios/summary`
-- `GET /v1/release-pack/launch`
-- `GET /v1/release-pack/launch/summary`
-- `GET /v1/release-manifest`
-- `GET /v1/release-manifest/summary`
-- `GET /v1/release-notes`
-- `GET /v1/release-notes/summary`
-- `GET /v1/release-center`
-- `GET /v1/release-center/summary`
-- `GET /v1/release-history`
-- `GET /v1/release-history/summary`
-- `GET /v1/phases`
-- `GET /v1/phases/summary`
-- `GET /v1/phases/phase-1`
-- `GET /v1/phases/phase-1/summary`
-- `GET /v1/publish-plan`
-- `GET /v1/publish-plan/summary`
-- `GET /v1/ecosystem-entry`
-- `GET /v1/ecosystem-entry/summary`
-- `GET /v1/launch-narrative`
-- `GET /v1/launch-narrative/summary`
-- `GET /v1/outreach-proof`
-- `GET /v1/outreach-proof/summary`
-- `GET /v1/announcement-pack`
-- `GET /v1/announcement-pack/summary`
-- `GET /v1/release-candidate`
-- `GET /v1/release-candidate/summary`
-- `xoonya-release --summary`
-- `xoonya-release --comparison --summary`
-- `xoonya-release --adoption --summary`
-- `xoonya-release --scenarios --summary`
-- `xoonya-release --launch --summary`
-- `xoonya-release --manifest --summary`
-- `xoonya-release --notes --summary`
-- `xoonya-release --center --summary`
-- `xoonya-release --history --summary`
-- `xoonya-release --phases --summary`
-- `xoonya-release --phase-1 --summary`
-- `xoonya-release --ecosystem --summary`
-- `xoonya-release --narrative --summary`
-- `xoonya-release --outreach-proof --summary`
-- `xoonya-release --announcement --summary`
-- `xoonya-release --candidate --summary`
-
-These surfaces package the current proof-side value story, first-contact proof-review CLI path, proof-center posture, handoff/review/governance surfaces, and integration breadth into one machine-readable launch boundary.
-
-For explicit runtime-economics carry, the proof-side handoff boundary now also accepts a canonical `handoff_bundle` wrapper from `xytara` so the economic consequence seam stays contract-shaped across the two repos instead of being reassembled ad hoc by callers.
-
-That same carried bundle can now also ride inside the normal result-package handoff path:
-
-- if `xytara` sends `handoff_bundle.economic_consequence_handoff_bundle`
-- `xoonya` will validate it through the existing bounded handoff logic
-- normal result-package review and run surfaces will expose compact economic-conformance review data automatically
-- direct-pay or non-metered handoffs remain unaffected
-
-The package and service now also expose a default proof center surface so the intended proof-native path is easy to inspect directly:
-
-- canonical event bundle v1
-- receipt v1
-- proof bundle v1
-- compact compatibility helpers preserved, but not treated as the public conceptual center
-- proof remains settlement-agnostic and workflow-agnostic by default
-
-The current `1.6.0` companion slice adds guided default proof loops on top of that proof center:
-
-- default proof-loop catalog and detail routes
-- a direct proof-loop run route for the canonical proof-native path
-- package helpers that build, verify, and summarize the proof bundle boundary in one step
-
-This keeps `xoonya` narrow while making the intended proof path easier to inspect alongside the newer guided transaction-loop work in `xytara`.
-
-The current `1.7.0` companion slice adds a lightweight transaction proof-handoff surface:
-
-- a transaction proof-handoff center that states the expected handoff contract
-- a direct handoff run path that turns transaction-side proof handoff data into a proof-native bundle
-- summary helpers that make the recommended proof follow-through explicit without widening proof scope
-
-The current `1.8.0` companion slice extends that same proof-side carry to richer grouped interaction spine handoffs:
-
-- an interaction-spine handoff center and summary surface
-- a direct interaction-spine handoff run path for composed transaction spines
-- proof-side summaries that preserve both pre-commit and committed-ref context without importing commerce logic
-
-## Proof Model
-
-The primary proof model is layered:
-
-1. `Canonical Event Bundle`
-2. `Receipt`
-3. `Proof Bundle`
-4. optional domain-specific `Profiles`
-
-That means the center of gravity is now:
-
-- `canonicalizeEvent(...)`
-- `hashEvent(...)`
-- `emitReceipt(...)`
-- `buildProofBundle(...)`
-- `verifyProofBundle(...)`
-- `listProofVerificationMethods(...)`
-- `getProofVerificationMethod(...)`
-
-### Verification Methods
-
-`xoonya` keeps proof verification method-agnostic. The proof bundle verifier uses a small method registry instead of treating every non-empty signature as equally verified.
-
-Current built-in methods:
-
-- `legacy-opreturn-v1` verifies the compatibility OP_RETURN receipt path.
-- `detached-assertion-v1` accepts an explicit detached assertion after canonical receipt checks; cryptographic verification is expected to happen outside this helper.
-- `xoonya-native-sha256-v1` verifies xoonya's native deterministic digest format.
-- `xoonya-native-signed-v1` verifies xoonya's native signed proof envelope with Ed25519, secp256k1, and P-256 implemented through the explicit suite registry. Other suites stay registry-only until validators exist.
-- `xoonya-native-anchored-v1` verifies xoonya's native anchor-binding proof envelope for chain, batch, finality, content-hash, or external attestation refs. It verifies the binding, not the external provider or chain truth itself.
-- `jwt-assertion-v1` accepts compact JWT assertion envelopes after canonical receipt checks; JWT signature, issuer, and audience verification remain external to this helper.
-- `did-vc-v1` accepts DID/VC proof envelopes after canonical receipt checks; DID resolution and VC proof validation remain external to this helper.
-- `sd-jwt-vc-v1` accepts SD-JWT VC disclosure envelopes after canonical receipt checks; issuer, holder binding, and disclosure verification remain external to this helper.
-- `signed-envelope-v1` accepts generic signed envelopes after canonical receipt checks; envelope-specific signature verification remains external to this helper.
-- `partner-proof-envelope-v1` accepts partner-specific proof envelopes after canonical receipt checks; partner verifier policy remains external to this helper.
-
-`algorithm: "none"` is not a registered verification method and does not verify. External proof methods are first-class registry entries, but xoonya does not pretend to replace their own cryptographic verifier stacks. The proof core checks the canonical receipt, method registration, and method boundary; issuer-specific validation stays with the relevant JWT, DID/VC, SD-JWT VC, signed-envelope, or partner verifier.
-
-### xoonya Native Proof Format
-
-xoonya Native is the optional native proof/result/attestation format direction for machine proof. It is not a replacement for JWT, OAuth, OIDC, DID/VC, or SD-JWT VC. Those remain interoperability lanes.
-
-The native standard is xoonya's own fixed-size hot-path commitment atom, cold-path proof envelope, semantic-free core bytes, and deterministic validation. The current implemented native methods are `xoonya-native-sha256-v1`, `xoonya-native-signed-v1`, `xoonya-native-anchored-v1`, and `xoonya-native-hybrid-v1`. The signed native method verifies Ed25519, secp256k1, and P-256 today. The hybrid native method verifies only registered runtime-supported suite pairs, with `ed25519+ml-dsa-65` as the current promoted baseline and other pairings staying non-claimable until runtime support and vectors exist. The anchored native method binds receipts to declared anchor/finality/attestation refs without claiming the external system has been independently verified by xoonya.
-
-The atom ladder is treated as native xoonya design, not a runtime dependency: `xoonya-native-atom/v1` is the 58-byte classical commitment atom, `xoonya-native-atom/v2` is the 70-byte PQ-horizon identity commitment candidate, and `xoonya-native-atom/v3-contingency` stays reserved for a future digest-family shift only if the underlying hash assumptions materially change.
-
-The canonical xoonya Native atom magic is `XNYA`. No other magic value is part of the xoonya Native atom standard. The formal atom spec ships inside the `xoonya` package first; a separate standards repo can be extracted later if external governance needs it.
-
-XNYA atom conformance now includes stable machine-readable reject codes and adversarial vectors. Passing only the happy-path vectors is not enough to claim xoonya Native compatibility.
-
-The native payload profile is now explicit: `xoonya-native-payload-profile/v1` uses the binary `XNYP` magic and typed fields with deterministic ordering, fixed-width integer encoding, unknown-field policy checks, and no floats or loose JSON semantics. The optional `xoonya-native-line-rate-frame/v1` wraps an existing 58-byte or 70-byte `XNYA` atom with a 2-byte checksum for transport fast rejection; it does not change the atom and does not claim signature, encryption, custody, settlement, or external finality truth.
-
-The `XNYA-compatible` mark is now defined as a conformance claim, not a marketing label. Implementations may use it only when atom bytes, payload profile rules, proof-envelope method behavior, adversarial vectors, and stable error codes match the published artifacts. The mark must not be used to claim unregistered or runtime-unsupported PQ/hybrid verification, live external-provider execution, chain finality, custody, identity/auth, or external issuer truth without separate verifier evidence. `xoonya-native-hybrid-v1` is now implemented only for registered runtime-supported suite pairs, with current first-class verification centered on `ed25519+ml-dsa-65`.
-
-The JavaScript `xoonya` package is the current canonical XNYA reference implementation. A Python candidate scaffold now verifies the XNYA atom, native atom adversarial, XNYP payload profile, line-rate frame, canonical event, receipt, and non-signed proof-bundle vectors independently. It also verifies Ed25519 native signed vectors when Python's optional `cryptography` package is installed, otherwise it reports the deterministic dependency gate. It is not yet a full second reference until always-on signature-suite parity, proof-bundle round trips, and the full promotion gates pass. Rust remains planned until a verified vector-parity implementation exists.
-
-Run `npm run verify:reference-python-crypto` to create an isolated temporary Python virtual environment, install the optional crypto dependency, and require the Ed25519 native signed vector to verify. Run `npm run verify:reference-rust-scaffold` to check the packaged source-only Rust scaffold and its non-promotion boundary.
-
-See [XOONYA_NATIVE_PROOF_FORMAT.md](./XOONYA_NATIVE_PROOF_FORMAT.md).
-See [XOONYA_NATIVE_ATOM_SPEC.md](./XOONYA_NATIVE_ATOM_SPEC.md).
-See [XOONYA_NATIVE_STANDARD_GOVERNANCE.md](./XOONYA_NATIVE_STANDARD_GOVERNANCE.md).
-See [XNYA_CONFORMANCE_MARK.md](./XNYA_CONFORMANCE_MARK.md).
-See [XNYA_REFERENCE_IMPLEMENTATIONS.md](./XNYA_REFERENCE_IMPLEMENTATIONS.md).
-See [CROSS_RUNTIME_POSTURE.md](./CROSS_RUNTIME_POSTURE.md).
-
-## Compatibility Surface
-
-Legacy compact receipt and profile helpers are still available during alignment:
-
-- `createReceipt(...)`
-- `verifyReceipt(...)`
-- `createReceiptV2(...)`
-- `verifyReceiptV2(...)`
-- `createProofEnvelopeV1(...)`
-- `verifyProofEnvelopeV1(...)`
-- `createxoonyaNativeAtomV1(...)`
-- `createxoonyaNativeAtomV2(...)`
-- `verifyxoonyaNativeAtom(...)`
-- `createEconomicReceiptProfileV1(...)`
-- `verifyEconomicReceiptProfileV1(...)`
-- `createRegistryProfileV1(...)`
-- `verifyRegistryProfileV1(...)`
-
-Those helpers remain verified so current receipt/profile consumers are not broken while the newer proof model becomes the primary public direction.
-
-## Package Quickstart
-
-Run:
-
-```bash
-node examples/package_quickstart.js
-```
-
-The package quickstart demonstrates:
-
-- proof integration discovery and certification posture
-- staged proof-integration registration and snapshot export
-- legacy compact receipt verification
-- legacy proof-envelope verification
-- canonical event creation
-- canonical receipt emission
-- proof bundle construction
-- proof bundle verification
-- transaction proof-handoff follow-through
-- proof-side bridge carry for explicit economic consequence review when runtime economics need proof-adjacent preservation
-
-## Service Quickstart
-
-Run:
-
-```bash
-npm start
-```
-
-Then in another shell:
-
-```bash
-curl -X POST http://127.0.0.1:4310/v1/events/hash ^
-  -H "content-type: application/json" ^
-  -d "{\"event\":{\"version\":\"canonical-event-bundle/v1\",\"domain_id\":\"demo\",\"sequence\":\"1\",\"actor_id\":\"agent-1\",\"adapter_source\":\"curl\",\"event_type\":\"demo.event\",\"event_hash\":\"abababababababababababababababababababababababababababababababab\"}}"
-```
-
-Environment example:
-
-- [`.env.example`](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/.env.example)
-
-## Service Routes
-
-Primary proof-model routes:
-
-- `GET /health`
-- `GET /v1/proof-center`
-- `GET /v1/proof-center/summary`
-- `GET /v1/proof-center/native-standard`
-- `GET /v1/proof-center/native-standard/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`
-- `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-conformance-mark`
-- `GET /v1/proof-center/native-conformance-mark/summary`
-- `GET /v1/proof-center/native-reference-implementations`
-- `GET /v1/proof-center/native-reference-implementations/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/review/summary`
-- `POST /v1/proof-center/import-adapter/run`
-- `GET /v1/proof-center/default-loops`
-- `GET /v1/proof-center/default-loops/summary`
-- `GET /v1/proof-center/default-loop`
-- `POST /v1/proof-center/default-loops/run`
-- `GET /v1/proof-center/transaction-handoff`
-- `GET /v1/proof-center/transaction-handoff/summary`
-- `POST /v1/proof-center/transaction-handoff/run`
-- `GET /v1/proof-center/result-package-handoff`
-- `GET /v1/proof-center/result-package-handoff/summary`
-- `GET /v1/proof-center/governance`
-- `GET /v1/proof-center/governance/summary`
-- `GET /v1/proof-center/bridge`
-- `GET /v1/proof-center/bridge/summary`
-- `GET /v1/proof-center/bridge/profile-support`
-- `POST /v1/proof-center/governance/interpretation-validate`
-- `POST /v1/proof-center/governance/coordination`
-- `POST /v1/proof-center/governance/dashboard`
-- `POST /v1/proof-center/governance/operator-view`
-- `POST /v1/proof-center/governance/admin-view`
-- `POST /v1/proof-center/governance/dashboard-pack`
-- `POST /v1/proof-center/governance/workflow-pack`
-- `POST /v1/proof-center/governance/signoff-pack`
-- `POST /v1/proof-center/governance/disputes/summary`
-- `POST /v1/proof-center/governance/disputes/case-review`
-- `POST /v1/proof-center/governance/disputes/action`
-- `POST /v1/proof-center/governance/disputes/case-bundle`
-- `POST /v1/proof-center/governance/disputes/resolution-pack`
-- `POST /v1/proof-center/governance/console-pack`
-- `POST /v1/proof-center/governance/handoff-bundle`
-- `POST /v1/proof-center/governance/review-link`
-- `POST /v1/proof-center/bridge/receipt-wrap`
-- `POST /v1/proof-center/bridge/validator-verify`
-- `POST /v1/proof-center/bridge/receipt-ledger-handoff`
-- `POST /v1/proof-center/bridge/economic-handoff`
-- `POST /v1/proof-center/bridge/economic-conformance-pack`
-- `POST /v1/proof-center/bridge/operator-review-pack`
-- `POST /v1/proof-center/bridge/compatibility-pack`
-- `POST /v1/proof-center/bridge/workflow-pack`
-- `POST /v1/proof-center/bridge/admin-pack`
-- `POST /v1/proof-center/result-package-handoff/review`
-- `POST /v1/proof-center/result-package-handoff/review/summary`
-- `POST /v1/proof-center/result-package-handoff/review/extension-readiness`
-- `POST /v1/proof-center/result-package-handoff/review/extension-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/default-continuation`
-- `POST /v1/proof-center/result-package-handoff/review/default-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/contract-summary`
-- `POST /v1/proof-center/result-package-handoff/review/contract-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/contract-carry`
-- `POST /v1/proof-center/result-package-handoff/review/bridge-summary`
-- `POST /v1/proof-center/result-package-handoff/review/bridge-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/bridge-carry`
-- `POST /v1/proof-center/result-package-handoff/review/bridge-run`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-continuity`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-intake`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-intake-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-intake-carry`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-package-intake`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-package-carry`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-package-run`
-- `POST /v1/proof-center/result-package-handoff/review/execution-package`
-- `POST /v1/proof-center/result-package-handoff/review/execution-package-carry`
-- `POST /v1/proof-center/result-package-handoff/review/execution-package-run`
-- `POST /v1/proof-center/result-package-handoff/review/execution-contract`
-- `POST /v1/proof-center/result-package-handoff/review/execution-contract-carry`
-- `POST /v1/proof-center/result-package-handoff/review/execution-contract-run`
-- `POST /v1/proof-center/result-package-handoff/review/operating-contract`
-- `POST /v1/proof-center/result-package-handoff/review/operating-contract-carry`
-- `POST /v1/proof-center/result-package-handoff/review/operating-contract-run`
-- `POST /v1/proof-center/result-package-handoff/review/operating-interface`
-- `POST /v1/proof-center/result-package-handoff/review/operating-interface-carry`
-- `POST /v1/proof-center/result-package-handoff/review/operating-interface-run`
-- `POST /v1/proof-center/result-package-handoff/review/operating-integration`
-- `POST /v1/proof-center/result-package-handoff/review/operating-integration-carry`
-
-When `xytara` sends `handoff_bundle.economic_consequence_handoff_bundle`, `xoonya` now preserves a compact `economic_audit_summary` inside review output so proof-side operators can see the linked `account_ref`, `usage_meter_ref`, `credit_spend_ref`, `usage_units`, `pricing_band`, `payment_ref`, `settlement_ref`, `settlement_txid`, `settlement_finality_status`, `treasury_receipt_ref`, `proof_ref`, and `conformance_pack_ref` without re-deriving the carry by hand.
-- `POST /v1/proof-center/result-package-handoff/review/operating-integration-run`
-- `POST /v1/proof-center/result-package-handoff/review/operating-path`
-- `POST /v1/proof-center/result-package-handoff/review/operating-path-carry`
-- `POST /v1/proof-center/result-package-handoff/review/operating-path-run`
-- `POST /v1/proof-center/result-package-handoff/review/complete-default-path`
-- `POST /v1/proof-center/result-package-handoff/review/complete-default-path-carry`
-- `POST /v1/proof-center/result-package-handoff/review/complete-default-path-run`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-run`
-- `POST /v1/proof-center/result-package-handoff/run`
-
-The result-package review surface now also returns a durability summary so the preserved execution, economic, and proof-facing context is easier to inspect before proof-native execution.
-It also now exposes an extension-readiness summary so the stable post-review proof boundary is easier to treat as a reusable seam.
-It now also exposes a reusable-default continuation summary so that same stable post-review boundary is easier to reuse as a standard proof-side default path.
-It now also exposes a compact reusable-default boundary summary so the proof-side default seam can be treated as a stable public boundary, not just a recommended path.
-It now also exposes composition-contract summaries so the proof-side default seam can be treated more clearly as a stable public contract across review and run.
-It now also exposes compact contract-carry summaries so the stable proof-side contract context is easier to inspect directly without expanding proof scope.
-It now also exposes bridge summaries, bridge-boundary summaries, and bridge-carry summaries so the proof-side review seam is easier to treat as an adapter-ready bridge without widening proof scope.
-It now also exposes a bridge-run summary so that same proof-side bridge can be read directly as the final run posture instead of only as review-stage carry.
-It now also exposes a handoff-continuity summary so the proof-side bridge can be treated more clearly as a stable handoff contract into proof-native execution.
-It now also exposes a handoff-intake summary and handoff-intake-boundary summary so that same handoff contract can be consumed more directly as a stable proof-native intake surface for future adapters without widening proof scope.
-It now also exposes a handoff-intake-carry summary so the same proof-side intake surface can be reused more directly as compact consumable carry instead of only summary or boundary posture.
-It now also exposes a handoff-run summary so that same handoff contract can be read directly as the final proof-native run posture instead of only as continuity guidance.
-
-The Wave B governance carry-over line adds a bounded governance center on the proof side:
-
-- governance interpretation validation for receipt-ledger and result-package follow-through
-- governance coordination emission for the next proof-side/operator handoff step
-- governance dashboard, operator-view, admin-view, dashboard-pack, workflow-pack, and signoff-pack packaging
-- dispute summary, case review, metadata-only dispute action, case-bundle export, and resolution-pack export
-- console-pack, handoff-bundle, and explicit review-link surfaces for compact operator carry into the proof-side review/run ladder
-
-This keeps governance review attached to the proof-side operating shape without widening `xoonya` into a runtime or economics system.
-
-The Wave E bridge carry-over line adds a bounded bridge center on the proof side:
-
-- receipt-wrap support for compact compatibility receipts when an outside bridge still needs that bounded surface
-- validator-compatible verification and receipt inspection posture for bridge-side review
-- receipt-ledger handoff packaging for compact proof-to-economics carry
-- operator review packs, workflow packs, admin packs, and compatibility packs so bridge-facing support breadth is easy to inspect without changing the public proof center
-
-This keeps the public story centered on `xoonya` while preserving the useful bridge, validator, and profile lineage as support surfaces instead of separate product identities.
-
-The current `1.18.0` line starts turning that adapter-consumable handoff surface into a clearer adapter-usable handoff package:
-
-- proof-side handoff-package intake summaries on top of the intake surface
-- proof-side handoff-package carry for compact usable package carry
-- proof-side handoff-package run summaries for direct default run posture
-- clearer handoff-package ids across intake, carry, and proof-native run posture
-
-This is intended to make the proof-side continuation path easier to use directly as a stable public handoff package instead of only a proof-native intake surface.
-
-The current `1.19.0` line starts turning that adapter-usable handoff package into a clearer adapter-ready execution package:
-
-- proof-side execution-package posture on top of the handoff-package path
-- compact execution-package carry for direct execution-ready posture
-- proof-side execution-package run posture for direct default proof-native run carry
-- clearer execution-package ids across package review, carry, and proof-native run posture
-
-This is intended to make the proof-side continuation path easier to execute against directly as a stable public package instead of only a package posture.
-
-The current `1.20.0` line starts turning that adapter-ready execution package into a clearer adapter-operable execution contract:
-
-- proof-side execution-contract posture on top of the execution-package path
-- compact execution-contract carry for direct operable proof-side carry
-- proof-side execution-contract run posture for direct default proof-native operation carry
-- clearer execution-contract ids across review, carry, and proof-native run posture
-
-This is intended to make the proof-side continuation path easier to operate against repeatedly as a stable public contract instead of only a package that is execution-ready by posture.
-
-The current `1.21.0` line starts turning that adapter-operable execution contract into a clearer adapter-stable operating contract:
-
-- proof-side operating-contract posture on top of the execution-contract path
-- compact operating-contract carry for direct stable proof-side operating carry
-- proof-side operating-contract run posture for direct default proof-native operating posture
-- clearer operating-contract ids across review, carry, and proof-native run posture
-
-This is intended to make the proof-side continuation path easier to depend on repeatedly as a durable public operating contract instead of only a contract that is operable in the moment.
-
-The current `1.22.0` line starts turning that adapter-stable operating contract into a clearer adapter-reliable operating interface:
-
-- proof-side operating-interface posture on top of the operating-contract path
-- compact operating-interface carry for direct reliable proof-side interface carry
-- proof-side operating-interface run posture for direct default proof-native reliable posture
-- clearer operating-interface ids across review, carry, and proof-native run posture
-
-This is intended to make the proof-side continuation path easier to rely on operationally as a durable public interface instead of only a stable operating contract shape.
-
-The current `1.23.0` line starts turning that adapter-reliable operating interface into a clearer adapter-integrable operating path:
-
-- proof-side operating-integration posture on top of the operating-interface path
-- compact operating-integration carry for direct integrable proof-side path carry
-- proof-side operating-integration run posture for direct default proof-native integration posture
-- clearer operating-integration ids across review, carry, and proof-native run posture
-
-This is intended to make the proof-side continuation path easier to plug into adapters directly as a durable public operating path instead of only a reliable interface shape.
-
-The current `1.24.0` line starts turning that adapter-integrable operating path into a clearer adapter-ready default path:
-
-- proof-side operating-path posture on top of the operating-integration path
-- compact operating-path carry for direct default proof-side path carry
-- proof-side operating-path run posture for direct default proof-native path posture
-- clearer operating-path ids across review, carry, and proof-native run posture
-
-This is intended to make the proof-side continuation path easier to use as the obvious first public adapter path instead of only a path that is integrable with a little extra coordination.
-
-The current `1.25.0` line starts turning that adapter-ready default path into a clearer adapter-complete default path:
-
-- proof-side complete-default-path posture on top of the operating-path path
-- compact complete-default-path carry for direct complete proof-side path carry
-- proof-side complete-default-path run posture for direct default proof-native complete path posture
-- clearer complete-default-path ids across review, carry, and proof-native run posture
-
-This is intended to make the proof-side continuation path easier to adopt as the complete public default path an outside builder can use without needing private interpretation.
-
-The current `1.26.0` line finalizes that public shape into a cleaner production-ready package:
-
-- a publishable [START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/START_HERE.md) onboarding path
-- clearer top-level README entry points for the default proof-side production flow
-- publishable contract, compatibility, and terminology docs carried in the package tarball
-- naming cleanup that keeps the public story anchored to `xytara` and `xoonya`
-
-This is intended to make the public proof-side package feel like a finished production-facing product instead of a strong stack that still assumes milestone-history context.
-- `POST /v1/events/canonicalize`
-- `POST /v1/events/hash`
-- `POST /v1/receipts/emit`
-- `POST /v1/proof-bundles/build`
-- `POST /v1/proof-bundles/verify`
-- `GET /v1/integrations`
-- `GET /v1/integrations/summary`
-- `GET /v1/integrations/snapshot`
-- `GET /v1/integrations/promotion-readiness`
-- `GET /v1/integrations/promotion-workflow`
-
-Preserved compatibility routes:
-
-- `POST /validate`
-- `POST /v1/receipts/verify`
-- `POST /v1/receipts/inspect`
-- `POST /v1/proofs/verify`
-- `POST /v1/profiles/economic/verify`
-- `POST /v1/profiles/registry/verify`
-
-## Verification
-
-Local verification commands:
-
-- `npm run verify:package`
-- `npm run verify:conformance`
-- `npm run verify:vectors`
-- `npm run verify:examples`
-- `npm run verify:service`
-- `npm run verify:tooling`
-- `npm run verify:all`
-
-The current verification covers:
-
-- proof integration discovery metadata and filtering
-- staged proof integration registration import and snapshot export
-- package export presence
-- deterministic event hashing
-- proof-bundle tamper detection
-- public conformance CLI execution through `xoonya conformance --json`
-- published conformance vectors
-- published adversarial vectors
-- package quickstart flow
-- service routes for both the primary proof model and the legacy compatibility layer
-
-Public conformance command:
-
-```bash
-xoonya conformance
-xoonya conformance --json
-```
-
-The conformance command verifies the published vector files shipped in the package. The positive set covers `legacy-opreturn-v1`, `detached-assertion-v1`, `xoonya-native-sha256-v1`, `xoonya-native-signed-v1`, `xoonya-native-anchored-v1`, `xoonya-native-hybrid-v1`, `jwt-assertion-v1`, `did-vc-v1`, `sd-jwt-vc-v1`, `signed-envelope-v1`, and `partner-proof-envelope-v1`. The adversarial set covers bad event versions, missing signatures, mismatched commitments, unsupported methods, ambiguous `none`, replayed receipt context, native digest tampering, native signed proof tampering, native anchored proof tampering, native hybrid signature and key-binding tampering, native-to-detached downgrade attempts, and receipt-id mismatches.
-
-Published proof hardening artifacts:
-
-- [conformance-vectors.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/vectors/conformance-vectors.json)
-- [adversarial-vectors.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/vectors/adversarial-vectors.json)
-- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
-
-## Control Files
-
-- `CROSS_RUNTIME_POSTURE.md`
-- `FINAL_CONTRACT.md`
-- `TERMINOLOGY.md`
-- `SERVICE_CONTRACT.md`
-- `COMPATIBILITY_NOTE.md`
-
-## Proof Integration Toolkit
-
-`xoonya` keeps its integration model narrower than `xytara`. The proof-side toolkit is for additive proof helpers only:
-
-- identity-material providers
-- attestation and evidence reference adapters
-- anchor reference adapters
-- profile verification helpers
-- compatibility-oriented proof integrations
-
-This integration toolkit is broader than the proof verification method registry. Verification methods describe how a receipt or proof envelope is admitted at the proof boundary; integrations describe additive proof-side helpers, references, profiles, and staged third-party support that can be reviewed without changing the proof kernel.
-
-The package now includes:
-
-- `validateIntegrationRegistration(...)`
-- `importRegisteredIntegration(...)`
-- `exportIntegrationRegistrySnapshot(...)`
-- `validateIntegrationRegistrySnapshot(...)`
-- `summarizeIntegrationPromotionReadiness(...)`
-- `summarizeIntegrationPromotionWorkflow(...)`
-- `summarizeIntegrationPromotionWorkflowList(...)`
-
-Those helpers are intended to normalize proof-adjacent integrations without letting pricing, workflow, or settlement logic leak into the proof kernel.
-
-For the lightweight external-builder path, use:
-
-- [PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
-
-For lightweight local review flows, `xoonya` also includes a small repo-local proof-side CLI when working from a cloned `xoonya` repository:
-
-```bash
-node scripts/registry_cli.js validate-registration --example verifier
-node scripts/registry_cli.js export-snapshot --registration_state staging_registered
-node scripts/registry_cli.js promotion-readiness --integration partner.verifier.lattice_notary
-node scripts/registry_cli.js promotion-workflow --integration partner.verifier.lattice_notary
-node scripts/registry_cli.js promotion-workflow-summary --source third_party_example --registration_state staging_registered --bundled false
-```
-
-That tooling is intentionally narrow: validate proof-integration registration posture and export filtered proof registry snapshots.
-
-The proof-side readiness layer now also makes promotion posture explicit without expanding `xoonya` into a control plane:
-
-- review-ready means a proof integration is staged and inspectable
-- default-eligible means it can participate in the proof-side default posture
-- production-default-ready means certification, maturity, bundled posture, and selection posture all line up
-- blockers are returned as data instead of being left implicit
-- promotion workflow summaries now show the next proof-side transition and the current recommendation without introducing approval state
-
+# xoonya
+
+`xoonya` is the proof and review foundation for machine actions.
+
+> New to the code? Read [`ARCHITECTURE.md`](ARCHITECTURE.md) first. It separates
+> the compact proof engine (the ~1,600-line crypto core in `proof_sdk.js`) from
+> the large machine-readable proof catalog, so the real engine is legible fast.
+
+It exists to make machine evidence:
+
+- deterministic
+- portable
+- minimal
+- verifiable
+- replayable
+
+This repo is the proof-side half of the final two-repo public stack. It focuses on canonical events, receipts, proof bundles, and verification. It does not own pricing, catalogs, workflow orchestration, payment rails, or settlement policy.
+
+The 10-phase public program is now complete. `xoonya` is in terminal closeout posture rather than active milestone build posture.
+
+## Public Discovery
+
+The broader stack now has a canonical human front door and a canonical machine doorway:
+
+- https://www.naxytra.com/agents
+- https://www.naxytra.com/v1/agent-discovery-index
+- https://www.naxytra.com/v1/agent-discovery-index/summary
+- https://www.naxytra.com/.well-known/agent.json
+
+Use the human page when you want the shortest adoption landing page, and use the machine endpoints when a registry, crawler, or agent needs a stable public discovery surface.
+
+The shared control-plane contract documents are:
+
+- [OPERATIONAL_RECEIPT_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OPERATIONAL_RECEIPT_CONTRACT.md)
+- [MACHINE_IDENTITY_REGISTRY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/MACHINE_IDENTITY_REGISTRY_CONTRACT.md)
+- [CRYPTO_AGILITY_MATRIX.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/CRYPTO_AGILITY_MATRIX.md)
+- [AUTHORITY_BINDING_LIFECYCLE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/AUTHORITY_BINDING_LIFECYCLE_CONTRACT.md)
+- [PUBLIC_SURFACE_POLICY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/PUBLIC_SURFACE_POLICY_CONTRACT.md)
+- [OFFLINE_VERIFIABILITY_AND_RECOVERY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OFFLINE_VERIFIABILITY_AND_RECOVERY_CONTRACT.md)
+- [ADAPTER_CERTIFICATION_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/ADAPTER_CERTIFICATION_CONTRACT.md)
+- [TRUST_PORTABILITY_BOUNDARY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/TRUST_PORTABILITY_BOUNDARY_CONTRACT.md)
+- [SIGNED_AUDIT_PROVENANCE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/SIGNED_AUDIT_PROVENANCE_CONTRACT.md)
+
+## Public Boundary
+
+The public adoption story is intentionally narrow:
+
+- receive a handoff or event bundle
+- review it
+- verify it
+- emit a durable proof bundle
+
+`xoonya` should expose proof, review, and continuity. It should not force outside builders to learn runtime treasury or operator internals just to use the proof layer correctly.
+
+## Universal Proof Shape
+
+`xoonya` is intended to be usable from:
+
+- CLI and terminal
+- direct API calls
+- chat and agent environments that can submit handoff bundles
+- hosted or embedded review flows
+- partner systems that need deterministic proof verification
+
+The shortest public proof loop is:
+
+- receive a handoff or event bundle
+- review it
+- verify it
+- emit a durable proof bundle
+- preserve governance and continuity context when needed
+
+The frozen proof-side fact model for `3.0.0` closeout is documented in:
+
+- [XOONYA_PROOF_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_PROOF_TRUTH_MODEL.md)
+- [OPERATIONAL_RECEIPT_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OPERATIONAL_RECEIPT_CONTRACT.md)
+
+Machine-readable proof-truth surfaces:
+
+- `GET /v1/proof-truth`
+- `GET /v1/proof-truth/summary`
+- `GET /v1/proof-truth/:object_id`
+
+The frozen multi-surface proof default-path model for `3.0.0` closeout is documented in:
+
+- [XOONYA_DEFAULT_PATH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_DEFAULT_PATH_MODEL.md)
+
+Machine-readable proof default-path surfaces:
+
+- `GET /v1/default-path`
+- `GET /v1/default-path/summary`
+- `GET /v1/default-path/:surface_id`
+
+The frozen bridge, governance, trust-portability, and verification followthrough boundary for `3.0.0` closeout is documented in:
+
+- [XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md)
+
+Machine-readable followthrough-truth surfaces:
+
+- `GET /v1/followthrough-truth`
+- `GET /v1/followthrough-truth/summary`
+- `GET /v1/followthrough-truth/:profile_id`
+
+The current proof breadth already includes:
+
+- canonical events, receipts, and proof bundles
+- result-package handoff review and run paths
+- bridge and compatibility review surfaces
+- governance, dispute, and signoff support
+- proof-side continuity for economic consequence carry
+- proof-adjacent integration registration and review
+
+It also already carries broader first-class proof and interoperability lanes for:
+
+- framework continuity across `langchain`, `langgraph`, `semantic_kernel`, `autogen`, `crewai`, and `llamaindex`
+- native and external verification methods such as `XNYA`, JWT assertion, DID VC, SD-JWT VC, signed-envelope, detached assertion, and partner proof-envelope compatibility
+- operator and artifact lanes such as telemetry, provenance, artifact distribution, shared signals, feature control, trust portability, and external proof import review
+
+If you want the broadest machine-readable census for these already-core proof lanes, inspect:
+
+- `GET /v1/integration-matrix`
+- `GET /v1/proof-bridge`
+- `GET /v1/telemetry`
+- `GET /v1/provenance`
+- `GET /v1/artifact-distribution`
+- `GET /v1/shared-signals`
+- `GET /v1/feature-control`
+- `GET /v1/adapter-certification`
+- `GET /v1/trust-portability-boundary`
+- `GET /v1/signed-audit-provenance`
+
+## One-Line After Install
+
+If you only run two commands after install, use:
+
+- `xoonya start-here`
+- `xoonya first-run`
+- `xoonya first-run --verify-native --pretty`
+- `xoonya release --summary`
+- `xoonya conformance`
+
+If you want the shortest machine-readable discovery path, inspect:
+
+- `GET /v1/providers`
+- `GET /v1/frameworks`
+- `GET /v1/integration-matrix`
+- `GET /v1/proof-bridge`
+- `GET /v1/telemetry`
+- `GET /v1/provenance`
+- `GET /v1/adapter-certification`
+- `GET /v1/trust-portability-boundary`
+- `GET /v1/signed-audit-provenance`
+
+If you are working on shared evidence, inspect the operational receipt contract pack:
+
+- `buildOperationalReceiptContractPack()`
+- `summarizeOperationalReceiptContractPack()`
+
+If you are working on machine identity, inspect the registry contract pack:
+
+- `buildMachineIdentityRegistryContractPack()`
+- `summarizeMachineIdentityRegistryContractPack()`
+
+If you are working on crypto agility, inspect the matrix pack:
+
+- `buildCryptoAgilityMatrixPack()`
+- `summarizeCryptoAgilityMatrixPack()`
+
+If you are working on binding lifecycle, inspect the lifecycle pack:
+
+- `buildAuthorityBindingLifecycleContractPack()`
+- `summarizeAuthorityBindingLifecycleContractPack()`
+
+If you are working on public route policy, inspect the surface policy pack:
+
+- `buildPublicSurfacePolicyContractPack()`
+- `summarizePublicSurfacePolicyContractPack()`
+
+If you are working on offline recovery, inspect the recovery pack:
+
+- `buildOfflineVerifiabilityRecoveryContractPack()`
+- `summarizeOfflineVerifiabilityRecoveryContractPack()`
+
+If you are working on adapter certification, inspect the certification pack:
+
+- `buildAdapterCertificationContractPack()`
+- `summarizeAdapterCertificationContractPack()`
+
+If you are working on trust portability boundaries, inspect the boundary pack:
+
+- `buildTrustPortabilityBoundaryContractPack()`
+- `summarizeTrustPortabilityBoundaryContractPack()`
+
+If you are working on signed audit and provenance, inspect the audit/provenance pack:
+
+- `buildSignedAuditProvenanceContractPack()`
+- `summarizeSignedAuditProvenanceContractPack()`
+
+## Start Here
+
+If you are new to the proof-side package, use this order:
+
+1. read [START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/START_HERE.md)
+2. run `node examples/package_quickstart.js`
+3. run `npm run verify:all`
+4. use [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/FINAL_CONTRACT.md) and [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/SERVICE_CONTRACT.md) as the durable public contract
+
+If you are reading the GitHub repo and want deeper product context beyond the npm starter path, continue with:
+
+- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
+
+If you want one concrete cross-repo adoption story, start with:
+
+- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
+
+If you want the shortest neutral external-adoption bundle, continue with:
+
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
+- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
+- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/EXAMPLE_PATHS.md)
+- `node examples/partner_proof_walkthrough.js`
+
+If you are integrating from outside the stack, also read:
+
+- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
+- [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
+
+If you want the broader already-core proof continuity layers, continue with:
+
+- [XOONYA_NATIVE_PROOF_FORMAT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_NATIVE_PROOF_FORMAT.md)
+- [XOONYA_NATIVE_ATOM_SPEC.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_NATIVE_ATOM_SPEC.md)
+- [XNYA_REFERENCE_IMPLEMENTATIONS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XNYA_REFERENCE_IMPLEMENTATIONS.md)
+- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
+- [XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md)
+
+## Production Path
+
+The intended production-facing proof path is now:
+
+1. receive the transaction-side handoff or default path artifact from `xytara`
+2. inspect the proof-side review posture
+3. confirm carry and run posture
+4. emit and verify the proof-native completion path
+
+The rest of this README explains the broader route ladder, but the public starting posture should now be understandable from that one proof-side path.
+
+For a direct one-line proof-side review of a carried handoff bundle, use the bundled CLI:
+
+```bash
+xoonya-review --file ./handoff.json --summary
+```
+
+For release-grade adoption posture, inspect:
+
+- `GET /v1/release-pack`
+- `GET /v1/release-pack/summary`
+- `GET /v1/release-pack/comparison`
+- `GET /v1/release-pack/comparison/summary`
+- `GET /v1/release-pack/adoption`
+- `GET /v1/release-pack/adoption/summary`
+- `GET /v1/release-pack/scenarios`
+- `GET /v1/release-pack/scenarios/summary`
+- `GET /v1/release-pack/launch`
+- `GET /v1/release-pack/launch/summary`
+- `GET /v1/release-manifest`
+- `GET /v1/release-manifest/summary`
+- `GET /v1/release-notes`
+- `GET /v1/release-notes/summary`
+- `GET /v1/release-center`
+- `GET /v1/release-center/summary`
+- `GET /v1/release-history`
+- `GET /v1/release-history/summary`
+- `GET /v1/phases`
+- `GET /v1/phases/summary`
+- `GET /v1/phases/phase-1`
+- `GET /v1/phases/phase-1/summary`
+- `GET /v1/publish-plan`
+- `GET /v1/publish-plan/summary`
+- `GET /v1/ecosystem-entry`
+- `GET /v1/ecosystem-entry/summary`
+- `GET /v1/launch-narrative`
+- `GET /v1/launch-narrative/summary`
+- `GET /v1/outreach-proof`
+- `GET /v1/outreach-proof/summary`
+- `GET /v1/announcement-pack`
+- `GET /v1/announcement-pack/summary`
+- `GET /v1/release-candidate`
+- `GET /v1/release-candidate/summary`
+- `xoonya-release --summary`
+- `xoonya-release --comparison --summary`
+- `xoonya-release --adoption --summary`
+- `xoonya-release --scenarios --summary`
+- `xoonya-release --launch --summary`
+- `xoonya-release --manifest --summary`
+- `xoonya-release --notes --summary`
+- `xoonya-release --center --summary`
+- `xoonya-release --history --summary`
+- `xoonya-release --phases --summary`
+- `xoonya-release --phase-1 --summary`
+- `xoonya-release --ecosystem --summary`
+- `xoonya-release --narrative --summary`
+- `xoonya-release --outreach-proof --summary`
+- `xoonya-release --announcement --summary`
+- `xoonya-release --candidate --summary`
+
+These surfaces package the current proof-side value story, first-contact proof-review CLI path, proof-center posture, handoff/review/governance surfaces, and integration breadth into one machine-readable launch boundary.
+
+For explicit runtime-economics carry, the proof-side handoff boundary now also accepts a canonical `handoff_bundle` wrapper from `xytara` so the economic consequence seam stays contract-shaped across the two repos instead of being reassembled ad hoc by callers.
+
+That same carried bundle can now also ride inside the normal result-package handoff path:
+
+- if `xytara` sends `handoff_bundle.economic_consequence_handoff_bundle`
+- `xoonya` will validate it through the existing bounded handoff logic
+- normal result-package review and run surfaces will expose compact economic-conformance review data automatically
+- direct-pay or non-metered handoffs remain unaffected
+
+The package and service now also expose a default proof center surface so the intended proof-native path is easy to inspect directly:
+
+- canonical event bundle v1
+- receipt v1
+- proof bundle v1
+- compact compatibility helpers preserved, but not treated as the public conceptual center
+- proof remains settlement-agnostic and workflow-agnostic by default
+
+The current `1.6.0` companion slice adds guided default proof loops on top of that proof center:
+
+- default proof-loop catalog and detail routes
+- a direct proof-loop run route for the canonical proof-native path
+- package helpers that build, verify, and summarize the proof bundle boundary in one step
+
+This keeps `xoonya` narrow while making the intended proof path easier to inspect alongside the newer guided transaction-loop work in `xytara`.
+
+The current `1.7.0` companion slice adds a lightweight transaction proof-handoff surface:
+
+- a transaction proof-handoff center that states the expected handoff contract
+- a direct handoff run path that turns transaction-side proof handoff data into a proof-native bundle
+- summary helpers that make the recommended proof follow-through explicit without widening proof scope
+
+The current `1.8.0` companion slice extends that same proof-side carry to richer grouped interaction spine handoffs:
+
+- an interaction-spine handoff center and summary surface
+- a direct interaction-spine handoff run path for composed transaction spines
+- proof-side summaries that preserve both pre-commit and committed-ref context without importing commerce logic
+
+## Proof Model
+
+The primary proof model is layered:
+
+1. `Canonical Event Bundle`
+2. `Receipt`
+3. `Proof Bundle`
+4. optional domain-specific `Profiles`
+
+That means the center of gravity is now:
+
+- `canonicalizeEvent(...)`
+- `hashEvent(...)`
+- `emitReceipt(...)`
+- `buildProofBundle(...)`
+- `verifyProofBundle(...)`
+- `listProofVerificationMethods(...)`
+- `getProofVerificationMethod(...)`
+
+### Verification Methods
+
+`xoonya` keeps proof verification method-agnostic. The proof bundle verifier uses a small method registry instead of treating every non-empty signature as equally verified.
+
+Current built-in methods:
+
+- `legacy-opreturn-v1` verifies the compatibility OP_RETURN receipt path.
+- `detached-assertion-v1` accepts an explicit detached assertion after canonical receipt checks; cryptographic verification is expected to happen outside this helper.
+- `xoonya-native-sha256-v1` verifies xoonya's native deterministic digest format.
+- `xoonya-native-signed-v1` verifies xoonya's native signed proof envelope with Ed25519, secp256k1, and P-256 implemented through the explicit suite registry. Other suites stay registry-only until validators exist.
+- `xoonya-native-anchored-v1` verifies xoonya's native anchor-binding proof envelope for chain, batch, finality, content-hash, or external attestation refs. It verifies the binding, not the external provider or chain truth itself.
+- `jwt-assertion-v1` accepts compact JWT assertion envelopes after canonical receipt checks; JWT signature, issuer, and audience verification remain external to this helper.
+- `did-vc-v1` accepts DID/VC proof envelopes after canonical receipt checks; DID resolution and VC proof validation remain external to this helper.
+- `sd-jwt-vc-v1` accepts SD-JWT VC disclosure envelopes after canonical receipt checks; issuer, holder binding, and disclosure verification remain external to this helper.
+- `signed-envelope-v1` accepts generic signed envelopes after canonical receipt checks; envelope-specific signature verification remains external to this helper.
+- `partner-proof-envelope-v1` accepts partner-specific proof envelopes after canonical receipt checks; partner verifier policy remains external to this helper.
+
+`algorithm: "none"` is not a registered verification method and does not verify. External proof methods are first-class registry entries, but xoonya does not pretend to replace their own cryptographic verifier stacks. The proof core checks the canonical receipt, method registration, and method boundary; issuer-specific validation stays with the relevant JWT, DID/VC, SD-JWT VC, signed-envelope, or partner verifier.
+
+Every verify result now says which of these happened through `verification_class` and `cryptographically_verified` (see "Verification Classes" below). Native signed and hybrid proofs bind `public_key_ref` to the key carried in the proof, not to the identity string; pass `trusted_public_key_refs` or `expected_public_key_ref` to bind an identity to its keys, and `strict: true` to refuse anything that was not cryptographically verified.
+
+### xoonya Native Proof Format
+
+xoonya Native is the optional native proof/result/attestation format direction for machine proof. It is not a replacement for JWT, OAuth, OIDC, DID/VC, or SD-JWT VC. Those remain interoperability lanes.
+
+The native standard is xoonya's own fixed-size hot-path commitment atom, cold-path proof envelope, semantic-free core bytes, and deterministic validation. The current implemented native methods are `xoonya-native-sha256-v1`, `xoonya-native-signed-v1`, `xoonya-native-anchored-v1`, and `xoonya-native-hybrid-v1`. The signed native method verifies Ed25519, secp256k1, and P-256 today. The hybrid native method verifies only registered runtime-supported suite pairs, with `ed25519+ml-dsa-65` as the current promoted baseline and other pairings staying non-claimable until runtime support and vectors exist. The anchored native method binds receipts to declared anchor/finality/attestation refs without claiming the external system has been independently verified by xoonya.
+
+The atom ladder is treated as native xoonya design, not a runtime dependency: `xoonya-native-atom/v1` is the 58-byte classical commitment atom, `xoonya-native-atom/v2` is the 70-byte PQ-horizon identity commitment candidate, and `xoonya-native-atom/v3-contingency` stays reserved for a future digest-family shift only if the underlying hash assumptions materially change.
+
+The canonical xoonya Native atom magic is `XNYA`. No other magic value is part of the xoonya Native atom standard. The formal atom spec ships inside the `xoonya` package first; a separate standards repo can be extracted later if external governance needs it.
+
+XNYA atom conformance now includes stable machine-readable reject codes and adversarial vectors. Passing only the happy-path vectors is not enough to claim xoonya Native compatibility.
+
+The native payload profile is now explicit: `xoonya-native-payload-profile/v1` uses the binary `XNYP` magic and typed fields with deterministic ordering, fixed-width integer encoding, unknown-field policy checks, and no floats or loose JSON semantics. The optional `xoonya-native-line-rate-frame/v1` wraps an existing 58-byte or 70-byte `XNYA` atom with a 2-byte checksum for transport fast rejection; it does not change the atom and does not claim signature, encryption, custody, settlement, or external finality truth.
+
+The `XNYA-compatible` mark is now defined as a conformance claim, not a marketing label. Implementations may use it only when atom bytes, payload profile rules, proof-envelope method behavior, adversarial vectors, and stable error codes match the published artifacts. The mark must not be used to claim unregistered or runtime-unsupported PQ/hybrid verification, live external-provider execution, chain finality, custody, identity/auth, or external issuer truth without separate verifier evidence. `xoonya-native-hybrid-v1` is now implemented only for registered runtime-supported suite pairs, with current first-class verification centered on `ed25519+ml-dsa-65`.
+
+The JavaScript `xoonya` package is the current canonical XNYA reference implementation. A Python candidate scaffold now verifies the XNYA atom, native atom adversarial, XNYP payload profile, line-rate frame, canonical event, receipt, and non-signed proof-bundle vectors independently. It also verifies Ed25519 native signed vectors when Python's optional `cryptography` package is installed, otherwise it reports the deterministic dependency gate. It is not yet a full second reference until always-on signature-suite parity, proof-bundle round trips, and the full promotion gates pass. Rust remains planned until a verified vector-parity implementation exists.
+
+Run `npm run verify:reference-python-crypto` to create an isolated temporary Python virtual environment, install the optional crypto dependency, and require the Ed25519 native signed vector to verify. Run `npm run verify:reference-rust-scaffold` to check the packaged source-only Rust scaffold and its non-promotion boundary.
+
+See [XOONYA_NATIVE_PROOF_FORMAT.md](./XOONYA_NATIVE_PROOF_FORMAT.md).
+See [XOONYA_NATIVE_ATOM_SPEC.md](./XOONYA_NATIVE_ATOM_SPEC.md).
+See [XOONYA_NATIVE_STANDARD_GOVERNANCE.md](./XOONYA_NATIVE_STANDARD_GOVERNANCE.md).
+See [XNYA_CONFORMANCE_MARK.md](./XNYA_CONFORMANCE_MARK.md).
+See [XNYA_REFERENCE_IMPLEMENTATIONS.md](./XNYA_REFERENCE_IMPLEMENTATIONS.md).
+See [CROSS_RUNTIME_POSTURE.md](./CROSS_RUNTIME_POSTURE.md).
+
+## Compatibility Surface
+
+Legacy compact receipt and profile helpers are still available during alignment:
+
+- `createReceipt(...)`
+- `verifyReceipt(...)`
+- `createReceiptV2(...)`
+- `verifyReceiptV2(...)`
+- `createProofEnvelopeV1(...)`
+- `verifyProofEnvelopeV1(...)`
+- `createxoonyaNativeAtomV1(...)`
+- `createxoonyaNativeAtomV2(...)`
+- `verifyxoonyaNativeAtom(...)`
+- `createEconomicReceiptProfileV1(...)`
+- `verifyEconomicReceiptProfileV1(...)`
+- `createRegistryProfileV1(...)`
+- `verifyRegistryProfileV1(...)`
+
+Those helpers remain verified so current receipt/profile consumers are not broken while the newer proof model becomes the primary public direction.
+
+## Package Quickstart
+
+Run:
+
+```bash
+node examples/package_quickstart.js
+```
+
+The package quickstart demonstrates:
+
+- proof integration discovery and certification posture
+- staged proof-integration registration and snapshot export
+- legacy compact receipt verification
+- legacy proof-envelope verification
+- canonical event creation
+- canonical receipt emission
+- proof bundle construction
+- proof bundle verification
+- transaction proof-handoff follow-through
+- proof-side bridge carry for explicit economic consequence review when runtime economics need proof-adjacent preservation
+
+## Service Quickstart
+
+Run:
+
+```bash
+npm start
+```
+
+Then in another shell:
+
+```bash
+curl -X POST http://127.0.0.1:4310/v1/events/hash ^
+  -H "content-type: application/json" ^
+  -d "{\"event\":{\"version\":\"canonical-event-bundle/v1\",\"domain_id\":\"demo\",\"sequence\":\"1\",\"actor_id\":\"agent-1\",\"adapter_source\":\"curl\",\"event_type\":\"demo.event\",\"event_hash\":\"abababababababababababababababababababababababababababababababab\"}}"
+```
+
+Environment example:
+
+- [`.env.example`](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/.env.example)
+
+Service environment variables:
+
+- `XOONYA_HOST`, `XOONYA_PORT` (or `PORT`): bind address and port.
+- `XOONYA_STRICT_VERIFY=1`: make every proof-bundle verification strict (only `cryptographic` results are `valid`).
+- `XOONYA_ACCEPT_PRIVATE_KEY_MATERIAL`: `true` or `false`. When `false`, or when it is unset and `RENDER` is set (hosted deployments), `POST /v1/receipts/emit`, `POST /v1/proof-bundles/build`, and the proof-center run routes reject any body containing a field matching `/private_key/i` with `400 private_key_material_not_accepted`. Sign locally with the SDK (`emitReceipt`, `buildProofBundle`) or the `xoonya` CLI and submit the signed receipt or bundle instead. Local runs without `RENDER` keep accepting private key material so the existing verifiers pass.
+
+Request bodies are capped at 1 MiB by byte count (a larger declared `content-length` is rejected before the body is read). `OPTIONS` returns `204` with an `allow` header, `HEAD` mirrors `GET` without a body, malformed percent-encoding in a path returns `400 invalid_path_encoding`, and unexpected handler failures return a generic `500 internal_error` with the stack logged server-side only.
+
+## Service Routes
+
+Primary proof-model routes:
+
+- `GET /health`
+- `GET /v1/proof-center`
+- `GET /v1/proof-center/summary`
+- `GET /v1/proof-center/native-standard`
+- `GET /v1/proof-center/native-standard/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`
+- `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-conformance-mark`
+- `GET /v1/proof-center/native-conformance-mark/summary`
+- `GET /v1/proof-center/native-reference-implementations`
+- `GET /v1/proof-center/native-reference-implementations/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/review/summary`
+- `POST /v1/proof-center/import-adapter/run`
+- `GET /v1/proof-center/default-loops`
+- `GET /v1/proof-center/default-loops/summary`
+- `GET /v1/proof-center/default-loop`
+- `POST /v1/proof-center/default-loops/run`
+- `GET /v1/proof-center/transaction-handoff`
+- `GET /v1/proof-center/transaction-handoff/summary`
+- `POST /v1/proof-center/transaction-handoff/run`
+- `GET /v1/proof-center/result-package-handoff`
+- `GET /v1/proof-center/result-package-handoff/summary`
+- `GET /v1/proof-center/governance`
+- `GET /v1/proof-center/governance/summary`
+- `GET /v1/proof-center/bridge`
+- `GET /v1/proof-center/bridge/summary`
+- `GET /v1/proof-center/bridge/profile-support`
+- `POST /v1/proof-center/governance/interpretation-validate`
+- `POST /v1/proof-center/governance/coordination`
+- `POST /v1/proof-center/governance/dashboard`
+- `POST /v1/proof-center/governance/operator-view`
+- `POST /v1/proof-center/governance/admin-view`
+- `POST /v1/proof-center/governance/dashboard-pack`
+- `POST /v1/proof-center/governance/workflow-pack`
+- `POST /v1/proof-center/governance/signoff-pack`
+- `POST /v1/proof-center/governance/disputes/summary`
+- `POST /v1/proof-center/governance/disputes/case-review`
+- `POST /v1/proof-center/governance/disputes/action`
+- `POST /v1/proof-center/governance/disputes/case-bundle`
+- `POST /v1/proof-center/governance/disputes/resolution-pack`
+- `POST /v1/proof-center/governance/console-pack`
+- `POST /v1/proof-center/governance/handoff-bundle`
+- `POST /v1/proof-center/governance/review-link`
+- `POST /v1/proof-center/bridge/receipt-wrap`
+- `POST /v1/proof-center/bridge/validator-verify`
+- `POST /v1/proof-center/bridge/receipt-ledger-handoff`
+- `POST /v1/proof-center/bridge/economic-handoff`
+- `POST /v1/proof-center/bridge/economic-conformance-pack`
+- `POST /v1/proof-center/bridge/operator-review-pack`
+- `POST /v1/proof-center/bridge/compatibility-pack`
+- `POST /v1/proof-center/bridge/workflow-pack`
+- `POST /v1/proof-center/bridge/admin-pack`
+- `POST /v1/proof-center/result-package-handoff/review`
+- `POST /v1/proof-center/result-package-handoff/review/summary`
+- `POST /v1/proof-center/result-package-handoff/review/extension-readiness`
+- `POST /v1/proof-center/result-package-handoff/review/extension-boundary`
+- `POST /v1/proof-center/result-package-handoff/review/default-continuation`
+- `POST /v1/proof-center/result-package-handoff/review/default-boundary`
+- `POST /v1/proof-center/result-package-handoff/review/contract-summary`
+- `POST /v1/proof-center/result-package-handoff/review/contract-boundary`
+- `POST /v1/proof-center/result-package-handoff/review/contract-carry`
+- `POST /v1/proof-center/result-package-handoff/review/bridge-summary`
+- `POST /v1/proof-center/result-package-handoff/review/bridge-boundary`
+- `POST /v1/proof-center/result-package-handoff/review/bridge-carry`
+- `POST /v1/proof-center/result-package-handoff/review/bridge-run`
+- `POST /v1/proof-center/result-package-handoff/review/handoff-continuity`
+- `POST /v1/proof-center/result-package-handoff/review/handoff-intake`
+- `POST /v1/proof-center/result-package-handoff/review/handoff-intake-boundary`
+- `POST /v1/proof-center/result-package-handoff/review/handoff-intake-carry`
+- `POST /v1/proof-center/result-package-handoff/review/handoff-package-intake`
+- `POST /v1/proof-center/result-package-handoff/review/handoff-package-carry`
+- `POST /v1/proof-center/result-package-handoff/review/handoff-package-run`
+- `POST /v1/proof-center/result-package-handoff/review/execution-package`
+- `POST /v1/proof-center/result-package-handoff/review/execution-package-carry`
+- `POST /v1/proof-center/result-package-handoff/review/execution-package-run`
+- `POST /v1/proof-center/result-package-handoff/review/execution-contract`
+- `POST /v1/proof-center/result-package-handoff/review/execution-contract-carry`
+- `POST /v1/proof-center/result-package-handoff/review/execution-contract-run`
+- `POST /v1/proof-center/result-package-handoff/review/operating-contract`
+- `POST /v1/proof-center/result-package-handoff/review/operating-contract-carry`
+- `POST /v1/proof-center/result-package-handoff/review/operating-contract-run`
+- `POST /v1/proof-center/result-package-handoff/review/operating-interface`
+- `POST /v1/proof-center/result-package-handoff/review/operating-interface-carry`
+- `POST /v1/proof-center/result-package-handoff/review/operating-interface-run`
+- `POST /v1/proof-center/result-package-handoff/review/operating-integration`
+- `POST /v1/proof-center/result-package-handoff/review/operating-integration-carry`
+
+When `xytara` sends `handoff_bundle.economic_consequence_handoff_bundle`, `xoonya` now preserves a compact `economic_audit_summary` inside review output so proof-side operators can see the linked `account_ref`, `usage_meter_ref`, `credit_spend_ref`, `usage_units`, `pricing_band`, `payment_ref`, `settlement_ref`, `settlement_txid`, `settlement_finality_status`, `treasury_receipt_ref`, `proof_ref`, and `conformance_pack_ref` without re-deriving the carry by hand.
+- `POST /v1/proof-center/result-package-handoff/review/operating-integration-run`
+- `POST /v1/proof-center/result-package-handoff/review/operating-path`
+- `POST /v1/proof-center/result-package-handoff/review/operating-path-carry`
+- `POST /v1/proof-center/result-package-handoff/review/operating-path-run`
+- `POST /v1/proof-center/result-package-handoff/review/complete-default-path`
+- `POST /v1/proof-center/result-package-handoff/review/complete-default-path-carry`
+- `POST /v1/proof-center/result-package-handoff/review/complete-default-path-run`
+- `POST /v1/proof-center/result-package-handoff/review/handoff-run`
+- `POST /v1/proof-center/result-package-handoff/run`
+
+The result-package review surface now also returns a durability summary so the preserved execution, economic, and proof-facing context is easier to inspect before proof-native execution.
+It also now exposes an extension-readiness summary so the stable post-review proof boundary is easier to treat as a reusable seam.
+It now also exposes a reusable-default continuation summary so that same stable post-review boundary is easier to reuse as a standard proof-side default path.
+It now also exposes a compact reusable-default boundary summary so the proof-side default seam can be treated as a stable public boundary, not just a recommended path.
+It now also exposes composition-contract summaries so the proof-side default seam can be treated more clearly as a stable public contract across review and run.
+It now also exposes compact contract-carry summaries so the stable proof-side contract context is easier to inspect directly without expanding proof scope.
+It now also exposes bridge summaries, bridge-boundary summaries, and bridge-carry summaries so the proof-side review seam is easier to treat as an adapter-ready bridge without widening proof scope.
+It now also exposes a bridge-run summary so that same proof-side bridge can be read directly as the final run posture instead of only as review-stage carry.
+It now also exposes a handoff-continuity summary so the proof-side bridge can be treated more clearly as a stable handoff contract into proof-native execution.
+It now also exposes a handoff-intake summary and handoff-intake-boundary summary so that same handoff contract can be consumed more directly as a stable proof-native intake surface for future adapters without widening proof scope.
+It now also exposes a handoff-intake-carry summary so the same proof-side intake surface can be reused more directly as compact consumable carry instead of only summary or boundary posture.
+It now also exposes a handoff-run summary so that same handoff contract can be read directly as the final proof-native run posture instead of only as continuity guidance.
+
+The Wave B governance carry-over line adds a bounded governance center on the proof side:
+
+- governance interpretation validation for receipt-ledger and result-package follow-through
+- governance coordination emission for the next proof-side/operator handoff step
+- governance dashboard, operator-view, admin-view, dashboard-pack, workflow-pack, and signoff-pack packaging
+- dispute summary, case review, metadata-only dispute action, case-bundle export, and resolution-pack export
+- console-pack, handoff-bundle, and explicit review-link surfaces for compact operator carry into the proof-side review/run ladder
+
+This keeps governance review attached to the proof-side operating shape without widening `xoonya` into a runtime or economics system.
+
+The Wave E bridge carry-over line adds a bounded bridge center on the proof side:
+
+- receipt-wrap support for compact compatibility receipts when an outside bridge still needs that bounded surface
+- validator-compatible verification and receipt inspection posture for bridge-side review
+- receipt-ledger handoff packaging for compact proof-to-economics carry
+- operator review packs, workflow packs, admin packs, and compatibility packs so bridge-facing support breadth is easy to inspect without changing the public proof center
+
+This keeps the public story centered on `xoonya` while preserving the useful bridge, validator, and profile lineage as support surfaces instead of separate product identities.
+
+The current `1.18.0` line starts turning that adapter-consumable handoff surface into a clearer adapter-usable handoff package:
+
+- proof-side handoff-package intake summaries on top of the intake surface
+- proof-side handoff-package carry for compact usable package carry
+- proof-side handoff-package run summaries for direct default run posture
+- clearer handoff-package ids across intake, carry, and proof-native run posture
+
+This is intended to make the proof-side continuation path easier to use directly as a stable public handoff package instead of only a proof-native intake surface.
+
+The current `1.19.0` line starts turning that adapter-usable handoff package into a clearer adapter-ready execution package:
+
+- proof-side execution-package posture on top of the handoff-package path
+- compact execution-package carry for direct execution-ready posture
+- proof-side execution-package run posture for direct default proof-native run carry
+- clearer execution-package ids across package review, carry, and proof-native run posture
+
+This is intended to make the proof-side continuation path easier to execute against directly as a stable public package instead of only a package posture.
+
+The current `1.20.0` line starts turning that adapter-ready execution package into a clearer adapter-operable execution contract:
+
+- proof-side execution-contract posture on top of the execution-package path
+- compact execution-contract carry for direct operable proof-side carry
+- proof-side execution-contract run posture for direct default proof-native operation carry
+- clearer execution-contract ids across review, carry, and proof-native run posture
+
+This is intended to make the proof-side continuation path easier to operate against repeatedly as a stable public contract instead of only a package that is execution-ready by posture.
+
+The current `1.21.0` line starts turning that adapter-operable execution contract into a clearer adapter-stable operating contract:
+
+- proof-side operating-contract posture on top of the execution-contract path
+- compact operating-contract carry for direct stable proof-side operating carry
+- proof-side operating-contract run posture for direct default proof-native operating posture
+- clearer operating-contract ids across review, carry, and proof-native run posture
+
+This is intended to make the proof-side continuation path easier to depend on repeatedly as a durable public operating contract instead of only a contract that is operable in the moment.
+
+The current `1.22.0` line starts turning that adapter-stable operating contract into a clearer adapter-reliable operating interface:
+
+- proof-side operating-interface posture on top of the operating-contract path
+- compact operating-interface carry for direct reliable proof-side interface carry
+- proof-side operating-interface run posture for direct default proof-native reliable posture
+- clearer operating-interface ids across review, carry, and proof-native run posture
+
+This is intended to make the proof-side continuation path easier to rely on operationally as a durable public interface instead of only a stable operating contract shape.
+
+The current `1.23.0` line starts turning that adapter-reliable operating interface into a clearer adapter-integrable operating path:
+
+- proof-side operating-integration posture on top of the operating-interface path
+- compact operating-integration carry for direct integrable proof-side path carry
+- proof-side operating-integration run posture for direct default proof-native integration posture
+- clearer operating-integration ids across review, carry, and proof-native run posture
+
+This is intended to make the proof-side continuation path easier to plug into adapters directly as a durable public operating path instead of only a reliable interface shape.
+
+The current `1.24.0` line starts turning that adapter-integrable operating path into a clearer adapter-ready default path:
+
+- proof-side operating-path posture on top of the operating-integration path
+- compact operating-path carry for direct default proof-side path carry
+- proof-side operating-path run posture for direct default proof-native path posture
+- clearer operating-path ids across review, carry, and proof-native run posture
+
+This is intended to make the proof-side continuation path easier to use as the obvious first public adapter path instead of only a path that is integrable with a little extra coordination.
+
+The current `1.25.0` line starts turning that adapter-ready default path into a clearer adapter-complete default path:
+
+- proof-side complete-default-path posture on top of the operating-path path
+- compact complete-default-path carry for direct complete proof-side path carry
+- proof-side complete-default-path run posture for direct default proof-native complete path posture
+- clearer complete-default-path ids across review, carry, and proof-native run posture
+
+This is intended to make the proof-side continuation path easier to adopt as the complete public default path an outside builder can use without needing private interpretation.
+
+The current `1.26.0` line finalizes that public shape into a cleaner production-ready package:
+
+- a publishable [START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/START_HERE.md) onboarding path
+- clearer top-level README entry points for the default proof-side production flow
+- publishable contract, compatibility, and terminology docs carried in the package tarball
+- naming cleanup that keeps the public story anchored to `xytara` and `xoonya`
+
+This is intended to make the public proof-side package feel like a finished production-facing product instead of a strong stack that still assumes milestone-history context.
+- `POST /v1/events/canonicalize`
+- `POST /v1/events/hash`
+- `POST /v1/receipts/emit`
+- `POST /v1/proof-bundles/build`
+- `POST /v1/proof-bundles/verify`
+- `GET /v1/integrations`
+- `GET /v1/integrations/summary`
+- `GET /v1/integrations/snapshot`
+- `GET /v1/integrations/promotion-readiness`
+- `GET /v1/integrations/promotion-workflow`
+
+Preserved compatibility routes:
+
+- `POST /validate`
+- `POST /v1/receipts/verify`
+- `POST /v1/receipts/inspect`
+- `POST /v1/proofs/verify`
+- `POST /v1/profiles/economic/verify`
+- `POST /v1/profiles/registry/verify`
+
+## Verification
+
+Local verification commands:
+
+- `npm run verify:package`
+- `npm run verify:conformance`
+- `npm run verify:vectors`
+- `npm run verify:examples`
+- `npm run verify:service`
+- `npm run verify:tooling`
+- `npm run verify:forgery-resistance`
+- `npm run verify:all`
+
+The current verification covers:
+
+- proof integration discovery metadata and filtering
+- staged proof integration registration import and snapshot export
+- package export presence
+- deterministic event hashing
+- proof-bundle tamper detection
+- public conformance CLI execution through `xoonya conformance --json`
+- published conformance vectors
+- published adversarial vectors
+- package quickstart flow
+- service routes for both the primary proof model and the legacy compatibility layer
+- forgery resistance: key substitution with and without a trust root, strict-mode rejection of digest and structural results, hybrid PQ tampering and wrong-pin rejection, and result determinism
+
+### Verification Classes
+
+`verifyProofBundle(bundle, options)` and `POST /v1/proof-bundles/verify` (`{ "bundle": ..., "options": ... }`) return `verification_class`, `cryptographically_verified`, `strict`, and `trust_root_applied` next to `valid`:
+
+| `verification_class` | Methods | `cryptographically_verified` | Strict mode |
+| --- | --- | --- | --- |
+| `cryptographic` | `xoonya-native-signed-v1`, `xoonya-native-hybrid-v1` | `true` when valid | accepted |
+| `digest` | `xoonya-native-sha256-v1`, `legacy-opreturn-v1` | `false` | rejected: `digest_only_not_cryptographically_verified` |
+| `anchored_binding` | `xoonya-native-anchored-v1` | `false` | rejected: `digest_only_not_cryptographically_verified` |
+| `structural` | `detached-assertion-v1`, `jwt-assertion-v1`, `did-vc-v1`, `sd-jwt-vc-v1`, `signed-envelope-v1`, `partner-proof-envelope-v1` | `false` | rejected: `external_verification_required` |
+
+Default `valid` semantics are unchanged. Options:
+
+- `strict: true` (or env `XOONYA_STRICT_VERIFY=1`): only `cryptographic` results are `valid`.
+- `expected_public_key_ref`, `expected_classical_public_key_ref`, `expected_pq_public_key_ref`, `expected_hybrid_public_key_ref`: pin the exact key refs a native proof must carry.
+- `trusted_public_key_refs`: `{ "<identity_ref>": "<ref>" | ["<ref>", ...] | { "classical": ..., "pq": ..., "hybrid": ... } }`. Native signed proofs fail with `native_public_key_not_trusted` and native hybrid proofs with `native_hybrid_public_key_not_trusted` when the signing key is not pinned for that identity. Any trust-root option sets `trust_root_applied: true` and fails closed for identities that are not listed.
+
+Without a trust root, a native signed proof only proves that the carried key signed the receipt; `identity_ref` and `agent_identity` are not bound to that key by xoonya. `npm run verify:forgery-resistance` pins this behavior.
+
+Public conformance command:
+
+```bash
+xoonya conformance
+xoonya conformance --json
+```
+
+The conformance command verifies the published vector files shipped in the package. The positive set covers `legacy-opreturn-v1`, `detached-assertion-v1`, `xoonya-native-sha256-v1`, `xoonya-native-signed-v1`, `xoonya-native-anchored-v1`, `xoonya-native-hybrid-v1`, `jwt-assertion-v1`, `did-vc-v1`, `sd-jwt-vc-v1`, `signed-envelope-v1`, and `partner-proof-envelope-v1`. The adversarial set covers bad event versions, missing signatures, mismatched commitments, unsupported methods, ambiguous `none`, replayed receipt context, native digest tampering, native signed proof tampering, native anchored proof tampering, native hybrid signature and key-binding tampering, native-to-detached downgrade attempts, and receipt-id mismatches.
+
+Published proof hardening artifacts:
+
+- [conformance-vectors.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/vectors/conformance-vectors.json)
+- [adversarial-vectors.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/vectors/adversarial-vectors.json)
+- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
+
+## Control Files
+
+- `CROSS_RUNTIME_POSTURE.md`
+- `FINAL_CONTRACT.md`
+- `TERMINOLOGY.md`
+- `SERVICE_CONTRACT.md`
+- `COMPATIBILITY_NOTE.md`
+
+## Proof Integration Toolkit
+
+`xoonya` keeps its integration model narrower than `xytara`. The proof-side toolkit is for additive proof helpers only:
+
+- identity-material providers
+- attestation and evidence reference adapters
+- anchor reference adapters
+- profile verification helpers
+- compatibility-oriented proof integrations
+
+This integration toolkit is broader than the proof verification method registry. Verification methods describe how a receipt or proof envelope is admitted at the proof boundary; integrations describe additive proof-side helpers, references, profiles, and staged third-party support that can be reviewed without changing the proof kernel.
+
+The package now includes:
+
+- `validateIntegrationRegistration(...)`
+- `importRegisteredIntegration(...)`
+- `exportIntegrationRegistrySnapshot(...)`
+- `validateIntegrationRegistrySnapshot(...)`
+- `summarizeIntegrationPromotionReadiness(...)`
+- `summarizeIntegrationPromotionWorkflow(...)`
+- `summarizeIntegrationPromotionWorkflowList(...)`
+
+Those helpers are intended to normalize proof-adjacent integrations without letting pricing, workflow, or settlement logic leak into the proof kernel.
+
+For the lightweight external-builder path, use:
+
+- [PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
+
+For lightweight local review flows, `xoonya` also includes a small repo-local proof-side CLI when working from a cloned `xoonya` repository:
+
+```bash
+node scripts/registry_cli.js validate-registration --example verifier
+node scripts/registry_cli.js export-snapshot --registration_state staging_registered
+node scripts/registry_cli.js promotion-readiness --integration partner.verifier.lattice_notary
+node scripts/registry_cli.js promotion-workflow --integration partner.verifier.lattice_notary
+node scripts/registry_cli.js promotion-workflow-summary --source third_party_example --registration_state staging_registered --bundled false
+```
+
+That tooling is intentionally narrow: validate proof-integration registration posture and export filtered proof registry snapshots.
+
+The proof-side readiness layer now also makes promotion posture explicit without expanding `xoonya` into a control plane:
+
+- review-ready means a proof integration is staged and inspectable
+- default-eligible means it can participate in the proof-side default posture
+- production-default-ready means certification, maturity, bundled posture, and selection posture all line up
+- blockers are returned as data instead of being left implicit
+- promotion workflow summaries now show the next proof-side transition and the current recommendation without introducing approval state
+