Study forms, SaaS webhooks, and progressive disclosure

• Parent: README.md
• Data policy: STUDY_PARTICIPANT_DATA_POLICY.md

Strategy (v1)

Fast path — external instruments (Typeform, Qualtrics, Google Forms)

• Use hosted forms for time-to-value and mature skip logic.
• Ingest via webhook → signed handler on Edgework (or client-side export → manual upload) into Dash or Knotchain envelopes — not Firebase/D1 as system of record (see policy doc).
• Store hashes, aggregates, or encrypted blobs keyed by study_id + instrument_version + participant pseudonym.

Forkjoin path — first-party multi-step (Edgework or static shell)

• One screen = one section (demographics, instrument block, debrief).
• Progressive disclosure: reveal later sections only after valid earlier inputs; show time estimate and save-and-continue when Dash sync is available.
• Branching: encode skip rules in instrument version; snapshot references instrument_version, not individual answers.

Progressive disclosure — UX rules

1. Order: consent → eligibility → core items → sensitive optional → debrief.
2. Friction: never hide required ethics/consent behind progressive UI without an explicit summary screen first.
3. Partial state: persist step index + validated fields in Dash session or encrypted checkpoint blob on Knotchain — avoid raw PII in URL query strings.

Technical sketch

• State: step index + checkpoint_id in Dash; or single Knotchain commit per milestone.
• Correlation: @a0n/gnosis/study-participant-link ingress ref links study_id to invite/reminder flows without embedding PII in StudyGraphSnapshotV1.

Verification

• Staging: webhook signature verification + fixed allowlist recipients for Mailgun (/api/internal/study/mail) and Twilio SMS (/api/internal/study/sms) using the same ops bearer token.
• No paid AI in Workers for this path (repo policy).