A DV engineer asks, 'Investigate last night's failures and fix the regression.' That sentence combines reading, diagnosis, expensive execution, and design changes. A beginner cannot evaluate success because neither the data scope nor the permitted effects are clear. First reduce the request to an evidence task: summarize the supplied reset_smoke failure in run R42, locate its relevant reset requirement, compare the supplied history, and hand unresolved questions to an engineer. The assistant should make that limited review easier even when it cannot identify a cause.
A useful contract names the input snapshot, allowed questions, evidence sources, forbidden effects, and completion criteria. 'Read-only' alone is insufficient: reading a protected netlist could still disclose intellectual property. Our contract allows exactly lab/runs/R42/log.txt, lab/spec/reset-v3.txt, and history for reset_smoke in fixture-v1. These strings identify in-memory teaching records; they do not grant access to similarly named real files. The requester does not gain permission to enlarge the scope by placing instructions inside a log.
Contract item | Synthetic regression assistant |
|---|---|
Question | What failed, which requirement applies, and what is still unknown? |
Tools | searchlogs, readspec, getrunhistory |
Permitted effect | Read fixed fixtures and return a console evidence packet |
Forbidden effect | Shell commands, jobs, writes, waivers, or protected data access |
Done | Evidence handed over or an explicit blocked/budget status |
The supplied R42 log reports reset_smoke failing at cycle 12, with observed_valid=1 and expected_valid=0. Specification revision 3 says valid must remain zero through the first rising edge after reset release. The correct first deliverable pairs those two observations. It does not declare that an RTL reset synchronizer is broken: the excerpt does not establish whether cycle 12 is that first edge, whether the checker samples correctly, or whether the configured specification revision matches the run. History can strengthen a comparison but cannot fill those missing facts.
For an STA engineer, the same contract might restrict reading to one timing report, one constraint excerpt, and a history of the same analysis scenario. For PD, it might compare a congestion report with an approved floorplan note. A negative slack value or congestion hotspot is an observation, while blaming an exception or macro placement is a hypothesis. Start with a single scenario and keep units, corners, and revision identities visible so the comparison has meaning.
Rewrite this request: 'Find why timing regressed and rerun until it passes.' Give the assistant one current report, one previous report, and an approved constraint excerpt. Specify the report identifiers and scenario, allow only evidence retrieval, and require a handover listing the changed observations and missing context. Use invented identifiers rather than actual project data. Decide what the assistant should return if the previous report is absent.
Return a partial comparison with the missing report recorded as an unknown. Do not substitute a report from another corner, launch timing analysis, or invent a previous slack value.
A contract cannot make incomplete evidence sufficient. Its value is that a reviewer can distinguish task completion from engineering closure. A short, well-sourced partial answer is a valid handover; accepting a design or signing off timing remains a separate engineering decision. For the threat of retrieved content changing an assistant's instructions, see OWASP LLM01:2025 Prompt Injection, the 2025 risk entry. This section applies that concern through deterministic tool boundaries.