A per-amendment dashboard on the devnet that measures how the amendment's new transaction types are actually being used, with an AI layer that analyzes the usage and reports what the numbers alone don't show. It exists to answer one question with data: is this primitive ready to activate? Built and operated by the Amendment Manager (role duties 11 and 12); the output feeds the activation readiness call and loops findings back into the spec and docs.
One dashboard deployment per devnet, one view per amendment under test. An amendment is registered with a config entry:
- amendment name and feature bit
- new transaction types
- new ledger entry types
- new fields, flags, and result codes introduced on existing types
Everything below is driven from that config; adding the next amendment is a config change, not a build.
Subscribe to the devnet's validated transaction stream over websocket and filter on the registered transaction types (plus existing types carrying the registered new fields or flags). Store the full transaction and metadata for the retention window; append-only, queryable (JSONL into DuckDB or SQLite is enough, this is a devnet tool, not an indexer). A periodic ledger_data sweep counts the registered ledger entry types for object growth. Devnet data is public by definition; there is nothing to anonymize.
- Volume — transactions per type over time.
- Results — result-code distribution per type: tes vs tec/tem/ter/tel, top failure codes, trend, first-seen dates.
- Actors — unique accounts per type, new vs returning, concentration (is one test script generating everything?).
- Coverage — the spec-surface matrix: every optional field, flag, transaction path, and result code the amendment defines, against whether the devnet has ever exercised it. The gaps are the point: an edge case nobody has hit is untested surface going to mainnet.
- Objects — registered ledger entry types created and deleted over time, net growth.
- Readiness — the summary panel per amendment: coverage percentage, failure trend, distinct integrators, days of activity. These are the numbers behind the readiness call in role duty 6.
A scheduled pass (daily) over the window's transactions, per amendment:
- Flow reconstruction — group transactions by account into sequences and describe the flows developers are actually building with the primitive.
- Misuse detection — patterns that indicate the spec is being misunderstood: repeated tem/tec loops, malformed field usage, retries of transactions that can never succeed, flows the spec did not intend.
- Unexercised surface — the narrative on the coverage gaps: which parts of the spec nobody is touching and a guess at why (undocumented, unclear, or genuinely rare).
Output is a short written report per amendment per week, rendered in the dashboard next to the panels. Each finding is tagged spec-bug, docs-gap, or test-gap and routed to the owning duty (spec duty 1, parity duty 5, or the test plan). The model reads public devnet data only.
- Not a mainnet analytics product and not an indexer; DEX Timeseries covers in-node market analytics.
- No general-purpose transaction explorer features; the explorer exists.
- No per-user tracking beyond what the public ledger already states.
Web dashboard, one deployment per devnet, config registered per amendment entering the pipeline. Retention: the amendment's devnet lifetime. Owner: the Amendment Manager builds it (duty 11) and maintains it (duty 12).