SATIK DEVELOPER DOCS · V1 BETA

Trace the decision.

Understand which Satik rules produced a verification verdict.

How a trace is generated

Satik maintains a fixed set of decision rules. Google supplies validation signals; Satik applies the rules and generates rule_trace for each result. Each entry contains a rule identifier and a human-readable reason. This is a record of matched decision rules, not every check performed. Flags describe signals, verdict gives the assessment, and recommended_action tells you the next step.

Address rules

The address rules run in the order below. The first matching condition determines the initial verdict and action. Rule 8 is the successful default when none of the preceding conditions matches. Conditions below describe current implementation behavior, not a delivery guarantee.

Address rule identifiers, conditions, and results
Rule	Condition → verdict / recommended action
No usable location`1`	No usable geocode or validation granularity → VERIFY_FIRST / REQUEST_FULL_ADDRESS.
Incomplete address`2`	Validation granularity is OTHER, or the provider does not mark the address complete → VERIFY_FIRST / CALL_CUSTOMER.
Suspicious locality or pincode`3`	The provider marks locality or postal code as unconfirmed and suspicious → VERIFY_FIRST / CONFIRM_PINCODE.
Pincode replaced`4`	The provider replaced the postal code → REVIEW / CONFIRM_PINCODE.
Unresolved address evidence`4a`	Unconfirmed, missing, unexpected or unresolved components, a supplied unit absent from provider confirmation, or conflicting parsed input → REVIEW / MANUAL_REVIEW. When the pincode is unconfirmed or reported missing, the flag is unconfirmed_pincode and the trace identifies the pincode issue; otherwise unconfirmed_components is used. This earlier rule takes priority over later missing-unit/landmark checks.
Other replaced components`4b`	The provider replaced address details other than a postal code already handled by rule 4 → REVIEW / CONFIRM_CORRECTIONS.
Missing unit or building`5`	Neither a confirmed unit/street number nor a confirmed named building is available → REVIEW / REQUEST_UNIT_NUMBER.
Landmark-dependent premise`6`	The premise is unconfirmed but plausible and the input relies on a landmark → REVIEW / REQUEST_LANDMARK.
Inferred details`7`	Inferred details beyond the narrow confirmed state/country exception → REVIEW / CONFIRM_CORRECTIONS. The exception requires complete building-level validation, no replacements, and no unconfirmed, missing, unexpected or unresolved details. Inferred city/pincode/unit/street/building details are not exempt.
Building not confirmed`8a`	Validation is below PREMISE/SUB_PREMISE or the provider signal indicates a Plus Code without building-level validation → REVIEW / MANUAL_REVIEW.
Complete building-level validation`8`	None of the preceding address conditions applies → SHIP / SHIP_AS_IS. History rules may still change this decision.

Delivery-history rules

History is checked after the address decision and can add trace entries. RTO means return to origin. These ratios use recorded outcomes; they are not calibrated delivery probabilities. The denominator includes delivered, RTO, customer-refused, and address-issue outcomes, excluding lost and cancelled shipments.

History thresholds and decision changes
Rule	Condition → verdict / recommended action
Elevated area returns`9a`	An otherwise SHIP result has at least 30 DIGIPIN8-area outcomes and an RTO rate of at least 25% → REVIEW / MANUAL_REVIEW.
Elevated unit returns`9b`	A known unit has at least 5 outcomes and an RTO rate of at least 50% → VERIFY_FIRST / CALL_CUSTOMER. This can override the preceding verdict.

Read a trace

Here Rule 7 causes REVIEW because the provider inferred details. Ask the customer to confirm them. The no_history flag is informational and does not create a separate rule-trace entry or cause REVIEW. Reason wording can vary; use verdict and recommended_action to drive your workflow.

{
  "flags": [
    "inferred_components",
    "no_history"
  ],
  "verdict": "REVIEW",
  "recommended_action": "CONFIRM_CORRECTIONS",
  "rule_trace": [
    {
      "rule": "7",
      "reason": "Provider inferred address components"
    }
  ]
}

Cached results

Compatible evidence-cache hits reuse provider evidence, then rebuild the decision and trace once using current request flags and delivery history. They do not call Google again. Legacy final-response cache entries are bypassed during the staged rollout; existing logs and completed idempotency replays preserve their original decisions. Check meta.cache_hit alongside the trace.