Ticket graphs

Every ticket as the root of its provenance graph — goal, patch, approval, runs and (as the ticket-class build lands) mandate, manifestations, guarantees, journey, artifacts and children. Rendered through the <<<TicketGraphList>>> tag.

← all ticket-graphs

REQUESTED#492 peer_system

[deferred] Local trace store: de-duplicate extract, content-address blobs, wire telemetry_iter_mcp

goal

DEFERRED BY DECISION 2026-07-23. Not work to start now -- work to start when the threshold below is crossed. Filed so the measurement is not re-derived later. WHY DEFERRED Measured today: peer_system/logs/ holds ONE trace, 17 MB, against 1.1 TB free. Roughly 60,000 runs from discomfort. Building a content-addressed store now would solve an unmeasurable problem while the rules run (#491) and the menu rewrite are on the critical path. THE MEASUREMENT (keep this; it is the expensive part) One run, one ticket, one engine: 302 records, 18.3 MB, ~60,597 bytes/step. Bytes by field: stack_delta 26%, model_raw 25%, dispatch 24%, extract 24%. Projected at 300-step runs: 25 rules tickets ................ 455 MB 4 engines x 25 (tournament) ..... 1.8 GB + 3 replay forks per run ........ 5.5 GB TRIGGER -- start this work when EITHER holds: (a) peer_system/logs/ exceeds ~20 GB, or (b) the first multi-engine tournament with replay forks is scheduled. THE STORE STAYS LOCAL. Decided on VOLUME, not secrecy: we trace every branch, so growth is superlinear and a replicated droplet store is the wrong home. Supersedes the earlier "telemetry stays local" rationale, which was recorded as a leak concern. Note the droplet `events` table (704k rows) has zero peer_system rows and its newest activity is 2026-07-05 -- that is by design, not breakage. THE THREE MOVES, cheapest first 1. DE-DUPLICATE `extract`. It is 24% of every trace and is very nearly a copy of `dispatch` -- one holds {tool, args}, the other {tool, args, result}. Store a reference when they match. Roughly a quarter of the trace, for a small change in trace.py. 2. CONTENT-ADDRESS repeated blobs. The overnight qwen3 run made 293 tool calls carrying only SEVEN distinct argument digests, 179 of them byte-identical. Store each distinct blob once and reference it. Pathological runs collapse by an order of magnitude -- and those are exactly the runs worth keeping. 3. WIRE telemetry_iter_mcp. It already exists (summary / new_iterator / get_next / peek / reset_iterator / walk_run), described in mcp_tools/MANIFEST.txt as "an ITERATOR over telemetry so an agent pages through instead of dumping". It has a launchd plist and is unwired. Built for exactly this problem; nothing has to be designed. CONSTRAINT: the trace must stay REPLAY-GRADE and full-fidelity. digest_args (landed 2026-07-23) shortens only what re-enters the model's context, never the record. De-duplication and content-addressing must be lossless -- reconstruct_stack and trace_replay --verify must still rebuild byte-identical state, with the tamper negative control still failing.

patch

none

approval

wallet-signed

runs

no runs recorded

mandate (clauses)

not yet recorded — lands with the ticket-class build

manifestations

not yet recorded — lands with the ticket-class build

guarantees

not yet recorded — lands with the ticket-class build

journey (blunders & successes)

not yet recorded — lands with the ticket-class build

artifacts (forge)

not yet recorded — lands with the ticket-class build

source (forge tree)

browse congruency source (forge-parked tree)

children

not yet recorded — lands with the ticket-class build