Lab admin demo: the pipeline behind the answers
Before a researcher gets a cited answer, a lab admin turns raw files into a governed, citeable knowledge base. These walkthroughs show that pipeline on the real product UI — from upload and security scanning through ingestion, embedding, and structured sources.
The data pipeline
The data pipelineAdmin walkthrough
- Upload research files — PDFs, Office docs, notes, code and simulation decks.
- Each file is malware-scanned before anything else touches it.
- Ingestion extracts text; embedding makes it searchable — each stage shows its status.
Every upload clears security scanning, then ingestion, then embedding — visible per file.
Text description of this walkthrough
- A lab admin opens the Documents view for their workspace.
- The list shows the workspace's uploaded files, each with its own processing state.
- One file, autoclave-protocol.md, has finished: its document status reads ready and its embedding status reads ready, so it is searchable and citeable.
- A second file, reagent-safety.pdf, is still moving through the pipeline: its document status reads processing and its embedding status is still pending.
- No stage is hidden — an admin can see exactly where any file is before anyone asks a question of it.
Data structuring
Data structuringAdmin walkthrough
- A document carries its type, source, and confidentiality — captured, never invented.
- Its page and section structure is what later answers cite back to.
- Nothing is summarized or altered; the original passages remain the source of truth.
A raw file becomes a structured, citeable document with type, source, and page/section context.
Text description of this walkthrough
- A lab admin opens the detail view for a single processed document, autoclave-protocol.md.
- The page is headed by the original filename — the file is never renamed or rewritten.
- Alongside it sits the document's captured metadata: its type, its source, and its confidentiality marking.
- Below that is the structure extracted from the file — the page and section context that later answers cite back to.
Governance and provider choice
Governance and provider choiceAdmin walkthrough
- Every workspace shows its own AI usage — the basis for hard spend caps.
- The AI provider is the admin's call: platform-managed, your own API key, or on-prem/local.
- Where the research data and the model run stays a governance decision, not a default.
Per-workspace AI usage plus the provider setup — managed, your own key, or fully local.
Text description of this walkthrough
- A lab admin opens the organization settings page for their workspace.
- The Workspace AI usage panel is shown first: the number of AI events, the total tokens used — 1,500 in this recording — and the estimated cost, USD 2.50.
- Those figures are estimates for visibility, and they are the basis for the workspace's hard AI spend cap.
- The view then moves to the AI provider setup panel, where the admin chooses how AI runs: platform-managed, the lab's own provider API key, or a fully local, self-hosted model.
Governance the whole time
- Per-tenant isolation: each lab's corpus stays separate by organization and workspace.
- Your choice of where the AI runs — managed, your own key, or fully local/on-prem.
- Hard AI spend caps per workspace, so ingestion and questions never run away on cost.