A community-solar story states a 3% credit. A tester asks an LLM for expected-result lines for three usage bands. What capability is this, and what constraint still applies?
Select an answer to reveal the explanation.
Short Explanation
Asking for expected-result lines is oracle help—handy drafts for each usage band. The 3% credit still lives in the story, so you verify every line against that basis. The model proposes; the tester confirms.
Full Explanation
Asking an LLM for expected-result lines for three usage bands on a community-solar story that states a 3% credit illustrates oracle / expected-result support—and the tester must still check every draft against the authoritative basis. Civic energy credits are regulated arithmetic affecting resident bills; fluent wrong bands remain wrong and can poison automation oracles if unchecked. The model proposes; the tester confirms.
Treating the ask as automation scripting only, with a rule that expected results must never be drafted by an LLM, denies a listed syllabus capability and over-restricts legitimate drafting help. Requirements cleanup that replaces the 3% credit with model-invented rates corrupts the basis under the guise of assistance. Result analysis of production meter logs without any link to the story addresses a different capability entirely.
Exam caveat: oracle support is allowed as drafts; authoritative numbers remain in the story and published tariff policy, not in unchecked model arithmetic.
Operational check: draft expected results per usage band; recalculate the 3% credit by hand or spreadsheet from the story; accept only matching lines into the suite; store the verification step in the solar billing municipal definition of done for GenAI-assisted oracles.