Overview & Architecture

EMA Forge is an open-source toolkit for building, deploying, and analyzing Ecological Momentary Assessment (EMA) and digital-phenotyping studies. It is end-to-end serverless: your study is compiled into a static web app, participants complete it in their mobile browser, and response data is generated, stored, and downloaded entirely on the participant's device.

There are three things you'll interact with as a researcher, and one thing your participants will interact with:

Why Serverless?

Traditional EMA platforms require standing up a backend server, authenticating users, and handling data-in-transit through a database that becomes a named component of every IRB protocol. The tradeoffs EMA Forge makes to avoid that:

• Zero backend infrastructure. Host on GitHub Pages, Netlify, Vercel, Cloudflare Pages, or any institutional static web server. No runtime, no DB, no SSL cert to renew.
• Data stays local until the participant hands it over. Response data is written to the participant's device as a file. You collect it via whatever channel your IRB has already approved for data return (secure email, REDCap upload, institutional SFTP, etc.).
• Offline-tolerant. Once the study app is loaded in the browser, it keeps functioning without network. Completed sessions queue locally and download when the participant taps "Save."
• Full transparency. Every line of runtime code is visible in the exported HTML. Reviewers, participants, and IRBs can inspect exactly what runs on a participant's device.

Tradeoffs to be honest about (see Known Limitations):

• There is no central "dashboard" of live enrollment — data is only visible once files are returned to the researcher.
• EMA Forge does not send notifications itself. You need an external scheduler/SMS service to deliver links at the right time. The beta Twilio dispatcher ships this gap (see Twilio Integration).
• The static host can see request metadata (IP, timestamp of page load). This is the same constraint as any web page — it's not a data transmission, but it's not nothing.

Feature Status Matrix

Keep this in front of you when planning a study. Anything marked BETA has shipped but hasn't yet been through external pilot validation; anything marked WIP or PLANNED is not yet usable.

System Requirements

For you (researcher)

• Any modern desktop browser. Chrome, Edge, Firefox, or Safari (from 2022 onward). The Builder and Dashboard run entirely in your browser at emaforge.keeganwhitacre.com.
• A way to host your exported study. GitHub Pages is the path of least resistance and free for researchers. Any institutional static-file server works too. (See Hosting Your Study — it is genuinely ten clicks.)
• A way to send participants links at the right times — an SMS service, institutional email scheduler, Twilio, or similar. EMA Forge generates the links; something else delivers them.
• R or Python (optional). The Dashboard handles most day-to-day compliance monitoring in the browser. You'll want R or Python for real analysis.

For participants

• iOS Safari 14.5+ or Chrome for Android 90+ (roughly anything from 2021 onward).
• For the HR / ePAT modules only: a rear-facing camera with a controllable torch (flashlight). All modern iPhones and most Android devices qualify; tablets without rear cameras do not. Desktop browsers will refuse to launch these modules.
• A working browser link. That's it — no app install, no account.

Quick Start — 5 minutes to a working pilot

You do not need to install anything. The Builder and Dashboard are hosted and ready to use.

1. Go to emaforge.keeganwhitacre.com and click Builder.
2. In the Study tab, name your study.
3. In Questions, click + Slider and add one mood item. Keep the default anchors.
4. In Schedule, set study length to 3 days and keep the default morning/afternoon/evening windows.
5. Click Export → Single HTML file. You'll get a file you can email to yourself.
6. Open that file on your phone with ?id=1&day=1&session=w1 appended. You're running a study.
7. When you finish the session, your phone downloads a CSV. Go back to emaforge.keeganwhitacre.com, open the Dashboard, import the folder, and you'll see your own compliance data.

That round trip tells you whether your device can open sessions and whether your data is landing where you expect. Always do this before enrolling a participant.

Study Tab

Global study configuration. Set here:

• Study name & institution — appears in participant app title and CSV metadata.
• Theme & accent color — OLED (pure black, recommended for battery), dark, or light. Accent color inherits into the participant app.
• Response format — CSV (one row per answered question) or JSON (full structured payload). Both are downloaded; JSON is always included when a session contains high-density signal data (PPG/ePAT).
• Webhook URL (optional) — if set, session data is auto-uploaded to this URL instead of being manually downloaded by the participant. See Auto-upload with Webhooks for setup.
• Greetings — per-window header text ("Good Morning", "Check-In", etc.).
• Completion lock & crash recovery — see Runtime Behavior.

Onboarding & Consent

The Onboarding flow runs exactly once per participant, on their first link (?id=N&session=onboarding, Day 0). It covers:

• A progress-barred multi-screen intro.
• A rich-text consent screen that requires scroll-to-bottom before the "I agree" checkbox activates. Consent text accepts HTML so you can paste in your IRB-approved language with headings.
• An optional schedule-sanity screen letting the participant confirm they'll be available during each window.
• For studies with ePAT enabled: a two-phase practice (tone-to-tone, then tone-to-heartbeat) before the real trials start.

If onboarding is disabled, Day 0 is skipped entirely and participants land directly in their first EMA window.

Questions Tab

The Questions tab is where you write your survey items. Each question appears as a card — click to expand it, drag to reorder. Changes show up live in the phone preview as you type.

Question types

Per-question settings

• Show In (Phase): whether this question appears pre-task, post-task, or both within a phase-sequenced window.
• Active Sessions: restrict the question to specific time windows (e.g. only morning).
• Required: blocks advancement until answered.
• Skip Logic: compound AND/OR conditions on any prior question. Operators: eq, neq, gt, gte, lt, lte, includes. When a condition evaluates false, the question is silently skipped and not recorded.
• Response piping: insert {{q_id}} in a later question's text to substitute the participant's prior answer. Useful for contextualizing follow-ups ("You said your mood was {{q1}}. What was the cause?").

Schedule & Phase Sequencing

A study consists of N days, each day containing K time windows, each window containing an ordered phase sequence of steps.

Days & windows

• Study length: 1–365 days.
• Days of week: restrict to weekdays only, etc.
• Windows: each has an ID, a display label, and a start/end time. The ID (e.g. morning) is what becomes the session= URL parameter.

Phase sequence

Inside a window, you build an ordered list of steps. A step is one of:

Steps run top-to-bottom. The same task can appear multiple times; you can have Pre-EMA → HR → ePAT → Post-EMA, or two tasks sandwiched between three EMA blocks — whatever the protocol calls for.

Tasks Tab

The Tasks tab is where you turn optional task modules on or off. Toggling a task makes it available to drop into your schedule — it doesn't insert it anywhere automatically; you still choose where in the session sequence it runs (see Schedule).

Currently available: ePAT, HCT, and IAT. No camera is required for the IAT — it is the only task module that works on any smartphone without hardware constraints.

Live Preview

The right-hand iframe in the Builder is a fully functional participant app, re-stitched on every edit. It runs in preview mode (__PREVIEW_MODE__ = true), which disables link expiry and session locking so you can walk through the same session repeatedly. Clicking Reset clears the preview's local storage without touching your real project.

Preview is the fastest way to catch issues before you export anything. Touch-test it on your own phone by opening the Builder's URL on your device — the preview iframe works over any local network you're on.

Export Options

Hosting Your Study

This section is about hosting the exported study bundle — the thing participants will open. You are not hosting the Builder itself (that already lives at emaforge.keeganwhitacre.com).

The simplest option for most academic labs is GitHub Pages. It is free, reliable, and requires no command-line work. The minimal path:

1. Create a free GitHub account if you don't have one.
2. Create a new repository (e.g. my-ema-study). Make it public or private — both work with GitHub Pages on free accounts.
3. Click Add file → Upload files, and drop in the entire contents of your extracted Export zip (the index.html, config.json, and the css / js folders).
4. Go to Settings → Pages. Under "Source," choose main branch, root folder.
5. Wait a minute. Your study is now live at https://<your-username>.github.io/my-ema-study/.

That URL is the base you give to the Builder's Deployment tab to generate participant links. You're done.

# From your extracted bundle folder
git init
git add .
git commit -m "study v1"
git branch -M main
git remote add origin https://github.com/your-lab/your-study.git
git push -u origin main

# Then in GitHub: Settings → Pages → Source = main branch, root
# Your study is live at https://your-lab.github.io/your-study/

Participant Routing

Because there is no backend, the participant's session is entirely determined by the URL they open. Four query parameters drive this:

https://your-lab.github.io/study/?id=104&day=2&session=morning&t=1732812000000

Generating Links in Bulk

The Builder's Deployment tab takes a base URL and a participant-ID range, and emits a CSV with one row per (participant × day × session). Each row includes a Phase_Sequence column so you can eyeball at a glance what each link will do.

Participant_ID,Day,Session,Phase_Sequence,URL
104,0,Setup,Onboarding,https://.../?id=104&session=onboarding
104,1,Morning,Pre-EMA → ePAT → Post-EMA,https://.../?id=104&day=1&session=w1
104,1,Evening,Pre-EMA,https://.../?id=104&day=1&session=w2
...

This CSV is the glue between EMA Forge and your delivery mechanism of choice — drop it into a Qualtrics contacts list, a Twilio scheduled-SMS campaign, an institutional email merge, or a lab-built scheduler. Your scheduler is responsible for appending a t= timestamp at send-time if you want expiry enforcement.

Sending Prompts

You have two paths. Both use the same routing CSV as their source of truth.

• Bring your own mechanism. Drop the routing CSV into an institutional email merge, a Qualtrics contacts list, a Power Automate flow, or any SMS tool that can schedule messages from a CSV. You handle timing and t= injection.
• Export the Twilio dispatcher. BETA Generates an Apps Script that runs on a time trigger in a Google Sheet, handles timezone math, dedupes sends, and enforces t= expiry. See Twilio Integration for full setup.

Session Lifecycle

When a participant opens a link, the runtime:

1. Parses URL parameters.
2. Checks expiry (if t and expiry_minutes are both set).
3. Checks the completion lock — has this (id, day, session) tuple already been submitted on this device?
4. Checks for an in-progress resume state for this session.
5. Renders the first step of the session (usually a pre-task EMA block).
6. On each phase completion, writes the phase's responses to local storage and advances.
7. When the last phase finishes, the full session payload is assembled and the "Save Local Copy" screen appears. Tapping it triggers a file download.

Expiry & Grace Period

• Expiry window (default 60 min): after this many minutes past t, the link renders a "Link Expired" screen and the Start button is disabled. Recorded as a missed ping by the Dashboard.
• Grace period: a secondary buffer primarily used for downstream compliance calculations; the link remains functional during grace, but responses inside the grace window can be flagged during analysis.

Session Locking

By default, a participant who completes a session and then re-clicks the same link sees a "Session Complete — thanks, come back at the next prompt" screen. This prevents accidental double-submissions.

Researchers can override with ?force=1 appended to the URL (useful for QA walkthroughs or for rescuing a participant whose submission didn't land). Do not include force in participant-facing links.

Crash Recovery

If a participant's browser crashes mid-session (tab killed by iOS memory pressure, phone restart, app switch past timeout), reopening the same link will:

• Restore all completed phases (pre-EMA, finished task trials, etc.) — that data survives.
• Restart the current phase from the beginning. Partial data within the phase is discarded to avoid ambiguity.

This is intentionally conservative. A half-finished phase with an unknown number of missing questions is worse than a clean re-run.

Schema Versioning & Migrations

Every study carries a schema version (currently 1.5.0). When the Builder loads a saved study — whether from your browser's local storage or a backup file you imported — it checks that version:

• Equal → load as-is.
• Older → forward-migrate silently (new fields get sensible defaults).
• Newer → refuse to load. A newer schema might include fields this runtime doesn't know how to preserve; loading would silently corrupt them. Export a backup from the newer Builder or reset.

This is worth knowing when rolling out an EMA Forge update mid-study: finish in-progress waves on the old version, then upgrade.

What Happens at Session End

When the last phase completes, one of two things happens depending on whether you've configured a webhook (Study tab → Webhook URL):

Manual return (default)

The participant sees a "Save Local Copy" button. Tapping it downloads one or two files to their device:

• ema_data_[ID]_[DAY]_[SESSION].csv — long-format, one row per question answered. Default output when the session contains only standard EMA responses.
• ema_data_[ID]_[DAY]_[SESSION].json — full structured payload, included automatically whenever the session contains high-density signal data (PPG samples, ePAT trial-level data). Written alongside the CSV, not instead of it.

The participant returns these files via whatever channel your IRB approved (secure email, REDCap file upload, institutional SFTP). The Dashboard expects a folder of JSON files for analysis; a CSV-only workflow is also viable for simpler studies.

Webhook return (opt-in)

If a Webhook URL is set, the same data POSTs silently to your endpoint and the participant sees "✓ Data uploaded successfully" instead of a download button. Setup, payload shape, and concrete Google Sheets / Microsoft recipes are in Auto-upload with Webhooks. If the POST fails (offline participant, endpoint down), the "Save Local Copy" button automatically reappears — data is never lost silently.

CSV Schema (Dashboard export)

When you use the Export Master CSV button in the Dashboard, you get one row per (session, question) pair in long format. The columns:

JSON Schema (per-session)

The raw JSON payload is what the Dashboard reads and is the source of truth. Shape (abbreviated):

{
  "participantId": "104",
  "sessionId": "s_a1b2c3",
  "day": 2,
  "type": "morning",
  "status": "complete",
  "startedAt": "2026-04-22T08:03:11Z",
  "completedAt": "2026-04-22T08:06:48Z",
  "data": [
    {
      "type": "ema_response",
      "block": "pre",
      "windowId": "w1",
      "startedAt": "...",
      "submittedAt": "...",
      "presentationOrder": [["q1", "q2"], ["q3"]],
      "responses": {
        "q1":    { "value": 72,                        "respondedAt": "..." },
        "q2":    { "value": "Working",                 "respondedAt": "..." },
        "q3":    { "value": {"valence": 0.4,
                             "arousal": -0.2},         "respondedAt": "..." },
        "q_hr_1":{ "value": { "bpm": 74,
                              "sqi": 0.82,
                              "ibi_series": [810, 795, ...] },
                   "respondedAt": "..." }
      }
    },
    {
      "type": "epat_response",
      "trials": [ { "trial": 1, "phase_ms": 342, "confidence": 3, "sqi": 0.91 }, ... ],
      "summary": { "valid_trials": 18, "mean_abs_phase_ms": 218, "..." }
    }
  ]
}

Analysis in R

Because the Dashboard's CSV export is long-format, getting from a folder of per-session files to a tidy dataset is short. A typical starter pipeline:

library(tidyverse)
library(jsonlite)

# 1. Ingest a folder of per-session JSON files
files <- list.files("data/", pattern = "\\.json$", full.names = TRUE)
sessions <- map(files, ~ fromJSON(.x, simplifyVector = FALSE))

# 2. Flatten to long format (or just use the Dashboard's master CSV)
df <- read_csv("ema_master_dataset_2026-04-22.csv")

# 3. Compliance per participant
compliance <- df |>
  distinct(participant_id, day, session_id) |>
  count(participant_id) |>
  rename(sessions_completed = n)

# 4. Mean mood by time-of-day, handling the long format
mood <- df |>
  filter(question_id == "q1") |>
  group_by(participant_id, window_label) |>
  summarize(mean_mood  = mean(response_numeric, na.rm = TRUE),
            sd_mood    = sd(response_numeric,   na.rm = TRUE),
            n          = n(),
            .groups    = "drop")

# 5. Affect Grid (stored as "valence;arousal" in response_value)
affect <- df |>
  filter(question_type == "affect_grid") |>
  separate(response_value, into = c("valence", "arousal"),
           sep = ";", convert = TRUE)

Dashboard

dashboard.html is a local analysis UI. Everything parses in your browser; no data is transmitted anywhere.

What to feed it

The Dashboard accepts two input shapes. You can mix them in a single import — the parser sorts out which files are which.

• A folder of JSON files. One per-session .json as produced by the participant app, plus a single config.json (the same one inside your exported study). This is the right shape when participants return files manually, or when you've downloaded them out of REDCap/institutional storage.
• A CSV from the Google Sheets webhook. BETA If you're using the Google Apps Script webhook recipe, your sheet has a Raw JSON column holding each session's payload. Export the sheet as .csv (File → Download → CSV) and import it alongside your config.json. The parser reads each row's Raw JSON cell as a full session payload.

Once imported, the Dashboard renders:

KPIs

• Avg. Compliance Rate — completed sessions / expected sessions, scoped by filters.
• Total Pings Delivered — expected sessions up to the current study day.
• Signal Noise / Invalid % — proportion of sessions flagged as "speeding" (total session duration < 30 seconds). A rough heuristic; tune in your own analysis.
• Avg. Time to Complete — mean session duration.

Filters & views

• Aggregate vs. Per-Participant segmented view.
• Date range (by study day).
• Exclude missed prompts toggle (affects denominator of compliance).
• Filter rapid responders (<30s) toggle.
• Attention Required watchlist — participants whose compliance is below threshold, ready for a check-in text.
• Export Master CSV — flattens all imported sessions into one long-format file (schema above).

Heart-Rate Capture (Camera PPG)

EMA Forge ships a lightweight photoplethysmography (PPG) pipeline that recovers heart rate from the participant's rear-facing smartphone camera, with the torch on as an illumination source. It powers two user-facing features:

• A heart_rate question type you can drop into an EMA block anywhere.
• A standalone HR step in a window's phase sequence (identical capture, structural placement differs).

ePAT — Ecological Phase Assessment Task

The ePAT is a cardiac interoceptive-accuracy task adapted for in-the-wild, mobile-first use. It is directly descended from the Phase Adjustment Task (PAT) and its refined successor PAT 2.0 — see Acknowledgments & Prior Work for primary sources. Participants align an auditory tone with their own felt heartbeats by rotating a dial until the tone "feels like it's landing on" each beat. Their phase offset (in ms, relative to ground-truth peaks detected by the camera PPG) is the dependent measure.

Heartbeat Counting Task (HCT) BETA

The Heartbeat Counting Task is a classic measure of cardiac interoceptive accuracy (Schandry, 1981). Participants silently count the heartbeats they perceive over a set of timed intervals. The accuracy score for each interval is 1 - |actual - reported| / actual, where actual is the objective beat count and reported is the participant's count. Mean accuracy across intervals is the canonical Schandry score.

EMA Forge's HCT module reuses the same camera-PPG pipeline (ePATCore) that powers the ePAT and the inline heart-rate question type, so objective beat counts during each interval are computed with the WABP onset detector and signal-quality gating described in HR Capture (PPG). Participants hold their fingertip over the rear camera + flashlight for the duration of the task.

{
  "type": "hct_response",
  "startedAt": "2026-04-30T08:04:11Z",
  "baseline": { "recordedHR": [72, 71, ...], "totalBeats": 60, "finalSqi": 0.012, ... },
  "intervals": [
    {
      "intervalIndex": 1, "isPractice": false,
      "duration_sec": 35, "durationMs_actual": 35012,
      "reportedCount": 32, "actualBeats": 41,
      "accuracy": 0.7805,
      "confidence": 6, "bodyPos": 1,
      "recordedHR": [70, 71, ...], "ibi_series": [810, 795, ...],
      "qualitySummary": { "cleanBeats": 39, "flaggedBeats": 2,
                          "sqiBadSeconds": 0.5, "sqiFinalValue": 0.012, ... }
    }, ...
  ],
  "practices": [...],
  "summary": {
    "valid_intervals": 3, "practice_intervals": 1,
    "mean_accuracy": 0.81,
    "mean_confidence": 5.7,
    "interoceptive_awareness": 0.42,
    "mean_sqi": 0.011,
    "instruction_variant": "count",
    "randomized": true,
    "intervals_sec": [25, 35, 45]
  }
}

Implicit Association Task (IAT)

The IAT (Greenwald, McGhee & Schwartz, 1998) measures the strength of automatic associations between concept pairs by comparing response times across compatible and incompatible sorting conditions. EMA Forge implements the standard 7-block IAT with D-score scoring (Greenwald, Nosek & Banaji, 2003) computed entirely in the participant's browser at session end. No server, no camera, no hardware requirements beyond a touchscreen.

Because the IAT is RT-based, mobile deployment requires deliberate engineering choices that differ from desktop implementations:

• touchstart, not click. Response time is recorded from touchstart, which fires at finger contact (~50–100 ms earlier than click). click fires as a fallback for desktop/preview.
• rAF-anchored stimulus onset. The stimulus word is written to the DOM and then t₀ = performance.now() is captured inside a requestAnimationFrame callback — not at the moment of the innerHTML write. This ensures t₀ reflects pixel-on-screen rather than JS execution time, which can diverge by a full frame (16 ms at 60 Hz) or more under load.
• Half-screen tap zones. The left and right halves of the screen are independent invisible buttons. A hairline center divider provides a visual affordance. Tap targets are intentionally the full screen height, not thumb-zone strips, to minimize motor error variance.

{
  "type": "iat_response",
  "startedAt": "2026-04-30T08:12:44Z",
  "trials": [
    {
      "block_index": 0,
      "block_id": 1,
      "block_label": "Practice: Flowers",
      "pairing_id": null,
      "critical_for_d": false,
      "trial_n_in_block": 1,
      "trial_n_overall": 1,
      "stimulus": "Orchid",
      "category": "target_a",
      "correct_side": "left",
      "response_side": "left",
      "correct": true,
      "rt_ms": 621.4,
      "excluded": false,
      "exclude_reason": null,
      "timestamp": "2026-04-30T08:12:45Z"
    },
    ...
  ],
  "summary": {
    "d_score": 0.482,
    "d_mean_pairing1": 712.3,
    "d_mean_pairing2": 891.6,
    "d_sd_pooled": 372.1,
    "d_n_pairing1": 118,
    "d_n_pairing2": 117,
    "block_order_variant": 0,
    "fast_responder": false,
    "total_trials": 200,
    "excluded_trials": 3,
    "exclusion_rate": 0.015,
    "target_a_label": "Flowers",
    "target_b_label": "Insects",
    "attr_pos_label": "Pleasant",
    "attr_neg_label": "Unpleasant",
    "block_stats": [
      {
        "block_id": 1,
        "n_total": 20, "n_valid": 20, "n_excluded": 0,
        "n_errors": 2, "error_rate": 0.1,
        "mean_rt": 698.2,
        "fast_trial_count": 0, "fast_trial_rate": 0.0
      },
      ...
    ]
  }
}

library(jsonlite)
library(dplyr)
library(purrr)
 
sessions <- list.files("data/", pattern = "\\.json$", full.names = TRUE) |>
  map(read_json)
 
iat_summary <- sessions |>
  map_dfr(function(s) {
    iat <- keep(s$data, ~ .$type == "iat_response")
    if (!length(iat)) return(NULL)
    sm <- iat[[1]]$summary
    tibble(
      pid              = s$participantId,
      day              = s$day,
      d_score          = sm$d_score,
      block_order      = sm$block_order_variant,
      fast_responder   = sm$fast_responder,
      exclusion_rate   = sm$exclusion_rate,
      mean_rt_p1       = sm$d_mean_pairing1,
      mean_rt_p2       = sm$d_mean_pairing2
    )
  })
 
# Trial-level data (for block-by-block RT analysis)
iat_trials <- sessions |>
  map_dfr(function(s) {
    iat <- keep(s$data, ~ .$type == "iat_response")
    if (!length(iat)) return(NULL)
    iat[[1]]$trials |>
      map_dfr(as_tibble) |>
      mutate(pid = s$participantId, day = s$day)
  })

Conditional Tasks

A task step in a window's phase sequence can carry a condition that gates whether it runs at all:

{ kind: "task", id: "epat",
  condition: { question_id: "q_hr_1", operator: "gt", value: 80 } }

At runtime, EMA Forge evaluates the condition against the participant's responses collected earlier in the same session. If the condition is false, the step is silently skipped — as if it were never in the sequence. Typical use cases:

• "Only run ePAT if resting HR is elevated" — gate on a prior HR capture's BPM.
• "Only show the post-task stress items if the participant reported feeling stressed beforehand" — gate on a slider threshold.
• "Skip the cognitive task on the 3rd daily window" — gate on window ID.

Privacy Model

Written plainly, because IRBs will ask you to restate this in your protocol:

1. Response data transmission is opt-in. By default, data is generated, stored, and downloaded entirely on the participant's device, and you receive it via whatever channel the participant uses to return files. If the researcher configures a webhook (Study tab → Webhook URL), the session JSON is POSTed to that specific endpoint at session end instead. No transmission happens to any endpoint other than the one you configure. The webhook field is off by default.
2. The static host sees page-load requests. Your GitHub Pages / Netlify / institutional host will receive HTTP requests when the participant opens a link. These requests include timestamp, IP, User-Agent, and the full URL (including ?id=). If participant ID alone is identifiable, choose an unlinkable ID (short opaque strings, not names or MRNs).
3. No third-party analytics, no CDN fetches, no font-provider calls. The exported study has zero outbound network calls at runtime other than (a) the initial page load from your host, and (b) the single webhook POST at session end if configured. You can verify this in Chrome DevTools → Network.
4. Camera / microphone access (HR, ePAT) is handled entirely through the browser's getUserMedia permission prompt. The media stream never leaves the device; only the derived signal (BPM, IBIs, phase offsets) is stored.
5. Consent is captured as a boolean plus a timestamp in the onboarding JSON payload. The full consent text as the participant saw it is logged alongside.

IRB Boilerplate

Two variants depending on your data-return design — use the one that matches your protocol.

Variant A: Manual participant return (no webhook)

Participant response data will be collected via a custom web-based application (EMA Forge, an open-source static web tool). The application operates entirely in the participant's mobile browser: response data is generated and stored on the participant's device and is not transmitted to any central server in the course of normal operation. Participants return completed session files to the research team via [INSTITUTIONAL SECURE CHANNEL — e.g., REDCap file upload, institutional SFTP]. No protected health information or direct identifiers are included in the study data; participants are identified only by an opaque study ID. Physiological measurements (heart rate via photoplethysmography) are derived from the participant's smartphone camera locally; raw video is not stored or transmitted. The application source code is open and available for review at github.com/keeganwhitacre/emaforge.

Variant B: Webhook auto-upload to a defined endpoint

Participant response data will be collected via a custom web-based application (EMA Forge, an open-source static web tool). The application operates in the participant's mobile browser and, at the end of each session, transmits the session's response data via HTTPS POST to a single pre-configured endpoint controlled by the research team at [ENDPOINT DESCRIPTION — e.g., an institutionally-hosted endpoint writing to a secured REDCap project / an institutional Google Workspace sheet under the PI's account / an AWS Lambda writing to an encrypted S3 bucket in the institution's AWS organization]. No data is transmitted to any other endpoint. If network transmission fails, the application falls back to on-device storage and manual return via [FALLBACK CHANNEL]. No protected health information or direct identifiers are included in the study data; participants are identified only by an opaque study ID. Physiological measurements (heart rate via photoplethysmography) are derived from the participant's smartphone camera locally; raw video is not stored or transmitted. The application source code is open and available for review at github.com/keeganwhitacre/emaforge.

Known Limitations

• No live enrollment dashboard. Data is only visible once files are returned.
• Missed-ping detection is derived, not direct. The app cannot know a prompt was sent unless you record that externally.
• Device heterogeneity. HR/ePAT quality depends on camera sensor, torch brightness, and case thickness. Pilot across a range of devices before locking your protocol.
• Browser storage can be cleared. A participant who "clears website data" mid-study loses their in-progress resume state (but not already-downloaded session files). The completion lock also resets.
• Single-file exports don't let you patch typos. Use the static-hosting bundle if you anticipate edits after deployment.
• Accessibility is a work in progress. Screen-reader support for sliders and the affect grid is incomplete. Audit against your accessibility requirements before broad enrollment.

Roadmap

Auto-upload with Webhooks STABLE

By default, each session ends with the participant tapping "Save Local Copy" and emailing the resulting file to your lab. This works, but it has two costs: it depends on the participant remembering the step, and it depends on your return channel being IRB-approved.

The webhook option removes both. When you paste a URL into the Webhook URL field in the Builder's Study tab, the exported study silently POSTs the full session JSON to that URL at save-time. The participant sees "✓ Data uploaded successfully" instead of a download prompt. If the upload fails (no network, endpoint down), the manual download button automatically re-appears — data is never lost silently.

What gets sent

The runtime POSTs a JSON body to your endpoint with this shape:

{
  "participant_id": "104",
  "day": 2,
  "window_id": "morning",
  "session_data": {
    "participantId": "104",
    "sessionId":     "s_a1b2c3",
    "day":           2,
    "type":          "morning",
    "status":        "complete",
    "startedAt":     "2026-04-22T08:03:11Z",
    "completedAt":   "2026-04-22T08:06:48Z",
    "data": [ /* ema_response, epat_response, etc. — full payload */ ]
  }
}

The top four fields are duplicated out of session_data for easy dispatch/filtering on your receiving end. The session_data object is the same JSON documented in JSON Schema.

Webhook recipes by receiver

EMA Forge's webhook is a plain HTTPS POST with a JSON body. Anything that can accept that and respond with a 2xx works. The table below summarises the recipes documented in this section; pick the one whose tradeoffs match your IRB, your IT environment, and your willingness to do setup work.

Google Sheets via Apps Script STABLE

The fastest path to a working pipeline — no server, no billing, no institutional signoff beyond your existing Google account. Sessions fill a Google Sheet one row at a time as participants complete them.

function doPost(e) {
  try {
    const data  = JSON.parse(e.postData.contents);
    const sheet = SpreadsheetApp.getActiveSpreadsheet().getActiveSheet();

    if (sheet.getLastRow() === 0) {
      sheet.appendRow(['Timestamp', 'Participant ID', 'Day', 'Window', 'Raw JSON']);
      sheet.getRange(1, 1, 1, 5).setFontWeight("bold");
      sheet.setFrozenRows(1);
    }

    sheet.appendRow([
      new Date(),
      data.participant_id || 'Unknown',
      data.day            || 'Unknown',
      data.window_id      || 'Unknown',
      JSON.stringify(data.session_data || data)
    ]);

    return ContentService
      .createTextOutput(JSON.stringify({status: 'success'}))
      .setMimeType(ContentService.MimeType.JSON);

  } catch (error) {
    return ContentService
      .createTextOutput(JSON.stringify({error: error.message}))
      .setMimeType(ContentService.MimeType.JSON);
  }
}

Cloudflare Worker → R2 object storage STABLE

Cloudflare Workers are free up to 100,000 requests per day. R2 (Cloudflare's S3-compatible object storage) is free up to 10 GB stored with no egress fees. This combination scales further than Apps Script, stores one full JSON per session (so signal-heavy ePAT sessions don't bump against any row-size cap), and has no cold-start latency.

export default {
  async fetch(request, env) {
    const cors = {
      'Access-Control-Allow-Origin':  '*',
      'Access-Control-Allow-Methods': 'POST, OPTIONS',
      'Access-Control-Allow-Headers': 'Content-Type',
    };

    if (request.method === 'OPTIONS') return new Response(null, { headers: cors });
    if (request.method !== 'POST')    return new Response('POST only', { status: 405, headers: cors });

    const url = new URL(request.url);
    if (env.AUTH_SECRET && url.searchParams.get('auth') !== env.AUTH_SECRET) {
      return new Response('unauthorized', { status: 401, headers: cors });
    }

    let body;
    try { body = await request.json(); }
    catch {
      return new Response(JSON.stringify({error: 'bad json'}), {
        status: 400, headers: { ...cors, 'Content-Type': 'application/json' }
      });
    }

    const pid = String(body.participant_id || 'unknown');
    const day = String(body.day || '0');
    const win = String(body.window_id || 'na');
    const ts  = new Date().toISOString().replace(/[:.]/g, '-');
    const key = `sessions/${pid}/day-${day}/${win}_${ts}.json`;

    await env.EMA_BUCKET.put(key, JSON.stringify(body), {
      httpMetadata:   { contentType: 'application/json' },
      customMetadata: { pid, day, win }
    });

    return new Response(JSON.stringify({status: 'success', key}), {
      status: 200, headers: { ...cors, 'Content-Type': 'application/json' }
    });
  }
};

library(aws.s3)

Sys.setenv(
  AWS_ACCESS_KEY_ID     = "<your R2 access key>",
  AWS_SECRET_ACCESS_KEY = "<your R2 secret key>",
  AWS_S3_ENDPOINT       = "<account_id>.r2.cloudflarestorage.com"
)

# Sync entire bucket to local
files <- get_bucket_df(bucket = "ema-forge-sessions", region = "auto")
for (key in files$Key) {
  save_object(key, bucket = "ema-forge-sessions",
              file = file.path("data", basename(key)))
}

Azure Function → SharePoint List STABLE

The institutional Microsoft path. Best fit when your university mandates Microsoft 365 for research data storage, when your IRB prefers data stay inside the institutional tenant, or when your IT contact will resist approving non-Microsoft cloud services. Azure Functions on the consumption plan are free up to 1 million executions per month, which is well above any plausible EMA workload.

This recipe requires a one-time app registration in Azure AD, which typically means asking your central IT to grant the Sites.ReadWrite.All application permission. Most university IT shops process this routinely.

const { app } = require('@azure/functions');
const { Client } = require('@microsoft/microsoft-graph-client');
const { ClientSecretCredential } = require('@azure/identity');
require('isomorphic-fetch');

app.http('SaveSession', {
  methods: ['POST', 'OPTIONS'],
  authLevel: 'function',
  handler: async (req, ctx) => {
    const cors = {
      'Access-Control-Allow-Origin':  '*',
      'Access-Control-Allow-Methods': 'POST, OPTIONS',
      'Access-Control-Allow-Headers': 'Content-Type',
    };
    if (req.method === 'OPTIONS') return { status: 200, headers: cors };

    try {
      const raw  = await req.text();
      const data = JSON.parse(raw);

      const credential = new ClientSecretCredential(
        process.env.TENANT_ID,
        process.env.CLIENT_ID,
        process.env.CLIENT_SECRET
      );
      const graph = Client.initWithMiddleware({
        authProvider: {
          getAccessToken: async () =>
            (await credential.getToken('https://graph.microsoft.com/.default')).token
        }
      });

      const siteId = process.env.SHAREPOINT_SITE_ID;
      const listId = process.env.SHAREPOINT_LIST_ID;

      await graph
        .api(`/sites/${siteId}/lists/${listId}/items`)
        .post({
          fields: {
            Title:        `${data.participant_id}_D${data.day}_${data.window_id}`,
            Participant:  String(data.participant_id || ''),
            Day:          Number(data.day) || 0,
            Window:       String(data.window_id || ''),
            ReceivedAt:   new Date().toISOString(),
            SessionJSON:  JSON.stringify(data.session_data || {}).slice(0, 250000)
          }
        });

      return {
        status: 200,
        headers: { ...cors, 'Content-Type': 'application/json' },
        body: JSON.stringify({ status: 'success' })
      };
    } catch (err) {
      ctx.error(err);
      return {
        status: 500,
        headers: { ...cors, 'Content-Type': 'application/json' },
        body: JSON.stringify({ error: err.message })
      };
    }
  }
});

npm install @azure/functions @azure/identity @microsoft/microsoft-graph-client isomorphic-fetch

Power Automate → Excel STABLE

Simpler than the Azure Function path, but the "When an HTTP request is received" trigger is a Premium Power Automate connector that most institutional Microsoft 365 plans do not include. Before investing time, check with IT whether your Microsoft 365 plan has Premium Power Automate. If not, use the Azure Function path instead.

REDCap via institutional PHP proxy STABLE

Direct browser-to-REDCap POSTs are blocked by CORS on most REDCap installations. The realistic path is a one-file PHP proxy hosted on your lab's institutional web server, which accepts the POST from the participant's phone and forwards it to REDCap's API using your project token. This is the path most IRBs prefer because the data path is institutional end-to-end — the participant's phone hits a university domain, which forwards to a university REDCap instance, with no external cloud services involved.

<?php
// ema-forge-redcap-proxy.php
// Forwards EMA Forge sessions into a REDCap project's repeatable instrument.

header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: POST, OPTIONS');
header('Access-Control-Allow-Headers: Content-Type');
header('Content-Type: application/json');

if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
    http_response_code(200);
    exit;
}

$REDCAP_URL    = getenv('REDCAP_URL')   ?: 'https://redcap.your-uni.edu/api/';
$REDCAP_TOKEN  = getenv('REDCAP_TOKEN') ?: 'PASTE_YOUR_TOKEN_HERE';
$SHARED_SECRET = getenv('EMA_SECRET')   ?: '';  // optional, recommended

if ($SHARED_SECRET && ($_GET['auth'] ?? '') !== $SHARED_SECRET) {
    http_response_code(401);
    echo json_encode(['error' => 'unauthorized']);
    exit;
}

$body = file_get_contents('php://input');
$data = json_decode($body, true);
if (!$data) {
    http_response_code(400);
    echo json_encode(['error' => 'invalid JSON']);
    exit;
}

$record = [[
    'record_id'                => $data['participant_id'] ?? 'unknown',
    'redcap_event_name'        => 'ema_arm_1',           // edit to match your project
    'redcap_repeat_instrument' => 'session',
    'redcap_repeat_instance'   => 'new',                  // REDCap auto-assigns
    'session_day'              => $data['day'] ?? '',
    'session_window'           => $data['window_id'] ?? '',
    'session_json'             => json_encode($data['session_data'] ?? []),
    'session_received'         => date('Y-m-d H:i:s'),
]];

$payload = http_build_query([
    'token'             => $REDCAP_TOKEN,
    'content'           => 'record',
    'format'            => 'json',
    'type'              => 'flat',
    'data'              => json_encode($record),
    'overwriteBehavior' => 'normal',
    'forceAutoNumber'   => 'false',
    'returnContent'     => 'count',
]);

$ch = curl_init($REDCAP_URL);
curl_setopt_array($ch, [
    CURLOPT_POST           => true,
    CURLOPT_POSTFIELDS     => $payload,
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_SSL_VERIFYPEER => true,
    CURLOPT_TIMEOUT        => 30,
]);
$result = curl_exec($ch);
$code   = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close($ch);

if ($code >= 200 && $code < 300) {
    http_response_code(200);
    echo json_encode(['status' => 'success']);
} else {
    http_response_code(502);
    echo json_encode(['error' => 'redcap rejected', 'code' => $code]);
}

AWS Lambda → S3 STABLE

For labs standardised on AWS. Cost is roughly $0–3 per month at EMA scale: Lambda's free tier covers ~1M requests/month indefinitely, and S3 storage runs about $0.023 per GB-month. Output shape mirrors the Cloudflare R2 recipe (one JSON file per session, partitioned by participant/day), so analysis pipelines are interchangeable.

import { S3Client, PutObjectCommand } from '@aws-sdk/client-s3';

const s3     = new S3Client({ region: process.env.AWS_REGION });
const BUCKET = process.env.BUCKET_NAME;

export const handler = async (event) => {
  const cors = {
    'Access-Control-Allow-Origin':  '*',
    'Access-Control-Allow-Methods': 'POST, OPTIONS',
    'Access-Control-Allow-Headers': 'Content-Type',
  };

  if (event.requestContext?.http?.method === 'OPTIONS') {
    return { statusCode: 200, headers: cors };
  }

  try {
    const body = JSON.parse(event.body);
    const pid  = String(body.participant_id || 'unknown');
    const day  = String(body.day || '0');
    const win  = String(body.window_id || 'na');
    const ts   = Date.now();
    const key  = `sessions/${pid}/day-${day}/${win}_${ts}.json`;

    await s3.send(new PutObjectCommand({
      Bucket:      BUCKET,
      Key:         key,
      Body:        JSON.stringify(body),
      ContentType: 'application/json',
      Metadata:    { participantid: pid, day, windowid: win }
    }));

    return {
      statusCode: 200,
      headers:    { ...cors, 'Content-Type': 'application/json' },
      body:       JSON.stringify({ status: 'success', key })
    };
  } catch (err) {
    return {
      statusCode: 500,
      headers:    { ...cors, 'Content-Type': 'application/json' },
      body:       JSON.stringify({ error: err.message })
    };
  }
};

Cautions and gotchas

• Your endpoint URL is effectively a credential. Anyone who has it can post synthetic data into your dataset. For serious studies, add a shared secret — have the study POST an ?auth=... query parameter that the script checks, rotate it if leaked.
• Google Apps Script rate limits exist but are generous for EMA-scale traffic. Expect no issues below ~1000 participant-sessions per day. Beyond that, batch or switch to a dedicated endpoint.
• Apps Script responses don't always reach the client cleanly. The runtime treats any response.ok as success; if Apps Script happens to return a redirect to a final content URL, the fetch still counts as a success. Your row will appear in the sheet regardless. This is fine for the "did it save?" question; if you need byte-exact response parsing, use a real endpoint.
• If you change the webhook URL mid-study, participants who cached the old exported HTML will continue to post to the old URL until they clear site data or you push a new export. Make webhook changes at export boundaries, not mid-enrollment.
• Webhooks do not eliminate the manual-download safety net. By design. If connectivity fails at session end, the "Save Local Copy" button reappears and the participant can still return the file by your IRB-approved channel.

Twilio Integration BETA

EMA Forge can now emit a ready-to-deploy Google Apps Script that dispatches scheduled SMS to participants via Twilio. It's a serverless companion to the serverless study app: the whole pipeline — scheduling, sending, retry, dedupe — lives in a spreadsheet attached to your Google account.

From the Builder's Deployment tab, alongside the existing Generate Routing CSV button, an Export Twilio Dispatcher (.gs) button produces a single .gs file pre-configured with your study's URL, study length, expiry window, and schedule. You paste it into an Apps Script project attached to a Google Sheet and it does the rest.

Setup

1. In the Builder's Deployment tab, set the Hosted URL to where your exported study lives (e.g. https://your-lab.github.io/study/).
2. Click Export Twilio Dispatcher (.gs). You'll get a file named like my-study-twilio-dispatcher.gs.
3. Open sheets.google.com and create a blank spreadsheet. Extensions → Apps Script.
4. Delete the placeholder myFunction. Paste the entire contents of the .gs file. Save.
5. Close and reopen the spreadsheet. You'll see a new EMA Forge 🛠️ menu.
6. Click 1. Setup Twilio & Roster. Supply your Twilio Account SID, Auth Token, and Twilio phone number (E.164 format, e.g. +15551234567). The wizard creates a Roster sheet with the schema below, plus a hidden _Dispatch_Log sheet for audit and dedupe.
7. Fill in the Roster. One row per participant.
8. Click 2. Start Automation (every 15 min). A time-based trigger is installed that runs dispatchPrompts every fifteen minutes.

Roster schema

How dispatch actually works

Every 15 minutes the trigger runs dispatchPrompts, which for each Active participant:

1. Computes the participant's current study day in their own timezone. Handles DST correctly — a spring-forward or fall-back won't shift anyone's morning ping.
2. If a ping is already scheduled and its time has passed, sends it via Twilio, then clears the scheduled fields. The URL includes an &t= timestamp so the study's expiry_minutes setting is actually enforced.
3. Otherwise, schedules the next window: picks the first window (sorted by end-time) whose end is still in the participant's future today, or rolls to tomorrow's first window if they've finished today. Within the window, a random minute is picked — the core behavior any EMA designer needs.
4. Writes outcomes to the hidden _Dispatch_Log sheet with a sent:HTTPcode or fail:HTTPcode:message marker. Failures leave the ping scheduled for retry on the next tick; successes are recorded so a subsequent tick can't send a duplicate even if the sheet-write that clears Next_Ping_ISO somehow failed mid-operation.

The dedupe key is (Participant_ID, Day, Window_ID) scoped to today in the participant's timezone. A participant gets at most one SMS per window per day, regardless of what happens to the sheet cells in between.

Message format

The outbound SMS is templated from your study name and expiry window:

StudyName: time for your check-in. Expires in 60 min. https://.../?id=104&day=2&session=morning&t=1732812000000  Reply STOP to opt out.

The Reply STOP to opt out line is not optional. US A2P 10DLC and Twilio's own messaging policy require clear opt-out language in programmatic SMS. Your IRB will also want it.

Menu reference

Known beta caveats

• Two-way SMS is not wired. Participants who reply STOP will stop receiving messages from Twilio (Twilio handles the opt-out carrier-side automatically), but the dispatcher won't know and will keep trying. You'll see the failures accumulate in _Dispatch_Log. The manual workaround: set that participant's Status to Paused.
• Credentials are "script-private," not "secure." Anyone with edit access to the Apps Script project can read them back with two lines of code. For the typical single-PI setup this is fine; for a shared lab Sheet, restrict Apps Script edit access explicitly.
• Delivery-receipt latency is not captured. The dispatcher records when Twilio accepted the request, not when the carrier delivered the SMS. True ping-to-open latency still needs a separate Twilio status-callback integration (planned).
• Retry back-off is coarse. A transient Twilio failure retries on the next 15-minute tick. If Twilio is down for an hour you'll accumulate four attempts per participant before success. This is fine for Twilio's actual reliability profile but worth knowing.
• Apps Script has a 6-minute execution limit per trigger run. At 15-minute ticks and typical send rates this is never an issue, but if you're running more than a few hundred participants in one dispatcher, split them across multiple sheets.

Under the Hood

You do not need any of this to run a study. It's here for the small subset of users who want to audit the code, contribute a new task module, or fork the project for a deeply custom use case.

ema-forge/
├── index.html             # Landing page
├── builder.html           # Study authoring environment
├── dashboard.html         # Local analysis dashboard
├── readme.html            # This file
├── ppgtester.html     # Standalone PPG pipeline tester
│
├── css/
│   └── studio.css             # Shared design tokens + component styles
│
├── js/
│   ├── state.js               # Central state + schema (SCHEMA_VERSION)
│   ├── storage.js             # LocalStorage + project import/export + migrations
│   ├── export.js              # Compiles study to HTML / zip bundle
│   ├── preview.js             # Live iframe preview
│   │
│   ├── tabs/                  # Builder tab controllers
│   │   ├── study.js
│   │   ├── onboarding.js
│   │   ├── questions.js
│   │   ├── schedule.js        # Windows + phase_sequence editor
│   │   ├── tasks.js           # Pluggable module registry
│   │   └── deployment.js      # Routing CSV generator
│   │
│   └── dashboard/
│       ├── parser.js          # Ingests participant JSON folder
│       └── dashboard.js       # Charts, filters, CSV export
│
└── templates/                # Source files stitched into the exported study
    ├── epat-core.js           # PPG pipeline + BeatDetector
    ├── study-base.js          # Runtime skeleton
    ├── module-onboarding.js
    ├── module-ema.js          # EMA block + inline HR capture
    └── module-epat.js         # ePAT task

git clone https://github.com/keeganwhitacre/emaforge.git
cd emaforge
python -m http.server 8000
# then open http://localhost:8000

Credit & Citation

EMA Forge was created by Keegan Whitacre at the Affective Science Lab, The Ohio State University. If you use EMA Forge in a published study, please cite:

Whitacre, K. (2026). EMA Forge: A serverless toolkit for
ecological momentary assessment and digital phenotyping.
Affective Science Lab, The Ohio State University.
https://github.com/keeganwhitacre/emaforge

For ePAT-specific methods, also describe the implementation (PPG pipeline + AudioContext-scheduled stimulus + dial-alignment response) in your Methods section. Issues, pull requests, and replication reports are welcome.

License

EMA Forge is released under the MIT License — free for academic and commercial use, modification, and redistribution. See LICENSE in the repository for the full text.

Acknowledgments & Prior Work

EMA Forge stands on a substantial body of prior work. The ePAT task in particular is not a novel invention but an ecological adaptation of an established psychophysical paradigm. Proper attribution here matters both scholarly and practically — if you publish using these modules, these are the citations your Methods section owes.

The Phase Adjustment Task (PAT) lineage

The core psychophysical logic of the ePAT — aligning an auditory tone to felt heartbeat via a continuous-adjustment response — is adapted from the Phase Adjustment Task developed by Plans, Ponzo, Morelli, Cairo, Ring, Keating, Cunningham, Catmur, Murphy & Bird, with subsequent refinements in PAT 2.0.

• Plans, D., Ponzo, S., Morelli, D., Cairo, M., Ring, C., Keating, C. T., Cunningham, A. C., Catmur, C., Murphy, J., & Bird, G. (2021). Measuring interoception: The phase adjustment task. Biological Psychology, 165, 108171.
• Palmer, C., Murphy, J., Bird, G., et al. (2025). Refinements of the Phase Adjustment Task (PAT 2.0). Preprint. doi:10.31219/osf.io/4qtwv.
• Original reference implementation (Swift/iOS): huma-engineering/Phase-Adjustment-Task.

The ePAT's contribution is specifically the ecological framing: porting the paradigm to a participant-owned smartphone, using camera PPG rather than a dedicated pulse oximeter, scheduling it within an EMA protocol rather than as a discrete lab session, and treating the resulting phase-offset trajectory as a time-varying individual-difference signal rather than a single-point measurement.

Beat detection — WABP

The PPG peak-detection routine is a JavaScript port of the WABP (Waveform Analysis for Blood Pressure) algorithm, originally developed for arterial blood pressure onset detection and released on PhysioNet. The algorithm generalizes well from arterial pressure to PPG because both signals share the characteristic upstroke-dominant morphology the algorithm was designed around.

• Zong, W., Heldt, T., Moody, G. B., & Mark, R. G. (2003). An open-source algorithm to detect onset of arterial blood pressure pulses. Computers in Cardiology, 30, 259–262.
• Reference C implementation: PhysioNet wabp.c.

Camera-based PPG acquisition

The browser-side camera acquisition approach — sampling the red channel of a rear-camera video stream under torch illumination — was informed by Richard Moore's open-source demonstrator, which established the feasibility of the pattern in a pure web environment.

• Moore, R. heart-rate-monitor. github.com/richrd/heart-rate-monitor.

Conceptual framework

The decision to operationalize interoceptive accuracy as an ecological, time-varying construct — and to embed it within a broader affective-science EMA protocol — is grounded in the Theory of Constructed Emotion and contemporary work on interoceptive predictive processing. The ePAT is one instrument within that larger program; it is not itself a complete theory.