Section 12: Sources and Scores, Not Forks - Follow-up Feature Evolution

Executive Summary: This section answers the interviewer's closing move: six months later, procurement signs a second blocklist vendor, product wants CAPTCHAs instead of 403s, three internal teams want in, and someone asks where the ML is. Every evolution lands on the spine Sections 5 through 9 built. A second vendor is a second adapter and a source column behind explicit precedence — run in shadow mode before it may deny anyone (D10's spirit). Reputation scores turn binary verdicts into graduated actions, which lowers the cost of being wrong and loosens the freshness pressure D8 priced. Platformizing means rule namespaces on the same SDK and policy API — one enforcement path, many policies (D12) — while the vendor budget stays owned by the one scheduler (D7). ML ranks and advises; it never hard-blocks alone, because a block must survive an appeal.

The whiteboard is full, the 0.0.0.0/0 drill just bounced off the gates in Sections 9 and 10, and the interviewer leans back: "Six months later. You've signed a second blocklist vendor. Product hates that real users behind a listed VPN get a hard 403. Fraud and the API gateway team both want in. And a new hire asks why a system this important has no ML. What changes?" D12 promised evolution by adding sources and scores, never a fork. Time to cash that promise.

A Second Vendor: Shadow First, Precedence Always

You: "The vendor adapter was an interface from Section 4 for exactly this day. Vendor B is a new adapter feeding the same mirror — a source column on verdicts distinguishes its rows, and it gets its own token bucket at its own contracted rate, because D7's rule generalizes: every vendor budget is owned by the one scheduler, never shared ambiently, never spent by anyone else."

What a second source actually forces is the question most candidates skip: what happens when the vendors disagree? The conflict policy must be explicit and compiled in, not emergent. The starting policy is conservative and simple: any-vendor-deny denies — a listing from either source puts the range in the deny set, and manual overrides still beat both (D11's precedence, now with one more row: override > country/legal > vendor A ∪ vendor B). The alternative — requiring both vendors to agree — is a policy choice legal may someday want for a low-confidence source, so the compiler takes the merge rule as configuration, not code.

But nobody earns a place in the deny set on day one. The same discipline that gates a snapshot (D10: list updates are deployments) gates a source: Vendor B runs in shadow mode first. Its verdicts flow into the mirror and the compiler produces a parallel would-deny set that no edge enforces. For two to four weeks you measure what you'd otherwise discover in production: overlap with SentinelDB (95% overlap means you bought redundancy, not coverage), unique listings, and — the number that matters — the false-positive rate on would-have-denied traffic, estimated against known-good signals and the appeals history Section 9 started collecting. A vendor whose unique contribution is mostly FPs costs trust; you learned that before a single user saw a 403 with its name on it.

Quick check before moving on: