systems lab / learning guideSYNTHETIC MODEL · LOGICAL TICKS
Review capacity · model v1
Where does work wait when execution gets faster?
We follow the same 24 tasks through three admission policies, with one reviewer. The aim is to learn what extra execution capacity changes, and why a shorter review queue can leave the total time to a decision unchanged.
4× → 1.33×Execution slots versus decisions completed by tick 60.
8 = 8B and C deliver the same number of decisions at the common horizon.
15 → 1Review queue under WIP 3. Admission waiting rises from 0 to 13.
01 / Define the boundary
Follow work before and after admission
Scroll figures sideways to inspect their labels on a narrow screen.
Work in progress, or WIP, means tasks we have admitted but have not yet decided. It includes execution, waiting for review and review itself. Tasks waiting for admission sit outside the WIP limit. We still count them when we measure the whole system.
The model keeps two queues in memory. Eight execution ticks represent a workflow without timing actual agents. Its synthetic reviewer is separate from the playground's Reviewer agent.
02 / Compare a common horizon
Compare decisions with review capacity held fixed
Keep arrivals and service demand fixed. A has one execution slot, B has four, and C adds an admitted-WIP cap of three. Compare decisions and every unfinished task at tick 60.
All 24 tasks have arrived by tick 46. Four slots are a capacity ceiling, not a promise that all four stay busy.
Inclusive horizon: tick 60. Full drain: the same 24-task cohort.
Policy
Slots / WIP
Decided / pending
Admission queue
Review queue
Full drain
The WIP cap changes where work waits. B and C both have 16 unfinished tasks at tick 60. C holds more tasks before admission and fewer before review. We need both queues to judge whether total waiting has changed.
03 / Inspect the saved trace
Inspect the task states at each tick
Select a policy and seek to a tick. Each tile is a task from the saved model trace. These controls change this documentation view only.
DOCUMENTATION REPLAY · NO LIVE AGENTS
1 · Admission queue
Outside admitted WIP
Execution slots
2 · Review queue
Inside admitted WIP
Synthetic reviewer
One resource · accepts all
Decided tasks
Modeled decisions only
Admitted WIP: Not yet arrived: Total unfinished:
04 / Follow the full workload
Follow all 24 tasks to a decision
With four execution slots, the reviewer stays supplied after startup. WIP 3 also keeps it supplied here, while holding most waiting upstream. B and C have identical per-task decision ticks.
Each point records the state after an event, and that state holds until the next event. The dotted line marks tick 60; the curves continue until every task has a decision, which we call full drain. WIP 3 keeps the reviewer supplied in this scenario. It is not a universal optimum.
05 / Read the wait correctly
Check the time from arrival to decision
Across all 24 tasks, B and C both have median end-to-end time 58 ticks and p95 102 ticks.
Median review-queue wait changes from 44 to 4 ticks; median admission wait changes from 0 to 40 ticks.
These percentiles include all 24 tasks. The median is the middle of the ordered values; p95 describes the upper end of the distribution. Component percentiles cannot generally be added, and measuring only tasks that finish early leaves out the slower work.
06 / Connect to systems thinking
Connect the queues to stocks and flows
A queue is a stock: work that has accumulated. Arrivals, admission and review are flows that move work into or out of those stocks. The WIP cap creates a balancing rule: when all places are occupied, admission waits until a decision releases room.
Observe only the review queue and C looks much faster. Include admission waiting and decisions, and the tradeoff becomes visible.
This is our interpretation of the teaching model. The experiment is not copied from Thinking in Systems, and it does not measure a real team.
07 / Challenge the explanation
Change one assumption and compare again
1. Change only C's WIP cap from 3 to 2. Does the reviewer become starved, and does full-drain time increase?
2. Change review service from 6 to 3 ticks for every policy. Does the limiting stage move toward execution?
3. Before applying this to actual agents, define quality, rework, failures and permission-release semantics.
Questions 1 and 2 use existing scenario fields. G02 below adds fixed corrections to a separate numerical model. Real review quality and runtime behavior still need their own experiments. This page replays saved scenarios; it does not run interventions.
Limits of the A/B/C evidence
Every review accepts. Arrivals are finite and scheduled; service demand is uniform. There is no output quality, rework, fatigue, priority, failure, live model, real human approval or measured agent execution time.
No cost reduction or quality improvement was measured.
Reproduce and inspect the evidence
This page keeps a fixed copy of the data needed to explain a saved deterministic report. Original attempts remain in ignored .lab/. The replay is separate from Activity, the audit journal and OpenTelemetry workflow spans.
uv run --locked systems-lab experiment review-capacity \
--scenario experiments/review-capacity/scenario.json
With identical input, each attempt gets a new ID and manifest time, while the report bytes and SHA-256 hash stay the same. A privileged owner can rewrite the local files and their hashes. These files are not write-once, read-many (WORM) storage.
Scenario SHA-256
Report SHA-256
G02 / When a review requests changes
A lower average, fifteen tasks finishing later
Six of these 24 tasks need a correction. We compare the order in which work becomes ready for review with giving returning corrections priority. The workload and capacity stay the same.
Complete-cohort results, in logical ticks. Lower times for five tasks outweigh smaller delays for fifteen others.
Measure
Arrival order (FIFO)
Corrections first
Both runs consume 216 execution-slot ticks and 180 reviewer ticks. Tasks 4, 8, 12, 16, 20 and 24 each need one correction. Every second review accepts. These are chosen model assumptions.
Compare the two orders at the same moment
Move the clock to see accepted and unfinished tasks. Select a task to follow both of its journeys below. The summary above always covers all 24 completed tasks.
Arrival order (FIFO)
accepted · unfinished
Waiting for execution
Executing
Waiting for review
In review
not yet arrived
Corrections first
accepted · unfinished
Waiting for execution
Executing
Waiting for review
In review
not yet arrived
WaitingInitial executionCorrectionReview
Selected task: complete timings, independent of the current clock position.
Policy
Arrival
First review starts
Ready-to-first-review wait
Accepted
Arrival to acceptance
At tick 182, the priority reviewer has nothing ready while task 24 is corrected. Review resumes at 186 and finishes at 192. FIFO covers that correction with other reviews and finishes the batch at 188.
Inspect all 24 outcomes
Acceptance ticks from the same saved traces. Select any task to inspect its timeline.
Task
Correction need
FIFO acceptance
Priority acceptance
Effect of priority
See the full comparison figure
Negative differences mean earlier acceptance with priority. The six starred tasks require corrections. On a narrow screen, scroll the figure sideways.Model assumptions and reproducible evidence
24 tasks arrive every two ticks. Four execution slots take eight ticks for initial work and four for a correction. One reviewer takes six ticks per visit. There is no admission limit. FIFO orders attempts by when they become ready for review; priority selects returning corrections first. Neither policy interrupts an active review.
Corrections are prescribed and always succeed. The model has no measured quality, fatigue, varying task value or continuous arrivals. It cannot establish real-team productivity or a general best review policy.
make review-rework-demo
Scenario SHA-256
Report SHA-256
This page replays saved results locally. It makes no API calls and starts no agents. All times are logical ticks.
