Skip to content

Address or Endpoint Validation

Pre-dispatch verification protocol — instantiates Endpoint Fan-Out Fulfillment

Checks each endpoint's identity, location, eligibility, connectivity, and access prerequisites before anything is dispatched, so effort is only spent on endpoints that can actually be served.

A failed attempt at the endpoint is expensive — a wasted truck roll, a bounced payment, a crew standing in a driveway that isn't ready. Address or Endpoint Validation moves that failure detection from the costly field to the cheap desk: before anything crosses from consolidated trunk flow into the fan-out, it verifies the prerequisites the endpoint must meet — a real, reachable location; confirmed identity and authorization; eligibility; connectivity; the access details the work needs. Its defining move is being a gate on the boundary, run before commitment: only endpoints that clear every prerequisite are released into the dispatch queue; the rest are held with a specific, actionable reason. This is distinct from recovering a failure after it happens — validation exists to prevent the attempt that would fail.

Example

A residential solar installer schedules crews to fit rooftop panels. A truck roll costs a full day, so a crew sent to a site that isn't ready is pure waste. Address or Endpoint Validation runs at the desk before dispatch: the service address must geocode to an actual roof (not a PO box), the utility interconnection permit must be approved, a panel photo must show adequate electrical capacity, the homeowner's identity and authorization must match the account, and the access notes — gate code, dog, ladder point — must be present. Only sites clearing every prerequisite cross the boundary into the dispatch queue; the rest are held with a precise reason like "permit pending" rather than dispatched into failure. The result: crews arrive at sites that can actually be installed, and the failed-roll rate falls because the failure was caught at the desk, not the driveway.

How it works

The distinguishing idea is a verified boundary crossing, not a generic checklist:

  • Gate the trunk-to-endpoint boundary. Nothing enters the fan-out until its prerequisites are checked; the boundary becomes an enforced checkpoint rather than an open seam anything flows through.
  • Verify against real prerequisites. Each check tests something dispatch actually depends on — location resolvable, identity confirmed, eligibility met, access possible — so a pass genuinely predicts a servable endpoint.
  • Hold with a reason, don't drop. A failed check yields a specific, fixable cause ("address unresolved," "permit pending"), so the endpoint can be corrected or routed onward instead of silently lost.

Tuning parameters

  • Check stringency — how many prerequisites must clear before dispatch. Stricter cuts wasted attempts but delays or blocks marginal cases that might have worked.
  • Data freshness — how recently each input must have been verified. Fresher is more accurate but costs re-verification effort.
  • Automation vs. human review — which checks run automatically and which need a person. Automation scales; human review catches the subtle mismatches automation misses.
  • Fail-open vs. fail-closed — whether an unverifiable prerequisite blocks dispatch (safe, but strands cases with bad data) or passes it through flagged (more coverage, more failures).
  • Boundary placement — how far upstream the gate sits; earlier catches problems sooner but on less-complete information.

When it helps, and when it misleads

Its strength is that it relocates failure detection from the expensive field to the cheap desk, concentrating effort on endpoints that can actually be served, and it is the natural chokepoint for identity and safety checks. Its failure mode is that over-strict validation becomes an access barrier: real endpoints with imperfect records get turned away — a false negative that reads as "ineligible" but is really "our data is stale" — and the burden of fixing the data lands on the endpoint least equipped to carry it. The classic misuse is validation as covert rationing: quietly tightening prerequisites to suppress demand and flatter completion rates by excluding hard cases rather than serving them. The discipline is to measure who gets blocked and why, route fixable-data cases onward to outreach instead of dropping them, and keep identity and safety checks proportionate to real risk.[1]

How it implements the components

Address or Endpoint Validation realizes the pre-dispatch gate — the components a verification protocol fills, not the completion, outreach, or recovery machinery:

  • trunk_to_endpoint_boundary — validation is the gate that governs the boundary: nothing crosses from trunk flow into the endpoint fan-out until its prerequisites are verified, making the boundary an enforced checkpoint.
  • endpoint_privacy_and_safety_guardrail — verifying identity, authorization, and access prerequisites is the privacy-and-safety gate, stopping unsafe or unauthorized dispatch before it can happen.

It does not remove blockers so a stuck endpoint can complete (endpoint_success_contract, coverage_floor) — that is Targeted Outreach Campaign; nor does it hold nonstandard cases for judgment (local_fit_exception_process), which is Exception Queue, though validation failures are a main source of its entries.

References

[1] Know Your Customer (KYC) rules require verifying a customer's identity before providing a service; the well-documented failure mode — legitimate people excluded because they lack standard documentation — is the same false-negative risk any pre-dispatch validation must guard against, which is why reviewing who gets blocked matters as much as running the check. ↩