> In a future state, we've talked about rendering a snapshot of the report and checking that into version control, so that even if your underlying data is a mov

> In a future state, we've talked about rendering a snapshot of the report and checking that into version control, so that even if your underlying data is a moving target, you can hold onto what the report looked like at a moment in time. > We're kind of mixed on that idea of snapshotting reports themselves though, Right. In terms of a code-oriented version control service like GitHub, you shouldn't be checking in the rendered reports unless you want people modifying them directly (and they will) and submitting PRs. Instead, consider attaching the generated report artifacts as releases* associated with a tag (or possibly a branch) in the version-controlled source, and you get a few helpful conventions and affordances. OTOH, you are then sort of constrained to reviewing a release (or release candidate) with the built-in functionality only in the unrendered-but-version-controlled source, which probably isn't what you want.