About pillars and stages
Two vocabularies describe the platform and they are deliberately different in shape. Pillars are the outer positioning: three upper-case words that say what the platform is for. Stages are the inner lifecycle: four immutable ids that say where in a drug-development program a record sits. Products hang between them: each product serves one pillar and every product covers all four stages.
The problem
A drug-development program is long, and its evidence, plans, reviews and milestones outlive the people who started them. The brief asked for four capability areas (discovery investigation, research execution, quality review and traceability, program progress) and named the lifecycle “discovery, preclinical and clinical development, and manufacturing planning”. One flat list of features would blur the two ideas; a matrix of areas by lifecycle would multiply pages without adding meaning.
How it works
| Pillar | Product | Stages | Status |
|---|---|---|---|
| CONTEXT, “Evidence in context” | Evidence | all four | designed |
| CONTINUITY, “Work with continuity” | Plans | all four | designed |
| CONTINUITY, “Work with continuity” | Progress | all four | designed |
| RECORD, “Decisions with a record” | Review | all four | designed |
No pillar has a live product. Every product is designed: the routes, records and screens exist as an
intended workflow against the contract, and nothing is deployed on any host. The status word changes only
through the product catalog.
The pillar titles are the brand kit’s three core messages verbatim. Pillar labels are single upper-case
words so they never collide with a product name or a stage title. Stage ids are lower-case and never
change; their titles (Discovery, Preclinical development, Clinical development, Manufacturing planning)
may be reworded without a migration. Every scoped record stores one stage_id, defaulting to the
program’s current_stage_id, so a finding made during preclinical work is still marked preclinical when
the program has moved on.
Why this design
- Three pillars and not four: Plans and Progress both express continuity (a plan that becomes protocols, experiments and reports; milestones and approvals that carry the program forward), so they share one pillar rather than each inventing a message.
- Stages as a fixed lifecycle and not a six-step research workflow: the brief tracks whole programs, and a program-level lifecycle is what leads and manufacturing specialists plan against. Per-experiment workflow lives inside Plans instead.
- Products cover all four stages: evidence, plans, reviews and milestones exist in every stage, so restricting a product to some stages would only hide records.
- The fourth product was first proposed as “Programs” and renamed Progress before any route existed, because the tenant scope is the program (ADR 0002, ADR 0003).
Consequences and limits
- The web rail lists products, not pillars; pillars appear in positioning and on this site only.
- A stage badge is informational; changing a program’s current stage does not move or lock records.
- The brand line “Evidence -> Plans -> Review -> Progress” is a reading order, not a state machine: a program uses all four at once.
Related
- Products for the table the code uses.
- About programs for the scope that holds the records.
- ADR 0002 for the decision.