Integrity-response fields answer different questions. Collapsing application recognition, device conditions and unevaluated states into one safe label can produce policy errors.
Evaluation approach
First verify that the request belongs to the expected application and context. Then assess device assurance and available additional signals against the policy. The meaning of a missing field depends on the documentation and version.
Application example
A low-risk read and the addition of a payment method can use different thresholds. The user-facing message should provide enough information to resolve the problem.
Limits and considerations
Verdict names do not imply absolute assurance independent of operating-system version.
Connect verdicts to loss scenarios
A missing verdict field may not mean the same thing as a negative result. Check feature enablement, request type and evaluation conditions. Policies that handle these states separately make user blocks easier to investigate.
Converting every result into a clean or dirty label makes future policy changes harder. Record the necessary fields with their meaning, without retaining unnecessary raw data. A versioned rule should explain which combinations are accepted for each operation.
Checks and decisions
- Keep fields distinct
- Model missing results
- Version the policy
Distinguish an absent field from a negative verdict, and observe real distributions before changing enforcement.
Sources
The primary references above provide the technical basis. Example workflows and evaluation suggestions are this publication’s explanations, not independent test results for a particular product.