1. Start a session | 2. Tag your source datasets | Tagging multiple datasets | 3. Derive new variables | 4. Join datasets with lineage tracking | 5. Filter with mandatory exclusion reasons | 6. The session operation log | 7. End the session | 8. Complete minimal workflow | 9. Visualise the pipeline

Setup: a complete pipeline | Derive analysis variables | 1. lg_population(): documenting analysis sets | Multiple populations | What lg_population() records | print method | 2. lg_spec(): documenting variable derivations | Documenting flag derivations | Overwriting a spec | 3. lg_report(): generating the provenance report | In-memory report (inspect without writing to disk) | Write to file | Report arguments | 4. A note on CDISC-specific usage | 5. Visualise the pipeline lineage | 6. End the session

Setup: a realistic multi-stage pipeline | 1. lg_filter() in depth | Mandatory reason | reason_code: machine-readable classification | population: grouping exclusions by analysis set | 2. The exclusion registry | Filter by population | Filter by dataset | The exclusion record structure | 3. Disposition tables | Group by reason | Group by population | Group by dataset | 4. Subject tracing | Tracing an excluded subject | Tracing an included subject | Tracing a subject not found | Using the trace result programmatically | 5. The operation log | 6. Visualise exclusions as a lineage graph | 7. Common patterns | Cascaded filters with verbose tracking

1. Initialise a session | 2. Log actions | 3. Log field changes | 4. Log notes and decisions | 5. Logging data reads | Single reads with rl_read() | Scoped logging with with_log() | 6. Electronic signatures | 7. Verify chain integrity | 8. Query the log | 9. Convert to data frame | 10. Export the audit trail | 11. Entry type reference | 12. Validation (regulated environments) | Running the protocols | Capturing the qualification record | Requirements traceability | Logging the qualification itself | Re-qualification

1. Basic pattern | 2. User resolution | 3. Session lifecycle events | 4. Using regulog_observer() | 5. Notes and decisions from Shiny | 6. Logging data changes from Shiny | 7. Electronic signatures from Shiny | 8. Download handler for the audit trail | 9. Per-session vs shared log | Per-session (default) | Shared log across users | 10. Querying and verifying from outside the app | 11. Logging data reads from Shiny | 12. Complete minimal example

1. The genesis record | 2. How entries are hashed | 3. Verification | 4. What tampering looks like | 4a. Modifying an entry's content | 4b. Deleting an entry | 4c. Breaking the prev_hash directly | 5. What the chain does NOT protect against | 6. Verifying a file without a live session | 7. Working with persistent .rlog files | 8. The NDJSON format | 9. Archival and long-term storage | 10. Hash algorithm

How audit_script() detects calls | What gets skipped | Single-file vs directory scan | Version resolution | The audit_report object | How risk_score() works | Check 1: "changelog" — the breaking-changes database | Check 2: "seed_check" — missing set.seed() | Check 3: "locale_check" — locale-sensitive operations | Combining checks and filtering | Working with the results | Practical interpretation

The problem they solve — a real scenario | Scenario — The revision drift problem | certify() — creating a baseline | What gets hashed | Choosing what to certify | Tags and the certification store | list_certs() — inspecting the store | check_drift() — comparing against a baseline | Basic usage | The four statuses | Using "latest" | Using drift results programmatically | Recommended workflow | At submission | After reviewer comments | Version control

repro_report() — generating reports | The verdict | Style: "minimal" | Style: "academic" | Style: "pharma" | Format: "md" and "html" | All nine combinations | repro_badge() — status badges | Badge colours | Inserting into README.md | Removing a badge | Full CI pipeline

What is reproducr? | Why this matters — real failure modes | Scenario 1 — The collaborator upgrade problem | Scenario 2 — The server deployment problem | Scenario 3 — The renv false sense of security | Tier 1: Scan and score | Auditing a script | Scoring for risk | Tier 2: Baseline and drift detection | Certifying outputs | Checking for drift | Tier 3: Report and export | The full pipeline

What belongs in the database | Examples of things that belong | Examples of things that do not belong | The database schema | The version window | Rules for setting to_version | Quick reference | Risk levels | Finding candidates | From NEWS.md files | From your own experience | Writing an entry | Testing your entry | Submitting a pull request | Minimum test for a new entry | Keeping the database current