npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

xoonya

v3.0.1

Published

Deterministic proof and review engine for receipts, handoffs, governance, and verification.

Downloads

1,850

Vulnerabilities

Powered byPowered by Snyk
  • 0High
  • 0Medium
  • 0Low

Links

Maintainers

naxytranaxytra

Keywords

proofreviewhandoffgovernanceauditreceiptcanonical-eventsproof-bundledeterministicmachineevidence

Readme

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 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:

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:

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:

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

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

Start Here

If you are new to the proof-side package, use this order:

  1. read START_HERE.md
  2. run node examples/package_quickstart.js
  3. run npm run verify:all
  4. use FINAL_CONTRACT.md and 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:

If you want one concrete cross-repo adoption story, start with:

If you want the shortest neutral external-adoption bundle, continue with:

If you are integrating from outside the stack, also read:

If you want the broader already-core proof continuity layers, continue with:

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:

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. See XOONYA_NATIVE_ATOM_SPEC.md. See XOONYA_NATIVE_STANDARD_GOVERNANCE.md. See XNYA_CONFORMANCE_MARK.md. See XNYA_REFERENCE_IMPLEMENTATIONS.md. See 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:

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:

npm start

Then in another shell:

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:

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 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:

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:

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:

For lightweight local review flows, xoonya also includes a small repo-local proof-side CLI when working from a cloned xoonya repository:

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