An engineer asks, 'How many failures were caused by reset?' A keyword search may find a useful log paragraph, but it cannot establish how many attempts are in the population or whether reset caused their failures. The sentence mixes three tasks: counting records, retrieving descriptions, and making a causal judgment. Separate them before using AI. A query can count attempts with a reviewed reset tag; document search can retrieve the tag definition; an engineer still needs evidence before assigning root cause.
Use a structured query when the answer depends on exact fields, comparisons, grouping, or complete coverage of a defined dataset. Use search when you need passages that explain a requirement, an error message, or a procedure. A search ranking usually returns a limited set of relevant items rather than an exhaustive inventory. Retrieving three paragraphs mentioning timeout is therefore not the same as finding three timeout failures. Several paragraphs may describe one attempt.
Question | First tool | Evidence needed |
|---|---|---|
How many FAIL attempts are in B1? | SQL on runs | Two attempts: R2 and R3, with the build and status filter stated. |
What does timeout mean in this fictional checker? | Version-filtered document search | The checker definition, section, revision, and applicable configuration. |
Which failed attempts have a timeout tag? | SQL join | R2 and R3 from the tags relationship, counted as distinct attempts. |
Did the revision fix the timeout? | Query plus engineering investigation | Comparable runs, settings, seeds, logs, and a reviewed causal argument. |
A useful combined answer keeps the sources separate. Hand-authored synthetic response: 'B1 has two FAIL attempts, R2 and R3, in this five-attempt dataset. Both carry timeout tags. The available records do not establish why they timed out.' That answer is less dramatic than a guessed diagnosis, but it gives the next engineer a reliable starting point. Cite the query scope and relevant run IDs so another person can reproduce the selection.
The same split helps STA and PD work. SQL can select endpoints with slack below a specified threshold in a particular corner. Search can retrieve what a sign convention or exception means in the applicable documentation. Neither operation alone proves timing closure. For PD, a congestion report can identify measured hotspots, while a methodology note explains an approved remedy. A remedy that was valid for another stage or tool revision may not apply to the current run.
Define the run population and status policy, then query authoritative structured records with an explicit denominator. Use logs to explain selected attempts, not to estimate total attempts from search hits. If the records are incomplete, report that coverage limit instead of manufacturing a project-wide rate.
Before letting an assistant draft SQL, give it the approved schema rather than unrestricted database discovery. Before retrieval, give it an approved document collection and the required project, version, and configuration filters. Keep both tools read-only. If records conflict with a document, surface the conflict: a design requirement and an observed implementation result are different kinds of evidence. Do not silently overwrite one with the other.
A well-written query can still summarize bad imports, and a highly ranked passage can still belong to the wrong specification. Keep an export snapshot identifier, query text, parameter values, and document revision with the answer. References: SQLite SELECT semantics, consulted 2026-10-18; Sentence Transformers semantic-search documentation, consulted 2026-10-18. The next section builds an evidence retrieval workflow with explicit abstention when the required source is missing.