# Research implementation kit Use these four working aids to move from a research question and protocol to an implementable, reviewable specification. They complement the [protocol templates](https://rwednesdays.com/table-shells.html#protocol-templates), [AMCP dossier templates](https://rwednesdays.com/table-shells.html#amcp-dossiers), and [table shells](https://rwednesdays.com/table-shells.html). They are original RWEdnesdays editorial tools, not official forms or validated approval instruments. ## Choose the next artifact | Starting point | Use | Expected result | | --- | --- | --- | | A protocol with scientific objectives | Protocol to SAP handoff | Traceable estimands, analysis specifications, diagnostics, sensitivity analyses and output shells | | Trials or studies proposed for comparison | ITC feasibility workbook | Evidence inventory, compatibility assessment, unresolved limitations and a human feasibility decision | | A proposed dossier statement | Dossier claim evidence matrix | Trace from exact wording to evidence, limitations, lifecycle status and review records | | A design and an actual claims data dictionary | Claims implementation worksheet | Field definitions, temporal rules, episode algorithms and synthetic expected-result cases | Start with one module. Link modules using the record IDs when the work requires them. An ITC may need a separate synthesis protocol; a dossier claim may rely on an ITC feasibility assessment; a claims study needs its field rules linked to the SAP and phenotype evidence. ## Use directly 1. Save a project copy and record its title, owner, version, evidence cut-off and source documents. Keep the downloaded original as a reference. 2. Read the module instructions and synthetic example. Examples illustrate a format or decision; they are not default settings or real evidence. 3. Enter the actual study information into the working records. Preserve stable IDs when sorting or adding rows. Keep unknown fields blank or explicitly unresolved, with an owner and next action. 4. Link each scientific statement or design choice to its source or human decision. Record a precise page, section, table or field location where possible. 5. Obtain the relevant scientific, statistical, data and organizational review. A populated template or a zero count of open rows does not establish approval. Word files are useful for the narrative and approval package. Excel workbooks support repeated records for ITC, dossier evidence and claims implementation. Markdown is the portable source format. The templates are starting specifications; extend them when the design requires more detail. ## Use with a frontier model Keep the entire extracted folder together. Supply the selected Markdown template, the matching build prompt, your authorized study brief and the relevant evidence or dictionary. A model supporting folder-based skills can read `SKILL.md`; other models can use the prompt directly. The kit does not install or configure itself. For a first message, use: > Read the kit instructions and the selected module. Use the supplied brief and source documents to build a reviewable draft. Preserve unresolved decisions and ask only questions that change the scientific or implementation plan. Return the artifact, source ledger, open-decision log and cross-reference check. Do not treat synthetic examples as study facts. Run the corresponding review prompt against the actual completed draft and sources in a separate context. Review should identify concrete problems, their consequences, and the exact evidence or decision needed to resolve them. Retain the human review record after corrections. ## Related working records - [Data fitness and observability](https://rwednesdays.com/assets/downloads/rwe-analysis-data-fitness-assessment.md) - [Phenotype validation evidence matrix](https://rwednesdays.com/assets/downloads/rwe-phenotype-validation-evidence-matrix.md) - [Protocol and SAP deviation log](https://rwednesdays.com/assets/downloads/rwe-protocol-sap-deviation-log.md) Check the current official guidance and the actual receiving organization's requirements. A source ledger documents what was checked; it does not replace a source review or confer permission to share confidential material.