## TL;DR
Zscaler renamed the posture field and the agent's parser returned unknown. Version the expected schema, map old and new field names, and treat persistent unknown as a failure to investigate, not a pass.

## The query
```text
agent's zscaler device-posture check returned "unknown": api field rename
```

## Use this when
- posture checks return unknown after a Zscaler update
- the agent cannot read posture data
- field names changed in the API

## Not for
- devices genuinely failing posture
- Zscaler policy configuration
- client enrollment problems

## Steps
1. Diff the old and new API responses to find the renamed field. Expected output: the rename is documented.
2. Update the parser to read both the old and new field names. Expected output: both API versions parse.
3. Version-tag the schema expectation and select by API version. Expected output: the right mapping applies automatically.
4. Treat unknown as investigate, never as compliant. Expected output: unknowns route to a human queue.
5. Alert on unknown-rate spikes to catch the next rename early. Expected output: future renames surface immediately.

## Applies to
Zscaler API, device posture checks, agent integrations.

## Variant phrasings
### Field renamed in a minor API update
Pin to a documented API version and test on upgrade.

### Multiple renamed fields at once
Regenerate the mapping from the current API schema, not from memory.

## Why it happens
SaaS APIs rename fields without ceremony. Parsers written against one shape return unknown on the next, and unknown must never mean compliant.

## Edge cases
- Unknown posture should block access or escalate, per your risk posture.
- Keep sample API responses per version in the test suite.
- Subscribe to Zscaler API changelogs for advance warning.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xaKQU-OWlRIpFqSQtR9tkw