Clarification on bibliographic API usage in ARS-Codex

[Alexei-WLU]

Could you please confirm whether ARS-Codex uses the OpenAlex, Semantic Scholar, Crossref, or arXiv APIs/clients:

1. During normal literature discovery or topic searching?
2. During subsequent citation/reference verification?

For each stage, are these calls automatic, explicitly requested, or not used?
Please also clarify whether this differs between upstream ARS and ARS-Codex.

[Imbad0202]

Thanks for asking. I checked this against the signed upstream ARS v3.21.0 release (2b639c1). ARS-Codex v0.1.26 is now published with that vendor alignment and a Codex-specific routing table, so the Codex v3.21 statements below describe the released package.

Short answer: ordinary literature discovery/topic searching does not launch any of the four Python resolver clients. Later citation verification can use them, but the trigger differs between upstream script-backed execution and ARS-Codex.

Path	Semantic Scholar	OpenAlex	Crossref	arXiv	Trigger / runtime meaning
Ordinary topic or candidate discovery	Resolver client not used	Resolver client not used	Resolver client not used	Resolver client not used	Upstream uses WebSearch; ARS-Codex maps this to Codex browsing and authoritative web sources
Agent-side ingest, deduplication, or source checks	Upstream prompts may name an index lookup, but do not bind the Python resolver class	Same	Same	May be used as a source/index through session tooling, but not through the narrow resolver client	Prompt-level “automatic lookup” intent; ARS-Codex performs the inline route through browsing or official metadata pages
Citation-existence gate	Runs for each non-manual reference	Runs for each non-manual reference	Runs for each non-manual reference	Runs only when arxiv_id is present	In an upstream script-backed full-pipeline run, the gate fires at Stages 2.5 and 4.5. In ARS-Codex, ars-full alone does not authorize or launch the Python clients; programmatic reference verification must be requested explicitly. Standalone CLI use is also explicit
Claim-standing discovery (new in v3.21; not ordinary discovery)	Called only if selected as an index target	Same	Same	Same	Separate user request plus affirmative, plan-bound consent. This path uses separate keyword-discovery adapters and never imports the single-reference resolver clients
Migration or backfill	Explicit legacy S2 backfill CLI	Explicit OpenAlex backfill CLI	Explicit Crossref backfill/metadata CLI	No equivalent migration caller	Explicit CLI invocation only; never automatic

Two uses of “automatic” are easy to conflate here:

1. Upstream prompt text can instruct an agent to perform an index lookup automatically through available session tooling. That is not executable wiring to the four Python resolver classes.
2. Once the script-backed citation gate has actually been entered, its resolver selection is automatic: Crossref/OpenAlex/Semantic Scholar for non-manual references, plus conditional arXiv.

Even in the second case, this does not mean every reference is checked live against all four indexes: manual references skip all four, arXiv is conditional, cache hits make no live call, and stale live revalidation is opt-in. Citation-existence results are advisory by default; strict blocking is separately opt-in.

So the upstream/Codex difference is mainly the launch boundary: upstream script-backed Stage 2.5/4.5 execution invokes the gate, while the ARS-Codex adapter requires an explicit programmatic-verification request and otherwise performs its mandatory integrity checkpoints through Codex browsing. The v3.21 claim-standing path is a third, separately consented discovery path, not an expansion of ordinary topic search.

The relevant upstream maps are DATA_FLOWS.md, the citation verification gate, and the separate claim-standing discovery adapters.