# Validate a Third-Party Identity Payload A third-party service returns a JSON payload with a fixed documented structure. The first subject contains a `VerificationAnalysis` record with these fields: `FirstNameVerification`, `LastNameVerification`, `DateOfBirthVerification`, and `SsnVerification`. Each must equal `"match"` for the subject to pass. The subject also contains zero or more add-on products. Each add-on may contain an `IdManagerVerification.Message` array whose objects have a `Code`. The caller supplies a set of disqualifying error codes. A subject passes only when all four identity checks match and none of the returned message codes is in that set. ### Clarifying Questions to Ask - Is the first subject and first verification analysis the authoritative record, or must several records be combined? - Should a missing field be treated as a failure or as an invalid payload? - Should unknown message codes be ignored but retained for diagnostics? - May personally identifying values appear in logs or returned error messages? ### Part 1: Return a Boolean Decision Design a function that accepts a decoded JSON object and the error-code set, then returns whether the subject passes. The documented object shape is stable, so do not perform an unconstrained recursive search for similarly named keys. #### What This Part Should Cover - Direct navigation of the documented schema - Safe defaults for missing arrays, objects, and fields - Correct all-four-check and no-blocked-code logic - Linear work in the number of returned messages ### Part 2: Return Useful Failure Reasons Extend the result so callers can distinguish failed identity checks, blocked error codes, and malformed or incomplete structure without exposing sensitive payload contents. #### What This Part Should Cover - A structured result rather than fragile prose - Stable reason codes and deterministic ordering - Collection of all relevant failures rather than only the first - Redaction and observability boundaries ### Part 3: Handle Corrupted or Unparseable JSON Explain how the boundary that receives raw text should handle syntax errors, wrong JSON types, truncated responses, and schema drift. #### What This Part Should Cover - Separation of parsing, schema validation, and business rules - Fail-closed behavior for ambiguous identity decisions - Actionable internal diagnostics without leaking personal data - Tests for malformed and partially valid payloads ### What a Strong Answer Covers A strong answer states the authoritative path, uses explicit validation instead of a recursive key hunt, treats missing decision inputs conservatively, returns typed reasons, and tests both happy paths and hostile or incomplete payloads. ### Follow-up Questions - How would you version the parser when the provider adds a new schema? - Which metrics would reveal a provider-side format regression? - How would you replay quarantined payloads after deploying a parser fix?