Keeps the scientific record.
Entries are read, never written. A scientist carries agent-generated text over by hand, with a provenance footer.
Security
Accountability and security.
Trovensa is being designed so that every consequential action has a scope, a permission, an actor and a record, whether a person or an agent took it. A pilot is non-GxP decision support with a light validation package.
The records it would keep are evidence your quality process consumes. They do not vouch for a record, validate a therapy or stand in for a reviewer; an authorised person reviews and decides.
The controls
The trust ledger.
One row per control: what it is, where it stands, the record it leaves, who can read that record and the page that describes it. Nothing here is a compliance statement.
| Control | Status | The record it leaves | Who can read it | Reference |
|---|---|---|---|---|
| Programs as the working scope A program is the scoped workspace of one development effort. Every record, thread, document and connection is intended to carry its organisation, program and stage, so scope is a property of the data rather than a filter. | Preview | organization · program · stage on every record | Program members with program.settings.read; every persona of the program holds it. | Permissions reference |
| Permission-gated actions Actions are being designed to check a named permission before they run. Agents would act under a run-scoped identity with one token per role and only the tools that role may call; approving an agent's write needs the write's own permission, recorded as the permission exercised. | Preview | permission string · scope · role · permission exercised | Holders of program.roles.read see who holds what; the permission exercised is part of the audit entry. | Personas reference |
| Audit of every change Every change would write an audit entry in the same transaction: who or which agent acted, who approved, the proposed and the approved content as hashes, and the reason where one is required. The database sets the sequence number and the row hash; the application can add and read entries, never change or remove them. | Preview | actor kind · agent · approved by · reason · sequence · row hash | program.audit.read inside a program (every program persona); org.audit.read for the organisation export (owner, admin, auditor). | Export the audit trail |
| Agent action records Each run is intended to keep its plan, its tool calls (proposed, approved, edited, declined or refused), the sources it read, the agent version and the model configuration record, so a reviewer can replay it later without opening the thread. | Preview | plan · tool calls · sources read · agent version · model configuration | program.agent_runs.read lists runs; the events, tool calls and snapshot of a thread run follow the thread rule (owner, shared, or program.threads.read). | Console reference |
| Approval records Plans, protocols, reports, hypotheses and milestones would carry approval requests with the decision, the deciding person and the rationale. "Approved" is a record, never a default; agents hold no tool to request or decide one. | Preview | request · decision · decided by · rationale · signature | progress.approvals.read, held by every program persona; deciding needs progress.approvals.approve. | About records and signatures |
| Version history Protocols, reports and procedures are being designed as versioned records. A signed record cannot be edited in place; a change creates a new version naming the one it supersedes, and every check names the SOP version it was bound to. | Preview | version · supersedes · changed by · SOP version bound | The record's own read permission: plans.protocols.read, plans.reports.read, review.sops.read. | About SOP binding |
| Decision signatures Approving a protocol, a report or a requirement set would require a decision signature: the signer, a meaning the server derives from the action (authored, reviewed, approved or acknowledged), the statement shown and confirmed, a fresh sign-in, and a hash of the signed content. The record shows whether the signature is still valid. | Preview | signer · meaning · statement · record hash · signed at | Anyone who may read the signed record; the signature shows whether it is still valid. | Approve with a signature |
| Private threads Conversations are private to their owner by default and say so. Quality reviewers and program leads can read a thread for review; sharing is the owner's explicit action with a confirmation; archiving or exporting a thread needs a recorded reason. The same rule governs the run details behind it. | Preview | owner · visibility · shared on · read for review by | The owner and anyone the owner shared with (program.threads.read_own); quality reviewers, program leads and owners read for review (program.threads.read). | About the console |
Private preview for design partners. The console, Evidence, Plans and Review are in preview; Progress is in preview; clinical and manufacturing objects are designed. Not generally available. Status as of 2026-09-15.
Pilot positioning
Three records, three owners.
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.
Keeps the SOP record.
Effective versions are mirrored read-only. Trovensa never approves a controlled procedure.
Keeps the record of what agents proposed and what people decided.
Plans, tool-call proposals, decisions, signatures and audit entries, kept for the life of the tenant.
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.
Retention, describedConversation bodies are redacted after the organisation's retention period; tool-call proposals, decisions, snapshots, signatures and audit entries persist. Notebook content fetched into a program is archived and purged after a hold when its source is removed, with the locator and hash retained.
Record shapes
Field names, not figures.
The record types below are the ones a quality process would ask for first. Each is shown as its intended fields; the values would come from your program.
Audit entryIllustrative
- sequence number (database-set)
- row hash (database-set)
- actor kind (person, agent or system)
- agent identity
- approved by
- decision id
- proposal hash
- approved hash
- reason
- occurred at
Tool-call proposalIllustrative
- run
- tool
- argument summary
- proposal hash
- approved hash
- decision (approved, edited, declined, refused)
- decided by
- permission exercised
- reason
Decision signatureIllustrative
- signer
- meaning (authored, reviewed, approved, acknowledged)
- statement shown
- record type and version
- record hash
- signed at
- sign-in evidence
Approval recordIllustrative
- subject (plan, protocol, report, hypothesis or milestone)
- version
- requested by
- decided by
- decision
- rationale
- signature
- time
Check bindingIllustrative
- record checked
- SOP version
- binding rule (automatic or chosen)
- binding reason
- requirement set hash
- check logic version
- agent version
- supersedes check
Run snapshotIllustrative
- run
- thread
- plan hash
- chunks read (ids and hashes)
- records read
- SOP versions
- prompt version
- tool allowlist
- permission snapshot
- model configuration check
Illustrative record shapes from the console build; not generally available.
Infrastructure
Infrastructure, described.
Each heading below is filled only from the infrastructure code and the contract. A heading without a verified fact renders nothing.
- Tenancy
- One organisation per identity-provider tenant; every record carries its organisation, program and stage, so scope is a property of the data rather than a filter.
- Identity providers
- Sign-in uses your organisation's own enterprise identity provider with issuer and audience pinned; the first supported provider is Microsoft Entra ID. Development tokens are accepted only in development environments.
- Encryption
- Database storage is encrypted at rest. Documents live in a versioned bucket encrypted with a dedicated managed key whose policy refuses plaintext transport. Every public host serves TLS.
- Backups
- Automated database backups run with a retention window set per environment by the infrastructure code; programs are archived, never deleted, so audit and signature rows keep their references.
- Data location
- The current environment runs in one cloud region in the United States (us-east-1); the database, the documents bucket and the outbound mail identity live in the same account and region.
No compliance claim
Described, never claimed.
We make no compliance claim. We describe each control and name the record it leaves.
Read on