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
Verification
Establishing that required work actually happened, rather than accepting a confident report that it did. Coverage, completion, and what evidence supports a claim.
14 pages
Writing
Verified, Not Trusted: Expense Analysis, Part Three
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
Verified, Not Trusted: Expense Analysis, Part Two
Imperative Python controls expense analysis and verifies model contributions through source evidence, reconciliation, and exact calculations. Models handle bounded judgments.
Writing
Verified, Not Trusted: Expense Analysis, Part One
Expense totals need verifiable source coverage and reproducible calculations. Two prompts show how parsing, category rules, refunds, and code shape the evidence.
Writing
Stampede at the Gates
AI generation exposed an already flawed SDLC: faster code review moves the queue to verification, which needs functional acceptance testing at the boundary.
Writing
Skills versus Controlled Workflows
Stakes and human verification determine where workflow control belongs. Explicit prompts guide a model; imperative code enforces steps, checks, and use of results.
Writing
Assertions That Verify the Whole Outcome
Assertions must compare every required field, count, and effect. Pure asserters separate observations from comparisons and report available failures together with verified expectations.
Writing
From a Green Suite to a Release
A green behavioral suite supports release when its evidence belongs to the build being advanced. Preserve execution receipts and verify deployed capabilities, configuration, and other release duties.
Writing
Functional Acceptance Testing at the Boundary
Functional acceptance tests verify complete outcomes through the assembled system. Correct arrangements, deep assertions, and controlled observations support release confidence.
Writing
Knowing Which Scenarios a Feature Requires
A green suite needs correct scenarios for established requirements. An obligation map connects each rule to its arrangement, expected outcome, independent observation, and assertion.
Writing
One Order, Every Obligation
One ordering scenario verifies the caller result, stored lines, fulfillment, and confirmation. Follow its complete C# test, independent observations, and accumulated failure reports.
Writing
Questions About Functional Acceptance Testing at the Boundary
Boundary testing questions concern evidence, isolation, failures, and release confidence. Compare the practice with mocks, TDD, generated checks, formal models, and production observation.
Writing
The Regression Suite the Business Is Paying For
The maintained regression suite protects earlier business behavior as new features change the system. Keep approved expectations, run the required suite, and preserve lessons as permanent scenarios.
Writing
AI-native SDLC
Engineering both gates requires certified code review, functional acceptance tests at the boundary ratified by humans, and verification against the specification.