“Find earlier cases about this fault” and “How many cases involved this fault last quarter?” sound like neighboring questions. They need different evidence. A useful set of search results can answer the first without containing everything required to answer the second. Counting the returned results can produce a precise-looking number with the wrong meaning.
Disclosure: An AI agent researched and drafted this article from my public project documentation and the linked technical sources. The reporting examples are hypothetical design examples, not findings from company records.
My Illumia Archive Intelligence case study describes an implemented local retrieval tool using Python and PostgreSQL, with a browser interface and a Claude Desktop MCP connection. Parent cases remain connected to their work records. The assistant has six bounded, read-only tools, including search, record retrieval, and exact aggregates. Counts and totals come from database queries.
Its validation boundary matters: application, packaging, and MCP startup tests used synthetic records. Full archive relevance checks and acceptance on managed workplace devices are separate steps. Those tests do not establish production answer accuracy.
Microsoft's October 13, 2026 article on grounding apps without a separate vector database describes using the Microsoft 365 Copilot Retrieval API with SharePoint Embedded. An application retrieves relevant text extracts, then supplies them to its own model. The developer retains control over prompting and orchestration while Microsoft handles retrieval from the governed content layer.
This is a different architecture from Illumia's local PostgreSQL archive. The useful connection is the shape of the task: retrieval selects evidence for an answer. Moving that operation into a managed service does not turn its response into a complete census of the underlying records.
The Retrieval API reference makes the selection visible. Its documented maximum result count is between 1 and 25, and results are security-trimmed for the calling user. The SharePoint Embedded guidance also states that a metadata-matching file might not appear if its content is unrelated to the semantic query. That data-source support is marked preview in the guidance.
A returned list can be highly relevant and still be incomplete for counting. A source link lets someone inspect a result. It does not establish how many unreturned records meet a reporting definition.
For a comparable service archive, I would clarify the unit before implementing the aggregate. Does the question ask for distinct cases, matching work entries, or recorded hours? A single case can contain several notes about the same fault. Counting notes and calling them cases changes the result even if every match is correctly retrieved. The date needs a definition too. “Last quarter” might refer to when a case opened, when a technician wrote a note, or when work occurred. A case opened before the reporting period could contain work inside it. A query using the wrong date field may run perfectly and answer a different question.
Then define the category. Literal mentions of a fault code are observable. “Cases caused by this component” may require a diagnosis field or a reviewed classification rule. A note can mention a component to say it was checked and ruled out. Search relevance alone cannot settle that distinction.
If the data cannot support the requested category, the answer should say what can be counted. “Cases containing this exact code in work notes” is a useful, limited measure. Calling it the number of confirmed component failures would overstate the evidence. Once the definition is clear, I would expose a bounded aggregate with typed filters and a known result shape. The response should include the value, the counting unit, the date field and interval, and the applied category rule. Keep the model's job focused on explaining that result and identifying an unresolved assumption.
This is a proposed reporting contract, not a claim about every field currently returned by Illumia. The documented project choice is narrower: the assistant uses bounded tools, and database queries provide exact aggregates rather than model estimates.
The count is exact only relative to its query and dataset. Missing imports, duplicate source records, an outdated snapshot, or an unsuitable category definition can still make it unhelpful. Returning the archive's coverage or import status, when available, helps a person judge the number's limits.
For testing, a small synthetic archive can deliberately include one parent case with several matching notes, a note outside the date interval, and a case whose text mentions a fault without confirming it. Compare the aggregate with an independently calculated expected result. Separately test whether search finds useful examples. Those checks answer different questions. A useful interface can show a scoped total and a few supporting cases together. Label the cases as examples, identify how they were selected, and let a reviewer inspect their histories. Do not imply that a short ranked list explains every member of the total.
Access scope also belongs in the wording. A count over records available to one user should not be presented as an organization-wide total unless that scope is established. A retrieval or reporting service must enforce the relevant access rules; a sentence in the assistant's prompt cannot substitute for that enforcement.
As grounding services become easier to integrate, more teams can build an archive assistant quickly. The operational work shifts toward defining the questions it can answer faithfully. Keep discovery flexible, give reporting explicit definitions, and make the answer's scope visible. That lets people use the assistant for investigation without accidentally treating a selection of good examples as the whole business.