# Implementation Parity Report Format

All implementation parity check agents return results in this JSON structure.

## Schema

```json
{
  "check_type": "<one of: resolver-doc-code-parity, screen-doc-code-parity, page-screen-doc-parity, module-wiring-parity>",
  "app": "<app-name>",
  "gaps": [
    {
      "source": "<source doc or code path>",
      "target": "<target code or doc path, or 'missing'>",
      "check": "<check_id from the agent's parity checks table>",
      "status": "pass | fail | skip",
      "evidence": "<file:line supporting the verdict — required for pass and fail>",
      "detail": "<human-readable description of the finding>"
    }
  ],
  "inconsistencies": [
    {
      "type": "<inconsistency type, e.g. type_mismatch, missing_field>",
      "location": "<source vs target description>",
      "detail": "<human-readable description>"
    }
  ],
  "summary": {
    "total_checks": 0,
    "passed": 0,
    "failed": 0,
    "skipped": 0,
    "claims_total": 0
  }
}
```

## Field Reference

### gaps[]

One entry per parity check performed. `status` is:

- `pass`: doc and code are consistent — requires `evidence` (`file:line`)
- `fail`: gap or mismatch found — requires `evidence`, or detail "no evidence found"
- `skip`: target code/doc missing or empty, check could not run

A `pass` without `evidence` is invalid and must be treated as `fail` by the aggregator.

### inconsistencies[]

Cross-cutting issues that don't fit a single gap entry (e.g., type mismatches, naming violations, missing patterns).

### summary

Aggregate counts. `total_checks = passed + failed + skipped`.

`claims_total` is the omission detector: it is fixed while enumerating doc claims (before reading any code), so the aggregator can catch silently skipped claims — if `total_checks < claims_total`, the agent verified fewer claims than it enumerated. Evidence catches sloppy passes; `claims_total` catches silent omission.