# Elements of Scalable Web Development: knowledge graph
Schema version: 2. Authored content revision: `9950e02439aeef7bf144499deaf43293d0dfe318644d7a29738225b047e4f3ed`.
46 concepts, 110 explained connections, and 32 reading locations.
[Agent guide](https://scalableweb.dev/concepts/agent-guide.md) · [JSON](https://scalableweb.dev/concepts/graph.json) · [Visual explorer](https://scalableweb.dev/concepts/)
Authored teaching connections with explicit directed or undirected semantics. For direction=directed, read source → label → target. For direction=undirected, endpoint order has no meaning. The label and explanation establish the claim, not the arrow alone; direction does not imply a prerequisite. A concept is discussed in a reading. Co-occurrence does not create a graph edge. A curated guide to the book, not an exhaustive account of possible connections. Curated concept-to-resource mappings, not new graph edges. Graphics are authored illustrations. Demo PNGs are static previews of default views, not live execution or measured evidence; current behavior and saved input state can differ. Prediction prompts deliberately omit a model answer. Optional task-led activities linked to concepts, not new graph edges or required deliverables. The catalog contains starting URLs; authored scenarios and worked reasoning are separate resources. Optional guidance for the student's agent, not site-enforced behavior or an advertisement of client rendering capabilities. The authored material remains the reference for agent-created adaptations.
## Concepts
### [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary)
ID: `measurement-boundary`. Group: Evidence.
**Definition:** The declared start, end, population, and observation window of a measurement. A boundary determines which work and waiting the result includes.
**Usage in this book:** Measurement boundary is the book's descriptive label for a measurement's scope and timing convention, rather than a separate formal model.
**Assumptions:** Comparisons and equations must describe compatible work, units, and windows. Record failed, rejected, and unfinished work alongside successful completions.
**Worked example:** An event takes 20 ms inside the database but 200 ms from submission to visible activity. The database timer leaves out network, application, queue, and rendering time; it cannot establish the end-to-end latency.
**Common mistake:** A faster component proves a faster user journey. Work outside the measured component can dominate or become slower.
**Teaching passages:**
- [Measurement: declare the protocol](https://scalableweb.dev/chapters/benchmarking/#benchmark-to-test-a-claim): Specify what starts and ends each observation.
- [Scaling: test where the cost moved](https://scalableweb.dev/chapters/scaling/#implement-the-smallest-justified-response): Keep the original outcome visible after changing a component.
**Readings:**
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [B · Reproducible environments](https://scalableweb.dev/appendices/reproducible-environments/)
- [E · Scalability models](https://scalableweb.dev/appendices/scalability-models/)
- [Part I · Establish](https://scalableweb.dev/parts/establish/)
- [Project · Introduction](https://scalableweb.dev/project/introduction/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Assessment](https://scalableweb.dev/project/grading/)
**Graphics and experiments:**
- [Measurement boundary: connections](#resource-graph-measurement-boundary)
- [From pressure to bounded evidence](#resource-pressure-evidence)
- [Tail latency simulator](#resource-demo-tail-latency-simulator)
- [Browser performance workbench](#resource-demo-browser-performance-workbench)
- [OpenTelemetry trace explorer](#resource-demo-opentelemetry-trace-explorer)
- [Reliability chain lab](#resource-demo-reliability-chain-lab)
- [Latency budget map](#resource-demo-latency-budget-map)
### [Throughput](https://scalableweb.dev/concepts/#throughput)
ID: `throughput`. Group: Evidence.
**Definition:** The rate of completed work at a declared boundary. Useful throughput counts completions that meet the stated correctness and quality criteria.
**Assumptions:** Name the completion event, units, and window. Offered, admitted, and completed work are different rates, especially during overload or asynchronous processing.
**Worked example:** A service acknowledges 150 events/s while its worker makes 100 events/s visible. Acknowledgment throughput is 150/s; visible-event throughput is 100/s. If all admitted events remain pending until processed, backlog grows by 50 events/s.
**Common mistake:** More acknowledgments or generated changes mean more useful output. Pending events and unreviewed changes have not yet crossed their completion boundary.
**Teaching passages:**
- [Measurement: count outcomes separately](https://scalableweb.dev/chapters/benchmarking/#check-whether-the-generator-hides-overload): Separate offered, admitted, completed, and timed-out work.
- [Fleets: sequential review limits speedup](https://scalableweb.dev/chapters/agent-fleets/#amdahl-s-law-and-the-sequential-bottleneck): Measure accepted changes rather than generation activity.
**Readings:**
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [Part III · Compare](https://scalableweb.dev/parts/compare/)
- [Case · Webernetes](https://scalableweb.dev/case-studies/webernetes/)
- [Case · Temper](https://scalableweb.dev/case-studies/temper/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Compare](https://scalableweb.dev/project/compare/)
**Graphics and experiments:**
- [Throughput: connections](#resource-graph-throughput)
- [Three connected scalability loops](#resource-three-connected-loops)
- [Sequential work bound](#resource-demo-sequential-work-bound)
- [Saturation boundary lab](#resource-demo-saturation-boundary-lab)
- [Contention curve lab](#resource-demo-contention-curve-lab)
**Task-led explorations:**
- [Vary human work in progress](https://scalableweb.dev/explore/human-work-in-progress/agent.md): Keep the same worker limit while changing how many unfinished changes enter the workflow. Plan a bounded comparison.
### [Latency](https://scalableweb.dev/concepts/#latency)
ID: `latency`. Group: Evidence.
**Definition:** Elapsed time between a declared start and completion event. End-to-end latency can include waiting, processing, network transfer, and rendering.
**Assumptions:** State the timing boundary and population. Averages and percentiles answer different questions; Little's Law uses an average, not p95. A timeout is a deadline lower bound, not an observed completion time.
**Worked example:** Of 20 requests, 18 take 40 ms and two take 240 ms. Mean latency is 60 ms; nearest-rank p95 is 240 ms. A goal below 120 ms passes for the mean and fails for p95.
**Common mistake:** A lower average guarantees a better experience for everyone. A slow minority, failures, or work omitted from the timer can be hidden by that average.
**Teaching passages:**
- [Measurement: calculate the average and tail](https://scalableweb.dev/chapters/benchmarking/#exercise-measurement-prediction): Compare a mean with a declared percentile convention.
- [Scaling: latency and geography](https://scalableweb.dev/chapters/scaling/#latency-and-geography): Follow time across network and consistency boundaries.
**Readings:**
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
**Graphics and experiments:**
- [Latency: connections](#resource-graph-latency)
- [Web architecture lens](#resource-demo-web-architecture-lens)
- [Tail latency simulator](#resource-demo-tail-latency-simulator)
- [Browser performance workbench](#resource-demo-browser-performance-workbench)
- [OpenTelemetry trace explorer](#resource-demo-opentelemetry-trace-explorer)
- [Latency budget map](#resource-demo-latency-budget-map)
### [Queue](https://scalableweb.dev/concepts/#queue)
ID: `queue`. Group: Operations.
**Definition:** Work waiting for a resource or a next stage. A queue may contain events awaiting a worker or changes awaiting review; work in progress also includes work currently being processed.
**Assumptions:** Name what enters, what leaves, capacity, and the policy for full or abandoned work. A sustained arrival rate above completion capacity cannot produce a stable backlog.
**Worked example:** Admitting 120 events/s to a worker completing 100 events/s adds 20 pending events/s under a constant-rate model without loss or retries. Six changes arriving per hour with four accepted per hour add two unfinished changes per hour if none leave through rejection or withdrawal. These illustrative rates are not measured capacity.
**Common mistake:** Adding a queue creates processing capacity. It can absorb a bounded burst or decouple stages, but it also creates waiting, recovery, and admission obligations.
**Teaching passages:**
- [Measurement: transfer the boundary to review work](https://scalableweb.dev/chapters/benchmarking/#exercise-measurement-transfer): Apply the same relationship with different work and units.
- [Recap: a queue changes three loops](https://scalableweb.dev/chapters/recap/#how-the-loops-affect-one-another): Connect application backlog to implementation and review work.
**Readings:**
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
**Graphics and experiments:**
- [Queue: connections](#resource-graph-queue)
- [Three connected scalability loops](#resource-three-connected-loops)
- [Saturation boundary lab](#resource-demo-saturation-boundary-lab)
**Task-led explorations:**
- [Vary human work in progress](https://scalableweb.dev/explore/human-work-in-progress/agent.md): Keep the same worker limit while changing how many unfinished changes enter the workflow. Plan a bounded comparison.
### [Saturation](https://scalableweb.dev/concepts/#saturation)
ID: `saturation`. Group: Operations.
**Definition:** The point at which a limiting resource or capability can no longer absorb more pressure while maintaining the declared goal. In this book, the limit can be a physical resource, quota, dependency, or human review capacity.
**Usage in this book:** The book uses saturation across technical and human limits, drawing on resilience engineering's treatment of finite adaptive capacity. Name the limiting capacity in each example; resource utilization alone does not describe every limit.
- [Woods: the theory of graceful extensibility](https://link.springer.com/article/10.1007/s10669-018-9708-3)
**Assumptions:** Identify the workload, maintained goal, and limiting resource. Expanding one limit can expose another; rejection or retries can change the observed rates.
**Worked example:** A request visits stages with capacities of 180, 110, 150, and 130 requests/s. With one visit per stage and no retries, the ceiling is 110/s. Raising that stage to 150/s moves the limit to the 130/s stage.
**Common mistake:** Adding capacity to one component removes the system's limit. Another stage can bind first, and a quicker acknowledgment can conceal a growing backlog.
**Teaching passages:**
- [Pressure: name the binding limit](https://scalableweb.dev/chapters/reality/#from-failed-assumptions-to-useful-signals): Connect a disturbance to the limit and its signals.
- [Scaling: move the saturation boundary](https://scalableweb.dev/chapters/scaling/#name-the-saturation-boundary): Test which constraint appears after an intervention.
**Readings:**
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
**Graphics and experiments:**
- [Saturation: connections](#resource-graph-saturation)
- [From pressure to bounded evidence](#resource-pressure-evidence)
- [An external quota becomes the availability boundary](#resource-dependency-failure)
- [Saturation boundary lab](#resource-demo-saturation-boundary-lab)
- [Contention curve lab](#resource-demo-contention-curve-lab)
### [Little's Law](https://scalableweb.dev/concepts/#little-law)
ID: `little-law`. Group: Models.
**Definition:** For a stable conserved-work boundary, average work in progress L equals completion rate λ multiplied by average time in the boundary W: L = λW.
**Assumptions:** Use the same work, boundary, compatible windows, and units. Arrivals and completions must approximately balance over a suitable observation period. Include waiting when it is inside the boundary.
**Worked example:** At 20 completed events/s and 0.5 s per event, expected average work in progress is 10 events. At four accepted changes/hour and three hours per change, it is 12 changes. These are illustrative steady-state calculations, not measured capacity.
**Common mistake:** A mismatch proves the database is the bottleneck, or matching values prove the system is healthy. The relationship checks consistency; it does not isolate a cause or establish an acceptable waiting time.
**Teaching passages:**
- [Measurement: check compatible averages](https://scalableweb.dev/chapters/benchmarking/#check-measurements-against-a-model): Calculate the relationship and inspect what a mismatch means.
- [Scaling: choose the question before the equation](https://scalableweb.dev/chapters/scaling/#exercise-scaling-model-choice): Distinguish consistency of flow from a bound on parallel speedup.
**Readings:**
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [E · Scalability models](https://scalableweb.dev/appendices/scalability-models/)
- [Project · Challenge](https://scalableweb.dev/project/challenge/)
**Graphics and experiments:**
- [Little's Law: connections](#resource-graph-little-law)
### [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law)
ID: `amdahl-law`. Group: Models.
**Definition:** For a fixed workload with parallelizable fraction p and n workers, ideal speedup is S(n) = 1 / ((1 − p) + p/n). The sequential fraction bounds the gain.
**Assumptions:** Hold the workload and sequential fraction fixed. Assume ideal division of parallel work with no added coordination cost. The result is an upper bound under those assumptions.
**Worked example:** If 80% of baseline work can run in parallel and 20% remains sequential, four workers give ideal speedup 1 / (0.2 + 0.8/4) = 2.5. Even infinitely many workers cannot exceed 5× in this model.
**Common mistake:** Four agents guarantee four times the accepted output. Review or integration that must remain sequential limits fixed-task speedup; added coordination cost can reduce the gain further. Ongoing accepted-change throughput requires its own measurements.
**Teaching passages:**
- [Fleets: calculate the sequential bound](https://scalableweb.dev/chapters/agent-fleets/#amdahl-s-law-and-the-sequential-bottleneck): Account for integration and review in the workload.
- [Scaling: choose between the two laws](https://scalableweb.dev/chapters/scaling/#exercise-scaling-model-choice): Choose a model by the question it can answer.
**Readings:**
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [E · Scalability models](https://scalableweb.dev/appendices/scalability-models/)
**Graphics and experiments:**
- [Amdahl's Law: connections](#resource-graph-amdahl-law)
- [Sequential work bound](#resource-demo-sequential-work-bound)
- [Contention curve lab](#resource-demo-contention-curve-lab)
### [Development friction](https://scalableweb.dev/concepts/#development-friction)
ID: `development-friction`. Group: Development.
**Definition:** The resistance a team encounters while setting up, understanding, changing, testing, reviewing, deploying, or operating a system.
**Usage in this book:** Development friction is a descriptive umbrella for observed effort and waiting. The course's setup, comprehension, change, and protective-friction categories organize an audit; they are not a standardized productivity score.
**Assumptions:** Locate a concrete blockage and the boundary it crosses. Some friction protects a named risk; a commitment is not automatically technical debt.
**Worked example:** Adding an event category requires finding the HTTP contract, changing validation and stored data, updating the feed's cache key, and checking deployment compatibility. Record where effort and waiting accumulate before choosing an intervention.
**Common mistake:** All friction should be removed, or faster generation removes it. Validation and release gates can be protective, while generation can move effort into comprehension, review, and operation.
**Teaching passages:**
- [Friction: recognize the forms](https://scalableweb.dev/chapters/friction/#recognize-where-friction-appears): Distinguish setup, comprehension, change, and protective friction.
- [Friction: find the commitment point](https://scalableweb.dev/chapters/friction/#find-the-commitment-point): Explain when a simple revert stops restoring the prior state.
**Readings:**
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
**Graphics and experiments:**
- [Development friction: connections](#resource-graph-development-friction)
### [Scalability](https://scalableweb.dev/concepts/#scalability)
ID: `scalability`. Group: Operations.
**Definition:** The ability to maintain a declared goal as a relevant pressure changes, within stated constraints.
**Usage in this book:** The book applies scalability to runtime capacity and to development work. For contributors and change, relate the claim to maintainability, evolvability, or coordination as appropriate; name the goal rather than assuming one shared measure of scale.
**Assumptions:** Name the goal, changing pressure, workload, and resources allowed to change. A scalability claim is conditional on these choices.
**Worked example:** The tracker must keep valid-event p95 below 200 ms as offered traffic doubles, without exceeding its operating budget. This is a testable claim; ‘handles many users’ is not.
**Common mistake:** Scalability means maximum traffic. Data growth, more contributors, and frequent change can also threaten the maintained goal.
**Teaching passages:**
- [Scalability: begin with the goal](https://scalableweb.dev/chapters/what-is-scalability/#begin-with-the-goal-that-must-continue-to-hold): State the property that pressure must not break.
- [Scaling: choose a response](https://scalableweb.dev/chapters/scaling/#start-with-the-pressure): Connect the changing pressure to an intervention.
**Readings:**
- [Introduction](https://scalableweb.dev/chapters/introduction/)
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [Part I · Establish](https://scalableweb.dev/parts/establish/)
- [Part III · Compare](https://scalableweb.dev/parts/compare/)
- [Case · Thesis Journey Tracker](https://scalableweb.dev/case-studies/thesis-journey-tracker/)
**Graphics and experiments:**
- [Scalability: connections](#resource-graph-scalability)
- [From pressure to bounded evidence](#resource-pressure-evidence)
- [Three connected scalability loops](#resource-three-connected-loops)
### [Scaling pressure](https://scalableweb.dev/concepts/#pressure)
ID: `pressure`. Group: Operations.
**Definition:** A change in demand, data, contributors, or rate of change that tests the system's ability to maintain its goal.
**Usage in this book:** Scaling pressure is the book's organizing label. Demand, data, contributors, and change are four useful dimensions for this course, not an exhaustive or universally adopted taxonomy.
**Assumptions:** Separate the pressure from its symptom and from the proposed response. Describe the distribution of work, not only its total volume.
**Worked example:** A reconnect burst increases event arrivals while the database size stays constant. A growing activity history can slow queries even with unchanged traffic.
**Common mistake:** ‘We need caching’ names the pressure. It names a response whose relevance still needs evidence.
**Teaching passages:**
- [Scalability: four pressures](https://scalableweb.dev/chapters/what-is-scalability/#four-pressures-organize-the-course): Distinguish demand, data, contributors, and change.
- [Pressure: identify the binding limit](https://scalableweb.dev/chapters/reality/#from-failed-assumptions-to-useful-signals): Trace a disturbance to its signals and limit.
**Readings:**
- [Introduction](https://scalableweb.dev/chapters/introduction/)
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [Part II · Challenge](https://scalableweb.dev/parts/challenge/)
- [Project · Challenge](https://scalableweb.dev/project/challenge/)
**Graphics and experiments:**
- [Scaling pressure: connections](#resource-graph-pressure)
- [From pressure to bounded evidence](#resource-pressure-evidence)
- [An external quota becomes the availability boundary](#resource-dependency-failure)
- [Three connected scalability loops](#resource-three-connected-loops)
- [Saturation boundary lab](#resource-demo-saturation-boundary-lab)
- [Orchestration control loop](#resource-demo-orchestration-control-loop)
### [Trade-off](https://scalableweb.dev/concepts/#trade-off)
ID: `trade-off`. Group: Architecture.
**Definition:** A choice that improves one desired property while imposing a cost, risk, or obligation elsewhere.
**Assumptions:** State which goal improves, who pays the cost, and under which conditions the choice remains worthwhile. Compare alternatives under compatible conditions.
**Worked example:** Acknowledging events before processing shortens acknowledgment latency, but creates a pending state, queue, drain procedure, and a second completion boundary.
**Common mistake:** A faster benchmark establishes the best design. Correctness, recovery, operating cost, and maintainability may change the decision.
**Teaching passages:**
- [Scaling: assess the obligations](https://scalableweb.dev/chapters/scaling/#trade-offs): Explain the operating contract each response introduces.
- [Recap: make a decision](https://scalableweb.dev/chapters/recap/#turn-comparison-into-a-decision): Use evidence and constraints to justify a preference.
**Readings:**
- [Introduction](https://scalableweb.dev/chapters/introduction/)
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [Part I · Establish](https://scalableweb.dev/parts/establish/)
- [Part III · Compare](https://scalableweb.dev/parts/compare/)
- [Case · Slideotter](https://scalableweb.dev/case-studies/slideotter/)
- [Case · Thesis Journey Tracker](https://scalableweb.dev/case-studies/thesis-journey-tracker/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Project · Compare](https://scalableweb.dev/project/compare/)
- [Project · Assessment](https://scalableweb.dev/project/grading/)
**Graphics and experiments:**
- [Trade-off: connections](#resource-graph-trade-off)
- [One application, three development systems](#resource-course-progression)
- [From pressure to bounded evidence](#resource-pressure-evidence)
- [Cache decision lab](#resource-demo-cache-decision-lab)
- [Web architecture lens](#resource-demo-web-architecture-lens)
- [Latency budget map](#resource-demo-latency-budget-map)
### [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark)
ID: `benchmark`. Group: Evidence.
**Definition:** A reproducible procedure that tests a specific performance claim with a declared workload, environment, boundaries, and success criteria.
**Assumptions:** Record versions, input distribution, warm-up, concurrency or arrival schedule, repetitions, failures, and unfinished work. Check that the generator is able to offer the intended load.
**Worked example:** Run the same activity-feed workload against A, B, and C, preserving logical operation boundaries and reporting valid completions separately from overload rejections.
**Common mistake:** A single requests-per-second number ranks implementations. Different work, failure accounting, or generator behavior can make the numbers incomparable.
**Teaching passages:**
- [Measurement: test a claim](https://scalableweb.dev/chapters/benchmarking/#benchmark-to-test-a-claim): Declare the protocol before interpreting numbers.
- [Project: common workload](https://scalableweb.dev/project/#7-1-shared-baseline-workload): Hold logical operations constant across implementations.
**Readings:**
- [Introduction](https://scalableweb.dev/chapters/introduction/)
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
- [B · Reproducible environments](https://scalableweb.dev/appendices/reproducible-environments/)
- [Part I · Establish](https://scalableweb.dev/parts/establish/)
- [Case · Webernetes](https://scalableweb.dev/case-studies/webernetes/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Establish](https://scalableweb.dev/project/establish/)
**Graphics and experiments:**
- [Benchmark protocol: connections](#resource-graph-benchmark)
- [One application, three development systems](#resource-course-progression)
- [From pressure to bounded evidence](#resource-pressure-evidence)
- [Tail latency simulator](#resource-demo-tail-latency-simulator)
- [Browser performance workbench](#resource-demo-browser-performance-workbench)
- [Fleet trace debugger](#resource-demo-fleet-trace-debugger)
### [Tail latency](https://scalableweb.dev/concepts/#tail-latency)
ID: `tail-latency`. Group: Evidence.
**Definition:** The slow end of the elapsed-time distribution, often described by a percentile such as p95 or p99.
**Assumptions:** State the percentile convention, population, sample size, and failure treatment. A small sample cannot precisely characterize rare slow outcomes.
**Worked example:** Eighteen requests at 40 ms and two at 240 ms have a 60 ms mean and a nearest-rank p95 of 240 ms. The mean hides the slow minority.
**Common mistake:** A good mean implies a good tail, or p95 can replace average time in Little's Law. These statistics answer different questions.
**Teaching passages:**
- [Measurement: compare mean and tail](https://scalableweb.dev/chapters/benchmarking/#exercise-measurement-prediction): Calculate how a slow minority affects the result.
- [Scaling: budget latency](https://scalableweb.dev/chapters/scaling/#latency-budget-lab): Account for the journey across stages.
**Readings:**
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [Project · Common contract](https://scalableweb.dev/project/)
**Graphics and experiments:**
- [Tail latency: connections](#resource-graph-tail-latency)
- [Tail latency simulator](#resource-demo-tail-latency-simulator)
### [Observability](https://scalableweb.dev/concepts/#observability)
ID: `observability`. Group: Evidence.
**Definition:** The capability to use telemetry to investigate system behavior across boundaries, including failures not anticipated when the system was instrumented.
**Assumptions:** Telemetry supplies evidence such as metrics, logs, and traces. Choose signals from the question and connect them with operation identity, time, and boundary; collecting signals alone does not establish observability or a cause.
**Worked example:** For a duplicated event after a timeout, join the command identifier, request trace, commit result, retry, and visible activity. Healthy HTTP success alone misses the duplicate.
**Common mistake:** Collecting many logs establishes the cause. Signals need a coherent question and a traceable connection to the user outcome.
**Teaching passages:**
- [Pressure: trace a failure](https://scalableweb.dev/chapters/reality/#trace-one-failure-across-the-web-boundary): Join symptoms, policies, and authoritative outcomes.
- [Measurement: signal selection](https://scalableweb.dev/chapters/benchmarking/#measurement-alone-cannot-explain-behavior): Use telemetry and the trace explorer to investigate behavior.
**Readings:**
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [Part II · Challenge](https://scalableweb.dev/parts/challenge/)
- [Project · Challenge](https://scalableweb.dev/project/challenge/)
**Graphics and experiments:**
- [Observability: connections](#resource-graph-observability)
- [OpenTelemetry trace explorer](#resource-demo-opentelemetry-trace-explorer)
- [Fleet trace debugger](#resource-demo-fleet-trace-debugger)
**Task-led explorations:**
- [Compare evidence for an agent repair](https://scalableweb.dev/explore/telemetry-guided-repair/agent.md): Saving an event reports success, but the list stays unchanged. Compare task feedback, runtime logs, and a diagnostic brief.
- [Follow a fix into running systems](https://scalableweb.dev/explore/verify-remediation/agent.md): A release succeeds and every health check passes. Decide what the runtime inventory still requires you to investigate.
### [Goodhart's Law](https://scalableweb.dev/concepts/#goodhart-law)
ID: `goodhart-law`. Group: Evidence.
**Definition:** A warning that optimizing a proxy as a target can weaken its relationship to the outcome it was intended to represent.
**Assumptions:** Identify the useful outcome, the proxy, and how behavior changes when rewarded for the proxy. Check the outcome with evidence beyond the target metric.
**Worked example:** Rewarding generated changes per hour can produce more small submissions while accepted output stays flat and reviewer waiting grows.
**Common mistake:** Every metric is useless. Metrics can inform decisions when their boundary, incentives, and omitted outcomes remain visible.
**Teaching passages:**
- [Measurement: challenge the metric](https://scalableweb.dev/chapters/benchmarking/#measurements-can-lead-you-astray): Use the Goodhart pressure test to inspect the proxy.
- [Fleets: measure accepted output](https://scalableweb.dev/chapters/agent-fleets/#measure-accepted-throughput): Count accepted work and the human effort it needs.
**Readings:**
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
**Graphics and experiments:**
- [Goodhart's Law: connections](#resource-graph-goodhart-law)
### [Agent evaluation](https://scalableweb.dev/concepts/#eval)
ID: `eval`. Group: Evidence.
**Definition:** A declared task-and-grading procedure for assessing an agent workflow's capability, regression behavior, cost, and reliability.
**Assumptions:** Separate the evaluated agent harness from the evaluation harness. Preserve task inputs, served configuration, trial rules, graders, and failed attempts.
**Worked example:** Run a contract-change task with fixed acceptance checks across repeated trials, recording correctness, retries, tokens, and reviewer minutes.
**Common mistake:** A pass on one task proves general reliability. Task selection, graders, environment, and trial variability limit the claim.
**Teaching passages:**
- [Appendix A: anatomy of an eval](https://scalableweb.dev/appendices/evaluating-agentic-workflows/#anatomy-of-an-agent-evaluation): Separate execution, environment, and grading.
- [Modern Web Guidance: evaluate the guidance](https://scalableweb.dev/case-studies/modern-web-guidance/#the-guidance-has-an-evaluation-loop): Check whether a capability improves actual task outcomes.
**Readings:**
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
- [Appendices](https://scalableweb.dev/parts/appendices/)
- [Case · Webernetes](https://scalableweb.dev/case-studies/webernetes/)
- [Case · Modern Web Guidance](https://scalableweb.dev/case-studies/modern-web-guidance/)
**Graphics and experiments:**
- [Agent evaluation: connections](#resource-graph-eval)
**Task-led explorations:**
- [Compare evidence for an agent repair](https://scalableweb.dev/explore/telemetry-guided-repair/agent.md): Saving an event reports success, but the list stays unchanged. Compare task feedback, runtime logs, and a diagnostic brief.
- [Probe an API with temporary clients](https://scalableweb.dev/explore/temporary-api-consumers/agent.md): A generated CSV client reports success but exports two rows. Design independent checks for a fixed paginated event feed.
- [Examine a confident classification](https://scalableweb.dev/explore/confidence-before-routing/agent.md): Twenty valid classifications report 90% confidence. Examine the evidence before using that score to route work.
### [Maintainability assessment](https://scalableweb.dev/concepts/#change-probe)
ID: `change-probe`. Group: Evidence.
**Definition:** An assessment of the effort and effectiveness of understanding, changing, and validating software. This course gathers evidence through a bounded change task performed by an unfamiliar maintainer.
**Usage in this book:** Change probe names this course's task-based maintainability assessment protocol. One task supplies evidence about that change under the recorded conditions; it is not a complete maintainability assessment or a standardized score.
**Assumptions:** Declare the starting version, task, auditor familiarity, completion criteria, and effort boundary. One probe does not represent all future maintenance.
**Worked example:** Ask another team to add one event filter. Record where they looked, what contracts they changed, validation effort, and the accepted result.
**Common mistake:** A system with passing behavior tests is necessarily easy to change. Navigability and the next-change cost need separate evidence.
**Teaching passages:**
- [Project: change-probe protocol](https://scalableweb.dev/project/#10-1-change-probe-protocol): Bound the audit and preserve comparable evidence.
- [Appendix A: next-change cost](https://scalableweb.dev/appendices/evaluating-agentic-workflows/#evaluate-the-cost-of-the-next-change): Evaluate maintainability beyond first-pass success.
**Readings:**
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
- [B · Reproducible environments](https://scalableweb.dev/appendices/reproducible-environments/)
- [Part II · Challenge](https://scalableweb.dev/parts/challenge/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Challenge](https://scalableweb.dev/project/challenge/)
- [Project · Assessment](https://scalableweb.dev/project/grading/)
**Graphics and experiments:**
- [Maintainability assessment: connections](#resource-graph-change-probe)
### [Coding agent](https://scalableweb.dev/concepts/#agent)
ID: `agent`. Group: Development.
**Definition:** A model-driven loop that observes context, chooses actions through tools, and uses resulting feedback to continue a development task.
**Usage in this book:** Agent is an established AI concept; coding agent has a more specific working meaning here. LLM practitioners vary in whether predefined workflows count as agents. The definition above requires model-directed action through tools.
- [Anthropic: definitions of workflows and agents](https://www.anthropic.com/engineering/building-effective-agents)
**Assumptions:** Capabilities depend on the model, context, tools, environment, budget, and permitted authority. Generated work remains candidate work until accepted.
**Worked example:** An agent edits an event handler, runs contract tests, inspects a failure, and revises the implementation before a maintainer accepts the change.
**Common mistake:** The model alone determines the development result. Its harness and the project's constraints materially shape what it can do and verify.
**Teaching passages:**
- [Development: define an agent](https://scalableweb.dev/chapters/scalable-development/#what-is-an-agent): Identify the observation–action loop.
- [Fleets: choose a coordination structure](https://scalableweb.dev/chapters/agent-fleets/#choose-a-coordination-structure): Explain the coordination obligations of each option.
**Readings:**
- [Introduction](https://scalableweb.dev/chapters/introduction/)
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [D · Agent security](https://scalableweb.dev/appendices/agent-system-security/)
- [Part I · Establish](https://scalableweb.dev/parts/establish/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Case · Webernetes](https://scalableweb.dev/case-studies/webernetes/)
- [Project · Introduction](https://scalableweb.dev/project/introduction/)
- [Project · Establish](https://scalableweb.dev/project/establish/)
**Graphics and experiments:**
- [Coding agent: connections](#resource-graph-agent)
- [One application, three development systems](#resource-course-progression)
- [Three connected scalability loops](#resource-three-connected-loops)
### [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering)
ID: `loop-engineering`. Group: Development.
**Definition:** The design of control structures that repeatedly direct agent work toward a declared goal, using observations, retained state, bounded actions and resources, and explicit acceptance, stopping, and escalation rules.
**Usage in this book:** Loop engineering is an emerging practitioner term. This book includes bounded goal-driven iteration as well as recurring agent runs. Lulla and colleagues use a narrower definition requiring scheduled or event-triggered recurrence. The label does not establish that greater autonomy improves outcomes.
- [Osmani: Loop Engineering (practitioner essay)](https://addyosmani.com/blog/loop-engineering/)
- [IBM: What is loop engineering? (industry explainer)](https://www.ibm.com/think/topics/loop-engineering)
- [Lulla et al.: building blocks and adoption (exploratory preprint)](https://arxiv.org/abs/2608.21884v2)
**Assumptions:** Name the trigger, goal, permitted actions, state owner, evidence, budget, and human acceptance responsibility. Retain relevant progress between iterations or runs; recurrence and delegation are separate design choices.
**Worked example:** A CSV-export repair loop gives an agent the failing input and a bounded task, records the attempted fix, and checks downloaded rows against permitted events and fields. It returns evidence for acceptance or escalates when the repair budget is exhausted.
**Common mistake:** Repeating a prompt, adding a schedule, or assigning another reviewer guarantees improvement. A loop can repeatedly pursue the wrong goal or pass checks that share its mistaken assumptions.
**Teaching passages:**
- [Development: design the loop](https://scalableweb.dev/chapters/scalable-development/#loop-engineering): Distinguish loop design from feedback and harness infrastructure.
- [Appendix A: research and evidence](https://scalableweb.dev/appendices/evaluating-agentic-workflows/#research-behind-loop-engineering): Separate adoption evidence, refinement experiments, and claims about developer effort.
- [Friction: match feedback to the boundary](https://scalableweb.dev/chapters/friction/#match-feedback-to-the-changed-boundary): Choose useful repair feedback without weakening final acceptance.
- [Fleets: choose coordination deliberately](https://scalableweb.dev/chapters/agent-fleets/#choose-a-coordination-structure): Add delegation only when the task and acceptance arrangement justify it.
**Readings:**
- [Introduction](https://scalableweb.dev/chapters/introduction/)
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
**Graphics and experiments:**
- [Loop engineering: connections](#resource-graph-loop-engineering)
- [Three connected scalability loops](#resource-three-connected-loops)
### [Project harness](https://scalableweb.dev/concepts/#harness)
ID: `harness`. Group: Development.
**Definition:** The versioned project instructions, specifications, architecture notes, environment, commands, and checks that make candidate changes inspectable and repeatable.
**Usage in this book:** Project harness is the book's name for this bundle of repository guidance and executable development controls. Harness terminology is still developing. The bundle supports the development workflow; the wider development system also includes people, review, integration, and ownership.
- [Anthropic: an agent harness and its project environment](https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents)
**Assumptions:** Keep the project harness distinct from an agent execution harness and an evaluation harness. Controls must be executable and maintained as the project changes.
**Worked example:** Pinned versions, a documented test command, contract tests, and a review gate let an agent and an unfamiliar human validate the same event change.
**Common mistake:** A long instruction file makes the workflow controlled. Instructions require enforceable checks and an owner for acceptance.
**Teaching passages:**
- [Development: the project harness](https://scalableweb.dev/chapters/scalable-development/#the-project-harness): Connect instructions with executable controls.
- [Kirjolab: prepare before feature pressure](https://scalableweb.dev/case-studies/kirjolab/#the-harness-existed-before-the-feature-pressure): See a harness support rapid delivery.
**Readings:**
- [Introduction](https://scalableweb.dev/chapters/introduction/)
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
- [B · Reproducible environments](https://scalableweb.dev/appendices/reproducible-environments/)
- [D · Agent security](https://scalableweb.dev/appendices/agent-system-security/)
- [Part I · Establish](https://scalableweb.dev/parts/establish/)
- [Case · Slideotter](https://scalableweb.dev/case-studies/slideotter/)
- [Case · Thesis Journey Tracker](https://scalableweb.dev/case-studies/thesis-journey-tracker/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Case · Webernetes](https://scalableweb.dev/case-studies/webernetes/)
- [Case · Modern Web Guidance](https://scalableweb.dev/case-studies/modern-web-guidance/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Establish](https://scalableweb.dev/project/establish/)
**Graphics and experiments:**
- [Project harness: connections](#resource-graph-harness)
- [Knowledge and artifact ownership](#resource-shared-knowledge-boundary)
### [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria)
ID: `acceptance-criteria`. Group: Development.
**Definition:** Declared observable conditions a candidate result must satisfy before it counts as completed work.
**Assumptions:** Criteria should follow the task and invariants, be testable where possible, and identify who accepts the result. Passing checks establish only what those checks cover.
**Worked example:** An event change must preserve workspace isolation, show the new activity in the feed, and pass the shared tests before it counts as accepted throughput.
**Common mistake:** A clean diff or successful merge establishes correctness. Behavior, integration, and accountable review are separate obligations.
**Teaching passages:**
- [Fleets: authority and acceptance](https://scalableweb.dev/chapters/agent-fleets/#map-authority-and-acceptance): Assign acceptance before parallel work begins.
- [Webernetes: shared behavioral tests](https://scalableweb.dev/case-studies/webernetes/#shared-tests-created-a-behavioral-contrast): Test generated behavior against a reference.
**Readings:**
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
- [D · Agent security](https://scalableweb.dev/appendices/agent-system-security/)
- [Part I · Establish](https://scalableweb.dev/parts/establish/)
- [Case · Slideotter](https://scalableweb.dev/case-studies/slideotter/)
- [Case · Webernetes](https://scalableweb.dev/case-studies/webernetes/)
- [Case · Temper](https://scalableweb.dev/case-studies/temper/)
- [Project · Introduction](https://scalableweb.dev/project/introduction/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Establish](https://scalableweb.dev/project/establish/)
- [Project · Challenge](https://scalableweb.dev/project/challenge/)
- [Project · Assessment](https://scalableweb.dev/project/grading/)
**Graphics and experiments:**
- [Acceptance criteria: connections](#resource-graph-acceptance-criteria)
- [One application, three development systems](#resource-course-progression)
**Task-led explorations:**
- [Move a prototype into shared use](https://scalableweb.dev/explore/prototype-to-shared-use/agent.md): A working CSV exporter is ready for a demo. What would make it ready for a team's weekly report?
- [Challenge an explanation](https://scalableweb.dev/explore/challenge-an-explanation/agent.md): An agent says a recorder prevents duplicate events after restart. Predict the behavior and test its claim.
- [Compare evidence for an agent repair](https://scalableweb.dev/explore/telemetry-guided-repair/agent.md): Saving an event reports success, but the list stays unchanged. Compare task feedback, runtime logs, and a diagnostic brief.
- [Follow a fix into running systems](https://scalableweb.dev/explore/verify-remediation/agent.md): A release succeeds and every health check passes. Decide what the runtime inventory still requires you to investigate.
- [Probe an API with temporary clients](https://scalableweb.dev/explore/temporary-api-consumers/agent.md): A generated CSV client reports success but exports two rows. Design independent checks for a fixed paginated event feed.
- [Examine a confident classification](https://scalableweb.dev/explore/confidence-before-routing/agent.md): Twenty valid classifications report 90% confidence. Examine the evidence before using that score to route work.
### [Action authorization](https://scalableweb.dev/concepts/#authority)
ID: `authority`. Group: Development.
**Definition:** The permission granted to an actor to propose, prepare, or execute a decision or action within stated limits.
**Usage in this book:** The book also calls this action authority. Authorization concerns permission to act; accountability concerns ownership of the consequences. Keep both separate from which stored state is authoritative.
- [NIST: authorization definitions and their contexts](https://csrc.nist.gov/glossary/term/authorization)
**Assumptions:** Name who may act and who remains accountable for the outcome. Separate holding credentials, being authorized to act, and being contained by the environment. Reading untrusted material does not grant it authority.
**Worked example:** An implementation agent may edit a worktree and run tests, but may only prepare a release. A named maintainer authorizes the release and owns acceptance of its behavior.
**Common mistake:** Access to a tool implies permission for every action it supports. Credentials, action approval, and containment are different controls.
**Teaching passages:**
- [Development: assign authority](https://scalableweb.dev/chapters/scalable-development/#assign-authority-and-ownership): Make execution and acceptance ownership explicit.
- [Appendix D: separate security controls](https://scalableweb.dev/appendices/agent-system-security/#separate-credential-custody-action-authorization-and-containment): Distinguish access, authorization, and containment.
**Readings:**
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
- [D · Agent security](https://scalableweb.dev/appendices/agent-system-security/)
- [Appendices](https://scalableweb.dev/parts/appendices/)
- [Case · Thesis Journey Tracker](https://scalableweb.dev/case-studies/thesis-journey-tracker/)
- [Case · Modern Web Guidance](https://scalableweb.dev/case-studies/modern-web-guidance/)
- [Case · Temper](https://scalableweb.dev/case-studies/temper/)
- [Project · Introduction](https://scalableweb.dev/project/introduction/)
- [Project · Compare](https://scalableweb.dev/project/compare/)
**Graphics and experiments:**
- [Action authorization: connections](#resource-graph-authority)
- [Knowledge and artifact ownership](#resource-shared-knowledge-boundary)
- [Deterministic boundary lab](#resource-demo-deterministic-boundary-lab)
- [Fleet trace debugger](#resource-demo-fleet-trace-debugger)
**Task-led explorations:**
- [Move a prototype into shared use](https://scalableweb.dev/explore/prototype-to-shared-use/agent.md): A working CSV exporter is ready for a demo. What would make it ready for a team's weekly report?
- [Probe an API with temporary clients](https://scalableweb.dev/explore/temporary-api-consumers/agent.md): A generated CSV client reports success but exports two rows. Design independent checks for a fixed paginated event feed.
- [Examine a confident classification](https://scalableweb.dev/explore/confidence-before-routing/agent.md): Twenty valid classifications report 90% confidence. Examine the evidence before using that score to route work.
### [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop)
ID: `feedback-loop`. Group: Development.
**Definition:** A cycle in which a system's effects feed back into its subsequent behavior. Negative feedback counteracts a deviation; positive feedback reinforces it.
**Usage in this book:** Positive and negative describe whether the loop reinforces or counteracts a change, not whether its outcome is desirable. The development examples mainly use corrective feedback; overload examples also use reinforcing feedback.
- [Caltech: negative and positive feedback](https://murray.cds.caltech.edu/Is_control_a_type_of_negative_feedback%3F)
**Assumptions:** Identify the causal path, signal, response, and delay. For a corrective loop, also name the desired state and owner. Negative feedback can still become unstable when delay or response strength is poorly controlled.
**Worked example:** A failing contract check leads an agent to revise a change: corrective feedback. Overload causes timeouts, timeouts cause retries, and retries add load: reinforcing feedback.
**Common mistake:** More frequent feedback guarantees improvement. A delayed or misleading signal can amplify the wrong behavior.
**Teaching passages:**
- [Development: constrain, generate, validate, revise](https://scalableweb.dev/chapters/scalable-development/#constrain-generate-validate-revise): Use the loop to turn candidate work into accepted work.
- [Scaling: orchestration control](https://scalableweb.dev/chapters/scaling/#orchestration-maintains-declared-capacity): Compare development feedback with runtime control.
- [Scaling: retry amplification](https://scalableweb.dev/chapters/scaling/#name-the-saturation-boundary): Trace the reinforcing cycle from overload to timeouts, retries, and more load.
**Readings:**
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [B · Reproducible environments](https://scalableweb.dev/appendices/reproducible-environments/)
- [Case · Thesis Journey Tracker](https://scalableweb.dev/case-studies/thesis-journey-tracker/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Case · Webernetes](https://scalableweb.dev/case-studies/webernetes/)
**Graphics and experiments:**
- [Feedback loop: connections](#resource-graph-feedback-loop)
- [Three connected scalability loops](#resource-three-connected-loops)
- [Orchestration control loop](#resource-demo-orchestration-control-loop)
### [Decision log](https://scalableweb.dev/concepts/#decision-log)
ID: `decision-log`. Group: Development.
**Definition:** A maintained record of consequential decisions, their context, rationale, status, and consequences. An Architecture Decision Record (ADR) captures one architecturally significant choice in such a log.
**Assumptions:** For the course, include alternatives, evidence, ownership, current reversibility, and a revisit condition. Distinguish proposed, accepted, and implemented status from whether the choice remains soft or has become hard. Link superseding decisions to earlier records.
**Worked example:** A record accepts an optional category field for an isolated trial, links compatibility tests, and requires review before production adoption. It notes that storing the representation and exposing it to independent clients will make reversal require compatibility or migration.
**Common mistake:** Writing an ADR makes a decision permanent, proves it was implemented, or replaces current tests and contracts. The log preserves rationale and review conditions; it must remain connected to the actual implementation and evidence.
**Teaching passages:**
- [Friction: record the commitment](https://scalableweb.dev/chapters/friction/#keep-a-decision-log): Record soft and hard choices with their evidence and revisit conditions.
- [Measurement: preserve accepted context](https://scalableweb.dev/chapters/benchmarking/#field-note-preserve-accepted-context-not-every-interaction): Distinguish accepted rationale from a complete execution trace.
- [Project: record the stack hypothesis](https://scalableweb.dev/project/establish/#record-the-stack-hypothesis): Use the existing stack decision record to make assumptions reviewable.
**Readings:**
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [3 · Measurement](https://scalableweb.dev/chapters/benchmarking/)
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [Part II · Challenge](https://scalableweb.dev/parts/challenge/)
- [Case · Slideotter](https://scalableweb.dev/case-studies/slideotter/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Project · Introduction](https://scalableweb.dev/project/introduction/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Establish](https://scalableweb.dev/project/establish/)
- [Project · Compare](https://scalableweb.dev/project/compare/)
**Graphics and experiments:**
- [Decision log: connections](#resource-graph-decision-log)
### [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility)
ID: `decision-reversibility`. Group: Development.
**Definition:** How easily a decision can be revised or undone safely. Soft decisions remain cheap to change; hard decisions require more coordination or recovery because other work depends on them.
**Usage in this book:** Soft and hard decisions are the book's shorthand for low and high reversal cost. This relates to the one-way/two-way-door distinction, but the course treats reversal cost as a spectrum that changes with dependencies and durable effects.
- [Amazon: reversible decisions and two-way doors](https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders)
**Assumptions:** Assess the current dependencies, durable effects, reversal cost, and evidence of safe recovery. Soft and hard are relative descriptions, and a choice can become harder as it is used.
**Worked example:** A category representation tried in an isolated branch is easy to revise. Once production events store it and independent clients rely on it, changing that same choice requires compatibility or migration rather than only a code revert.
**Common mistake:** A small code change is always a soft decision, or a hard decision is automatically technical debt. Durable effects and dependencies determine reversal cost; some hard commitments are necessary and justified.
**Teaching passages:**
- [Friction: plan soft and hard decisions](https://scalableweb.dev/chapters/friction/#plan-soft-and-hard-decisions): Keep uncertain choices cheap to revise and identify what would make them hard.
- [Scalability: change exposes commitments](https://scalableweb.dev/chapters/what-is-scalability/#change-makes-old-commitments-visible): Connect the ability to keep changing with the dependencies already created.
- [Friction: keep a decision log](https://scalableweb.dev/chapters/friction/#keep-a-decision-log): Preserve what makes a choice reversible and when it should be reviewed.
**Readings:**
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [Part II · Challenge](https://scalableweb.dev/parts/challenge/)
- [Project · Establish](https://scalableweb.dev/project/establish/)
- [Project · Challenge](https://scalableweb.dev/project/challenge/)
**Graphics and experiments:**
- [Decision reversibility: connections](#resource-graph-decision-reversibility)
- [Knowledge and artifact ownership](#resource-shared-knowledge-boundary)
**Task-led explorations:**
- [Move a prototype into shared use](https://scalableweb.dev/explore/prototype-to-shared-use/agent.md): A working CSV exporter is ready for a demo. What would make it ready for a team's weekly report?
### [Technical debt](https://scalableweb.dev/concepts/#technical-debt)
ID: `technical-debt`. Group: Development.
**Definition:** Future change cost or reduced practical options created by earlier design or process shortcuts, compromises, or unmanaged coupling.
**Assumptions:** Identify the earlier choice, future change it obstructs, and evidence of its cost. A necessary hard commitment is not automatically debt; deliberately accepted debt can be justified when its future cost is visible and owned.
**Worked example:** An undocumented schema assumption spreads into the API and UI. Adding one state later requires coordinated changes whose boundaries are hard to find.
**Common mistake:** Debt is merely untidy code. Coupled contracts, environments, and missing ownership can reduce optionality even when the code is neat.
**Teaching passages:**
- [Challenge: reduced optionality](https://scalableweb.dev/parts/challenge/#technical-debt-reduces-optionality): Connect commitments with future choices.
- [Kirjolab: revise the architecture](https://scalableweb.dev/case-studies/kirjolab/#refactoring-was-the-revision-phase): Follow consolidation after rapid generation.
- [Friction: find the commitment point](https://scalableweb.dev/chapters/friction/#find-the-commitment-point): Distinguish the cost of reversing a commitment from technical debt.
**Readings:**
- [1 · Scalability](https://scalableweb.dev/chapters/what-is-scalability/)
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [Part II · Challenge](https://scalableweb.dev/parts/challenge/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Project · Challenge](https://scalableweb.dev/project/challenge/)
**Graphics and experiments:**
- [Technical debt: connections](#resource-graph-technical-debt)
- [Knowledge and artifact ownership](#resource-shared-knowledge-boundary)
### [Reproducible environment](https://scalableweb.dev/concepts/#reproducible-environment)
ID: `reproducible-environment`. Group: Development.
**Definition:** A declared setup that allows another run or maintainer to recreate the dependencies and conditions relevant to a result.
**Assumptions:** Choose the necessary strength: pinned versions, containers, or stronger isolation as the claim requires. Seeds and versions do not remove all nondeterminism.
**Worked example:** The auditor uses the documented runtime, lockfile, database seed, and test commands to reproduce an event-feed failure from a clean checkout.
**Common mistake:** It works on one laptop, so the result is reproducible. Hidden services, mutable dependencies, and undeclared state can invalidate that inference.
**Teaching passages:**
- [Friction: version the environment](https://scalableweb.dev/chapters/friction/#treat-the-environment-as-a-versioned-input): Treat setup as part of the development boundary.
- [Appendix B: choose the strength](https://scalableweb.dev/appendices/reproducible-environments/#choose-the-required-strength): Match reproducibility to the experiment.
**Readings:**
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [B · Reproducible environments](https://scalableweb.dev/appendices/reproducible-environments/)
- [Appendices](https://scalableweb.dev/parts/appendices/)
- [Case · Modern Web Guidance](https://scalableweb.dev/case-studies/modern-web-guidance/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Establish](https://scalableweb.dev/project/establish/)
- [Project · Assessment](https://scalableweb.dev/project/grading/)
**Graphics and experiments:**
- [Reproducible environment: connections](#resource-graph-reproducible-environment)
### [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet)
ID: `agent-fleet`. Group: Development.
**Definition:** Several agents working under an explicit task, coordination, authority, integration, and acceptance arrangement.
**Usage in this book:** Multi-agent system is the established broader term. Agent fleet names the book's coordinated coding-agent arrangement within a development workflow. A multi-agent system need not use LLMs, pursue a shared goal, or have the integration and acceptance structure described here.
- [Poole and Mackworth: multiagent systems](https://artint.info/3e/html/ArtInt3e.Ch14.S1.html)
**Assumptions:** Useful parallelism depends on separable work and available integration capacity. Count accepted changes and coordination cost, not only simultaneous agents.
**Worked example:** One agent changes the event contract, another updates consumers after that contract is fixed, and a reviewer tests their integrated behavior.
**Common mistake:** More agents guarantee more useful output. Shared dependencies and sequential review can erase the benefit.
**Teaching passages:**
- [Fleets: choose a coordination structure](https://scalableweb.dev/chapters/agent-fleets/#choose-a-coordination-structure): Choose a structure that fits the work and integration capacity.
- [Compare: implementation C](https://scalableweb.dev/parts/compare/#implementation-c-work-activity-tracker): Declare and evaluate a fleet in the project.
**Readings:**
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [D · Agent security](https://scalableweb.dev/appendices/agent-system-security/)
- [Part III · Compare](https://scalableweb.dev/parts/compare/)
- [Project · Introduction](https://scalableweb.dev/project/introduction/)
- [Project · Compare](https://scalableweb.dev/project/compare/)
**Graphics and experiments:**
- [Agent fleet: connections](#resource-graph-agent-fleet)
- [One application, three development systems](#resource-course-progression)
- [Fleet trace debugger](#resource-demo-fleet-trace-debugger)
- [Sequential work bound](#resource-demo-sequential-work-bound)
**Task-led explorations:**
- [Vary human work in progress](https://scalableweb.dev/explore/human-work-in-progress/agent.md): Keep the same worker limit while changing how many unfinished changes enter the workflow. Plan a bounded comparison.
### [Task graph](https://scalableweb.dev/concepts/#task-graph)
ID: `task-graph`. Group: Development.
**Definition:** A representation of work units and their dependencies, ownership, outputs, and integration points.
**Assumptions:** Dependencies must reflect shared contracts and actual acceptance order. Independent files do not necessarily mean independent behavior.
**Worked example:** Fix the event schema before parallel API and UI tasks; reunite them in a shared-contract integration test.
**Common mistake:** Tasks that merge without conflicts were independent. A clean merge can still combine incompatible assumptions.
**Teaching passages:**
- [Fleets: define the task graph](https://scalableweb.dev/chapters/agent-fleets/#define-the-web-task-graph): Separate parallel work from ordered integration.
- [Appendix D: task and resource control](https://scalableweb.dev/appendices/agent-system-security/#separate-task-control-from-resource-access): Keep task dependencies distinct from access permissions.
**Readings:**
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [D · Agent security](https://scalableweb.dev/appendices/agent-system-security/)
- [Part III · Compare](https://scalableweb.dev/parts/compare/)
- [Project · Compare](https://scalableweb.dev/project/compare/)
**Graphics and experiments:**
- [Task graph: connections](#resource-graph-task-graph)
### [Review capacity](https://scalableweb.dev/concepts/#review-budget)
ID: `review-budget`. Group: Development.
**Definition:** The finite human attention and integration effort available to evaluate and accept candidate changes.
**Usage in this book:** Review capacity applies capacity and queueing ideas to human review and integration. It is not a fixed personal productivity rating; task complexity, review depth, interruptions, and correction work affect the observed capacity.
**Assumptions:** Record review, correction, waiting, acceptance, rejection, and withdrawal at a declared boundary. Human tasks vary; one observation of backlog or accepted output does not establish sustainable capacity.
**Worked example:** In one hour, agents submit six changes and the maintainer accepts four. If none leave through rejection or withdrawal, unfinished work increases by two. Measure over time before treating four accepted changes/hour as sustainable capacity.
**Common mistake:** Review is an overhead that disappears with better generation. Understanding and accountable acceptance remain part of useful throughput.
**Teaching passages:**
- [Development: generation outruns comprehension](https://scalableweb.dev/chapters/scalable-development/#when-generation-outruns-comprehension): Locate the human constraint.
- [Introduction: editorial acceptance](https://scalableweb.dev/chapters/introduction/#how-this-book-was-made): Separate publishing checks from editorial judgment.
**Readings:**
- [Introduction](https://scalableweb.dev/chapters/introduction/)
- [2 · Scalable development](https://scalableweb.dev/chapters/scalable-development/)
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [9 · Recap](https://scalableweb.dev/chapters/recap/)
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
- [Part III · Compare](https://scalableweb.dev/parts/compare/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Case · Temper](https://scalableweb.dev/case-studies/temper/)
- [Project · Compare](https://scalableweb.dev/project/compare/)
**Graphics and experiments:**
- [Review capacity: connections](#resource-graph-review-budget)
- [Three connected scalability loops](#resource-three-connected-loops)
- [Sequential work bound](#resource-demo-sequential-work-bound)
**Task-led explorations:**
- [Vary human work in progress](https://scalableweb.dev/explore/human-work-in-progress/agent.md): Keep the same worker limit while changing how many unfinished changes enter the workflow. Plan a bounded comparison.
### [Application contract](https://scalableweb.dev/concepts/#contract)
ID: `contract`. Group: Architecture.
**Definition:** An agreement about observable behavior, valid inputs, outputs, errors, and obligations at an application boundary.
**Assumptions:** Identify consumers, versioning, authority, and compatibility expectations. Contracts include behavior that a type signature alone cannot express.
**Worked example:** POST /events accepts one logical activity with workspace isolation and a declared duplicate policy, regardless of which runtime hosts the handler.
**Common mistake:** A deployment location or matching types fully defines the contract. Timing, retries, errors, and state effects also matter.
**Teaching passages:**
- [Architecture: contracts outlive deployment](https://scalableweb.dev/chapters/architecture/#application-contracts-outlive-deployment-choices): Separate behavior from where execution happens.
- [Appendix C: executable HTTP contracts](https://scalableweb.dev/appendices/advanced-web-boundaries/#executable-http-contracts): Make boundary expectations testable.
**Readings:**
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [5 · Friction](https://scalableweb.dev/chapters/friction/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
- [D · Agent security](https://scalableweb.dev/appendices/agent-system-security/)
- [Part I · Establish](https://scalableweb.dev/parts/establish/)
- [Part II · Challenge](https://scalableweb.dev/parts/challenge/)
- [Case · Kirjolab](https://scalableweb.dev/case-studies/kirjolab/)
- [Case · Webernetes](https://scalableweb.dev/case-studies/webernetes/)
- [Case · Modern Web Guidance](https://scalableweb.dev/case-studies/modern-web-guidance/)
- [Case · Temper](https://scalableweb.dev/case-studies/temper/)
- [Project · Common contract](https://scalableweb.dev/project/)
- [Project · Challenge](https://scalableweb.dev/project/challenge/)
**Graphics and experiments:**
- [Application contract: connections](#resource-graph-contract)
- [An external quota becomes the availability boundary](#resource-dependency-failure)
- [Knowledge and artifact ownership](#resource-shared-knowledge-boundary)
- [Deterministic boundary lab](#resource-demo-deterministic-boundary-lab)
- [Cache decision lab](#resource-demo-cache-decision-lab)
- [Web architecture lens](#resource-demo-web-architecture-lens)
- [Reliability chain lab](#resource-demo-reliability-chain-lab)
- [Orchestration control loop](#resource-demo-orchestration-control-loop)
**Task-led explorations:**
- [Probe an API with temporary clients](https://scalableweb.dev/explore/temporary-api-consumers/agent.md): A generated CSV client reports success but exports two rows. Design independent checks for a fixed paginated event feed.
### [Rendering and activation](https://scalableweb.dev/concepts/#rendering)
ID: `rendering`. Group: Architecture.
**Definition:** Rendering creates a representation; activation connects that representation to interactive behavior. Their work can occur at different times and locations.
**Assumptions:** Trace data authority, representation freshness, delivered assets, and activation cost separately. A visible interface is not necessarily ready to act.
**Worked example:** A static activity page arrives quickly, but client listeners and data must initialize before its filter works. Move work only after measuring the user journey.
**Common mistake:** Server rendering, client rendering, or hydration is universally fastest. The workload and interaction boundary determine the result.
**Teaching passages:**
- [Architecture: move rendering work](https://scalableweb.dev/chapters/architecture/#rendering-moves-work-across-time-and-place): Compare representation delivery choices.
- [Appendix C: activate an interface](https://scalableweb.dev/appendices/advanced-web-boundaries/#activate-delivered-interfaces): Distinguish rendering from activation.
**Readings:**
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
**Graphics and experiments:**
- [Rendering and activation: connections](#resource-graph-rendering)
- [Web architecture lens](#resource-demo-web-architecture-lens)
- [Browser performance workbench](#resource-demo-browser-performance-workbench)
### [Authoritative state](https://scalableweb.dev/concepts/#state-authority)
ID: `state-authority`. Group: Architecture.
**Definition:** The state treated as the source of truth for a named domain outcome, together with the boundary responsible for committing and preserving it.
**Usage in this book:** The book also uses state authority for the boundary that owns authoritative state. Authority terminology varies by system; identify the particular record and owner rather than assuming every domain has one central store.
**Assumptions:** Name which state is authoritative and how copies catch up. Permission to submit an action does not establish that it committed; a successful response or rebuilt view also needs evidence of the authoritative outcome.
**Worked example:** The event store commits one activity. A delayed cached feed may show none yet; rebuilding the feed must not create a second activity.
**Common mistake:** Every copy is equally authoritative, or stateless handlers remove state. Authority still exists somewhere in the system.
**Teaching passages:**
- [Architecture: authority and access](https://scalableweb.dev/chapters/architecture/#data-placement-follows-authority-and-access): Follow ownership before choosing placement.
- [Appendix C: rebuild without repeating effects](https://scalableweb.dev/appendices/advanced-web-boundaries/#rebuild-a-view-without-repeating-its-effects): Keep derived views separate from durable actions.
**Readings:**
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
- [F · Durable workflows](https://scalableweb.dev/appendices/durable-workflows/)
- [Case · Slideotter](https://scalableweb.dev/case-studies/slideotter/)
**Graphics and experiments:**
- [Authoritative state: connections](#resource-graph-state-authority)
- [Deterministic boundary lab](#resource-demo-deterministic-boundary-lab)
- [ACID transaction lab](#resource-demo-acid-transaction-lab)
- [Web architecture lens](#resource-demo-web-architecture-lens)
- [Fleet trace debugger](#resource-demo-fleet-trace-debugger)
- [Orchestration control loop](#resource-demo-orchestration-control-loop)
- [Durable effect retry lab](#resource-demo-durable-effect-retry-lab)
- [CAP partition lab](#resource-demo-cap-partition-lab)
**Task-led explorations:**
- [Challenge an explanation](https://scalableweb.dev/explore/challenge-an-explanation/agent.md): An agent says a recorder prevents duplicate events after restart. Predict the behavior and test its claim.
### [Transaction](https://scalableweb.dev/concepts/#transaction)
ID: `transaction`. Group: Architecture.
**Definition:** A unit of state change with declared atomicity, isolation, and durability guarantees used to preserve invariants across concurrency and failure.
**Assumptions:** Check the actual store and isolation behavior. A database transaction does not automatically make effects in an external service atomic with its commit.
**Worked example:** Commit the event and its reusable idempotency result together so a retried command cannot observe only half of the intended state.
**Common mistake:** Using a transaction makes every distributed action exactly once. External effects and ambiguous outcomes still need their own protocol.
**Teaching passages:**
- [Architecture: preserve invariants](https://scalableweb.dev/chapters/architecture/#transactions-preserve-invariants-across-failure-and-concurrency): Explain why the state changes belong together.
- [Appendix C: transaction guarantees](https://scalableweb.dev/appendices/advanced-web-boundaries/#preserve-durable-invariants-with-transactions): Test concurrency and failure assumptions.
**Readings:**
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
- [F · Durable workflows](https://scalableweb.dev/appendices/durable-workflows/)
**Graphics and experiments:**
- [Transaction: connections](#resource-graph-transaction)
- [ACID transaction lab](#resource-demo-acid-transaction-lab)
### [Invariant](https://scalableweb.dev/concepts/#invariant)
ID: `invariant`. Group: Architecture.
**Definition:** A condition that must hold for every valid state or accepted transition within a declared domain boundary.
**Assumptions:** Specify the boundary and concurrent transitions. Validate at the authority; input validation alone may not protect against competing requests.
**Worked example:** An event must reference a work item in the same workspace. The rule must survive concurrent writes and retries, not only the UI form.
**Common mistake:** Passing the happy path proves the invariant. Invalid combinations, concurrency, and partial failure challenge it.
**Teaching passages:**
- [Architecture: valid data combinations](https://scalableweb.dev/chapters/architecture/#model-valid-data-combinations): Make invalid combinations explicit.
- [Appendix C: durable invariants](https://scalableweb.dev/appendices/advanced-web-boundaries/#preserve-durable-invariants-with-transactions): Place enforcement at the durable boundary.
**Readings:**
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
- [Case · Temper](https://scalableweb.dev/case-studies/temper/)
- [Project · Common contract](https://scalableweb.dev/project/)
**Graphics and experiments:**
- [Invariant: connections](#resource-graph-invariant)
- [Deterministic boundary lab](#resource-demo-deterministic-boundary-lab)
- [ACID transaction lab](#resource-demo-acid-transaction-lab)
- [CAP partition lab](#resource-demo-cap-partition-lab)
### [Cache](https://scalableweb.dev/concepts/#cache)
ID: `cache`. Group: Architecture.
**Definition:** A controlled copy of a representation or result whose identity, freshness, invalidation, and access policy are part of the application contract.
**Assumptions:** Name the authority, cache key, eligible population, stale tolerance, and invalidation path. Shared caches must preserve isolation between users and workspaces.
**Worked example:** Cache an activity feed by workspace and filter, then define when a newly committed event becomes visible. Omitting workspace from the key can expose another workspace's data.
**Common mistake:** Caching only changes speed. It also changes freshness, authorization exposure, dependency load, and recovery behavior.
**Teaching passages:**
- [Architecture: controlled copies](https://scalableweb.dev/chapters/architecture/#caching-coordinates-controlled-copies): Specify cache policy as behavior.
- [Pressure: a dependency quota outage](https://scalableweb.dev/chapters/reality/#field-note-when-caching-complexity-became-an-availability-risk): Trace faulty caching into an availability failure.
**Readings:**
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
**Graphics and experiments:**
- [Cache: connections](#resource-graph-cache)
- [An external quota becomes the availability boundary](#resource-dependency-failure)
- [Cache decision lab](#resource-demo-cache-decision-lab)
- [Latency budget map](#resource-demo-latency-budget-map)
### [Idempotency](https://scalableweb.dev/concepts/#idempotency)
ID: `idempotency`. Group: Architecture.
**Definition:** The property that repeating one logical operation has the same intended effect at a declared boundary as performing it once.
**Assumptions:** Name the operation and all its intended effects. For key-based deduplication, define key scope and lifetime, conflicting payload behavior, and atomic enforcement with the effect and result at their authority.
**Worked example:** Completing a work item promises the Done status and one activity event. A retry that leaves the status unchanged but appends another event violates the whole operation's contract.
**Common mistake:** An unchanged final status proves the whole operation is idempotent. Its contract may include other effects; a local deduplication guarantee also does not establish exactly-once execution elsewhere.
**Teaching passages:**
- [Pressure: lost response and duplicate](https://scalableweb.dev/chapters/reality/#trace-one-failure-across-the-web-boundary): Follow one logical command through a retry.
- [Pressure: inspect all promised effects](https://scalableweb.dev/chapters/reality/#exercise-pressure-retries): Assess the status and activity history together before choosing a retry mechanism.
- [Appendix C: HTTP method semantics](https://scalableweb.dev/appendices/advanced-web-boundaries/#distinguish-http-method-semantics-from-domain-retry-safety): Separate intended effects, response differences, and incidental request logging.
- [Appendix F: audit the effect](https://scalableweb.dev/appendices/durable-workflows/#audit-the-effect-boundary): Place deduplication at the authority for the effect.
**Readings:**
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
- [F · Durable workflows](https://scalableweb.dev/appendices/durable-workflows/)
**Graphics and experiments:**
- [Idempotency: connections](#resource-graph-idempotency)
- [Durable effect retry lab](#resource-demo-durable-effect-retry-lab)
**Task-led explorations:**
- [Challenge an explanation](https://scalableweb.dev/explore/challenge-an-explanation/agent.md): An agent says a recorder prevents duplicate events after restart. Predict the behavior and test its claim.
### [Retry policy](https://scalableweb.dev/concepts/#retry)
ID: `retry`. Group: Operations.
**Definition:** The rules for attempting work again after failure or an ambiguous result, including limits, delay, deadlines, and operation identity.
**Assumptions:** Distinguish transient failure from permanent rejection and unknown completion. Bound attempts and preserve retry-safe semantics before adding retries.
**Worked example:** A timeout after commit leaves the client uncertain. Reuse the command key and delay a bounded retry; synchronized immediate retries can overload the recovering dependency.
**Common mistake:** Retrying always improves availability. It can duplicate effects or amplify the pressure that caused the failure.
**Teaching passages:**
- [Pressure: production assumptions](https://scalableweb.dev/chapters/reality/#local-correctness-leaves-production-assumptions-untested): Account for network ambiguity and retry amplification.
- [Appendix F: retry-safe effects](https://scalableweb.dev/appendices/durable-workflows/#audit-the-effect-boundary): Distinguish workflow progress from effect safety.
**Readings:**
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [F · Durable workflows](https://scalableweb.dev/appendices/durable-workflows/)
**Graphics and experiments:**
- [Retry policy: connections](#resource-graph-retry)
- [OpenTelemetry trace explorer](#resource-demo-opentelemetry-trace-explorer)
- [Durable effect retry lab](#resource-demo-durable-effect-retry-lab)
### [Admission and backpressure](https://scalableweb.dev/concepts/#backpressure)
ID: `backpressure`. Group: Operations.
**Definition:** Policies that bound admitted work or communicate downstream inability to keep up, preserving a declared service goal under pressure.
**Assumptions:** Specify capacity, rejection or slowing behavior, caller obligations, and recovery. Rejected work must stay visible in the outcome accounting.
**Worked example:** A full event queue rejects optional submissions with a retry policy instead of accumulating unbounded waiting and exhausting memory.
**Common mistake:** Rejecting load means the design cannot scale, or a queue is unlimited capacity. Bounded admission can protect useful work while capacity is restored.
**Teaching passages:**
- [Scaling: response guide](https://scalableweb.dev/chapters/scaling/#start-with-the-pressure): Match the intervention to the pressured boundary.
- [Pressure: recovery architecture](https://scalableweb.dev/chapters/reality/#recovery-is-part-of-the-architecture): Plan how overload and backlog drain end.
**Readings:**
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
**Graphics and experiments:**
- [Admission and backpressure: connections](#resource-graph-backpressure)
- [Saturation boundary lab](#resource-demo-saturation-boundary-lab)
### [Recovery](https://scalableweb.dev/concepts/#recovery)
ID: `recovery`. Group: Operations.
**Definition:** The prepared path from a disrupted state back to useful, correct service, including restored capacity, authoritative state, and backlog handling.
**Assumptions:** Check whether recovery tools depend on the failed service. Preserve operation identity and state integrity while replaying or draining work.
**Worked example:** Restore the worker, then observe queue age and visible event freshness until the backlog drains. A healthy process alone does not establish recovery.
**Common mistake:** Restarting the endpoint ends the incident. Stale copies, duplicates, blocked tools, and pending work may persist.
**Teaching passages:**
- [Pressure: recovery is architecture](https://scalableweb.dev/chapters/reality/#recovery-is-part-of-the-architecture): Prepare the path before the disturbance.
- [Thesis tracker: recovery features](https://scalableweb.dev/case-studies/thesis-journey-tracker/#recovery-is-a-first-class-feature): See recovery become part of the product.
**Readings:**
- [6 · Production pressure](https://scalableweb.dev/chapters/reality/)
- [F · Durable workflows](https://scalableweb.dev/appendices/durable-workflows/)
- [Part II · Challenge](https://scalableweb.dev/parts/challenge/)
- [Case · Thesis Journey Tracker](https://scalableweb.dev/case-studies/thesis-journey-tracker/)
**Graphics and experiments:**
- [Recovery: connections](#resource-graph-recovery)
- [An external quota becomes the availability boundary](#resource-dependency-failure)
- [ACID transaction lab](#resource-demo-acid-transaction-lab)
- [Orchestration control loop](#resource-demo-orchestration-control-loop)
- [Durable effect retry lab](#resource-demo-durable-effect-retry-lab)
- [CAP partition lab](#resource-demo-cap-partition-lab)
**Task-led explorations:**
- [Follow a fix into running systems](https://scalableweb.dev/explore/verify-remediation/agent.md): A release succeeds and every health check passes. Decide what the runtime inventory still requires you to investigate.
### [Network partition](https://scalableweb.dev/concepts/#partition)
ID: `partition`. Group: Operations.
**Definition:** A disruption that prevents some nodes from communicating while they may continue running and accepting local work.
**Assumptions:** Specify the operation, consistency promise, and what each side may accept. A partition requires an operational choice about unavailable or divergent work.
**Worked example:** Two regions cannot coordinate workspace writes. Either reject or delay some operations to preserve the declared consistency, or accept a weaker promise and reconciliation obligations.
**Common mistake:** A deployment can freely choose consistency and availability as independent switches during a partition. The operation's contract constrains the choice.
**Teaching passages:**
- [Scaling: operational choice](https://scalableweb.dev/chapters/scaling/#partitions-force-an-operational-choice): Explain the consequences for the tracker.
- [Appendix C: partition proof and lab](https://scalableweb.dev/appendices/advanced-web-boundaries/#partitions-and-replicated-state): Examine the guarantees and compare two partition policies.
- [Pressure: documented incidents](https://scalableweb.dev/chapters/reality/#what-documented-web-incidents-reveal): Follow divergent histories during a real partition.
**Readings:**
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
**Graphics and experiments:**
- [Network partition: connections](#resource-graph-partition)
- [CAP partition lab](#resource-demo-cap-partition-lab)
### [Consistency](https://scalableweb.dev/concepts/#consistency)
ID: `consistency`. Group: Architecture.
**Definition:** The promised relationship between operations and the state they can observe across concurrent access and replicated copies.
**Assumptions:** Name the actual guarantee and the relevant operation. Freshness delay, ordering, and durable integrity are related but different questions.
**Worked example:** A committed event may reach a regional feed later. Decide whether that stale read is permitted and how the UI represents pending visibility.
**Common mistake:** All consistency choices are simply strong or eventual. The contract must describe what a consumer can rely on in its specific operation.
**Teaching passages:**
- [Scaling: geography and latency](https://scalableweb.dev/chapters/scaling/#latency-and-geography): Connect distance with observation guarantees.
- [Appendix C: partition proof and lab](https://scalableweb.dev/appendices/advanced-web-boundaries/#partitions-and-replicated-state): Distinguish operation ordering from transaction atomicity.
- [Architecture: data authority](https://scalableweb.dev/chapters/architecture/#data-placement-follows-authority-and-access): Distinguish authoritative state from copies.
**Readings:**
- [4 · Architecture](https://scalableweb.dev/chapters/architecture/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [C · Advanced web boundaries](https://scalableweb.dev/appendices/advanced-web-boundaries/)
**Graphics and experiments:**
- [Consistency: connections](#resource-graph-consistency)
- [ACID transaction lab](#resource-demo-acid-transaction-lab)
- [Cache decision lab](#resource-demo-cache-decision-lab)
- [CAP partition lab](#resource-demo-cap-partition-lab)
- [Latency budget map](#resource-demo-latency-budget-map)
### [Durable workflow](https://scalableweb.dev/concepts/#durable-workflow)
ID: `durable-workflow`. Group: Operations.
**Definition:** Execution that preserves coordination progress so work can resume after interruption without reconstructing every completed step.
**Assumptions:** Persistence of workflow progress does not itself make external effects retry-safe. Audit each effect's authority, operation identity, and uncertain-outcome handling.
**Worked example:** A workflow checkpoints completed rendering and resumes publication after a crash. Publishing still needs a stable identity so an uncertain response cannot create duplicate artifacts.
**Common mistake:** Durable execution guarantees exactly-once external effects. Progress recovery and effect safety are separate guarantees.
**Teaching passages:**
- [Appendix F: preserve coordination progress](https://scalableweb.dev/appendices/durable-workflows/#durable-execution-preserves-coordination-progress): Separate durable coordination from effect semantics.
- [Slideotter: artifact authority](https://scalableweb.dev/case-studies/slideotter/#the-project-found-durable-authority-boundaries): Locate the artifact that generation may replace.
**Readings:**
- [F · Durable workflows](https://scalableweb.dev/appendices/durable-workflows/)
- [Appendices](https://scalableweb.dev/parts/appendices/)
- [Case · Slideotter](https://scalableweb.dev/case-studies/slideotter/)
- [Case · Temper](https://scalableweb.dev/case-studies/temper/)
**Graphics and experiments:**
- [Durable workflow: connections](#resource-graph-durable-workflow)
- [Durable effect retry lab](#resource-demo-durable-effect-retry-lab)
### [Contention](https://scalableweb.dev/concepts/#contention)
ID: `contention`. Group: Models.
**Definition:** Competition for shared resources or coordination that makes additional parallel workers spend more time waiting or synchronizing.
**Assumptions:** Declare the workload and shared resource. Fit or compare a contention model only with suitable measurements; its parameters are not universal constants.
**Worked example:** More event workers compete for the same database lock. Parallelism increases, but completed throughput can plateau or fall as coordination grows.
**Common mistake:** Amdahl's ideal speedup bound accounts for every coordination cost. Added contention can make actual scaling worse than that bound suggests.
**Teaching passages:**
- [Scaling: beyond Amdahl](https://scalableweb.dev/chapters/scaling/#contention-beyond-amdahl-s-bound): Account for costs introduced by parallelism.
- [Appendix E: contention curve](https://scalableweb.dev/appendices/scalability-models/#contention-curve-lab): Compare a model with the observed curve.
**Readings:**
- [7 · Agent fleets](https://scalableweb.dev/chapters/agent-fleets/)
- [8 · Scaling responses](https://scalableweb.dev/chapters/scaling/)
- [E · Scalability models](https://scalableweb.dev/appendices/scalability-models/)
- [Appendices](https://scalableweb.dev/parts/appendices/)
**Graphics and experiments:**
- [Contention: connections](#resource-graph-contention)
- [Contention curve lab](#resource-demo-contention-curve-lab)
### [Lusser's Law](https://scalableweb.dev/concepts/#lusser-law)
ID: `lusser-law`. Group: Models.
**Definition:** For a chain that requires every stage to succeed, independent stage success probabilities multiply to give the chain's success probability.
**Assumptions:** Define an eligible end-to-end attempt and the success criterion at each stage. Independence is a strong assumption; conditional stage success can describe a chain without assuming independence.
**Worked example:** If three required stages each independently succeed with probability 0.99, chain success is 0.99³, about 0.9703. A shared outage invalidates the independence assumption.
**Common mistake:** High component reliability guarantees equally high journey reliability. Required stages accumulate failure opportunities, and common causes can change the calculation.
**Teaching passages:**
- [Appendix E: reliability chain](https://scalableweb.dev/appendices/scalability-models/#lusser-s-law-and-the-reliability-chain): Declare the chain and denominator.
- [Appendix E: test independence](https://scalableweb.dev/appendices/scalability-models/#test-the-independence-assumption): Inspect shared failure rather than assuming it away.
**Readings:**
- [E · Scalability models](https://scalableweb.dev/appendices/scalability-models/)
- [Appendices](https://scalableweb.dev/parts/appendices/)
**Graphics and experiments:**
- [Lusser's Law: connections](#resource-graph-lusser-law)
- [Reliability chain lab](#resource-demo-reliability-chain-lab)
### [Reliability](https://scalableweb.dev/concepts/#reliability)
ID: `reliability`. Group: Models.
**Definition:** The probability or observed proportion of successful outcomes under a declared workload, environment, time horizon, and success criterion.
**Assumptions:** Include all eligible attempts in the denominator and state uncertainty. Agent first-attempt success and eventual success with retries answer different questions.
**Worked example:** A task succeeds on 18 of 20 independent trials under one fixed configuration. Report the trials and uncertainty rather than claiming a general 90% guarantee.
**Common mistake:** One successful run establishes reliability, or success after repeated attempts implies first-attempt reliability.
**Teaching passages:**
- [Appendix A: uncertainty and trials](https://scalableweb.dev/appendices/evaluating-agentic-workflows/#report-uncertainty-not-only-point-estimates): Choose a success summary that matches the question.
- [Appendix E: eligible attempts](https://scalableweb.dev/appendices/scalability-models/#estimate-from-all-eligible-attempts): Preserve the denominator across the journey.
**Readings:**
- [A · Agent evaluation](https://scalableweb.dev/appendices/evaluating-agentic-workflows/)
- [E · Scalability models](https://scalableweb.dev/appendices/scalability-models/)
**Graphics and experiments:**
- [Reliability: connections](#resource-graph-reliability)
- [An external quota becomes the availability boundary](#resource-dependency-failure)
- [Reliability chain lab](#resource-demo-reliability-chain-lab)
## Connections
- [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary) **defines timing scope of** → [Latency](https://scalableweb.dev/concepts/#latency) — The measurement boundary defines which waiting and processing latency includes.
- [Little's Law](https://scalableweb.dev/concepts/#little-law) **requires a shared** → [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary) — Little's Law requires work in progress, rate, and average time to describe the same boundary.
- [Queue](https://scalableweb.dev/concepts/#queue) **can add waiting time to** → [Latency](https://scalableweb.dev/concepts/#latency) — Waiting in a queue contributes to latency when the queue is inside the timing boundary.
- [Throughput](https://scalableweb.dev/concepts/#throughput) — [Queue](https://scalableweb.dev/concepts/#queue) — **arrivals and exits:** Compare admissions with all departures at the queue boundary to explain backlog growth. Useful throughput separately counts completions that meet the declared outcome criteria.
- [Saturation](https://scalableweb.dev/concepts/#saturation) **bounds sustainable** → [Throughput](https://scalableweb.dev/concepts/#throughput) — The saturated stage bounds the sustainable completion rate for the declared workload.
- [Queue](https://scalableweb.dev/concepts/#queue) **can signal** → [Saturation](https://scalableweb.dev/concepts/#saturation) — A growing queue can expose pressure above completion capacity, even while acknowledgments remain fast.
- [Little's Law](https://scalableweb.dev/concepts/#little-law) **accounts for work in** → [Queue](https://scalableweb.dev/concepts/#queue) — Little's Law connects stable work in progress, including queued and processing work, to rate and average time.
- [Little's Law](https://scalableweb.dev/concepts/#little-law) — [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law) — **different questions:** Little's Law checks stable flow averages; Amdahl's Law bounds ideal fixed-workload parallel speedup.
- [Throughput](https://scalableweb.dev/concepts/#throughput) — [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law) — **ideal gain vs output:** An Amdahl speedup bound does not guarantee accepted-change throughput; review, coordination, and correctness still matter.
- [Little's Law](https://scalableweb.dev/concepts/#little-law) **uses average** → [Latency](https://scalableweb.dev/concepts/#latency) — Little's Law uses average time inside the boundary, not a tail percentile such as p95.
- [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering) **designs agent use of** → [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop) — Loop engineering chooses the observations and responses that guide agent work; a feedback loop describes how effects influence subsequent behavior, including harmful reinforcing cycles.
- [Project harness](https://scalableweb.dev/concepts/#harness) **supplies controls for** → [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering) — The project harness supplies maintained instructions, environments, and checks that loop engineering connects to task initiation, progress, repair, and acceptance.
- [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria) **define outcomes for** → [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering) — Acceptance criteria define the result a loop should pursue. A stop condition can also terminate an unsuccessful run at its budget or escalation boundary.
- [Action authorization](https://scalableweb.dev/concepts/#authority) **bounds actions in** → [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering) — A loop may continue only within the granted action authority; starting another iteration or run does not expand permissions.
- [Observability](https://scalableweb.dev/concepts/#observability) **supplies evidence for** → [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering) — Recorded inputs, tool outcomes, failures, and state changes help explain why the loop continued, stopped, or escalated; a successful job status alone can hide an idle or ineffective run.
- [Agent evaluation](https://scalableweb.dev/concepts/#eval) **assesses outcomes of** → [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering) — Representative tasks and independent acceptance evidence can assess a loop change while accounting for retries, resource cost, and human correction.
- [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering) **can coordinate** → [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet) — A loop can assign and verify work across a fleet, but one agent can also operate inside a designed loop. Delegation adds coordination and integration obligations.
- [Review capacity](https://scalableweb.dev/concepts/#review-budget) **constrains admission in** → [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering) — Loop design must account for the owner's capacity to review, correct, and accept work; more autonomous runs can otherwise accumulate an unreviewed backlog.
- [Decision log](https://scalableweb.dev/concepts/#decision-log) **records conditions for** → [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility) — A decision record can state which choices remain soft, what dependencies would make them hard, and what safe reversal would require.
- [Decision log](https://scalableweb.dev/concepts/#decision-log) **records rationale for** → [Trade-off](https://scalableweb.dev/concepts/#trade-off) — The log preserves the alternatives, rationale, and consequences that justified a trade-off under the conditions known at the time.
- [Decision log](https://scalableweb.dev/concepts/#decision-log) — [Project harness](https://scalableweb.dev/concepts/#harness) — **accepted context:** Decision records preserve accepted project context, while current specifications and executable harness checks must reflect the implemented choice.
- [Decision log](https://scalableweb.dev/concepts/#decision-log) — [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop) — **revisit conditions:** A recorded revisit condition makes new evidence a reason to review a choice; a superseding record preserves why the earlier decision changed.
- [Decision log](https://scalableweb.dev/concepts/#decision-log) **can document** → [Technical debt](https://scalableweb.dev/concepts/#technical-debt) — A record makes deliberately accepted debt and its future change cost visible so an owner can review it instead of letting the obligation disappear from view.
- [Decision log](https://scalableweb.dev/concepts/#decision-log) — [Action authorization](https://scalableweb.dev/concepts/#authority) — **decision ownership:** A proposed record does not grant action authority; acceptance needs a named owner, and the record's status must distinguish intent from implementation.
- [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility) — [Technical debt](https://scalableweb.dev/concepts/#technical-debt) — **commitment vs debt:** Technical debt can reduce future options, but a hard decision is not automatically debt; its dependencies and reversal cost may be necessary and justified.
- [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility) — [Development friction](https://scalableweb.dev/concepts/#development-friction) — **reversal cost:** A choice becomes harder to revise as safe reversal requires coordination across data, consumers, and deployment boundaries.
- [Application contract](https://scalableweb.dev/concepts/#contract) **can constrain** → [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility) — An independently deployed consumer relying on a contract can turn a locally editable choice into a hard compatibility commitment.
- [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility) — [Trade-off](https://scalableweb.dev/concepts/#trade-off) — **option value:** Planning a trade-off includes the value of keeping an uncertain choice soft and the obligations introduced by committing to it.
- [Maintainability assessment](https://scalableweb.dev/concepts/#change-probe) **assesses** → [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility) — A bounded change probe can test how much effort a revision requires and which dependencies make a decision hard to change.
- [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility) — [Recovery](https://scalableweb.dev/concepts/#recovery) — **safe reversal:** Reversing a decision after durable effects may require migration or reconciliation; restoring code alone does not establish safe recovery.
- [Development friction](https://scalableweb.dev/concepts/#development-friction) — [Technical debt](https://scalableweb.dev/concepts/#technical-debt) — **change cost:** Friction can expose the practical cost of technical debt, but protective checks and necessary commitments are not automatically debt.
- [Reproducible environment](https://scalableweb.dev/concepts/#reproducible-environment) **can reduce** → [Development friction](https://scalableweb.dev/concepts/#development-friction) — A declared, reproducible environment can reduce setup friction and reveal hidden inputs rather than relying on undocumented repairs.
- [Development friction](https://scalableweb.dev/concepts/#development-friction) — [Application contract](https://scalableweb.dev/concepts/#contract) — **cross-boundary change:** A small feature can create friction as it crosses HTTP, data, cache, and deployment contracts owned at different boundaries.
- [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop) **can reduce** → [Development friction](https://scalableweb.dev/concepts/#development-friction) — Feedback matched to the changed boundary can reduce diagnosis and revision friction while retaining useful checks.
- [Maintainability assessment](https://scalableweb.dev/concepts/#change-probe) **assesses** → [Development friction](https://scalableweb.dev/concepts/#development-friction) — A bounded change probe records concrete blockages and effort so a friction claim can be tested by an unfamiliar maintainer.
- [Development friction](https://scalableweb.dev/concepts/#development-friction) — [Action authorization](https://scalableweb.dev/concepts/#authority) — **protective friction:** Explicit ownership reduces coordination ambiguity; authorization and release gates can remain protective friction when they control a named risk.
- [Scalability](https://scalableweb.dev/concepts/#scalability) **is assessed under** → [Scaling pressure](https://scalableweb.dev/concepts/#pressure) — A scalability claim states which goal must hold as a particular pressure changes.
- [Saturation](https://scalableweb.dev/concepts/#saturation) **can threaten** → [Scalability](https://scalableweb.dev/concepts/#scalability) — Saturation identifies the current limit that threatens the maintained scalability goal.
- [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark) **tests claims of** → [Scalability](https://scalableweb.dev/concepts/#scalability) — A benchmark protocol makes a conditional scalability claim testable.
- [Scalability](https://scalableweb.dev/concepts/#scalability) — [Trade-off](https://scalableweb.dev/concepts/#trade-off) — **response obligations:** A scaling response must justify the costs and obligations it introduces alongside the maintained goal.
- [Scaling pressure](https://scalableweb.dev/concepts/#pressure) **can expose** → [Technical debt](https://scalableweb.dev/concepts/#technical-debt) — Change pressure can expose future change cost from earlier shortcuts, compromises, or unmanaged coupling. A necessary compatibility obligation alone does not establish technical debt.
- [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet) **can create** → [Scaling pressure](https://scalableweb.dev/concepts/#pressure) — Adding contributors or agents increases coordination pressure as well as possible parallelism.
- [Scaling pressure](https://scalableweb.dev/concepts/#pressure) **can motivate** → [Cache](https://scalableweb.dev/concepts/#cache) — Data or demand pressure may motivate caching, but the cache introduces a freshness and access contract.
- [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark) **declares** → [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary) — A benchmark protocol declares the boundary at which elapsed time and completed work are counted.
- [Reproducible environment](https://scalableweb.dev/concepts/#reproducible-environment) **supports repeatable** → [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark) — Reproducible environments help separate implementation differences from setup differences in a benchmark.
- [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark) — [Agent evaluation](https://scalableweb.dev/concepts/#eval) — **shared protocol:** Benchmarks and agent evaluations both require declared tasks, boundaries, outcome criteria, and failure accounting.
- [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark) **declares how to measure** → [Tail latency](https://scalableweb.dev/concepts/#tail-latency) — A benchmark needs a declared latency population and percentile convention to support a tail-latency claim.
- [Latency](https://scalableweb.dev/concepts/#latency) — [Tail latency](https://scalableweb.dev/concepts/#tail-latency) — **mean vs tail:** Tail latency describes slow outcomes that an average elapsed time can hide.
- [Observability](https://scalableweb.dev/concepts/#observability) **can help explain** → [Tail latency](https://scalableweb.dev/concepts/#tail-latency) — Latency distributions reveal a slow population; traces and event records help investigate its path.
- [Observability](https://scalableweb.dev/concepts/#observability) — [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary) — **matched signals:** Useful signals must identify the same logical work and boundaries as the outcome being explained.
- [Observability](https://scalableweb.dev/concepts/#observability) **provides evidence for** → [Recovery](https://scalableweb.dev/concepts/#recovery) — Recovery needs evidence about authoritative state, pending work, and user-visible outcomes, not only process health.
- [Observability](https://scalableweb.dev/concepts/#observability) **supplies signals for** → [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop) — A corrective feedback loop can choose a useful response only when its signals describe the relevant goal and boundary.
- [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop) — [Retry policy](https://scalableweb.dev/concepts/#retry) — **reinforcing load:** Overload can cause timeouts that trigger retries and add more load. A bounded retry policy with delay and admission control can limit this reinforcing feedback; retry-safe effects are still required.
- [Goodhart's Law](https://scalableweb.dev/concepts/#goodhart-law) **warns about targeting** → [Throughput](https://scalableweb.dev/concepts/#throughput) — Counting generated or acknowledged work can become a misleading target when useful accepted completions are the intended outcome.
- [Goodhart's Law](https://scalableweb.dev/concepts/#goodhart-law) — [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria) — **outcome checks:** Acceptance criteria help check the intended outcome when a convenient proxy metric becomes a target.
- [Agent evaluation](https://scalableweb.dev/concepts/#eval) **estimates** → [Reliability](https://scalableweb.dev/concepts/#reliability) — Repeated agent evaluation distinguishes a successful example from evidence about success frequency and uncertainty.
- [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria) **define grading for** → [Agent evaluation](https://scalableweb.dev/concepts/#eval) — An evaluation grader must assess the declared task and invariants rather than hidden acceptance assumptions.
- [Project harness](https://scalableweb.dev/concepts/#harness) **supplies checks for** → [Agent evaluation](https://scalableweb.dev/concepts/#eval) — The project harness supplies reusable checks and setup, while the evaluation harness provisions and scores trials.
- [Maintainability assessment](https://scalableweb.dev/concepts/#change-probe) **can reveal** → [Technical debt](https://scalableweb.dev/concepts/#technical-debt) — A bounded change probe can expose coupling or earlier shortcuts that make a later modification costly even when current behavior tests pass. Use that evidence to distinguish debt from necessary compatibility work.
- [Agent evaluation](https://scalableweb.dev/concepts/#eval) **can include** → [Maintainability assessment](https://scalableweb.dev/concepts/#change-probe) — An agent evaluation can include next-change tasks to assess maintainability beyond initial task success.
- [Reproducible environment](https://scalableweb.dev/concepts/#reproducible-environment) **supports repeatable** → [Maintainability assessment](https://scalableweb.dev/concepts/#change-probe) — An unfamiliar auditor needs a reproducible starting environment to distinguish setup friction from change difficulty.
- [Project harness](https://scalableweb.dev/concepts/#harness) **supplies context for** → [Coding agent](https://scalableweb.dev/concepts/#agent) — An agent's useful capability depends on the project context, tools, checks, and commands supplied by its harness.
- [Action authorization](https://scalableweb.dev/concepts/#authority) **bounds actions of** → [Coding agent](https://scalableweb.dev/concepts/#agent) — An agent's ability to invoke a tool must be bounded by the authority granted for the task.
- [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet) **coordinates** → [Coding agent](https://scalableweb.dev/concepts/#agent) — A fleet extends one agent's execution loop with explicit coordination, integration, and acceptance.
- [Project harness](https://scalableweb.dev/concepts/#harness) **provides checks for** → [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop) — Executable harness checks turn generated work into feedback that can guide a revision.
- [Project harness](https://scalableweb.dev/concepts/#harness) **requires a declared** → [Reproducible environment](https://scalableweb.dev/concepts/#reproducible-environment) — A harness needs a declared environment so its checks can be run by another agent or maintainer.
- [Project harness](https://scalableweb.dev/concepts/#harness) **provides evidence for** → [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria) — Harness checks provide repeatable evidence for acceptance criteria, while a named owner remains accountable for acceptance.
- [Action authorization](https://scalableweb.dev/concepts/#authority) — [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria) — **acceptance ownership:** Authority defines who may execute work and who may judge that the acceptance criteria have been met.
- [Action authorization](https://scalableweb.dev/concepts/#authority) — [Authoritative state](https://scalableweb.dev/concepts/#state-authority) — **permission vs commit:** Action authorization asks who may execute an operation; authoritative state establishes its committed outcome and the boundary responsible for preserving it. An authorized attempt can still fail to commit.
- [Application contract](https://scalableweb.dev/concepts/#contract) **states rules for** → [Action authorization](https://scalableweb.dev/concepts/#authority) — An application contract specifies which actors may invoke an operation and which boundary enforces that permission. A workspace handle or tool credential alone does not authorize every action.
- [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop) — [Technical debt](https://scalableweb.dev/concepts/#technical-debt) — **omitted future cost:** Feedback that omits the cost of later changes can allow technical debt to grow while current tasks pass.
- [Technical debt](https://scalableweb.dev/concepts/#technical-debt) — [Application contract](https://scalableweb.dev/concepts/#contract) — **coupled contracts:** Unclear or tightly coupled contracts can make one local change require coordinated changes elsewhere.
- [Task graph](https://scalableweb.dev/concepts/#task-graph) **organizes work in** → [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet) — A fleet's task graph states what can proceed independently and where contracts or integration impose order.
- [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law) **bounds ideal speedup of** → [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet) — Amdahl's Law provides an ideal bound when part of a fleet's fixed workload remains sequential.
- [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet) — [Review capacity](https://scalableweb.dev/concepts/#review-budget) — **candidate vs accepted:** Additional agents can increase candidate output faster than human review can accept it.
- [Application contract](https://scalableweb.dev/concepts/#contract) **constrains independence in** → [Task graph](https://scalableweb.dev/concepts/#task-graph) — Task independence depends on compatible shared contracts, not merely separate files.
- [Task graph](https://scalableweb.dev/concepts/#task-graph) **requires** → [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria) — Integration points in a task graph need acceptance checks that cover the combined behavior.
- [Review capacity](https://scalableweb.dev/concepts/#review-budget) — [Queue](https://scalableweb.dev/concepts/#queue) — **review backlog:** Candidate changes waiting for review form a queue. Its growth depends on submissions and all departures, including rejection or withdrawal; accepted-change throughput counts only successful acceptance.
- [Review capacity](https://scalableweb.dev/concepts/#review-budget) **can limit accepted** → [Throughput](https://scalableweb.dev/concepts/#throughput) — Reviewer attention and correction effort can limit accepted-change throughput even when generation speeds up.
- [Review capacity](https://scalableweb.dev/concepts/#review-budget) — [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law) — **sequential fraction:** Review or integration that must remain sequential belongs in Amdahl's sequential fraction for a fixed task. A growing review queue asks a separate question about ongoing arrival and completion rates.
- [Review capacity](https://scalableweb.dev/concepts/#review-budget) **can be a limit at** → [Saturation](https://scalableweb.dev/concepts/#saturation) — Human review capacity can be the binding limit when candidate work arrives faster than it can be understood, integrated, and accepted. Increasing generation alone does not expand that capacity.
- [Invariant](https://scalableweb.dev/concepts/#invariant) **constrains transitions in** → [Application contract](https://scalableweb.dev/concepts/#contract) — A contract describes valid boundary behavior; invariants state conditions its accepted transitions must preserve.
- [Application contract](https://scalableweb.dev/concepts/#contract) **defines effects for** → [Idempotency](https://scalableweb.dev/concepts/#idempotency) — The contract names all intended effects against which idempotency is judged. A key-based retry protocol also needs scope, conflict, retention, and outcome rules.
- [Rendering and activation](https://scalableweb.dev/concepts/#rendering) **can affect** → [Latency](https://scalableweb.dev/concepts/#latency) — Moving rendering or activation changes which work lies on the measured user journey.
- [Rendering and activation](https://scalableweb.dev/concepts/#rendering) — [Cache](https://scalableweb.dev/concepts/#cache) — **freshness and activation:** A cached representation needs freshness and activation policies in addition to a fast delivery path.
- [Rendering and activation](https://scalableweb.dev/concepts/#rendering) — [Authoritative state](https://scalableweb.dev/concepts/#state-authority) — **view vs durable state:** Rendering a representation must remain distinct from committing the durable action it displays.
- [Transaction](https://scalableweb.dev/concepts/#transaction) **protects changes to** → [Authoritative state](https://scalableweb.dev/concepts/#state-authority) — Transactions protect related changes at the durable authority under the store's actual guarantees.
- [Authoritative state](https://scalableweb.dev/concepts/#state-authority) **is the source for** → [Cache](https://scalableweb.dev/concepts/#cache) — A cache is a controlled copy whose freshness and invalidation depend on the authoritative state.
- [Consistency](https://scalableweb.dev/concepts/#consistency) **governs observations of** → [Authoritative state](https://scalableweb.dev/concepts/#state-authority) — Consistency promises describe how consumers observe authoritative changes through concurrency and copies.
- [Transaction](https://scalableweb.dev/concepts/#transaction) **must preserve** → [Invariant](https://scalableweb.dev/concepts/#invariant) — The chosen transaction and isolation behavior must preserve the domain invariant under concurrent transitions.
- [Transaction](https://scalableweb.dev/concepts/#transaction) **can support** → [Idempotency](https://scalableweb.dev/concepts/#idempotency) — A key-based command protocol can atomically enforce operation identity with the promised effects and a reusable result at their authority. A transaction alone does not prevent repeated commands.
- [Cache](https://scalableweb.dev/concepts/#cache) **has freshness rules in** → [Consistency](https://scalableweb.dev/concepts/#consistency) — Cache freshness is part of the observation promise, but it does not by itself define every consistency guarantee.
- [Cache](https://scalableweb.dev/concepts/#cache) **introduces** → [Trade-off](https://scalableweb.dev/concepts/#trade-off) — Caching can reduce dependency load while introducing invalidation, freshness, and access obligations.
- [Idempotency](https://scalableweb.dev/concepts/#idempotency) **guards repeated effects of** → [Retry policy](https://scalableweb.dev/concepts/#retry) — A deduplicated command reuses its logical operation identity after an ambiguous outcome so the retry cannot invent another durable action.
- [Idempotency](https://scalableweb.dev/concepts/#idempotency) **guards repeated effects in** → [Durable workflow](https://scalableweb.dev/concepts/#durable-workflow) — Durable coordination can resume steps, while idempotency protects effects that may be attempted again.
- [Retry policy](https://scalableweb.dev/concepts/#retry) **can amplify load at** → [Saturation](https://scalableweb.dev/concepts/#saturation) — Retries can amplify pressure on an already saturated dependency instead of improving useful completion.
- [Retry policy](https://scalableweb.dev/concepts/#retry) **supports bounded replay in** → [Recovery](https://scalableweb.dev/concepts/#recovery) — Bounded retry and backlog replay policies must protect state integrity and capacity during recovery.
- [Admission and backpressure](https://scalableweb.dev/concepts/#backpressure) **can bound admission to** → [Queue](https://scalableweb.dev/concepts/#queue) — A bounded queue requires a policy for slowing or rejecting new work when downstream capacity cannot keep up.
- [Admission and backpressure](https://scalableweb.dev/concepts/#backpressure) **can protect capacity at** → [Saturation](https://scalableweb.dev/concepts/#saturation) — Admission controls can protect a saturated boundary while making rejected or delayed work explicit.
- [Admission and backpressure](https://scalableweb.dev/concepts/#backpressure) **can introduce** → [Trade-off](https://scalableweb.dev/concepts/#trade-off) — Bounding admission can preserve useful service while sacrificing immediate acceptance of some work.
- [Durable workflow](https://scalableweb.dev/concepts/#durable-workflow) **preserves progress for** → [Recovery](https://scalableweb.dev/concepts/#recovery) — Preserved workflow progress helps interrupted coordination resume, but recovery must still audit its effects.
- [Consistency](https://scalableweb.dev/concepts/#consistency) **constrains acceptance during** → [Network partition](https://scalableweb.dev/concepts/#partition) — During a partition, the operation's consistency promise constrains which work disconnected nodes may accept.
- [Recovery](https://scalableweb.dev/concepts/#recovery) **reconciles histories after** → [Network partition](https://scalableweb.dev/concepts/#partition) — Recovery from a partition may require reconciling divergent histories and draining pending work.
- [Consistency](https://scalableweb.dev/concepts/#consistency) **can add delay to** → [Latency](https://scalableweb.dev/concepts/#latency) — Coordinating remote state can add latency; permitting delayed observations changes the consumer's contract.
- [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law) **omits new costs of** → [Contention](https://scalableweb.dev/concepts/#contention) — Amdahl's ideal fixed-workload bound omits new contention and coordination costs introduced by parallelism.
- [Contention](https://scalableweb.dev/concepts/#contention) **can reduce** → [Throughput](https://scalableweb.dev/concepts/#throughput) — Competition for a shared resource can make throughput plateau or decline as workers are added.
- [Contention](https://scalableweb.dev/concepts/#contention) **can expose** → [Saturation](https://scalableweb.dev/concepts/#saturation) — Contention can expose a binding shared-resource limit before every worker is fully utilized.
- [Lusser's Law](https://scalableweb.dev/concepts/#lusser-law) **calculates chain** → [Reliability](https://scalableweb.dev/concepts/#reliability) — Lusser's Law calculates a required-stage chain's reliability under a declared independence assumption.
- [Application contract](https://scalableweb.dev/concepts/#contract) **defines required stages for** → [Lusser's Law](https://scalableweb.dev/concepts/#lusser-law) — The reliability chain includes the stages that must succeed to meet the declared end-to-end contract.
- [Reliability](https://scalableweb.dev/concepts/#reliability) **requires a declared** → [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary) — A reliability claim needs a declared eligible-attempt denominator and end-to-end success boundary.
## Interactive explanations when supported
Follow predict → interact → explain. Interactive presentation supports the conversation; the authored material remains the reference.
Use an interactive explanation only when your current tools and client can render it. Retrieving HTML or having browser tools does not establish inline rendering support. Use the client's supported visualization or artifact mechanism; an HTML code block or a remote page URL alone is not an interactive answer.
Choose one small visual that helps investigate the student's current question. Ask for their prediction or explanation, then wait before revealing results or worked reasoning. Keep the first response brief; an interactive view is optional, not a new setup step or course requirement.
Build from the authored scenario or a retrieved learning resource. Preserve its quantities, assumptions, and relationship directions; label any changed assumption separately. Cite the source and identify the view as an agent-created adaptation. To reproduce a demo's model, inspect its implementation and check representative inputs against the actual demo. Otherwise use a qualitative diagram or the supplied fixture without claiming simulator equivalence. Generated or illustrative outputs are not measured project evidence.
Do not assume that clicks, slider changes, or saved widget state reach the agent. Ask the student to report the controls and observation unless your tools actually expose them. Distinguish their report, your direct observation, and a deduction. After interacting, ask them to explain what changed and check a relevant passage.
Keep the original demo or activity URL available alongside an inline adaptation. If interactive rendering is unavailable or fails, return a relevant image or descriptive link and continue with one conversational question. Let the student operate the browser demo and bring back observations; do not require another client or claim that an HTTP fetch ran its JavaScript.
Possible aids, selected after the student's attempt:
- For caching, use the [cache decision lab](https://scalableweb.dev/demos/#demo-cache-decision-lab) and its catalog assumptions to investigate response age and origin validation.
- For retries, use [the recorder fixture](https://scalableweb.dev/explore/challenge-an-explanation/agent.md) to trace local and durable state across a restart.
- For confidence, use [the classification fixture](https://scalableweb.dev/explore/confidence-before-routing/agent.md) to compare a reported score with reference agreement after the student predicts it.
These suggestions do not add tasks or authorize external actions. Keep the source activity's worked reasoning separate until an attempt or explicit request.
## Graphics and experiments
Demo images are static previews of default views, not live results. Predict before opening a demo, then compare the observations with its assumptions.
### The complete concept graph
ID: `graph-complete`. Kind: graphic. Concepts: [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary), [Throughput](https://scalableweb.dev/concepts/#throughput), [Latency](https://scalableweb.dev/concepts/#latency), [Queue](https://scalableweb.dev/concepts/#queue), [Saturation](https://scalableweb.dev/concepts/#saturation), [Little's Law](https://scalableweb.dev/concepts/#little-law), [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law), [Development friction](https://scalableweb.dev/concepts/#development-friction), [Scalability](https://scalableweb.dev/concepts/#scalability), [Scaling pressure](https://scalableweb.dev/concepts/#pressure), [Trade-off](https://scalableweb.dev/concepts/#trade-off), [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark), [Tail latency](https://scalableweb.dev/concepts/#tail-latency), [Observability](https://scalableweb.dev/concepts/#observability), [Goodhart's Law](https://scalableweb.dev/concepts/#goodhart-law), [Agent evaluation](https://scalableweb.dev/concepts/#eval), [Maintainability assessment](https://scalableweb.dev/concepts/#change-probe), [Coding agent](https://scalableweb.dev/concepts/#agent), [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering), [Project harness](https://scalableweb.dev/concepts/#harness), [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria), [Action authorization](https://scalableweb.dev/concepts/#authority), [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop), [Decision log](https://scalableweb.dev/concepts/#decision-log), [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility), [Technical debt](https://scalableweb.dev/concepts/#technical-debt), [Reproducible environment](https://scalableweb.dev/concepts/#reproducible-environment), [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet), [Task graph](https://scalableweb.dev/concepts/#task-graph), [Review capacity](https://scalableweb.dev/concepts/#review-budget), [Application contract](https://scalableweb.dev/concepts/#contract), [Rendering and activation](https://scalableweb.dev/concepts/#rendering), [Authoritative state](https://scalableweb.dev/concepts/#state-authority), [Transaction](https://scalableweb.dev/concepts/#transaction), [Invariant](https://scalableweb.dev/concepts/#invariant), [Cache](https://scalableweb.dev/concepts/#cache), [Idempotency](https://scalableweb.dev/concepts/#idempotency), [Retry policy](https://scalableweb.dev/concepts/#retry), [Admission and backpressure](https://scalableweb.dev/concepts/#backpressure), [Recovery](https://scalableweb.dev/concepts/#recovery), [Network partition](https://scalableweb.dev/concepts/#partition), [Consistency](https://scalableweb.dev/concepts/#consistency), [Durable workflow](https://scalableweb.dev/concepts/#durable-workflow), [Contention](https://scalableweb.dev/concepts/#contention), [Lusser's Law](https://scalableweb.dev/concepts/#lusser-law), [Reliability](https://scalableweb.dev/concepts/#reliability).
[Source and context](https://scalableweb.dev/concepts/?view=all) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-complete.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-complete.svg)
**Image description:** The complete labelled concept graph. See graph.json or graph.md for the same connections as text.
All concepts and authored connections in the book, with relationship labels and directional arrows.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Measurement boundary: connections
ID: `graph-measurement-boundary`. Kind: graphic. Concepts: [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary).
[Source and context](https://scalableweb.dev/concepts/?topic=measurement-boundary) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-measurement-boundary.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-measurement-boundary.svg)
**Image description:** Labelled connections around Measurement boundary. Read their explanations in the concept graph data.
Measurement boundary and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Throughput: connections
ID: `graph-throughput`. Kind: graphic. Concepts: [Throughput](https://scalableweb.dev/concepts/#throughput).
[Source and context](https://scalableweb.dev/concepts/?topic=throughput) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-throughput.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-throughput.svg)
**Image description:** Labelled connections around Throughput. Read their explanations in the concept graph data.
Throughput and its 6 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Latency: connections
ID: `graph-latency`. Kind: graphic. Concepts: [Latency](https://scalableweb.dev/concepts/#latency).
[Source and context](https://scalableweb.dev/concepts/?topic=latency) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-latency.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-latency.svg)
**Image description:** Labelled connections around Latency. Read their explanations in the concept graph data.
Latency and its 6 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Queue: connections
ID: `graph-queue`. Kind: graphic. Concepts: [Queue](https://scalableweb.dev/concepts/#queue).
[Source and context](https://scalableweb.dev/concepts/?topic=queue) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-queue.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-queue.svg)
**Image description:** Labelled connections around Queue. Read their explanations in the concept graph data.
Queue and its 6 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Saturation: connections
ID: `graph-saturation`. Kind: graphic. Concepts: [Saturation](https://scalableweb.dev/concepts/#saturation).
[Source and context](https://scalableweb.dev/concepts/?topic=saturation) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-saturation.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-saturation.svg)
**Image description:** Labelled connections around Saturation. Read their explanations in the concept graph data.
Saturation and its 7 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Little's Law: connections
ID: `graph-little-law`. Kind: graphic. Concepts: [Little's Law](https://scalableweb.dev/concepts/#little-law).
[Source and context](https://scalableweb.dev/concepts/?topic=little-law) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-little-law.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-little-law.svg)
**Image description:** Labelled connections around Little's Law. Read their explanations in the concept graph data.
Little's Law and its 4 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Amdahl's Law: connections
ID: `graph-amdahl-law`. Kind: graphic. Concepts: [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law).
[Source and context](https://scalableweb.dev/concepts/?topic=amdahl-law) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-amdahl-law.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-amdahl-law.svg)
**Image description:** Labelled connections around Amdahl's Law. Read their explanations in the concept graph data.
Amdahl's Law and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Development friction: connections
ID: `graph-development-friction`. Kind: graphic. Concepts: [Development friction](https://scalableweb.dev/concepts/#development-friction).
[Source and context](https://scalableweb.dev/concepts/?topic=development-friction) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-development-friction.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-development-friction.svg)
**Image description:** Labelled connections around Development friction. Read their explanations in the concept graph data.
Development friction and its 7 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Scalability: connections
ID: `graph-scalability`. Kind: graphic. Concepts: [Scalability](https://scalableweb.dev/concepts/#scalability).
[Source and context](https://scalableweb.dev/concepts/?topic=scalability) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-scalability.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-scalability.svg)
**Image description:** Labelled connections around Scalability. Read their explanations in the concept graph data.
Scalability and its 4 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Scaling pressure: connections
ID: `graph-pressure`. Kind: graphic. Concepts: [Scaling pressure](https://scalableweb.dev/concepts/#pressure).
[Source and context](https://scalableweb.dev/concepts/?topic=pressure) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-pressure.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-pressure.svg)
**Image description:** Labelled connections around Scaling pressure. Read their explanations in the concept graph data.
Scaling pressure and its 4 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Trade-off: connections
ID: `graph-trade-off`. Kind: graphic. Concepts: [Trade-off](https://scalableweb.dev/concepts/#trade-off).
[Source and context](https://scalableweb.dev/concepts/?topic=trade-off) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-trade-off.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-trade-off.svg)
**Image description:** Labelled connections around Trade-off. Read their explanations in the concept graph data.
Trade-off and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Benchmark protocol: connections
ID: `graph-benchmark`. Kind: graphic. Concepts: [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark).
[Source and context](https://scalableweb.dev/concepts/?topic=benchmark) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-benchmark.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-benchmark.svg)
**Image description:** Labelled connections around Benchmark protocol. Read their explanations in the concept graph data.
Benchmark protocol and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Tail latency: connections
ID: `graph-tail-latency`. Kind: graphic. Concepts: [Tail latency](https://scalableweb.dev/concepts/#tail-latency).
[Source and context](https://scalableweb.dev/concepts/?topic=tail-latency) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-tail-latency.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-tail-latency.svg)
**Image description:** Labelled connections around Tail latency. Read their explanations in the concept graph data.
Tail latency and its 3 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Observability: connections
ID: `graph-observability`. Kind: graphic. Concepts: [Observability](https://scalableweb.dev/concepts/#observability).
[Source and context](https://scalableweb.dev/concepts/?topic=observability) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-observability.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-observability.svg)
**Image description:** Labelled connections around Observability. Read their explanations in the concept graph data.
Observability and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Goodhart's Law: connections
ID: `graph-goodhart-law`. Kind: graphic. Concepts: [Goodhart's Law](https://scalableweb.dev/concepts/#goodhart-law).
[Source and context](https://scalableweb.dev/concepts/?topic=goodhart-law) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-goodhart-law.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-goodhart-law.svg)
**Image description:** Labelled connections around Goodhart's Law. Read their explanations in the concept graph data.
Goodhart's Law and its 2 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Agent evaluation: connections
ID: `graph-eval`. Kind: graphic. Concepts: [Agent evaluation](https://scalableweb.dev/concepts/#eval).
[Source and context](https://scalableweb.dev/concepts/?topic=eval) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-eval.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-eval.svg)
**Image description:** Labelled connections around Agent evaluation. Read their explanations in the concept graph data.
Agent evaluation and its 6 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Maintainability assessment: connections
ID: `graph-change-probe`. Kind: graphic. Concepts: [Maintainability assessment](https://scalableweb.dev/concepts/#change-probe).
[Source and context](https://scalableweb.dev/concepts/?topic=change-probe) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-change-probe.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-change-probe.svg)
**Image description:** Labelled connections around Maintainability assessment. Read their explanations in the concept graph data.
Maintainability assessment and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Coding agent: connections
ID: `graph-agent`. Kind: graphic. Concepts: [Coding agent](https://scalableweb.dev/concepts/#agent).
[Source and context](https://scalableweb.dev/concepts/?topic=agent) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-agent.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-agent.svg)
**Image description:** Labelled connections around Coding agent. Read their explanations in the concept graph data.
Coding agent and its 3 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Loop engineering: connections
ID: `graph-loop-engineering`. Kind: graphic. Concepts: [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering).
[Source and context](https://scalableweb.dev/concepts/?topic=loop-engineering) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-loop-engineering.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-loop-engineering.svg)
**Image description:** Labelled connections around Loop engineering. Read their explanations in the concept graph data.
Loop engineering and its 8 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Project harness: connections
ID: `graph-harness`. Kind: graphic. Concepts: [Project harness](https://scalableweb.dev/concepts/#harness).
[Source and context](https://scalableweb.dev/concepts/?topic=harness) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-harness.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-harness.svg)
**Image description:** Labelled connections around Project harness. Read their explanations in the concept graph data.
Project harness and its 7 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Acceptance criteria: connections
ID: `graph-acceptance-criteria`. Kind: graphic. Concepts: [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria).
[Source and context](https://scalableweb.dev/concepts/?topic=acceptance-criteria) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-acceptance-criteria.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-acceptance-criteria.svg)
**Image description:** Labelled connections around Acceptance criteria. Read their explanations in the concept graph data.
Acceptance criteria and its 6 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Action authorization: connections
ID: `graph-authority`. Kind: graphic. Concepts: [Action authorization](https://scalableweb.dev/concepts/#authority).
[Source and context](https://scalableweb.dev/concepts/?topic=authority) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-authority.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-authority.svg)
**Image description:** Labelled connections around Action authorization. Read their explanations in the concept graph data.
Action authorization and its 7 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Feedback loop: connections
ID: `graph-feedback-loop`. Kind: graphic. Concepts: [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop).
[Source and context](https://scalableweb.dev/concepts/?topic=feedback-loop) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-feedback-loop.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-feedback-loop.svg)
**Image description:** Labelled connections around Feedback loop. Read their explanations in the concept graph data.
Feedback loop and its 7 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Decision log: connections
ID: `graph-decision-log`. Kind: graphic. Concepts: [Decision log](https://scalableweb.dev/concepts/#decision-log).
[Source and context](https://scalableweb.dev/concepts/?topic=decision-log) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-decision-log.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-decision-log.svg)
**Image description:** Labelled connections around Decision log. Read their explanations in the concept graph data.
Decision log and its 6 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Decision reversibility: connections
ID: `graph-decision-reversibility`. Kind: graphic. Concepts: [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility).
[Source and context](https://scalableweb.dev/concepts/?topic=decision-reversibility) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-decision-reversibility.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-decision-reversibility.svg)
**Image description:** Labelled connections around Decision reversibility. Read their explanations in the concept graph data.
Decision reversibility and its 7 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Technical debt: connections
ID: `graph-technical-debt`. Kind: graphic. Concepts: [Technical debt](https://scalableweb.dev/concepts/#technical-debt).
[Source and context](https://scalableweb.dev/concepts/?topic=technical-debt) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-technical-debt.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-technical-debt.svg)
**Image description:** Labelled connections around Technical debt. Read their explanations in the concept graph data.
Technical debt and its 7 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Reproducible environment: connections
ID: `graph-reproducible-environment`. Kind: graphic. Concepts: [Reproducible environment](https://scalableweb.dev/concepts/#reproducible-environment).
[Source and context](https://scalableweb.dev/concepts/?topic=reproducible-environment) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-reproducible-environment.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-reproducible-environment.svg)
**Image description:** Labelled connections around Reproducible environment. Read their explanations in the concept graph data.
Reproducible environment and its 4 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Agent fleet: connections
ID: `graph-agent-fleet`. Kind: graphic. Concepts: [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet).
[Source and context](https://scalableweb.dev/concepts/?topic=agent-fleet) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-agent-fleet.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-agent-fleet.svg)
**Image description:** Labelled connections around Agent fleet. Read their explanations in the concept graph data.
Agent fleet and its 6 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Task graph: connections
ID: `graph-task-graph`. Kind: graphic. Concepts: [Task graph](https://scalableweb.dev/concepts/#task-graph).
[Source and context](https://scalableweb.dev/concepts/?topic=task-graph) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-task-graph.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-task-graph.svg)
**Image description:** Labelled connections around Task graph. Read their explanations in the concept graph data.
Task graph and its 3 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Review capacity: connections
ID: `graph-review-budget`. Kind: graphic. Concepts: [Review capacity](https://scalableweb.dev/concepts/#review-budget).
[Source and context](https://scalableweb.dev/concepts/?topic=review-budget) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-review-budget.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-review-budget.svg)
**Image description:** Labelled connections around Review capacity. Read their explanations in the concept graph data.
Review capacity and its 6 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Application contract: connections
ID: `graph-contract`. Kind: graphic. Concepts: [Application contract](https://scalableweb.dev/concepts/#contract).
[Source and context](https://scalableweb.dev/concepts/?topic=contract) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-contract.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-contract.svg)
**Image description:** Labelled connections around Application contract. Read their explanations in the concept graph data.
Application contract and its 8 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Rendering and activation: connections
ID: `graph-rendering`. Kind: graphic. Concepts: [Rendering and activation](https://scalableweb.dev/concepts/#rendering).
[Source and context](https://scalableweb.dev/concepts/?topic=rendering) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-rendering.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-rendering.svg)
**Image description:** Labelled connections around Rendering and activation. Read their explanations in the concept graph data.
Rendering and activation and its 3 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Authoritative state: connections
ID: `graph-state-authority`. Kind: graphic. Concepts: [Authoritative state](https://scalableweb.dev/concepts/#state-authority).
[Source and context](https://scalableweb.dev/concepts/?topic=state-authority) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-state-authority.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-state-authority.svg)
**Image description:** Labelled connections around Authoritative state. Read their explanations in the concept graph data.
Authoritative state and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Transaction: connections
ID: `graph-transaction`. Kind: graphic. Concepts: [Transaction](https://scalableweb.dev/concepts/#transaction).
[Source and context](https://scalableweb.dev/concepts/?topic=transaction) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-transaction.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-transaction.svg)
**Image description:** Labelled connections around Transaction. Read their explanations in the concept graph data.
Transaction and its 3 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Invariant: connections
ID: `graph-invariant`. Kind: graphic. Concepts: [Invariant](https://scalableweb.dev/concepts/#invariant).
[Source and context](https://scalableweb.dev/concepts/?topic=invariant) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-invariant.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-invariant.svg)
**Image description:** Labelled connections around Invariant. Read their explanations in the concept graph data.
Invariant and its 2 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Cache: connections
ID: `graph-cache`. Kind: graphic. Concepts: [Cache](https://scalableweb.dev/concepts/#cache).
[Source and context](https://scalableweb.dev/concepts/?topic=cache) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-cache.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-cache.svg)
**Image description:** Labelled connections around Cache. Read their explanations in the concept graph data.
Cache and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Idempotency: connections
ID: `graph-idempotency`. Kind: graphic. Concepts: [Idempotency](https://scalableweb.dev/concepts/#idempotency).
[Source and context](https://scalableweb.dev/concepts/?topic=idempotency) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-idempotency.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-idempotency.svg)
**Image description:** Labelled connections around Idempotency. Read their explanations in the concept graph data.
Idempotency and its 4 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Retry policy: connections
ID: `graph-retry`. Kind: graphic. Concepts: [Retry policy](https://scalableweb.dev/concepts/#retry).
[Source and context](https://scalableweb.dev/concepts/?topic=retry) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-retry.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-retry.svg)
**Image description:** Labelled connections around Retry policy. Read their explanations in the concept graph data.
Retry policy and its 4 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Admission and backpressure: connections
ID: `graph-backpressure`. Kind: graphic. Concepts: [Admission and backpressure](https://scalableweb.dev/concepts/#backpressure).
[Source and context](https://scalableweb.dev/concepts/?topic=backpressure) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-backpressure.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-backpressure.svg)
**Image description:** Labelled connections around Admission and backpressure. Read their explanations in the concept graph data.
Admission and backpressure and its 3 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Recovery: connections
ID: `graph-recovery`. Kind: graphic. Concepts: [Recovery](https://scalableweb.dev/concepts/#recovery).
[Source and context](https://scalableweb.dev/concepts/?topic=recovery) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-recovery.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-recovery.svg)
**Image description:** Labelled connections around Recovery. Read their explanations in the concept graph data.
Recovery and its 5 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Network partition: connections
ID: `graph-partition`. Kind: graphic. Concepts: [Network partition](https://scalableweb.dev/concepts/#partition).
[Source and context](https://scalableweb.dev/concepts/?topic=partition) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-partition.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-partition.svg)
**Image description:** Labelled connections around Network partition. Read their explanations in the concept graph data.
Network partition and its 2 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Consistency: connections
ID: `graph-consistency`. Kind: graphic. Concepts: [Consistency](https://scalableweb.dev/concepts/#consistency).
[Source and context](https://scalableweb.dev/concepts/?topic=consistency) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-consistency.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-consistency.svg)
**Image description:** Labelled connections around Consistency. Read their explanations in the concept graph data.
Consistency and its 4 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Durable workflow: connections
ID: `graph-durable-workflow`. Kind: graphic. Concepts: [Durable workflow](https://scalableweb.dev/concepts/#durable-workflow).
[Source and context](https://scalableweb.dev/concepts/?topic=durable-workflow) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-durable-workflow.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-durable-workflow.svg)
**Image description:** Labelled connections around Durable workflow. Read their explanations in the concept graph data.
Durable workflow and its 2 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Contention: connections
ID: `graph-contention`. Kind: graphic. Concepts: [Contention](https://scalableweb.dev/concepts/#contention).
[Source and context](https://scalableweb.dev/concepts/?topic=contention) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-contention.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-contention.svg)
**Image description:** Labelled connections around Contention. Read their explanations in the concept graph data.
Contention and its 3 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Lusser's Law: connections
ID: `graph-lusser-law`. Kind: graphic. Concepts: [Lusser's Law](https://scalableweb.dev/concepts/#lusser-law).
[Source and context](https://scalableweb.dev/concepts/?topic=lusser-law) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-lusser-law.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-lusser-law.svg)
**Image description:** Labelled connections around Lusser's Law. Read their explanations in the concept graph data.
Lusser's Law and its 2 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### Reliability: connections
ID: `graph-reliability`. Kind: graphic. Concepts: [Reliability](https://scalableweb.dev/concepts/#reliability).
[Source and context](https://scalableweb.dev/concepts/?topic=reliability) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/graph-reliability.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/graph-reliability.svg)
**Image description:** Labelled connections around Reliability. Read their explanations in the concept graph data.
Reliability and its 3 neighboring concepts. Labels state the authored relationships.
**Assumptions:** Authored teaching connections, not an exhaustive model. Read directed edges as source → label → target; direction alone does not establish causation or a prerequisite. Consult each connection's explanation in the graph data.
### One application, three development systems
ID: `course-progression`. Kind: graphic. Concepts: [Coding agent](https://scalableweb.dev/concepts/#agent), [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet), [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark), [Trade-off](https://scalableweb.dev/concepts/#trade-off), [Acceptance criteria](https://scalableweb.dev/concepts/#acceptance-criteria).
[Source and context](https://scalableweb.dev/chapters/introduction/#course-progression-caption) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/course-progression.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/course-progression.svg)
**Image description:** The task stays comparatively stable while the development system changes. Learning accumulates; application code does not.
The task stays comparatively stable while the development system changes. Learning accumulates; application code does not.
**Assumptions:** The course uses three fresh implementations of a shared specification. Domain knowledge and evidence carry forward; application code and implementation-specific tests do not.
### From pressure to bounded evidence
ID: `pressure-evidence`. Kind: graphic. Concepts: [Scalability](https://scalableweb.dev/concepts/#scalability), [Scaling pressure](https://scalableweb.dev/concepts/#pressure), [Saturation](https://scalableweb.dev/concepts/#saturation), [Trade-off](https://scalableweb.dev/concepts/#trade-off), [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark), [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary).
[Source and context](https://scalableweb.dev/chapters/what-is-scalability/#figure-pressure-evidence) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/pressure-evidence.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/pressure-evidence.svg)
**Image description:** A scaling response remains a hypothesis until bounded evidence challenges the maintained goal, limit, and trade-off.
A scaling response remains a hypothesis until bounded evidence challenges the maintained goal, limit, and trade-off.
**Assumptions:** A named workload, maintained goal, measurement boundary, and conditions are needed to assess the response.
### An external quota becomes the availability boundary
ID: `dependency-failure`. Kind: graphic. Concepts: [Saturation](https://scalableweb.dev/concepts/#saturation), [Reliability](https://scalableweb.dev/concepts/#reliability), [Cache](https://scalableweb.dev/concepts/#cache), [Application contract](https://scalableweb.dev/concepts/#contract), [Scaling pressure](https://scalableweb.dev/concepts/#pressure), [Recovery](https://scalableweb.dev/concepts/#recovery).
[Source and context](https://scalableweb.dev/chapters/reality/#figure-dependency-failure) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/dependency-failure.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/dependency-failure.svg)
**Image description:** Production traffic was amplified into GitHub API traffic until one external quota became the availability boundary for the whole site.
Production traffic was amplified into GitHub API traffic until one external quota became the availability boundary for the whole site.
**Assumptions:** This is the book's specific dependency-failure example. Its chain does not establish that all dependencies fail in the same way.
### Knowledge and artifact ownership
ID: `shared-knowledge-boundary`. Kind: graphic. Concepts: [Application contract](https://scalableweb.dev/concepts/#contract), [Action authorization](https://scalableweb.dev/concepts/#authority), [Project harness](https://scalableweb.dev/concepts/#harness), [Decision reversibility](https://scalableweb.dev/concepts/#decision-reversibility), [Technical debt](https://scalableweb.dev/concepts/#technical-debt).
[Source and context](https://scalableweb.dev/case-studies/kirjolab/#figure-shared-knowledge-boundary) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/shared-knowledge-boundary.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/shared-knowledge-boundary.svg)
**Image description:** Reusable source knowledge stays external; Slideotter and Kirjolab own their artifact-specific decisions.
Reusable source knowledge stays external; Slideotter and Kirjolab own their artifact-specific decisions.
**Assumptions:** Ownership boundaries describe these two products. Evaluate whether the same split fits another system rather than copying it automatically.
### Three connected scalability loops
ID: `three-connected-loops`. Kind: graphic. Concepts: [Scalability](https://scalableweb.dev/concepts/#scalability), [Loop engineering](https://scalableweb.dev/concepts/#loop-engineering), [Scaling pressure](https://scalableweb.dev/concepts/#pressure), [Coding agent](https://scalableweb.dev/concepts/#agent), [Queue](https://scalableweb.dev/concepts/#queue), [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop), [Review capacity](https://scalableweb.dev/concepts/#review-budget), [Throughput](https://scalableweb.dev/concepts/#throughput).
[Source and context](https://scalableweb.dev/chapters/recap/#figure-three-connected-loops) · [Image (PNG)](https://scalableweb.dev/concepts/visuals/three-connected-loops.png) · [Vector image (SVG)](https://scalableweb.dev/concepts/visuals/three-connected-loops.svg)
**Image description:** Pressure becomes development work; accepted agent-assisted change alters the application and its next likely limit.
Pressure becomes development work; accepted agent-assisted change alters the application and its next likely limit.
**Assumptions:** Application, development, and agentic work have distinct completion boundaries. Candidate output is not automatically accepted change.
### Deterministic boundary lab
ID: `demo-deterministic-boundary-lab`. Kind: demo. Concepts: [Invariant](https://scalableweb.dev/concepts/#invariant), [Action authorization](https://scalableweb.dev/concepts/#authority), [Application contract](https://scalableweb.dev/concepts/#contract), [Authoritative state](https://scalableweb.dev/concepts/#state-authority).
[Open demo](https://scalableweb.dev/demos/#demo-deterministic-boundary-lab) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-deterministic-boundary-lab.png)
**Image description:** Deterministic boundary lab: static preview of the default demo view. Follow accepted and rejected transitions through a delivery statechart.
Follow accepted and rejected transitions through a delivery statechart.
**Assumptions:** TESTS_PASS is a supplied event, not an executed application test. The statechart models a declared delivery protocol. It does not by itself authorize real operations or guarantee durable effects.
**Controls:** Scenario and transition actions; Premature RELEASE proposal; Cancellation; Statechart inspection.
**Predict first:** Which state or guard should prevent the next proposed action, and why?
**Try:** Propose RELEASE before checks pass; inspect the rejected event and unchanged state. Then follow a valid route or cancel.
**Observe:** Compare state, enabled actions, and the shared parent cancellation rule.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### ACID transaction lab
ID: `demo-acid-transaction-lab`. Kind: demo. Concepts: [Transaction](https://scalableweb.dev/concepts/#transaction), [Invariant](https://scalableweb.dev/concepts/#invariant), [Authoritative state](https://scalableweb.dev/concepts/#state-authority), [Consistency](https://scalableweb.dev/concepts/#consistency), [Recovery](https://scalableweb.dev/concepts/#recovery).
[Open demo](https://scalableweb.dev/demos/#demo-acid-transaction-lab) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-acid-transaction-lab.png)
**Image description:** ACID transaction lab: static preview of the default demo view. Inspect lifecycle and ledger records under failed writes, concurrency, and restart.
Inspect lifecycle and ledger records under failed writes, concurrency, and restart.
**Assumptions:** These are authored ledger traces, not database execution. The restart case holds the transaction fixed and varies acknowledgement timing. The concurrency case assumes a stale application check followed by an unconditional write; the displayed conditional-write alternative is pseudocode, not executed SQL. Check the deployed store's guarantees.
**Controls:** Disturbance; Separate writes or transaction; Read committed or serializable isolation; Reply before or after durable commit on restart.
**Predict first:** Which invariant could fail between two application-managed writes?
**Try:** For failure compare separate writes and a transaction; for concurrency inspect the stale-check program before varying isolation. For restart keep the durable transaction fixed and vary reply timing.
**Observe:** Inspect the lifecycle and activity ledger together rather than inferring correctness from a response.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Cache decision lab
ID: `demo-cache-decision-lab`. Kind: demo. Concepts: [Cache](https://scalableweb.dev/concepts/#cache), [Application contract](https://scalableweb.dev/concepts/#contract), [Consistency](https://scalableweb.dev/concepts/#consistency), [Trade-off](https://scalableweb.dev/concepts/#trade-off).
[Open demo](https://scalableweb.dev/demos/#demo-cache-decision-lab) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-cache-decision-lab.png)
**Image description:** Cache decision lab: static preview of the default demo view. Trace reuse, validation, and stale responses under different HTTP cache policies.
Trace reuse, validation, and stale responses under different HTTP cache policies.
**Assumptions:** Warm browser and shared entries of the same age; a stale browser entry is forwarded and only the shared cache uses the stale window. Request overrides and browser SWR behavior need separate verification.
**Controls:** Response policy; Time since storage; Changed origin representation.
**Predict first:** Which policy can reuse a response without contacting the origin, and what freshness promise does that make?
**Try:** Change policy and response age, then mark the origin representation as changed.
**Observe:** Distinguish stored data, validation, and what the caller actually receives.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Web architecture lens
ID: `demo-web-architecture-lens`. Kind: demo. Concepts: [Rendering and activation](https://scalableweb.dev/concepts/#rendering), [Application contract](https://scalableweb.dev/concepts/#contract), [Authoritative state](https://scalableweb.dev/concepts/#state-authority), [Latency](https://scalableweb.dev/concepts/#latency), [Trade-off](https://scalableweb.dev/concepts/#trade-off).
[Open demo](https://scalableweb.dev/demos/#demo-web-architecture-lens) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-web-architecture-lens.png)
**Image description:** Web architecture lens: static preview of the default demo view. Compare page navigation, HTML fragments, and browser-built views for the same operation.
Compare page navigation, HTML fragments, and browser-built views for the same operation.
**Assumptions:** Three representative modeled exchanges, with no network calls or payload estimates. Draft restoration is an explicit application choice, not a guarantee of an architecture.
**Controls:** Document, HTML fragment, or JSON update; Unsaved note; Explicit draft restoration; Reveal modeled update.
**Predict first:** Which local state might be lost when an action causes a full-page navigation?
**Try:** Create a local draft and perform the same action in two interaction modes.
**Observe:** Inspect the exchanged representation, state ownership, and preserved browser state.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Tail latency simulator
ID: `demo-tail-latency-simulator`. Kind: demo. Concepts: [Latency](https://scalableweb.dev/concepts/#latency), [Tail latency](https://scalableweb.dev/concepts/#tail-latency), [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark), [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary).
[Open demo](https://scalableweb.dev/demos/#demo-tail-latency-simulator) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-tail-latency-simulator.png)
**Image description:** Tail latency simulator: static preview of the default demo view. Compare average latency and p95 when a minority of requests take a slow path.
Compare average latency and p95 when a minority of requests take a slow path.
**Assumptions:** A constructed population of 60 records, nearest-rank p95 at rank 57. No queueing or capacity model; a passing p95 can leave three slower requests outside it.
**Controls:** Slow-path fraction; Average and p95 objective; Prediction and simulation.
**Predict first:** Will the average and p95 cross the objective together when only a minority of requests become slow?
**Try:** Keep the objective fixed and compare 5% with 10% slow paths.
**Observe:** Inspect ordered records, rank 57 and the count missing the objective alongside average and p95.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Browser performance workbench
ID: `demo-browser-performance-workbench`. Kind: demo. Concepts: [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark), [Latency](https://scalableweb.dev/concepts/#latency), [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary), [Rendering and activation](https://scalableweb.dev/concepts/#rendering).
[Open demo](https://scalableweb.dev/demos/#demo-browser-performance-workbench) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-browser-performance-workbench.png)
**Image description:** Browser performance workbench: static preview of the default demo view. Measure total time and instrumented JavaScript slices while yielding or blocking the main thread.
Measure total time and instrumented JavaScript slices while yielding or blocking the main thread.
**Assumptions:** Measurements are browser- and workload-specific. Frame callbacks are a scheduling proxy; slices exclude later layout and rendering.
**Controls:** Rendered event count; One task or yielded batches; Repeated measurements.
**Predict first:** Which strategy will have the shorter total time, and which the shorter longest JavaScript slice?
**Try:** Run both strategies five times with the same event count.
**Observe:** Compare distributions and timer boundaries before claiming an improvement in user-visible response.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### OpenTelemetry trace explorer
ID: `demo-opentelemetry-trace-explorer`. Kind: demo. Concepts: [Observability](https://scalableweb.dev/concepts/#observability), [Latency](https://scalableweb.dev/concepts/#latency), [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary), [Retry policy](https://scalableweb.dev/concepts/#retry).
[Open demo](https://scalableweb.dev/demos/#demo-opentelemetry-trace-explorer) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-opentelemetry-trace-explorer.png)
**Image description:** OpenTelemetry trace explorer: static preview of the default demo view. Inspect spans, timing, and retries within a simulated server request trace.
Inspect spans, timing, and retries within a simulated server request trace.
**Assumptions:** The timeline covers server handling, excluding browser work and time outside the server span. No incoming parent context is modeled. Literal OTLP uses typed values and a more verbose envelope; a trace is not proof of every user-visible outcome.
**Controls:** Request A, B, or C; Span selection; Reveal authored interpretation.
**Predict first:** Which span would account for the additional time in the slow or retried request?
**Try:** Compare unlabeled request cases, select a child span as evidence, then reveal the authored interpretation. Instrument one operation in your own project for actual trace evidence.
**Observe:** Relate span timing, parentage, and events to the declared request boundary.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Fleet trace debugger
ID: `demo-fleet-trace-debugger`. Kind: demo. Concepts: [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet), [Action authorization](https://scalableweb.dev/concepts/#authority), [Observability](https://scalableweb.dev/concepts/#observability), [Benchmark protocol](https://scalableweb.dev/concepts/#benchmark), [Authoritative state](https://scalableweb.dev/concepts/#state-authority).
[Open demo](https://scalableweb.dev/demos/#demo-fleet-trace-debugger) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-fleet-trace-debugger.png)
**Image description:** Fleet trace debugger: static preview of the default demo view. Reconcile orchestration intent, gateway decisions, and the physical execution ledger.
Reconcile orchestration intent, gateway decisions, and the physical execution ledger.
**Assumptions:** Count each physical row once, including failed, cancelled, and unmatched work. Missing linking evidence must remain unmatched.
**Controls:** Trace inspection; Run attribution; Physical ledger accounting.
**Predict first:** Which records prove execution, and which express only an intended or authorized action?
**Try:** Attribute records to R41, R42, or unmatched using the available linking evidence.
**Observe:** Compare the physical ledger with orchestration intent and identify unsupported attribution.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Reliability chain lab
ID: `demo-reliability-chain-lab`. Kind: demo. Concepts: [Lusser's Law](https://scalableweb.dev/concepts/#lusser-law), [Reliability](https://scalableweb.dev/concepts/#reliability), [Application contract](https://scalableweb.dev/concepts/#contract), [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary).
[Open demo](https://scalableweb.dev/demos/#demo-reliability-chain-lab) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-reliability-chain-lab.png)
**Image description:** Reliability chain lab: static preview of the default demo view. Calculate a required-stage chain's reliability under explicit independence and repair assumptions.
Calculate a required-stage chain's reliability under explicit independence and repair assumptions.
**Assumptions:** Identical independent required steps; the first terminal outcome decides the run. Correlated failures or optional stages require a different model.
**Controls:** Initial correctness; Error detection; Repair success; Critical step count.
**Predict first:** How will doubling the required step count affect end-to-end success if per-step behavior stays fixed?
**Try:** Keep correctness, detection, and repair fixed; compare two critical step counts.
**Observe:** Separate per-step success, chain success and wrong results; distinguish an already-met target from absent detection or required repair.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Sequential work bound
ID: `demo-sequential-work-bound`. Kind: demo. Concepts: [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law), [Agent fleet](https://scalableweb.dev/concepts/#agent-fleet), [Review capacity](https://scalableweb.dev/concepts/#review-budget), [Throughput](https://scalableweb.dev/concepts/#throughput).
[Open demo](https://scalableweb.dev/demos/#demo-sequential-work-bound) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-sequential-work-bound.png)
**Image description:** Sequential work bound: static preview of the default demo view. Inspect the ideal speedup bound when part of a fixed workload stays sequential.
Inspect the ideal speedup bound when part of a fixed workload stays sequential.
**Assumptions:** Amdahl's ideal fixed-workload model excludes new coordination, contention, conflicts, retries, and review queues.
**Controls:** Parallelizable fraction; Agent count.
**Predict first:** With 80% parallelizable work, will increasing from four to eight agents double speedup?
**Try:** Set parallelizable work to 80% and compare four and eight agents.
**Observe:** Inspect the unchanged sequential work and explain why accepted-change throughput is a separate claim.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Saturation boundary lab
ID: `demo-saturation-boundary-lab`. Kind: demo. Concepts: [Saturation](https://scalableweb.dev/concepts/#saturation), [Throughput](https://scalableweb.dev/concepts/#throughput), [Queue](https://scalableweb.dev/concepts/#queue), [Admission and backpressure](https://scalableweb.dev/concepts/#backpressure), [Scaling pressure](https://scalableweb.dev/concepts/#pressure).
[Open demo](https://scalableweb.dev/demos/#demo-saturation-boundary-lab) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-saturation-boundary-lab.png)
**Image description:** Saturation boundary lab: static preview of the default demo view. Compare offered, admitted and completed event rates and move the binding limit.
Compare offered, admitted and completed event rates and move the binding limit.
**Assumptions:** Steady rates, one visit per stage, successful work, and a buffer before the pipeline. Completion is the minimum admitted rate and stage capacity. Bars compare admitted rates to limits, not measured utilization.
**Controls:** Offered load; Stage capacities; Limit admission to bottleneck rate.
**Predict first:** If you raise only the database capacity, which stage will limit completion next?
**Try:** Predict the next limit, expand the current one and compare the recorded before/after. Enable admission limiting and compare admitted, completed, queued and rejected work.
**Observe:** Distinguish spare capacity, zero headroom at the limit and excess demand; inspect backlog or explicit rejection and the newly limiting stage.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Contention curve lab
ID: `demo-contention-curve-lab`. Kind: demo. Concepts: [Contention](https://scalableweb.dev/concepts/#contention), [Throughput](https://scalableweb.dev/concepts/#throughput), [Saturation](https://scalableweb.dev/concepts/#saturation), [Amdahl's Law](https://scalableweb.dev/concepts/#amdahl-law).
[Open demo](https://scalableweb.dev/demos/#demo-contention-curve-lab) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-contention-curve-lab.png)
**Image description:** Contention curve lab: static preview of the default demo view. Explore a modeled capacity curve as contention and coherency costs change.
Explore a modeled capacity curve as contention and coherency costs change.
**Assumptions:** A parameterized Universal Scalability Law model. Coefficients require workload-specific evidence before predicting real capacity.
**Controls:** Contention coefficient; Coherency coefficient; Worker concurrency.
**Predict first:** Will adding workers always increase capacity when coherency cost is nonzero?
**Try:** Vary concurrency with fixed costs; then set both costs to zero and distinguish an interior peak from the largest displayed value.
**Observe:** Identify plateau or decline where shown; a rising chart endpoint is not an optimum. Distinguish this model from Amdahl's ideal bound.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Orchestration control loop
ID: `demo-orchestration-control-loop`. Kind: demo. Concepts: [Feedback loop](https://scalableweb.dev/concepts/#feedback-loop), [Recovery](https://scalableweb.dev/concepts/#recovery), [Authoritative state](https://scalableweb.dev/concepts/#state-authority), [Scaling pressure](https://scalableweb.dev/concepts/#pressure), [Application contract](https://scalableweb.dev/concepts/#contract).
[Open demo](https://scalableweb.dev/demos/#demo-orchestration-control-loop) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-orchestration-control-loop.png)
**Image description:** Orchestration control loop: static preview of the default demo view. Follow controller actions that reconcile observed replicas with desired state.
Follow controller actions that reconcile observed replicas with desired state.
**Assumptions:** A simplified control loop; restoring replica count does not establish application correctness or recovery of durable effects.
**Controls:** Desired replicas; Controller and failure actions; Send simulated request; Roll back to v1.
**Predict first:** After losing a replica, what discrepancy should the controller observe and what action should follow?
**Try:** Deploy running-but-broken v2, send a simulated request and reconcile replicas. Compare HTTP 500 with the response after rollback to v1.
**Observe:** Separate replica convergence from useful HTTP responses; retain failed responses in the request log.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Durable effect retry lab
ID: `demo-durable-effect-retry-lab`. Kind: demo. Concepts: [Durable workflow](https://scalableweb.dev/concepts/#durable-workflow), [Retry policy](https://scalableweb.dev/concepts/#retry), [Idempotency](https://scalableweb.dev/concepts/#idempotency), [Authoritative state](https://scalableweb.dev/concepts/#state-authority), [Recovery](https://scalableweb.dev/concepts/#recovery).
[Open demo](https://scalableweb.dev/demos/#demo-durable-effect-retry-lab) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-durable-effect-retry-lab.png)
**Image description:** Durable effect retry lab: static preview of the default demo view. Stop a worker after an external effect but before its completion enters durable history.
Stop a worker after an external effect but before its completion enters durable history.
**Assumptions:** All counts and history here are an in-memory model; the persisted-retry workspace exercise supplies real SQLite/process evidence. The failure is outside the workflow history boundary. Retry safety depends on the receiver atomically preserving operation identity with the effect.
**Controls:** Retry policy; Reused business key or fresh attempt key; Receiver deduplication; Prediction and failure window.
**Predict first:** If the receiver applied the effect but completion was not recorded, what could make a retry apply it twice?
**Try:** Stop in the failure window, then compare key reuse and receiver deduplication choices.
**Observe:** Count external effects separately from attempts and preserved workflow progress.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### CAP partition lab
ID: `demo-cap-partition-lab`. Kind: demo. Concepts: [Network partition](https://scalableweb.dev/concepts/#partition), [Consistency](https://scalableweb.dev/concepts/#consistency), [Invariant](https://scalableweb.dev/concepts/#invariant), [Authoritative state](https://scalableweb.dev/concepts/#state-authority), [Recovery](https://scalableweb.dev/concepts/#recovery).
[Open demo](https://scalableweb.dev/demos/#demo-cap-partition-lab) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-cap-partition-lab.png)
**Image description:** CAP partition lab: static preview of the default demo view. Compare conflicting writes across a network split under quorum and local-acceptance policies.
Compare conflicting writes across a network split under quorum and local-acceptance policies.
**Assumptions:** An operation-specific consistency scenario. Repair cannot retract a success response already observed by a client.
**Controls:** Quorum or accept-in-every-region policy; Partition, writes, and repair actions.
**Predict first:** Can both sides acknowledge a conflicting start operation while preserving the declared invariant?
**Try:** Partition Helsinki from the majority, submit both writes, and compare policies before repair.
**Observe:** Record acknowledgments, state divergence, and what reconciliation can and cannot fix.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
### Latency budget map
ID: `demo-latency-budget-map`. Kind: demo. Concepts: [Latency](https://scalableweb.dev/concepts/#latency), [Measurement boundary](https://scalableweb.dev/concepts/#measurement-boundary), [Consistency](https://scalableweb.dev/concepts/#consistency), [Trade-off](https://scalableweb.dev/concepts/#trade-off), [Cache](https://scalableweb.dev/concepts/#cache).
[Open demo](https://scalableweb.dev/demos/#demo-latency-budget-map) · [Static preview (PNG)](https://scalableweb.dev/concepts/visuals/demo-latency-budget-map.png)
**Image description:** Latency budget map: static preview of the default demo view. Estimate latency contributions from geography, round trips, and execution time.
Estimate latency contributions from geography, round trips, and execution time.
**Assumptions:** Hypothetical timings and a propagation floor, not hardware classes or deployment advice. Batching requires identical query results, unchanged execution cost and dependencies fitting into at most two trips.
**Controls:** User–application and application–database distances; Network multiplier; Sequential query count; Query and application work.
**Predict first:** Which will matter more in your scenario: faster query execution or fewer sequential remote round trips?
**Try:** Keep placement fixed and vary query count; then keep work fixed and move the database.
**Observe:** Compare sequential and batched response budgets side by side, explain when batching is possible and identify omitted costs.
**Reflect:** Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system.
## Course-task starting points
These optional activities connect a course decision to the graph. Retrieve a starting point to investigate one question at a time; worked reasoning is separate.
- **Establish: [Move a prototype into shared use](https://scalableweb.dev/explore/prototype-to-shared-use/agent.md)** — A working CSV exporter is ready for a demo. What would make it ready for a team's weekly report? Use with [Establish the evidence baseline](https://scalableweb.dev/project/establish/#establish-the-evidence-baseline); [read without an agent](https://scalableweb.dev/explore/prototype-to-shared-use/).
- **Establish: [Challenge an explanation](https://scalableweb.dev/explore/challenge-an-explanation/agent.md)** — An agent says a recorder prevents duplicate events after restart. Predict the behavior and test its claim. Use with [Establish the evidence baseline](https://scalableweb.dev/project/establish/#establish-the-evidence-baseline); [read without an agent](https://scalableweb.dev/explore/challenge-an-explanation/).
- **Establish: [Compare evidence for an agent repair](https://scalableweb.dev/explore/telemetry-guided-repair/agent.md)** — Saving an event reports success, but the list stays unchanged. Compare task feedback, runtime logs, and a diagnostic brief. Use with [Establish the evidence baseline](https://scalableweb.dev/project/establish/#establish-the-evidence-baseline); [read without an agent](https://scalableweb.dev/explore/telemetry-guided-repair/).
- **Challenge: [Follow a fix into running systems](https://scalableweb.dev/explore/verify-remediation/agent.md)** — A release succeeds and every health check passes. Decide what the runtime inventory still requires you to investigate. Use with [Apply runtime pressure and examine recovery](https://scalableweb.dev/project/challenge/#apply-runtime-pressure); [read without an agent](https://scalableweb.dev/explore/verify-remediation/).
- **Challenge: [Probe an API with temporary clients](https://scalableweb.dev/explore/temporary-api-consumers/agent.md)** — A generated CSV client reports success but exports two rows. Design independent checks for a fixed paginated event feed. Use with [Repeat the evidence collection](https://scalableweb.dev/project/challenge/#repeat-the-evidence-collection); [read without an agent](https://scalableweb.dev/explore/temporary-api-consumers/).
- **Compare: [Vary human work in progress](https://scalableweb.dev/explore/human-work-in-progress/agent.md)** — Keep the same worker limit while changing how many unfinished changes enter the workflow. Plan a bounded comparison. Use with [Compare one agent with the fleet](https://scalableweb.dev/project/compare/#compare-one-agent-with-the-fleet); [read without an agent](https://scalableweb.dev/explore/human-work-in-progress/).
- **Compare: [Examine a confident classification](https://scalableweb.dev/explore/confidence-before-routing/agent.md)** — Twenty valid classifications report 90% confidence. Examine the evidence before using that score to route work. Use with [Compare one agent with the fleet](https://scalableweb.dev/project/compare/#compare-one-agent-with-the-fleet); [read without an agent](https://scalableweb.dev/explore/confidence-before-routing/).