literature_review_requested is hardcoded true at emit — recorded intent field doesn't reflect SME intent

[andrewsu]

Summary

The provenance field literature_review_requested, recorded in policies/intake-facts.json, is hardcoded to true at emit time rather than derived from the SME request. Its name reads as captured intent ("the SME requested a literature review"), but its value is a constant independent of what the SME actually asked for. For a system whose central claim is faithful capture of SME intent, this is a provenance-fidelity gap in the intent subgraph.

Determined vs. recorded

• Recorded in: policies/intake-facts.json — the literature_review_requested boolean on IntakeFacts (crates/core/src/intake_facts.rs, field ~L67; mirrored to the UI via crates/core/bindings/IntakeFacts.ts).
• Nominal determiner: IntakeFacts::detect_literature_intent(prose) (crates/core/src/intake_facts.rs, ~L176) — a deterministic, conservative substring match over LITERATURE_INTENT_KEYWORDS = [literature, prior work, references, citations, contextualize, published] (+ "compared to (the) literature"). Default false. Its docstring calls it "the single source of truth for whether literature_review_requested flips true."
• Effective determiner: a hardcoded override. Both emit paths set the flag unconditionally:
  • crates/cli/src/main.rs (~L943): intake_facts.literature_review_requested = true;
  • crates/conversation/src/emit/mod.rs (~L259): intake_facts.literature_review_requested = true;
  • Comment at both sites: "Literature contextualization is unconditional — every emitted DAG carries the review_prior_work + contextualize_findings_with_literature atoms."
• The gate is a no-op: composer::slot_fill::prune_literature_atoms_from_workflow_dag(_dag, _requested) returns the empty set and ignores _requested by design (docstring: "a no-op: it never prunes … Always returns the empty set."). The regression test crates/core/tests/composer/composer_literature.rs asserts "there is no longer an opt-in gate that drops them on plain prose."

So the detector still exists, but its result affects neither the emitted DAG nor the recorded fact.

Reproduction (Himes case study)

The Himes request text contains none of the six literature keywords, yet the emitted package records "literature_review_requested": true (see testdata/replay/himes-parent/policies/intake-facts.json and all 23 testdata/emitted-packages/*/policies/intake-facts.json, which are uniformly true). The value was not derived from the request.

Why it matters

A reviewer inspecting a deposited package's intent subgraph will reasonably read literature_review_requested: true as "the scientist asked for literature grounding," when it only means "the emitter always writes true." The field masquerades as captured intent while being a constant — undermining the faithful-intent-capture property in exactly the subgraph that's supposed to carry it.

Stale documentation (same root cause)

Several comments still describe the removed opt-in behavior and should be reconciled:

• config/archetypes/bulk_rnaseq_de.yaml — review_prior_work comment: "Gated by intake.literature_review_requested via compose_with_intake; when the SME hasn't opted in, this atom … filtered out … so the emitted DAG is byte-identical to a pre-literature DAG." (also in generic_omics.yaml, chip_seq_peaks.yaml, variant_calling_germline.yaml)
• IntakeFacts::detect_literature_intent docstring — claims "the … emit path … call[s] it," but the emit path overrides it.

Proposed fixes (pick one)

1. If literature is genuinely always-on: rename the field to a DAG fact (e.g. literature_atoms_included: true) so it stops presenting as captured intent, and update the stale docstrings/archetype comments.
2. If intent capture is the goal: set the recorded field from detect_literature_intent(prose) — record the real SME intent even though the atoms run unconditionally (decouple "what was asked" from "what was executed"). Consider recording both.

Open question

Does anything downstream (audit-proof pass, claim-completeness, RO-Crate intent subgraph) read literature_review_requested as evidence of intent? If so, the constant-true value is load-bearing, not merely cosmetic, and fix (2) is preferable.

---

_{Filed from a source review against main (8cd0f34). Line numbers approximate.}