An agent searches for a deployment procedure and finds a relevant passage. Meanwhile, someone has published a correction to that procedure. The passage is useful, but it's from the previous version.
That can happen without a failed publish or a broken search. In a system with asynchronous indexing, the newest saved document and the newest searchable document can be different versions.
The caller needs to make three separate judgments: does the passage relate to the task, can we reopen its exact source, and is that version current enough for the work?
A relevant result can come from an older version
LedgerInfra Search retrieves chunks from authorized HTML in one Workspace. It combines keyword and semantic retrieval; it doesn't generate an answer or decide whether a procedure applies to your task.
Publishing saves a version before its search index is ready. While a new version is pending, Search can continue using the previous ready version. If the new index fails, that previous ready version can remain searchable.
Consider this illustrative sequence:
| State | Latest saved version | Searchable version | Latest-only search |
|---|---|---|---|
| Initial review indexed | A | A | A is eligible |
| Correction published, indexing pending | B | A | Slide is excluded |
| Correction indexed | B | B | B is eligible |
| Correction indexing failed | B | A | Slide is excluded |
Eligibility doesn't guarantee a match for your query. The point is that saving B and finding B are separate checkpoints.
For a historical comparison, A may be exactly the version you need. For a task that requires the current operating procedure, silently using A would be a mistake.
Cite the fixed source you actually read
Run a search in the intended Workspace:
led search "deployment recovery procedure" \
--workspace <WORKSPACE_KEY> --limit 8 --json
For each result you use, inspect version_key, latest_version_key, and is_latest_version. Keep its fixed_version_url with the evidence.
The fixed URL points to the uploaded HTML version behind that chunk. latest_url, when present, is useful for checking current content, but it can move after an update. Citing it as the source of an older retrieved passage could send a reviewer to different text.
Read the surrounding document before applying the excerpt. A relevant paragraph may have a scope restriction elsewhere in the same review. A ranking score helps order retrieval results; it doesn't establish authority, accuracy, or approval.
Decide whether older evidence is acceptable
When the task requires current versions, use:
led search "deployment recovery procedure" \
--workspace <WORKSPACE_KEY> --require-latest --json
--require-latest filters out Slides whose latest version isn't ready in the search index. It doesn't wait for indexing, force a retry, or retrieve the previous version while calling it current.
That makes fewer results a meaningful outcome. An empty latest-only response means this search found no eligible matches. It doesn't prove that the Workspace contains no relevant material, or that an older result was wrong.
Choose the response in your agent workflow explicitly:
- For a historical investigation, allow an older version and label it as such.
- For work requiring the current procedure, stop or defer when the latest source can't be verified.
- When you already know the intended Slide and version keys, fetch that saved version directly instead of depending on Search discovery.
Avoid automatically relaxing the filter after zero results. That changes the evidence policy of the task.
Verify a known version without waiting for discovery
For a just-published review, retain the returned identifiers and check its status:
led show <SLIDE_KEY> --workspace <WORKSPACE_KEY> --json
led fetch <SLIDE_KEY> --version <EXPECTED_VERSION_KEY> \
--workspace <WORKSPACE_KEY> --output ./source-review.html --json
Replace placeholders with real keys and use an unused output filename. show reports the latest version's search_index_status: pending, ready, or failed. A pending index doesn't prevent authorized retrieval of a saved fixed version.
If discovery is required, your orchestrator can perform a bounded retry and decide when to stop. LedgerInfra doesn't supply that scheduling or completion policy. Don't infer a readiness deadline from publish success.
Access still matters. A private Slide is visible only to its current private owner; membership alone doesn't reveal it. Read grants don't include private Slides. An authorization error should lead to an access check, not an automatic visibility change.
Carry the version check into the next task
Record the exact source version and why it was acceptable for the task. Distinguish “current when checked” from “the version used for the earlier decision.” Recheck freshness when a later task requires current evidence.
Search reads static uploaded HTML. It doesn't execute JavaScript or fetch remote data to discover facts that appear only after rendering. Keep necessary caveats and evidence in static text. Fixed versions preserve the uploaded bytes, while access, remote dependencies, and final rendering remain separate concerns.
To try the retrieval side with a non-sensitive artifact, follow the LedgerInfra Quickstart.
When your agent finds an older source during a current task, does it stop, label the version, or quietly use it?
Top comments (0)