Something real to operate on

Read top to bottom for the full picture, or jump. Sections 3 through 6 are the system itself; 7 through 9 are the reasoning; 10 is the honest comparison to the real thing.

BELLWETHER targets one job: Netflix's Staff AI Engineer role on the Ads Platform team, requisition AJRT30201. That posting asks for five things — a centralized context layer, dev lifecycle agents, ops agents, multi-agent orchestration, and evaluation frameworks — and its underlying tension is stated plainly: ship faster with AI without accumulating slop, regressions, and accountability gaps.

The obvious way to build a portfolio for that role is to demo agents. The problem is that almost every agent demo has the same hole in it: the agent operates on nothing. An "incident triage agent" reads a hand-written log file. An "RCA agent" is handed a fixture describing the answer it is supposed to find. Those demos prove the prompt works. They prove nothing about whether the agent could function against a real system.

So Level 0 inverts the usual order. Before any AI is written, build the thing the AI will operate on:

• Ops agents need real logs and metrics that were emitted by services actually handling requests, and real incidents with real causes.
• Dev agents need a real codebase with real conventions, real tests, and real architectural decisions to be consistent with.
• The context layer needs a real corpus: code, decision records, runbooks, API specs — documents that exist because the project needs them, not because the retriever needs something to retrieve.
• Every eval needs a ground truth that was not authored alongside the answer.

Ads was chosen as the domain because it is the domain of the job. Using the posting's own vocabulary — ad insertion, brand safety, frequency capping, pacing — in the code, the metrics and the logs means a reviewer reads the repo in their own language. It also happens to be a genuinely good domain for this exercise: ad decisioning is latency-sensitive, rule-dense, config-driven and money-adjacent, which produces exactly the kind of failure modes that make ops agents interesting.

Where Level 0 sits in the 30 days

Level 0 is Days 1–5 of a six-level, 30-day build. It is the only level that contains no AI at all. Everything after it consumes it.

None of the design decisions parse without the vocabulary. This is the whole domain model in one page.

A viewer is watching something. The player reaches a point where an ad can run — an ad break. The system is given a fraction of a second to answer one question: which ad, if any, should play here? That question is an ad request, and it carries two things:

• Member context — who is watching. In BELLWETHER: a member id, a country, a device type. In production this is much richer, and much more privacy-governed.
• The slot — the opportunity itself. How many seconds are available, what the content's maturity rating is, and what the surrounding content is about (its categories).

On the other side sit campaigns. A campaign is an advertiser's booking: a budget, a flight window (start and end dates), targeting rules, brand-safety exclusions, a frequency cap, and one or more creatives — the actual video assets, each with a duration.

The job of the decision path is to narrow the campaign set to the ones that are allowed to serve into this specific slot, then pick one. Four constraints do most of that narrowing, and all four appear verbatim in the job posting:

• Targeting — does this campaign want this viewer? Country, device, content rating. An empty targeting list means "unrestricted", not "matches nothing".
• Brand safety — does the advertiser refuse to appear next to this kind of content? A family snack brand excluding true-crime is the canonical case. This is the advertiser protecting itself, and getting it wrong is a real-world incident.
• Frequency capping — has this viewer already seen this campaign too many times today? This is the constraint viewers actually feel. Capping is a quality-of-experience feature as much as a contractual one.
• Budget pacing — is this campaign allowed to spend right now? A campaign with a daily budget should spread it across the day rather than exhausting it by 9am and going dark through prime time.

If a campaign survives all of that and has a creative that fits the slot's duration, it is eligible. If one is chosen, that is a fill; the resulting play is an impression. If nothing survives, it is a no-fill, and the share of requests that fill is the fill rate — the single most-watched number on the serving path.

Two conventions worth explaining

Money is stored in micros — millionths of a currency unit — as integers. Money is never a floating-point number in an ad system, because floats accumulate rounding error and ad systems perform billions of tiny arithmetic operations against budgets. 2_000 micros is $0.002, a plausible price for one impression.

Every rejection has a name. In BELLWETHER a filter never returns a bare false. It returns a reason: targeting_mismatch, brand_safety_excluded, frequency_capped, pacing_throttled. That single decision shapes the whole rest of the project, and section 9 explains why.

The decomposition follows the natural seams of an ads platform rather than technical layers. Each service owns one question, and each owns its own state.

The request path, in order

One trip through the system, from opportunity to recorded fact.

The two state stores, and why there are two

Postgres holds configuration and history: campaigns, budgets, creatives, and every delivered impression. Low write rate, long lived, relational, auditable.

Redis holds the serving path's working set: how many times this member saw this campaign today, and how much this campaign has spent today. Written on every single impression, scoped to one member, and worthless once the day rolls over. That is a counter with an expiry, not a row with a history — so the keys are day-scoped and expire themselves after 48 hours.

These two now deliberately disagree, and the disagreement is meaningful: Redis spend is what the pacer believed at decision time; the Postgres event table is what was actually delivered. The gap between them is reporting loss, and it is a panel on the dashboard.

The data model

Three tables in total across the platform. Small on purpose — every field earns its place by being read by a rule.

Note what the event table stores: request_id. Every impression can be traced back to the exact decision that produced it, including the trace of which campaigns lost and why. That link is the reason a Level 3 root-cause agent will be able to answer "why did fill rate drop at 14:20" against evidence rather than by guessing.

This is the heart of Level 0. Every candidate campaign walks the same chain and is dropped at the first rule it fails, carrying the name of that rule out with it. The order is not arbitrary — cheap, purely local checks run before anything that requires state, so the expensive work is done on the smallest possible candidate set.

Below: three campaigns entering the chain for one slot, and where each one dies.

Why "most budget remaining" wins, rather than "first match"

If the winner were simply the first eligible campaign, whichever campaign happened to sort first would drain its daily budget by mid-morning and then go dark, while under-delivering campaigns stayed under-delivered. Choosing the campaign with the most daily budget left is a crude but real delivery-balancing heuristic: it keeps campaigns tracking toward full delivery of what the advertiser paid for.

In a production system this slot is where an auction lives, and the winner is chosen on expected value — bid, predicted click-through, pacing multipliers, and so on. Level 0 has no auction and no bidding at all. That is the single largest simplification in the whole substrate, and section 10 is explicit about it.

Why pacing has a floor

Pacing releases budget linearly across the day: by noon, half the daily budget is available. Taken literally, that means at 00:00:01 the allowance is effectively zero and nothing can ever serve, because the first impression would exceed the allowance. So the allowance is floored at the price of a single impression — enough for the day to open. It is a one-line detail that is invisible until the day rolls over and the platform mysteriously stops filling.

What comes back

The response is not a boolean and not just an ad. It is the full audit trail of the decision.

Three campaigns, three different named reasons, one response. A human debugging a fill-rate drop does not have to reproduce anything — the answer is in the payload. And because those same names are Prometheus label values and structured log fields, the same answer is available in aggregate, over time, on a dashboard.

The traffic-simulator drives about two ad requests per second through the full stack, reporting impressions and clicks back as delivery events. The population is seeded, so a run is reproducible and an incident can be replayed — which matters more than statistical realism, because ops agents will be scored against runs that must repeat.

It can also break the platform, on demand, over HTTP. The load-bearing rule: failures change real configuration through public APIs. Nothing is mocked, and no service contains a branch that knows it is under test.

The reason this matters is downstream. A Level 3 RCA agent evaluated against a mocked failure can only ever discover the mock — the evaluation would measure the fixture, not the agent. Here, when fill rate collapses, the decision path has behaved perfectly; the cause is a wrong value sitting in a real table, reachable by exactly the query a human would run.

Making the change real forces something else that turned out to be the better design: recovery has to be real too. Returning to steady is not a flag that turns the incident off — it restores the seed configuration. Reverting is a rollback, which is precisely the remediation a guided-resolution agent should be recommending.

The quality gate

Level 0's exit criterion, from the design spec, was "all services healthy under simulator load; failure injection works — 100%". That sentence became a script that exits zero or names the check that failed.

The gate's decision logic is pure and unit-tested; the live run only supplies numbers. That split is what makes it trustworthy in both directions — it cannot pass by accident with the substrate switched off, and it cannot fail because a test double drifted away from reality. Two deliberate details: "not enough traffic" is never a pass (a fill-rate collapse needs at least ten requests of evidence), and the gate leaves the platform healthy when it exits.

On its first run the gate failed itself: the traffic-surge check read its baseline from the response of the call that switched the scenario, which already reflected the new rate — so it compared 20 requests/sec against 20 requests/sec and never moved. Exactly what a gate is for.

Five decision records cover Level 0. Each follows the same shape — context, decision, alternatives, consequences — plus one field that is unusual and is arguably the most valuable practice in the project: the trigger. Every decision names, in advance, the specific observable condition that would make it wrong.

That converts "we'll revisit this later" into a falsifiable statement. Two of the five triggers have now fired on schedule.

Every choice here was made against one constraint that outranks the others: the AI layer being built on top has to be able to read, reason about and modify this code. That biases hard toward explicit types, machine-readable contracts and boring, well-documented tools.

Two smaller choices with outsized effects

Non-default host ports. Postgres publishes on 5433 and Redis on 6380, because 5432 and 6379 are usually already taken on a working machine. Ten seconds of thought that prevents a whole class of "works on my machine" confusion — and the kind of detail a reviewer notices.

One shared observability module. Prometheus keeps a single registry per process, so two services each defining http_requests_total collide the moment both are imported — which the test suite does. The metric is defined once in substrate/shared/observability.py, and the service label is what separates them. This was found by a test failure on Day 3, not by design.

These recur across all four services. Most of them exist because of what has to be built on top.

The honest summary

Level 0 is structurally faithful and operationally miniature. The concepts, their names, their ordering and the shape of the services would all be recognisable to someone who works on CTV ad serving. The economics, the scale, the delivery mechanics and the entire privacy surface are either absent or reduced to a placeholder.

That trade is deliberate and it is the correct one for this project, because the substrate is not the deliverable. It exists to generate real traffic, real metrics, real logs and real incidents for an AI platform to operate on. Adding an auction would make the ads platform more impressive and the AI demonstration no better. Every hour spent on ad-tech sophistication is an hour not spent on the thing the job posting actually asks about.

The claim being made is precise: this person can build a production-shaped distributed system in the ads domain, and reason clearly about what they simplified and why. Not: this person rebuilt Netflix's ad server.

Naming omissions explicitly is part of the argument. An omission you can name is a scoping decision; an omission you cannot is a gap.

• No auction or bidding. No bids, no second-price mechanics, no floor prices, no deal IDs, no guaranteed-versus-biddable inventory.
• No machine-learned ranking. No CTR prediction, no relevance model, no experimentation framework. The selection rule is one line and is explained as a heuristic.
• No identity, consent or privacy layer. A member id is an opaque string; there are no segments, no consent signals, no regional regimes.
• No ad delivery. No transcoding, no CDN, no server-side insertion, no manifest manipulation, no VAST, no player beacons.
• No streaming data platform. Events arrive over HTTP and land in Postgres. There is no Kafka, no stream processor, no warehouse, no batch/real-time split.
• No forecasting or inventory management. No avails prediction, no reach-and-frequency planning, no overbooking protection.
• No multi-tenancy or authentication. Every API is open on localhost. Deliberate for a demo stack; disqualifying for anything else.
• No horizontal scale story. One replica per service. Notably, the frequency counters would survive replication (they are in Redis), while the in-process fallback store would not — and that is documented rather than hidden.

Each of these would be a reasonable thing to build. None of them would make the AI foundation on top of it any more convincing, which is the only test that mattered.

The project's stated thesis is "AI velocity with provable quality", so Level 0 publishes its own numbers before any AI exists to be measured.

Three real defects, found by pointing real load at it

This is the strongest evidence that the substrate is not theatre. On its first day of running, the simulator found three genuine defects in the platform it was pointed at.

1. Budgets overflow a 32-bit column. Micros were stored in a SQLAlchemy Integer, which is a Postgres INTEGER — capping a daily budget at 2,147,483,647 micros, about $2,147. The budget-runaway scenario tried to exceed it and Postgres raised a range error. The ceiling is now stated in the API contract as a validation bound; the real fix, widening the column to BIGINT, is exactly the change that ADR-0002 is waiting on migrations for.
2. That overflow escaped as a bare 500 — a direct violation of the project's own coding standard. Now a typed 422, with a handler ensuring no column's range error can ever surface untyped again.
3. The seed guard was all-or-nothing. One leftover campaign from a manual test suppressed the entire seed campaign set, and the simulator drove traffic against a single narrowly-targeted flight at a 2% fill rate, with 828 candidates rejected for targeting_mismatch. Seeding is now idempotent per campaign, by name.

And a fourth, in the gate itself: it failed on its first run because it read its baseline from the response of the call that changed the state it was measuring.

None of these would have been found by a test suite. All four came from running the real thing under real load and looking at the numbers — which is the entire argument for building a substrate.

Every artifact built in Days 1–5 becomes an input to something later. This is the payoff for choices that looked like over-engineering at the time.

Level 0 ends with four services running, real traffic flowing, dashboards live, five incidents stageable on demand, and a gate that says 11 out of 11. From here the substrate stops being the thing under construction and becomes the thing the AI knows about.