The task | A run that succeeds | A run that fails, and its retry | What you need to know when you write a task

Setup | A run in one diagram | A plan is one data pull | Analyses iterate within a plan | Only the first and the last plan run in a fixed order | A forked worker MUST NOT inherit an open connection | A task reads cores when it runs | A task builds its plans once per run | A completeness check covers every declared partition | plnr::expand_list() makes one argset per element | Size a plan by its data pull

The two environments | Which variable each backend reads | What check_environment_setup() asks for | Setting the variables from another package | Which one to use

Start here: SQLite, with no server | What SQLite does not need | cs9example needs no .Renviron at all | Which backend to use | Installation options | CRAN installation (limited functionality) | Full installation (database-driven surveillance) | Database setup | PostgreSQL installation | Option 1: Docker (recommended) | Option 2: System installation | Database schema setup | Environment variable configuration | Setting up .Renviron | Variable descriptions | Package behavior without database configuration | Docker | Apache Airflow Integration | Airflow scheduling pattern | Benefits of Airflow + CS9 | Docker Compose with Airflow | Moving from CRAN to full setup | Verification and troubleshooting | Verify your setup | Common issues | Next steps

Setup | Per-unit rebuild | Staged import | Per-plan staged swap | Staging as a checkpoint | Fit then fill | Export from a finished table | Notify after export | Three rules

Overview | Prerequisites | Step 1: Initialize a surveillance system | Step 2: Define database tables | Step 3: Implement task functions | Data selector function | Action function | Step 4: Configure the task | Step 5: Execute the task | Step 6: Monitor and debug tasks | Advanced task features | Parallel processing | Dynamic plan generation | Best practices | Error handling | Data validation | Modular design | Summary | See also

Two configurations | The same table against each | What differs | Why the field types are closed | Why the primary key cannot be added later | Which one to choose

Single-function plan | Many strata | Many variables | Multi-function plan

Core concepts | A first plan | Data | Function names | Debugging

Starting from the example package | 00_env_and_namespace.R | 01_definitions.R | 02_surveillance_systems.R | 03_tables.R | 04_tasks.R | 05_deliverables.R | 10_onLoad.R | 11_onAttach.R | Task files | weather_download_and_import_rawdata.R | weather_clean_data.R | weather_export_weather_plots.R | Notes | Next steps

What csdata is for | Two current limitations | Where csdata sits, and what to read next | Location | Ages | Sex

National trend | Reference tables

Why org? | Installation | Quick start | Concept | Code requirements | Results requirements | Data requirements | Project structure | Core components | 1. org::initialize_project | 2. Run.R | 3. R/ directory | Example project structure | Research article versioning | Team collaboration | Best practices | Recommended structure | Alternative structures | RMarkdown project | Single folder project | Path naming conventions | Function reference | Core functions | File operations | Common workflows | Setting up a new analysis | Working with existing projects | Environment management | Path construction and cross-platform compatibility | Troubleshooting | Common issues | Path issues | Sourcing problems | Getting help

What csdb is for | What this vignette does and does not prove | Two classes, and the split between them | The validators, and one gap | The three backends | Where csdb sits | A worked example | Who owns the connection | A connection does not survive a fork | Two tables that declare one index name | Emptying a table before you write to it | The upsert method answers the same four cases

A worked example | Step 1: install a base table | Step 2: apply root-level exclusions | Step 3: branch into sub-cohorts | The freeze rule | Step 4: derive cached artifacts | Step 5: inspect the cohort tree | Step 6: hand off downstream | Schemas | CONSORT diagrams | How the cache decides what to recompute | Mutation contract (summary) | Performance notes

The problem: scaling epidemiological analysis | NorSySS: a decade of operation | CS9 vs alternatives | What is CS9? | When to use CS9 | What CS9 does not decide for you | Key concepts and definitions | Surveillance system architecture | Example workflow | Plan-heavy or analysis-heavy tasks? | Other vignettes | Example | Surveillance system setup | Database table definition | Task configuration | for_each_plan | plnr::expand_list | for_each_analysis | universal_argset | upsert_at_end_of_each_plan | insert_at_end_of_each_plan | action_fn_name | data_selector_fn_name | schema | data_selector_fn | action_fn | Run the task | Common task patterns | Importing data | Analysis | Exporting multiple sets of results | Exporting combined results | Deployment | What the framework handles for you | Getting started | Next steps

Overview | Themes | Color palettes | Number formatting | Norwegian number format | Date formatting | Norwegian date format | Journal formatting | Number format comparison | Date format comparison | Log scale transformations | Utility functions | Pretty breaks | Every nth label | Further reading