Context

Discussion #10137 (MX — Model Experience) explicitly reserves its next actionable move: "Proposed instrumentation (separate ticket once this Discussion graduates)." This is that ticket. The four graduation criteria named in #10137 §"Graduation criteria" are measurable but currently unmeasured — instrumenting them gives us empirical data on whether the MX loop is actually working, and produces signal the Golden Path can consume to route future work.

This ticket is deliberately scoped narrowly. The instrumentation itself is the deliverable; deciding what to do with the data when it's collected is follow-up work once the measurement substrate exists.

The Problem

Four MX effectiveness axes named in #10137 with no current measurement primitive:

1. Friction-tickets-per-session ratio — how many tickets does a session file to improve the substrate vs. execute scoped work? Non-zero rate = evidence MX is functioning. Zero rate = either perfect substrate (unlikely) or friction suppression (more likely → flag).
2. Golden Path hit rate — of tickets marked top-priority by get_context_frontier this cycle, how many were actually picked up + closed in the next cycle? Low = ranking not trusted; high = routing is working.
3. Cross-session thread continuity metric — of threads surfaced via query_raw_memories in session N, how many are resumed/advanced in session N+1 vs. re-derived from scratch? High = memory is load-bearing.
4. Cross-model convergence — when different harnesses (Claude Code, Antigravity, Gemini CLI) work on the same epic, do they converge on compatible architectural decisions or diverge? Convergence = shared substrate works; divergence = memory/concept substrate has gaps.

Without instrumentation, MX graduation is a narrative claim. With instrumentation, it's a dashboard.

The Architectural Reality

Where each signal lives:

• Friction-tickets: ai/mcp/server/github-workflow/ — issue metadata already captured in resources/content/issues/. Friction tickets are a subset with a recognizable signature (labels: ai + tags like [KB_GAP] / [TOOLING_GAP] / [RETROSPECTIVE] in body, typically filed by agent identities @neo-opus-ada / @neo-gemini-pro). Ratio = friction-tickets-filed / agent-identity-session-count over a rolling window.
• Golden Path hit rate: get_context_frontier returns ranked priorities; comparing T0 top-N list vs T1 closed tickets gives the hit rate. Requires capturing frontier snapshots over time (not currently done).
• Cross-session thread continuity: Memory Core's query_raw_memories usage + [ADDRESSED]/[DEFERRED]/[REJECTED_WITH_RATIONALE] tag parsing gives resumption evidence. Retrospective daemon already ingests these tags — extraction endpoint needed.
• Cross-model convergence: cross-family PR review events (mandated by #10208/PR #10211) are the clearest convergence signal — Approved vs Request Changes cycles across model boundaries are graph-queryable via Memory Core + github-workflow sync.

None of the four currently has a surfacing endpoint. All four are compositions of data that already exists.

The Fix

Three surfacing mechanisms, landing together:

1. New MCP tool get_mx_metrics in ai/mcp/server/memory-core/ — returns a structured snapshot:

      {
     frictionTicketsRatio:       { window: '7d', ratio: 0.00-1.00, sampleSize: N },
     goldenPathHitRate:          { window: '7d', hits: X, misses: Y, rate: 0.00-1.00 },
     crossSessionContinuityRate: { window: '7d', resumed: X, rederived: Y, rate: 0.00-1.00 },
     crossModelConvergenceRate:  { window: '7d', approvedCrossFamily: X, requestChangesCrossFamily: Y, rate: 0.00-1.00 }
   }

2. Frontier snapshot capture — on each get_context_frontier invocation, persist the top-N list to Memory Core with a timestamp. Enables the Golden Path hit-rate comparison (requires a new memory-core node type FrontierSnapshot or similar). Without this, hit-rate measurement is impossible retroactively.
3. Dashboard ingestion — a minimal ai/scripts/mxMetrics.mjs CLI script that invokes the MCP tool + writes a JSON snapshot to resources/content/mx-metrics/<iso-date>.json. Later a learn/agentos/MX.md guide can render a chart from the snapshot history. The script is the minimum viable instrumentation; the guide is a follow-up.

Acceptance Criteria

• get_mx_metrics MCP tool implemented, schema matching the shape above
• FrontierSnapshot node type defined; get_context_frontier persists a snapshot on each invocation (idempotent — dedupe by timestamp + caller-identity hash)
• Playwright unit test covers each of the four metrics' calculation logic against seeded fixtures (e.g., seed 10 sessions with N friction tickets, assert ratio matches)
• ai/scripts/mxMetrics.mjs CLI: invokable, writes snapshot JSON to resources/content/mx-metrics/
• Guide stub at learn/agentos/MX-Instrumentation.md documenting the metric definitions + how to read the snapshots (can be extended later with chart rendering)
• Registered in learn/tree.json
• Post-merge validation: run the script in this session, observe a baseline snapshot. Even a single data point has value for comparing against future snapshots.

Out of Scope

• Automated alerting when metrics degrade (future ticket once we have a baseline + a sense of healthy ranges)
• Dashboard UI beyond the JSON snapshot + markdown guide (eventually a Neo app in the harness per #10119, but not required for the measurement itself)
• Deciding thresholds for "MX is working" vs "MX is failing" — the data needs to exist before the thresholds mean anything
• Retroactive historical snapshots — Golden Path hit rate can only be measured forward from the first snapshot capture

Avoided Traps

• "Build the dashboard first, instrumentation second": rejected. The measurement primitives ARE the deliverable; presentation is follow-up. A dashboard without real data is theater.
• "Pick one metric, ship it, defer the rest": considered and rejected. The four metrics co-define MX — isolated instrumentation of one would be confusing if the others didn't land. Composite landing is cleaner.
• "Make it a sub-agent workflow rather than a direct MCP tool": rejected for this phase. Direct MCP tool gives deterministic surface. A future sub-agent could synthesize narrative commentary FROM the raw metrics, but the raw metrics must exist first.

Related

• Parent Discussion (source of the graduation criteria): #10137 (MX — Model Experience, 2026-04-20)
• Sibling: #10119 (Neo Agent Harness) — the harness would eventually render these metrics natively, post-v12.2
• Concept Ontology: #10030 (semantic gap detection) — feeds the friction-ticket classification signal
• Multi-Tenant Memory Core: #9999 — once landed, these metrics become per-tenant, which changes the collection shape

Origin Session ID: 24aa1fa1-9a22-498e-97f2-760c12e5a79d

Handoff Retrieval Hints

• query_raw_memories(query="MX graduation criteria instrumentation measurement")
• query_raw_memories(query="Golden Path hit rate friction tickets empirical")
• query_summaries(query="MX substrate effectiveness instrumentation")