From evidence to output
An answer can draw on several kinds of source. The route matters: an exact patient-source or ETL read can produce a registered citation, while a live Copilot lookup can return a document link or public URL. These references carry different information about what was read.
Follow a source through its read, reference, and saved result. Explore the evidence paths.
Patient files and guidelines
The app preserves an uploaded or pasted source as an immutable version. When a drafting request starts, it records the selected source versions and confirmed patient state where required. Its workspace manifest names the exact files and byte hashes that Eve can read. The local prepared-file cache can be rebuilt; it does not own the record.
grep finds a relevant location. read_file then opens the original PDF pages, text lines, or structured record. A search snippet or extracted companion file may help locate the source, but the original owns the citation.
For application runs with evidence registration, OncoBrain verifies the source and exact passage before recording an evidence alias such as [E-…]. The record binds the alias to its run, source version, page or line range, and excerpt. A source chip in the resulting draft can therefore open the passage that supports the claim.
Clinical extraction has a separate input path: it receives a bounded packet prepared by the app and has no model-visible tools. Sources and chart review explains how extracted proposals become confirmed facts.
ETL records and internal-evidence tools
ETL publishes versioned LanceDB tables outside this repository. OncoBrain reads that corpus through its internal-evidence store. It does not run the upstream collection or transformation pipeline.
| Step | What crosses the boundary |
|---|---|
search_internal_evidence | A bounded query returns discovery results from an available source family, such as product labels. |
| Select a returned result | Eve maps the exact table version, row, passage offsets, and hash to a session-local result-N reference. |
read_internal_evidence | The app reopens that version and row, checks the passage hash and source URL, and returns the exact text. |
| Register the passage | The app stores the source version, locator, excerpt, and run-bound citation alias. |
| Write the draft | Eve uses that alias to support a claim within the source's scope. |
The read keeps the table version found by the search. A later ETL publication does not silently replace the passage. For a product label, provenance can include its official URL, effective date, SPL version, and content hash. Label evidence can answer a label question; it does not establish patient facts or a guideline's preferred treatment.
Library documents and live public search
General Copilot can inspect authorized documents without starting from an attached case. list_workspace returns the current Library inventory. read_document takes the selected item's complete readArguments, including its version selector, and returns preserved text or PDF pages with the recorded source identity and URL. Newly added documents can appear in this live inventory.
Copilot also has search_web for topic-only public research. The app checks the query for patient identifiers before dispatch. Search returns provider excerpts, source URLs, and a search time. This path currently has no separate page-opening tool and does not create evidence-ledger aliases. Copilot cites the returned URLs and dates in its reply.
Standard workup, treatment, and trial drafting do not receive this live-web tool. A public-search result is therefore shown on the Copilot branch above; it is not an input to the current treatment-drafting workflow.
What is saved
A workflow's final Markdown and its registered evidence references become an immutable artifact version. The organization database records the run, its captured inputs, the artifact identity, and the evidence ledger. Copilot replies instead belong to a conversation thread and retain the exact run that produced them.
Before saving an artifact, the app removes unregistered evidence-like aliases. This prevents an invented token from acting as a working citation; it does not prove that every clinical claim is correct. Source review remains necessary.
Treatment views derive from the saved draft:
| Result | Inputs and behavior |
|---|---|
| Comparison | A model formats the exact treatment artifact into structured options. It has no evidence tools; the app checks the result against the draft's labeled content and known citations. |
| Flowchart | A second projection uses that artifact, its current Comparison, and already registered citation excerpts. It records the exact Comparison version it depends on. |
| Matrix | The app derives a schedule view from the presentation, run-pinned templates, and clinician revisions or selection. Rendering it does not start another evidence search. |
| Plan version | A clinician selects or edits an option. The app preserves an immutable plan version with its source artifact and chosen option or schedule snapshot. |
These views help review the same treatment draft. They do not independently establish new clinical evidence or create orders.
Follow the implementation
| Boundary | Code |
|---|---|
| Immutable patient sources | apps/oncobrain/src/lib/server/cases/patient-source-store.server.ts |
| Captured run inputs and workspace | apps/oncobrain/src/lib/server/cases/run-workspace-projection.server.ts and run-workspace.server.ts |
| ETL search and version-pinned reads | apps/oncobrain/src/lib/server/internal-evidence/direct-internal-evidence-store.server.ts |
| Evidence verification and storage | apps/oncobrain/src/lib/server/evidence/evidence-verification.server.ts and apps/oncobrain/src/lib/db/evidence-store.ts |
| Live document and web tools | apps/oncobrain/src/lib/server/mcp/oncobrain-mcp.server.ts |
| Artifact settlement | apps/oncobrain/src/lib/server/cases/workflow-run-settlement.server.ts |
| Treatment views | apps/oncobrain/src/lib/server/treatment/treatment-presentation.server.ts and treatment-decision-map.server.ts |
AI walkthroughs connects these paths to concrete questions and tool calls. How AI requests run covers the request lifecycle.