The Quadrant Gate: Enforcing Coverage Before Generation
The four-quadrant discipline from the Pro track only holds if something enforces it. This lesson wires coverage into the pipeline as a checkpoint that reads the vault and blocks before generation even starts.
Coverage is a rule until something enforces it
The Pro track's quadrant discipline is simple to state and easy to drift from: four non-overlapping subtopics, at least six posts a week, at least one per quadrant per week. A person running that by hand can hold the line for a while and then, without noticing, spend three weeks in a row leaning on the quadrant that's easiest to write for. Nothing about a written rule stops that drift — a rule only holds when something is actually checking it, every time, before the thing it's supposed to prevent has already happened.
For the autonomous operation, that something is the quadrant gate: a checkpoint wired directly into the pipeline, sitting between the generation lane and the grader.
Its position is deliberate. The gate runs after a draft exists but before that draft costs anything further — before the grader's LLM-as-judge rubric spends time and inference scoring content that coverage math has already decided shouldn't advance. A draft the gate rejects goes back to the generation lane with a specific request instead of a vague failure: produce something for the quadrant that's actually starved, not another draft for the one that's already fed.
Reading the window
The gate's entire decision rests on one computation: a rolling count of postings per quadrant over the trailing seven days, recalculated fresh every time the gate runs, not reset at a fixed calendar boundary. A rolling window means a quadrant posted six days ago still counts today, and a quadrant that hasn't posted in the last seven days shows up as genuinely starved regardless of what day of the week it happens to be.
Four quadrants, one snapshot: Expertise sitting at three posts is overfed relative to the others in the same window. Case Studies at zero is starved. Systems and Industry POV, each at one, are covered but not excessive. The gate's action column in that table is the whole function in miniature — block the overfed quadrant's new drafts, admit the covered ones, and specifically request the starved one from the strategist on the next planning pass.
The exact condition the gate blocks
It's worth being precise about what "overfed" means here, because the gate isn't ranking quadrants against each other or enforcing some absolute cap on any single quadrant in isolation. It's checking one narrow, specific condition every time a draft comes through: would admitting this draft mean stacking more coverage onto a quadrant that already has some, while a different quadrant sits at zero in the same window?
That framing matters because it changes what counts as a violation. A quadrant with three posts isn't automatically blocked just for having three posts — it's blocked specifically when a starved quadrant exists at the same time. If every quadrant currently has at least one post, even an unevenly distributed week admits everything, because nothing is actually starved. The gate isn't trying to make coverage perfectly even; it's trying to make sure no quadrant goes to zero while another one keeps growing.
What a rejection actually costs
The gate has two jobs at two different points in the pipeline, and the cost profile is different for each. nextQuadrant runs before generation — it's the advisory half, steering the strategist toward the starved quadrant so an overfed draft rarely gets produced in the first place. When the steering works, a rejection costs nothing, because the draft that would have been rejected was never generated. admitDraft is the enforcement half, and it runs where the diagram shows: after a draft exists, before it's graded. A rejection there does forfeit the generation cost already spent on that draft — but it still saves the grader's LLM-as-judge pass, and more importantly it refuses to let the vault accumulate coverage the strategist should never have requested. The two halves are cheap insurance against each other: steering keeps enforcement rare, and enforcement keeps a mis-steered (or race-conditioned) draft from costing anything further downstream.
Determinism is not optional
nextQuadrant's tie-breaking rule — lowest count wins, first quadrant in the given order wins any tie — looks like a minor implementation detail until you consider what happens without it. A gate that resolved ties randomly would recommend a different quadrant on two calls against the identical vault state, which makes the system impossible to reason about from the outside: a strategist calling the gate twice in a row, or a human debugging why a particular quadrant got skipped, needs the answer to be the same answer every time the input is the same. Determinism isn't a nicety here — it's what makes the gate's decisions auditable at all. The same discipline resurfaces two lessons ahead in the upcycle scheduler, which has to make an equally repeatable call about which evergreen asset is due for its next repost.
Why the window rolls instead of resets
The coverage snapshot recalculates against whatever the trailing seven days actually contain, not against a fixed Monday-to-Sunday calendar week. That distinction avoids an artificial cliff: under a fixed-week reset, a quadrant posted on the last day of one week reads as fully covered right up until midnight, then instantly reads as starved the moment the new week begins — even though nothing about the actual posting cadence changed. A rolling window means the gate's decision always reflects real recent activity, not an accident of which day happens to be current when the check runs.
Implement nextQuadrant and admitDraft in this challenge, and the strategist and the gate will both be running on code you wrote — one recommending what's due, the other refusing anything that would make the recommendation meaningless before it's even acted on.