Three pillars outside. Four stages inside. One console.
Trovensa is being designed as one platform for a drug-development program: evidence in context, work with continuity and decisions with a record, across discovery, preclinical development, clinical development and manufacturing planning, with a console in every program where agents plan, propose and a person decides.
Programs as the working scope
Permission-gated actions
Audit of every change
Agent action records
Approval records
Version history
Decision signatures
Private threads
Conceptual scientific illustration; not a measured structure, an identified compound or an experimental result.
Three pillars outside
Three pillars outside, four stages inside.
The pillars are how the platform is described. The stages are the lifecycle the records move through. Every product belongs to one pillar and would work from the same records, permissions and evidence.
Pillars, products and status
Pillar
What it means
Products
Status
CONTEXT
Evidence in context Keep sources, findings, interpretations and open questions connected.
Choose a stage to see what Trovensa does there, the intended outcome and the records it keeps. Every product serves every stage; the switch changes the view, not the record.
01 / Discovery
Turn a question into evidence-supported next steps.
Trovensa is being designed to help researchers investigate questions, identify knowledge gaps and develop evidence-supported research plans.
Intended outcomeA research question with its sources, findings, gaps and proposed hypotheses connected and labelled.
Compare findings
Agents would examine open literature, internal documents, historical experiments and datasets to compare findings and surface contradictions, with a citation on every claim.
Propose hypotheses
Each proposed hypothesis links back to its supporting and contradicting evidence for scientific review.
Keep the plan, the protocol, the data and the interpretation connected.
During research execution Trovensa would connect with the tools scientists already use rather than replace them: an electronic lab notebook, a quality document system, approved analytical and design tools, and report drafting.
Intended outcomeA plan whose protocol, experiments, results and interpretation remain linked as work repeats and branches.
Prepare a draft
Agents would prepare protocol and report drafts for a scientist to review, edit and approve with a decision signature.
Carry context
Context would move between activities so a question, its plan, the resulting data and the interpretation stay connected.
Review records against approved procedures, with the source in view.
Trovensa would compare research records with the standard operating procedure version in force when the work was done, presenting each finding with its source, the requirement and an explanation for review.
Intended outcomeReview findings a quality reviewer can accept, dismiss or resolve, each traceable to a record, a requirement and an SOP version.
Surface potential gaps
Missing metadata, unsupported conclusions, inconsistent entries and potentially undocumented deviations would be surfaced for review, never treated as proof.
Record the decision
Reviewer decisions, versions and agent actions would be kept as a record without silently changing approved scientific records.
Across discovery, preclinical and clinical development and manufacturing planning, Trovensa would maintain a connected view of program progress.
Intended outcomeMilestones, dependencies, responsibilities, supporting evidence, outstanding questions and approvals in one place.
Track progress
Teams could track milestones and dependencies while accommodating parallel activities and repeated experiments.
Reduce lost context
The long-term ambition is fewer manual handoffs and less lost context between stages and teams.
RecordsMilestonesDependenciesOpen itemsApproval records
Connected development
Evidence and review connect the lifecycle.
Discovery, preclinical research and clinical development iterate on each other while manufacturing planning and quality run alongside. Sources, research plans, study records and review decisions are the connective tissue; scientists keep the decisions.
From the brand kit: a conceptual context map, not a specific program or a product screen.
The console
Ask in plain words. See the plan. Decide each write.
The console is being designed as a section of every program where a scientist talks to agents that have read the papers, know which SOP version is in force this week and can see the notebook entry just finished, and that never touch the record without asking.
PreviewIn preview; not generally available. Status as of 2026-09-15.
Console build, illustrative data
1
1A plan before anything runs: the approved plan is the control flow; a tool outside it is refused.
Captured 2026-09-15 from build e456d2d.
Conversation
Messages, plan and approval cards, citation markers, a composer with Stop.
Canvas
The current artifact with its versions: a comparison, a finding set, a protocol draft, a deviation table, an SOP diff.
Run rail
Steps, tool calls with the permission exercised, sources read, budget used, the SOP binding and the model configuration record.
Pilot positioning
Non-GxP decision support with a light validation package.
The electronic lab notebook stays the scientific record. The quality document system stays the SOP record. Trovensa is the record of what agents proposed and what people decided.
Agents plan, read, compare, propose and flag. An authorised person decides.
Nothing an agent produces would become a record on its own. Every proposed write is intended to wait for a named person with the permission to decide, and the decision is recorded beside it. Every decision stays human and recorded. Timing claims wait for measured data.
01
A plan first
Every run would start with a short plan naming the actions, tools, sources and expected writes. Nothing runs until a person approves the plan.
02
Agents propose
Agents would compare sources, prepare drafts and check records against the SOP version in force, inside the permissions of the program. Every write is a proposal card with its citations and consequence.
03
A person decides
An authorised scientist, reviewer or program lead approves, edits or declines each item with a reason. Protocols, reports and requirement sets are approved with a decision signature that states its meaning.
04
The record stays
Tool-call proposals, decisions, signatures and audit entries are intended to remain readable after the work moves on, and cannot be changed or removed by the application.
What agents cannot do, by construction
Approve, sign or notify: those tools do not exist in the agent's toolset.
Write into the notebook or the quality system: every connector is read-only.
Hold vendor credentials: connections are read by the platform, never by the agent runtime.
Act outside the approved plan: a tool outside the plan is refused and surfaces as a new decision.
Read retrieved text with write tools in hand: fetched documents reach only a reader role that returns summaries with chunk references.
Change or remove an audit entry or a signature: the application role can only add and read them.
The connected program view
One illustrative program across four stages.
Progress is being designed to show milestones, dependencies, open items and approvals by stage, each linked to the evidence behind it. The lanes below are an illustrative sketch of that view.
Illustrative program TRV-101Illustrative
01 Discovery
Question: candidate pathway
Finding comparison (agent-generated, cited)
Hypothesis: accepted
02 Preclinical development
Plan A
Protocol v2 (draft, unsigned)
Experiment 14 and repeat
03 Clinical development
SOP check: sample handling v3.1
Finding: open
Deviation: none recorded
04 Manufacturing planning
Milestone: planning question
Dependency: blocked
Open item: owner needed
Illustrative example; the view is designed and has not been built.
Connections
The tools scientists already use stay where they are.
Designed
Trovensa would connect with the systems a program already runs on rather than replace them, and would only read from them.
read-only
Electronic lab notebook
The notebook stays the scientific record.
How it would work
Entries, their review state and attachment metadata would be read into the program and kept inside it. A button inside an entry would start an SOP check in the console. Agents never write into the notebook; a scientist carries text over by hand, with a provenance footer. The first connector is designed for Benchling.
RecordsEntry as a sourceExperiment referenceCheck on an entry
read-only
Quality document system
The quality system stays the SOP record.
How it would work
Effective SOP versions, with major and minor version, lifecycle state and effective date, would be mirrored read-only. Trovensa never approves a controlled procedure; it records which version a check was bound to and who accepted the requirement set. The first connector is designed for Veeva Vault QualityDocs.
RecordsSOP versionRequirement set with acceptanceImpact review on a new version
read
Open literature and knowledge sources
Sources with clear licences, each code rendered on its own terms.
How it would work
Search, metadata and open-access full text from Europe PMC, Crossref, OpenAlex, PubMed, ClinicalTrials.gov, openFDA, Open Targets and ChEMBL. Every fetched document carries a licence code and its provenance; a full span, a verbatim excerpt or a locator with a link is shown according to that code, never a blanket label.
RecordsSource with licence codeCited passageFinding with citation
read
Document libraries
Internal documents as sources.
How it would work
Designed; no connector is built in the current release.
RecordsDocument as a source
read
Approved analytical and design tools
A catalogue with the invocation recorded.
How it would work
Designed; the catalogue records how a tool authenticates, how long its tokens live and how it is invoked. No tool is connected in the current release.
RecordsTool invocation record
Nothing is connected today; every connection above is a design target. An electronic-lab-notebook connector, a quality-document connector and open literature sources are built and move to preview when their gates pass.
A pilot
What a pilot involves.
A pilot is non-GxP decision support with a light validation package: one program, program-scoped connections.
Roles: a program lead, the scientists on the program and a quality reviewer who reads threads for review.
Every decision stays human and recorded. Timing claims wait for measured data.
What we hand over:
The light validation package (URS, risk assessment, traceability, test evidence, release notes, change control).
The audit export with sequence number and row hash.
