Feature Review Execution Telemetry

Feature: Review Execution Telemetry

A Feature-Pages entry. This page explains the capability; it never redefines it — see Feature-Pages for the canonical/Wiki boundary statement that applies to every page in this pattern.

What it does

Defines a small, machine-readable, purely observational record of what one review run actually inspected and executed: which review stages completed, which files were read, how many symbols and repository- intelligence expansions were performed, which runtime validations ran (and how), whether a large PR was partitioned, and best-effort stage timing. Each metric has an explicit unavailable state, so "not tracked" is never confused with "zero".

Why it exists

Nothing in a finished review records whether it looked at three files or three hundred, whether expansion ever fired, or whether a runtime validation ran or was skipped. This design defines a record that could answer those descriptive questions.

When it applies

Not a review option and not something a reviewer turns on. It is a repository-development design record: a metric catalog, a JSON Schema and a test-only reference model. It is not packaged into either Skill archive and is not wired into a packaged Skill runbook or policy. No review currently emits a telemetry record: assembling one from a live review is not implemented, and a review runs exactly as it would without this design. Read the rest of this page as a description of the designed record, not of review output you will see.

How it works (the designed record)

Telemetry would be assembled from observations a review already makes; it never feeds back into the review that produced them.

• Never decision-affecting. It has no effect on findings, severity, confidence, suppression or the decision, and is never attached to a finding. A test pins this: the same findings yield the same decision with and without a telemetry record.
• Not the same as coverage. stages_completed is descriptive only. The decision-affecting coverage concept (which can produce REVIEW INCOMPLETE) is owned separately by the stopping-criteria policy.
• Deliberately not collected: token usage or cost, prompt/response text, finding counts or the decision, reviewer/author identity or other PII, repository names, benchmark match outcomes, and cross-review trend data.

Three different kinds of signal

Signal	Answers	Can it change a live review?
Review-time evidence (code, context, runtime validation)	Is this finding supported?	Yes — it is what findings are reasoned from
Observational telemetry (this page)	What did the review touch?	Never
Benchmark ground truth (Benchmark-Testing)	Was the reviewer right against known cases?	Never edits a live review; it evaluates the Skill against a fixed corpus

Telemetry ≠ ground truth. A review can have complete telemetry and still be wrong, and a benchmark case can be evaluated with no telemetry at all. Neither substitutes for the other.

Product-layer boundary

Historical analytics, exports, and repository-scoped learning are an explicit product-layer boundary outside this Skill (not planned for it): they need persisted, cross-invocation history, which an invocation-scoped Skill does not have. The decision is recorded in the architecture model's "Product-layer boundary decision" addendum (linked below).

Related features

• Benchmark-Testing — the ground-truth side of the boundary above.
• Feature-Runtime-Validation-Evidence — runtime validations are one of the things telemetry records.

Canonical references

• docs/review-telemetry/review-execution-telemetry-model.md — metric catalog, guarantee, unavailable-state rules.
• docs/review-telemetry/review-execution-telemetry.schema.json — the exact record shape.
• docs/benchmark-measurement-architecture/ — where telemetry sits among the measurement layers, and the product-layer boundary decision.