The independent oracle

Establish the answer separately

An oracle is an independently established source expectation used to judge downstream actuals. It is not an agent's opinion, a screenshot or the output being tested. The useful question is where the expected answer came from and why its definition matches the business question. Without that explanation, a comparison can be precise yet test the wrong thing.

Return to the Sales grain problem. If a measure repeats an order-header amount across order lines, a second query copied from that implementation can repeat the same error. Two matching outputs would then share a defect. Independence means separating the expectation's authorship and capture from the implementation under test, and reviewing the business interpretation before freezing the required scenarios.

Describe the intended check

Start a synthetic worksheet with a plain-language question. State what a fact row represents, which population the question covers, which grouping or filter context applies, and which observations the eventual claim will include. This is a review exercise, so do not invent source query text or a command that the approved lab does not provide. Use the supplied manifest and current package guidance for executable work.

A scenario catalogue names the checks that define the qualification scope. A single grand total does not describe complete grouped-key coverage or all filter states. Qualification can compare scalar results and grouped actuals, but the claim remains bounded by its declared requirements. If a group is missing or an empty state behaves differently, retaining only the overall total may hide the defect from the reader.

Freeze before acceptance

Reviewed expectations are frozen so that the implementation cannot quietly redefine success after seeing a failure. The gate recomputes numeric comparisons against those expectations. Retained evidence and upstream bindings make it possible to inspect which inputs and observations supported the selected result. The order matters: agree the question, capture the expectation independently, freeze the reviewed catalogue, then observe and compare the implementation.

Suppose a downstream query disagrees. First inspect the declared check, the source definition, the actual result and the current evidence. A mismatch could reveal an implementation error, missing coverage or an incorrect assumption in the reviewed expectation. Each possibility needs an explicit investigation. Editing the answer key until the comparison passes removes the very independence the exercise was designed to preserve.

Keep precision and context visible

Exact SQL decimals, semantic projections and displayed rounding are different concerns. A report label can be rounded while the underlying comparison uses a different declared precision. A review should state which comparison was made and which display expectation was inspected. Do not infer that a readable label establishes the underlying arithmetic, or that a query match establishes every rendered label.

Review question	Evidence to identify
Who defined the expectation?	Independent authorship and business review
What did the source capture mean?	Grain, coverage, context and observation
What was frozen?	Catalogue, oracle definition and expected-value bindings
What was compared?	Selected actuals and declared required checks

Completion check

Write two descriptions of an expectation: one copied from the generated implementation, and one independently established from the agreed source question. Explain why only the second can challenge the shared assumption. Then identify one group, filter or empty state outside a grand-total check. Finish by separating the machine comparison from human grain ratification and business acceptance. Independent evidence supports those decisions; it does not impersonate the people responsible for them.