A system can return a plausible answer while violating the property that matters: what it knew at the time, whose data it retrieved, whether an effect happened once, or whether its evaluator notices failures.
This collection follows those boundaries. The seven companion articles below were published on September 17, 2026 and placed fortnightly from May 31 through August 23 in the archive. This guide occupies September 6. The dates are a disclosed retrospective reading sequence, not a record of earlier publication.
Choose the path that matches a current decision. Each ends with a concrete check you can add to a review or a test environment.
Path 1: Can you reproduce the data and the effect?
Start with Your Historical Data Knows the Future (May 31). It separates a fact’s effective date from the date it became available. A two-revision SQL fixture shows why a January 20 correction cannot appear in a January 10 decision.
Then read Kafka Exactly-Once Stops at the Database Boundary (June 14). Follow the crash between a database commit and a Kafka offset commit. An inbox transaction demonstrates where duplicate detection must live to protect a local effect.
The existing market-data analytics article now links temporal correctness to its storage discussion. The Kafka transactions chapter corrects the distinction between code executing and effects committing.
Check to take away: replay a late correction, then restart a handler after its destination commit. Assert the actual data and effects independently of the success message.
Path 2: Is the retrieval or coordination plan the one you think it is?
Your RAG Works Until You Add a Tenant Filter (June 28) compares a global candidate budget with an exact baseline inside the eligible corpus. More relevant records can exist even when a filtered approximate scan returns none.
Kafka Rebalancing Changed. Did Your Consumer Configuration? (July 12) separates classic cooperative assignment from the newer consumer protocol. It maps the settings that moved from client to server, using versioned Kafka 4.0 documentation.
Continue into retrieval fundamentals or consumer groups once the shorter diagnostic matches your situation.
Check to take away: inspect the executed retrieval plan or the group’s actual protocol. Configuration intent is not evidence of runtime behavior.
Path 3: Do cost controls and permission checks protect the right boundary?
Your Cache Hit Rate Is Not Your Token Savings (July 26) turns ten requests into a bill with separate read, write and uncached token categories. An 80% request hit rate becomes 64% cached input tokens in the example.
Your MCP Server Is an Authorization Boundary (August 9) separates token audience, user identity, client consent and object ownership. Its negative test matrix requires denied requests to produce no downstream action.
The revised Cost of Context removes unsupported latency claims and uses explicit cost assumptions. The security chapter replaces the misleading sanitizer and path-check guidance with a clearer containment boundary.
Check to take away: reconstruct one request’s token bill, then trace one tool call’s authority all the way to the target object.
Path 4: Would the evaluator catch any of this?
95% Agreement, Zero Failures Caught (August 23) is the final diagnostic. It defines failure as the positive class, reports the confusion matrix and separates a transcript’s success claim from the state left behind.
The Harness Engineering pitfalls chapter now qualifies judge-bias evidence and removes a universal sample-size prescription. The evaluation chapters link to the executable lab rather than repeating another broad introduction.
Check to take away: report actual failing-example counts and failure recall. A green agreement percentage is not enough.
Run the small examples, then replace their assumptions
Download counterexamples.py and run it with Python 3. It uses only the standard library. The assertions cover filtered candidate truncation, late revisions, misleading judge agreement, duplicate-safe local effects and cache-cost arithmetic.
These are synthetic teaching fixtures. They do not certify an ANN index, Kafka deployment, OAuth integration or production LLM judge. Their purpose is to make each failure small enough to see. The next useful step is to reproduce the same boundary with your own data, versioned dependencies and failure conditions.