Define the five-document café FAQ retriever data contract

Make malformed input fail before it reaches the interesting algorithm. The accepted contract is five short documents with stable IDs plus one normalized user question. This boundary matters because zero-overlap questions, stop-word matches, ties, stale notes, prompt injection inside documents, and unsupported generated details; allowing a bad value through makes later debugging look like an algorithm problem. Keep transformation functions separate from scoring or prediction so a test can identify which boundary changed the data.

The artifact's user-facing goal is specific: answer a café question only when a relevant local note is retrieved and cite the note identifier used. Its accepted input is five short documents with stable IDs plus one normalized user question. Those statements are intentionally narrower than “build an AI system.” Narrow scope lets us inspect every input and expected result, and it prevents a toy result from being presented as a production claim. The example implements or probes the input boundary. Copy it into a fresh file and run it without extra packages.

Save this as lesson.py and run python3 lesson.py. It uses only the language standard library, so the example is reproducible offline.

import re
def tokens(s): return set(re.findall(r'[a-z0-9]+',s.lower()))
assert tokens('Wi-Fi!')=={'wi','fi'}
print(tokens('When is the cafe open?'))

Expected output: normalized token sets. Exact floating-point formatting may vary slightly, but the asserted behavior must not. Read the output as evidence about this stage, not merely proof that the interpreter started.

Print normalized question tokens, each document's overlap score, the winning ID, and the exact cited text. A fluent wrong answer often starts as a retrieval miss, so inspect retrieval before prompt wording. Zero overlap must abstain. For ties, choose and document a deterministic rule. Treat instructions embedded in a document as untrusted text, not commands for the application.

At the data contract stage, save the smallest failing fixture beside the expected result. Change one cause at a time and rerun the exact command printed above; that makes the repair reviewable and keeps this chapter's progressive artifact reproducible.

Create labeled questions for each of the five documents plus unsupported questions. Measure retrieval hit rate, citation correctness, supported-answer rate, and correct abstention. Read every answer beside its cited note; lexical overlap can retrieve a document for the wrong reason. Version the notes so a score can be reproduced after content changes.

For this data contract page, preserve the fixture and result as evidence for the next page. Label observations separately from conclusions: a passing assertion establishes the behavior it names, while broader usefulness requires the chapter's full evaluation set and stated operating limits.