Infrastructure

REDCap · MySQL · Apache/SSL · Postfix · cron · API export
The data-collection stack behind the six-wave longitudinal study.

---

1. Server Stack

The lead researcher built the stack from bare university VMs. The university had no centrally managed REDCap instance. Two dedicated VMs formed a split web/database architecture on the university network:

Setup tasks. MySQL installation and secure configuration (mysql_secure_installation, dedicated user, remote bind, privilege scoping), Apache virtual-host and SSL certificate installation, PHP module setup (php-mysql, php-curl, php-gd, php-zip, php-mbstring, php-xml), REDCap database table creation via SQL, Postfix email relay, cron job, and a custom email-validation rule restricting registration to the university domain.

Security configuration. REDCap Control Centre: Send-It disabled, draft-mode auto-approval set to Never, non-admin users cannot create projects or modify events, survey response editing disabled, repeatable instruments locked.

Retained evidence. A complete database backup and server configuration archive were preserved at the end of the study. Python scripts parse the backup offline, enabling reproducible evidence extraction without a running database instance.

SSL and transport security

TLS 1.3 only (all older protocols disabled). OCSP stapling enabled. HttpOnly and Secure flags enforced on all cookies. Directory indexing disabled. Certificates issued by university IT Security with auto-renewal.

Scheduled tasks

A minute-frequency cron job drives REDCap’s automated survey invitations, reminders, and link expiry.

Database isolation

Separate web and database VMs connected over the university internal network. The application used a dedicated, scoped MySQL user with minimum-privilege access to a single study database. A de-identification salt was configured for REDCap’s internal hashing.

Network isolation

The database VM had no public-facing ports. MySQL accepted connections only from the web server, enforced by both bind-address configuration and host-level firewall rules. The application database user held minimum-privilege access (no schema modification, no administrative rights). SSH access was restricted to the university network. HTTP traffic was forced to HTTPS via redirect.

REDCap Control Centre hardening

Key security settings: non-admin users cannot create projects, draft-mode changes require admin approval, file-sharing (Send-It) disabled, API enabled for controlled data export, survey links shortened via REDCap’s built-in shortener.

---

2. Two-Project Model

The study used two linked REDCap projects with role-based access separation:

After baseline collection, the researcher exported all responses and erased the baseline project data from REDCap. The follow-up project was rebuilt from exported instrument ZIP files, preserving survey design without carrying forward participant records.

The PIS portal served as the consent gateway (1 form, 17 fields). The baseline project collected data across 28 instruments covering consent, alcohol measures, email validation, incentive distribution, referral management, and identification-key operations. The follow-up project collected five waves of data (waves 2–6) across 8 instruments including friend-nomination forms with 10 per-friend survey pages.

---

3. Identity Separation

The core design problem: participants must see names to nominate peers, but the analyst must not access those names.

The identity manager generated six-digit random identifiers in Excel (RANDBETWEEN) and loaded the resulting roster into the follow-up project, linking names to pseudonymous IDs.

When participants nominated up to 10 important peers by name (via dropdown), REDCap’s @HIDDEN-SURVEY and @HIDDEN-FORM action tags separated what participants saw from what the system recorded:

A calculated field converted each name selection to its coded ID. The researcher could export de-identified data only: no free text, no dates, no identifier fields, no access to reports or the design interface after initial setup.

No team member simultaneously held export access and the identity key.

Identity-key fields (suffixed _ik) are systematically hidden from the survey view and marked read-only, confirming the separation is enforced at the field level, not merely by convention.

Calculated fields for pseudonymised linkage

The follow-up project contains 21 calculated fields in the friend_nomination instrument. Ten fields convert name-dropdown selections to numeric IDs. A further 10 detect duplicate nominations using conditional logic, with an aggregating error-check flag. A friend_number field counts valid nominations per respondent.

---

4. Recruitment Operations

Recruitment ran in two phases with daily response tracking.

Follow-up waves (2–6) used unique non-forwardable survey links emailed via REDCap’s participant list. Up to three reminder emails per wave.

An anonymous enquiry portal stayed open throughout data collection. Participants could raise concerns without identifying themselves.

The follow-up project contains five longitudinal events (one per wave), each linking the same core instruments: alcohol use, friend nomination, per-friend perception pages, and incentive delivery. Combined with the baseline project (single event), the study covers six longitudinal time-points.

---

5. Incentive Automation

£10 Amazon eGift Card per completed survey. From Wave 2 onward, codes were delivered automatically at survey completion via the REDCap randomisation module:

• Amazon eGift Card codes pre-loaded into the REDCap randomisation table
• On submission, REDCap assigned the next available code and emailed it to the participant
• No manual matching of names to completion status required

Additional incentives: £10 bonus for completing all six waves, £500 prize draw at study end, £10 per successful referral for the referrer, £5 bonus for each referred participant.

---

6. Database Schema

The archived REDCap database preserves the full relational schema:

External modules installed

---

7. Field-Level Engineering

The follow-up project demonstrates the complexity of sociometric data collection at the field level:

Validation types (follow-up project)

The baseline project adds 5 validated fields: 2 alpha_only (name fields), 1 email, 1 float, 1 int.

Branching logic: sociometric nomination cascade

The follow-up project’s 151 branching rules implement a cascading survey design where each nominated friend generates a personalised block of perception questions:

The logic follows a three-layer pattern:

# Layer 1: Show descriptive-norm question only if friend N was nominated
# and is not a duplicate (error check passed)
deno1_friend_3: [friend3]<>"" and [error3]=0

# Layer 2: Show frequency question only if friend was nominated
# AND respondent rated them as drinking "sometimes" or more
deno2_friend_3: [friend3]<>"" and [error3]=0 and [deno1_friend_3]>1

# Layer 3: Cross-wave confirmation — show friend only if they
# appeared in the previous wave's nomination list
friend3_confirm: [previous-event-name][friend3:value]>1

This pattern repeats for friends 1–10 across four norm dimensions (descriptive frequency, descriptive quantity, injunctive approval, injunctive quantity), yielding the 151 branching rules. Fields with [previous-event-name] references demonstrate REDCap’s longitudinal piping: values carry forward from wave to wave without re-entry.

Duplicate-nomination detection

# Calculated field: flag if friend5 duplicates any earlier nomination
error5 = if(([friend5]<>"" and ([friend5]=[friend4] or
  [friend5]=[friend3] or [friend5]=[friend2] or [friend5]=[friend1])),1,0)

# Aggregate: total number of flagged duplicates
error_check = [error2]+[error3]+[error4]+[error5]+[error6]+
  [error7]+[error8]+[error9]+[error10]

If error_check > 0, the respondent is prompted to correct their nomination. This is automated data-quality enforcement at the instrument level.

---

8. Export Boundary

The researcher exported follow-up data via REDCap’s API. De-identification settings stripped free-text fields, date/time fields, and identifier fields before delivery.

The staged export (list_by_wave.RData) is the single input to the reproduction pipeline. Everything upstream belongs to the data-collection infrastructure; everything downstream belongs to the analysis pipeline documented in the Pipeline tab.

---

9. Design Decisions

Each choice below resolves a tension specific to sociometric data collection.

---

10. Role-Based Access Control

User rights were configured so that no team member simultaneously held export access and identity-key access. Named roles enforced the separation:

Five distinct role definitions were created across the two projects: Project Manager, Validation Officer, Super User, Identification Code Manager, and Amazon Code Manager. The identity manager had no export access; the researcher had no access to the identity-key instruments.

---

11. Audit Trail

REDCap logs every action to numbered redcap_log_event tables. The study’s audit trail covers survey submissions, record operations, user logins, role changes, and configuration updates across the full data-collection period (August 2022–September 2024). This trail is preserved in the archived backup and is available for institutional review.

---

12. Backup & Evidence Verification

A complete database backup and application archive were extracted from the production servers at the end of the study. The backup preserves the relational schema, project metadata, instrument definitions, and operational configuration needed to verify claims made in this documentation.

Automated evidence extraction

Python scripts parse the database backup offline as a text stream, extracting project structure, instrument definitions, action-tag usage, calculated fields, role definitions, event configuration, and survey settings. No running database instance is required. A single pass completes in under 2 seconds. Numeric claims in this tab were verified against these scripts.

python3 extract_projects.py          # project inventory
python3 extract_evidence.py           # instrument and role extraction
python3 generate_data_dictionaries.py # portable data dictionaries

---

13. Reproduction Guide

A researcher with no prior REDCap experience can recreate the study infrastructure from the portable files in presentation/portable/. These files contain only project structure (instruments, fields, logic, action tags) and zero participant data.

Portable artefacts

Generated by python3 presentation/generate_data_dictionaries.py, which parses the database backup without requiring MySQL.

Prerequisites

• REDCap licence — register at projectredcap.org and download the source. REDCap is free for non-commercial use but requires institutional agreement.
• Docker — any machine with Docker Desktop or Docker Engine. No other software required.

Step 1: Start a local REDCap instance

A Docker Compose config is provided in presentation/redcap-docker/:

cd presentation/redcap-docker/redcap-docker/

# Place REDCap source so that data/redcap/index.php exists
cp -r /path/to/redcap-source/* data/redcap/

docker compose up -d
# Wait ~30s for MySQL, then open http://localhost:8080

The container runs Apache + PHP + MySQL in an isolated network. No data leaves the machine. No email is sent.

Step 2: Create the baseline project

1. Log in (the DZD container creates a site_admin on first boot)
2. New Project → name it “TFS Baseline” → Classic project
3. Project Setup → Data Dictionary → Upload baseline_data_dictionary.csv
4. REDCap recreates all 28 instruments, 231 fields, 56 branching rules, 61 required-field constraints, 34 @DEFAULT tags, 14 @HIDDEN-SURVEY tags, and 37 @READONLY tags from the CSV alone

Step 3: Create the follow-up project

1. New Project → name it “TFS Follow-up” → Longitudinal project
2. Project Setup → Define My Events → create five events matching followup_events.csv:

   wave2  day_offset=1
   wave3  day_offset=2
   wave4  day_offset=3
   wave5  day_offset=4
   wave6  day_offset=5

3. Data Dictionary → Upload followup_data_dictionary.csv
4. Designate Instruments for My Events → assign forms per the forms column in followup_events.csv

This recreates the full sociometric instrument with 239 fields, 151 branching rules, cascading friend-nomination logic, duplicate-detection calculated fields, and all action tags.

Step 4: Verify

Step 5: Explore the survey design

Navigate the Online Designer to see the instruments as they appeared to participants and researchers:

• friend_nomination (64 fields) — dropdown selection of up to 10 peers, with friendid1–friendid10 calculated fields converting names to pseudonymous IDs
• friend1 (96 fields) — per-friend perception questions with three-layer branching cascade (show question → show follow-up → cross-wave confirmation)
• alcohol_use (45 fields) — AUDIT-C screening with [q1]>1 skip logic gating the B-YAACQ consequences section
• consent_form (41 fields, baseline) — 17 radio-button consent items, text fields for names and signatures, @TODAY timestamp

What the portable files do not contain

• Participant data (records, responses, timestamps)
• User accounts, roles, or access rights (set up manually per Section 10)
• Randomisation allocations (Amazon eGift Card codes; load separately)
• Survey configuration (titles, email templates, auto-continue settings)
• External modules (install giftcard_reward, auto_populate_fields, unique_actiontag, shazam, record_autonumber from the REDCap module repository)

These limitations are deliberate: participant data is confidential, and operational settings depend on the deployment context.

---

14. Infrastructure Limitations

Pipeline

Chapters 4–7. Make-orchestrated, config-driven.
Paths, toggles, and seeds live in reproduced/config/thesis.yml.

---

1. Architecture

---

2. Directory Structure

SAND/
├── Makefile                         Top-level proxy to reproduced/Makefile
├── Dockerfile                       Optional container build
├── LICENSE                          MIT (code) + CC BY 4.0 (docs)
├── CITATION.cff                     Citation metadata
├── README.md                        Entry point with findings and quick start
├── DATA_AVAILABILITY.md             What is public, protected, and synthetic
├── SECURITY.md                      Credential and vulnerability reporting
├── CONTRIBUTING.md                  Contribution workflow
├── CHANGELOG.md                     Release history
│
├── docs/
│   ├── reference.html               This file
│   └── readme-assets/               SVG figures for README
│
└── reproduced/                      The reproduction workspace
    ├── Makefile                      Build contract (all targets)
    ├── .Rprofile                     renv activation and library precedence
    ├── renv.lock                     90-package R dependency lock
    ├── environment.yml               Conda environment specification
    ├── REPRODUCIBLE_PIPELINE.md      Canonical build contract
    ├── README.md                     Pipeline entry point
    │
    ├── config/
    │   ├── thesis.yml                Single source of truth
    │   └── scenarios/
    │       └── saom_models.yml       SAOM model specifications
    │
    ├── data/
    │   ├── raw/                      Protected real data (staged locally, never committed)
    │   │   └── README.md
    │   ├── proxy/                    Synthetic structure-compatible data
    │   │   └── list_by_wave_schema.csv
    │   └── vendor/
    │       └── rsiena/               Pinned RSiena 1.4.7 source tarball
    │
    ├── analyses/
    │   ├── chapter4_data_collection/scripts/
    │   ├── chapter5_descriptive_norms/scripts/
    │   ├── chapter6_injunctive_norms/scripts/
    │   ├── chapter7_saom/scripts/
    │   └── chapter8_interventions/scripts/
    │
    ├── scripts/
    │   ├── 00_setup/                 Environment, proxy generation, verification, release
    │   ├── portfolio/                Data dictionary, privacy guard, dashboard
    │   ├── visualisation/            Network explorers, microstep animation
    │   └── utils/                    YAML loader, helpers
    │
    ├── tests/
    │   ├── test_verify_outputs.py    Verifier unit tests
    │   ├── test_build_public_release.py  Release-builder tests
    │   └── portfolio/testthat/       R portfolio test suite
    │
    ├── docs/
    │   ├── README.md                 Documentation hub
    │   ├── references/               Stable background: crosswalk, config guide, etc.
    │   ├── portfolio/                Public-facing study book, case study, findings
    │   ├── roadmaps/                 Canonical execution plan
    │   ├── status/                   Release audit and verification records
    │   └── decisions/                Architectural decision records
    │
    ├── outputs/                      Generated (gitignored)
    │   ├── chapter4/ ... chapter7/
    │   └── portfolio/
    │
    └── R/                            Shared R utilities

---

3. Configuration

Scripts read paths and toggles from reproduced/config/thesis.yml. Hardcoded paths in analysis code are bugs.

3.1 Key Config Paths

---

4. Data Modes

Priority: SAND_DATA_MODE env var overrides data.mode in thesis.yml.

Proxy data share the schema but contain no participant information. They are synthetic, not anonymised.

4.1 Proxy Data Generator

The script scripts/00_setup/create_realistic_proxy_data.R produces a deterministic synthetic dataset. Fixed seed: 20250921.

The generator produces list_by_wave.RData, participants.csv, outcomes.csv, a schema file, and a JSON generation report. Network ties, alcohol scores, and norm perceptions follow study-level design parameters; they do not transform, perturb, or anonymise real participant data.

---

5. Quick Start

5.1 Proxy Mode (no real data required)

make env                 # bootstrap Conda + renv + RSiena 1.4.7
make verify-proxy-quick  # regenerate proxy data, run Chapters 4-6

# Full path including Chapter 7 (~2 hours):
make verify-proxy

5.2 Real Data Mode

make env

# Stage required files:
#   reproduced/data/raw/list_by_wave.RData  (required)
#   reproduced/data/raw/participants.csv    (optional)
#   reproduced/data/raw/outcomes.csv        (optional)

make verify-real  # Chapters 4-7 plus empirical benchmarks

---

6. Chapter Walkthrough

6.1 Chapter 4: Data Preparation & QA

Method: Data extraction from REDCap exports, participation coverage, quality-assurance checks, imputation, network array construction.

Scripts (executed sequentially by make chapter4)

• 01_data_preparation_norms.R — Load list_by_wave.RData. Reshape wave-level survey responses into a longitudinal panel. Compute peer-level actual and perceived norms, derive misperception measures, apply LOCF imputation where configured.
• 02_qa_checks_norms.R — Participation counts per wave, nomination volume diagnostics, out-of-range value detection, Jaccard stability indices.
• 03_export_norms_longitudinal.R — Write the analysis-ready longitudinal dataset (norms_longitudinal.rds) and chapter manifest.
• 04_export_chapter5_bridge.R — Build directed network adjacency arrays aligned to SAOM waves. Export network_arrays.rds for Chapters 5–7.

Outputs

↓

6.2 Chapter 5: Descriptive Norms (NAM)

Method: Network Autocorrelation Models (sna::lnam()) across 3 time periods, quantifying how global and peer-level descriptive norm misperception relates to personal consumption.

Scripts

• 01_prepare_chapter5_data.R — Subset longitudinal data to Time 1/2/3 (Waves 2/5/6). Build NAM-compatible weight matrices from the network arrays.
• 02_estimate_nam_models.R — Fit NAM for each time period with the configured seed. Extract coefficients, standard errors, p-values.
• 03_generate_nam_figures.R — Coefficient comparison plots across time periods.
• 04_validate_nam_results.R — Compare estimated coefficients against thesis benchmarks. Proxy mode: warnings. Real-data mode: requires match within tolerance.
• 05_compare_nam_results.R — Side-by-side table: current vs. thesis vs. legacy October 2024 fits.

Outputs

↓

6.3 Chapter 6: Injunctive Norms (NAM)

Method: NAM across 3 approval scenarios (abstaining, binge drinking, passing out), testing whether injunctive norm misperception predicts consumption.

Scripts

• 01_prepare_approval_longitudinal.R — Build wave-level approval datasets for each scenario from the Chapter 4 manifest. Compute injunctive misperception measures.
• 02_analyze_injunctive_norms.R — Descriptive statistics and trend summaries for injunctive norm perceptions.
• 03_plot_injunctive_trends.R — Approval trajectory plots over time, stratified by scenario.
• 04_estimate_injunctive_nam_models.R — Fit NAM for each approval scenario. Extract coefficients and diagnostics.
• 05_validate_injunctive_results.R — Benchmark validation. Proxy mode: warnings for expected differences.

Outputs

↓

6.4 Chapter 7: Social Selection & Influence (SAOM)

Method: Stochastic Actor-Oriented Model (RSiena 1.4.7) jointly modelling network tie change and behaviour change across Waves 2, 4, 5, 6. Separates social selection from social influence.

Scripts

• 00_build_network_arrays_base.R — Build SAOM-compatible network arrays and behaviour vectors from Chapter 4 outputs. Align to thesis waves (2/4/5/6), build block and flat dyadic covariates from residence fields, extract baseline majority-status and sex covariates from Wave 1.
• 01_prepare_saom_inputs.R — Assemble the RSiena data object (sienaDataCreate): dependent network, dependent behaviour, constant/varying covariates, dyadic proximity covariates.
• 02_run_saom_model.R — Run siena07() with configured seed, n3, phase settings, Dolby correction. Write fitted object and text output. ~2h runtime.
• 03_generate_saom_tables_figures.R — Extract coefficient tables, goodness-of-fit diagnostics, summary figures from the fitted model.
• 04_validate_saom_results.R — Check convergence ratio (target ≤0.10), Jaccard indices, benchmark coefficients. Flag degenerate covariate effects.

Estimation parameters

Outputs

Runtime: ~2 hours on Apple M4 (10 cores). The fast CI gate covers Chapters 4–6 only; Chapter 7 is a separate manual or scheduled job.

6.5 Chapter 8: Interventions (Experimental)

Method: Counterfactual SAOM scenario simulations. Disabled by default (chapters.chapter8_interventions.enabled: false).

• 01_load_manifest_and_baseline.R — Loads the Chapter 7 fitted model as the baseline for intervention scenarios.
• 03_summarize_interventions.R — Aggregates simulation results across scenario batches.

Status: Scaffolding exists. Not part of the verified release. 462 scenarios × 3 chained periods.

---

7. Thesis-to-Code Crosswalk

Mapping from thesis chapter claims to the scripts and output files that produce them.

Abbreviated paths: chapter4/.../ means analyses/chapter4_data_collection/scripts/. All outputs land in reproduced/outputs/.

---

8. Verification

Proxy runs test execution and artefact structure; empirical differences are warnings, not failures. Real-data runs enforce chapter benchmarks.

---

9. Setup & Tooling Scripts

Under reproduced/scripts/, outside the chapter analysis directories.

00_setup/ — Environment and release

• install_r_packages.R — Restore the renv library from renv.lock into the project-local directory.
• install_rsiena.R — Download, compile, install exact RSiena 1.4.7 from the CRAN Archive tarball. Validate the installed version.
• create_realistic_proxy_data.R — Deterministic synthetic data generator. 255 students × 6 waves with network ties, alcohol scores, norm perceptions, residence structure. Seed: 20250921.
• validate_config.py — Check thesis.yml for required keys, valid types, path existence.
• verify_outputs.py — Mode-aware output verifier. Proxy: structural checks, empirical-difference warnings. Real: benchmark enforcement.
• build_public_release.py — Build a history-free release candidate. Scan for secrets, local paths, protected data paths, oversized files.
• generate_data_hashes.py — Compute SHA-256 hashes for staged data files.
• docker_smoke_test.R — Minimal R test for Docker container verification.

portfolio/ — Public documentation generators

• generate_data_dictionary.R — Generate a Markdown data dictionary from the proxy schema.
• generate_repro_manifest.R — Produce a reproducibility manifest: tracked scripts, configs, checksums.
• generate_validation_dashboard.R — HTML dashboard: proxy vs. empirical results per chapter.
• check_privacy.R — Scan generated Markdown/HTML for participant identifiers, real network data, missing synthetic labels.

visualisation/ — Network outputs

• 05_interactive_networks.R — Standalone HTML network explorers (one per SAOM wave) via visNetwork. Provenance labels and synthetic/real-data markers embedded in the output.
• 04_animate_microsteps.R — Optional SAOM microstep animation. Requires networkDynamic/ndtv.
• plot_network_panel.R / plot_network_stability.R — Static network and Jaccard stability plots.

---

10. Make Targets

---

11. Common Failure Modes

Release

Release status and contract. Scope, provenance, data restrictions, environment, validation, and limitations must all be inspectable.

---

1. Verification Status

Verified on 14 July 2026 · macOS 15.6 (arm64) · Apple M4 · R 4.3.2 · RSiena 1.4.7

---

2. Environment

2.1 Conda

Defined in reproduced/environment.yml. Key pins:

2.2 renv

reproduced/renv.lock locks 90 R packages with concrete version pins and hashes. The lock was regenerated from the maintained Chapters 4–7 source tree.

2.3 RSiena

Pinned to exact version 1.4.7 from the CRAN Archive. The installer downloads the source tarball to data/vendor/rsiena/, compiles it, and installs to the project-local .Rlib/ directory. A regression check confirms the activated version matches. The global R library may contain a newer RSiena; the project .Rprofile ensures the local 1.4.7 takes precedence.

2.4 Docker

Dockerfile builds a self-contained image. Not yet verified in the current release cycle.

---

3. Data Availability

Public: Analysis code, configuration, environment definitions, documentation, schema inventory, synthetic proxy-data generator.

Protected: Participant data. Longitudinal alcohol-use, demographic, residential, and network information. Pseudonymisation does not remove disclosure risk from a bounded social graph with repeated measurements. Not distributed.

Synthetic proxy: Generated by make proxy-data. Uses study-level design parameters to exercise the pipeline. Does not transform, perturb, or anonymise participant rows. Not suitable for substantive inference.

Aggregate results: README figures and tables were cross-checked against thesis Chapters 4–7 on 13 July 2026 (source cross-check, not a fresh protected-data run).

Access: No public access procedure. Future requests must follow institutional governance.

---

4. Release Contract

Included: Chapters 4–7 pipeline, real/proxy data modes, synthetic data generator, schema documentation, environment locks, thesis-to-code crosswalk, tests, validation reports, citation/contribution/security/data-availability documents, confirmed licence, release manifest.

Excluded: participant data, credentials, private Git history, project-management files, agent instructions, personal notes, unvalidated Chapter 8 claims.

4.1 Current Gates

4.2 Interpretation Rule

A proxy run proves the software executes on synthetic inputs. It does not prove proxy estimates match thesis results. A real-data run proves agreement with recorded empirical benchmarks, subject to stated tolerances. Release documentation keeps these claims separate.

---

5. License & Citation

Code: MIT License © 2025 Shangshang Gu

Documentation & diagrams: CC BY 4.0

Data: Not distributed. Synthetic proxy data are covered by the MIT License.

See LICENSE for full text and CITATION.cff for machine-readable citation metadata.

---

6. Reproduction Fidelity

On the thesis data, Chapters 5 and 6 reproduce every coefficient to 3 decimal places. Three code fixes were required to achieve exact match:

These fixes produce thesis-matching sample sizes (218/213/215 for Time 1/2/3) and exact agreement at 3dp.

6.1 Recorded Validation Targets

Machine-readable targets are stored in reproduced/docs/references/quan_results.md and consumed by each chapter’s validation script. Proxy runs cannot reproduce these values because synthetic inputs have different distributions; the verifier issues warnings rather than failures.

---

7. Verification Check Inventory

The verifier (scripts/00_setup/verify_outputs.py) runs 15 checks for a Chapters 4–6 proxy path, more when Chapter 7 is included.

Chapter 7 adds checks for network arrays, input manifest, run log, dyadic covariates (non-degenerate), fitted model file, and convergence ratio. Real-data runs also verify coefficient benchmarks.

---

8. Determinism & Platform Drift

Chapters 4–6 are deterministic for fixed inputs and configuration. Chapter 7 (SAOM) may show cross-platform numeric drift from BLAS/LAPACK and compiler differences, even with fixed seeds.

Roadmap

What has been completed and what comes next. Updated July 2026.

---

1. Completed

---

2. Next