# 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, 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",
      "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
  }
}
```

## Field Reference

### gaps[]

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

- `pass`: doc and code are consistent
- `fail`: gap or mismatch found
- `skip`: target code/doc missing or empty, check could not run

### 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`.
