A Lead Is Not a Verdict

I’ll begin with one ethical and architectural boundary: a score creates an investigative lead, not a payment denial or fraud determination. Humans decide next steps using source evidence and policy. I need the batch deadline, source update semantics, state-program isolation, investigator capacity, labels, appeal/correction path, and cost ratio of missed abuse versus needless investigation.

The core artifact is a signed batch manifest that freezes input partitions, code, rules, features, graphs, models, calibration, and quality policy. Derived scores can be recomputed from it; the source snapshot and investigator decisions remain authoritative.

Actors: state data stewards, program-integrity analysts, investigators, supervisors, model/rule owners, appeals/compliance reviewers, platform operators, and auditors. Version one ingests claims, eligibility, provider, taxonomy, sanctions, and geography; profiles quality; creates point-in-time features; executes four detector families; combines calibrated evidence; groups related hits into leads; enforces queue budgets and conflicts; supports notes, assignment, disposition, and evidence export; then learns only from adjudicated outcomes.

Mock SLOs: publish a 250M-row batch within 36 hours after inputs are complete; 99.5% batch success with deterministic resume; lead-list UI p95 under one second and evidence drill-down p95 under three; exact score replay for seven years. Out of scope: real-time claim blocking, criminal adjudication, provider outreach, and a universal cross-state identity graph. Those get explicit interfaces and legal review.

At perfect utilization one worker needs 50,000 seconds, or 13.9 hours, to scan all rows—so throughput math alone says one worker fits 36 hours. With 50% effective duty cycle and 50% failure/headroom, the one-pass equivalent rounds up to two workers. That deceptively small result ignores joins, multiple detector passes, shuffle, skew, retries, and roughly four feature facts per row; in practice shuffle partitions number in the hundreds for parallel stages and skew isolation, not because raw scan bandwidth alone requires them.

The bigger constraint is decisions: 1% produces 2.5 million raw hits, while investigators can close only 10,000 cases/day. We need grouping, suppression, calibrated risk, diversity/coverage constraints, and a fixed intake budget. Optimizing detector recall without modeling human service capacity makes the queue unstable.

A BatchManifest contains source object digests and row counts, schema mapping, partition list, quality-policy version, code image digest, enrichment reference snapshots, rule bundle, feature definitions, model/calibrator hashes, graph projection version, and random seed. Each ScoreReceipt records detector outputs, feature snapshot digest, composite formula, confidence/quality, and lineage to claim IDs. We never overwrite a score; correction creates a superseding batch.

Claims use source-stable claim-line IDs plus program namespace. Feature keys include as_of to prevent future leakage. Rule hits store clause/version and operands; model scores store feature-vector digest; graph scores store projection and component/community ID. APIs expose batch publication, lead search, evidence, assignment/lease, disposition, and reproducibility export. Interactive reads come from materialized case/lead stores, not the batch lake.

Source files land immutably in a program-specific object namespace. An intake service verifies checksums, schemas, counts, periods, and completeness before it seals the manifest. A batch orchestrator builds columnar canonical tables, quarantine tables, point-in-time enrichments, and quality reports. Detector jobs read the same frozen snapshot: deterministic SQL/rules, statistical windows, supervised model inference, and a bounded graph projection.

A score combiner calibrates by program/slice, applies data-quality penalties, and groups claim-level hits into provider/beneficiary/time-window lead entities. A queue policy enforces top-K capacity, minimum evidence, diversity, exclusions, and conflict-of-interest routing. Publishing the batch and an outbox event is transactional; a serving index feeds the full-stack investigator UI. Dispositions flow to a governed label store only after supervisory adjudication. Streaming is limited to job events, audit, and optional source arrival—not score truth.

Every reference lookup is bitemporal and pinned to a source digest; “latest provider file” is forbidden in a published run. The container image and dependency lockfile are content-addressed. Rule DSL compiles to a stored plan; feature definitions include null/imputation and window semantics. Stable ordering, fixed seeds, deterministic reducers, and explicit tie-breaking control graph/model nondeterminism. Hardware/library differences are either constrained by the release manifest or accepted within a documented numeric tolerance.

A replay mode reads the original manifest in an isolated namespace and writes a comparison report, never replacing history. We reconcile input row counts, partition hashes, feature aggregates, detector hit counts, lead counts, and a sample of per-entity receipts. An auditor can reconstruct one lead without recomputing all 250M rows because its evidence package contains source row IDs, feature operands, rule traces, and model/graph manifests.

I keep detector scores separate instead of collapsing them into an unexplained “fraud probability.” The combiner calibrates on adjudicated outcomes, but selection bias means observed labels are missing-not-at-random. We reserve a small random or stratified exploration sample, use inverse-propensity analysis where appropriate, and track label source and maturity. Unreviewed does not mean negative.

Queueing is a service-design problem: group duplicate claim hits into one coherent lead; suppress known explained patterns; respect open-case locks and investigator skills; cap provider exposure; reserve slots for high-severity policy rules and exploration; then rank by expected recoverable value, harm, evidence strength, novelty, and age. Supervisors see why a case ranked, what was suppressed, and slice-level yield. Queue changes are policy versions, not hidden model tweaks.

The input manifest had a completeness watermark; if it was violated, the published batch is marked impaired but remains reproducible. I ingest the correction as a new source version, compute lineage-based impact for affected member/time partitions, and build superseding batch B42. We do not mutate scores under open cases.

For untouched leads, queue policy withdraws or replaces them with an explicit reason. For acted-on cases, we attach a material-change alert, recomputed evidence, and required supervisor acknowledgment; downstream financial action needs its own reconciliation. The data steward receives a completeness incident. Future publication can require two-source control totals and an explicit waiver when the source misses its watermark.

That is likely topology and compute skew, not a fraud epidemic. The graph projection excludes or downweights known infrastructural hubs by typed edge semantics; it does not create a naive graph where any shared intermediary implies collusion. We monitor degree distributions and component growth before scoring. Heavy keys get salted partitions, two-stage aggregation, degree caps, and a dedicated skew lane.

I trip a detector-level circuit breaker when hit-rate or distribution shift exceeds bounds. Rules and other models can publish, but graph-derived leads stay shadowed until reviewed. A backfill runs on a corrected projection version; score receipts make the change explicit. We never silently lower a threshold just to fit the deadline.

Each stage key is (program,batch,input_partition_digest,stage_version); immutable outputs and a commit manifest make retries safe. Scheduler queues have per-program quotas, stage concurrency, retry budgets, straggler detection, and separate urgent/live versus historical backfill pools. Publication uses compare-and-set on batch state plus an outbox. Investigator assignment uses leases and optimistic versioning so two users cannot dispose one case concurrently.

State programs have separate object prefixes/accounts, keys, catalogs, serving indexes, and worker identities where contracts require. ABAC combines program, role, purpose, case assignment, and break-glass; analytical jobs use tokenized identities where possible, and FTI/PHI never enters metrics. Retention and legal-hold policy separately covers raw claims, features, graph projections, case notes, label sets, exports, backups, and derived indexes; deletion or correction traverses lineage rather than editing a published score receipt. Monitor input completeness, row quarantine, stage critical path, skew, cost, score drift, calibration, flags and confirmed yield by slice, queue age/capacity, overrides, audit export, and privileged access. Replicate manifests/objects only into authorized regions, rebuild serving stores from published batches, and rehearse regional restore with RPO/RTO and tombstone-reconciliation evidence.

Start with data-quality reports; then replay historical periods; run rules/model/graph in shadow beside the old process; show evidence to a small investigator cohort without changing queue rank; canary queue policy with matched control investigators; expand only when yield, reviewer time, subgroup fairness, recoverable value, reproducibility, and appeals stay within gates. Automatic adverse action remains out of scope.

The trade-off is detector recall versus constrained human attention and false accusation. A giant uncalibrated queue looks “sensitive” but wastes investigators and damages providers. I prefer an explicit capacity budget, diverse evidence, honest uncertainty, and exploration designed to learn about blind spots.

I’ll connect frozen batch truth, explainable detector receipts, bounded queues, and safe correction.