AI Can Write the Tests. Who Checks the Answer Key?

Compile-Time Intelligence, Part 3

Much of the knowledge that guides consequential decisions is written in natural language. Clinical guidelines describe which patients need attention. Insurance policies define eligibility and exclusions. Legal agreements specify obligations that apply under particular circumstances.

One promising use of AI is to help turn that written knowledge into executable rules. The potential is software that applies requirements consistently, makes individual decisions easier to inspect, and can be updated when the underlying guidance changes. In healthcare, that could help bring more clinical knowledge into everyday decision-making. Across other industries, it could make complex policies easier to apply and review.

But consistency cuts both ways. A missing exception or misinterpreted threshold can become a repeatable mistake. The software may run perfectly while making decisions that contradict the source it was supposed to implement.

Testing seems like the obvious safeguard. Give the generated rule a collection of scenarios, compare its answers with the expected results, and investigate anything that fails.

But an AI model can make the same mistake twice: once when it writes the rule, and again when it writes the expected answers used to test it. The tests pass because the incorrect rule agrees with the incorrect expectations.

This is the challenge running through Eventum’s Compile-Time Intelligence series. Part 1 explored why formally checking a result does not automatically establish that it captures the original human intent. Part 2, The Rule Passed Its Tests. What Did the Tests Establish?, examined how carefully chosen cases can expose mistakes that simpler tests miss. [1] [2]

Part 3 asks the other half of that question: who or what determines the expected answers, and why should we trust them?

The opportunity is to make those expectations explicit and reusable. Expert-reviewed examples, checkable requirements, and relationships between cases can each contribute. AI can help construct some of this evidence, but generating an answer key and establishing its authority are different tasks.

What the answer key actually contains

Consider a fictional clinical cohort definition. A patient belongs to the cohort, the group being selected, if a qualifying diagnosis, medication, or laboratory result is present. Any one is sufficient, unless a specified exclusion applies. For now, assume those four facts have already been resolved as present or absent.

A rule is the executable logic that produces an inclusion decision. A case supplies a particular combination of patient facts. A test runs the rule on that case and checks its result against an expectation.

But who or what determines the expected result?

That is the role of the test oracle: the criterion or mechanism used to judge whether the program’s behavior is acceptable. For an exact-answer test, it supplies the expected output. Other oracles check conditions that acceptable outputs must satisfy. An oracle is a role in testing, not an infallible source of truth. [3]

Two straightforward approaches are to obtain expected answers from a human expert or calculate them using a reference program.

The first approach is expert-reviewed cases. A clinician examines a hypothetical patient with a qualifying diagnosis but no medication, qualifying laboratory result, or exclusion. The source says diagnosis alone is sufficient, so the clinician records “include,” along with the justification.

Repeat that process for 100 cases, and the testing software can compare the generated rule’s results with 100 reviewed answers.

The limitation is the scope of that answer key. Each additional case needs a justified expectation before it can support an exact-answer test. That creates more work as the collection grows.

A second approach is a trusted reference implementation: a separate program used to calculate the expected answers. Instead of storing a result for each patient, it applies a reference version of the intended logic. This can support comparisons on new inputs within its domain, but the reference program’s own correctness needs support. [3]

Neither approach escapes the need to justify the answer key. A human can misread the source, and a reference program can encode a mistaken interpretation.

Our diagnosis-only patient makes the risk concrete. Suppose the generated rule incorrectly requires diagnosis plus medication or laboratory evidence. It excludes this patient. If the model that writes the tests adopts the same interpretation, it may also record “exclude” as the expected answer.

The test passes, even though the source says the patient qualifies.

Copying outputs directly from the candidate rule is more obviously circular: it records what the program does without establishing what the source requires. That record could reveal later changes in behavior, but it cannot independently establish that the original behavior was correct.

The challenge is therefore twofold: justify the expectations, and find practical ways to extend them beyond a small collection of individually reviewed cases.

A useful oracle does not need every answer

Expert review can establish answers for selected cases. A complete reference implementation could calculate many more, but building and validating it may involve much of the same interpretation work as building the software being tested.

There is another option: check individual requirements that apply across many cases without calculating the complete correct answer for each. This is one form of a partial oracle. [3]

For our cohort, one requirement is straightforward:

When the exclusion is present, the patient must not be included.

Diagnosis, medication, and laboratory evidence can vary; the exclusion still overrides them. An engineer could encode that requirement as an assertion, a condition checked during a test:

if excluded:
    assert actual_result == "exclude"

This assertion fails if the rule includes an excluded patient. It does not determine the correct answer for patients without the exclusion.

A broken program that excludes everyone would satisfy it. The check is justified, but insufficient to establish the whole rule’s correctness. An additional expectation, such as including a diagnosis-only patient with no exclusion, would detect a different mistake.

An oracle can be correct about what it checks while leaving important behavior unchecked.

The benefit is that one reviewed requirement can support many automated comparisons. That raises the next question: can AI help turn written requirements into the oracle’s checking conditions?

Can AI help write the oracle’s checks?

A specification states what software is required to do. A postcondition describes something that must hold about the result or state after successful execution, under the stated input conditions. A checkable postcondition can serve as part of an oracle. [4]

The exclusion assertion is a simple example. It constrains the answer without reproducing the entire eligibility algorithm.

The nl2postcond study investigated translating natural-language descriptions into postconditions (Madeline Endres, Sarah Fakhoury, Saikat Chakraborty, and Shuvendu Lahiri). Its evaluation examined whether generated checks accepted reference behavior and rejected faulty behavior.

Both matter. A condition written simply as True always reports success; passing on correct examples would tell us nothing about its usefulness.

In the historical-bug evaluation, a useful check had to pass the available tests on a repaired implementation and fail at least one on its buggy counterpart. Across the evaluated models and prompts, generated checks detected 64 distinct bugs in a 525-bug, Java-8-compatible subset of Defects4J, a collection of buggy and repaired Java programs. [4]

This gives models a constructive role beyond generating programs and inputs: they can propose executable checks for the oracle. Those checks still need evaluation. A model-generated condition belongs to the checking mechanism, but that does not automatically make it a correct or sufficiently demanding judge.

Extend the oracle’s checks to related cases

So far, our oracle has judged individual outputs. But another way to extend its reach is to establish how outputs should relate when a case changes.

We may not know the complete correct answer for every new input. We may nevertheless know that a particular change should leave the answer unchanged, or change it in a specified way. That relationship gives the oracle something meaningful to check on cases that do not have individually reviewed answers.

Metamorphic testing uses relationships between an original case and a deliberately changed case (T. Y. Chen, S. C. Cheung, and S. M. Yiu). It can extend testing without requiring a separately calculated expected answer for every new input. [5]

The process has two parts. First, establish a relationship justified by the requirements: what can change in the input, and what should happen to the output as a result. Then run the same program on the original and changed cases, and check whether its outputs obey that relationship. The relationship becomes part of the oracle. [3] [5]

For our fictional cohort, the source supports this relationship:

With the exclusion absent, removing one qualifying signal must not change an included patient’s result when another qualifying signal remains.

Start with a patient who has all three signals and no exclusion. The restrictive rule includes them.

Now remove the diagnosis while keeping medication and qualifying laboratory evidence. The source says either remaining signal is sufficient, so the patient should remain included. The restrictive rule instead excludes them.

The oracle can detect the problem by comparing the two results: the permitted change should have preserved inclusion, but did not.

That same relationship can be applied to other pairs of cases that meet its conditions. Rather than asking a reviewer to label every variation individually, the testing process reuses a justified piece of knowledge about how the rule should behave.

The assumptions remain essential. The exclusion must stay absent, the meanings of the inputs must stay unchanged, and another qualifying signal must remain. Removing evidence outside those conditions might legitimately change the decision.

Nor does satisfying a relationship establish that either output is correct in every respect. A program that incorrectly excludes both patients could satisfy a simple “these results should match” check. It would need another check to expose that error.

Metamorphic testing extends what an oracle can check; it does not give the oracle a complete answer key. Its value is that relationships supported by the requirements can turn additional cases into informative tests.

Use different implementations to strengthen the answer key

Relationships between cases still leave gaps. When the existing oracle cannot settle a case, comparing different programs can help identify what needs to be resolved.

An implementation is a concrete program intended to perform a task. Differential testing runs different implementations on the same inputs and compares their behavior. Whereas metamorphic testing compares one program’s results across related cases, differential testing compares different programs’ results for the same case. [3] [6]

Where do those implementations come from? In a policy-to-code workflow, they could be an existing program and a newly generated replacement, versions written separately by engineers, or candidate translations produced by different models or separate generation attempts. For the comparison to be meaningful, they must be intended to implement the same requirements on inputs with the same meaning.

A reference implementation is not a different testing technique. It is one of those programs serving a particular role: the comparison standard whose answers have a justified basis for being treated as expected results.

When such a reference exists, differential testing can use it to supply the oracle’s answers. EvalPlus, discussed in Part 2, compared generated programs with reference implementations. Its researchers also wrote their own versions and compared them with the original benchmark references, discovering errors in those references. The comparison standard itself was worth examining. [6]

When none of the implementations is trusted, the comparison serves a different purpose. It finds disagreements that need investigation; it does not determine which answer should enter the oracle.

Suppose one candidate implements our restrictive rule and another accepts any qualifying signal. They disagree about the diagnosis-only patient. A reviewer can return to the source, establish that the patient should be included, and record that answer with its justification. The disputed case has now become a test with a supported expectation.

Another disagreement might be harder to settle. Does a medication prescribed for a different condition count as qualifying evidence? That concerns the meaning of the medication input, not merely how the Boolean conditions are combined. A more detailed source or a documented clinical interpretation may be needed.

This is the connection to the article’s central question: comparing candidates can help build the oracle by identifying concrete cases whose expected answers need to be established.

Agreement alone is not enough. Separate programs, including separate outputs from the same model, can share a mistake. Their answers do not become authoritative through repetition. The useful sequence is to find a disagreement, investigate it, and preserve the justified expectation for future tests.

Make the expectations explicit before generating tests

The approaches above produce different pieces of an answer key: reviewed case labels, general checking conditions, relationships between executions, and decisions that still need clarification.

For those pieces to guide future tests, they need an explicit account of the intended behavior. Otherwise, each test writer must reconstruct the same expectations and may interpret them differently.

A behavioral contract provides such an account: which inputs the software accepts, what results it must produce, and where behavior is not specified. Its checkable requirements can supply oracle criteria.

Research on contract-first test generation examines whether making that account explicit helps models write better tests (Michele Tufano and colleagues).

In a study of 90 historical Google bugs, two test-generation agents received already-fixed code. One generated tests directly; the other first documented a behavioral contract. The reported five-attempt bug-detection rate increased from 53.4% to 63.2%. A detection required at least one generated suite that passed on the fixed implementation but failed on the corresponding buggy version. [7]

The result supports making expectations explicit in that setting. For a policy-to-code system, a further question remains: does the contract capture the source? Extracting a contract from the candidate code alone could preserve the same omission the tests are meant to detect.

A source-linked record makes that additional question inspectable. For our fictional example, it could look like this:

The expected-result field can become an automated test. The surrounding fields explain why that answer belongs in the oracle.

A similar record could preserve a metamorphic relationship: what input change is permitted, which conditions must remain fixed, how the outputs should relate, and which source requirement justifies that relationship. A resolved disagreement between implementations could contribute a new reviewed case.

The same structure can make gaps visible. Suppose the source does not specify how to handle missing exclusion information. Silently treating it as “no exclusion” would insert a decision that the source has not supplied.

There is a crucial difference between a requirement that tells the program to return “unknown” and a reviewer who does not know what the program should return. The first supplies a testable expectation. The second leaves the oracle incomplete.

From an answer key to evidence someone can examine

Compiled Health publicly describes an approach that turns medical standards into deterministic, traceable decision logic. [8] For systems pursuing that kind of compilation, the oracle problem explains why generating executable rules is only part of the work.

The research suggests a complementary use for models: helping express expectations as executable checks and organizing test generation around explicit contracts. Relationships between cases can extend those checks, while comparisons between implementations can identify questions that require better-grounded answers.

Applied to clinical or policy logic, these capabilities could make expert judgments more reusable while keeping their assumptions open to examination.

Part 2 asked:

Which plausible mistakes would these tests catch?

Part 3 adds:

What justifies the expected answers, and what remains outside their scope?

Together, these questions make a passing suite more informative. A reviewer can examine not only whether the software passed, but which expectations were checked, where those expectations came from, and what remains unresolved.

That is the larger opportunity: turning written knowledge into reusable decisions without losing the evidence that makes those decisions defensible.

Part 4 asks what must survive compilation so that the rule, its interpretation, its tests, and its review decisions remain connected as the system changes.

Building a system that turns policies, contracts, or clinical guidance into executable logic? Talk to Eventum about the translation, evaluation, and review process around it.

Sources

1. Bressler D. AI Is Discovering New Mathematics. The Hard Part Is Knowing Exactly What It Proved. Eventum AI, October 13, 2026. Compile-Time Intelligence, Part 1.
2. Bressler D. The Rule Passed Its Tests. What Did the Tests Establish? Eventum AI, October 19, 2026. Compile-Time Intelligence, Part 2.
3. Barr ET, Harman M, McMinn P, Shahbaz M, Yoo S. The Oracle Problem in Software Testing: A Survey. IEEE Transactions on Software Engineering 41(5), 507-525 (2015). DOI: 10.1109/TSE.2014.2372785. Examines specified, derived, partial, and human oracles, including relationships between executions and comparisons between implementations.
4. Endres M, Fakhoury S, Chakraborty S, Lahiri SK. Can Large Language Models Transform Natural Language Intent into Formal Method Postconditions? FSE 2024; arXiv:2310.01831, version 2. Evaluates generated postconditions for correctness and discrimination. The 64-bug result combines findings across the evaluated models and prompt variants.
5. Chen TY, Cheung SC, Yiu SM. Metamorphic Testing: A New Approach for Generating Next Test Cases. Technical Report HKUST-CS98-01, Hong Kong University of Science and Technology, 1998; posted on arXiv in 2020.
6. Liu J, Xia CS, Wang Y, Zhang L. Is Your Code Generated by ChatGPT Really Correct? Rigorous Evaluation of Large Language Models for Code Generation. NeurIPS 2023; arXiv:2305.01210, version 3. Describes differential evaluation and defects discovered by comparing reimplementations with the original HumanEval references.
7. Tufano M, McClure J, Cambronero J, Cheng R, Shi SY, Wei R, Chen D, Ivančić F, Dalloro L, Rondon P. Grounding AI Agents in Contracts: An Empirical Evaluation of Spec-Driven Test Generation. SpecOps 2026; arXiv:2608.17177, version 2. DOI: 10.1145/3842652.3843195. Section 4.3 describes the fixed-code setup; Table 2 reports the detection comparison.
8. Compiled Health. The Standard of Care Applied Deterministically. Company website, accessed October 19, 2026. Public description of its clinical knowledge-compilation approach.