Live config loaded — values shown in teal reflect what is currently deployed on this server.
AGS Documentation
Back to Dashboard

Study Design src/models/config.py

The three study conditions

Every session is assigned to exactly one condition at creation. The condition is resolved server-side from StudyConditionConfig — the client never sends or sees it. All three conditions produce identical-looking participant interfaces.

ConditionWhat it doesRules bypassedResearch purpose
governed_adaptive
Default
Full 17-rule governance evaluation. Interventions are gated, timed, and respect the "they're recovering" window. None The main experimental condition. Tests whether appropriate, well-timed adaptive support improves outcomes.
always_adaptive Governance fires more readily. Autonomy-preserving rules and post-intervention observation windows are removed, so help appears more often with fewer preconditions. R2, R3, R4, R5, R6, R9, R10 Tests whether more intervention is better than smarter intervention. Isolates governance quality from intervention quantity.
control Gate 0 exits before any computation. No readiness scores are calculated. No adaptation is shown. Signals are logged. All (exits immediately) The baseline. Tests what outcomes look like with no adaptive support at all. Essential for measuring the net effect of both adaptive conditions.
Why conditions must be invisible. If participants could tell which condition they were in, they would behave differently. A participant who knows they're in the control condition might try harder (to prove they don't need help) or give up faster (knowing no help is coming). This is demand characteristics — a well-documented threat to experimental validity. All overlays look identical across conditions. The participant experience is indistinguishable.

Changing the active condition

Only admin-role researchers can change the active study condition. The change requires a written reason, is written to the audit log and a condition history table, and takes effect for new sessions — not existing ones. Existing sessions are immutable once started. You can change the condition mid-study, but all historical sessions retain their original condition assignment.

Calibration — why three baseline interactions

Before the governance system can make meaningful decisions, it needs a reference point. The readiness model compares the participant's current interaction to their own personal baseline — their natural typing speed, their typical pause duration, their normal error rate. Without this, every participant gets compared to population averages, which are meaningless for a 70-year-old who has never used a smartphone.

The three calibration taps are not evaluated by governance. They establish:

  • Personal interaction pace — what is "normal" speed for this individual?
  • Baseline touch/tap profile — pressure, duration, timing (mobile)
  • Initial confidence signal — the pace and hesitation on calibration correlates with self-efficacy and sets the initial state

Why three specifically? One tap is too noisy — first interactions are almost always affected by novelty and nerves. Two taps provide a mean but no variance estimate. Three gives a minimal meaningful variance measure. Five or more would be more statistically robust but would delay the governance system by two additional interactions, during which the participant might be struggling without support.

Study phases and config locks

The study runs in two phases: calibration and main.

PhaseConfig changesThreshold changesCondition changes
calibration Allowed Allowed (for tuning before the study begins) Allowed (admin only)
main Allowed Locked Allowed (admin only, with extra audit logging)

Thresholds are locked in main phase to protect the integrity of the study. Changing the readiness thresholds mid-study would mean that a score of 45 means MODERATE in the first half and potentially HIGH in the second half, making the two halves uncomparable. If you genuinely need to change a threshold mid-study, document the change date precisely — the audit log provides this — and treat the pre- and post-change data as separate populations in analysis.

Adaptive task sequencing — ability model and ZPD

Within each practice session, participants complete up to 3 episodes. Each episode is a distinct scenario on the same simulation site. The scenario is selected to match the participant's current ability — not a fixed rotation.

Ability estimate (ELO-inspired)

Each participant has a persistent ability_score (0–100 scale, default 50). After every episode:

  • Performance score = completion (0.50) + independence from help (0.25) + efficiency vs expected time (0.25), minus governance penalties (worsened outcome: −0.10; readiness floor in OVERLOAD: −0.10; L4 HANDOFF fired: −0.15)
  • Expected performance = logistic function of (difficulty_level − ability/20 − 0.5), so a D3 scenario is "expected" for a participant at ability 50
  • Ability update = ability + K × (performance − expected), where K shrinks from 32 (first 5 attempts) to 20 (5–15 attempts) to 12 (stable)

The K-factor shrinkage reflects that early estimates are noisy — as the system accumulates data, smaller updates prevent oscillation.

Zone of Proximal Development targeting

The next scenario is selected from difficulty ±1 of the current ability tier. A participant at ability 55 (D3 zone) receives D2, D3, or D4 candidates. D4/D5 scenarios (involving privacy and risk judgment) are additionally gated behind at least one completed D3 scenario — ensuring the participant has demonstrated multi-step navigation before facing higher-stakes content.

If end-of-episode readiness is below 40 (LOW or OVERLOAD state), the next difficulty shifts down by 1 regardless of ability — a real-time accommodation for fatigue or environmental disruption.

Difficulty tiers

TierAbility rangeScenario typeExamples
D10–19Basic navigationOpen a chat and read a message
D220–39Simple actionReply to a health instruction
D340–59Multi-stepForward a link, find an appointment
D460–79Privacy/judgmentIdentify and correct a wrong recipient
D580–100Risk detectionIdentify a refund scam, unknown number

D4 and D5 scenarios are never the starting scenario and are gated behind a completed D3. This design ensures older adults are not confronted with high-stakes risk scenarios before they have demonstrated baseline competency.

Starting difficulty per session

At the start of each new session, the starting difficulty is not simply read from the stored ability. Three adjustments are applied:

  1. Time-gap decay — ability is reduced by 5 after a 14-day gap and by 10 after a 30-day gap. This accommodates the cognitive deconditioning common in older adults between study visits.
  2. Calibration delta — the 3 baseline taps provide a same-day readiness signal: if IKI (inter-keystroke interval) is 30% slower than the participant's personal baseline, or error/help rates during calibration are elevated, the starting point shifts down by up to 10 points.
  3. D3 cap — starting difficulty is capped at D3 regardless of ability. Even a participant who previously scored at D5 level starts a new session at D3 and earns their way back to harder material through today's performance.

The survey's role in subsequent sessions

The post-session survey is optional but scientifically important. Its confidence score becomes the GL (germane load) component of the cognitive load formula for the participant's next session. A participant who felt confident after Session 1 starts Session 2 with a higher GL score, which reduces their cognitive load calculation and raises their initial readiness state.

The temporal service updates these carry-forward values between sessions. If a participant skips the survey, GL remains at its prior value (or null for Session 1). Sessions are not invalidated by a skipped survey — they just use the previous session's GL.