OPTIONAL IMPLEMENTATION STUDIO · APPLICATIONS

Implement an evidence assistant.

Connect retrieval, source checks and local tools, then test the complete workflow instead of trusting individual components.

The guided assistant project works entirely in the browser. This studio adds Python implementation practice. It requires basic functions, lists and dictionaries; revisit the data-loading studio if those are unfamiliar. Optional implementation work does not inflate required completion percentages.

Predict a failure before writing code

With only one retrieved document, the assistant may miss a conflicting notice. An exact lookup can recover a lexical miss, but cannot erase the retrieval diagnostic. Predict how these two failures differ, then inspect the shared browser trace.

Download the small local starter

Python assistant starter — standard library only; no package installation, network access or model download.
Versioned fictional corpus and nine public cases — 8,249 bytes.
Corpus manifest with SHA-256 and provenance.
Permission to reuse the authored fictional data.

Save the starter and corpus.json in one folder. The script checks the exact corpus hash. All records are fictional; structured fact labels are supplied teaching metadata, not automatic language understanding. The licence covers these fixture data only.

Run the supplied baseline

python3 evidence-assistant.py --corpus corpus.json --reference --output extractive.json
python3 evidence-assistant.py --corpus corpus.json --reference --tools --output with-tools.json

On Windows, replace python3 with py -3. Run from the folder containing both downloads. Outputs must use new filenames; the script refuses to overwrite a file. No account or API key is used.

--reference explicitly uses supplied functions. At k=2, the extractive baseline completes 3/9 factual tasks and appropriately handles 7/9 cases. Tools raise these to 5/9 and 9/9. Four cases require unresolved handling; they do not become completed answers. Inspect each JSON trace and citation before explaining the totals.

Read hash-checked fixture
Rank and select source IDs
Check extracted fact labels
Call scoped lookup/arithmetic
Check receipt → assemble answer
Evaluate against separate expectations

Implement two boundaries

Function	Your task	Counterexample
`learner_rank`	Count distinct lowercase query words that appear in each document; sort by score then alphabetical ID.	Repeated query words must not multiply overlap; an unknown query produces deterministic zero-score ties.
`learner_accept_receipt`	Check exact fields, request identity, fact key, successful status and a bounded string value.	A schema-shaped result from a different request must not be accepted.

The starter includes supplied versions for comparison, so copying them is guided execution, not independent implementation evidence. Try your own implementation first and explain its tests.

python3 evidence-assistant.py --check
python3 evidence-assistant.py --corpus corpus.json --tools --output learner-run.json

The public checks intentionally fail until both TODO functions are implemented. Without --reference, the workflow uses your functions. The output identifies which implementation ran. Passing these public checks is practice; human code review and unfamiliar test cases are still needed.

Compare failures without changing the oracle

python3 evidence-assistant.py --corpus corpus.json --reference --tools --top-k 1 --output narrow.json
python3 evidence-assistant.py --corpus corpus.json --reference --tools --susceptible --no-runtime-check --output ablation.json

Inspect the conflict and injection rows. Gate ablations leave the external correctness expectations unchanged. Document proposals use a literal PROPOSE/JSON grammar, never eval. Unauthorized actions are fictional counter increments; no export, booking or external side effect happens.

Tools make at most one call per unresolved fact. The notebook tool multiplies a retrieved consistent price by the supplied quantity: 4 × 3 = 12 credits. A receipt must match the current request and key. Timeouts and wrong receipts remain failures rather than silently becoming answers.

Assumed latency uses scored × 1 + read × 4 + calls × 12 ms, excluding stated runtime/evaluation overhead. Measured CPU time includes the separate evaluator but excludes file I/O. Neither is real service latency.

Build a reviewable implementation artifact

Keep your edited starter, manifest, untouched corpus, run JSON, added tests and a brief comparison. Reports include corpus/code hashes and Python version; hashes identify bytes, not authorship or authenticated execution. Cases are public development evidence throughout.

Add tests beyond the supplied examples: irrelevant but well-formed evidence, malformed receipts, unsupported answers, a new instruction-bearing document, empty retrieval and a wrong target. Create these as separate in-memory test fixtures calling the bounded runner; do not edit the hash-locked public corpus or reuse its oracle for an unfamiliar case without declaring new expected outcomes.

For independent review, explain why your new expected outcomes are correct before running the implementation. Report failures as well as successes. The guided artifact remains a small programmed assistant, not a general-purpose language agent or deployed service.

Attach evidence to the saved assistant project

Keep complete files locally. The project’s 12,000-character code field can hold your edited functions, added tests and run instructions; record filenames and hashes in the report. The project stores this text inertly and reports as learner-authored evidence. Human implementation review and representative learner pilots remain pending. Continue with the local model operations studio for real HTTP packaging, feedback and rollback.