Is the capture store a stable seam for post-mortem consumers? (+ versioned index offer)

[iceteaSA]

Consumer question: is the capture store a stable integration seam, or an implementation detail?

Context

We run post-mortem tooling over finished agent sessions (terminal state, bounded error evidence, final output) and lifecycle detection over live ones. The interceptor's captures — session-scoped request/response/meta trios with truthful byte accounting and redaction — are the evidence layer those tools need when a session dies weirdly: the last provider exchange before a truncation or hang answers questions no harness-side row can.

Today

Our tools correlate harness DB rows only; capture files are a manual dig when something is strange enough to warrant it. Programmatic correlation (session id → its captures → the final anomalous exchange) would close the loop. Building that on the current store means depending on file layout and naming as an API.

Asks

1. Is the capture layout (paths, naming, meta schema) intended as a stable contract for external consumers, or internal with no compatibility promise?
2. If internal: would you take a small versioned index/manifest (per-session capture inventory with phase/anomaly markers, queryable without walking the tree) as a contribution? That is the entire seam a post-mortem consumer needs — we'd build our drill-down against it and leave the store format free to change underneath.
3. If there's an anomaly-phase taxonomy already (the README mentions anomaly phases), is it stable enough to reference from external tooling, or still moving?