R Markdown Template: Keep the Data, Calculation, and Interpretation Together

Changing a count in a report is risky when the table updates but the summary sentence still says the old total. Put the source data and calculations in the Rmd document, and derive the sentence from the same objects.

Re-render the native source before treating the output as current.

Keep the report and its source together
Keep the report and its source together
Open the full example ↗

Copy an original report skeleton

This fictional report asks how many workshop check-ins were recorded across three sessions. Counts 8, 12, and 10 are supplied demonstration inputs, not attendance evidence about real people. The manually checked expected total is 30 and the expected mean is 10; the source below has not been executed in this writing stage.

Save the following text as a native checkins.Rmd in your own report project. It includes YAML document settings, R chunks, and inline calculated values. The institutional R Markdown example illustrates the combination of prose, code, and output; this small count report is independently written.

---
title: "Workshop check-in report — fictional example"
output:
  html_document:
    self_contained: true
---

# Question and source

How many check-ins were recorded across the supplied sessions?
Source: original fictional demonstration counts, not unique-person data.

```{r data}
checkins <- data.frame(
  session = c("Session 1", "Session 2", "Session 3"),
  count = c(8, 12, 10)
)
stopifnot(is.numeric(checkins$count), !anyNA(checkins$count),
          all(checkins$count >= 0))
```

```{r summary}
total_checkins <- sum(checkins$count)
session_count <- nrow(checkins)
mean_checkins <- mean(checkins$count)
knitr::kable(checkins, caption = "Fictional session check-in counts")
```

# Interpretation

The supplied data contain `r total_checkins` check-ins across
`r session_count` sessions, with a mean of `r mean_checkins` per session.
These counts do not establish unique participants or an attendance rate.

# Open questions

- How were check-ins recorded and checked?
- Can one person appear in more than one session count?
- What denominator would an attendance-rate question require?

The validation rejects missing or negative counts instead of silently dropping them. Add integer-count and duplicate-session checks if those are requirements of your actual data. Do not infer that a file passing these checks has trustworthy source data.

Re-render after changing the source

Use the actual R/rmarkdown toolchain available in your project. The official render reference documents rendering an R Markdown input. In an environment with the required dependencies already available, the intended command is:

rmarkdown::render("checkins.Rmd")

Record the R and package versions and any dependency/render errors from your actual run. This article does not install packages or claim a successful render. PDF and Word outputs need their own settings and dependencies; do not rename the HTML file to satisfy a required output format.

For a fourth session, add the label and count 6 to the same data source and re-render. The manually checked expectations become 36 total and 9 per session. Inspect the table, total, mean, and prose together. An HTML view toggle cannot execute R or repair an output left stale by a missing re-render.

Turn the skeleton into a reusable template when needed

The official draft reference describes filesystem/package templates with template.yaml and skeleton/skeleton.Rmd, plus optional supporting files. Put this original skeleton in that structure only when you need the template-creation workflow. Keep source and supporting inputs in the project so the output's origin remains inspectable.

Prompt for your own computational report

Draft an original R Markdown report skeleton in US English.
Question and intended output format: [inputs]
Supplied data, units, source/provenance and missing-value policy: [inputs]
R/package environment actually available: [inputs or unknown]
Required calculations and interpretation limits: [inputs]

Return native Rmd text with YAML, visible data/validation chunks, derived table/summary objects, inline results and open assumptions. Derive prose from the same objects as the table. Mark manually checked expectations separately from executed output. Include a change-and-re-render check that reveals stale prose, and record required dependencies without claiming installation or successful execution.
Do not invent source data, unique-person counts, denominators, run logs or package versions. Mark gaps [NEEDED: input]. Preserve required HTML/PDF/Word output and native Rmd authority. Any HTML review controls are reading aids, never R execution or live source updates.

Re-render the Rmd in your project, compare the output with the supplied rows, and keep the actual run evidence beside the source. Treat the report as current only when its table and interpretation come from the version you intend to share.

Optional: review verified HTML output in NOS

If your actual toolchain produces a verified self-contained HTML report, NOS can save and render that output for presentation review. Keep the Rmd, supporting files, and execution record in the report project; NOS is not the R execution or knitting step.

Explore NOS

Keep reading