# Detection Schema Validation + Model-Version + Health

**Task**: AZ-661_detection_client_schema_and_health
**Name**: Response schema validation + model_version tracking + Tier-1 health degradation signal
**Description**: Validate every `DetectionBatch` response against the schema version the client was built against. Surface a hard error on schema mismatch (never silent downcast). Track `model_version`; on change, surface to `scan_controller` so per-class thresholds can be reloaded. Track sliding-window latency; on `latency_p99 > 100 ms` flip health → yellow so `scan_controller` can degrade to alternate-frame inference.
**Complexity**: 2 points
**Dependencies**: AZ-640_initial_structure, AZ-660_detection_client_grpc_stream
**Component**: detection_client
**Tracker**: AZ-661
**Epic**: AZ-628

## Problem

Schema drift between `../detections` and autopilot must be caught loudly — not silently downcast. The model version can change at runtime (model swap); when it does, the per-class confidence thresholds may need to be reloaded by `scan_controller`. The Tier-1 latency target (≤100 ms) is mostly owned by `../detections` but autopilot must observe drift and surface health degradation so the scan controller can take action.

## Outcome

- Every response is validated against the bundled schema; on mismatch, returns a hard error to the output channel and health → red.
- `last_model_version` is tracked; on change, a `ModelVersionChanged(new_version)` event is emitted on the output channel.
- A sliding-window latency tracker (e.g. last 1 min) emits a `Tier1Degraded { reason: HighLatency }` event when `latency_p99 > 100 ms`.

## Scope

### Included
- Schema validation hook on every response.
- `model_version` tracker.
- Sliding-window latency tracker + degradation signal.

### Excluded
- The reaction to `Tier1Degraded` (lives in `scan_controller`).
- The schema definition itself (lives in the contract).

## Acceptance Criteria

**AC-1: Schema mismatch surfaces as hard error**
Given the fixture server returns a `DetectionBatch` with an unknown field type
When the client validates the response
Then a hard error is emitted on the output channel and `errors_by_kind{kind="schema_mismatch"}` increments by 1.

**AC-2: Model version change is signalled**
Given the server reports `model_version = "v1.2"` on initial stream open
When a subsequent response reports `model_version = "v1.3"`
Then exactly one `ModelVersionChanged("v1.3")` event is emitted.

**AC-3: Latency degradation signal**
Given the server's response latency rises to 150 ms p99 over a 1-min window
When the latency tracker evaluates
Then `Tier1Degraded { reason: HighLatency }` is emitted exactly once until latency falls back below 100 ms.

## Non-Functional Requirements

**Performance**
- Validation overhead: ≤1 ms per response.

**Reliability**
- Schema mismatches never silent.

## Runtime Completeness

- **Named capability**: response schema validation + model-version awareness + latency-degradation signal.
- **Production code that must exist**: real schema validation; real model-version tracker; real percentile tracker.
- **Unacceptable substitutes**: silently downcasting an unknown response shape is unacceptable.
