Trovensa documentation

From evidence to progress. Trovensa is being designed to connect scientific evidence, research workflows, and the decisions that advance drug-development programs. Inside one program, four products are intended to hold the work: Evidence (questions, sources, findings, hypotheses), Plans (plans, protocols, experiments, reports), Review (SOP checks, findings, deviations) and Progress (milestones, dependencies, approvals), and a console section where a scientist talks to the agents inside a program. Agents prepare, compare, propose and flag; an authorised person reviews and decides, and the record shows who did what. This site describes how the platform is designed to behave, how it is built and what each release needs. The pilot is positioned as “non-GxP decision support with a light validation package”.

Status of every product

The four hosts answer since the first release on 2026-09-13 and sign-in is configured. Since 2026-09-15 the console, Evidence, Plans and Review carry the status word preview (a private preview for design partners, scoped to discovery and preclinical work); Progress and the clinical and manufacturing objects stay designed; nothing is generally available. The transition followed the two registered measurements named in the contract (section 10.12) and was made in one commit across forge.config.json, the contract, CLAUDE.md, this page and the claims register. Every seeded record is labelled “Illustrative”. The console is a program section, not a fifth product, and carries the same word.

The full table with icons, entry routes and stages is the products reference; the reasoning behind pillars and stages is in About pillars and stages.

What the kit says Trovensa is for

The brand line is “Evidence -> Plans -> Review -> Progress”. In the kit’s words, the three core messages are Evidence in context (findings that keep their sources), Work with continuity (plans, protocols, experiments and milestones that stay connected across a program) and Decisions with a record (review findings and approvals that a person decides, with a rationale that stays attached). Agent output is always “agent-generated” or “proposed”; a success colour never certifies a scientific conclusion.

How the documentation is organised

Every page has one job. Knowing the four types tells you where to look.

Start here

• New to the platform: Get started, then Ask the agent.
• Working in a program: How to connect a source, How to connect an ELN, How to connect a QMS, How to launch from your notebook, How to accept a requirement set, How to approve with a signature, How to export the audit trail, How to run an evidence comparison, How to review a record against an SOP, How to request an approval, How to switch programs.
• Looking things up: Permissions, Personas, Statuses, API, Console, Connectors, Licence codes, Signatures, Agent versions.
• Joining the team: Contract summary, Decision log, Roadmap, Runbooks.

Where things live

Hosts answer since the first release (see the deployment record); the local ports are the ones the tutorials use.