Project: Covert Cubicles Build Phase 4 / 7 \u00B7 PHASE-CLOSING MODULE —

MODULE 19 / 31 \u00B7 LAYER 4 \u00B7 ALMAA_CONDITION \u00B7 RQ1b PIVOT Adaptation Execution Gate

The architectural pivot point that makes the experiment an experiment. Reads conditionVariant from the session and gates whether ALMAA_Trigger's resolved trigger decisions translate into actual UI adaptation execution. This is the only ALMAA module permitted to behave differently between condition groups.

DEPENDENCIES: SM_Game, ALMAA_Trigger
Pending
RQ1b ARCHITECTURAL PIVOT \u00B7 GROUP A vs GROUP B
M19 is the only module where Group A and Group B sessions diverge.
Every other ALMAA module (M15, M16, M17, M18) follows the always-compute / always-log discipline (ADR-032 / ADR-038 / ADR-045 / ADR-050) so that Group A (adaptive) and Group B (static control) sessions produce identical raw measurement data. M19 is the exception that makes the experiment an experiment. Group A: triggers gate through to UI execution. Group B: every trigger is no-oped, regardless of detector outputs. Both groups produce a complete conditionLog so analysis can verify experimental integrity post-hoc.
Always-log discipline is preserved here too
Even though M19 behaves asymmetrically across groups, it logs every gating decision to SM_Game.conditionLog — including the ones in Group B that all return shouldExecute=false. This creates a verifiable audit trail: a Group B session with zero conditionLog entries would be visibly broken; a Group B session with any shouldExecute=true entry would be a research-data-integrity failure. The log is the experimental integrity check.

Automated Assertions

#AssertionResultDetail

Interactive Workbench — Group A vs Group B Comparison

Configure a synthetic trigger record using the inputs below. The two panels show how the same trigger is evaluated under Group A (adaptive) and Group B (static control) conditions. The asymmetry is deliberate — and architecturally enforced.

Synthetic trigger record (pure gateReasonFor evaluation)
GROUP A \u00B7 ADAPTIVE
conditionVariant: 'adaptive' \u00B7 RQ1b experimental treatment
shouldExecuteAdaptation:
—
Gate reason —
vs
GROUP B \u00B7 STATIC CONTROL
conditionVariant: 'static' \u00B7 RQ1b control condition
shouldExecuteAdaptation:
—
Gate reason —

Reason taxonomy

executeGroup A only \u00B7 trigger fires through to UI execution
static_conditionGroup B \u00B7 conditionVariant is 'static' \u00B7 always no-ops regardless of trigger
no_action_triggerGroup A \u00B7 trigger was already no_action upstream \u00B7 nothing to gate
upstream_blockedGroup A \u00B7 M18 already blocked the trigger (cooldown / scrutiny_gate)
invalid_variantDefensive \u00B7 conditionVariant is missing or unrecognised
Lifecycle test \u2014 stateful integration with M18

Drives the full pipeline through real M18 ALMAA_Trigger calls. Create a session with a chosen variant, submit decisions, watch the conditionLog accumulate. Toggle between adaptive and static to see the asymmetry in action.

Session (choose variant before creating)
Force scrutiny up so triggers can fire
Submit P1 decisions \u2192 trigger \u2192 condition gate
Defensive (should fail)
Condition log summary (live)

Current session

0 gating decisions
execute0
no_action_trigger0
upstream_blocked0
static_condition0

Experimental integrity check

Create a session and submit decisions to populate.
Session condition log
No condition records yet. Use the lifecycle workbench to populate.

API Surface — Manual Verification

Open DevTools and try the calls below.