Back to Dashboard
Terms & Status orientation
This section keeps the documentation readable for examiners, supervisors, researchers, and engineers who do not live in the code every day.
Core terms
| Term | Meaning in AGS |
|---|---|
| Readiness | A 0-100 estimate of whether a participant can continue without extra support. It combines cognitive, motivational, and environmental readiness. |
| IL / EL / GL | Intrinsic load, extraneous load, and germane load. AGS can react to avoidable load signals, especially extraneous load caused by interface friction. |
| Governance | The ordered rule system that decides whether to withhold, delay, reassess, or intervene. It protects autonomy and makes every adaptation auditable. |
| Adaptation | An AGS support-layer change: timing, message, intensity, language-specific help content, tooltip, guided prompt, reassurance, walkthrough, or rest prompt. |
| Capture mode | The technical path used to observe interaction signals: proxy, Service Worker proxy, extension, limited app capture, or offline replay. |
| Baseline | The first three calibration interactions used to establish a personal reference before governance rules are allowed to fire. |
| Study condition | The server-side experimental condition: governed adaptive, always adaptive, or control. The participant UI never reveals the condition. |
Task sequencing terms
| Term | Meaning in AGS |
|---|---|
| Episode | One scenario attempt within a session. A session contains up to 3 episodes. Each episode begins when the sim receives ags-next-scenario and ends when the participant completes the goal (sim fires ags-practice-goal-complete). |
| Scenario | A named task with a specific goal, difficulty level, and set of expected template steps (e.g., forward_sha_link, avoid_refund_scam). Distinct from a template step — scenarios are sequencer-layer concepts; steps are pipeline-layer concepts. |
| Template step | A reusable interaction checkpoint defined in the task template JSON (e.g., whatsapp_open_sarah). Multiple scenarios may traverse the same steps. Pipeline concepts (readiness, governance, adaptation) operate on step IDs, not scenario IDs. |
| Ability estimate | A persistent 0–100 score for each participant representing their demonstrated performance across all episodes. Stored in participant_ability. Default 50.0. Updated after every episode via an ELO-inspired formula. |
| ZPD | Zone of Proximal Development — the difficulty range where learning happens: just beyond current mastery but not so difficult as to cause defeat. AGS targets the next scenario at ±1 difficulty tier from the participant's current ability. |
| Difficulty tier | D1 (basic navigation) through D5 (risk judgment). Each tier maps to an ability band: D1=0–19, D2=20–39, D3=40–59, D4=60–79, D5=80–100. D4/D5 are gated behind completing at least one D3 scenario. |
| Readiness floor | The minimum readiness value observed at any point during an episode. Stored in Redis as ep_readiness_floor, written after every event. A floor below 20 (OVERLOAD) penalises the episode performance score by −0.10. |
| Calibration delta | A same-day ability adjustment (−10 to +10) computed from the 3 baseline interactions: IKI ratio vs personal baseline, error rate during calibration, help events during calibration. Applied on top of the persistent ability before computing starting difficulty. |
What to trust most
Authoritative sources
src/config.pyfor thresholds, weights, cooldowns, and governance constantssrc/pipeline/for scoring, readiness, governance, trajectory, and adaptation behavior/openapi.jsonfor request and response schemas- Dashboard exports and audit log for study evidence
Known documentation limits
- The API table is a curated reference, not a full replacement for OpenAPI.
- Private source-specification documents may not be present in every checkout or deploy bundle.
- Operational claims should be interpreted alongside staging logs and real study data.
- Formula sections must be updated whenever constants in
src/config.pychange.