
Writing
Verified, Not Trusted: Expense Analysis, Part Four
Evals measure reliability with reference keys, code graders, model judges and pass-rate gates. Expense examples show what to check and how structured output expands coverage.

Topic
Material specific to Python, or illustrated with Python examples.
12 pages

Writing
Evals measure reliability with reference keys, code graders, model judges and pass-rate gates. Expense examples show what to check and how structured output expands coverage.

Writing
Evals are acceptance tests for prompts and skills: repeated isolated runs, a pass rate for each check, and a minimum pass rate as the gate. Code grades extracted facts and traces failures.

Writing
Imperative Python controls expense analysis and verifies model contributions through source evidence, reconciliation, and exact calculations. Models handle bounded judgments.

Writing
Make long-running pipelines explain their work through numbered steps, ordered artifacts and a run manifest. Preserve evidence to investigate exceptions and incorrect results.

Writing
Expense totals need verifiable source coverage and reproducible calculations. Two prompts show how parsing, category rules, refunds, and code shape the evidence.

Writing
Jev can shorten LLM context by scoring which tool events a current question still needs. A recorded Noul response and Python retention code show what stays and why the threshold matters.

Writing
A model should express required fields, genuine absence, and distinct variants in its type. Python unions and C# records encode those promises, while boundaries check external values.

Chapter
Structure communicates intent: strict layers from Domain Facade to Gateway, a public surface declared in the boundary __init__.py, and folder depth that marks each class's level of abstraction.

Chapter
Two kinds of class and why that separation holds, no inheritance for extension, and naming conventions for polymorphic types.

Chapter
Python methods make work and contracts clear: pass operation data explicitly, orchestrate at one abstraction level, and let ordinary actions return `None` while queries return data or raise.

Chapter
Naming a thing for what it is: variables named after their type, methods that state the domain outcome, and why inventing a fresh name at each site is where wrong names come from.

Chapter
Annotations as intent rather than decoration: None used deliberately, dictionaries kept out of method boundaries, and capability types that tell the truth.