Build the Stack for a Live Project
The stack is not a generic bibliography. It is a versioned set of decisions about what controls this document.
Step 1: fix the identity of the output
Write one line that names the document, subtype, evidence object, destination, jurisdiction, lifecycle stage, and primary audience. “Manuscript” is not specific enough. “Primary publication of a randomized phase III trial for a named journal” is much more useful. “Safety report” is not specific enough. Name the report, reporting period, product or study scope, and destination.
Step 2: inventory candidate sources
Search across the relevant layers:
- law and regulation;
- regional authority guidance;
- harmonized or technical standards;
- study-design reporting guidelines and extensions;
- publication ethics and good practice;
- target instructions and portal specifications;
- organizational procedures and controlled templates;
- clinical guidance needed as evidence.
Use the document-type deep dives to identify the likely families, then verify the actual project.
Step 3: test applicability
For every candidate source, ask:
- What kind of source is it?
- Who owns or issues it?
- Which jurisdiction, audience, product, study design, lifecycle stage, document, or submission does it cover?
- Is it final, draft, superseded, transitional, or otherwise limited?
- Which version and date apply to this project?
- Does an extension or companion source apply?
- Does the target explicitly require a declaration or checklist?
- Who can confirm an uncertain interpretation?
Mark the result applies, does not apply, applies in part, or decision pending. Add the reason. A list without applicability reasons becomes dangerous when copied to another project.
Step 4: extract document impact
Translate each applicable source into observable consequences:
| Impact area | What to extract |
|---|---|
| Document existence | Whether the output is required and at what event or stage |
| Structure | Mandatory or expected sections, order, headings, and cross-references |
| Content | Required questions, data, explanations, declarations, and appendices |
| Method | Search, analysis, appraisal, conduct, or user-testing expectations that must be reported |
| Terminology | Controlled names, definitions, coding, units, and preferred expressions |
| Presentation | Tables, figures, flow diagrams, precision, denominators, and formats |
| Process | Roles, author input, independent review, approvals, reconciliation, and sign-off |
| Metadata | Registry identifiers, product or study identifiers, dates, versions, contributor data, and disclosures |
| Submission | File types, forms, portal fields, validation, and timing |
| Traceability | Which claims, data, decisions, and changes must be recoverable |
Step 5: resolve overlap and conflict
Do not create one global hierarchy and assume it works everywhere. Classify the sources and resolve each overlap in context.
- Confirm that both sources truly apply.
- Separate a direct conflict from a difference in detail or purpose.
- Identify the controlling legal, regulatory, contractual, or organizational owner within scope.
- Check whether the more specific source validly adds to the broader source.
- Surface the question to the responsible decision-maker.
- Record the decision, rationale, owner, and source versions.
- Update the outline, checklist, and review plan.
Never solve a governance conflict silently in the prose.
Step 6: make a compliance matrix
The smallest useful matrix has six columns:
| Requirement | Source and location | Applies because | Document location | Verification | Owner/status |
|---|---|---|---|---|---|
| A testable content or process requirement | Exact source anchor | Scope decision | Section, table, appendix, metadata, or workflow | How a reviewer can confirm it | Decision owner and state |
Keep requirements atomic. “Comply with CONSORT” is not testable. “State how the random allocation sequence was generated in Methods” is. A good matrix drives the outline and later becomes a focused QC instrument.
Step 7: preserve currency
At project start and before final delivery, confirm the version, status, links, target instructions, template, and relevant procedures. Save what governed the work. Record a review trigger when the project will run long enough for requirements to change.
The corpus is a learning source, not a currency service. Any named framework in this handbook is a route to verification, not proof that the project has the current version.