Foundations
Platform Overview
The documentation model for TrialStack and how customer docs relate to internal repository knowledge.
Platform Overview
TrialStack is organized around governed records, connected operational context, and reviewable workflows.
The operating model
Most teams experience TrialStack through five layers.
1. Core governed records
These are the records teams return to repeatedly:
These records are version-aware and designed for ongoing change, review, and recovery.
2. Connected context
Trials and documents do not stand alone. They connect to organizations, sites, contacts, personas, interventions, systems, and media so teams can review work in operational context rather than as isolated fields.
2.5. Shared entity views
Most record pages in TrialStack are built from the same entity-page pattern. A binding loads the entity and its history, metadata defines the sections and field descriptions, and a shared renderer turns that metadata into the visible form.
That is why trial, organization, site, contact, intervention, media, template, and rule pages feel related in use even when they describe very different kinds of records.
3. Workflow modules
Some areas need more than a single record page. Trial design, approval, monitoring, recruitment, retention, safety, and statistical planning each have their own operational depth and review expectations.
4. Automation and AI-assisted work
Templates, rules, actions, runs, chat workflows, and protocol feasibility help teams move faster, but they do not remove accountable human ownership.
5. Governance and administration
History, compare, restore, approvals, usage visibility, onboarding state, and permissions are part of the product surface. They are not hidden back-office details.
How to read the docs
Use this site to understand:
- What a capability is for.
- When to use it.
- How it affects the wider workflow.
- Where review and governance matter.
- How the shared entity-page model structures the data users maintain.
Use TrialStack API reference to understand:
- Exact contracts.
- Request and response details.
- Schema-level behavior.
Why the split matters
Customers need workflow guidance. Integration teams need contract detail. Engineering teams need implementation notes. Mixing those layers makes every audience slower.
The documentation model is therefore explicit:
- This site explains what to do and why.
- API reference explains the exact contract surface.
- Internal engineering notes stay in local READMEs and internal materials.
What success looks like
A team using TrialStack well should be able to:
- Understand the main record types and when to use them.
- Know when a workflow moves from drafting into review.
- Understand how history, restore, and approvals support safer change.
- Recognize the shared structure across entity pages and understand what data each section is responsible for.
- Decide when the UI is enough and when deeper integration is needed.