I'm building an AI
platform that writes code,
reviews it, and runs it

Day 00 · The problem

Where this started

Netflix has been the company I wanted to work for since well before I could have explained what a distributed system was. Not because of the product — because of how openly they think in public. Chaos engineering, the microservice patterns half the industry now copies, the causal-inference work, the agentic tooling they have started writing about: most of it was published while it was still being figured out, with the trade-offs left in rather than tidied away.

That is rare. Most companies publish the polished version, years later, once nothing is at stake. Reading Netflix work through a problem in public taught me more than most of the courses I have paid for.

So: dream company. Which is a pleasant sentence and completely useless on its own.

Wanting to work somewhere is not a plan

What I actually needed was a way to build something real rather than something aspirational. Which meant answering a question I had never thought to ask properly: how do you find out what a company is about to build, before they build it?

The answer turned out to be sitting in the open. A company's engineering blog and its job listings are the two most honest public statements it makes about its own direction.

• The blog tells you what they have already solved — and, more usefully, how they reason. What they measure. What they will accept as evidence.
• The listings tell you what they are staffing right now — which is to say, what somebody has already decided is important enough to spend headcount on, before a line of it ships.

So I read both, properly, for weeks. The blog gave me the house style. The listings gave me the target.

One posting stopped me: requisition AJRT30201 — Staff AI Engineer, AI Foundation & Tooling, Ads Platform. I started pulling it apart, and the more I dug the more it read less like a wish list and more like a roadmap somebody had already committed to. Strip out the boilerplate and it describes one specific, current problem:

Engineering teams can now produce code far faster than they can verify it.

That sentence is easy to nod along to and easy to underestimate, so let me show you what it actually means.

What "plausible but wrong" actually looks like

Here is a function from my own domain code. An AI could write it in a second, I could approve it in five, and it is wrong.

# Has this campaign spent its daily budget?
def within_budget(campaign, spent_micros):
    return spent_micros < campaign.daily_budget_micros

Read it again. It compiles. It passes a strict type check. It reads exactly like the comment above it. A test asserting "a campaign that has spent nothing is within budget" passes. So does "a campaign that has spent everything is not."

It is still wrong: it asks whether the campaign has already overspent, not whether serving this advert would cause it to overspend.

daily_budget   = 10,000,000   # $10.00
already_spent  =  9,999,000   # $9.999
this_ad_costs  =    500,000   # $0.50

within_budget(...)  → True     # because 9,999,000 < 10,000,000
                             # so it serves, and the day ends at 10,499,000

→ every campaign overspends its daily cap, every day, forever.

The correct version is one clause longer:

return spent_micros + price_micros <= campaign.daily_budget_micros

Nobody is ever paged for this. There is no crash, no error rate, no red panel on a dashboard. Advertisers are quietly billed slightly more than they agreed to, for months. It is found by an auditor, not by an alert.

The five capabilities the posting asks for

They are not independent. Each depends on the one before it — which is why the build order in this project is not negotiable.

Item five is where nearly every portfolio project quietly gives up — and it is the only one that makes the other four trustworthy.

A demo and an evaluation are not the same thing

The words get used interchangeably. They should not be.

Concretely, for the pull-request reviewer arriving on Day 13, the evaluation is this:

# Take working code. Plant 10 realistic bugs, one per branch.
# Each is the kind a tired human writes at 5pm on a Friday.

  1. off-by-one in a frequency cap         # < where it should be <=
  2. budget check ignores the pending ad   # the bug shown above
  3. missing guard when targeting is empty
  ...

# Ask the reviewer agent to review each branch, cold, with no hint
# that a bug exists. Score = caught, minus false alarms invented.

catch rate: 7/10 — published, including the run that scored 4

That number can go down when the code changes. That is precisely why it is worth having.

Why I'm building it in public, with the failures left in

The honest version: I want this job, and I know what a portfolio project usually looks like from the other side of the desk. A repository with a confident README, a demo video where everything works first time, and no way for a reviewer to tell whether any of it survives contact with reality.

I did not want to send that. Anyone can claim they build agentic systems. Almost nobody publishes the number that would prove it, because the number is often disappointing.

So I am building the version that can be checked. In the open, one day at a time, with the mistakes left where they happened. Every figure on this page came from a command I actually ran. Every amber box is something I got wrong and then wrote down — including the day I broke a rule I had written myself, four days earlier, about that exact mistake.

If the agents turn out worse than I hoped, that will be on this page too. It is the only thing that makes the good numbers worth anything.

The call I had to make before Day 1 existed

With a plan sketched out, one genuinely hard decision was left — and getting it wrong would have cost me the entire month.

The job is the AI layer. It is not ad serving. Nobody is hiring me to write a frequency capper. So which do I build first?

The top two rows are about convenience — what is quicker, what looks good sooner. The bottom two are about whether any of it means anything, and that is where the argument actually gets settled.

I chose the ads platform.

Play the other choice forward and picture Day 20. I am recording a video where an ops agent diagnoses an outage. Where did the outage come from? A JSON file of log lines I wrote by hand, describing a failure I invented, in a system that was never running. The agent finds the cause — because I put it there, in the shape I expected it to be found in.

What has that measured? My ability to write a fixture. Any viewer with production experience sees straight through it, and worse, I would never learn whether the thing works.

So I paid five days up front. It cost me a week of build videos in which the AI barely appears, and it is the reason every number later on this page is worth reading.

Which is to say: to show an agent an outage, you need an outage

Most demos fake it. In code, the fake usually looks about like this:

# The staged incident
if os.environ.get("CHAOS") == "true":
    return {"error": "database unavailable"}

Now point an agent at that and ask for a root cause. What is there to find? The only true answer is "an environment variable is set." The agent has learned nothing about databases, nothing about this system, and nothing that transfers to a real incident.

An agent tested against a fake failure can only ever find the fake. The evaluation measures the fixture, not the agent.

Compare what I do on Day 5. My simulator sends genuine PATCH requests rewriting every campaign's targeting to a country with no viewers. The decision service reads that configuration and correctly declines to serve. Fill rate drops from 43% to 2%.

Every part of that is real. The cause is a row in a table an agent can query. The symptom is a metric an agent can chart. The fix — restore the previous targeting — is a real operation with real consequences. That is something worth evaluating an agent against.

So the project is two systems, and the unglamorous one goes first

One system is the point. The other exists only so the first has something real to work on.

flowchart LR
    SUB["SUBSTRATE<br/>a small ads platform<br/>•<br/>4 services · real traffic<br/>real logs · real incidents"]
    BW["BELLWETHER<br/>the AI layer — the point<br/>•<br/>context · dev agents · ops agents<br/>orchestrator · evals"]
    SUB ==>|"its code, logs, metrics<br/>and real failures"| BW
    BW -.->|"operates on"| SUB
    classDef sub fill:#241416,stroke:#b8321f,stroke-width:1px,color:#f3d9d6;
    classDef ai fill:#12211a,stroke:#2f6f4f,stroke-width:1px,color:#d6ece0;
    class SUB sub;
    class BW ai;
        

Why an ads platform specifically

The substrate could have been anything. I chose ad serving for four reasons, none of them "it sounded impressive":

• It is the target team's actual domain. Using the posting's own vocabulary — targeting, frequency capping, brand safety, pacing — in code, logs and docs means every conversation lands in the right register.
• Its failures are configuration failures. The realistic outage in ad tech is not a severed cable, it is a bad targeting deploy. Those have a cause sitting in a database — exactly the shape an RCA agent can be honestly evaluated against.
• It produces genuine telemetry under load. Fill rates, rejection reasons, latency percentiles, spend. Real numbers that move for real reasons.
• It is small enough to finish. Four services, one machine. The substrate is scaffolding, and scaffolding that takes three weeks has eaten the project.

How "mini" is mini? An honest accounting

I want to be precise about this, because "I built a Netflix-style ads platform" is the kind of claim that deserves immediate suspicion.

What I built is realistic in shape and tiny in scale, and those are very different things. Here is the gap, stated plainly:

Read the right-hand column and the logic of every omission becomes visible. I built exactly the parts the AI layer has to reason about, and skipped the parts it does not.

Scale is the clearest example. Going from two requests a second to two million would be weeks of work and would teach the agents nothing new — a root-cause agent reads the same rejection reason off the same metric either way. Throughput is an interesting engineering problem and an irrelevant one here.

What I did not compromise on is the part that matters: every rejection carries a named reason, every request leaves a structured log line, every failure has a cause sitting in a real database, and every number comes from a real run. Those are the properties an agent operates on. A platform a thousand times larger with none of them would be useless to this project.

The thirty days, in six levels

I wrote every target before building its level. That ordering matters more than it looks: a target I invent after seeing the result is not a target, it is a description.

Days 1–5 I build the substrate. From Day 6 I start on the AI layer itself.

The method

How a single day actually runs

This is the loop I run every day. None of it is ceremony — every step is there because skipping it cost me something specific, and most of those costs are named later on this page.

flowchart LR
    A["1 · Read<br/>spec + yesterday's<br/>execution notes"] --> B["2 · Write the plan<br/>into the repo,<br/>task by task"]
    B --> C["3 · Per task:<br/>test first, watch it fail,<br/>then implement"]
    C --> D["4 · Four gates,<br/>run separately"]
    D -->|"any fail"| C
    D -->|"all pass"| E["5 · Commit<br/>conventional message"]
    E --> F["6 · Devlog + running doc<br/>+ execution notes"]
    F -->|"tomorrow"| A
      

Step 1 · The plan is a file in the repository

Before I write any code, I commit a written plan to docs/superpowers/plans/. Not a to-do list. A document naming every file that will exist, the exact function signatures, and the tests I will write first.

Here is the shape of a real task from the Day 7 plan:

### Task 4: The embedder protocol, cost tracking, and the hashing engine

Files: create embedders/base.py, embedders/hashing.py + tests

Produces:
  UsageRecord   — engine, texts, tokens, cost_usd, latency_ms
  EngineSpec    — name, label, dimensions, hosted, cost_per_million_tokens
  Embedder      — Protocol: spec, available() -> (bool, str), embed(texts)

Tests: determinism; unit norm; shared vocabulary scores higher than
       unrelated text; cost_usd == 0; registry lists all four names

- [ ] Write failing tests → run → implement → run → commit

I started writing plans into the repository because I kept discovering, four files into a task, that I had chosen the wrong shape — and by then the wrong shape was load-bearing. It forces me to think the design through while changing it is still free — renaming a function in a plan costs nothing, renaming it across nine files costs me an hour. And it means a fresh session, or someone else entirely, can pick the work up without re-deriving anything I already worked out.

The plans are also, deliberately, part of the corpus. From Day 6 onward the AI layer can read how each day was planned, including what the plan got wrong.

Step 2 · Test first — and watch it fail

Every task I write follows five steps. Here is a real one, start to finish.

2a. Write the test before the code exists. This is from Day 4's event-service — the test that pins down idempotent counting:

def test_the_same_event_reported_twice_is_counted_once():
    first  = post_event(event_id="evt-123", event_type="impression")
    second = post_event(event_id="evt-123", event_type="impression")

    assert first.status_code  == 201
    assert first.json()["status"]  == "recorded"
    assert second.status_code == 200
    assert second.json()["status"] == "duplicate"

    # the point of the whole day
    assert get_delivery()["impressions"] == 1

2b. Run it, and confirm it fails for the right reason.

$ uv run pytest tests/substrate/event_service -q

E   ModuleNotFoundError: No module named 'substrate.event_service.main'
1 error during collection

This is the step I am most tempted to skip. It feels like theatre — I already know it will fail, so why spend the ten seconds watching it?

I do it anyway, every time, because running the test before the code exists is the only proof that the test is capable of failing at all.

A test that has never been seen failing might be asserting nothing at all — a typo in a fixture name, an assertion inside a branch that never runs, a comparison that is always true. A test that always passes is worse than no test, because it produces confidence without evidence, and it will still be passing years later while the behaviour it claims to protect has quietly rotted.

2c. Write the minimum code to pass. Not the elegant version, not the general version — the one that makes this test go green.

2d. Run it again.

$ uv run pytest tests/substrate/event_service -q
............ 12 passed in 0.61s

2e. Commit. Then the next task starts from a green repository, which means any breakage in the next hour was introduced in the next hour.

Step 3 · Four gates, run separately, never piped

I run them as four separate commands on four separate lines. That sounds pedantic until you see what happened when I did not:

# WRONG — reports success even when mypy fails.
# In a pipeline the surviving exit code is tail's, and tail always succeeds.
uv run mypy tests substrate platform bellwether | tail -2 && git commit

# RIGHT — each gate's own exit code is visible and fatal.
uv run ruff check .
uv run ruff format --check .
uv run mypy tests substrate platform bellwether
uv run pytest

This exact mistake shipped nine type errors on Day 7. My own Day 4 notes warn against it. I wrote both.

Step 4 · The tests must pass with everything switched off

A rule I hold myself to: the entire suite passes with Docker stopped and no API keys set. 289 tests, about six seconds.

I built it this way for a selfish reason. A test suite that takes two minutes and needs four containers is a suite I will quietly stop running — not deliberately, just by drifting into running it less often, until the day it fails and I have no idea which of the last twenty changes did it. Six seconds is fast enough that I never have to decide.

This is enforced by design rather than willpower. Business logic never reaches out for what it needs — it is handed it. Databases, HTTP clients, clocks and random number generators all arrive as arguments:

# The decision logic has no I/O of its own. In production `store` is Redis
# and `now` is the wall clock. In tests they are a dict and a fixed datetime.
def decide(request, campaigns, store, now):
    ...

# So a frequency-cap test needs no Redis, and no container:
def test_a_member_at_their_cap_is_rejected():
    store = {"freq:member-0042:camp-1:2026-07-22": 3}
    result = decide(request, [campaign_capped_at(3)], store, now=FIXED_TIME)
    assert result.no_fill_reason == "frequency_capped"

Two payoffs. Speed — a six-second feedback loop instead of a two-minute one, which changes how often I am willing to run it. And honesty — a test that needs a running database is partly testing the database, and will fail for reasons that have nothing to do with the code I just wrote.

Step 5 · Decisions get written down with an expiry condition

Every significant choice becomes an Architecture Decision Record with a fixed five-part shape. Here is ADR-0003, in full outline:

Context       What was true when this was decided.
              Frequency counts are written on every impression, are
              per-viewer, and are worthless after midnight.

Decision      What was chosen.
              Redis holds decision state under day-scoped keys that
              expire themselves. Postgres stays the system of record.

Alternatives  What was rejected, and honestly why.
              Postgres for everything — rejected: these are counters
              with an expiry, not records; it would mean writing a
              cleanup job to delete yesterday's rows forever.

Consequences  What this now costs.
              Two stores to reason about. Redis can be lost without
              data loss, but the pacer briefly forgets what it spent.

Trigger       The specific condition that reverses this.
              Day 4's event-service, when impressions become durable
              and spend becomes billable.

I add the trigger because of something I have watched happen on every team I have worked on: a decision that was correct in 2023 is still being obeyed in 2026, and nobody can say why. The trigger is the part that makes this worth doing. Without it my decision hardens into folklore — "we don't do that here" — and nobody, including me, remembers whether the original reason still holds. With it, the decision carries its own review date.

And it fired. One day later, event-service made impressions durable. The trigger had named that exact event in advance, so the question was already on the table rather than being noticed six months later. The answer turned out to be narrow it rather than reverse it:

# ADR-0003, Day 4 update
Postgres now holds the auditable record of what was served.
Redis keeps only the hot counters the serving path reads.

They now disagree by design — and the gap between them is
"reporting loss", which became a panel on the dashboard.

A decision I could revisit on schedule turned into a feature. That only happened because I wrote down, a day in advance, the condition under which I would think about it again.

Step 6 · Commits say what changed and why

Every commit I make uses a conventional prefix and imperative mood, and has to leave the repository green — tests, lint and types all passing.

The message body carries the reasoning when it is not obvious. That fix: above reads, in full:

fix: restore mypy to clean after the vector store landed

The previous commit passed its gates through a pipe, so mypy's
non-zero exit was swallowed by tail and nine type errors went in
green. Day-04 execution note 6, committed by the person who wrote it.

I write the reasoning into the commit because the commit is the only artefact that survives with the code. Writing that down cost me thirty seconds and makes my mistake findable forever. Hiding it would have cost nothing today and everything the third time I do it.

Step 7 · Reproduce the CI command exactly, before pushing

Running a superset of what CI runs is not the same as running what CI runs, and the difference hides an entire class of failure.

Day 7 made this concrete. My machine had an optional AI dependency installed; the build server would not. So before pushing, I deliberately stripped my environment back to match:

# Strip the optional group so the venv matches the build server exactly
$ uv sync --group dev
 - model2vec==0.8.2
 - numpy==2.4.6

# Then run the four CI commands verbatim
$ uv run ruff check .                                    All checks passed
$ uv run ruff format --check .                           105 files formatted
$ uv run mypy tests substrate platform bellwether        no issues in 105 files
$ uv run pytest                                          289 passed

The test count went up by one without the optional package — a test that skips when the library is present and runs when it is absent. Both environments genuinely covered, and I would never have seen it without reproducing the real one.

Step 8 · The day ends by recording what the plan got wrong

Every plan I write ends with a section titled "Execution notes — what the plan missed." I write it after the work, listing everything reality disagreed with me about. Not a retrospective anyone schedules — a numbered list, in the plan file, committed.

A real one, from Day 7:

1. PUT /points in Qdrant replaces a point outright. The plan's
   two-call write destroys every previously written engine's vector,
   because the payload write is itself a full replace. Every unit test
   passed against the fake. Found only by pointing the store at a
   running Qdrant and asking whether the first vector survived. It did not.

   → Any plan that fakes a datastore must include one live
     round-trip before the design is trusted.

I write the next day's plan with those notes open. This is the single highest-leverage habit I have, and I only added it after Day 3 — because I genuinely do repeat the same mistake in disguise, and I would not have believed that about myself until I had the table below:

Step 9 · The definition of done, every day

My day is not finished when the code works. It is finished when all of this is true:

• Every task in the plan is implemented, test-first, and committed separately
• All four gates pass, run individually and unpiped, with Docker stopped
• The CI command has been reproduced verbatim in a matching environment
• Any significant choice has an ADR — with alternatives and a trigger
• The devlog is written: shipped, decisions, what running it found, what tomorrow does
• The running doc is updated — day tracker, and the scoreboard if a number was produced
• The execution notes are written, honestly, including the embarrassing ones

That last clause is doing real work. Every mistake on this page — the piped gate, the destroyed vectors, the gate that measured itself — I reported on myself. A build log that only contains successes is a marketing document, and nobody learns anything from it, least of all me.

The toolkit

Every tool, and what it beat

Nothing here was chosen because it is popular. Each one is doing a specific job, and the alternative it displaced is named.

Language and packaging

The web layer

Storage — two kinds, on purpose

Seeing what is happening

Infrastructure and quality

The AI layer adds three tools of its own — a vector database and two embedding models. They arrive in Reel three, alongside Day 7, where the ideas they depend on are explained first.

Reference · the substrate in full

The architecture, in depth

Reel two tells the build one day at a time. This chapter is the map you read it with — the finished platform as a whole, in five short passes:

• The shape — how the two halves connect, in one diagram
• The parts — every service and store, one line each
• One real request — traced end to end, no invented values
• The data — what is stored where, and what is measured
• One real failure — injected, measured, recovered

Skim it for the shape now; come back when a later day zooms in on one part.

flowchart TB
    subgraph SUB[" SUBSTRATE — a small ads platform, built Days 1–5 "]
        direction LR
        SIM["traffic-simulator<br/>seeded load + injectable failures"]
        ADS["ad-decision-service<br/>6-filter serving path"]
        CS["campaign-service<br/>campaigns, budgets, targeting"]
        EV["event-service<br/>impressions, clicks, spend"]
        RED[("Redis<br/>freq caps · pacing spend<br/>(hot, expires nightly)")]
        PG[("Postgres<br/>system of record")]
        OBS["Prometheus + Grafana<br/>metrics, dashboards, JSON logs"]
        SIM ==>|"① ad request"| ADS
        ADS -->|"reads active campaigns"| CS
        ADS <-->|"caps + spend"| RED
        ADS ==>|"② returns the ad"| SIM
        SIM ==>|"③ reports impression / click"| EV
        SIM -->|"seeds campaigns ·<br/>PATCHes them to inject a failure"| CS
        CS --> PG
        EV --> PG
        SIM -.-> OBS
        ADS -.-> OBS
        CS -.-> OBS
        EV -.-> OBS
    end

    STR1(["source, docs,<br/>API contracts, ADRs"])
    STR2(["logs, metrics,<br/>dashboards"])
    STR3(["real incidents<br/>with a cause in a table"])

    SUB --> STR1
    OBS --> STR2
    SIM --> STR3

    subgraph BW[" BELLWETHER — the AI layer, built Day 6 onward "]
        direction TB
        CTX["Context layer<br/>grounds every agent in team knowledge"]
        DEV["Dev agents<br/>code, tests, PR review, deploy checks"]
        OPS["Ops agents<br/>triage, log/metric correlation, RCA"]
        ORCH["Orchestrator<br/>coordinates agents, escalates to a human"]
        CTX --> DEV
        CTX --> OPS
        ORCH -.-> DEV
        ORCH -.-> OPS
    end

    STR1 ==>|"ingested, chunked, embedded"| CTX
    STR2 ==>|"parsed, correlated"| OPS
    STR3 ==>|"the thing to diagnose"| OPS

    EVAL{{"Eval harness<br/>a published score on every capability"}}
    DEV -.-> EVAL
    OPS -.-> EVAL
    CTX -.-> EVAL

    classDef sub fill:#241416,stroke:#b8321f,stroke-width:1px,color:#f3d9d6;
    classDef store fill:#1a1116,stroke:#8f5a63,stroke-width:1px,color:#e6d2d6;
    classDef ai fill:#12211a,stroke:#2f6f4f,stroke-width:1px,color:#d6ece0;
    classDef stream fill:#1c1c24,stroke:#6b6b78,stroke-width:1px,color:#eaeaef;
    classDef evalcls fill:#241f14,stroke:#e8a33d,stroke-width:1px,color:#f0d9ac;
    class SIM,ADS,CS,EV,OBS sub;
    class RED,PG store;
    class CTX,DEV,OPS,ORCH ai;
    class STR1,STR2,STR3 stream;
    class EVAL evalcls;
        

One edge matters more than all the others: the simulator seeds the campaigns, and it injects failures by genuinely PATCHing them through campaign-service's public API (ADR-0005). Every incident an agent later diagnoses starts on that edge — a genuinely broken configuration, not a fixture.

The substrate then feeds the AI layer three things. Its source and docs become the context layer (Days 6–10). Its logs and metrics are what the ops agents read (Days 16–20). Its injected incidents are the thing to diagnose. The eval harness scores every capability and publishes the number, flattering or not.

What each part is, in one line

One real ad request, traced end to end

Now the territory. One ad request moves through the running system, against the three campaigns the platform seeds itself with on first start. Nothing below is invented — every number, field and reason string is what the code produces.

A viewer reaches an ad break. The simulator sends this to ad-decision-service:8002:

POST /ad-request
{
  "member": { "member_id":"member-0042", "country":"US", "device_type":"tv" },
  "slot":   { "slot_id":"slot-118", "duration_seconds":30,
              "content_rating":"TV-14", "content_categories":["drama","comedy"] }
}

The decision service pulls the active campaign set from campaign-service, then runs three candidates through six filters in a fixed order — cheapest and most-eliminating first. Each column is one of the real seed campaigns:

Two campaigns clear all six filters. The tiebreak is the one line of policy that matters most: the winner is the eligible campaign with the most daily budget remaining — max(eligible, key=budget_remaining) — not the first match. Northwind ($65 left) beats Acme ($60 left). Without that rule, whichever campaign sorted first would drain its whole day by mid-morning.

The response names the winner and — this is the part that pays off for the whole rest of the project — carries a trace of why every candidate landed where it did:

{
  "request_id": "3f9c1a20-...",
  "slot_id": "slot-118",
  "filled": true,
  "ad": {
    "campaign_name": "Premium sedan, connected TV only",
    "advertiser":    "Northwind Motors",
    "creative_name": "30s cutdown",
    "asset_url":     "https://cdn.example/sedan-30.mp4",
    "duration_seconds": 30,
    "price_micros": 2000            // $0.002 per impression
  },
  "no_fill_reason": null,
  "candidates_considered": 3,
  "trace": [
    { "campaign_name":"Premium sedan, connected TV only", "reason":"eligible" },
    { "campaign_name":"Wide-reach snack launch",          "reason":"eligible" },
    { "campaign_name":"Sports drink, mobile takeover",    "reason":"targeting_mismatch" }
  ],
  "decision_latency_ms": 1.2
}

Two things happen the instant this fills, and they go to different stores for different reasons. The decision service writes the frequency count and pacing spend to Redis immediately, so the very next request for member-0042 sees the updated numbers. Separately, the simulator reports the impression to event-service:8003, carrying that same request_id, and it becomes one durable row in Postgres:

POST /events  → event-service         # the durable record
{ "event_id":"7c2...", "event_type":"impression", "request_id":"3f9c1a20-...",
  "campaign_id":"...", "member_id":"member-0042", "price_micros":2000 }
→ 201 recorded

# meanwhile, already written to Redis at decision time:
freq:member-0042:<campaign>:2026-07-23   =  1     # TTL 48h, self-expiring
spend:<campaign>:2026-07-23              =  2000  # micros

That split is deliberate and it is ADR-0003 made concrete: Redis is what the pacer believed at decision time; Postgres is what was actually delivered. They can diverge — a lost Redis write, a dropped event — and the gap between them is not a bug, it is a number on the dashboard called reporting loss.

The data model, in real fields

Two tables carry the durable state. Money is Integer micros everywhere — never a float — and a caller-supplied event_id is the primary key that makes double-counting impossible.

campaigns  (Postgres, behind campaign-service)
  id                     uuid   PK
  name, advertiser       str
  status                 str    # draft | active | paused
  budget_micros          int    # total; 32-bit — capped at $2,147 (found the hard way)
  daily_budget_micros    int
  frequency_cap_per_day  int    # default 3
  targeting              json   # { countries, device_types, content_ratings }
  brand_safety_exclusions json  # ["news", "true-crime", ...]
  starts_at, ends_at     datetime
  ↳ creatives          (name, duration_seconds, asset_url)

ad_events  (Postgres, behind event-service — append-only)
  event_id     uuid   PK     # chosen by the caller — the whole idempotency trick
  event_type   str           # impression | click
  request_id   uuid          # ties the event back to the decision that caused it
  campaign_id, creative_id  uuid
  member_id, slot_id        str
  price_micros int           # impression = 2000, click = 0
  occurred_at  datetime

What the platform measures

Prometheus scrapes every service every few seconds. These are the metrics that matter. The one that does the most work is ad_candidates_filtered_total — because Day 3 gave every rejection a name, a fill-rate collapse becomes a single chart where you read the cause off whichever band grew.

A failure, with the actual numbers

This is where the whole "real, not mocked" argument cashes out. To inject a bad config deploy, the simulator makes a genuine call to campaign-service — for every campaign:

PATCH /campaigns/{id}  → campaign-service      # repeated for all 3
{ "targeting": { "countries":["AQ"], "device_types":[], "content_ratings":[] } }
                    // AQ = Antarctica. No viewer is ever there.

Nothing is faked. The decision service reads the changed configuration and correctly declines to serve, because the targeting genuinely no longer matches anyone. On the running stack, the effect was measured:

fill rate     43%  →  2%          # within seconds of the PATCH
loss reason   the targeting_mismatch band takes over the "why candidates lost" chart

Recovery is equally real: the steady scenario PATCHes the original targeting back. It is not an undo flag — it is the same remediation an ops agent will be asked to recommend on Day 19. And a second failure mode, budget_runaway, is how the platform found a defect in itself on day one:

PATCH  daily_budget_micros  →  9,000,000,000
→ 500  NumericValueOutOfRange   # budget_micros is a 32-bit Integer,
                              # capped at 2,147,483,647 micros = $2,147/day

A real ceiling nobody knew existed, surfaced by pointing real load at a real platform — and, because it first escaped as a bare 500 in violation of the project's own standard, now a typed 422. That is the entire thesis in one incident: a system that is genuinely running finds the things a plan cannot.

Day 01 · Foundation

The boring day that decides the next twenty-nine

Day 1 produces nothing a user could touch. It builds the workshop: how code gets checked, how the databases start, how anyone can tell whether things are working.

Skipping this is the most common way a 30-day build collapses around day nine.

What actually got built

• The repository, with the four quality gates wired to run on every change
• A Compose file starting Postgres, Redis, Prometheus and Grafana — all healthy on one command
• Continuous integration: the same four gates run on every push, on a clean machine
• The running doc — a live page with the architecture, a 30-day tracker, and an evaluation scoreboard
• ADR-0001

The scoreboard shipped with every number blank. Publishing empty cells on day one is a commitment: those cells are the entire point of the series, and they only get filled by something that actually ran.

Day 02 · campaign-service

Where the advertisers live

The first real service. It stores campaigns — an advertiser's instructions about when, where and to whom their advert may be shown.

The vocabulary is deliberate. These are the exact terms the Netflix posting uses, and using them consistently in code, logs and documentation is what lets an agent later connect a question to an answer.

flowchart LR
    C["Campaign<br/>total budget · daily budget<br/>frequency cap · status<br/>flight window"]
    T["Targeting<br/>countries<br/>device types<br/>content ratings"]
    B["Brand safety<br/>excluded categories"]
    CR["Creative<br/>name · asset URL<br/>duration seconds"]
    C --> T
    C --> B
    C -->|"one campaign,<br/>many creatives"| CR
    C --> PG[("PostgreSQL")]
      

Money is never a decimal

Budgets are stored as whole numbers of micros — millionths of a currency unit. Ten dollars is 10000000.

This looks awkward and prevents a genuine disaster. Computers cannot represent 0.1 exactly in the decimal format most languages default to:

# Python, and every other language using the same number format
>>> 0.1 + 0.2
0.30000000000000004

>>> sum([0.1] * 10)
0.9999999999999999   # should be 1.0

Spread that across millions of impressions and the books stop balancing, in a way that is nearly impossible to trace afterwards. Whole numbers never drift.

Failures have a fixed shape

Every error — a malformed request, a campaign that does not exist, anything — returns the same envelope:

// A campaign that does not exist
{ "error": { "code": 404, "message": "Campaign 7f3a... not found" } }

// A budget that exceeds what the column can hold
{ "error": { "code": 422, "message": "daily_budget_micros must be <= 2147483647" } }

A generic "500 Internal Server Error" tells the caller nothing and gives them nothing to act on. Every failure here is typed and explained.

Every request leaves a structured trace

{"service":"campaign-service", "endpoint":"POST /campaigns",
 "status":201, "latency_ms":12.4, "campaign_id":"7f3a..."}

One line of JSON per request. Data, not prose.

Day 2 ended at 23 tests passing.

Day 03 · ad-decision-service

The twenty milliseconds that matter

This is the heart of any ads platform. A viewer reaches an ad break. Something must decide, in milliseconds, which advert to play — or that none is suitable.

// The request: who is watching, and what slot is available
POST /ad-request
{
  "member": { "member_id":"member-0042", "country":"US", "device_type":"tv" },
  "slot":   { "slot_id":"slot-118", "duration_seconds":30,
              "content_rating":"TV-14", "content_categories":["drama","comedy"] }
}

Six filters, in a deliberate order

Every campaign starts as a candidate. Each filter eliminates some. The order is chosen so the cheapest, most eliminating checks run first — there is no point asking Redis about frequency caps for a campaign that expired last week.

flowchart TB
    REQ["Ad request<br/>member + slot"] --> F1
    F1["1 · Eligibility<br/>active, and inside its flight window?"] --> F2
    F2["2 · Targeting<br/>right country, device, content rating?"] --> F3
    F3["3 · Brand safety<br/>does this content offend the advertiser?"] --> F4
    F4["4 · Frequency cap<br/>has this viewer already seen it enough?"] --> F5
    F5["5 · Budget pacing<br/>has it spent its allowance for now?"] --> F6
    F6["6 · Creative fit<br/>is there a video of the right length?"] --> WIN
    WIN["Winner: the campaign with the<br/>most daily budget remaining"] --> OUT["Filled ✓"]
    F1 -.->|"campaign_inactive"| NF["No-fill,<br/>with a named reason"]
    F2 -.->|"targeting_mismatch"| NF
    F3 -.->|"brand_safety_excluded"| NF
    F4 -.->|"frequency_capped"| NF
    F5 -.->|"pacing_throttled"| NF
    F6 -.->|"no_creative_fit"| NF
      

I made the winner the campaign with the most daily budget remaining, not the first one that matches. Otherwise whichever campaign happens to sort first drains its entire day by mid-morning and everything else starves.

// The response, when nothing could be served
{
  "request_id": "44444444-...",
  "filled": false,
  "no_fill_reason": "frequency_capped",
  "candidates_considered": 3,
  "trace": [
    {"campaign":"Wide-reach snack launch", "lost_to":"frequency_capped"},
    {"campaign":"Premium sedan, CTV only",  "lost_to":"targeting_mismatch"},
    {"campaign":"Sports drink, mobile",     "lost_to":"targeting_mismatch"}
  ],
  "decision_latency_ms": 1.2
}

Every response says which campaign lost, and to which rule.

Two kinds of memory

Frequency capping needs to know how many times this viewer has already seen this advert today. That count is written on every impression, is per-viewer, and is worthless after midnight.

Day 3 ended at 51 tests passing, all with Docker stopped.

Day 04 · event-service + dashboards

Counting things exactly once

An advert played. That is an impression, and it costs the advertiser money. Someone clicked it. That is a click, and it costs nothing. Both must be recorded.

The hard part is not storing them. It is storing them exactly once.

Why counting is genuinely hard

Networks are unreliable. A player reports an impression, the confirmation gets lost in transit, the player reasonably retries. The same impression now arrives twice. Count both and the advertiser is billed twice.

The obvious fix is to check first: have I seen this before? No? Then save it. That fix is broken, and understanding why is worth thirty seconds:

sequenceDiagram
    participant A as Report A
    participant B as Report B, a retry
    participant DB as Database
    Note over A,B: same impression, same moment
    A->>DB: seen event-123?
    DB-->>A: no
    B->>DB: seen event-123?
    DB-->>B: no
    A->>DB: save it
    B->>DB: save it
    Note over DB: counted twice
      

Both checks ran before either save. Neither did anything wrong. The bug lives in the gap between checking and writing — and no amount of careful code closes a gap that is inherent to the approach.

POST /events  { "event_id":"evt-123", "event_type":"impression", ... }
→ 201  { "status": "recorded" }

# the identical body again, twice
→ 200  { "status": "duplicate" }
→ 200  { "status": "duplicate" }

GET /delivery  → impressions: 1

The whole idea, in three requests.

Server-generated identifiers were never an option: every retry would receive a fresh one and therefore become a brand-new impression. The caller must own the identifier for any of this to work.

Totals are computed, never stored

Delivery figures come from scanning the events table on demand — one grouped query — rather than being maintained in a separate running-total table.

A running total is a second copy of the truth, and two copies drift the first time anyone corrects historical data. The scan is fast because the table is small, not because the query is clever, and that distinction is written down along with the condition that changes it: when the query exceeds roughly 200 milliseconds under load.

The trigger from yesterday fired, on schedule

ADR-0003 said Redis would hold spend until impressions became durable. Today they did. The decision narrowed rather than reversed:

flowchart LR
    R[("Redis<br/>what the pacer believed<br/>at decision time")]
    P[("Postgres<br/>what was actually<br/>delivered")]
    R -.->|"the gap between them"| G["reporting loss<br/>— a dashboard panel,<br/>not a bug"]
    P -.-> G
      

They now disagree by design, and the disagreement is the interesting number.

Dashboards that live in the repository

Two Grafana dashboards, defined as files under version control:

• substrate-health — which services are up, request rates, error ratios, 95th-percentile latency
• ads-delivery — fill rate, why candidates lost, events ingested, click-through rate, spend

"Why candidates lost" is Day 3's payoff. It is a stacked chart with one band per rejection reason. When fill rate collapses, you read the cause off whichever band grew. That is a diagnosis in one glance, and it exists only because every filter was made to name itself.

Day 4 ended at 87 tests, four services scraped by Prometheus.

Day 05 · traffic-simulator + the quality gate

Breaking it on purpose, for real

Four services exist and nothing uses them. Day 5 builds a simulator that generates realistic viewers, requests adverts, and reports impressions and clicks back — continuously, at a controlled rate, from a fixed random seed so any run can be replayed exactly.

Then it breaks things. Five failure modes, switchable live over an API:

flowchart LR
    OP["POST /scenario<br/>bad_config_deploy"] --> SIM["traffic-simulator"]
    SIM -->|"PATCH every campaign<br/>targeting → Antarctica"| CS["campaign-service"]
    SIM -->|"keeps requesting ads"| ADS["ad-decision-service"]
    ADS -->|"reads the changed config"| CS
    ADS --> NF["targeting_mismatch<br/>fill rate 43% → 2%"]
    NF --> PROM["Prometheus"]
    PROM --> GRAF["Grafana<br/>the incident, visible"]
    GRAF -.->|"Level 3"| RCA["ops agent finds<br/>the real cause"]
      

I could have built this in an afternoon with a flag each service checks. I spent the extra day on the honest version because of what happens on Day 18: an agent asked to find the root cause of a fake outage can only ever find the fake, and I would have spent the rest of the month grading it against a fixture I wrote myself.

Because the damage is real, recovery has to be real too. The steady scenario does not flip a flag back — it restores the original configuration through the same public API. Which is exactly the remediation an operations agent should later recommend, making it a genuine rehearsal rather than an undo button.

The first published number

The Level 0 quality gate: eleven automated checks against the running system. Five service health checks, one confirming Prometheus is collecting from all four, and one per failure mode — each verifying the failure produces the signal it claims to.

Its decision logic is pure and separately unit-tested; the live run only supplies the numbers. That is what makes it trustworthy in both directions — it cannot pass with the platform switched off, and it cannot fail because a test fixture drifted from reality.

Result: 11/11 — 100%. The first real figure on the scoreboard, and the gate leaves the platform healthy when it exits.

Level 0 complete: 141 tests, five services, real traffic, real incidents.

Day 06 · Document ingestion

Everything built so far becomes knowledge

Level 1 begins. The source code, the five decision records, the daily logs, the runbook, the API contracts, the Compose and Grafana configuration — all of it becomes the corpus.

This is the context layer, and it is the part of the job posting I was most interested in. Giving an AI your team's actual accumulated knowledge, so it answers from your decisions rather than from generic internet training. Ask a normal AI why this project uses Compose and it will recite general trade-offs. Ask one grounded in this corpus and it should quote ADR-0001 and name its trigger.

flowchart LR
    RULES["14 ordered rules<br/>what belongs in the corpus"] --> DISC["discover<br/>63 files claimed"]
    APPS["4 FastAPI app objects<br/>asked directly for their contracts"] --> SPECS["4 API contracts<br/>generated, not scraped"]
    DISC --> LOAD["load<br/>title · component · attributes"]
    LOAD --> HASH["normalise line endings<br/>then fingerprint (sha256)"]
    SPECS --> HASH
    HASH --> UP["store<br/>added / updated / unchanged"]
    UP --> PRUNE["prune<br/>anything whose source is gone"]
    PRUNE --> CORPUS["corpus.jsonl<br/>67 documents · 550 KiB"]
      

Contracts read from the code, not the network

Each service publishes an API contract. The obvious way to collect them is to ask the running services over HTTP.

That would mean the corpus depends on which containers happen to be running, cannot be rebuilt on a build server, and quietly differs between machines. Instead the contracts are generated by loading the application code and asking it directly — identical bytes on every machine, including one with Docker switched off.

Fingerprints, so nothing is done twice

Every document gets a content hash — a fingerprint that changes completely if a single character changes. Re-run the pipeline on an unchanged repository and the answer is "67 unchanged, nothing written."

That is what makes tomorrow's embedding step affordable to repeat, because tomorrow every changed document costs money.

Provenance, so every answer can be checked

{
  "doc_id": "docs/adr/0005-real-failures-not-mocked.md",
  "content_hash": "sha256:d42a03d4128146c2...",
  "provenance": {
    "source_type": "adr",
    "component":   "docs",
    "title":       "ADR-0005: Failures are injected by changing real...",
    "line_count":  37,
    "attributes":  { "adr_number": "0005" }
  }
}

The identifier is the file path itself — a citation someone can paste into an editor.

Day 6 ended at 201 tests, 67 documents.

Day 07 · Chunking, embeddings, vectors

Teaching it to find things by meaning

A whole document is the wrong unit for retrieval. One API contract is 851 lines — handing an agent all of it to answer one question wastes most of its attention.

Two problems: cut documents into useful pieces, and make those pieces findable by meaning rather than by keyword.

Cutting where the content already has seams

The naive approach cuts every 2,000 characters, which slices functions in half and separates a heading from the text under it. Instead each kind of document is cut where it already has natural boundaries:

flowchart TB
    DOC["A document"] --> R{"What kind?"}
    R -->|"Python"| PY["Split at functions and classes<br/>decorators stay attached<br/>anchor: the dotted symbol name"]
    R -->|"Markdown"| MD["Split at headings<br/>heading line stays in the piece<br/>anchor: the full heading path"]
    R -->|"API contract"| OA["Split per endpoint<br/>anchor: POST /campaigns"]
    R -->|"anything else"| WIN["Fixed window<br/>anchor: none"]
    PY & MD & OA & WIN --> CAP["Cap oversized pieces,<br/>keeping the parent anchor"]
      

Every piece keeps an anchor — the name of the thing it is:

ADR-0005 › Alternatives considered          // a heading path
substrate.traffic_simulator.driver.tick       // a dotted symbol
POST /ad-request                              // an endpoint

A piece that cannot name itself can be returned but not defended. That turns out to be measurable:

More pieces, each smaller and each able to say what it is. The naive baseline scores zero by construction — that is not a rigged comparison, it is the actual cost of splitting on a character count, stated as a number.

What an embedding actually is

An embedding converts text into a long list of numbers — a position in a space with hundreds or thousands of dimensions — arranged so that text with similar meaning lands nearby.

"Frequency capping" and "how often a viewer sees an advert" share no words at all. A good embedding still places them close together. Searching then becomes: convert the question to a position, return whatever is nearest.

Different models do this with very different quality. Rather than picking one on faith, BELLWETHER runs four behind a single interchangeable interface and measures them.

The fourth is worth explaining. hashing is a keyword-only method with no model at all — it exists so the test suite can assert real retrieval behaviour on a build server with no API key and no downloads. It is genuinely useful and genuinely limited, which makes it the perfect control.

What two cents buys

The test: "how often can the same viewer be shown one advert?" — a question containing none of the words frequency, cap, member, or impression.

Gemini understood the question. The local model found the right neighbourhood. The keyword-only baseline found nothing meaningful, because not one word of the question appears in the answer.

That gap is the entire argument for paying for embeddings — measured on this corpus, not quoted from a vendor's chart.

The tools this level added, and what each beat

Day 7 ended at 289 tests, 585 pieces, three engines measured.

Day 08 · Hybrid retrieval, reranking, an honest number

The day the prediction was wrong

Day 7 could find pieces that mean what you asked. It could not reliably find pieces that are named what you asked. The embedding of budget_micros lands near “budget” and “spending” — and no nearer the one piece that defines the field than the twenty that merely discuss money.

So Day 8 added keyword search (BM25) beside the vector search, fused the two rankings, reranked the result — and then did the part the other three exist to justify: measured whether any of it actually helped.

flowchart TB
    Q["A question"] --> D["Vector search<br/>finds meaning"]
    Q --> L["BM25<br/>finds names"]
    D & L --> F["Reciprocal Rank Fusion<br/>rank position only, never the score"]
    F --> RR["Rerank<br/>free heuristic · or an LLM"]
    RR --> TOP["The results"]
      

The prediction, written down before the code

The design spec pre-registered a claim in git, timestamped before a line of retrieval code existed: hybrid’s advantage would come almost entirely from identifier queries — questions like where is budget_micros enforced — and on conceptual questions it would be flat or slightly worse than vector search alone.

Writing the prediction down first is the whole point. A number is only honest if you cannot move the target after you have seen it.

The answer key nobody could rig

Before any system ran, 26 questions were committed. Then every configuration’s top results were pooled together, shuffled, and stripped of any sign of which system produced them, and each of the 475 question–piece pairs was graded 0, 1 or 2 by hand. The grader never saw which engine surfaced a piece, or where it ranked. The file is committed and pinned to the exact corpus revision it was judged against, so anyone can check the marking.

There was no aggregate hybrid win to explain. Vector search alone beat every hybrid configuration. Adding the keyword side lowered the headline score.

And the prediction failed exactly where it was most specific. BM25 was supposed to own the identifier category — its home ground, the literal-name questions. It came last:

Gemini’s embeddings are good enough on this corpus that they win the one category keyword search was built to dominate. What I would have published without the answer key: “hybrid retrieval, with reranking.” It would have been slower, more complex, and worse — and it would have looked like progress.

One honest boundary on the result: this is a finding about this corpus — 708 well-structured pieces of ADRs, devlogs and typed Python, embedded by a frontier model. A larger, messier, more jargon-dense corpus is exactly where keyword search earns its keep. The number is a baseline, not a law.

Day 8 ended at 410 tests, 708 pieces, six configurations measured — and one prediction, published wrong.

Day 09 · AST graph, reconciliation, click-to-focus

The graph that checks its own claims

Retrieval, from Day 7 and Day 8, answers what does this code say? It has no answer for what breaks if campaign_service changes? — a question about structure, not meaning. So Day 9 stops searching the text and starts reading the shape underneath it.

A walker built on Python’s own ast module reads every service’s source and produces a graph: a node for every service, endpoint, Pydantic model and external dependency, and an edge for every relationship between them — a service exposes an endpoint, defines a model, imports a module, depends_on a package. One edge kind is different from the rest: calls. It is the graph noticing that one service’s HTTP client is pointed at a URL that is supposed to be a live route somewhere else — a claim, not yet a fact.

Reconciliation: the graph auditing itself

So it checks. Reconciliation walks every calls edge and confirms the route it names is an endpoint node that actually exists in the graph, rather than a string that merely looks like one. A call pointed at a route that was renamed, removed, or never existed comes back dangling, printed by name — not buried in a diff nobody reads.

$ python -m bellwether.context.graph --reconcile

7/7 call paths resolved (100%)
isolated: platform

Today: 45 nodes, 74 edges — 25 endpoints, 9 services, 8 external dependencies, 3 models — and among the edges, 4 calls edges covering 7 call paths, all 7 resolved, nothing dangling. One name comes back isolated: platform, the Level 0 gate script from Day 5. It is a command-line entry point, not a module any service imports or calls into, so the extractor correctly finds nothing wired to it. Not a bug — a script and a service are different shapes, and the graph tells the two apart instead of guessing.

graph LR
  subgraph n_service_ad_decision_service_ef0d50ac["ad_decision_service"]
    n_endpoint_ad_decision_service_GET__health_f0a25609(["GET /health"])
    n_endpoint_ad_decision_service_GET__metrics_a43ef786(["GET /metrics"])
    n_endpoint_ad_decision_service_POST__ad_request_41a28ab8(["POST /ad-request"])
  end
  subgraph n_service_campaign_service_e8506251["campaign_service"]
    n_endpoint_campaign_service_DELETE__campaigns____d07f140b(["DELETE /campaigns/{}"])
    n_endpoint_campaign_service_GET__campaigns_caa4df2c(["GET /campaigns"])
    n_endpoint_campaign_service_GET__campaigns____71df29ed(["GET /campaigns/{}"])
    n_endpoint_campaign_service_GET__campaigns____creatives_c2d77467(["GET /campaigns/{}/creatives"])
    n_endpoint_campaign_service_GET__health_1e1ac476(["GET /health"])
    n_endpoint_campaign_service_GET__metrics_e482f5e5(["GET /metrics"])
    n_endpoint_campaign_service_PATCH__campaigns____069be044(["PATCH /campaigns/{}"])
    n_endpoint_campaign_service_POST__campaigns_6d2a9e35(["POST /campaigns"])
    n_endpoint_campaign_service_POST__campaigns____creatives_58e965f9(["POST /campaigns/{}/creatives"])
    n_model_campaign_service_Campaign_c979140a["Campaign"]
    n_model_campaign_service_Creative_7378759d["Creative"]
  end
  subgraph n_service_event_service_de0f72ab["event_service"]
    n_endpoint_event_service_GET__campaigns____delivery_5d703263(["GET /campaigns/{}/delivery"])
    n_endpoint_event_service_GET__delivery_420b8d39(["GET /delivery"])
    n_endpoint_event_service_GET__events_0513aa23(["GET /events"])
    n_endpoint_event_service_GET__health_cec6f042(["GET /health"])
    n_endpoint_event_service_GET__metrics_9d97db47(["GET /metrics"])
    n_endpoint_event_service_POST__events_6b7ade97(["POST /events"])
    n_model_event_service_AdEvent_b8129f81["AdEvent"]
  end
  subgraph n_service_shared_ac61e27b["shared"]
  end
  subgraph n_service_traffic_simulator_a4adaf7e["traffic_simulator"]
    n_endpoint_traffic_simulator_GET__health_647c3354(["GET /health"])
    n_endpoint_traffic_simulator_GET__metrics_ca76d008(["GET /metrics"])
    n_endpoint_traffic_simulator_GET__scenarios_b1a8a38a(["GET /scenarios"])
    n_endpoint_traffic_simulator_GET__status_5d0751d8(["GET /status"])
    n_endpoint_traffic_simulator_POST__control_f34a452b(["POST /control"])
    n_endpoint_traffic_simulator_POST__scenario_739f882d(["POST /scenario"])
    n_endpoint_traffic_simulator_POST__seed_e15bea1a(["POST /seed"])
  end
  n_service_ad_decision_service_ef0d50ac -->|"GET /campaigns"| n_service_campaign_service_e8506251
  n_service_ad_decision_service_ef0d50ac --> n_service_shared_ac61e27b
  n_service_campaign_service_e8506251 --> n_service_shared_ac61e27b
  n_service_event_service_de0f72ab --> n_service_shared_ac61e27b
  n_service_traffic_simulator_a4adaf7e -->|"POST /ad-request"| n_service_ad_decision_service_ef0d50ac
  n_service_traffic_simulator_a4adaf7e -->|"GET /campaigns, PATCH /campaigns/{}, POST /campaigns, POST /campaigns/{}/creatives"| n_service_campaign_service_e8506251
  n_service_traffic_simulator_a4adaf7e -->|"POST /events"| n_service_event_service_de0f72ab
  n_service_traffic_simulator_a4adaf7e --> n_service_shared_ac61e27b
        

7 / 7 call paths resolved — no drift

Day 9 ends at 45 nodes, 74 edges, 7 of 7 call paths reconciled — and 448 tests passing, 38 of them new.