xoonya 2.14.0 → 3.0.0

package/README.md

@@ -43,6 +43,36 @@ The shortest public proof loop is:
 - 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)
+
+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
@@ -52,6 +82,22 @@ The current proof breadth already includes:
 - 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`
+
 ## One-Line After Install
 
 If you only run two commands after install, use:
@@ -75,31 +121,39 @@ If you want the shortest machine-readable discovery path, inspect:
 
 If you are new to the proof-side package, use this order:
 
-1. read [START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/START_HERE.md)
+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_public/naxytra/xoonya/FINAL_CONTRACT.md) and [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/SERVICE_CONTRACT.md) as the durable public contract
+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_public/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PARTNER_READY_PATH.md)
+- [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_public/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
+- [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_public/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
-- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/EXAMPLE_PATHS.md)
+- [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_public/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
-- [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
+- [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
 
@@ -252,7 +306,7 @@ Current built-in methods:
 
 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`, and `xoonya-native-anchored-v1`. The signed native method verifies Ed25519, secp256k1, and P-256 today and keeps PQ/hybrid suites in the registry until their validators are implemented, so the standard stays agnostic without overclaiming. The anchored native method binds receipts to declared anchor/finality/attestation refs without claiming the external system has been independently verified by xoonya.
+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.
 
@@ -262,7 +316,7 @@ XNYA atom conformance now includes stable machine-readable reject codes and adve
 
 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 PQ/hybrid verification, live external-provider execution, chain finality, custody, identity/auth, or external issuer truth without separate verifier evidence. Until real PQ/hybrid validators exist, `xoonya-native-hybrid-v1` is an explicit design-gate method that rejects with `native_hybrid_design_gated`.
+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.
 
@@ -334,7 +388,7 @@ curl -X POST http://127.0.0.1:4310/v1/events/hash ^
 
 Environment example:
 
-- [`.env.example`](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/.env.example)
+- [`.env.example`](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/.env.example)
 
 ## Service Routes
 
@@ -555,7 +609,7 @@ This is intended to make the proof-side continuation path easier to adopt as the
 
 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_public/naxytra/xoonya/START_HERE.md) onboarding path
+- 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`
@@ -613,13 +667,13 @@ 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`, `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`, explicit native hybrid/PQ design-gated rejection, replayed receipt context, native digest tampering, native signed proof tampering, native anchored proof tampering, native-to-detached downgrade attempts, and receipt-id mismatches.
+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_public/naxytra/xoonya/vectors/conformance-vectors.json)
-- [adversarial-vectors.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/vectors/adversarial-vectors.json)
-- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
+- [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
 
@@ -655,7 +709,7 @@ Those helpers are intended to normalize proof-adjacent integrations without lett
 
 For the lightweight external-builder path, use:
 
-- [PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
+- [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:
 
@@ -676,3 +730,4 @@ The proof-side readiness layer now also makes promotion posture explicit without
 - 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
+

package/RELEASE_NOTES.md

@@ -1,14 +1,15 @@
-`xoonya` 2.14.0 is the lifecycle and continuity hardening release for stronger proof-side followthrough, trust portability, and cross-venue review continuity.
+`xoonya` 3.0.0 is the final synchronized major release for the live proof, verification, continuity, governance, replay, and public first-contact line.
 
-This release keeps the synchronized public-release bundle intact while tightening trust-portability, governance/dispute visibility, and the runtime-to-proof followthrough story into one coherent next step toward the final closeout line.
+This release cuts the final public proof line only after the final synchronized dress rehearsal stayed green, the frozen proof truth models were already live, the widened finish-line scope was implemented, and the naxytra public contract, proof, release, and gate surfaces were aligned tightly enough for a truthful launch-grade major version.
 
 Highlights:
 
-- keeps `/v1/proof-center/trust-portability` and `/v1/proof-center/trust-portability/summary` as the named proof-side continuity boundary for the release
-- strengthens visibility for portability across identity, delegation, delivery history, and settlement-linked followthrough
+- keeps `/v1/proof-truth` and `/v1/proof-truth/summary` as the named proof object boundary
+- keeps `/v1/default-path` and `/v1/default-path/summary` as the named proof-side multi-surface entry boundary
+- keeps `/v1/followthrough-truth` and `/v1/followthrough-truth/summary` as the named bridge, governance, portability, and verification claim boundary
 - keeps verification services, trust-portability surfaces, governance/dispute visibility, and reference-implementation posture aligned with the same synchronized public release line
-- preserves XNYA-compatible conformance, native reference implementation boundaries, external proof import boundaries, and the PQ/hybrid design gate
-- strengthens the native-standard, payload-profile, line-rate-frame, and conformance-mark story as one discoverable proof stack
+- promotes bounded native hybrid live verification for registered runtime-supported vector-covered suites instead of leaving PQ/hybrid as a design-only posture
+- preserves XNYA-compatible conformance, native reference implementation boundaries, external proof import boundaries, deterministic replay posture, and proof-side governance as one discoverable proof stack inside the final major line
 - keeps `RELEASE_NOTES.md` scoped to the current release so npm and GitHub release notes stay clean
 - keeps the canonical `https://naxytra.com/xoonya` public product URL and single naxytra website positioning intact
-- verifies the release candidate, full package verifier, umbrella pre-deploy gates, and clean-consumer release smoke
+- verifies the release candidate, full package verifier, umbrella pre-deploy gates, and clean-consumer release smoke before the major cut

package/START_HERE.md

@@ -4,7 +4,7 @@ This is the shortest reliable path for understanding and using the public `xoony
 
 The phase program is now complete, so this file is the right starting point for a closed and release-shaped proof system rather than an in-flight milestone build.
 
-The next public release path is intentionally intermediary and is now centered on the paired `2.14.0` lifecycle and continuity hardening milestone documented in [RELEASE_2_14_0_LIFECYCLE_CONTINUITY_PLAN.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/release/RELEASE_2_14_0_LIFECYCLE_CONTINUITY_PLAN.md) and [PUBLISH_PLAN.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PUBLISH_PLAN.md). That release is meant to tighten proof-side followthrough before the final `3.0.0` consolidation.
+The product-side implementation, proof posture, and bounded hybrid verification work for the widened `3.0.0` finish line are now complete. The remaining step is the synchronized public `3.0.0` release cut, publish, deploy, and verification sequence documented in [NAXYTRA_3_0_0_RELEASE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/release/NAXYTRA_3_0_0_RELEASE_CONTRACT.md) and [PUBLISH_PLAN.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLISH_PLAN.md).
 
 ## 1. Understand The Role
 
@@ -29,6 +29,27 @@ Then run the local proof followthrough:
 xoonya first-run --verify-native --pretty
 ```
 
+If you want the frozen machine-readable proof-truth contract behind that flow, inspect:
+
+```text
+GET /v1/proof-truth
+GET /v1/proof-truth/summary
+```
+
+If you want the frozen machine-readable proof default-path contract behind that flow, inspect:
+
+```text
+GET /v1/default-path
+GET /v1/default-path/summary
+```
+
+If you want the frozen machine-readable followthrough claim boundary behind that flow, inspect:
+
+```text
+GET /v1/followthrough-truth
+GET /v1/followthrough-truth/summary
+```
+
 ## 2. Run The Fastest Real Example
 
 Run:
@@ -41,13 +62,13 @@ This is the fastest way to see the intended proof-side package story end-to-end.
 
 If you want the clearest cross-repo adoption path instead of the broad package tour, continue with:
 
-- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
+- [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_public/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
-- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/EXAMPLE_PATHS.md)
+- [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`
 
 ## 3. Verify The Whole Package
@@ -64,8 +85,8 @@ This is the production-confidence check for the published proof package surface.
 
 For long-term product understanding, read:
 
-- [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/FINAL_CONTRACT.md)
-- [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/SERVICE_CONTRACT.md)
+- [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/FINAL_CONTRACT.md)
+- [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/SERVICE_CONTRACT.md)
 - `GET /openapi.json`
 - `GET /asyncapi.json`
 - `GET /cloudevents.json`
@@ -87,23 +108,23 @@ For long-term product understanding, read:
 - `GET /v1/result-package-trust`
 - `GET /v1/event-systems`
 - `GET /v1/integrations`
-- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PROGRAM_STATUS.md)
-- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/OPERATOR_START_HERE.md)
-- [OPERATIONS_RUNBOOK.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/OPERATIONS_RUNBOOK.md)
-- [PROGRAM_COMPLETE_RELEASE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PROGRAM_COMPLETE_RELEASE.md)
-- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
-- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [TERMINOLOGY.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/TERMINOLOGY.md)
+- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_STATUS.md)
+- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
+- [OPERATIONS_RUNBOOK.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATIONS_RUNBOOK.md)
+- [PROGRAM_COMPLETE_RELEASE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_COMPLETE_RELEASE.md)
+- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
+- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
+- [TERMINOLOGY.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/TERMINOLOGY.md)
 
 ## 5. If You Are Integrating From Outside
 
 Continue with:
 
-- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
-- [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [COMPATIBILITY_NOTE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/COMPATIBILITY_NOTE.md)
+- [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)
+- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
+- [COMPATIBILITY_NOTE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/COMPATIBILITY_NOTE.md)
 
 ## 6. Production Reading Rule
 
@@ -125,5 +146,5 @@ If you want the shortest CLI-first read of the package after install, use:
 
 Use:
 
-- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/PROGRAM_STATUS.md)
-- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_public/naxytra/xoonya/OPERATOR_START_HERE.md)
+- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_STATUS.md)
+- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)

package/XNYA_REFERENCE_IMPLEMENTATIONS.md

@@ -55,7 +55,7 @@ It currently covers:
 - receipt emission for external assertion, native digest, legacy OP_RETURN, and native anchored methods
 - proof-bundle build/verify parity for non-signed native methods
 - adversarial reason parity for non-signed proof-bundle checks
-- deterministic `native_hybrid_design_gated` rejection for the future hybrid/PQ method
+- bounded hybrid-method awareness without yet claiming independent PQ/hybrid validator parity
 - optional Ed25519 native signed verification when the Python `cryptography` package is available
 - deterministic `native_signature_crypto_dependency_missing` when the optional crypto dependency is absent
 
@@ -65,7 +65,7 @@ Run:
 npm run verify:reference-python
 ```
 
-This is vector-parity progress, not a full reference promotion. Python does not yet claim always-on native signature-suite cryptographic verification, secp256k1/P-256 parity, external method import, or all native signed proof-bundle round-trip behavior.
+This is vector-parity progress, not a full reference promotion. Python does not yet claim always-on native signature-suite cryptographic verification, secp256k1/P-256 parity, external method import, independent PQ/hybrid signature parity, or all native signed proof-bundle round-trip behavior.
 
 Optional Ed25519 crypto check:
 
@@ -120,7 +120,7 @@ An implementation may claim `XNYA-compatible` only when it:
 - rejects unsupported or malformed native atoms with deterministic errors
 - rejects `algorithm: "none"` as a production proof method
 - verifies only implemented signature suites with suite-specific validators
-- treats PQ/hybrid methods as design-gated until validators and vectors exist
+- treats PQ/hybrid methods as independently unverified until that runtime has its own validators and vector parity
 - binds external proof formats without claiming external issuer truth
 - binds anchor references without claiming external chain or provider finality truth
 

package/XOONYA_DEFAULT_PATH_MODEL.md

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

package/XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md

@@ -0,0 +1,63 @@
+# xoonya Followthrough Truth Model
+
+`xoonya` cannot reach a truthful `3.0.0` if its followthrough story is left as scattered bridge, governance, trust-portability, and verification endpoints.
+
+For the public launch line, it needs one frozen answer to:
+
+- what proof-side followthrough is publicly claimable
+- what trust portability is real and bounded
+- what bridge carry is real and bounded
+- what governance and dispute posture is real and bounded
+- what must remain outside the public `xoonya` claim boundary
+
+## Core Rule
+
+All public followthrough claims must stay inside one bounded proof-side truth:
+
+`verify -> carry -> review -> govern -> preserve continuity`
+
+`xoonya` may expose many helper routes.
+It may not imply unbounded scope.
+
+## Covered Followthrough Families
+
+The frozen `3.0.0` followthrough truth model covers:
+
+- verification services
+- trust portability
+- bridge followthrough
+- governance followthrough
+
+## What This Model Allows Us To Claim
+
+We can publicly claim:
+
+- proof bundles, receipts, and handoffs can be verified and replayed through real public surfaces
+- trust can remain portable across the listed identity, delegation, delivery, and settlement-linked review lanes
+- bridge carry can preserve operator and compatibility review without becoming the runtime owner
+- governance can preserve disputes, signoff, interpretation, and handoff continuity without pretending to be universal legal truth
+
+## What This Model Does Not Allow Us To Claim
+
+We do not publicly claim:
+
+- unbounded runtime execution truth
+- universal external chain truth
+- universal custody truth
+- universal identity truth
+- universal legal or regulatory judgment truth
+
+## Machine-Readable Surfaces
+
+- `GET /v1/followthrough-truth`
+- `GET /v1/followthrough-truth/summary`
+- `GET /v1/followthrough-truth/:profile_id`
+
+## Launch Standard
+
+For `3.0.0`, this model is considered real only if:
+
+- each listed profile has callable first-party surfaces
+- each listed profile stays attached to proof truth and proof review
+- each listed profile has an explicit claim boundary
+- no launch copy overstates `xoonya` beyond these frozen followthrough profiles

package/XOONYA_NATIVE_PROOF_FORMAT.md

@@ -325,13 +325,36 @@ Important boundary:
 
 ### `xoonya-native-hybrid-v1`
 
-Design-gated future extension.
+Implemented for registered runtime-supported suite pairs.
 
-This should provide stronger-crypto or PQC-sensitive proof lanes if production need appears. It should not become the default until there is a real reason.
+This method provides stronger-crypto and PQ-sensitive proof lanes without redefining the rest of the native proof model. It is not the global default; it is the promoted higher-assurance lane when a runtime can actually verify the declared classical and PQ signatures together.
 
-The current rule is strict: `xoonya-native-hybrid-v1` remains design-gated until runtime validators, public key formats, conformance vectors, adversarial vectors, and deterministic error codes exist. xoonya may expose readiness and promotion criteria for this method, but must not claim PQC or hybrid verification before those artifacts are real.
+The current rule is strict:
 
-Before promotion, any proof bundle that directly asks the current verifier to accept `xoonya-native-hybrid-v1` must fail with the deterministic reason `native_hybrid_design_gated`. Hybrid-looking native signatures also must not verify through an external assertion method; those downgrade attempts fail as `signature_method_mismatch`.
+- only registered runtime-supported suite pairs may be claimed as verified
+- current first-class promoted verification is `ed25519+ml-dsa-65`
+- other candidate hybrid combinations remain non-claimable until runtime support, vectors, and deterministic error behavior exist
+
+Required hybrid fields:
+
+- `method`
+- `hybrid_suite`
+- `identity_ref`
+- `classical_public_key_ref`
+- `pq_public_key_ref`
+- `classical_public_key_material`
+- `pq_public_key_material`
+- `proof_material.classical_signature`
+- `proof_material.pq_signature`
+- `proof_material.signing_material_sha256`
+
+Current adversarial expectations include:
+
+- tampered PQ signature rejects as `native_hybrid_pq_signature_invalid`
+- key-binding mismatches reject as `native_hybrid_public_key_ref_mismatch`
+- downgrade attempts through external assertion methods reject as `signature_method_mismatch`
+
+This keeps the boundary honest: xoonya now verifies the hybrid lane where the runtime and vectors are real, and refuses to overclaim beyond that runtime-supported registry.
 
 ## Crypto And Identity Support Boundary
 

package/XOONYA_PROOF_TRUTH_MODEL.md

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

package/index.js

@@ -5,6 +5,9 @@ module.exports = {
   ...require("./integrations/registry"),
   ...require("./lib/verification_service_pack"),
   ...require("./lib/trust_portability_pack"),
+  ...require("./lib/proof_truth_contract"),
+  ...require("./lib/default_path_contract"),
+  ...require("./lib/followthrough_truth_contract"),
   ...require("./lib/governance_disputes_summary"),
   ...require("./lib/release_pack"),
   ...require("./lib/release_manifest"),