Credentialing is condition 6 of the settlement gate

A settlement gate that will authorize an advance against an OIG-excluded provider is not a billing bug — it is a False Claims Act liability wired directly into the money path. shteg.ai closes that path by making provider legitimacy a condition of the gate itself, not a report that runs beside it. Two commits build this: RB-SCREEN (OIG-LEIE + NPPES screening as condition 6) and RB-CRED (continuous credentialing / PSV as a composite of that same condition).

The False Claims Act exposure

If an OIG-excluded provider or an NPPES-inactive NPI can pass the settlement gate, you have a False Claims Act problem sitting inside your money path. The fix is architectural, not procedural: the settlement gate — the sole authorizer of any advance — became a six-condition conjunction, and condition 6 is provider screening.

GATE_CONDITION_COUNT auto-derives to 6 from the conjunction itself, so nobody can quietly drop a condition without the count and the guardrail check noticing — guardrails-check asserts the 6-condition conjunction including provider_screening. You cannot delete the screen and keep a green build.

CLEAR requires an affirmative clean answer

The screener queries OIG-LEIE (oig.hhs.gov) and CMS NPPES over an SSRF-safe fetch — https-only, fixed-host allowlist. The rule that matters: CLEAR is returned only on an affirmative clean OIG result and an active NPPES result. Any API error, timeout, stale screen, missing NPI, or unregistered screener resolves to INDETERMINATE, which BLOCKS. The module never fabricates CLEAR from a failure to reach the database.

It is a just-in-time live screen backed by a 30-day-TTL persisted cache (the ProviderScreening model), with a rescreenStale() entry point for a scheduled re-screen job.

// condition 6 outcomes — INDETERMINATE is a BLOCK, never a pass
//   EXCLUDED (OIG)         -> BLOCK
//   NPPES inactive         -> BLOCK
//   api error / timeout    -> INDETERMINATE -> BLOCK
//   stale screen           -> BLOCK
//   missing NPI            -> BLOCK
//   no screener registered -> NO_PROVIDER_SCREENER -> BLOCK
//   clean OIG AND active NPPES AND fresh -> CLEAR -> pass

From point-in-time screen to continuous credentialing

RB-SCREEN was the point-in-time OIG/NPPES check. RB-CRED extends condition 6 into full provider eligibility as a composite screener: FSMB license status (ACTIVE / EXPIRING_SOON / EXPIRED), NPDB adverse actions, DEA and SAM.gov sanctions, CAQH sync, payer EDI/EFT enrollment, and an ABMS board map.

The composite registers last, so it wins as the active condition-6 screener. A mid-cycle license lapse or a new sanction now freezes new advances — and unconfigured PSV sources resolve to INDETERMINATE and BLOCK, the deliberate inversion of a legacy module we ported that always returned VERIFIED_PRIMARY_SOURCE.

Freeze THROUGH the gate, never a side-effect

A screening module originates no money side-effect of its own — no auto-lockout, no direct pay-hold. That is Guardrail 10: a lapse routes through the gate, so the block is the gate refusing to authorize — in one place, auditable — rather than a scattering of ad-hoc freezes. We stripped the legacy trust-score, trust-badge, and auto-lockout behaviors on the way in.

Guardrail 5 also holds: NPI goes in, codes/counts/statuses come out; the provider name is used server-side only to drive the OIG name search and is never persisted or surfaced. The AC suite proves it — EXCLUDED blocks, API-error resolves to INDETERMINATE and blocks, a lapsed license blocks, a sanctioned provider blocks, and only CLEAR-and-fresh passes.

Grounded in commits 3a950c0 (RB-SCREEN, G2) and 10db3ec (RB-CRED, G17), and SOVEREIGN_VISION.md Layer 2. No real dollar has moved and no real PHI has flowed; this describes the gate architecture, not production volume.