From d513d387a8c0deed3d5b60f33e510c31cb981595 Mon Sep 17 00:00:00 2001 From: philipp Date: Fri, 10 Apr 2026 11:29:23 +0200 Subject: [PATCH] Archive implementation turn: execution outcome truth and settled attribution Proof: Preserve the completed implementation turn and record its outcome in the tracked archive. Assumptions: The archived files capture the relevant planning state for the completed turn. Still fake: Archiving does not validate the work by itself; external evidence still governs whether the result is trustworthy. --- ARCHIVE.md | 1 + IMPLEMENTATION.md | 175 +----------------- PROOF.md | 139 +------------- ...-and-settled-attribution-implementation.md | 174 +++++++++++++++++ ...ome-truth-and-settled-attribution-proof.md | 138 ++++++++++++++ 5 files changed, 319 insertions(+), 308 deletions(-) create mode 100644 archive/implementation/20260410T092923Z-execution-outcome-truth-and-settled-attribution-implementation.md create mode 100644 archive/implementation/20260410T092923Z-execution-outcome-truth-and-settled-attribution-proof.md diff --git a/ARCHIVE.md b/ARCHIVE.md index 76581fb..b19c1f7 100644 --- a/ARCHIVE.md +++ b/ARCHIVE.md @@ -13,6 +13,7 @@ Legacy note: - 2026-04-08: `cow-protocol-intent-based-venue-integration` closed with status `paused`. The CoW venue integration turn is paused after cluster investigation showed a real NEAR Intents ingest outage exposed a larger observability gap: the dashboard did not escalate stale quote flow or disconnected websocket clients, so runtime health and alerting need to be strengthened before adding a second venue. - 2026-04-08: `runtime-health-sentinel-alert-routing-and-anomaly-detection` closed with status `passed`. Runtime health is now sentinel-owned, stale truth no longer renders healthy, alert delivery and safe containment exist, and deployment automation rolls all repo-owned services from push. - 2026-04-09: `quote-lifecycle-truth-and-execution-explanation` closed with status `passed`. Live operator surfaces now derive quote lifecycle from durable evidence, distinguish strategy rejection from executor blocking and submission, expose copyable quote traces, and no longer overclaim submission as completion or asset movement. +- 2026-04-10: `execution-outcome-truth-and-settled-attribution` closed with status `passed`. Deployed e0dfd24, validated 1 completed heuristic settlement-attributed trade, 6 inferred not-filled outcomes, submitted-only rows without asset deltas, and stable armed strategy/executor at the approved 1.49% threshold. ## Research Turns ## Planning Events diff --git a/IMPLEMENTATION.md b/IMPLEMENTATION.md index 444b42c..c6b72a8 100644 --- a/IMPLEMENTATION.md +++ b/IMPLEMENTATION.md @@ -1,174 +1,5 @@ -# Implementation Turn: execution outcome truth and settled attribution +# Implementation Turn -Status: open -Opened: 2026-04-09 +Status: idle -## Goal -Make the live BTC/EURe quote path more real by durably linking submission, downstream outcome, and settled inventory attribution so the dashboard can distinguish completion from submission and show real post-trade movement where available. - -## Selected backlog items -- [I017] Per-trade realized attribution: link each successful trade to actual settled inventory deltas and attributable costs so the system can report realized net contribution per trade instead of only expected edge. -- [I018] Quote-to-outcome and markout analytics: link quote, response, decision, execution result, and settlement, then store later reference-price markouts to measure adverse selection and quote quality. - -## Design rules -- Treat downstream outcome and settlement truth as part of the same shared evidence path, not separate dashboard decoration. -- Preserve the current turn’s semantic boundary: submission is still non-terminal. -- Store explicit linkage and attribution records instead of recomputing ad hoc joins differently across pages. -- If a linkage is heuristic, store the heuristic and expose uncertainty. -- Keep the first implementation narrow to the active pair and current venue. - -## Problem statement for this turn -The repository now explains why a quote was rejected, blocked, or submitted, but it still does not fully explain what happened after submission: -- terminal outcome truth is absent or disconnected -- recent submission tables are still quote-term oriented rather than settlement oriented -- completed and realized labels cannot yet be proven from repo-owned durable records -- later analytics such as markout and realized contribution have no canonical per-quote linkage record - -This turn must therefore improve: -- downstream outcome ingestion or linkage -- quote-to-outcome storage -- settlement attribution storage -- operator rendering of completed versus submission-only rows - -## Required evidence model -Add one repo-owned quote outcome and attribution model with at least: -- `quote_id` -- `decision_id` -- `command_id` -- `execution_result_status` -- `outcome_status` -- `outcome_observed_at` -- `outcome_source` -- `attribution_status` -- `attributed_inventory_delta` -- `attribution_method` -- `markout_reference_price` where implemented - -Suggested vocabulary: -- outcome states: - - `submitted` - - `awaiting_outcome` - - `not_filled` - - `completed` -- attribution states: - - `unattributed` - - `heuristic_match` - - `linked_settlement` - -## Backend changes - -### 1. Add durable outcome linkage -- inspect available downstream event sources, solver relay data, inventory movement evidence, and existing history tables -- add a durable record or derived snapshot that links a submitted quote to later terminal outcome when possible -- preserve source timestamps and raw evidence pointers - -### 2. Add durable settlement attribution -- link completed quote outcomes to later inventory movement for the active assets -- store both raw units and formatted operator values -- track whether the attribution is exact or heuristic -- do not report net realized contribution unless costs are explicitly present - -### 3. Extend dashboard bootstrap models -- expose recent quote outcome rows with terminal evidence where available -- expose settled attribution separately from submitted quote terms -- ensure summary metrics count completed outcomes and submission-only rows separately - -### 4. Prepare markout support on the same linkage path -- if implemented in this turn, compute later reference-price markout from the linked quote or completion timestamp -- store it in a way that cannot be confused with realized settlement contribution - -## UI changes - -### Strategy page -- extend lifecycle rows so submitted paths can become `Awaiting outcome`, `Not filled`, or `Completed` -- show linked outcome reason and settlement attribution state -- keep quote, decision, and command trace ids visible - -### Funds page -- separate: - - recent submission terms - - recent settled attribution - - completed outcome ledger -- if no settled attribution exists yet for a completed row, say that plainly - -### Summary language -- introduce distinct labels for: - - recent submissions - - recent completed outcomes - - recent settled attributions -- never reuse one metric for all three concepts - -## Edge cases -- submitted row with no later evidence: - render as `Submitted` or `Awaiting outcome` -- explicit expiry or non-fill evidence: - render as `Not filled` -- completed outcome with no attributable inventory delta yet: - render completion truthfully, but mark attribution as missing -- inventory movement with no unambiguous quote match: - keep unattributed and do not silently assign -- multiple near-simultaneous quotes in the same direction: - require explicit or recorded heuristic linkage before claiming settlement - -## Concrete implementation order - -### Phase 1. Discover and define outcome sources -- inspect current relay, executor, and inventory evidence -- document what fields can carry downstream outcome and settlement linkage -- define exact versus heuristic attribution rules - -### Phase 2. Implement durable outcome and attribution records -- add storage or derived records for linked outcomes -- add storage or derived records for settlement attribution -- preserve raw references and timestamps - -### Phase 3. Update dashboard aggregation -- join recent lifecycle rows to outcome and attribution records -- split summary metrics and ledgers by evidence strength -- keep submission-only rows clearly non-terminal - -### Phase 4. Validate on live data -- prove at least one recent row remains submission-only -- prove blocked and rejected rows remain distinct -- prove a completed or non-fill row appears only with durable linked evidence -- prove settled attribution is shown only when actual linked movement exists - -## Test plan -- unit tests for outcome linkage: - - submitted with no outcome - - submitted with non-fill outcome - - submitted with completed outcome -- unit tests for attribution: - - completed with linked settlement - - completed without settlement yet - - ambiguous movement remains unattributed -- negative semantic tests: - - submission-only rows must not render completion - - markout must not be labeled realized - - quote terms must not be labeled settled asset delta -- dashboard bootstrap tests for: - - separated summary metrics - - completed rows carrying explicit outcome evidence - - unattributed rows staying plainly unattributed - -## Validation checklist against the proof -- recent rows separate submitted, awaiting, not-filled, and completed where evidence exists -- completed rows show explicit outcome linkage -- settled attribution is visible and clearly sourced -- submission-only rows still do not claim completion or realized movement -- remaining uncertainty is named plainly - -## Failure modes to plan for -- linking the wrong inventory movement to a quote -- mistaking inventory rebalance or treasury movement for trade settlement -- rendering completed from incomplete venue evidence -- blending markout and realized attribution into one metric -- introducing hidden heuristics without storing them - -## Truth review checklist for this turn -For every outcome or attribution field: -- what exact durable event or snapshot backs it -- how is the quote linked to it -- is the linkage exact or heuristic -- what wording would overclaim certainty -- what regression test prevents that overclaim from returning +No approved implementation turn is active yet. diff --git a/PROOF.md b/PROOF.md index 79edb82..71baf39 100644 --- a/PROOF.md +++ b/PROOF.md @@ -1,138 +1,5 @@ -# Implementation Proof: execution outcome truth and settled attribution +# Implementation Proof -Status: open -Opened: 2026-04-09 +Status: idle -## Target outcome -This turn proves that `unrip` can move recent quote rows past submission-only evidence and into durable downstream outcome truth. - -For the live NEAR Intents BTC/EURe system, the operator must be able to answer: -- was the quote merely submitted -- did the venue later complete or not fill it -- what settled inventory delta, if any, was actually observed afterward -- what part of the post-trade change is still inferred versus durably linked - -## Why this is a meaningful architecture test -The previous turn fixed an overclaiming dashboard, but it also exposed the next hard truth gap: -- `submitted` is now shown truthfully as non-terminal evidence -- downstream completion and non-fill states are still mostly absent from durable repo-owned data -- recent asset-term tables still describe submitted quote terms, not settled inventory truth -- realized attribution is still fake because quote response success is not the same thing as completed asset movement - -That means the system is now honest about the gap, but the gap still exists. This turn is where the shared history path must become more real again. - -## Hypothesis -`unrip` becomes materially more trustworthy if it durably links: -- quote -- strategy decision -- execute command -- executor submission result -- downstream venue or relay outcome where available -- later settled inventory deltas attributable to that quote - -The turn passes only if the operator can distinguish submission from later outcome and can inspect a recent completed path with explicit settled attribution instead of implied completion. - -## Scope -- [I017] Per-trade realized attribution: link each successful trade to actual settled inventory deltas and attributable costs so the system can report realized net contribution per trade instead of only expected edge. -- [I018] Quote-to-outcome and markout analytics: link quote, response, decision, execution result, and settlement, then store later reference-price markouts to measure adverse selection and quote quality. -- Focus on the active NEAR Intents BTC/EURe venue and the repo-owned path already in production. -- Cover recent rows first; historical backfill is secondary unless required to prove the live path. - -## Assumptions -- The venue or relay emits enough downstream identifiers or status surfaces to link at least some submitted quotes to later terminal outcomes. -- Inventory snapshots and durable history can support quote-to-settlement attribution for the active pair, even if the first version uses a narrow matching heuristic. -- Some rows will still remain unattributed or partially inferred; the UI and stored records must say that plainly. -- This turn should prioritize truthful linkage and settlement evidence over broad analytics polish. - -## Turn-shaping rules -- `submitted` remains non-terminal evidence. -- `completed`, `not filled`, `settled`, `realized`, and `asset delta` are forbidden unless backed by a durable linked record representing that fact. -- If settlement attribution is heuristic rather than exact, the stored attribution record and operator surface must say so explicitly. -- Do not build a broad analytics suite before the quote-to-outcome path is durably linked. -- Prefer one repo-owned outcome and attribution model reused by storage, dashboard, and later analytics. - -## Non-goals -- No new venue integration. -- No generalized PnL accounting for all treasury cashflows. -- No broad historical backfill project unless needed to prove current-path linkage. -- No strategy changes beyond what is required to preserve truthful lifecycle and attribution semantics. - -## Required operator behavior - -### Outcome truth -For a recent submitted quote, the dashboard must be able to render one of: -- `Submitted` -- `Awaiting outcome` -- `Not filled` -- `Completed` - -The label must be driven by the strongest durable evidence currently stored. - -### Settlement truth -For a recent completed quote, the operator must be able to inspect: -- quote id -- decision id -- command id -- executor result id or submission timestamp -- linked terminal outcome evidence -- linked settled asset delta or explicitly missing settled delta - -### Attribution truth -If the system reports realized contribution, it must be derived from: -- linked settled asset movement -- explicit attributable costs where available - -If costs or full settlement are missing, the system must not claim net realized truth. - -### Markout truth -If markout is stored for completed or submitted rows, it must: -- be clearly labeled as later reference-price comparison -- remain separate from realized settlement attribution - -## Semantic invariants -The implementation and tests must enforce at least: -- `submitted != completed` -- `completed` requires linked terminal outcome evidence -- settled asset delta requires linked settlement evidence, not quote terms -- markout is not realized PnL -- unattributed inventory movement must not be silently assigned to a quote - -## Definition of done -- A durable quote outcome link exists from submission to later outcome where available. -- The repo stores an explicit per-quote outcome or attribution record for the active path. -- The dashboard can show at least one recent path as `Completed` only when durable linked evidence supports it. -- The dashboard can show non-fill or still-awaiting paths truthfully where that evidence exists. -- Recent settled asset delta or explicit lack of attribution is visible per completed row. -- Submission-term tables and summaries do not overclaim settled truth. -- Regression tests cover the negative semantic boundaries above. - -## Validation evidence required -- direct evidence from deployed dashboard or bootstrap payload that recent rows separate `Submitted`, `Blocked`, `Rejected`, `Not filled`, and `Completed` when the evidence exists -- direct evidence that a completed row shows linked settled attribution rather than quote terms alone -- direct evidence that a submission-only row still does not claim completion or realized asset movement -- automated test evidence for quote-to-outcome linkage -- automated test evidence for settlement attribution boundaries - -## Failure conditions -- the system still cannot represent downstream terminal outcome beyond submission -- any UI or backend surface claims completion from submission-only evidence -- settled asset delta is still derived from quoted terms rather than linked settlement evidence -- markout or later reference comparison is presented as realized PnL -- outcome attribution silently guesses across ambiguous rows without recording uncertainty - -## Current real before this turn -- quote, decision, command, and execution submission result are durable -- the dashboard now renders those stages truthfully -- submission counts and recent submission terms are constrained to submission evidence - -## Deliberately not built by this proof -- full treasury fee ledger -- generalized tax or accounting treatment -- multi-venue settlement harmonization - -## Prevention requirements for this proof -- For every new `Completed`, `Not filled`, or realized attribution label: - - what exact durable record backs it - - what linkage key or heuristic connects it to the quote - - what uncertainty remains - - what regression test prevents future overclaiming +No approved implementation proof is active yet. diff --git a/archive/implementation/20260410T092923Z-execution-outcome-truth-and-settled-attribution-implementation.md b/archive/implementation/20260410T092923Z-execution-outcome-truth-and-settled-attribution-implementation.md new file mode 100644 index 0000000..444b42c --- /dev/null +++ b/archive/implementation/20260410T092923Z-execution-outcome-truth-and-settled-attribution-implementation.md @@ -0,0 +1,174 @@ +# Implementation Turn: execution outcome truth and settled attribution + +Status: open +Opened: 2026-04-09 + +## Goal +Make the live BTC/EURe quote path more real by durably linking submission, downstream outcome, and settled inventory attribution so the dashboard can distinguish completion from submission and show real post-trade movement where available. + +## Selected backlog items +- [I017] Per-trade realized attribution: link each successful trade to actual settled inventory deltas and attributable costs so the system can report realized net contribution per trade instead of only expected edge. +- [I018] Quote-to-outcome and markout analytics: link quote, response, decision, execution result, and settlement, then store later reference-price markouts to measure adverse selection and quote quality. + +## Design rules +- Treat downstream outcome and settlement truth as part of the same shared evidence path, not separate dashboard decoration. +- Preserve the current turn’s semantic boundary: submission is still non-terminal. +- Store explicit linkage and attribution records instead of recomputing ad hoc joins differently across pages. +- If a linkage is heuristic, store the heuristic and expose uncertainty. +- Keep the first implementation narrow to the active pair and current venue. + +## Problem statement for this turn +The repository now explains why a quote was rejected, blocked, or submitted, but it still does not fully explain what happened after submission: +- terminal outcome truth is absent or disconnected +- recent submission tables are still quote-term oriented rather than settlement oriented +- completed and realized labels cannot yet be proven from repo-owned durable records +- later analytics such as markout and realized contribution have no canonical per-quote linkage record + +This turn must therefore improve: +- downstream outcome ingestion or linkage +- quote-to-outcome storage +- settlement attribution storage +- operator rendering of completed versus submission-only rows + +## Required evidence model +Add one repo-owned quote outcome and attribution model with at least: +- `quote_id` +- `decision_id` +- `command_id` +- `execution_result_status` +- `outcome_status` +- `outcome_observed_at` +- `outcome_source` +- `attribution_status` +- `attributed_inventory_delta` +- `attribution_method` +- `markout_reference_price` where implemented + +Suggested vocabulary: +- outcome states: + - `submitted` + - `awaiting_outcome` + - `not_filled` + - `completed` +- attribution states: + - `unattributed` + - `heuristic_match` + - `linked_settlement` + +## Backend changes + +### 1. Add durable outcome linkage +- inspect available downstream event sources, solver relay data, inventory movement evidence, and existing history tables +- add a durable record or derived snapshot that links a submitted quote to later terminal outcome when possible +- preserve source timestamps and raw evidence pointers + +### 2. Add durable settlement attribution +- link completed quote outcomes to later inventory movement for the active assets +- store both raw units and formatted operator values +- track whether the attribution is exact or heuristic +- do not report net realized contribution unless costs are explicitly present + +### 3. Extend dashboard bootstrap models +- expose recent quote outcome rows with terminal evidence where available +- expose settled attribution separately from submitted quote terms +- ensure summary metrics count completed outcomes and submission-only rows separately + +### 4. Prepare markout support on the same linkage path +- if implemented in this turn, compute later reference-price markout from the linked quote or completion timestamp +- store it in a way that cannot be confused with realized settlement contribution + +## UI changes + +### Strategy page +- extend lifecycle rows so submitted paths can become `Awaiting outcome`, `Not filled`, or `Completed` +- show linked outcome reason and settlement attribution state +- keep quote, decision, and command trace ids visible + +### Funds page +- separate: + - recent submission terms + - recent settled attribution + - completed outcome ledger +- if no settled attribution exists yet for a completed row, say that plainly + +### Summary language +- introduce distinct labels for: + - recent submissions + - recent completed outcomes + - recent settled attributions +- never reuse one metric for all three concepts + +## Edge cases +- submitted row with no later evidence: + render as `Submitted` or `Awaiting outcome` +- explicit expiry or non-fill evidence: + render as `Not filled` +- completed outcome with no attributable inventory delta yet: + render completion truthfully, but mark attribution as missing +- inventory movement with no unambiguous quote match: + keep unattributed and do not silently assign +- multiple near-simultaneous quotes in the same direction: + require explicit or recorded heuristic linkage before claiming settlement + +## Concrete implementation order + +### Phase 1. Discover and define outcome sources +- inspect current relay, executor, and inventory evidence +- document what fields can carry downstream outcome and settlement linkage +- define exact versus heuristic attribution rules + +### Phase 2. Implement durable outcome and attribution records +- add storage or derived records for linked outcomes +- add storage or derived records for settlement attribution +- preserve raw references and timestamps + +### Phase 3. Update dashboard aggregation +- join recent lifecycle rows to outcome and attribution records +- split summary metrics and ledgers by evidence strength +- keep submission-only rows clearly non-terminal + +### Phase 4. Validate on live data +- prove at least one recent row remains submission-only +- prove blocked and rejected rows remain distinct +- prove a completed or non-fill row appears only with durable linked evidence +- prove settled attribution is shown only when actual linked movement exists + +## Test plan +- unit tests for outcome linkage: + - submitted with no outcome + - submitted with non-fill outcome + - submitted with completed outcome +- unit tests for attribution: + - completed with linked settlement + - completed without settlement yet + - ambiguous movement remains unattributed +- negative semantic tests: + - submission-only rows must not render completion + - markout must not be labeled realized + - quote terms must not be labeled settled asset delta +- dashboard bootstrap tests for: + - separated summary metrics + - completed rows carrying explicit outcome evidence + - unattributed rows staying plainly unattributed + +## Validation checklist against the proof +- recent rows separate submitted, awaiting, not-filled, and completed where evidence exists +- completed rows show explicit outcome linkage +- settled attribution is visible and clearly sourced +- submission-only rows still do not claim completion or realized movement +- remaining uncertainty is named plainly + +## Failure modes to plan for +- linking the wrong inventory movement to a quote +- mistaking inventory rebalance or treasury movement for trade settlement +- rendering completed from incomplete venue evidence +- blending markout and realized attribution into one metric +- introducing hidden heuristics without storing them + +## Truth review checklist for this turn +For every outcome or attribution field: +- what exact durable event or snapshot backs it +- how is the quote linked to it +- is the linkage exact or heuristic +- what wording would overclaim certainty +- what regression test prevents that overclaim from returning diff --git a/archive/implementation/20260410T092923Z-execution-outcome-truth-and-settled-attribution-proof.md b/archive/implementation/20260410T092923Z-execution-outcome-truth-and-settled-attribution-proof.md new file mode 100644 index 0000000..79edb82 --- /dev/null +++ b/archive/implementation/20260410T092923Z-execution-outcome-truth-and-settled-attribution-proof.md @@ -0,0 +1,138 @@ +# Implementation Proof: execution outcome truth and settled attribution + +Status: open +Opened: 2026-04-09 + +## Target outcome +This turn proves that `unrip` can move recent quote rows past submission-only evidence and into durable downstream outcome truth. + +For the live NEAR Intents BTC/EURe system, the operator must be able to answer: +- was the quote merely submitted +- did the venue later complete or not fill it +- what settled inventory delta, if any, was actually observed afterward +- what part of the post-trade change is still inferred versus durably linked + +## Why this is a meaningful architecture test +The previous turn fixed an overclaiming dashboard, but it also exposed the next hard truth gap: +- `submitted` is now shown truthfully as non-terminal evidence +- downstream completion and non-fill states are still mostly absent from durable repo-owned data +- recent asset-term tables still describe submitted quote terms, not settled inventory truth +- realized attribution is still fake because quote response success is not the same thing as completed asset movement + +That means the system is now honest about the gap, but the gap still exists. This turn is where the shared history path must become more real again. + +## Hypothesis +`unrip` becomes materially more trustworthy if it durably links: +- quote +- strategy decision +- execute command +- executor submission result +- downstream venue or relay outcome where available +- later settled inventory deltas attributable to that quote + +The turn passes only if the operator can distinguish submission from later outcome and can inspect a recent completed path with explicit settled attribution instead of implied completion. + +## Scope +- [I017] Per-trade realized attribution: link each successful trade to actual settled inventory deltas and attributable costs so the system can report realized net contribution per trade instead of only expected edge. +- [I018] Quote-to-outcome and markout analytics: link quote, response, decision, execution result, and settlement, then store later reference-price markouts to measure adverse selection and quote quality. +- Focus on the active NEAR Intents BTC/EURe venue and the repo-owned path already in production. +- Cover recent rows first; historical backfill is secondary unless required to prove the live path. + +## Assumptions +- The venue or relay emits enough downstream identifiers or status surfaces to link at least some submitted quotes to later terminal outcomes. +- Inventory snapshots and durable history can support quote-to-settlement attribution for the active pair, even if the first version uses a narrow matching heuristic. +- Some rows will still remain unattributed or partially inferred; the UI and stored records must say that plainly. +- This turn should prioritize truthful linkage and settlement evidence over broad analytics polish. + +## Turn-shaping rules +- `submitted` remains non-terminal evidence. +- `completed`, `not filled`, `settled`, `realized`, and `asset delta` are forbidden unless backed by a durable linked record representing that fact. +- If settlement attribution is heuristic rather than exact, the stored attribution record and operator surface must say so explicitly. +- Do not build a broad analytics suite before the quote-to-outcome path is durably linked. +- Prefer one repo-owned outcome and attribution model reused by storage, dashboard, and later analytics. + +## Non-goals +- No new venue integration. +- No generalized PnL accounting for all treasury cashflows. +- No broad historical backfill project unless needed to prove current-path linkage. +- No strategy changes beyond what is required to preserve truthful lifecycle and attribution semantics. + +## Required operator behavior + +### Outcome truth +For a recent submitted quote, the dashboard must be able to render one of: +- `Submitted` +- `Awaiting outcome` +- `Not filled` +- `Completed` + +The label must be driven by the strongest durable evidence currently stored. + +### Settlement truth +For a recent completed quote, the operator must be able to inspect: +- quote id +- decision id +- command id +- executor result id or submission timestamp +- linked terminal outcome evidence +- linked settled asset delta or explicitly missing settled delta + +### Attribution truth +If the system reports realized contribution, it must be derived from: +- linked settled asset movement +- explicit attributable costs where available + +If costs or full settlement are missing, the system must not claim net realized truth. + +### Markout truth +If markout is stored for completed or submitted rows, it must: +- be clearly labeled as later reference-price comparison +- remain separate from realized settlement attribution + +## Semantic invariants +The implementation and tests must enforce at least: +- `submitted != completed` +- `completed` requires linked terminal outcome evidence +- settled asset delta requires linked settlement evidence, not quote terms +- markout is not realized PnL +- unattributed inventory movement must not be silently assigned to a quote + +## Definition of done +- A durable quote outcome link exists from submission to later outcome where available. +- The repo stores an explicit per-quote outcome or attribution record for the active path. +- The dashboard can show at least one recent path as `Completed` only when durable linked evidence supports it. +- The dashboard can show non-fill or still-awaiting paths truthfully where that evidence exists. +- Recent settled asset delta or explicit lack of attribution is visible per completed row. +- Submission-term tables and summaries do not overclaim settled truth. +- Regression tests cover the negative semantic boundaries above. + +## Validation evidence required +- direct evidence from deployed dashboard or bootstrap payload that recent rows separate `Submitted`, `Blocked`, `Rejected`, `Not filled`, and `Completed` when the evidence exists +- direct evidence that a completed row shows linked settled attribution rather than quote terms alone +- direct evidence that a submission-only row still does not claim completion or realized asset movement +- automated test evidence for quote-to-outcome linkage +- automated test evidence for settlement attribution boundaries + +## Failure conditions +- the system still cannot represent downstream terminal outcome beyond submission +- any UI or backend surface claims completion from submission-only evidence +- settled asset delta is still derived from quoted terms rather than linked settlement evidence +- markout or later reference comparison is presented as realized PnL +- outcome attribution silently guesses across ambiguous rows without recording uncertainty + +## Current real before this turn +- quote, decision, command, and execution submission result are durable +- the dashboard now renders those stages truthfully +- submission counts and recent submission terms are constrained to submission evidence + +## Deliberately not built by this proof +- full treasury fee ledger +- generalized tax or accounting treatment +- multi-venue settlement harmonization + +## Prevention requirements for this proof +- For every new `Completed`, `Not filled`, or realized attribution label: + - what exact durable record backs it + - what linkage key or heuristic connects it to the quote + - what uncertainty remains + - what regression test prevents future overclaiming