{
  "schemaVersion": 2,
  "revision": "9950e02439aeef7bf144499deaf43293d0dfe318644d7a29738225b047e4f3ed",
  "title": "Elements of Scalable Web Development",
  "url": "https://scalableweb.dev/concepts/",
  "resources": {
    "guide": "https://scalableweb.dev/concepts/agent-guide.md",
    "json": "https://scalableweb.dev/concepts/graph.json",
    "markdown": "https://scalableweb.dev/concepts/graph.md",
    "explorations": "https://scalableweb.dev/explore/index.json",
    "explorationIndex": "https://scalableweb.dev/explore/",
    "mcp": "https://scalableweb.dev/mcp",
    "agentSetup": "https://scalableweb.dev/agents/"
  },
  "semantics": {
    "relationships": "Authored teaching connections with explicit directed or undirected semantics.",
    "sourceAndTarget": "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.",
    "readingMembership": "A concept is discussed in a reading. Co-occurrence does not create a graph edge.",
    "coverage": "A curated guide to the book, not an exhaustive account of possible connections.",
    "learningResources": "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.",
    "explorations": "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.",
    "agentPresentation": "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."
  },
  "agentPresentation": {
    "sequence": [
      "predict",
      "interact",
      "explain"
    ],
    "inline": {
      "capability": "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.",
      "pacing": "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.",
      "fidelity": "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.",
      "state": "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."
    },
    "fallback": "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."
  },
  "readingActivities": [
    {
      "id": "learning-loop",
      "version": 1,
      "title": "Make sense of this idea",
      "reading": "",
      "conceptIds": [],
      "phases": [
        {
          "id": "predict",
          "prompt": "What do you think so far? Start with an explanation, a prediction or an uncertainty."
        },
        {
          "id": "experiment",
          "prompt": "Try one check: revisit the passage, compare a case or test an assumption. What did you find, and where does that evidence come from?"
        },
        {
          "id": "reflect",
          "prompt": "What can you explain now? What remains uncertain, and what will you check next?"
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied.",
      "observation": {
        "kind": "student-report",
        "fields": [
          "evidence",
          "nextCheck"
        ],
        "authority": "The student describes a check and its evidence. This is a report, not proof of execution. Public MCP supplies the authored loop, never private learning state."
      }
    },
    {
      "id": "investigate-demo-deterministic-boundary-lab",
      "version": 2,
      "demoId": "demo-deterministic-boundary-lab",
      "title": "Deterministic boundary lab",
      "reading": "/demos/#demo-deterministic-boundary-lab",
      "conceptIds": [
        "invariant",
        "authority",
        "contract",
        "state-authority"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Which state or guard should prevent the next proposed action, and why?"
        },
        {
          "id": "experiment",
          "prompt": "Propose RELEASE before checks pass; inspect the rejected event and unchanged state. Then follow a valid route or cancel. Compare state, enabled actions, and the shared parent cancellation rule."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-acid-transaction-lab",
      "version": 3,
      "demoId": "demo-acid-transaction-lab",
      "title": "ACID transaction lab",
      "reading": "/demos/#demo-acid-transaction-lab",
      "conceptIds": [
        "transaction",
        "invariant",
        "state-authority",
        "consistency",
        "recovery"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Which invariant could fail between two application-managed writes?"
        },
        {
          "id": "experiment",
          "prompt": "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. Inspect the lifecycle and activity ledger together rather than inferring correctness from a response."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-cache-decision-lab",
      "version": 2,
      "demoId": "demo-cache-decision-lab",
      "title": "Cache decision lab",
      "reading": "/demos/#demo-cache-decision-lab",
      "conceptIds": [
        "cache",
        "contract",
        "consistency",
        "trade-off"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Which policy can reuse a response without contacting the origin, and what freshness promise does that make?"
        },
        {
          "id": "experiment",
          "prompt": "Change policy and response age, then mark the origin representation as changed. Distinguish stored data, validation, and what the caller actually receives."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-web-architecture-lens",
      "version": 2,
      "demoId": "demo-web-architecture-lens",
      "title": "Web architecture lens",
      "reading": "/demos/#demo-web-architecture-lens",
      "conceptIds": [
        "rendering",
        "contract",
        "state-authority",
        "latency",
        "trade-off"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Which local state might be lost when an action causes a full-page navigation?"
        },
        {
          "id": "experiment",
          "prompt": "Create a local draft and perform the same action in two interaction modes. Inspect the exchanged representation, state ownership, and preserved browser state."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-tail-latency-simulator",
      "version": 2,
      "demoId": "demo-tail-latency-simulator",
      "title": "Tail latency simulator",
      "reading": "/demos/#demo-tail-latency-simulator",
      "conceptIds": [
        "latency",
        "tail-latency",
        "benchmark",
        "measurement-boundary"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Will the average and p95 cross the objective together when only a minority of requests become slow?"
        },
        {
          "id": "experiment",
          "prompt": "Keep the objective fixed and compare 5% with 10% slow paths. Inspect ordered records, rank 57 and the count missing the objective alongside average and p95."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-browser-performance-workbench",
      "version": 1,
      "demoId": "demo-browser-performance-workbench",
      "title": "Browser performance workbench",
      "reading": "/demos/#demo-browser-performance-workbench",
      "conceptIds": [
        "benchmark",
        "latency",
        "measurement-boundary",
        "rendering"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Which strategy will have the shorter total time, and which the shorter longest JavaScript slice?"
        },
        {
          "id": "experiment",
          "prompt": "Run both strategies five times with the same event count. Compare distributions and timer boundaries before claiming an improvement in user-visible response."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored assumptions: Measurements are browser- and workload-specific. Frame callbacks are a scheduling proxy; slices exclude later layout and rendering.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-opentelemetry-trace-explorer",
      "version": 2,
      "demoId": "demo-opentelemetry-trace-explorer",
      "title": "OpenTelemetry trace explorer",
      "reading": "/demos/#demo-opentelemetry-trace-explorer",
      "conceptIds": [
        "observability",
        "latency",
        "measurement-boundary",
        "retry"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Which span would account for the additional time in the slow or retried request?"
        },
        {
          "id": "experiment",
          "prompt": "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. Relate span timing, parentage, and events to the declared request boundary."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-fleet-trace-debugger",
      "version": 1,
      "demoId": "demo-fleet-trace-debugger",
      "title": "Fleet trace debugger",
      "reading": "/demos/#demo-fleet-trace-debugger",
      "conceptIds": [
        "agent-fleet",
        "authority",
        "observability",
        "benchmark",
        "state-authority"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Which records prove execution, and which express only an intended or authorized action?"
        },
        {
          "id": "experiment",
          "prompt": "Attribute records to R41, R42, or unmatched using the available linking evidence. Compare the physical ledger with orchestration intent and identify unsupported attribution."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored assumptions: Count each physical row once, including failed, cancelled, and unmatched work. Missing linking evidence must remain unmatched.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-reliability-chain-lab",
      "version": 2,
      "demoId": "demo-reliability-chain-lab",
      "title": "Reliability chain lab",
      "reading": "/demos/#demo-reliability-chain-lab",
      "conceptIds": [
        "lusser-law",
        "reliability",
        "contract",
        "measurement-boundary"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "How will doubling the required step count affect end-to-end success if per-step behavior stays fixed?"
        },
        {
          "id": "experiment",
          "prompt": "Keep correctness, detection, and repair fixed; compare two critical step counts. Separate per-step success, chain success and wrong results; distinguish an already-met target from absent detection or required repair."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored assumptions: Identical independent required steps; the first terminal outcome decides the run. Correlated failures or optional stages require a different model.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-sequential-work-bound",
      "version": 1,
      "demoId": "demo-sequential-work-bound",
      "title": "Sequential work bound",
      "reading": "/demos/#demo-sequential-work-bound",
      "conceptIds": [
        "amdahl-law",
        "agent-fleet",
        "review-budget",
        "throughput"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "With 80% parallelizable work, will increasing from four to eight agents double speedup?"
        },
        {
          "id": "experiment",
          "prompt": "Set parallelizable work to 80% and compare four and eight agents. Inspect the unchanged sequential work and explain why accepted-change throughput is a separate claim."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored assumptions: Amdahl's ideal fixed-workload model excludes new coordination, contention, conflicts, retries, and review queues.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-saturation-boundary-lab",
      "version": 3,
      "demoId": "demo-saturation-boundary-lab",
      "title": "Saturation boundary lab",
      "reading": "/demos/#demo-saturation-boundary-lab",
      "conceptIds": [
        "saturation",
        "throughput",
        "queue",
        "backpressure",
        "pressure"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "If you raise only the database capacity, which stage will limit completion next?"
        },
        {
          "id": "experiment",
          "prompt": "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. Distinguish spare capacity, zero headroom at the limit and excess demand; inspect backlog or explicit rejection and the newly limiting stage."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-contention-curve-lab",
      "version": 2,
      "demoId": "demo-contention-curve-lab",
      "title": "Contention curve lab",
      "reading": "/demos/#demo-contention-curve-lab",
      "conceptIds": [
        "contention",
        "throughput",
        "saturation",
        "amdahl-law"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Will adding workers always increase capacity when coherency cost is nonzero?"
        },
        {
          "id": "experiment",
          "prompt": "Vary concurrency with fixed costs; then set both costs to zero and distinguish an interior peak from the largest displayed value. Identify plateau or decline where shown; a rising chart endpoint is not an optimum. Distinguish this model from Amdahl's ideal bound."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored assumptions: A parameterized Universal Scalability Law model. Coefficients require workload-specific evidence before predicting real capacity.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-orchestration-control-loop",
      "version": 2,
      "demoId": "demo-orchestration-control-loop",
      "title": "Orchestration control loop",
      "reading": "/demos/#demo-orchestration-control-loop",
      "conceptIds": [
        "feedback-loop",
        "recovery",
        "state-authority",
        "pressure",
        "contract"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "After losing a replica, what discrepancy should the controller observe and what action should follow?"
        },
        {
          "id": "experiment",
          "prompt": "Deploy running-but-broken v2, send a simulated request and reconcile replicas. Compare HTTP 500 with the response after rollback to v1. Separate replica convergence from useful HTTP responses; retain failed responses in the request log."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored assumptions: A simplified control loop; restoring replica count does not establish application correctness or recovery of durable effects.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-durable-effect-retry-lab",
      "version": 2,
      "demoId": "demo-durable-effect-retry-lab",
      "title": "Durable effect retry lab",
      "reading": "/demos/#demo-durable-effect-retry-lab",
      "conceptIds": [
        "durable-workflow",
        "retry",
        "idempotency",
        "state-authority",
        "recovery"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "If the receiver applied the effect but completion was not recorded, what could make a retry apply it twice?"
        },
        {
          "id": "experiment",
          "prompt": "Stop in the failure window, then compare key reuse and receiver deduplication choices. Count external effects separately from attempts and preserved workflow progress."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-cap-partition-lab",
      "version": 1,
      "demoId": "demo-cap-partition-lab",
      "title": "CAP partition lab",
      "reading": "/demos/#demo-cap-partition-lab",
      "conceptIds": [
        "partition",
        "consistency",
        "invariant",
        "state-authority",
        "recovery"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Can both sides acknowledge a conflicting start operation while preserving the declared invariant?"
        },
        {
          "id": "experiment",
          "prompt": "Partition Helsinki from the majority, submit both writes, and compare policies before repair. Record acknowledgments, state divergence, and what reconciliation can and cannot fix."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored assumptions: An operation-specific consistency scenario. Repair cannot retract a success response already observed by a client.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    },
    {
      "id": "investigate-demo-latency-budget-map",
      "version": 3,
      "demoId": "demo-latency-budget-map",
      "title": "Latency budget map",
      "reading": "/demos/#demo-latency-budget-map",
      "conceptIds": [
        "latency",
        "measurement-boundary",
        "consistency",
        "trade-off",
        "cache"
      ],
      "phases": [
        {
          "id": "predict",
          "prompt": "Which will matter more in your scenario: faster query execution or fewer sequential remote round trips?"
        },
        {
          "id": "experiment",
          "prompt": "Keep placement fixed and vary query count; then keep work fixed and move the database. Compare sequential and batched response budgets side by side, explain when batching is possible and identify omitted costs."
        },
        {
          "id": "reflect",
          "prompt": "Explain which assumption makes your prediction hold, where the model might fail, and what evidence you would need from your own system."
        }
      ],
      "guidance": "Adapt one explanation and one next check to the selected source, student's initial thinking and evidence. Cite the source. Distinguish authored claims, student reports, direct browser observations and hypothetical examples. Respect direct explanation requests. Support reflection in the student's own words and a next independent check without judging mastery, grading work or submitting anything. Only deliberately supplied context is available; no other notebook, peer or course records are implied. The student operates the demo controls. Treat the actual controls and displayed text as a bounded browser snapshot; do not infer canvas pixels, hidden results or later changes. Preserve these authored 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.",
      "observation": {
        "kind": "browser-demo-snapshot",
        "fields": [
          "demoId",
          "observedAt",
          "controls",
          "visibleText"
        ],
        "authority": "The active browser supplies this demo's actual visible controls and text on explicit send and can service observations during that reply. Canvas pixels are excluded. A snapshot is not project evidence. Public MCP publishes the contract without live state or execution."
      }
    }
  ],
  "concepts": [
    {
      "id": "measurement-boundary",
      "group": "Evidence",
      "title": "Measurement boundary",
      "definition": "The declared start, end, population, and observation window of a measurement. A boundary determines which work and waiting the result includes.",
      "assumptions": "Comparisons and equations must describe compatible work, units, and windows. Record failed, rejected, and unfinished work alongside successful completions.",
      "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.",
      "misconception": "A faster component proves a faster user journey. Work outside the measured component can dominate or become slower.",
      "usage": {
        "note": "Measurement boundary is the book's descriptive label for a measurement's scope and timing convention, rather than a separate formal model."
      },
      "contexts": [
        {
          "label": "Measurement: declare the protocol",
          "href": "https://scalableweb.dev/chapters/benchmarking/#benchmark-to-test-a-claim",
          "description": "Specify what starts and ends each observation."
        },
        {
          "label": "Scaling: test where the cost moved",
          "href": "https://scalableweb.dev/chapters/scaling/#implement-the-smallest-justified-response",
          "description": "Keep the original outcome visible after changing a component."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#measurement-boundary",
      "readings": [
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/appendices/reproducible-environments/",
        "https://scalableweb.dev/appendices/scalability-models/",
        "https://scalableweb.dev/parts/establish/",
        "https://scalableweb.dev/project/introduction/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/grading/"
      ],
      "resourceIds": [
        "graph-measurement-boundary",
        "pressure-evidence",
        "demo-tail-latency-simulator",
        "demo-browser-performance-workbench",
        "demo-opentelemetry-trace-explorer",
        "demo-reliability-chain-lab",
        "demo-latency-budget-map"
      ],
      "explorationIds": []
    },
    {
      "id": "throughput",
      "group": "Evidence",
      "title": "Throughput",
      "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.",
      "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.",
      "misconception": "More acknowledgments or generated changes mean more useful output. Pending events and unreviewed changes have not yet crossed their completion boundary.",
      "contexts": [
        {
          "label": "Measurement: count outcomes separately",
          "href": "https://scalableweb.dev/chapters/benchmarking/#check-whether-the-generator-hides-overload",
          "description": "Separate offered, admitted, completed, and timed-out work."
        },
        {
          "label": "Fleets: sequential review limits speedup",
          "href": "https://scalableweb.dev/chapters/agent-fleets/#amdahl-s-law-and-the-sequential-bottleneck",
          "description": "Measure accepted changes rather than generation activity."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#throughput",
      "readings": [
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/parts/compare/",
        "https://scalableweb.dev/case-studies/webernetes/",
        "https://scalableweb.dev/case-studies/temper/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/compare/"
      ],
      "resourceIds": [
        "graph-throughput",
        "three-connected-loops",
        "demo-sequential-work-bound",
        "demo-saturation-boundary-lab",
        "demo-contention-curve-lab"
      ],
      "explorationIds": [
        "human-work-in-progress"
      ]
    },
    {
      "id": "latency",
      "group": "Evidence",
      "title": "Latency",
      "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.",
      "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.",
      "misconception": "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.",
      "contexts": [
        {
          "label": "Measurement: calculate the average and tail",
          "href": "https://scalableweb.dev/chapters/benchmarking/#exercise-measurement-prediction",
          "description": "Compare a mean with a declared percentile convention."
        },
        {
          "label": "Scaling: latency and geography",
          "href": "https://scalableweb.dev/chapters/scaling/#latency-and-geography",
          "description": "Follow time across network and consistency boundaries."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#latency",
      "readings": [
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/chapters/scaling/"
      ],
      "resourceIds": [
        "graph-latency",
        "demo-web-architecture-lens",
        "demo-tail-latency-simulator",
        "demo-browser-performance-workbench",
        "demo-opentelemetry-trace-explorer",
        "demo-latency-budget-map"
      ],
      "explorationIds": []
    },
    {
      "id": "queue",
      "group": "Operations",
      "title": "Queue",
      "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.",
      "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.",
      "misconception": "Adding a queue creates processing capacity. It can absorb a bounded burst or decouple stages, but it also creates waiting, recovery, and admission obligations.",
      "contexts": [
        {
          "label": "Measurement: transfer the boundary to review work",
          "href": "https://scalableweb.dev/chapters/benchmarking/#exercise-measurement-transfer",
          "description": "Apply the same relationship with different work and units."
        },
        {
          "label": "Recap: a queue changes three loops",
          "href": "https://scalableweb.dev/chapters/recap/#how-the-loops-affect-one-another",
          "description": "Connect application backlog to implementation and review work."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#queue",
      "readings": [
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/chapters/recap/"
      ],
      "resourceIds": [
        "graph-queue",
        "three-connected-loops",
        "demo-saturation-boundary-lab"
      ],
      "explorationIds": [
        "human-work-in-progress"
      ]
    },
    {
      "id": "saturation",
      "group": "Operations",
      "title": "Saturation",
      "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.",
      "assumptions": "Identify the workload, maintained goal, and limiting resource. Expanding one limit can expose another; rejection or retries can change the observed rates.",
      "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.",
      "misconception": "Adding capacity to one component removes the system's limit. Another stage can bind first, and a quicker acknowledgment can conceal a growing backlog.",
      "usage": {
        "note": "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.",
        "sources": [
          {
            "label": "Woods: the theory of graceful extensibility",
            "href": "https://link.springer.com/article/10.1007/s10669-018-9708-3"
          }
        ]
      },
      "contexts": [
        {
          "label": "Pressure: name the binding limit",
          "href": "https://scalableweb.dev/chapters/reality/#from-failed-assumptions-to-useful-signals",
          "description": "Connect a disturbance to the limit and its signals."
        },
        {
          "label": "Scaling: move the saturation boundary",
          "href": "https://scalableweb.dev/chapters/scaling/#name-the-saturation-boundary",
          "description": "Test which constraint appears after an intervention."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#saturation",
      "readings": [
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/chapters/scaling/"
      ],
      "resourceIds": [
        "graph-saturation",
        "pressure-evidence",
        "dependency-failure",
        "demo-saturation-boundary-lab",
        "demo-contention-curve-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "little-law",
      "group": "Models",
      "title": "Little's Law",
      "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.",
      "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.",
      "misconception": "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.",
      "contexts": [
        {
          "label": "Measurement: check compatible averages",
          "href": "https://scalableweb.dev/chapters/benchmarking/#check-measurements-against-a-model",
          "description": "Calculate the relationship and inspect what a mismatch means."
        },
        {
          "label": "Scaling: choose the question before the equation",
          "href": "https://scalableweb.dev/chapters/scaling/#exercise-scaling-model-choice",
          "description": "Distinguish consistency of flow from a bound on parallel speedup."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#little-law",
      "readings": [
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/appendices/scalability-models/",
        "https://scalableweb.dev/project/challenge/"
      ],
      "resourceIds": [
        "graph-little-law"
      ],
      "explorationIds": []
    },
    {
      "id": "amdahl-law",
      "group": "Models",
      "title": "Amdahl's Law",
      "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.",
      "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.",
      "misconception": "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.",
      "contexts": [
        {
          "label": "Fleets: calculate the sequential bound",
          "href": "https://scalableweb.dev/chapters/agent-fleets/#amdahl-s-law-and-the-sequential-bottleneck",
          "description": "Account for integration and review in the workload."
        },
        {
          "label": "Scaling: choose between the two laws",
          "href": "https://scalableweb.dev/chapters/scaling/#exercise-scaling-model-choice",
          "description": "Choose a model by the question it can answer."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#amdahl-law",
      "readings": [
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/appendices/scalability-models/"
      ],
      "resourceIds": [
        "graph-amdahl-law",
        "demo-sequential-work-bound",
        "demo-contention-curve-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "development-friction",
      "title": "Development friction",
      "group": "Development",
      "definition": "The resistance a team encounters while setting up, understanding, changing, testing, reviewing, deploying, or operating a system.",
      "assumptions": "Locate a concrete blockage and the boundary it crosses. Some friction protects a named risk; a commitment is not automatically technical debt.",
      "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.",
      "misconception": "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.",
      "usage": {
        "note": "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."
      },
      "contexts": [
        {
          "label": "Friction: recognize the forms",
          "href": "https://scalableweb.dev/chapters/friction/#recognize-where-friction-appears",
          "description": "Distinguish setup, comprehension, change, and protective friction."
        },
        {
          "label": "Friction: find the commitment point",
          "href": "https://scalableweb.dev/chapters/friction/#find-the-commitment-point",
          "description": "Explain when a simple revert stops restoring the prior state."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#development-friction",
      "readings": [
        "https://scalableweb.dev/chapters/friction/"
      ],
      "resourceIds": [
        "graph-development-friction"
      ],
      "explorationIds": []
    },
    {
      "id": "scalability",
      "title": "Scalability",
      "group": "Operations",
      "definition": "The ability to maintain a declared goal as a relevant pressure changes, within stated constraints.",
      "assumptions": "Name the goal, changing pressure, workload, and resources allowed to change. A scalability claim is conditional on these choices.",
      "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.",
      "misconception": "Scalability means maximum traffic. Data growth, more contributors, and frequent change can also threaten the maintained goal.",
      "usage": {
        "note": "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."
      },
      "contexts": [
        {
          "label": "Scalability: begin with the goal",
          "href": "https://scalableweb.dev/chapters/what-is-scalability/#begin-with-the-goal-that-must-continue-to-hold",
          "description": "State the property that pressure must not break."
        },
        {
          "label": "Scaling: choose a response",
          "href": "https://scalableweb.dev/chapters/scaling/#start-with-the-pressure",
          "description": "Connect the changing pressure to an intervention."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#scalability",
      "readings": [
        "https://scalableweb.dev/chapters/introduction/",
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/parts/establish/",
        "https://scalableweb.dev/parts/compare/",
        "https://scalableweb.dev/case-studies/thesis-journey-tracker/"
      ],
      "resourceIds": [
        "graph-scalability",
        "pressure-evidence",
        "three-connected-loops"
      ],
      "explorationIds": []
    },
    {
      "id": "pressure",
      "title": "Scaling pressure",
      "group": "Operations",
      "definition": "A change in demand, data, contributors, or rate of change that tests the system's ability to maintain its goal.",
      "assumptions": "Separate the pressure from its symptom and from the proposed response. Describe the distribution of work, not only its total volume.",
      "example": "A reconnect burst increases event arrivals while the database size stays constant. A growing activity history can slow queries even with unchanged traffic.",
      "misconception": "‘We need caching’ names the pressure. It names a response whose relevance still needs evidence.",
      "usage": {
        "note": "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."
      },
      "contexts": [
        {
          "label": "Scalability: four pressures",
          "href": "https://scalableweb.dev/chapters/what-is-scalability/#four-pressures-organize-the-course",
          "description": "Distinguish demand, data, contributors, and change."
        },
        {
          "label": "Pressure: identify the binding limit",
          "href": "https://scalableweb.dev/chapters/reality/#from-failed-assumptions-to-useful-signals",
          "description": "Trace a disturbance to its signals and limit."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#pressure",
      "readings": [
        "https://scalableweb.dev/chapters/introduction/",
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/parts/challenge/",
        "https://scalableweb.dev/project/challenge/"
      ],
      "resourceIds": [
        "graph-pressure",
        "pressure-evidence",
        "dependency-failure",
        "three-connected-loops",
        "demo-saturation-boundary-lab",
        "demo-orchestration-control-loop"
      ],
      "explorationIds": []
    },
    {
      "id": "trade-off",
      "title": "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.",
      "example": "Acknowledging events before processing shortens acknowledgment latency, but creates a pending state, queue, drain procedure, and a second completion boundary.",
      "misconception": "A faster benchmark establishes the best design. Correctness, recovery, operating cost, and maintainability may change the decision.",
      "contexts": [
        {
          "label": "Scaling: assess the obligations",
          "href": "https://scalableweb.dev/chapters/scaling/#trade-offs",
          "description": "Explain the operating contract each response introduces."
        },
        {
          "label": "Recap: make a decision",
          "href": "https://scalableweb.dev/chapters/recap/#turn-comparison-into-a-decision",
          "description": "Use evidence and constraints to justify a preference."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#trade-off",
      "readings": [
        "https://scalableweb.dev/chapters/introduction/",
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/parts/establish/",
        "https://scalableweb.dev/parts/compare/",
        "https://scalableweb.dev/case-studies/slideotter/",
        "https://scalableweb.dev/case-studies/thesis-journey-tracker/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/project/compare/",
        "https://scalableweb.dev/project/grading/"
      ],
      "resourceIds": [
        "graph-trade-off",
        "course-progression",
        "pressure-evidence",
        "demo-cache-decision-lab",
        "demo-web-architecture-lens",
        "demo-latency-budget-map"
      ],
      "explorationIds": []
    },
    {
      "id": "benchmark",
      "title": "Benchmark protocol",
      "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.",
      "example": "Run the same activity-feed workload against A, B, and C, preserving logical operation boundaries and reporting valid completions separately from overload rejections.",
      "misconception": "A single requests-per-second number ranks implementations. Different work, failure accounting, or generator behavior can make the numbers incomparable.",
      "contexts": [
        {
          "label": "Measurement: test a claim",
          "href": "https://scalableweb.dev/chapters/benchmarking/#benchmark-to-test-a-claim",
          "description": "Declare the protocol before interpreting numbers."
        },
        {
          "label": "Project: common workload",
          "href": "https://scalableweb.dev/project/#7-1-shared-baseline-workload",
          "description": "Hold logical operations constant across implementations."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#benchmark",
      "readings": [
        "https://scalableweb.dev/chapters/introduction/",
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/",
        "https://scalableweb.dev/appendices/reproducible-environments/",
        "https://scalableweb.dev/parts/establish/",
        "https://scalableweb.dev/case-studies/webernetes/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/establish/"
      ],
      "resourceIds": [
        "graph-benchmark",
        "course-progression",
        "pressure-evidence",
        "demo-tail-latency-simulator",
        "demo-browser-performance-workbench",
        "demo-fleet-trace-debugger"
      ],
      "explorationIds": []
    },
    {
      "id": "tail-latency",
      "title": "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.",
      "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.",
      "misconception": "A good mean implies a good tail, or p95 can replace average time in Little's Law. These statistics answer different questions.",
      "contexts": [
        {
          "label": "Measurement: compare mean and tail",
          "href": "https://scalableweb.dev/chapters/benchmarking/#exercise-measurement-prediction",
          "description": "Calculate how a slow minority affects the result."
        },
        {
          "label": "Scaling: budget latency",
          "href": "https://scalableweb.dev/chapters/scaling/#latency-budget-lab",
          "description": "Account for the journey across stages."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#tail-latency",
      "readings": [
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/project/"
      ],
      "resourceIds": [
        "graph-tail-latency",
        "demo-tail-latency-simulator"
      ],
      "explorationIds": []
    },
    {
      "id": "observability",
      "title": "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.",
      "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.",
      "misconception": "Collecting many logs establishes the cause. Signals need a coherent question and a traceable connection to the user outcome.",
      "contexts": [
        {
          "label": "Pressure: trace a failure",
          "href": "https://scalableweb.dev/chapters/reality/#trace-one-failure-across-the-web-boundary",
          "description": "Join symptoms, policies, and authoritative outcomes."
        },
        {
          "label": "Measurement: signal selection",
          "href": "https://scalableweb.dev/chapters/benchmarking/#measurement-alone-cannot-explain-behavior",
          "description": "Use telemetry and the trace explorer to investigate behavior."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#observability",
      "readings": [
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/parts/challenge/",
        "https://scalableweb.dev/project/challenge/"
      ],
      "resourceIds": [
        "graph-observability",
        "demo-opentelemetry-trace-explorer",
        "demo-fleet-trace-debugger"
      ],
      "explorationIds": [
        "telemetry-guided-repair",
        "verify-remediation"
      ]
    },
    {
      "id": "goodhart-law",
      "title": "Goodhart's 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.",
      "example": "Rewarding generated changes per hour can produce more small submissions while accepted output stays flat and reviewer waiting grows.",
      "misconception": "Every metric is useless. Metrics can inform decisions when their boundary, incentives, and omitted outcomes remain visible.",
      "contexts": [
        {
          "label": "Measurement: challenge the metric",
          "href": "https://scalableweb.dev/chapters/benchmarking/#measurements-can-lead-you-astray",
          "description": "Use the Goodhart pressure test to inspect the proxy."
        },
        {
          "label": "Fleets: measure accepted output",
          "href": "https://scalableweb.dev/chapters/agent-fleets/#measure-accepted-throughput",
          "description": "Count accepted work and the human effort it needs."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#goodhart-law",
      "readings": [
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/"
      ],
      "resourceIds": [
        "graph-goodhart-law"
      ],
      "explorationIds": []
    },
    {
      "id": "eval",
      "title": "Agent evaluation",
      "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.",
      "example": "Run a contract-change task with fixed acceptance checks across repeated trials, recording correctness, retries, tokens, and reviewer minutes.",
      "misconception": "A pass on one task proves general reliability. Task selection, graders, environment, and trial variability limit the claim.",
      "contexts": [
        {
          "label": "Appendix A: anatomy of an eval",
          "href": "https://scalableweb.dev/appendices/evaluating-agentic-workflows/#anatomy-of-an-agent-evaluation",
          "description": "Separate execution, environment, and grading."
        },
        {
          "label": "Modern Web Guidance: evaluate the guidance",
          "href": "https://scalableweb.dev/case-studies/modern-web-guidance/#the-guidance-has-an-evaluation-loop",
          "description": "Check whether a capability improves actual task outcomes."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#eval",
      "readings": [
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/",
        "https://scalableweb.dev/parts/appendices/",
        "https://scalableweb.dev/case-studies/webernetes/",
        "https://scalableweb.dev/case-studies/modern-web-guidance/"
      ],
      "resourceIds": [
        "graph-eval"
      ],
      "explorationIds": [
        "telemetry-guided-repair",
        "temporary-api-consumers",
        "confidence-before-routing"
      ]
    },
    {
      "id": "change-probe",
      "title": "Maintainability assessment",
      "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.",
      "assumptions": "Declare the starting version, task, auditor familiarity, completion criteria, and effort boundary. One probe does not represent all future maintenance.",
      "example": "Ask another team to add one event filter. Record where they looked, what contracts they changed, validation effort, and the accepted result.",
      "misconception": "A system with passing behavior tests is necessarily easy to change. Navigability and the next-change cost need separate evidence.",
      "usage": {
        "note": "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."
      },
      "contexts": [
        {
          "label": "Project: change-probe protocol",
          "href": "https://scalableweb.dev/project/#10-1-change-probe-protocol",
          "description": "Bound the audit and preserve comparable evidence."
        },
        {
          "label": "Appendix A: next-change cost",
          "href": "https://scalableweb.dev/appendices/evaluating-agentic-workflows/#evaluate-the-cost-of-the-next-change",
          "description": "Evaluate maintainability beyond first-pass success."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#change-probe",
      "readings": [
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/",
        "https://scalableweb.dev/appendices/reproducible-environments/",
        "https://scalableweb.dev/parts/challenge/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/challenge/",
        "https://scalableweb.dev/project/grading/"
      ],
      "resourceIds": [
        "graph-change-probe"
      ],
      "explorationIds": []
    },
    {
      "id": "agent",
      "title": "Coding agent",
      "group": "Development",
      "definition": "A model-driven loop that observes context, chooses actions through tools, and uses resulting feedback to continue a development task.",
      "assumptions": "Capabilities depend on the model, context, tools, environment, budget, and permitted authority. Generated work remains candidate work until accepted.",
      "example": "An agent edits an event handler, runs contract tests, inspects a failure, and revises the implementation before a maintainer accepts the change.",
      "misconception": "The model alone determines the development result. Its harness and the project's constraints materially shape what it can do and verify.",
      "usage": {
        "note": "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.",
        "sources": [
          {
            "label": "Anthropic: definitions of workflows and agents",
            "href": "https://www.anthropic.com/engineering/building-effective-agents"
          }
        ]
      },
      "contexts": [
        {
          "label": "Development: define an agent",
          "href": "https://scalableweb.dev/chapters/scalable-development/#what-is-an-agent",
          "description": "Identify the observation–action loop."
        },
        {
          "label": "Fleets: choose a coordination structure",
          "href": "https://scalableweb.dev/chapters/agent-fleets/#choose-a-coordination-structure",
          "description": "Explain the coordination obligations of each option."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#agent",
      "readings": [
        "https://scalableweb.dev/chapters/introduction/",
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/appendices/agent-system-security/",
        "https://scalableweb.dev/parts/establish/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/case-studies/webernetes/",
        "https://scalableweb.dev/project/introduction/",
        "https://scalableweb.dev/project/establish/"
      ],
      "resourceIds": [
        "graph-agent",
        "course-progression",
        "three-connected-loops"
      ],
      "explorationIds": []
    },
    {
      "id": "loop-engineering",
      "title": "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.",
      "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.",
      "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.",
      "misconception": "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.",
      "usage": {
        "note": "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.",
        "sources": [
          {
            "label": "Osmani: Loop Engineering (practitioner essay)",
            "href": "https://addyosmani.com/blog/loop-engineering/"
          },
          {
            "label": "IBM: What is loop engineering? (industry explainer)",
            "href": "https://www.ibm.com/think/topics/loop-engineering"
          },
          {
            "label": "Lulla et al.: building blocks and adoption (exploratory preprint)",
            "href": "https://arxiv.org/abs/2608.21884v2"
          }
        ]
      },
      "contexts": [
        {
          "label": "Development: design the loop",
          "href": "https://scalableweb.dev/chapters/scalable-development/#loop-engineering",
          "description": "Distinguish loop design from feedback and harness infrastructure."
        },
        {
          "label": "Appendix A: research and evidence",
          "href": "https://scalableweb.dev/appendices/evaluating-agentic-workflows/#research-behind-loop-engineering",
          "description": "Separate adoption evidence, refinement experiments, and claims about developer effort."
        },
        {
          "label": "Friction: match feedback to the boundary",
          "href": "https://scalableweb.dev/chapters/friction/#match-feedback-to-the-changed-boundary",
          "description": "Choose useful repair feedback without weakening final acceptance."
        },
        {
          "label": "Fleets: choose coordination deliberately",
          "href": "https://scalableweb.dev/chapters/agent-fleets/#choose-a-coordination-structure",
          "description": "Add delegation only when the task and acceptance arrangement justify it."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#loop-engineering",
      "readings": [
        "https://scalableweb.dev/chapters/introduction/",
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/"
      ],
      "resourceIds": [
        "graph-loop-engineering",
        "three-connected-loops"
      ],
      "explorationIds": []
    },
    {
      "id": "harness",
      "title": "Project harness",
      "group": "Development",
      "definition": "The versioned project instructions, specifications, architecture notes, environment, commands, and checks that make candidate changes inspectable and repeatable.",
      "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.",
      "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.",
      "misconception": "A long instruction file makes the workflow controlled. Instructions require enforceable checks and an owner for acceptance.",
      "usage": {
        "note": "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.",
        "sources": [
          {
            "label": "Anthropic: an agent harness and its project environment",
            "href": "https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents"
          }
        ]
      },
      "contexts": [
        {
          "label": "Development: the project harness",
          "href": "https://scalableweb.dev/chapters/scalable-development/#the-project-harness",
          "description": "Connect instructions with executable controls."
        },
        {
          "label": "Kirjolab: prepare before feature pressure",
          "href": "https://scalableweb.dev/case-studies/kirjolab/#the-harness-existed-before-the-feature-pressure",
          "description": "See a harness support rapid delivery."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#harness",
      "readings": [
        "https://scalableweb.dev/chapters/introduction/",
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/",
        "https://scalableweb.dev/appendices/reproducible-environments/",
        "https://scalableweb.dev/appendices/agent-system-security/",
        "https://scalableweb.dev/parts/establish/",
        "https://scalableweb.dev/case-studies/slideotter/",
        "https://scalableweb.dev/case-studies/thesis-journey-tracker/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/case-studies/webernetes/",
        "https://scalableweb.dev/case-studies/modern-web-guidance/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/establish/"
      ],
      "resourceIds": [
        "graph-harness",
        "shared-knowledge-boundary"
      ],
      "explorationIds": []
    },
    {
      "id": "acceptance-criteria",
      "title": "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.",
      "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.",
      "misconception": "A clean diff or successful merge establishes correctness. Behavior, integration, and accountable review are separate obligations.",
      "contexts": [
        {
          "label": "Fleets: authority and acceptance",
          "href": "https://scalableweb.dev/chapters/agent-fleets/#map-authority-and-acceptance",
          "description": "Assign acceptance before parallel work begins."
        },
        {
          "label": "Webernetes: shared behavioral tests",
          "href": "https://scalableweb.dev/case-studies/webernetes/#shared-tests-created-a-behavioral-contrast",
          "description": "Test generated behavior against a reference."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#acceptance-criteria",
      "readings": [
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/",
        "https://scalableweb.dev/appendices/agent-system-security/",
        "https://scalableweb.dev/parts/establish/",
        "https://scalableweb.dev/case-studies/slideotter/",
        "https://scalableweb.dev/case-studies/webernetes/",
        "https://scalableweb.dev/case-studies/temper/",
        "https://scalableweb.dev/project/introduction/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/establish/",
        "https://scalableweb.dev/project/challenge/",
        "https://scalableweb.dev/project/grading/"
      ],
      "resourceIds": [
        "graph-acceptance-criteria",
        "course-progression"
      ],
      "explorationIds": [
        "prototype-to-shared-use",
        "challenge-an-explanation",
        "telemetry-guided-repair",
        "verify-remediation",
        "temporary-api-consumers",
        "confidence-before-routing"
      ]
    },
    {
      "id": "authority",
      "title": "Action authorization",
      "group": "Development",
      "definition": "The permission granted to an actor to propose, prepare, or execute a decision or action within stated limits.",
      "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.",
      "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.",
      "misconception": "Access to a tool implies permission for every action it supports. Credentials, action approval, and containment are different controls.",
      "usage": {
        "note": "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.",
        "sources": [
          {
            "label": "NIST: authorization definitions and their contexts",
            "href": "https://csrc.nist.gov/glossary/term/authorization"
          }
        ]
      },
      "contexts": [
        {
          "label": "Development: assign authority",
          "href": "https://scalableweb.dev/chapters/scalable-development/#assign-authority-and-ownership",
          "description": "Make execution and acceptance ownership explicit."
        },
        {
          "label": "Appendix D: separate security controls",
          "href": "https://scalableweb.dev/appendices/agent-system-security/#separate-credential-custody-action-authorization-and-containment",
          "description": "Distinguish access, authorization, and containment."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#authority",
      "readings": [
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/",
        "https://scalableweb.dev/appendices/agent-system-security/",
        "https://scalableweb.dev/parts/appendices/",
        "https://scalableweb.dev/case-studies/thesis-journey-tracker/",
        "https://scalableweb.dev/case-studies/modern-web-guidance/",
        "https://scalableweb.dev/case-studies/temper/",
        "https://scalableweb.dev/project/introduction/",
        "https://scalableweb.dev/project/compare/"
      ],
      "resourceIds": [
        "graph-authority",
        "shared-knowledge-boundary",
        "demo-deterministic-boundary-lab",
        "demo-fleet-trace-debugger"
      ],
      "explorationIds": [
        "prototype-to-shared-use",
        "temporary-api-consumers",
        "confidence-before-routing"
      ]
    },
    {
      "id": "feedback-loop",
      "title": "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.",
      "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.",
      "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.",
      "misconception": "More frequent feedback guarantees improvement. A delayed or misleading signal can amplify the wrong behavior.",
      "usage": {
        "note": "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.",
        "sources": [
          {
            "label": "Caltech: negative and positive feedback",
            "href": "https://murray.cds.caltech.edu/Is_control_a_type_of_negative_feedback%3F"
          }
        ]
      },
      "contexts": [
        {
          "label": "Development: constrain, generate, validate, revise",
          "href": "https://scalableweb.dev/chapters/scalable-development/#constrain-generate-validate-revise",
          "description": "Use the loop to turn candidate work into accepted work."
        },
        {
          "label": "Scaling: orchestration control",
          "href": "https://scalableweb.dev/chapters/scaling/#orchestration-maintains-declared-capacity",
          "description": "Compare development feedback with runtime control."
        },
        {
          "label": "Scaling: retry amplification",
          "href": "https://scalableweb.dev/chapters/scaling/#name-the-saturation-boundary",
          "description": "Trace the reinforcing cycle from overload to timeouts, retries, and more load."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#feedback-loop",
      "readings": [
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/appendices/reproducible-environments/",
        "https://scalableweb.dev/case-studies/thesis-journey-tracker/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/case-studies/webernetes/"
      ],
      "resourceIds": [
        "graph-feedback-loop",
        "three-connected-loops",
        "demo-orchestration-control-loop"
      ],
      "explorationIds": []
    },
    {
      "id": "decision-log",
      "title": "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.",
      "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.",
      "misconception": "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.",
      "contexts": [
        {
          "label": "Friction: record the commitment",
          "href": "https://scalableweb.dev/chapters/friction/#keep-a-decision-log",
          "description": "Record soft and hard choices with their evidence and revisit conditions."
        },
        {
          "label": "Measurement: preserve accepted context",
          "href": "https://scalableweb.dev/chapters/benchmarking/#field-note-preserve-accepted-context-not-every-interaction",
          "description": "Distinguish accepted rationale from a complete execution trace."
        },
        {
          "label": "Project: record the stack hypothesis",
          "href": "https://scalableweb.dev/project/establish/#record-the-stack-hypothesis",
          "description": "Use the existing stack decision record to make assumptions reviewable."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#decision-log",
      "readings": [
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/benchmarking/",
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/parts/challenge/",
        "https://scalableweb.dev/case-studies/slideotter/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/project/introduction/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/establish/",
        "https://scalableweb.dev/project/compare/"
      ],
      "resourceIds": [
        "graph-decision-log"
      ],
      "explorationIds": []
    },
    {
      "id": "decision-reversibility",
      "title": "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.",
      "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.",
      "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.",
      "misconception": "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.",
      "usage": {
        "note": "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.",
        "sources": [
          {
            "label": "Amazon: reversible decisions and two-way doors",
            "href": "https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders"
          }
        ]
      },
      "contexts": [
        {
          "label": "Friction: plan soft and hard decisions",
          "href": "https://scalableweb.dev/chapters/friction/#plan-soft-and-hard-decisions",
          "description": "Keep uncertain choices cheap to revise and identify what would make them hard."
        },
        {
          "label": "Scalability: change exposes commitments",
          "href": "https://scalableweb.dev/chapters/what-is-scalability/#change-makes-old-commitments-visible",
          "description": "Connect the ability to keep changing with the dependencies already created."
        },
        {
          "label": "Friction: keep a decision log",
          "href": "https://scalableweb.dev/chapters/friction/#keep-a-decision-log",
          "description": "Preserve what makes a choice reversible and when it should be reviewed."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#decision-reversibility",
      "readings": [
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/parts/challenge/",
        "https://scalableweb.dev/project/establish/",
        "https://scalableweb.dev/project/challenge/"
      ],
      "resourceIds": [
        "graph-decision-reversibility",
        "shared-knowledge-boundary"
      ],
      "explorationIds": [
        "prototype-to-shared-use"
      ]
    },
    {
      "id": "technical-debt",
      "title": "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.",
      "example": "An undocumented schema assumption spreads into the API and UI. Adding one state later requires coordinated changes whose boundaries are hard to find.",
      "misconception": "Debt is merely untidy code. Coupled contracts, environments, and missing ownership can reduce optionality even when the code is neat.",
      "contexts": [
        {
          "label": "Challenge: reduced optionality",
          "href": "https://scalableweb.dev/parts/challenge/#technical-debt-reduces-optionality",
          "description": "Connect commitments with future choices."
        },
        {
          "label": "Kirjolab: revise the architecture",
          "href": "https://scalableweb.dev/case-studies/kirjolab/#refactoring-was-the-revision-phase",
          "description": "Follow consolidation after rapid generation."
        },
        {
          "label": "Friction: find the commitment point",
          "href": "https://scalableweb.dev/chapters/friction/#find-the-commitment-point",
          "description": "Distinguish the cost of reversing a commitment from technical debt."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#technical-debt",
      "readings": [
        "https://scalableweb.dev/chapters/what-is-scalability/",
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/parts/challenge/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/project/challenge/"
      ],
      "resourceIds": [
        "graph-technical-debt",
        "shared-knowledge-boundary"
      ],
      "explorationIds": []
    },
    {
      "id": "reproducible-environment",
      "title": "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.",
      "example": "The auditor uses the documented runtime, lockfile, database seed, and test commands to reproduce an event-feed failure from a clean checkout.",
      "misconception": "It works on one laptop, so the result is reproducible. Hidden services, mutable dependencies, and undeclared state can invalidate that inference.",
      "contexts": [
        {
          "label": "Friction: version the environment",
          "href": "https://scalableweb.dev/chapters/friction/#treat-the-environment-as-a-versioned-input",
          "description": "Treat setup as part of the development boundary."
        },
        {
          "label": "Appendix B: choose the strength",
          "href": "https://scalableweb.dev/appendices/reproducible-environments/#choose-the-required-strength",
          "description": "Match reproducibility to the experiment."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#reproducible-environment",
      "readings": [
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/appendices/reproducible-environments/",
        "https://scalableweb.dev/parts/appendices/",
        "https://scalableweb.dev/case-studies/modern-web-guidance/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/establish/",
        "https://scalableweb.dev/project/grading/"
      ],
      "resourceIds": [
        "graph-reproducible-environment"
      ],
      "explorationIds": []
    },
    {
      "id": "agent-fleet",
      "title": "Agent fleet",
      "group": "Development",
      "definition": "Several agents working under an explicit task, coordination, authority, integration, and acceptance arrangement.",
      "assumptions": "Useful parallelism depends on separable work and available integration capacity. Count accepted changes and coordination cost, not only simultaneous agents.",
      "example": "One agent changes the event contract, another updates consumers after that contract is fixed, and a reviewer tests their integrated behavior.",
      "misconception": "More agents guarantee more useful output. Shared dependencies and sequential review can erase the benefit.",
      "usage": {
        "note": "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.",
        "sources": [
          {
            "label": "Poole and Mackworth: multiagent systems",
            "href": "https://artint.info/3e/html/ArtInt3e.Ch14.S1.html"
          }
        ]
      },
      "contexts": [
        {
          "label": "Fleets: choose a coordination structure",
          "href": "https://scalableweb.dev/chapters/agent-fleets/#choose-a-coordination-structure",
          "description": "Choose a structure that fits the work and integration capacity."
        },
        {
          "label": "Compare: implementation C",
          "href": "https://scalableweb.dev/parts/compare/#implementation-c-work-activity-tracker",
          "description": "Declare and evaluate a fleet in the project."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#agent-fleet",
      "readings": [
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/appendices/agent-system-security/",
        "https://scalableweb.dev/parts/compare/",
        "https://scalableweb.dev/project/introduction/",
        "https://scalableweb.dev/project/compare/"
      ],
      "resourceIds": [
        "graph-agent-fleet",
        "course-progression",
        "demo-fleet-trace-debugger",
        "demo-sequential-work-bound"
      ],
      "explorationIds": [
        "human-work-in-progress"
      ]
    },
    {
      "id": "task-graph",
      "title": "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.",
      "example": "Fix the event schema before parallel API and UI tasks; reunite them in a shared-contract integration test.",
      "misconception": "Tasks that merge without conflicts were independent. A clean merge can still combine incompatible assumptions.",
      "contexts": [
        {
          "label": "Fleets: define the task graph",
          "href": "https://scalableweb.dev/chapters/agent-fleets/#define-the-web-task-graph",
          "description": "Separate parallel work from ordered integration."
        },
        {
          "label": "Appendix D: task and resource control",
          "href": "https://scalableweb.dev/appendices/agent-system-security/#separate-task-control-from-resource-access",
          "description": "Keep task dependencies distinct from access permissions."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#task-graph",
      "readings": [
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/appendices/agent-system-security/",
        "https://scalableweb.dev/parts/compare/",
        "https://scalableweb.dev/project/compare/"
      ],
      "resourceIds": [
        "graph-task-graph"
      ],
      "explorationIds": []
    },
    {
      "id": "review-budget",
      "title": "Review capacity",
      "group": "Development",
      "definition": "The finite human attention and integration effort available to evaluate and accept candidate changes.",
      "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.",
      "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.",
      "misconception": "Review is an overhead that disappears with better generation. Understanding and accountable acceptance remain part of useful throughput.",
      "usage": {
        "note": "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."
      },
      "contexts": [
        {
          "label": "Development: generation outruns comprehension",
          "href": "https://scalableweb.dev/chapters/scalable-development/#when-generation-outruns-comprehension",
          "description": "Locate the human constraint."
        },
        {
          "label": "Introduction: editorial acceptance",
          "href": "https://scalableweb.dev/chapters/introduction/#how-this-book-was-made",
          "description": "Separate publishing checks from editorial judgment."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#review-budget",
      "readings": [
        "https://scalableweb.dev/chapters/introduction/",
        "https://scalableweb.dev/chapters/scalable-development/",
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/chapters/recap/",
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/",
        "https://scalableweb.dev/parts/compare/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/case-studies/temper/",
        "https://scalableweb.dev/project/compare/"
      ],
      "resourceIds": [
        "graph-review-budget",
        "three-connected-loops",
        "demo-sequential-work-bound"
      ],
      "explorationIds": [
        "human-work-in-progress"
      ]
    },
    {
      "id": "contract",
      "title": "Application 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.",
      "example": "POST /events accepts one logical activity with workspace isolation and a declared duplicate policy, regardless of which runtime hosts the handler.",
      "misconception": "A deployment location or matching types fully defines the contract. Timing, retries, errors, and state effects also matter.",
      "contexts": [
        {
          "label": "Architecture: contracts outlive deployment",
          "href": "https://scalableweb.dev/chapters/architecture/#application-contracts-outlive-deployment-choices",
          "description": "Separate behavior from where execution happens."
        },
        {
          "label": "Appendix C: executable HTTP contracts",
          "href": "https://scalableweb.dev/appendices/advanced-web-boundaries/#executable-http-contracts",
          "description": "Make boundary expectations testable."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#contract",
      "readings": [
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/chapters/friction/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/",
        "https://scalableweb.dev/appendices/agent-system-security/",
        "https://scalableweb.dev/parts/establish/",
        "https://scalableweb.dev/parts/challenge/",
        "https://scalableweb.dev/case-studies/kirjolab/",
        "https://scalableweb.dev/case-studies/webernetes/",
        "https://scalableweb.dev/case-studies/modern-web-guidance/",
        "https://scalableweb.dev/case-studies/temper/",
        "https://scalableweb.dev/project/",
        "https://scalableweb.dev/project/challenge/"
      ],
      "resourceIds": [
        "graph-contract",
        "dependency-failure",
        "shared-knowledge-boundary",
        "demo-deterministic-boundary-lab",
        "demo-cache-decision-lab",
        "demo-web-architecture-lens",
        "demo-reliability-chain-lab",
        "demo-orchestration-control-loop"
      ],
      "explorationIds": [
        "temporary-api-consumers"
      ]
    },
    {
      "id": "rendering",
      "title": "Rendering and activation",
      "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.",
      "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.",
      "misconception": "Server rendering, client rendering, or hydration is universally fastest. The workload and interaction boundary determine the result.",
      "contexts": [
        {
          "label": "Architecture: move rendering work",
          "href": "https://scalableweb.dev/chapters/architecture/#rendering-moves-work-across-time-and-place",
          "description": "Compare representation delivery choices."
        },
        {
          "label": "Appendix C: activate an interface",
          "href": "https://scalableweb.dev/appendices/advanced-web-boundaries/#activate-delivered-interfaces",
          "description": "Distinguish rendering from activation."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#rendering",
      "readings": [
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/"
      ],
      "resourceIds": [
        "graph-rendering",
        "demo-web-architecture-lens",
        "demo-browser-performance-workbench"
      ],
      "explorationIds": []
    },
    {
      "id": "state-authority",
      "title": "Authoritative state",
      "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.",
      "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.",
      "example": "The event store commits one activity. A delayed cached feed may show none yet; rebuilding the feed must not create a second activity.",
      "misconception": "Every copy is equally authoritative, or stateless handlers remove state. Authority still exists somewhere in the system.",
      "usage": {
        "note": "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."
      },
      "contexts": [
        {
          "label": "Architecture: authority and access",
          "href": "https://scalableweb.dev/chapters/architecture/#data-placement-follows-authority-and-access",
          "description": "Follow ownership before choosing placement."
        },
        {
          "label": "Appendix C: rebuild without repeating effects",
          "href": "https://scalableweb.dev/appendices/advanced-web-boundaries/#rebuild-a-view-without-repeating-its-effects",
          "description": "Keep derived views separate from durable actions."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#state-authority",
      "readings": [
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/",
        "https://scalableweb.dev/appendices/durable-workflows/",
        "https://scalableweb.dev/case-studies/slideotter/"
      ],
      "resourceIds": [
        "graph-state-authority",
        "demo-deterministic-boundary-lab",
        "demo-acid-transaction-lab",
        "demo-web-architecture-lens",
        "demo-fleet-trace-debugger",
        "demo-orchestration-control-loop",
        "demo-durable-effect-retry-lab",
        "demo-cap-partition-lab"
      ],
      "explorationIds": [
        "challenge-an-explanation"
      ]
    },
    {
      "id": "transaction",
      "title": "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.",
      "example": "Commit the event and its reusable idempotency result together so a retried command cannot observe only half of the intended state.",
      "misconception": "Using a transaction makes every distributed action exactly once. External effects and ambiguous outcomes still need their own protocol.",
      "contexts": [
        {
          "label": "Architecture: preserve invariants",
          "href": "https://scalableweb.dev/chapters/architecture/#transactions-preserve-invariants-across-failure-and-concurrency",
          "description": "Explain why the state changes belong together."
        },
        {
          "label": "Appendix C: transaction guarantees",
          "href": "https://scalableweb.dev/appendices/advanced-web-boundaries/#preserve-durable-invariants-with-transactions",
          "description": "Test concurrency and failure assumptions."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#transaction",
      "readings": [
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/",
        "https://scalableweb.dev/appendices/durable-workflows/"
      ],
      "resourceIds": [
        "graph-transaction",
        "demo-acid-transaction-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "invariant",
      "title": "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.",
      "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.",
      "misconception": "Passing the happy path proves the invariant. Invalid combinations, concurrency, and partial failure challenge it.",
      "contexts": [
        {
          "label": "Architecture: valid data combinations",
          "href": "https://scalableweb.dev/chapters/architecture/#model-valid-data-combinations",
          "description": "Make invalid combinations explicit."
        },
        {
          "label": "Appendix C: durable invariants",
          "href": "https://scalableweb.dev/appendices/advanced-web-boundaries/#preserve-durable-invariants-with-transactions",
          "description": "Place enforcement at the durable boundary."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#invariant",
      "readings": [
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/",
        "https://scalableweb.dev/case-studies/temper/",
        "https://scalableweb.dev/project/"
      ],
      "resourceIds": [
        "graph-invariant",
        "demo-deterministic-boundary-lab",
        "demo-acid-transaction-lab",
        "demo-cap-partition-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "cache",
      "title": "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.",
      "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.",
      "misconception": "Caching only changes speed. It also changes freshness, authorization exposure, dependency load, and recovery behavior.",
      "contexts": [
        {
          "label": "Architecture: controlled copies",
          "href": "https://scalableweb.dev/chapters/architecture/#caching-coordinates-controlled-copies",
          "description": "Specify cache policy as behavior."
        },
        {
          "label": "Pressure: a dependency quota outage",
          "href": "https://scalableweb.dev/chapters/reality/#field-note-when-caching-complexity-became-an-availability-risk",
          "description": "Trace faulty caching into an availability failure."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#cache",
      "readings": [
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/"
      ],
      "resourceIds": [
        "graph-cache",
        "dependency-failure",
        "demo-cache-decision-lab",
        "demo-latency-budget-map"
      ],
      "explorationIds": []
    },
    {
      "id": "idempotency",
      "title": "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.",
      "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.",
      "misconception": "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.",
      "contexts": [
        {
          "label": "Pressure: lost response and duplicate",
          "href": "https://scalableweb.dev/chapters/reality/#trace-one-failure-across-the-web-boundary",
          "description": "Follow one logical command through a retry."
        },
        {
          "label": "Pressure: inspect all promised effects",
          "href": "https://scalableweb.dev/chapters/reality/#exercise-pressure-retries",
          "description": "Assess the status and activity history together before choosing a retry mechanism."
        },
        {
          "label": "Appendix C: HTTP method semantics",
          "href": "https://scalableweb.dev/appendices/advanced-web-boundaries/#distinguish-http-method-semantics-from-domain-retry-safety",
          "description": "Separate intended effects, response differences, and incidental request logging."
        },
        {
          "label": "Appendix F: audit the effect",
          "href": "https://scalableweb.dev/appendices/durable-workflows/#audit-the-effect-boundary",
          "description": "Place deduplication at the authority for the effect."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#idempotency",
      "readings": [
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/",
        "https://scalableweb.dev/appendices/durable-workflows/"
      ],
      "resourceIds": [
        "graph-idempotency",
        "demo-durable-effect-retry-lab"
      ],
      "explorationIds": [
        "challenge-an-explanation"
      ]
    },
    {
      "id": "retry",
      "title": "Retry policy",
      "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.",
      "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.",
      "misconception": "Retrying always improves availability. It can duplicate effects or amplify the pressure that caused the failure.",
      "contexts": [
        {
          "label": "Pressure: production assumptions",
          "href": "https://scalableweb.dev/chapters/reality/#local-correctness-leaves-production-assumptions-untested",
          "description": "Account for network ambiguity and retry amplification."
        },
        {
          "label": "Appendix F: retry-safe effects",
          "href": "https://scalableweb.dev/appendices/durable-workflows/#audit-the-effect-boundary",
          "description": "Distinguish workflow progress from effect safety."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#retry",
      "readings": [
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/appendices/durable-workflows/"
      ],
      "resourceIds": [
        "graph-retry",
        "demo-opentelemetry-trace-explorer",
        "demo-durable-effect-retry-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "backpressure",
      "title": "Admission and 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.",
      "example": "A full event queue rejects optional submissions with a retry policy instead of accumulating unbounded waiting and exhausting memory.",
      "misconception": "Rejecting load means the design cannot scale, or a queue is unlimited capacity. Bounded admission can protect useful work while capacity is restored.",
      "contexts": [
        {
          "label": "Scaling: response guide",
          "href": "https://scalableweb.dev/chapters/scaling/#start-with-the-pressure",
          "description": "Match the intervention to the pressured boundary."
        },
        {
          "label": "Pressure: recovery architecture",
          "href": "https://scalableweb.dev/chapters/reality/#recovery-is-part-of-the-architecture",
          "description": "Plan how overload and backlog drain end."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#backpressure",
      "readings": [
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/chapters/scaling/"
      ],
      "resourceIds": [
        "graph-backpressure",
        "demo-saturation-boundary-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "recovery",
      "title": "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.",
      "example": "Restore the worker, then observe queue age and visible event freshness until the backlog drains. A healthy process alone does not establish recovery.",
      "misconception": "Restarting the endpoint ends the incident. Stale copies, duplicates, blocked tools, and pending work may persist.",
      "contexts": [
        {
          "label": "Pressure: recovery is architecture",
          "href": "https://scalableweb.dev/chapters/reality/#recovery-is-part-of-the-architecture",
          "description": "Prepare the path before the disturbance."
        },
        {
          "label": "Thesis tracker: recovery features",
          "href": "https://scalableweb.dev/case-studies/thesis-journey-tracker/#recovery-is-a-first-class-feature",
          "description": "See recovery become part of the product."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#recovery",
      "readings": [
        "https://scalableweb.dev/chapters/reality/",
        "https://scalableweb.dev/appendices/durable-workflows/",
        "https://scalableweb.dev/parts/challenge/",
        "https://scalableweb.dev/case-studies/thesis-journey-tracker/"
      ],
      "resourceIds": [
        "graph-recovery",
        "dependency-failure",
        "demo-acid-transaction-lab",
        "demo-orchestration-control-loop",
        "demo-durable-effect-retry-lab",
        "demo-cap-partition-lab"
      ],
      "explorationIds": [
        "verify-remediation"
      ]
    },
    {
      "id": "partition",
      "title": "Network 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.",
      "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.",
      "misconception": "A deployment can freely choose consistency and availability as independent switches during a partition. The operation's contract constrains the choice.",
      "contexts": [
        {
          "label": "Scaling: operational choice",
          "href": "https://scalableweb.dev/chapters/scaling/#partitions-force-an-operational-choice",
          "description": "Explain the consequences for the tracker."
        },
        {
          "label": "Appendix C: partition proof and lab",
          "href": "https://scalableweb.dev/appendices/advanced-web-boundaries/#partitions-and-replicated-state",
          "description": "Examine the guarantees and compare two partition policies."
        },
        {
          "label": "Pressure: documented incidents",
          "href": "https://scalableweb.dev/chapters/reality/#what-documented-web-incidents-reveal",
          "description": "Follow divergent histories during a real partition."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#partition",
      "readings": [
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/"
      ],
      "resourceIds": [
        "graph-partition",
        "demo-cap-partition-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "consistency",
      "title": "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.",
      "example": "A committed event may reach a regional feed later. Decide whether that stale read is permitted and how the UI represents pending visibility.",
      "misconception": "All consistency choices are simply strong or eventual. The contract must describe what a consumer can rely on in its specific operation.",
      "contexts": [
        {
          "label": "Scaling: geography and latency",
          "href": "https://scalableweb.dev/chapters/scaling/#latency-and-geography",
          "description": "Connect distance with observation guarantees."
        },
        {
          "label": "Appendix C: partition proof and lab",
          "href": "https://scalableweb.dev/appendices/advanced-web-boundaries/#partitions-and-replicated-state",
          "description": "Distinguish operation ordering from transaction atomicity."
        },
        {
          "label": "Architecture: data authority",
          "href": "https://scalableweb.dev/chapters/architecture/#data-placement-follows-authority-and-access",
          "description": "Distinguish authoritative state from copies."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#consistency",
      "readings": [
        "https://scalableweb.dev/chapters/architecture/",
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/appendices/advanced-web-boundaries/"
      ],
      "resourceIds": [
        "graph-consistency",
        "demo-acid-transaction-lab",
        "demo-cache-decision-lab",
        "demo-cap-partition-lab",
        "demo-latency-budget-map"
      ],
      "explorationIds": []
    },
    {
      "id": "durable-workflow",
      "title": "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.",
      "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.",
      "misconception": "Durable execution guarantees exactly-once external effects. Progress recovery and effect safety are separate guarantees.",
      "contexts": [
        {
          "label": "Appendix F: preserve coordination progress",
          "href": "https://scalableweb.dev/appendices/durable-workflows/#durable-execution-preserves-coordination-progress",
          "description": "Separate durable coordination from effect semantics."
        },
        {
          "label": "Slideotter: artifact authority",
          "href": "https://scalableweb.dev/case-studies/slideotter/#the-project-found-durable-authority-boundaries",
          "description": "Locate the artifact that generation may replace."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#durable-workflow",
      "readings": [
        "https://scalableweb.dev/appendices/durable-workflows/",
        "https://scalableweb.dev/parts/appendices/",
        "https://scalableweb.dev/case-studies/slideotter/",
        "https://scalableweb.dev/case-studies/temper/"
      ],
      "resourceIds": [
        "graph-durable-workflow",
        "demo-durable-effect-retry-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "contention",
      "title": "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.",
      "example": "More event workers compete for the same database lock. Parallelism increases, but completed throughput can plateau or fall as coordination grows.",
      "misconception": "Amdahl's ideal speedup bound accounts for every coordination cost. Added contention can make actual scaling worse than that bound suggests.",
      "contexts": [
        {
          "label": "Scaling: beyond Amdahl",
          "href": "https://scalableweb.dev/chapters/scaling/#contention-beyond-amdahl-s-bound",
          "description": "Account for costs introduced by parallelism."
        },
        {
          "label": "Appendix E: contention curve",
          "href": "https://scalableweb.dev/appendices/scalability-models/#contention-curve-lab",
          "description": "Compare a model with the observed curve."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#contention",
      "readings": [
        "https://scalableweb.dev/chapters/agent-fleets/",
        "https://scalableweb.dev/chapters/scaling/",
        "https://scalableweb.dev/appendices/scalability-models/",
        "https://scalableweb.dev/parts/appendices/"
      ],
      "resourceIds": [
        "graph-contention",
        "demo-contention-curve-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "lusser-law",
      "title": "Lusser's 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.",
      "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.",
      "misconception": "High component reliability guarantees equally high journey reliability. Required stages accumulate failure opportunities, and common causes can change the calculation.",
      "contexts": [
        {
          "label": "Appendix E: reliability chain",
          "href": "https://scalableweb.dev/appendices/scalability-models/#lusser-s-law-and-the-reliability-chain",
          "description": "Declare the chain and denominator."
        },
        {
          "label": "Appendix E: test independence",
          "href": "https://scalableweb.dev/appendices/scalability-models/#test-the-independence-assumption",
          "description": "Inspect shared failure rather than assuming it away."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#lusser-law",
      "readings": [
        "https://scalableweb.dev/appendices/scalability-models/",
        "https://scalableweb.dev/parts/appendices/"
      ],
      "resourceIds": [
        "graph-lusser-law",
        "demo-reliability-chain-lab"
      ],
      "explorationIds": []
    },
    {
      "id": "reliability",
      "title": "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.",
      "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.",
      "misconception": "One successful run establishes reliability, or success after repeated attempts implies first-attempt reliability.",
      "contexts": [
        {
          "label": "Appendix A: uncertainty and trials",
          "href": "https://scalableweb.dev/appendices/evaluating-agentic-workflows/#report-uncertainty-not-only-point-estimates",
          "description": "Choose a success summary that matches the question."
        },
        {
          "label": "Appendix E: eligible attempts",
          "href": "https://scalableweb.dev/appendices/scalability-models/#estimate-from-all-eligible-attempts",
          "description": "Preserve the denominator across the journey."
        }
      ],
      "url": "https://scalableweb.dev/concepts/#reliability",
      "readings": [
        "https://scalableweb.dev/appendices/evaluating-agentic-workflows/",
        "https://scalableweb.dev/appendices/scalability-models/"
      ],
      "resourceIds": [
        "graph-reliability",
        "dependency-failure",
        "demo-reliability-chain-lab"
      ],
      "explorationIds": []
    }
  ],
  "relationships": [
    {
      "source": "measurement-boundary",
      "target": "latency",
      "direction": "directed",
      "label": "defines timing scope of",
      "explanation": "The measurement boundary defines which waiting and processing latency includes."
    },
    {
      "source": "little-law",
      "target": "measurement-boundary",
      "direction": "directed",
      "label": "requires a shared",
      "explanation": "Little's Law requires work in progress, rate, and average time to describe the same boundary."
    },
    {
      "source": "queue",
      "target": "latency",
      "direction": "directed",
      "label": "can add waiting time to",
      "explanation": "Waiting in a queue contributes to latency when the queue is inside the timing boundary."
    },
    {
      "source": "throughput",
      "target": "queue",
      "direction": "undirected",
      "label": "arrivals and exits",
      "explanation": "Compare admissions with all departures at the queue boundary to explain backlog growth. Useful throughput separately counts completions that meet the declared outcome criteria."
    },
    {
      "source": "saturation",
      "target": "throughput",
      "direction": "directed",
      "label": "bounds sustainable",
      "explanation": "The saturated stage bounds the sustainable completion rate for the declared workload."
    },
    {
      "source": "queue",
      "target": "saturation",
      "direction": "directed",
      "label": "can signal",
      "explanation": "A growing queue can expose pressure above completion capacity, even while acknowledgments remain fast."
    },
    {
      "source": "little-law",
      "target": "queue",
      "direction": "directed",
      "label": "accounts for work in",
      "explanation": "Little's Law connects stable work in progress, including queued and processing work, to rate and average time."
    },
    {
      "source": "little-law",
      "target": "amdahl-law",
      "direction": "undirected",
      "label": "different questions",
      "explanation": "Little's Law checks stable flow averages; Amdahl's Law bounds ideal fixed-workload parallel speedup."
    },
    {
      "source": "throughput",
      "target": "amdahl-law",
      "direction": "undirected",
      "label": "ideal gain vs output",
      "explanation": "An Amdahl speedup bound does not guarantee accepted-change throughput; review, coordination, and correctness still matter."
    },
    {
      "source": "little-law",
      "target": "latency",
      "direction": "directed",
      "label": "uses average",
      "explanation": "Little's Law uses average time inside the boundary, not a tail percentile such as p95."
    },
    {
      "source": "loop-engineering",
      "target": "feedback-loop",
      "direction": "directed",
      "label": "designs agent use of",
      "explanation": "Loop engineering chooses the observations and responses that guide agent work; a feedback loop describes how effects influence subsequent behavior, including harmful reinforcing cycles."
    },
    {
      "source": "harness",
      "target": "loop-engineering",
      "direction": "directed",
      "label": "supplies controls for",
      "explanation": "The project harness supplies maintained instructions, environments, and checks that loop engineering connects to task initiation, progress, repair, and acceptance."
    },
    {
      "source": "acceptance-criteria",
      "target": "loop-engineering",
      "direction": "directed",
      "label": "define outcomes for",
      "explanation": "Acceptance criteria define the result a loop should pursue. A stop condition can also terminate an unsuccessful run at its budget or escalation boundary."
    },
    {
      "source": "authority",
      "target": "loop-engineering",
      "direction": "directed",
      "label": "bounds actions in",
      "explanation": "A loop may continue only within the granted action authority; starting another iteration or run does not expand permissions."
    },
    {
      "source": "observability",
      "target": "loop-engineering",
      "direction": "directed",
      "label": "supplies evidence for",
      "explanation": "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."
    },
    {
      "source": "eval",
      "target": "loop-engineering",
      "direction": "directed",
      "label": "assesses outcomes of",
      "explanation": "Representative tasks and independent acceptance evidence can assess a loop change while accounting for retries, resource cost, and human correction."
    },
    {
      "source": "loop-engineering",
      "target": "agent-fleet",
      "direction": "directed",
      "label": "can coordinate",
      "explanation": "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."
    },
    {
      "source": "review-budget",
      "target": "loop-engineering",
      "direction": "directed",
      "label": "constrains admission in",
      "explanation": "Loop design must account for the owner's capacity to review, correct, and accept work; more autonomous runs can otherwise accumulate an unreviewed backlog."
    },
    {
      "source": "decision-log",
      "target": "decision-reversibility",
      "direction": "directed",
      "label": "records conditions for",
      "explanation": "A decision record can state which choices remain soft, what dependencies would make them hard, and what safe reversal would require."
    },
    {
      "source": "decision-log",
      "target": "trade-off",
      "direction": "directed",
      "label": "records rationale for",
      "explanation": "The log preserves the alternatives, rationale, and consequences that justified a trade-off under the conditions known at the time."
    },
    {
      "source": "decision-log",
      "target": "harness",
      "direction": "undirected",
      "label": "accepted context",
      "explanation": "Decision records preserve accepted project context, while current specifications and executable harness checks must reflect the implemented choice."
    },
    {
      "source": "decision-log",
      "target": "feedback-loop",
      "direction": "undirected",
      "label": "revisit conditions",
      "explanation": "A recorded revisit condition makes new evidence a reason to review a choice; a superseding record preserves why the earlier decision changed."
    },
    {
      "source": "decision-log",
      "target": "technical-debt",
      "direction": "directed",
      "label": "can document",
      "explanation": "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."
    },
    {
      "source": "decision-log",
      "target": "authority",
      "direction": "undirected",
      "label": "decision ownership",
      "explanation": "A proposed record does not grant action authority; acceptance needs a named owner, and the record's status must distinguish intent from implementation."
    },
    {
      "source": "decision-reversibility",
      "target": "technical-debt",
      "direction": "undirected",
      "label": "commitment vs debt",
      "explanation": "Technical debt can reduce future options, but a hard decision is not automatically debt; its dependencies and reversal cost may be necessary and justified."
    },
    {
      "source": "decision-reversibility",
      "target": "development-friction",
      "direction": "undirected",
      "label": "reversal cost",
      "explanation": "A choice becomes harder to revise as safe reversal requires coordination across data, consumers, and deployment boundaries."
    },
    {
      "source": "contract",
      "target": "decision-reversibility",
      "direction": "directed",
      "label": "can constrain",
      "explanation": "An independently deployed consumer relying on a contract can turn a locally editable choice into a hard compatibility commitment."
    },
    {
      "source": "decision-reversibility",
      "target": "trade-off",
      "direction": "undirected",
      "label": "option value",
      "explanation": "Planning a trade-off includes the value of keeping an uncertain choice soft and the obligations introduced by committing to it."
    },
    {
      "source": "change-probe",
      "target": "decision-reversibility",
      "direction": "directed",
      "label": "assesses",
      "explanation": "A bounded change probe can test how much effort a revision requires and which dependencies make a decision hard to change."
    },
    {
      "source": "decision-reversibility",
      "target": "recovery",
      "direction": "undirected",
      "label": "safe reversal",
      "explanation": "Reversing a decision after durable effects may require migration or reconciliation; restoring code alone does not establish safe recovery."
    },
    {
      "source": "development-friction",
      "target": "technical-debt",
      "direction": "undirected",
      "label": "change cost",
      "explanation": "Friction can expose the practical cost of technical debt, but protective checks and necessary commitments are not automatically debt."
    },
    {
      "source": "reproducible-environment",
      "target": "development-friction",
      "direction": "directed",
      "label": "can reduce",
      "explanation": "A declared, reproducible environment can reduce setup friction and reveal hidden inputs rather than relying on undocumented repairs."
    },
    {
      "source": "development-friction",
      "target": "contract",
      "direction": "undirected",
      "label": "cross-boundary change",
      "explanation": "A small feature can create friction as it crosses HTTP, data, cache, and deployment contracts owned at different boundaries."
    },
    {
      "source": "feedback-loop",
      "target": "development-friction",
      "direction": "directed",
      "label": "can reduce",
      "explanation": "Feedback matched to the changed boundary can reduce diagnosis and revision friction while retaining useful checks."
    },
    {
      "source": "change-probe",
      "target": "development-friction",
      "direction": "directed",
      "label": "assesses",
      "explanation": "A bounded change probe records concrete blockages and effort so a friction claim can be tested by an unfamiliar maintainer."
    },
    {
      "source": "development-friction",
      "target": "authority",
      "direction": "undirected",
      "label": "protective friction",
      "explanation": "Explicit ownership reduces coordination ambiguity; authorization and release gates can remain protective friction when they control a named risk."
    },
    {
      "source": "scalability",
      "target": "pressure",
      "direction": "directed",
      "label": "is assessed under",
      "explanation": "A scalability claim states which goal must hold as a particular pressure changes."
    },
    {
      "source": "saturation",
      "target": "scalability",
      "direction": "directed",
      "label": "can threaten",
      "explanation": "Saturation identifies the current limit that threatens the maintained scalability goal."
    },
    {
      "source": "benchmark",
      "target": "scalability",
      "direction": "directed",
      "label": "tests claims of",
      "explanation": "A benchmark protocol makes a conditional scalability claim testable."
    },
    {
      "source": "scalability",
      "target": "trade-off",
      "direction": "undirected",
      "label": "response obligations",
      "explanation": "A scaling response must justify the costs and obligations it introduces alongside the maintained goal."
    },
    {
      "source": "pressure",
      "target": "technical-debt",
      "direction": "directed",
      "label": "can expose",
      "explanation": "Change pressure can expose future change cost from earlier shortcuts, compromises, or unmanaged coupling. A necessary compatibility obligation alone does not establish technical debt."
    },
    {
      "source": "agent-fleet",
      "target": "pressure",
      "direction": "directed",
      "label": "can create",
      "explanation": "Adding contributors or agents increases coordination pressure as well as possible parallelism."
    },
    {
      "source": "pressure",
      "target": "cache",
      "direction": "directed",
      "label": "can motivate",
      "explanation": "Data or demand pressure may motivate caching, but the cache introduces a freshness and access contract."
    },
    {
      "source": "benchmark",
      "target": "measurement-boundary",
      "direction": "directed",
      "label": "declares",
      "explanation": "A benchmark protocol declares the boundary at which elapsed time and completed work are counted."
    },
    {
      "source": "reproducible-environment",
      "target": "benchmark",
      "direction": "directed",
      "label": "supports repeatable",
      "explanation": "Reproducible environments help separate implementation differences from setup differences in a benchmark."
    },
    {
      "source": "benchmark",
      "target": "eval",
      "direction": "undirected",
      "label": "shared protocol",
      "explanation": "Benchmarks and agent evaluations both require declared tasks, boundaries, outcome criteria, and failure accounting."
    },
    {
      "source": "benchmark",
      "target": "tail-latency",
      "direction": "directed",
      "label": "declares how to measure",
      "explanation": "A benchmark needs a declared latency population and percentile convention to support a tail-latency claim."
    },
    {
      "source": "latency",
      "target": "tail-latency",
      "direction": "undirected",
      "label": "mean vs tail",
      "explanation": "Tail latency describes slow outcomes that an average elapsed time can hide."
    },
    {
      "source": "observability",
      "target": "tail-latency",
      "direction": "directed",
      "label": "can help explain",
      "explanation": "Latency distributions reveal a slow population; traces and event records help investigate its path."
    },
    {
      "source": "observability",
      "target": "measurement-boundary",
      "direction": "undirected",
      "label": "matched signals",
      "explanation": "Useful signals must identify the same logical work and boundaries as the outcome being explained."
    },
    {
      "source": "observability",
      "target": "recovery",
      "direction": "directed",
      "label": "provides evidence for",
      "explanation": "Recovery needs evidence about authoritative state, pending work, and user-visible outcomes, not only process health."
    },
    {
      "source": "observability",
      "target": "feedback-loop",
      "direction": "directed",
      "label": "supplies signals for",
      "explanation": "A corrective feedback loop can choose a useful response only when its signals describe the relevant goal and boundary."
    },
    {
      "source": "feedback-loop",
      "target": "retry",
      "direction": "undirected",
      "label": "reinforcing load",
      "explanation": "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."
    },
    {
      "source": "goodhart-law",
      "target": "throughput",
      "direction": "directed",
      "label": "warns about targeting",
      "explanation": "Counting generated or acknowledged work can become a misleading target when useful accepted completions are the intended outcome."
    },
    {
      "source": "goodhart-law",
      "target": "acceptance-criteria",
      "direction": "undirected",
      "label": "outcome checks",
      "explanation": "Acceptance criteria help check the intended outcome when a convenient proxy metric becomes a target."
    },
    {
      "source": "eval",
      "target": "reliability",
      "direction": "directed",
      "label": "estimates",
      "explanation": "Repeated agent evaluation distinguishes a successful example from evidence about success frequency and uncertainty."
    },
    {
      "source": "acceptance-criteria",
      "target": "eval",
      "direction": "directed",
      "label": "define grading for",
      "explanation": "An evaluation grader must assess the declared task and invariants rather than hidden acceptance assumptions."
    },
    {
      "source": "harness",
      "target": "eval",
      "direction": "directed",
      "label": "supplies checks for",
      "explanation": "The project harness supplies reusable checks and setup, while the evaluation harness provisions and scores trials."
    },
    {
      "source": "change-probe",
      "target": "technical-debt",
      "direction": "directed",
      "label": "can reveal",
      "explanation": "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."
    },
    {
      "source": "eval",
      "target": "change-probe",
      "direction": "directed",
      "label": "can include",
      "explanation": "An agent evaluation can include next-change tasks to assess maintainability beyond initial task success."
    },
    {
      "source": "reproducible-environment",
      "target": "change-probe",
      "direction": "directed",
      "label": "supports repeatable",
      "explanation": "An unfamiliar auditor needs a reproducible starting environment to distinguish setup friction from change difficulty."
    },
    {
      "source": "harness",
      "target": "agent",
      "direction": "directed",
      "label": "supplies context for",
      "explanation": "An agent's useful capability depends on the project context, tools, checks, and commands supplied by its harness."
    },
    {
      "source": "authority",
      "target": "agent",
      "direction": "directed",
      "label": "bounds actions of",
      "explanation": "An agent's ability to invoke a tool must be bounded by the authority granted for the task."
    },
    {
      "source": "agent-fleet",
      "target": "agent",
      "direction": "directed",
      "label": "coordinates",
      "explanation": "A fleet extends one agent's execution loop with explicit coordination, integration, and acceptance."
    },
    {
      "source": "harness",
      "target": "feedback-loop",
      "direction": "directed",
      "label": "provides checks for",
      "explanation": "Executable harness checks turn generated work into feedback that can guide a revision."
    },
    {
      "source": "harness",
      "target": "reproducible-environment",
      "direction": "directed",
      "label": "requires a declared",
      "explanation": "A harness needs a declared environment so its checks can be run by another agent or maintainer."
    },
    {
      "source": "harness",
      "target": "acceptance-criteria",
      "direction": "directed",
      "label": "provides evidence for",
      "explanation": "Harness checks provide repeatable evidence for acceptance criteria, while a named owner remains accountable for acceptance."
    },
    {
      "source": "authority",
      "target": "acceptance-criteria",
      "direction": "undirected",
      "label": "acceptance ownership",
      "explanation": "Authority defines who may execute work and who may judge that the acceptance criteria have been met."
    },
    {
      "source": "authority",
      "target": "state-authority",
      "direction": "undirected",
      "label": "permission vs commit",
      "explanation": "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."
    },
    {
      "source": "contract",
      "target": "authority",
      "direction": "directed",
      "label": "states rules for",
      "explanation": "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."
    },
    {
      "source": "feedback-loop",
      "target": "technical-debt",
      "direction": "undirected",
      "label": "omitted future cost",
      "explanation": "Feedback that omits the cost of later changes can allow technical debt to grow while current tasks pass."
    },
    {
      "source": "technical-debt",
      "target": "contract",
      "direction": "undirected",
      "label": "coupled contracts",
      "explanation": "Unclear or tightly coupled contracts can make one local change require coordinated changes elsewhere."
    },
    {
      "source": "task-graph",
      "target": "agent-fleet",
      "direction": "directed",
      "label": "organizes work in",
      "explanation": "A fleet's task graph states what can proceed independently and where contracts or integration impose order."
    },
    {
      "source": "amdahl-law",
      "target": "agent-fleet",
      "direction": "directed",
      "label": "bounds ideal speedup of",
      "explanation": "Amdahl's Law provides an ideal bound when part of a fleet's fixed workload remains sequential."
    },
    {
      "source": "agent-fleet",
      "target": "review-budget",
      "direction": "undirected",
      "label": "candidate vs accepted",
      "explanation": "Additional agents can increase candidate output faster than human review can accept it."
    },
    {
      "source": "contract",
      "target": "task-graph",
      "direction": "directed",
      "label": "constrains independence in",
      "explanation": "Task independence depends on compatible shared contracts, not merely separate files."
    },
    {
      "source": "task-graph",
      "target": "acceptance-criteria",
      "direction": "directed",
      "label": "requires",
      "explanation": "Integration points in a task graph need acceptance checks that cover the combined behavior."
    },
    {
      "source": "review-budget",
      "target": "queue",
      "direction": "undirected",
      "label": "review backlog",
      "explanation": "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."
    },
    {
      "source": "review-budget",
      "target": "throughput",
      "direction": "directed",
      "label": "can limit accepted",
      "explanation": "Reviewer attention and correction effort can limit accepted-change throughput even when generation speeds up."
    },
    {
      "source": "review-budget",
      "target": "amdahl-law",
      "direction": "undirected",
      "label": "sequential fraction",
      "explanation": "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."
    },
    {
      "source": "review-budget",
      "target": "saturation",
      "direction": "directed",
      "label": "can be a limit at",
      "explanation": "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."
    },
    {
      "source": "invariant",
      "target": "contract",
      "direction": "directed",
      "label": "constrains transitions in",
      "explanation": "A contract describes valid boundary behavior; invariants state conditions its accepted transitions must preserve."
    },
    {
      "source": "contract",
      "target": "idempotency",
      "direction": "directed",
      "label": "defines effects for",
      "explanation": "The contract names all intended effects against which idempotency is judged. A key-based retry protocol also needs scope, conflict, retention, and outcome rules."
    },
    {
      "source": "rendering",
      "target": "latency",
      "direction": "directed",
      "label": "can affect",
      "explanation": "Moving rendering or activation changes which work lies on the measured user journey."
    },
    {
      "source": "rendering",
      "target": "cache",
      "direction": "undirected",
      "label": "freshness and activation",
      "explanation": "A cached representation needs freshness and activation policies in addition to a fast delivery path."
    },
    {
      "source": "rendering",
      "target": "state-authority",
      "direction": "undirected",
      "label": "view vs durable state",
      "explanation": "Rendering a representation must remain distinct from committing the durable action it displays."
    },
    {
      "source": "transaction",
      "target": "state-authority",
      "direction": "directed",
      "label": "protects changes to",
      "explanation": "Transactions protect related changes at the durable authority under the store's actual guarantees."
    },
    {
      "source": "state-authority",
      "target": "cache",
      "direction": "directed",
      "label": "is the source for",
      "explanation": "A cache is a controlled copy whose freshness and invalidation depend on the authoritative state."
    },
    {
      "source": "consistency",
      "target": "state-authority",
      "direction": "directed",
      "label": "governs observations of",
      "explanation": "Consistency promises describe how consumers observe authoritative changes through concurrency and copies."
    },
    {
      "source": "transaction",
      "target": "invariant",
      "direction": "directed",
      "label": "must preserve",
      "explanation": "The chosen transaction and isolation behavior must preserve the domain invariant under concurrent transitions."
    },
    {
      "source": "transaction",
      "target": "idempotency",
      "direction": "directed",
      "label": "can support",
      "explanation": "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."
    },
    {
      "source": "cache",
      "target": "consistency",
      "direction": "directed",
      "label": "has freshness rules in",
      "explanation": "Cache freshness is part of the observation promise, but it does not by itself define every consistency guarantee."
    },
    {
      "source": "cache",
      "target": "trade-off",
      "direction": "directed",
      "label": "introduces",
      "explanation": "Caching can reduce dependency load while introducing invalidation, freshness, and access obligations."
    },
    {
      "source": "idempotency",
      "target": "retry",
      "direction": "directed",
      "label": "guards repeated effects of",
      "explanation": "A deduplicated command reuses its logical operation identity after an ambiguous outcome so the retry cannot invent another durable action."
    },
    {
      "source": "idempotency",
      "target": "durable-workflow",
      "direction": "directed",
      "label": "guards repeated effects in",
      "explanation": "Durable coordination can resume steps, while idempotency protects effects that may be attempted again."
    },
    {
      "source": "retry",
      "target": "saturation",
      "direction": "directed",
      "label": "can amplify load at",
      "explanation": "Retries can amplify pressure on an already saturated dependency instead of improving useful completion."
    },
    {
      "source": "retry",
      "target": "recovery",
      "direction": "directed",
      "label": "supports bounded replay in",
      "explanation": "Bounded retry and backlog replay policies must protect state integrity and capacity during recovery."
    },
    {
      "source": "backpressure",
      "target": "queue",
      "direction": "directed",
      "label": "can bound admission to",
      "explanation": "A bounded queue requires a policy for slowing or rejecting new work when downstream capacity cannot keep up."
    },
    {
      "source": "backpressure",
      "target": "saturation",
      "direction": "directed",
      "label": "can protect capacity at",
      "explanation": "Admission controls can protect a saturated boundary while making rejected or delayed work explicit."
    },
    {
      "source": "backpressure",
      "target": "trade-off",
      "direction": "directed",
      "label": "can introduce",
      "explanation": "Bounding admission can preserve useful service while sacrificing immediate acceptance of some work."
    },
    {
      "source": "durable-workflow",
      "target": "recovery",
      "direction": "directed",
      "label": "preserves progress for",
      "explanation": "Preserved workflow progress helps interrupted coordination resume, but recovery must still audit its effects."
    },
    {
      "source": "consistency",
      "target": "partition",
      "direction": "directed",
      "label": "constrains acceptance during",
      "explanation": "During a partition, the operation's consistency promise constrains which work disconnected nodes may accept."
    },
    {
      "source": "recovery",
      "target": "partition",
      "direction": "directed",
      "label": "reconciles histories after",
      "explanation": "Recovery from a partition may require reconciling divergent histories and draining pending work."
    },
    {
      "source": "consistency",
      "target": "latency",
      "direction": "directed",
      "label": "can add delay to",
      "explanation": "Coordinating remote state can add latency; permitting delayed observations changes the consumer's contract."
    },
    {
      "source": "amdahl-law",
      "target": "contention",
      "direction": "directed",
      "label": "omits new costs of",
      "explanation": "Amdahl's ideal fixed-workload bound omits new contention and coordination costs introduced by parallelism."
    },
    {
      "source": "contention",
      "target": "throughput",
      "direction": "directed",
      "label": "can reduce",
      "explanation": "Competition for a shared resource can make throughput plateau or decline as workers are added."
    },
    {
      "source": "contention",
      "target": "saturation",
      "direction": "directed",
      "label": "can expose",
      "explanation": "Contention can expose a binding shared-resource limit before every worker is fully utilized."
    },
    {
      "source": "lusser-law",
      "target": "reliability",
      "direction": "directed",
      "label": "calculates chain",
      "explanation": "Lusser's Law calculates a required-stage chain's reliability under a declared independence assumption."
    },
    {
      "source": "contract",
      "target": "lusser-law",
      "direction": "directed",
      "label": "defines required stages for",
      "explanation": "The reliability chain includes the stages that must succeed to meet the declared end-to-end contract."
    },
    {
      "source": "reliability",
      "target": "measurement-boundary",
      "direction": "directed",
      "label": "requires a declared",
      "explanation": "A reliability claim needs a declared eligible-attempt denominator and end-to-end success boundary."
    }
  ],
  "explorations": [
    {
      "id": "prototype-to-shared-use",
      "title": "Move a prototype into shared use",
      "phase": "Establish",
      "summary": "A working CSV exporter is ready for a demo. What would make it ready for a team's weekly report?",
      "conceptIds": [
        "authority",
        "acceptance-criteria",
        "decision-reversibility"
      ],
      "task": {
        "title": "Establish the evidence baseline",
        "href": "https://scalableweb.dev/project/establish/#establish-the-evidence-baseline"
      },
      "reading": {
        "title": "Assign authority and ownership",
        "href": "https://scalableweb.dev/chapters/scalable-development/#assign-authority-and-ownership"
      },
      "url": "https://scalableweb.dev/explore/prototype-to-shared-use/",
      "agentUrl": "https://scalableweb.dev/explore/prototype-to-shared-use/agent.md",
      "discussionUrl": "https://scalableweb.dev/explore/prototype-to-shared-use/discussion.md",
      "graphUrl": "https://scalableweb.dev/concepts/?topic=authority"
    },
    {
      "id": "challenge-an-explanation",
      "title": "Challenge an explanation",
      "phase": "Establish",
      "summary": "An agent says a recorder prevents duplicate events after restart. Predict the behavior and test its claim.",
      "conceptIds": [
        "idempotency",
        "state-authority",
        "acceptance-criteria"
      ],
      "task": {
        "title": "Establish the evidence baseline",
        "href": "https://scalableweb.dev/project/establish/#establish-the-evidence-baseline"
      },
      "reading": {
        "title": "Test an explanation against behavior",
        "href": "https://scalableweb.dev/chapters/scalable-development/#test-an-explanation-against-behavior"
      },
      "url": "https://scalableweb.dev/explore/challenge-an-explanation/",
      "agentUrl": "https://scalableweb.dev/explore/challenge-an-explanation/agent.md",
      "discussionUrl": "https://scalableweb.dev/explore/challenge-an-explanation/discussion.md",
      "graphUrl": "https://scalableweb.dev/concepts/?topic=idempotency"
    },
    {
      "id": "telemetry-guided-repair",
      "title": "Compare evidence for an agent repair",
      "phase": "Establish",
      "summary": "Saving an event reports success, but the list stays unchanged. Compare task feedback, runtime logs, and a diagnostic brief.",
      "conceptIds": [
        "observability",
        "eval",
        "acceptance-criteria"
      ],
      "task": {
        "title": "Establish the evidence baseline",
        "href": "https://scalableweb.dev/project/establish/#establish-the-evidence-baseline"
      },
      "reading": {
        "title": "Use runtime evidence during repair",
        "href": "https://scalableweb.dev/chapters/benchmarking/#use-runtime-evidence-during-repair"
      },
      "url": "https://scalableweb.dev/explore/telemetry-guided-repair/",
      "agentUrl": "https://scalableweb.dev/explore/telemetry-guided-repair/agent.md",
      "discussionUrl": "https://scalableweb.dev/explore/telemetry-guided-repair/discussion.md",
      "graphUrl": "https://scalableweb.dev/concepts/?topic=observability"
    },
    {
      "id": "verify-remediation",
      "title": "Follow a fix into running systems",
      "phase": "Challenge",
      "summary": "A release succeeds and every health check passes. Decide what the runtime inventory still requires you to investigate.",
      "conceptIds": [
        "recovery",
        "observability",
        "acceptance-criteria"
      ],
      "task": {
        "title": "Apply runtime pressure and examine recovery",
        "href": "https://scalableweb.dev/project/challenge/#apply-runtime-pressure"
      },
      "reading": {
        "title": "Follow a fix through affected deployments",
        "href": "https://scalableweb.dev/chapters/reality/#follow-a-fix-through-affected-deployments"
      },
      "url": "https://scalableweb.dev/explore/verify-remediation/",
      "agentUrl": "https://scalableweb.dev/explore/verify-remediation/agent.md",
      "discussionUrl": "https://scalableweb.dev/explore/verify-remediation/discussion.md",
      "graphUrl": "https://scalableweb.dev/concepts/?topic=recovery"
    },
    {
      "id": "temporary-api-consumers",
      "title": "Probe an API with temporary clients",
      "phase": "Challenge",
      "summary": "A generated CSV client reports success but exports two rows. Design independent checks for a fixed paginated event feed.",
      "conceptIds": [
        "contract",
        "acceptance-criteria",
        "eval",
        "authority"
      ],
      "task": {
        "title": "Repeat the evidence collection",
        "href": "https://scalableweb.dev/project/challenge/#repeat-the-evidence-collection"
      },
      "reading": {
        "title": "Probe an API with temporary clients",
        "href": "https://scalableweb.dev/appendices/evaluating-agentic-workflows/#probe-an-api-with-temporary-clients"
      },
      "url": "https://scalableweb.dev/explore/temporary-api-consumers/",
      "agentUrl": "https://scalableweb.dev/explore/temporary-api-consumers/agent.md",
      "discussionUrl": "https://scalableweb.dev/explore/temporary-api-consumers/discussion.md",
      "graphUrl": "https://scalableweb.dev/concepts/?topic=contract"
    },
    {
      "id": "human-work-in-progress",
      "title": "Vary human work in progress",
      "phase": "Compare",
      "summary": "Keep the same worker limit while changing how many unfinished changes enter the workflow. Plan a bounded comparison.",
      "conceptIds": [
        "review-budget",
        "agent-fleet",
        "throughput",
        "queue"
      ],
      "task": {
        "title": "Compare one agent with the fleet",
        "href": "https://scalableweb.dev/project/compare/#compare-one-agent-with-the-fleet"
      },
      "reading": {
        "title": "Agent concurrency and human work in progress",
        "href": "https://scalableweb.dev/chapters/agent-fleets/#separate-agent-concurrency-from-human-work-in-progress"
      },
      "url": "https://scalableweb.dev/explore/human-work-in-progress/",
      "agentUrl": "https://scalableweb.dev/explore/human-work-in-progress/agent.md",
      "discussionUrl": "https://scalableweb.dev/explore/human-work-in-progress/discussion.md",
      "graphUrl": "https://scalableweb.dev/concepts/?topic=review-budget"
    },
    {
      "id": "confidence-before-routing",
      "title": "Examine a confident classification",
      "phase": "Compare",
      "summary": "Twenty valid classifications report 90% confidence. Examine the evidence before using that score to route work.",
      "conceptIds": [
        "eval",
        "authority",
        "acceptance-criteria"
      ],
      "task": {
        "title": "Compare one agent with the fleet",
        "href": "https://scalableweb.dev/project/compare/#compare-one-agent-with-the-fleet"
      },
      "reading": {
        "title": "Check confidence before routing",
        "href": "https://scalableweb.dev/appendices/evaluating-agentic-workflows/#check-confidence-before-routing"
      },
      "url": "https://scalableweb.dev/explore/confidence-before-routing/",
      "agentUrl": "https://scalableweb.dev/explore/confidence-before-routing/agent.md",
      "discussionUrl": "https://scalableweb.dev/explore/confidence-before-routing/discussion.md",
      "graphUrl": "https://scalableweb.dev/concepts/?topic=eval"
    }
  ],
  "readings": [
    {
      "url": "https://scalableweb.dev/chapters/introduction/",
      "title": "Introduction",
      "concepts": [
        "scalability",
        "pressure",
        "agent",
        "loop-engineering",
        "harness",
        "benchmark",
        "trade-off",
        "review-budget"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/what-is-scalability/",
      "title": "1 · Scalability",
      "concepts": [
        "scalability",
        "pressure",
        "saturation",
        "throughput",
        "latency",
        "tail-latency",
        "trade-off",
        "technical-debt",
        "decision-reversibility"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/scalable-development/",
      "title": "2 · Scalable development",
      "concepts": [
        "agent",
        "loop-engineering",
        "harness",
        "decision-log",
        "authority",
        "decision-reversibility",
        "feedback-loop",
        "acceptance-criteria",
        "review-budget",
        "throughput",
        "technical-debt"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/benchmarking/",
      "title": "3 · Measurement",
      "concepts": [
        "measurement-boundary",
        "loop-engineering",
        "benchmark",
        "decision-log",
        "throughput",
        "latency",
        "tail-latency",
        "observability",
        "goodhart-law",
        "queue",
        "little-law"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/architecture/",
      "title": "4 · Architecture",
      "concepts": [
        "contract",
        "rendering",
        "state-authority",
        "transaction",
        "invariant",
        "idempotency",
        "cache",
        "consistency",
        "trade-off",
        "decision-log"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/friction/",
      "title": "5 · Friction",
      "concepts": [
        "development-friction",
        "loop-engineering",
        "technical-debt",
        "decision-reversibility",
        "decision-log",
        "reproducible-environment",
        "contract",
        "authority",
        "feedback-loop",
        "change-probe",
        "harness"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/reality/",
      "title": "6 · Production pressure",
      "concepts": [
        "pressure",
        "saturation",
        "observability",
        "retry",
        "idempotency",
        "recovery",
        "decision-reversibility",
        "backpressure",
        "state-authority",
        "cache",
        "queue"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/agent-fleets/",
      "title": "7 · Agent fleets",
      "concepts": [
        "agent-fleet",
        "loop-engineering",
        "task-graph",
        "authority",
        "decision-log",
        "acceptance-criteria",
        "review-budget",
        "throughput",
        "amdahl-law",
        "contention"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/scaling/",
      "title": "8 · Scaling responses",
      "concepts": [
        "scalability",
        "pressure",
        "saturation",
        "queue",
        "backpressure",
        "latency",
        "little-law",
        "amdahl-law",
        "contention",
        "partition",
        "consistency",
        "trade-off"
      ]
    },
    {
      "url": "https://scalableweb.dev/chapters/recap/",
      "title": "9 · Recap",
      "concepts": [
        "scalability",
        "loop-engineering",
        "feedback-loop",
        "decision-log",
        "queue",
        "throughput",
        "review-budget",
        "change-probe",
        "measurement-boundary",
        "trade-off"
      ]
    },
    {
      "url": "https://scalableweb.dev/appendices/evaluating-agentic-workflows/",
      "title": "A · Agent evaluation",
      "concepts": [
        "eval",
        "loop-engineering",
        "benchmark",
        "acceptance-criteria",
        "reliability",
        "change-probe",
        "review-budget",
        "harness",
        "goodhart-law"
      ]
    },
    {
      "url": "https://scalableweb.dev/appendices/reproducible-environments/",
      "title": "B · Reproducible environments",
      "concepts": [
        "reproducible-environment",
        "harness",
        "feedback-loop",
        "benchmark",
        "measurement-boundary",
        "change-probe"
      ]
    },
    {
      "url": "https://scalableweb.dev/appendices/advanced-web-boundaries/",
      "title": "C · Advanced web boundaries",
      "concepts": [
        "contract",
        "state-authority",
        "transaction",
        "invariant",
        "partition",
        "consistency",
        "rendering",
        "cache",
        "idempotency",
        "authority"
      ]
    },
    {
      "url": "https://scalableweb.dev/appendices/agent-system-security/",
      "title": "D · Agent security",
      "concepts": [
        "authority",
        "agent",
        "agent-fleet",
        "task-graph",
        "contract",
        "acceptance-criteria",
        "harness"
      ]
    },
    {
      "url": "https://scalableweb.dev/appendices/scalability-models/",
      "title": "E · Scalability models",
      "concepts": [
        "little-law",
        "amdahl-law",
        "contention",
        "lusser-law",
        "reliability",
        "measurement-boundary"
      ]
    },
    {
      "url": "https://scalableweb.dev/appendices/durable-workflows/",
      "title": "F · Durable workflows",
      "concepts": [
        "durable-workflow",
        "idempotency",
        "retry",
        "recovery",
        "state-authority",
        "transaction"
      ]
    },
    {
      "url": "https://scalableweb.dev/parts/establish/",
      "title": "Part I · Establish",
      "concepts": [
        "scalability",
        "agent",
        "harness",
        "benchmark",
        "measurement-boundary",
        "acceptance-criteria",
        "contract",
        "trade-off"
      ]
    },
    {
      "url": "https://scalableweb.dev/parts/challenge/",
      "title": "Part II · Challenge",
      "concepts": [
        "contract",
        "technical-debt",
        "decision-reversibility",
        "decision-log",
        "pressure",
        "observability",
        "recovery",
        "change-probe"
      ]
    },
    {
      "url": "https://scalableweb.dev/parts/compare/",
      "title": "Part III · Compare",
      "concepts": [
        "agent-fleet",
        "task-graph",
        "throughput",
        "review-budget",
        "trade-off",
        "scalability"
      ]
    },
    {
      "url": "https://scalableweb.dev/parts/appendices/",
      "title": "Appendices",
      "concepts": [
        "eval",
        "reproducible-environment",
        "authority",
        "durable-workflow",
        "lusser-law",
        "contention"
      ]
    },
    {
      "url": "https://scalableweb.dev/case-studies/slideotter/",
      "title": "Case · Slideotter",
      "concepts": [
        "harness",
        "state-authority",
        "durable-workflow",
        "acceptance-criteria",
        "decision-log",
        "trade-off"
      ]
    },
    {
      "url": "https://scalableweb.dev/case-studies/thesis-journey-tracker/",
      "title": "Case · Thesis Journey Tracker",
      "concepts": [
        "scalability",
        "trade-off",
        "harness",
        "authority",
        "feedback-loop",
        "recovery"
      ]
    },
    {
      "url": "https://scalableweb.dev/case-studies/kirjolab/",
      "title": "Case · Kirjolab",
      "concepts": [
        "agent",
        "harness",
        "technical-debt",
        "review-budget",
        "change-probe",
        "contract",
        "trade-off",
        "decision-log",
        "feedback-loop"
      ]
    },
    {
      "url": "https://scalableweb.dev/case-studies/webernetes/",
      "title": "Case · Webernetes",
      "concepts": [
        "contract",
        "acceptance-criteria",
        "agent",
        "benchmark",
        "harness",
        "eval",
        "throughput",
        "feedback-loop"
      ]
    },
    {
      "url": "https://scalableweb.dev/case-studies/modern-web-guidance/",
      "title": "Case · Modern Web Guidance",
      "concepts": [
        "harness",
        "eval",
        "authority",
        "contract",
        "reproducible-environment"
      ]
    },
    {
      "url": "https://scalableweb.dev/case-studies/temper/",
      "title": "Case · Temper",
      "concepts": [
        "contract",
        "invariant",
        "authority",
        "acceptance-criteria",
        "review-budget",
        "throughput",
        "durable-workflow"
      ]
    },
    {
      "url": "https://scalableweb.dev/project/introduction/",
      "title": "Project · Introduction",
      "concepts": [
        "agent",
        "agent-fleet",
        "authority",
        "acceptance-criteria",
        "decision-log",
        "measurement-boundary"
      ]
    },
    {
      "url": "https://scalableweb.dev/project/",
      "title": "Project · Common contract",
      "concepts": [
        "contract",
        "invariant",
        "harness",
        "reproducible-environment",
        "decision-log",
        "benchmark",
        "measurement-boundary",
        "throughput",
        "tail-latency",
        "change-probe",
        "acceptance-criteria"
      ]
    },
    {
      "url": "https://scalableweb.dev/project/establish/",
      "title": "Project · Establish",
      "concepts": [
        "agent",
        "harness",
        "decision-log",
        "decision-reversibility",
        "benchmark",
        "reproducible-environment",
        "acceptance-criteria"
      ]
    },
    {
      "url": "https://scalableweb.dev/project/challenge/",
      "title": "Project · Challenge",
      "concepts": [
        "pressure",
        "contract",
        "observability",
        "technical-debt",
        "decision-reversibility",
        "change-probe",
        "acceptance-criteria",
        "little-law"
      ]
    },
    {
      "url": "https://scalableweb.dev/project/compare/",
      "title": "Project · Compare",
      "concepts": [
        "agent-fleet",
        "task-graph",
        "authority",
        "throughput",
        "review-budget",
        "trade-off",
        "decision-log"
      ]
    },
    {
      "url": "https://scalableweb.dev/project/grading/",
      "title": "Project · Assessment",
      "concepts": [
        "acceptance-criteria",
        "reproducible-environment",
        "measurement-boundary",
        "change-probe",
        "trade-off"
      ]
    }
  ],
  "learningResources": [
    {
      "id": "graph-complete",
      "kind": "graphic",
      "title": "The complete concept graph",
      "conceptIds": [
        "measurement-boundary",
        "throughput",
        "latency",
        "queue",
        "saturation",
        "little-law",
        "amdahl-law",
        "development-friction",
        "scalability",
        "pressure",
        "trade-off",
        "benchmark",
        "tail-latency",
        "observability",
        "goodhart-law",
        "eval",
        "change-probe",
        "agent",
        "loop-engineering",
        "harness",
        "acceptance-criteria",
        "authority",
        "feedback-loop",
        "decision-log",
        "decision-reversibility",
        "technical-debt",
        "reproducible-environment",
        "agent-fleet",
        "task-graph",
        "review-budget",
        "contract",
        "rendering",
        "state-authority",
        "transaction",
        "invariant",
        "cache",
        "idempotency",
        "retry",
        "backpressure",
        "recovery",
        "partition",
        "consistency",
        "durable-workflow",
        "contention",
        "lusser-law",
        "reliability"
      ],
      "url": "https://scalableweb.dev/concepts/?view=all",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-complete.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-complete.png",
        "alt": "The complete labelled concept graph. See graph.json or graph.md for the same connections as text."
      }
    },
    {
      "id": "graph-measurement-boundary",
      "kind": "graphic",
      "title": "Measurement boundary: connections",
      "conceptIds": [
        "measurement-boundary"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=measurement-boundary",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-measurement-boundary.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-measurement-boundary.png",
        "alt": "Labelled connections around Measurement boundary. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-throughput",
      "kind": "graphic",
      "title": "Throughput: connections",
      "conceptIds": [
        "throughput"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=throughput",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-throughput.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-throughput.png",
        "alt": "Labelled connections around Throughput. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-latency",
      "kind": "graphic",
      "title": "Latency: connections",
      "conceptIds": [
        "latency"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=latency",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-latency.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-latency.png",
        "alt": "Labelled connections around Latency. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-queue",
      "kind": "graphic",
      "title": "Queue: connections",
      "conceptIds": [
        "queue"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=queue",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-queue.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-queue.png",
        "alt": "Labelled connections around Queue. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-saturation",
      "kind": "graphic",
      "title": "Saturation: connections",
      "conceptIds": [
        "saturation"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=saturation",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-saturation.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-saturation.png",
        "alt": "Labelled connections around Saturation. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-little-law",
      "kind": "graphic",
      "title": "Little's Law: connections",
      "conceptIds": [
        "little-law"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=little-law",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-little-law.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-little-law.png",
        "alt": "Labelled connections around Little's Law. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-amdahl-law",
      "kind": "graphic",
      "title": "Amdahl's Law: connections",
      "conceptIds": [
        "amdahl-law"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=amdahl-law",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-amdahl-law.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-amdahl-law.png",
        "alt": "Labelled connections around Amdahl's Law. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-development-friction",
      "kind": "graphic",
      "title": "Development friction: connections",
      "conceptIds": [
        "development-friction"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=development-friction",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-development-friction.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-development-friction.png",
        "alt": "Labelled connections around Development friction. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-scalability",
      "kind": "graphic",
      "title": "Scalability: connections",
      "conceptIds": [
        "scalability"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=scalability",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-scalability.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-scalability.png",
        "alt": "Labelled connections around Scalability. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-pressure",
      "kind": "graphic",
      "title": "Scaling pressure: connections",
      "conceptIds": [
        "pressure"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=pressure",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-pressure.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-pressure.png",
        "alt": "Labelled connections around Scaling pressure. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-trade-off",
      "kind": "graphic",
      "title": "Trade-off: connections",
      "conceptIds": [
        "trade-off"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=trade-off",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-trade-off.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-trade-off.png",
        "alt": "Labelled connections around Trade-off. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-benchmark",
      "kind": "graphic",
      "title": "Benchmark protocol: connections",
      "conceptIds": [
        "benchmark"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=benchmark",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-benchmark.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-benchmark.png",
        "alt": "Labelled connections around Benchmark protocol. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-tail-latency",
      "kind": "graphic",
      "title": "Tail latency: connections",
      "conceptIds": [
        "tail-latency"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=tail-latency",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-tail-latency.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-tail-latency.png",
        "alt": "Labelled connections around Tail latency. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-observability",
      "kind": "graphic",
      "title": "Observability: connections",
      "conceptIds": [
        "observability"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=observability",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-observability.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-observability.png",
        "alt": "Labelled connections around Observability. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-goodhart-law",
      "kind": "graphic",
      "title": "Goodhart's Law: connections",
      "conceptIds": [
        "goodhart-law"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=goodhart-law",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-goodhart-law.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-goodhart-law.png",
        "alt": "Labelled connections around Goodhart's Law. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-eval",
      "kind": "graphic",
      "title": "Agent evaluation: connections",
      "conceptIds": [
        "eval"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=eval",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-eval.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-eval.png",
        "alt": "Labelled connections around Agent evaluation. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-change-probe",
      "kind": "graphic",
      "title": "Maintainability assessment: connections",
      "conceptIds": [
        "change-probe"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=change-probe",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-change-probe.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-change-probe.png",
        "alt": "Labelled connections around Maintainability assessment. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-agent",
      "kind": "graphic",
      "title": "Coding agent: connections",
      "conceptIds": [
        "agent"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=agent",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-agent.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-agent.png",
        "alt": "Labelled connections around Coding agent. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-loop-engineering",
      "kind": "graphic",
      "title": "Loop engineering: connections",
      "conceptIds": [
        "loop-engineering"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=loop-engineering",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-loop-engineering.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-loop-engineering.png",
        "alt": "Labelled connections around Loop engineering. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-harness",
      "kind": "graphic",
      "title": "Project harness: connections",
      "conceptIds": [
        "harness"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=harness",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-harness.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-harness.png",
        "alt": "Labelled connections around Project harness. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-acceptance-criteria",
      "kind": "graphic",
      "title": "Acceptance criteria: connections",
      "conceptIds": [
        "acceptance-criteria"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=acceptance-criteria",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-acceptance-criteria.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-acceptance-criteria.png",
        "alt": "Labelled connections around Acceptance criteria. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-authority",
      "kind": "graphic",
      "title": "Action authorization: connections",
      "conceptIds": [
        "authority"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=authority",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-authority.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-authority.png",
        "alt": "Labelled connections around Action authorization. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-feedback-loop",
      "kind": "graphic",
      "title": "Feedback loop: connections",
      "conceptIds": [
        "feedback-loop"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=feedback-loop",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-feedback-loop.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-feedback-loop.png",
        "alt": "Labelled connections around Feedback loop. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-decision-log",
      "kind": "graphic",
      "title": "Decision log: connections",
      "conceptIds": [
        "decision-log"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=decision-log",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-decision-log.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-decision-log.png",
        "alt": "Labelled connections around Decision log. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-decision-reversibility",
      "kind": "graphic",
      "title": "Decision reversibility: connections",
      "conceptIds": [
        "decision-reversibility"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=decision-reversibility",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-decision-reversibility.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-decision-reversibility.png",
        "alt": "Labelled connections around Decision reversibility. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-technical-debt",
      "kind": "graphic",
      "title": "Technical debt: connections",
      "conceptIds": [
        "technical-debt"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=technical-debt",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-technical-debt.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-technical-debt.png",
        "alt": "Labelled connections around Technical debt. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-reproducible-environment",
      "kind": "graphic",
      "title": "Reproducible environment: connections",
      "conceptIds": [
        "reproducible-environment"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=reproducible-environment",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-reproducible-environment.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-reproducible-environment.png",
        "alt": "Labelled connections around Reproducible environment. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-agent-fleet",
      "kind": "graphic",
      "title": "Agent fleet: connections",
      "conceptIds": [
        "agent-fleet"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=agent-fleet",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-agent-fleet.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-agent-fleet.png",
        "alt": "Labelled connections around Agent fleet. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-task-graph",
      "kind": "graphic",
      "title": "Task graph: connections",
      "conceptIds": [
        "task-graph"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=task-graph",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-task-graph.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-task-graph.png",
        "alt": "Labelled connections around Task graph. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-review-budget",
      "kind": "graphic",
      "title": "Review capacity: connections",
      "conceptIds": [
        "review-budget"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=review-budget",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-review-budget.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-review-budget.png",
        "alt": "Labelled connections around Review capacity. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-contract",
      "kind": "graphic",
      "title": "Application contract: connections",
      "conceptIds": [
        "contract"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=contract",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-contract.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-contract.png",
        "alt": "Labelled connections around Application contract. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-rendering",
      "kind": "graphic",
      "title": "Rendering and activation: connections",
      "conceptIds": [
        "rendering"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=rendering",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-rendering.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-rendering.png",
        "alt": "Labelled connections around Rendering and activation. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-state-authority",
      "kind": "graphic",
      "title": "Authoritative state: connections",
      "conceptIds": [
        "state-authority"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=state-authority",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-state-authority.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-state-authority.png",
        "alt": "Labelled connections around Authoritative state. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-transaction",
      "kind": "graphic",
      "title": "Transaction: connections",
      "conceptIds": [
        "transaction"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=transaction",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-transaction.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-transaction.png",
        "alt": "Labelled connections around Transaction. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-invariant",
      "kind": "graphic",
      "title": "Invariant: connections",
      "conceptIds": [
        "invariant"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=invariant",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-invariant.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-invariant.png",
        "alt": "Labelled connections around Invariant. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-cache",
      "kind": "graphic",
      "title": "Cache: connections",
      "conceptIds": [
        "cache"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=cache",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-cache.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-cache.png",
        "alt": "Labelled connections around Cache. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-idempotency",
      "kind": "graphic",
      "title": "Idempotency: connections",
      "conceptIds": [
        "idempotency"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=idempotency",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-idempotency.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-idempotency.png",
        "alt": "Labelled connections around Idempotency. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-retry",
      "kind": "graphic",
      "title": "Retry policy: connections",
      "conceptIds": [
        "retry"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=retry",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-retry.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-retry.png",
        "alt": "Labelled connections around Retry policy. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-backpressure",
      "kind": "graphic",
      "title": "Admission and backpressure: connections",
      "conceptIds": [
        "backpressure"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=backpressure",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-backpressure.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-backpressure.png",
        "alt": "Labelled connections around Admission and backpressure. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-recovery",
      "kind": "graphic",
      "title": "Recovery: connections",
      "conceptIds": [
        "recovery"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=recovery",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-recovery.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-recovery.png",
        "alt": "Labelled connections around Recovery. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-partition",
      "kind": "graphic",
      "title": "Network partition: connections",
      "conceptIds": [
        "partition"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=partition",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-partition.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-partition.png",
        "alt": "Labelled connections around Network partition. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-consistency",
      "kind": "graphic",
      "title": "Consistency: connections",
      "conceptIds": [
        "consistency"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=consistency",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-consistency.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-consistency.png",
        "alt": "Labelled connections around Consistency. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-durable-workflow",
      "kind": "graphic",
      "title": "Durable workflow: connections",
      "conceptIds": [
        "durable-workflow"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=durable-workflow",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-durable-workflow.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-durable-workflow.png",
        "alt": "Labelled connections around Durable workflow. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-contention",
      "kind": "graphic",
      "title": "Contention: connections",
      "conceptIds": [
        "contention"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=contention",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-contention.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-contention.png",
        "alt": "Labelled connections around Contention. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-lusser-law",
      "kind": "graphic",
      "title": "Lusser's Law: connections",
      "conceptIds": [
        "lusser-law"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=lusser-law",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-lusser-law.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-lusser-law.png",
        "alt": "Labelled connections around Lusser's Law. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "graph-reliability",
      "kind": "graphic",
      "title": "Reliability: connections",
      "conceptIds": [
        "reliability"
      ],
      "url": "https://scalableweb.dev/concepts/?topic=reliability",
      "caption": "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.",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/graph-reliability.svg",
        "png": "https://scalableweb.dev/concepts/visuals/graph-reliability.png",
        "alt": "Labelled connections around Reliability. Read their explanations in the concept graph data."
      }
    },
    {
      "id": "course-progression",
      "title": "One application, three development systems",
      "conceptIds": [
        "agent",
        "agent-fleet",
        "benchmark",
        "trade-off",
        "acceptance-criteria"
      ],
      "url": "https://scalableweb.dev/chapters/introduction/#course-progression-caption",
      "caption": "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.",
      "kind": "graphic",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/course-progression.svg",
        "png": "https://scalableweb.dev/concepts/visuals/course-progression.png",
        "alt": "The task stays comparatively stable while the development system changes. Learning accumulates; application code does not."
      }
    },
    {
      "id": "pressure-evidence",
      "title": "From pressure to bounded evidence",
      "conceptIds": [
        "scalability",
        "pressure",
        "saturation",
        "trade-off",
        "benchmark",
        "measurement-boundary"
      ],
      "url": "https://scalableweb.dev/chapters/what-is-scalability/#figure-pressure-evidence",
      "caption": "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.",
      "kind": "graphic",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/pressure-evidence.svg",
        "png": "https://scalableweb.dev/concepts/visuals/pressure-evidence.png",
        "alt": "A scaling response remains a hypothesis until bounded evidence challenges the maintained goal, limit, and trade-off."
      }
    },
    {
      "id": "dependency-failure",
      "title": "An external quota becomes the availability boundary",
      "conceptIds": [
        "saturation",
        "reliability",
        "cache",
        "contract",
        "pressure",
        "recovery"
      ],
      "url": "https://scalableweb.dev/chapters/reality/#figure-dependency-failure",
      "caption": "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.",
      "kind": "graphic",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/dependency-failure.svg",
        "png": "https://scalableweb.dev/concepts/visuals/dependency-failure.png",
        "alt": "Production traffic was amplified into GitHub API traffic until one external quota became the availability boundary for the whole site."
      }
    },
    {
      "id": "shared-knowledge-boundary",
      "title": "Knowledge and artifact ownership",
      "conceptIds": [
        "contract",
        "authority",
        "harness",
        "decision-reversibility",
        "technical-debt"
      ],
      "url": "https://scalableweb.dev/case-studies/kirjolab/#figure-shared-knowledge-boundary",
      "caption": "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.",
      "kind": "graphic",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/shared-knowledge-boundary.svg",
        "png": "https://scalableweb.dev/concepts/visuals/shared-knowledge-boundary.png",
        "alt": "Reusable source knowledge stays external; Slideotter and Kirjolab own their artifact-specific decisions."
      }
    },
    {
      "id": "three-connected-loops",
      "title": "Three connected scalability loops",
      "conceptIds": [
        "scalability",
        "loop-engineering",
        "pressure",
        "agent",
        "queue",
        "feedback-loop",
        "review-budget",
        "throughput"
      ],
      "url": "https://scalableweb.dev/chapters/recap/#figure-three-connected-loops",
      "caption": "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.",
      "kind": "graphic",
      "images": {
        "svg": "https://scalableweb.dev/concepts/visuals/three-connected-loops.svg",
        "png": "https://scalableweb.dev/concepts/visuals/three-connected-loops.png",
        "alt": "Pressure becomes development work; accepted agent-assisted change alters the application and its next likely limit."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "invariant",
        "authority",
        "contract",
        "state-authority"
      ],
      "caption": "Follow accepted and rejected transitions through a delivery statechart.",
      "controls": [
        "Scenario and transition actions",
        "Premature RELEASE proposal",
        "Cancellation",
        "Statechart inspection"
      ],
      "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.",
      "id": "demo-deterministic-boundary-lab",
      "kind": "demo",
      "title": "Deterministic boundary lab",
      "url": "https://scalableweb.dev/demos/#demo-deterministic-boundary-lab",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-deterministic-boundary-lab.png",
        "alt": "Deterministic boundary lab: static preview of the default demo view. Follow accepted and rejected transitions through a delivery statechart."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 3,
      "conceptIds": [
        "transaction",
        "invariant",
        "state-authority",
        "consistency",
        "recovery"
      ],
      "caption": "Inspect lifecycle and ledger records under failed writes, concurrency, and restart.",
      "controls": [
        "Disturbance",
        "Separate writes or transaction",
        "Read committed or serializable isolation",
        "Reply before or after durable commit on 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.",
      "id": "demo-acid-transaction-lab",
      "kind": "demo",
      "title": "ACID transaction lab",
      "url": "https://scalableweb.dev/demos/#demo-acid-transaction-lab",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-acid-transaction-lab.png",
        "alt": "ACID transaction lab: static preview of the default demo view. Inspect lifecycle and ledger records under failed writes, concurrency, and restart."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "cache",
        "contract",
        "consistency",
        "trade-off"
      ],
      "caption": "Trace reuse, validation, and stale responses under different HTTP cache policies.",
      "controls": [
        "Response policy",
        "Time since storage",
        "Changed origin representation"
      ],
      "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.",
      "id": "demo-cache-decision-lab",
      "kind": "demo",
      "title": "Cache decision lab",
      "url": "https://scalableweb.dev/demos/#demo-cache-decision-lab",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-cache-decision-lab.png",
        "alt": "Cache decision lab: static preview of the default demo view. Trace reuse, validation, and stale responses under different HTTP cache policies."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "rendering",
        "contract",
        "state-authority",
        "latency",
        "trade-off"
      ],
      "caption": "Compare page navigation, HTML fragments, and browser-built views for the same operation.",
      "controls": [
        "Document, HTML fragment, or JSON update",
        "Unsaved note",
        "Explicit draft restoration",
        "Reveal modeled update"
      ],
      "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.",
      "id": "demo-web-architecture-lens",
      "kind": "demo",
      "title": "Web architecture lens",
      "url": "https://scalableweb.dev/demos/#demo-web-architecture-lens",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-web-architecture-lens.png",
        "alt": "Web architecture lens: static preview of the default demo view. Compare page navigation, HTML fragments, and browser-built views for the same operation."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "latency",
        "tail-latency",
        "benchmark",
        "measurement-boundary"
      ],
      "caption": "Compare average latency and p95 when a minority of requests take a slow path.",
      "controls": [
        "Slow-path fraction",
        "Average and p95 objective",
        "Prediction and simulation"
      ],
      "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.",
      "id": "demo-tail-latency-simulator",
      "kind": "demo",
      "title": "Tail latency simulator",
      "url": "https://scalableweb.dev/demos/#demo-tail-latency-simulator",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-tail-latency-simulator.png",
        "alt": "Tail latency simulator: static preview of the default demo view. Compare average latency and p95 when a minority of requests take a slow path."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "conceptIds": [
        "benchmark",
        "latency",
        "measurement-boundary",
        "rendering"
      ],
      "caption": "Measure total time and instrumented JavaScript slices while yielding or blocking the main thread.",
      "controls": [
        "Rendered event count",
        "One task or yielded batches",
        "Repeated measurements"
      ],
      "assumptions": "Measurements are browser- and workload-specific. Frame callbacks are a scheduling proxy; slices exclude later layout and rendering.",
      "id": "demo-browser-performance-workbench",
      "kind": "demo",
      "title": "Browser performance workbench",
      "url": "https://scalableweb.dev/demos/#demo-browser-performance-workbench",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-browser-performance-workbench.png",
        "alt": "Browser performance workbench: static preview of the default demo view. Measure total time and instrumented JavaScript slices while yielding or blocking the main thread."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "observability",
        "latency",
        "measurement-boundary",
        "retry"
      ],
      "caption": "Inspect spans, timing, and retries within a simulated server request trace.",
      "controls": [
        "Request A, B, or C",
        "Span selection",
        "Reveal authored interpretation"
      ],
      "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.",
      "id": "demo-opentelemetry-trace-explorer",
      "kind": "demo",
      "title": "OpenTelemetry trace explorer",
      "url": "https://scalableweb.dev/demos/#demo-opentelemetry-trace-explorer",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-opentelemetry-trace-explorer.png",
        "alt": "OpenTelemetry trace explorer: static preview of the default demo view. Inspect spans, timing, and retries within a simulated server request trace."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "conceptIds": [
        "agent-fleet",
        "authority",
        "observability",
        "benchmark",
        "state-authority"
      ],
      "caption": "Reconcile orchestration intent, gateway decisions, and the physical execution ledger.",
      "controls": [
        "Trace inspection",
        "Run attribution",
        "Physical ledger accounting"
      ],
      "assumptions": "Count each physical row once, including failed, cancelled, and unmatched work. Missing linking evidence must remain unmatched.",
      "id": "demo-fleet-trace-debugger",
      "kind": "demo",
      "title": "Fleet trace debugger",
      "url": "https://scalableweb.dev/demos/#demo-fleet-trace-debugger",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-fleet-trace-debugger.png",
        "alt": "Fleet trace debugger: static preview of the default demo view. Reconcile orchestration intent, gateway decisions, and the physical execution ledger."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "lusser-law",
        "reliability",
        "contract",
        "measurement-boundary"
      ],
      "caption": "Calculate a required-stage chain's reliability under explicit independence and repair assumptions.",
      "controls": [
        "Initial correctness",
        "Error detection",
        "Repair success",
        "Critical step count"
      ],
      "assumptions": "Identical independent required steps; the first terminal outcome decides the run. Correlated failures or optional stages require a different model.",
      "id": "demo-reliability-chain-lab",
      "kind": "demo",
      "title": "Reliability chain lab",
      "url": "https://scalableweb.dev/demos/#demo-reliability-chain-lab",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-reliability-chain-lab.png",
        "alt": "Reliability chain lab: static preview of the default demo view. Calculate a required-stage chain's reliability under explicit independence and repair assumptions."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "conceptIds": [
        "amdahl-law",
        "agent-fleet",
        "review-budget",
        "throughput"
      ],
      "caption": "Inspect the ideal speedup bound when part of a fixed workload stays sequential.",
      "controls": [
        "Parallelizable fraction",
        "Agent count"
      ],
      "assumptions": "Amdahl's ideal fixed-workload model excludes new coordination, contention, conflicts, retries, and review queues.",
      "id": "demo-sequential-work-bound",
      "kind": "demo",
      "title": "Sequential work bound",
      "url": "https://scalableweb.dev/demos/#demo-sequential-work-bound",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-sequential-work-bound.png",
        "alt": "Sequential work bound: static preview of the default demo view. Inspect the ideal speedup bound when part of a fixed workload stays sequential."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 3,
      "conceptIds": [
        "saturation",
        "throughput",
        "queue",
        "backpressure",
        "pressure"
      ],
      "caption": "Compare offered, admitted and completed event rates and move the binding limit.",
      "controls": [
        "Offered load",
        "Stage capacities",
        "Limit admission to bottleneck rate"
      ],
      "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.",
      "id": "demo-saturation-boundary-lab",
      "kind": "demo",
      "title": "Saturation boundary lab",
      "url": "https://scalableweb.dev/demos/#demo-saturation-boundary-lab",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-saturation-boundary-lab.png",
        "alt": "Saturation boundary lab: static preview of the default demo view. Compare offered, admitted and completed event rates and move the binding limit."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "contention",
        "throughput",
        "saturation",
        "amdahl-law"
      ],
      "caption": "Explore a modeled capacity curve as contention and coherency costs change.",
      "controls": [
        "Contention coefficient",
        "Coherency coefficient",
        "Worker concurrency"
      ],
      "assumptions": "A parameterized Universal Scalability Law model. Coefficients require workload-specific evidence before predicting real capacity.",
      "id": "demo-contention-curve-lab",
      "kind": "demo",
      "title": "Contention curve lab",
      "url": "https://scalableweb.dev/demos/#demo-contention-curve-lab",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-contention-curve-lab.png",
        "alt": "Contention curve lab: static preview of the default demo view. Explore a modeled capacity curve as contention and coherency costs change."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "feedback-loop",
        "recovery",
        "state-authority",
        "pressure",
        "contract"
      ],
      "caption": "Follow controller actions that reconcile observed replicas with desired state.",
      "controls": [
        "Desired replicas",
        "Controller and failure actions",
        "Send simulated request",
        "Roll back to v1"
      ],
      "assumptions": "A simplified control loop; restoring replica count does not establish application correctness or recovery of durable effects.",
      "id": "demo-orchestration-control-loop",
      "kind": "demo",
      "title": "Orchestration control loop",
      "url": "https://scalableweb.dev/demos/#demo-orchestration-control-loop",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-orchestration-control-loop.png",
        "alt": "Orchestration control loop: static preview of the default demo view. Follow controller actions that reconcile observed replicas with desired state."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 2,
      "conceptIds": [
        "durable-workflow",
        "retry",
        "idempotency",
        "state-authority",
        "recovery"
      ],
      "caption": "Stop a worker after an external effect but before its completion enters durable history.",
      "controls": [
        "Retry policy",
        "Reused business key or fresh attempt key",
        "Receiver deduplication",
        "Prediction and failure window"
      ],
      "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.",
      "id": "demo-durable-effect-retry-lab",
      "kind": "demo",
      "title": "Durable effect retry lab",
      "url": "https://scalableweb.dev/demos/#demo-durable-effect-retry-lab",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-durable-effect-retry-lab.png",
        "alt": "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."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "conceptIds": [
        "partition",
        "consistency",
        "invariant",
        "state-authority",
        "recovery"
      ],
      "caption": "Compare conflicting writes across a network split under quorum and local-acceptance policies.",
      "controls": [
        "Quorum or accept-in-every-region policy",
        "Partition, writes, and repair actions"
      ],
      "assumptions": "An operation-specific consistency scenario. Repair cannot retract a success response already observed by a client.",
      "id": "demo-cap-partition-lab",
      "kind": "demo",
      "title": "CAP partition lab",
      "url": "https://scalableweb.dev/demos/#demo-cap-partition-lab",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-cap-partition-lab.png",
        "alt": "CAP partition lab: static preview of the default demo view. Compare conflicting writes across a network split under quorum and local-acceptance policies."
      },
      "experiment": {
        "predict": "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."
      }
    },
    {
      "activityVersion": 3,
      "conceptIds": [
        "latency",
        "measurement-boundary",
        "consistency",
        "trade-off",
        "cache"
      ],
      "caption": "Estimate latency contributions from geography, round trips, and execution time.",
      "controls": [
        "User–application and application–database distances",
        "Network multiplier",
        "Sequential query count",
        "Query and application work"
      ],
      "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.",
      "id": "demo-latency-budget-map",
      "kind": "demo",
      "title": "Latency budget map",
      "url": "https://scalableweb.dev/demos/#demo-latency-budget-map",
      "images": {
        "png": "https://scalableweb.dev/concepts/visuals/demo-latency-budget-map.png",
        "alt": "Latency budget map: static preview of the default demo view. Estimate latency contributions from geography, round trips, and execution time."
      },
      "experiment": {
        "predict": "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."
      }
    }
  ]
}