Problem
The WorkIQ retrieve tool accepts natural-language search queries and may return multiple hits. The current result contract exposes source identity in retrievalHits[] (including webUrl and metadata), but document text is combined into one top-level markdown value. There is no documented per-hit body/snippet field or stable span/citation grammar that binds every body segment to exactly one hit.
An application processing a user-supplied OneDrive or SharePoint link can therefore prove which hit represents the requested item, but cannot safely isolate that item's text when the search returns additional hits. Passing the combined markdown to another model allows unrelated sources to influence the result.
Using the filename as the query is not a safe substitute: an exact filename diagnostic returned 15 hits. Passing a raw sharing URL as the natural-language query is also not a reliable supported contract.
Requested capability
Please provide either:
- Per-hit bounded body/snippet content, with a documented stable source or citation-span mapping to the corresponding
retrievalHits[] entry; or
- A server-controlled exact-item semantic read operation accepting a OneDrive/SharePoint URL or resolved share/drive/item identity and returning evidence from only that item.
The capability should:
- Preserve sensitivity-label, DLP, extraction-rights and tenant policy enforcement.
- Avoid requiring clients to download the raw Office file.
- Provide deterministic source identity and a documented output contract.
- Support authenticated headless/non-interactive CLI workflows.
- Return explicit bounded error categories for authentication, access, policy and unsupported-content failures.
Security motivation
Without exact source-to-body binding, clients must either fail closed or risk unrelated-source contamination, prompt-injection influence and unverifiable evidence claims.
Environment
- WorkIQ plugin: 2.0.2
- GitHub Copilot CLI: 1.0.86-2
- Platform: Windows
- Interactive authentication and
retrieve access succeeded; the limitation is the multi-hit source/body contract.
Related to #31 for non-interactive WorkIQ behavior, but this request is specifically about exact-item evidence isolation.
Problem
The WorkIQ
retrievetool accepts natural-language search queries and may return multiple hits. The current result contract exposes source identity inretrievalHits[](includingwebUrland metadata), but document text is combined into one top-levelmarkdownvalue. There is no documented per-hit body/snippet field or stable span/citation grammar that binds every body segment to exactly one hit.An application processing a user-supplied OneDrive or SharePoint link can therefore prove which hit represents the requested item, but cannot safely isolate that item's text when the search returns additional hits. Passing the combined markdown to another model allows unrelated sources to influence the result.
Using the filename as the query is not a safe substitute: an exact filename diagnostic returned 15 hits. Passing a raw sharing URL as the natural-language query is also not a reliable supported contract.
Requested capability
Please provide either:
retrievalHits[]entry; orThe capability should:
Security motivation
Without exact source-to-body binding, clients must either fail closed or risk unrelated-source contamination, prompt-injection influence and unverifiable evidence claims.
Environment
retrieveaccess succeeded; the limitation is the multi-hit source/body contract.Related to #31 for non-interactive WorkIQ behavior, but this request is specifically about exact-item evidence isolation.