Skip to content

docs(groq): flatMap citations across all search executions (#69)#75

Merged
stackbilt-admin merged 1 commit into
mainfrom
docs/groq-builtin-citations-flatmap
May 29, 2026
Merged

docs(groq): flatMap citations across all search executions (#69)#75
stackbilt-admin merged 1 commit into
mainfrom
docs/groq-builtin-citations-flatmap

Conversation

@stackbilt-admin
Copy link
Copy Markdown
Member

Follow-up to the #69 sprint, from a live verification of the downstream consumer call.

Why

Running stackbilt-web's exact planned call (groq/compound + builtInTools: [{type:'web_search'}] + response_format: json_object) through the shipped code against live Groq, the model ran 2 search executions on the first real query. Multi-execution is the common case for research workloads — so metadata.builtInToolResults is an array of executions, and the citation-read documented in S5 (and the issue body):

res.metadata?.builtInToolResults?.[0]?.results   // silently drops execution [1]+

…compiles clean and returns a partial citation set with no error. That's the one runtime-silent footgun in the otherwise-green feature; left uncorrected it would land truncated citations in a consumer's evidence store unnoticed. The [0] pattern would be copied verbatim from the README into the downstream Librarian stage.

Change (docs-only)

  • Snippet now flatMaps across all executions:
    const citations = (res.metadata?.builtInToolResults ?? []).flatMap(exec => exec.results);
  • Citations note clarifies three things the live call surfaced: iterate all executions (not [0]); score is the provider's retrieval-relevance score (not an authority/quality ranking); and response content (the model's synthesized/curated answer) vs builtInToolResults (raw retrieved hits) are different sets.

No API change. The rest of the verification was green — see the review notes on the parent work.

🤖 Generated with Claude Code

…ions (#69)

Live verification of the downstream consumer call (groq/compound + web_search)
showed the model running multiple search executions in a single call — so
`builtInToolResults` is an array of executions, and the previously documented
`?.[0]?.results` pattern silently drops every execution after the first. That
read compiles clean and returns a partial citation set with no error, so it
would land truncated data in a consumer's store unnoticed.

- README built-in-tools snippet now flatMaps results across all executions.
- Citations note clarifies: iterate all executions (not just [0]); `score` is
  the provider's retrieval-relevance score, not an authority ranking; and
  response `content` (model's synthesized/curated answer) and
  `builtInToolResults` (raw retrieved hits) are different sets.

Docs-only; no API change.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@stackbilt-admin stackbilt-admin merged commit 7917832 into main May 29, 2026
2 checks passed
@stackbilt-admin stackbilt-admin deleted the docs/groq-builtin-citations-flatmap branch May 31, 2026 10:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant