SATIK DEVELOPER DOCS · V1 BETA

Understand what changed in an address.

Corrections, enrichments and confirmation evidence explain the decision.

Corrections versus enrichments

corrections contains meaningful differences from locally parsed values; identical values and case/whitespace-only differences are excluded. enrichments contains added details, including a provider-inferred state that Satik had already derived locally. Neither array alone determines whether an address is safe: read verdict, recommended_action, flags and rule_trace.

A confirmed state can be harmless

For Dak Bhawan, Sansad Marg, New Delhi 110001, the provider can confirm the building and add the state Delhi. If the address is complete, validation is PREMISE or SUB_PREMISE, all returned details are confirmed, there are no missing/unresolved/unexpected details or replacements, and no other risk rule applies, state/country enrichment alone does not force REVIEW. Inferred city, postal code, street, building and unit are not covered by this exception. Google ACCEPT does not override Satik checks or delivery-history risk.

Read the new reporting fields

This is a partial illustrative response, assuming the confirmed evidence described above. The state addition is an enrichment, not a Delhi-to-Delhi correction. Added fields may be absent from older logs, saved idempotency responses and demo fixtures.

{
  "verdict": "SHIP",
  "recommended_action": "SHIP_AS_IS",
  "flags": [
    "no_history"
  ],
  "address": {
    "corrections": [],
    "enrichments": [
      {
        "field": "state",
        "value": "Delhi",
        "source": "google",
        "confirmation_level": "CONFIRMED"
      }
    ],
    "component_provenance": {
      "state": {
        "source": "google",
        "parsed_source": "satik_derived",
        "input_value": null,
        "parsed_value": "Delhi",
        "provider_value": "Delhi",
        "confirmation_level": "CONFIRMED",
        "inferred": true,
        "replaced": false
      }
    }
  }
}

Provenance explains where a value came from

component_provenance records the locally parsed source and value, plus provider value and confirmation when available. source identifies the origin of the selected output value; parsed_source preserves its earlier origin. customer_input means the parser established input evidence, satik_derived means a local derivation, google means a confirmed provider value was selected, and unknown means input provenance was not established. input_value is a parsed representation, not necessarily the exact original spelling. An absent/unknown input is not a claim that the customer omitted the detail.

Uncertain or replaced details still require attention

A flat or street number appearing in the provider output is not enough: it must be confirmed. Unconfirmed/missing/unresolved details trigger REVIEW / MANUAL_REVIEW under rule 4a unless a stronger earlier rule applies. Replaced components trigger confirmation under rule 4b; a replaced postal code retains rule 4. A street-level result cannot become SHIP through the state/country exception.

Current evidence, current history

The rules run once with current request flags and delivery history. Compatible evidence-cache hits rebuild the response rather than replaying an old verdict; history risk may rise or fall. During the staged rollout, legacy final-response cache entries are bypassed and eligible requests may perform a fresh check at the normal 1-unit rate. Evidence caching restores the 0.1-unit hit path after its migration is enabled. Historical logs are unchanged. Completed idempotency retries still return the original saved operation response.