Unit 12.00: Scoping the assistant and its sources

The capstone begins with a written scope, and every technical decision afterwards follows from it.

Users, sources, refusals, budget

Who asks, what the answers come from, what is never answered, how fast, and what success means observably.

The code prints a scope and runs four checks against it.

import json

scope = {
    "users": "support agents, during a live conversation",
    "answers_from": ["published support policies", "product FAQ"],
    "never_answers": ["individual account details", "legal advice",
                      "anything not in the retrieved documents"],
    "latency_budget_ms": 800,
    "refusal_string": "The available documents do not cover that.",
    "success": "the agent resolves the query without opening the policy document",
    "sources": [{"name": "support-policies-v4.md", "updated": "2026-06-14",
                 "staleness_budget_days": 120}],
}
print(json.dumps(scope, indent=2))

checks = [
    ("refusal string is fixed", scope["refusal_string"].endswith(".")),
    ("out of scope is non-empty", len(scope["never_answers"]) > 0),
    ("every source has a staleness budget",
     all("staleness_budget_days" in s for s in scope["sources"])),
    ("success is observable", "resolves" in scope["success"]),
]
for check, ok in checks:
    print(f"  {'OK  ' if ok else 'FAIL'} {check}")

latency_budget_ms: 800 follows directly from "during a live conversation". An assistant consulted between calls could take five seconds; one used mid-conversation cannot, and that single phrase constrains k, reranking and model choice for the rest of the build.

Every source carries a staleness budget. That is the field Module 4 needed and the one that has to be decided by someone who knows how often the document actually changes.

The mistake this prevents

The mistake is writing the scope after the prototype. Written afterwards it describes what you built, every constraint is one the system already satisfies, and it rules nothing out - which is the only thing a scope is for.

Takeaway

Write the scope first with users, sources, refusals, a latency budget and an observable success criterion. The latency budget in particular constrains everything downstream.

Mark complete