xytara 3.1.0 → 3.1.2

package/XYTARA_EXECUTION_TRUTH_MODEL.md

@@ -1,171 +1,171 @@
-# xytara Execution Truth Model
-
-Status: active closeout contract
-
-Version: `xytara-execution-truth-model/v1`
-
-## Purpose
-
-This document freezes the runtime-side execution-truth model for `xytara`.
-
-It answers the closeout question:
-
-> What is the canonical hot-state fact model that `xytara` owns before proof followthrough moves into `xoonya`?
-
-The answer is:
-
-- `xytara` owns the runtime-side truth of quote, payment, execution, delivery, settlement linkage, treasury linkage, and proof handoff
-- `xoonya` owns proof semantics, proof verification semantics, and native proof truth
-
-## Core Doctrine
-
-`xytara` execution truth is not one isolated blob.
-
-It is a linked runtime-side object model:
-
-1. `quote`
-2. `transaction`
-3. `receipt`
-4. `delivery`
-5. `settlement`
-6. `proof_handoff`
-
-These objects together form the canonical `xytara` fact spine.
-
-## Object Roles
-
-### 1. Quote
-
-The quote is the priced pre-execution offer.
-
-It binds:
-
-- account
-- amount
-- currency
-- capability scope
-- adapter/settlement posture
-
-It must exist before irreversible paid execution.
-
-### 2. Transaction
-
-The transaction is the primary hot-state execution record.
-
-It carries:
-
-- payment state
-- settlement state
-- treasury state
-- execution state
-- timing
-- remediation state
-
-This is the main runtime object for "what happened."
-
-### 3. Receipt
-
-The receipt is the runtime completion record with a proof pointer.
-
-It carries:
-
-- execution summary
-- payment/settlement/treasury mirrors
-- timing
-- remediation
-- `proof_ref`
-
-It is not the proof core.
-
-It is the runtime-side completion artifact that points into proof followthrough.
-
-### 4. Delivery
-
-The delivery record captures:
-
-- where the result went
-- whether it was direct or callback-driven
-- callback retry/queue/failure state
-- output and proof refs
-
-This is part of runtime truth, not a proof-side side note.
-
-### 5. Settlement
-
-Settlement truth is linked to execution truth, but it is not identical to execution success.
-
-`xytara` must preserve:
-
-- settlement reference
-- mode
-- adapter
-- binding hash
-- finality posture where available
-
-without collapsing execution success into chain finality or treasury consequence.
-
-### 6. Proof Handoff
-
-`xytara` emits proof-compatible facts and references.
-
-That handoff includes:
-
-- `receipt.proof_ref`
-- `receipt.execution_summary`
-- `transaction.execution.results_by_task_id`
-- `delivery.proof_ref`
-
-`xoonya` then owns proof review, verification, continuity, and governance followthrough.
-
-## Layer Sequence
-
-The frozen runtime sequence is:
-
-1. quote
-2. pay or authorize
-3. execute
-4. deliver
-5. settle and reconcile
-6. hand off into proof followthrough
-
-This sequence may run synchronously or asynchronously, but the truth model does not change.
-
-## Non-Negotiable Invariants
-
-The following invariants define the closeout standard:
-
-1. Quote precedes irreversible paid execution.
-2. Transaction is the canonical hot-state execution record.
-3. Receipt is the runtime completion record, not the proof core.
-4. Delivery truth remains first-class and inspectable.
-5. Settlement truth remains linked but distinct from execution success.
-6. Treasury consequence remains reconstructible from runtime artifacts.
-7. `xytara` emits proof-compatible facts without redefining `xoonya` proof semantics.
-
-## Public Surfaces
-
-The machine-readable execution-truth surface is:
-
-- `GET /v1/execution-truth`
-- `GET /v1/execution-truth/summary`
-
-Supporting public surfaces include:
-
-- `GET /v1/capability-registry/execution-truth`
-- `GET /v1/lifecycle-continuity`
-- `GET /v1/deliveries`
-- `GET /v1/revenue-launch/paths`
-- `GET /v1/providers/journeys`
-- `POST /v1/transaction-center/result-packages/export`
-
-Proof followthrough boundary:
-
-- `https://xoonya.onrender.com/v1/proof-center/result-package-handoff/run`
-
-## Closeout Meaning
-
-For `3.0.0`, this model means:
-
-- the execution side is no longer only implied by multiple adjacent artifacts
-- the runtime-side fact model is explicit and frozen
-- outside builders and operators can understand where execution truth ends and proof truth begins
+# xytara Execution Truth Model
+
+Status: active closeout contract
+
+Version: `xytara-execution-truth-model/v1`
+
+## Purpose
+
+This document freezes the runtime-side execution-truth model for `xytara`.
+
+It answers the closeout question:
+
+> What is the canonical hot-state fact model that `xytara` owns before proof followthrough moves into `xoonya`?
+
+The answer is:
+
+- `xytara` owns the runtime-side truth of quote, payment, execution, delivery, settlement linkage, treasury linkage, and proof handoff
+- `xoonya` owns proof semantics, proof verification semantics, and native proof truth
+
+## Core Doctrine
+
+`xytara` execution truth is not one isolated blob.
+
+It is a linked runtime-side object model:
+
+1. `quote`
+2. `transaction`
+3. `receipt`
+4. `delivery`
+5. `settlement`
+6. `proof_handoff`
+
+These objects together form the canonical `xytara` fact spine.
+
+## Object Roles
+
+### 1. Quote
+
+The quote is the priced pre-execution offer.
+
+It binds:
+
+- account
+- amount
+- currency
+- capability scope
+- adapter/settlement posture
+
+It must exist before irreversible paid execution.
+
+### 2. Transaction
+
+The transaction is the primary hot-state execution record.
+
+It carries:
+
+- payment state
+- settlement state
+- treasury state
+- execution state
+- timing
+- remediation state
+
+This is the main runtime object for "what happened."
+
+### 3. Receipt
+
+The receipt is the runtime completion record with a proof pointer.
+
+It carries:
+
+- execution summary
+- payment/settlement/treasury mirrors
+- timing
+- remediation
+- `proof_ref`
+
+It is not the proof core.
+
+It is the runtime-side completion artifact that points into proof followthrough.
+
+### 4. Delivery
+
+The delivery record captures:
+
+- where the result went
+- whether it was direct or callback-driven
+- callback retry/queue/failure state
+- output and proof refs
+
+This is part of runtime truth, not a proof-side side note.
+
+### 5. Settlement
+
+Settlement truth is linked to execution truth, but it is not identical to execution success.
+
+`xytara` must preserve:
+
+- settlement reference
+- mode
+- adapter
+- binding hash
+- finality posture where available
+
+without collapsing execution success into chain finality or treasury consequence.
+
+### 6. Proof Handoff
+
+`xytara` emits proof-compatible facts and references.
+
+That handoff includes:
+
+- `receipt.proof_ref`
+- `receipt.execution_summary`
+- `transaction.execution.results_by_task_id`
+- `delivery.proof_ref`
+
+`xoonya` then owns proof review, verification, continuity, and governance followthrough.
+
+## Layer Sequence
+
+The frozen runtime sequence is:
+
+1. quote
+2. pay or authorize
+3. execute
+4. deliver
+5. settle and reconcile
+6. hand off into proof followthrough
+
+This sequence may run synchronously or asynchronously, but the truth model does not change.
+
+## Non-Negotiable Invariants
+
+The following invariants define the closeout standard:
+
+1. Quote precedes irreversible paid execution.
+2. Transaction is the canonical hot-state execution record.
+3. Receipt is the runtime completion record, not the proof core.
+4. Delivery truth remains first-class and inspectable.
+5. Settlement truth remains linked but distinct from execution success.
+6. Treasury consequence remains reconstructible from runtime artifacts.
+7. `xytara` emits proof-compatible facts without redefining `xoonya` proof semantics.
+
+## Public Surfaces
+
+The machine-readable execution-truth surface is:
+
+- `GET /v1/execution-truth`
+- `GET /v1/execution-truth/summary`
+
+Supporting public surfaces include:
+
+- `GET /v1/capability-registry/execution-truth`
+- `GET /v1/lifecycle-continuity`
+- `GET /v1/deliveries`
+- `GET /v1/revenue-launch/paths`
+- `GET /v1/providers/journeys`
+- `POST /v1/transaction-center/result-packages/export`
+
+Proof followthrough boundary:
+
+- `https://xoonya.onrender.com/v1/proof-center/result-package-handoff/run`
+
+## Closeout Meaning
+
+For `3.0.0`, this model means:
+
+- the execution side is no longer only implied by multiple adjacent artifacts
+- the runtime-side fact model is explicit and frozen
+- outside builders and operators can understand where execution truth ends and proof truth begins

package/XYTARA_PAYMENT_RAIL_TRUTH_MODEL.md

@@ -1,68 +1,68 @@
-# xytara Payment And Rail Truth Model
-
-For `3.0.0`, `xytara` needs a payment story that is both broad and honest.
-
-That means one public rule:
-
-- payment fronts can be callable and live
-- settlement families can be runtime-ready
-- but a specific treasury landing rail is only a public live claim when it is explicitly configured and allowed
-
-## Core Distinction
-
-There are two different truths:
-
-1. payment and execution truth
-2. treasury landing claim truth
-
-The first answers:
-
-- can the caller quote?
-- can they pay through a supported front?
-- can the work execute right away?
-- can the result continue into proof followthrough?
-
-The second answers:
-
-- which exact rail can we publicly say is already a live landing destination?
-
-Those are related, but they are not the same.
-
-## Launch Defaults
-
-The frozen `3.0.0` default posture is:
-
-- machine-native default front: `x402`
-- repeat-use default front: `account_credits`
-- human/browser default front: hosted checkout
-- optional permissionless fronts: `l402`, `bolt`
-- native settlement center: `bsv_teranode`
-
-## Claim Discipline
-
-`xytara` may publicly claim:
-
-- callable payment fronts
-- funded runtime execution
-- proof-ready followthrough
-- supported settlement families
-
-`xytara` must not publicly claim:
-
-- a specific rail as live treasury landing truth unless `public_claim_allowed` is true for that rail
-- operator-only custody or landing refs on public surfaces
-- adapter-ready fronts as first-party launch defaults
-
-## Machine-Readable Surfaces
-
-- `GET /v1/payment-rail-truth`
-- `GET /v1/payment-rail-truth/summary`
-- `GET /v1/payment-rail-truth/:profile_id`
-
-## Why This Matters
-
-This keeps the `3.0.0` claim clean:
-
-- we can truthfully say users can pay through multiple comfortable fronts
-- we can truthfully say execution and proof followthrough are real
-- we do not overclaim live treasury landing breadth where real operator configuration is still the deciding factor
+# xytara Payment And Rail Truth Model
+
+For `3.0.0`, `xytara` needs a payment story that is both broad and honest.
+
+That means one public rule:
+
+- payment fronts can be callable and live
+- settlement families can be runtime-ready
+- but a specific treasury landing rail is only a public live claim when it is explicitly configured and allowed
+
+## Core Distinction
+
+There are two different truths:
+
+1. payment and execution truth
+2. treasury landing claim truth
+
+The first answers:
+
+- can the caller quote?
+- can they pay through a supported front?
+- can the work execute right away?
+- can the result continue into proof followthrough?
+
+The second answers:
+
+- which exact rail can we publicly say is already a live landing destination?
+
+Those are related, but they are not the same.
+
+## Launch Defaults
+
+The frozen `3.0.0` default posture is:
+
+- machine-native default front: `x402`
+- repeat-use default front: `account_credits`
+- human/browser default front: hosted checkout
+- optional permissionless fronts: `l402`, `bolt`
+- native settlement center: `bsv_teranode`
+
+## Claim Discipline
+
+`xytara` may publicly claim:
+
+- callable payment fronts
+- funded runtime execution
+- proof-ready followthrough
+- supported settlement families
+
+`xytara` must not publicly claim:
+
+- a specific rail as live treasury landing truth unless `public_claim_allowed` is true for that rail
+- operator-only custody or landing refs on public surfaces
+- adapter-ready fronts as first-party launch defaults
+
+## Machine-Readable Surfaces
+
+- `GET /v1/payment-rail-truth`
+- `GET /v1/payment-rail-truth/summary`
+- `GET /v1/payment-rail-truth/:profile_id`
+
+## Why This Matters
+
+This keeps the `3.0.0` claim clean:
+
+- we can truthfully say users can pay through multiple comfortable fronts
+- we can truthfully say execution and proof followthrough are real
+- we do not overclaim live treasury landing breadth where real operator configuration is still the deciding factor