Implementation Plan — Inspired Applied Learning Platform (ALP)

Grounded in knowledge-tree/ and source-docs/. The phasing follows knowledge-tree/reference/implementation-roadmap.md. Open questions referenced inline live in knowledge-tree/questions/.

Problem statement

Inspired Instruction runs in-person professional development for teachers. Today there is no digital system that follows a teacher from “learned a strategy in a workshop” to “applied it in the classroom.” Existing thinking treats the platform like an LMS — it would measure completion (registered, attended, survey done) and stop there.

The actual product goal, verbatim from the v3 strategy, is to reduce the time between learning and improved practice. The platform must therefore measure and drive behavioral change — did the teacher apply the strategy, how fast, how many times before mastery — and intervene when expected behavior is absent.

Premises (to confirm before building)

1. Behavior over completion. The platform’s reason to exist is application speed/frequency, not course completion. Every metric ties to application. (If wrong, this is just another LMS.)
2. The 6-stage cycle is the spine. Prepare → Engage → Practice → Apply → Reflect → Adjust is the shared vocabulary on every screen. The v2 7-stage naming is deprecated.
3. Five roles. Participant, Learning Administrator, Instructional Strategist, Platform Manager, Content Creator. Content Creator’s day-to-day flow is undefined and out of scope for v1 (see content-creator-role).
4. HubSpot stays commercial; the platform owns delivery. v1 enters engagement data manually (PM); the HubSpot pull is a later adapter, not a v1 dependency (hubspot-sync).
5. Patterns, not individuals. Every Instructional-Strategist-facing analytic is aggregate by default; surfacing an individual requires an explicit, logged action.

Goal / non-goals

Premise gate resolved (Phase 1 CEO review): v1 narrowed to Phase 1 only, shipped to one pilot cohort, with IS-observed application evidence added alongside teacher self-report so the headline time-to-apply metric is corroborated rather than trusted blindly. Phase 2 (context layer) is funded only after the pilot proves applications actually get logged. Both the Claude and Codex strategy voices recommended this; the user confirmed.

Goals (v1 = Phase 1 + measurement integrity): ship the behavioral core (Practice + Apply phases, 48h gate, nudge cascade, mark-complete → survey → certificate, locked resources) to a single pilot cohort. The ApplicationEvent backbone records evidence_type ∈ {self_report, artifact, observation}; the IS logs observed application on a sample so self-report drift is measured during the pilot. Seed a minimal application-oriented microlearning set so Apply-phase nudges have something to point at.

Non-goals (deferred): Phase 2 context layer (School Context Profile, Cohort Snapshot, Context Brief, pulse check, intro video) — deferred until the pilot validates the loop; full Platform Manager automation + pattern detection (Phase 3); HubSpot pull/push + case-study pipeline (Phase 4); Content Creator authoring workflow (post-Phase-4, blocked on a working session); native mobile apps; SCORM/LMS import.

Architecture (proposed, see data-model)

• Stack: TypeScript end to end. Next.js (App Router) web app; Postgres (Supabase) with row-level security; Supabase Auth for the five roles; a job runner for the timed nudge cascade (Supabase scheduled functions or a small worker).
• Core entities: School, SchoolContextProfile (versioned), Engagement, Cohort/CohortSnapshot, Participant + LearnerProfile, ActionPlan, ApplicationEvent (the metric backbone), PulseResponse, Reflection/Survey, Certificate, ContentAsset + VisibilityTransition, IntroVideo, InterventionTrigger, NextEngagementSignal.
• Enums frozen up front: the 6 cycle phases, readiness 1–5, change-pressure tags, priority focus areas, attendee groups, evidence types, content visibility states.
• Privacy enforced at the query layer, not just UI: pulse aggregates never expose individual scores; individual-data access is logged.

Phased delivery

Phase 1 — Foundation (behavioral core) — v1

• Adopt 6-stage cycle vocabulary across all dashboards (shared phase-ribbon component + enum).
• Practice phase: ActionPlan object (what / when / with whom), submitted in-session.
• Apply phase: 48-hour application gate with three branches (≤24h / 24–48h / delayed / attempted-failed). ApplicationEvent capture with evidence_type ∈ {self_report, artifact, observation}; IS logs observed application on a pilot sample to measure self-report drift.
• Nudge cascade at 24h / 48h / 5d (Apply-phase subset of the intervention layer).
• Mark-complete (IS action) → opens application-tracking window, triggers participant survey, triggers certificate eligibility.
• Survey gate → certificate (visible-but-locked until survey done).
• Locked-resources mechanism (D1 visible-greyed pre; D2 IS release post).
• Decisions needed first: cycle naming, application evidence, timer anchor.

Phase 2 — Context layer — v1

• LA School Context Profile (A1–A5): readiness, change tags, top-3 priorities, narrative note; <5 min, reusable, versioned, school-level with workshop-level override.
• Cohort Snapshot (B1–B2) per engagement.
• IS Context Brief (C1) + Strategist Insights (E2–E4): % logged in, % watched intro, pulse aggregates, outliers; visible ≥3 days before engagement.
• Pulse check (C1–C3): 1 Likert + 3 MCQs, “diagnostic, not a test”, patterns-only guardrails.
• IS intro video (A1, A2): ≤30s upload → PM approval → auto-associate to assignments.

Phase 3 — Platform Manager + automation — v2

• Full PM flow; publishing-rule engine (4 visibility states + transition log); full intervention layer (all phases, not just Apply); cross-engagement pattern detection + at-risk/high-perf flags; Briefing Report in-platform intake.

Phase 4 — Business + Content loop — v2

• Next-engagement signal routed LA → PM → HubSpot (LA-first); case-study capture; Content Creator backlog feed; time-to-apply + mastery-curve metrics surfaced to sales.

Metrics that define success

• % applied within 24h / 48h / 5d; repeat-application rate; avg & median time-to-first-application; applications-to-mastery. Filterable by readiness / change load / priority once Phase 2 lands.
• Guardrail metric: nudge volume per participant per week stays under a cap (no fatigue).

Test strategy (high level)

• Unit: enum integrity, visibility state-machine transitions, timer-window math.
• Integration: mark-complete fan-out (survey + certificate + tracking window); nudge cascade firing on absence; pulse-aggregate query never leaks individual scores.
• E2E: full participant happy path (invite → apply → certificate) + each Apply branch.

Key risks

• Self-report-only application data is soft — mitigated by optional artifact upload + IS observation later.
• Nudge fatigue — bounded 1–3 nudges + global weekly cap + IS mute.
• Context-layer adoption — if LAs don’t fill the profile, IS prep stays generic; keep it <5 min.
• Privacy — teacher-facing “not evaluative” trust posture is load-bearing; enforce patterns-only at the data layer.

Rollout

Ship Phase 1 to one pilot school/cohort, instrument time-to-apply, validate the cycle approach produces application evidence, then add Phase 2 context. Phases 3–4 only after the pilot proves the behavioral loop works.

Phase 2 — Design Review

In-scope v1 surfaces (post premise gate): Participant dashboard and Instructional Strategist dashboard (behavioral-core subset). Context Brief, intro video, Strategist Insights, pulse, and the LA/PM dashboards are Phase 2 — mark them “future” in any v1 build so the implementer doesn’t build Phase 2 by accident (Codex scope-leakage catch).

Phase 2 dual voices — design consensus (litmus scorecard)

DESIGN DUAL VOICES — CONSENSUS TABLE
═══════════════════════════════════════════════════════════════════
  Dimension                              Claude   Codex   Consensus
  ────────────────────────────────────── ──────── ─────── ──────────
  1. Information hierarchy serves user?  Partial  Partial CONFIRMED (Participant ok; IS tone wrong)
  2. Interaction states specified?       No(crit) No      CONFIRMED (loading/empty/error/partial absent)
  3. Empty/success state designed?       No(crit) No(crit)CONFIRMED (IS "zero stuck" must read as success)
  4. Specific UI vs generic patterns?    Generic  Generic CONFIRMED (no copy, no hierarchy spec)
  5. Trust posture safe in UI?           No(high) No(high)CONFIRMED (timer/nudge = trust-risk center)
  6. Accessibility sufficient?           No(high) —       Claude-only (mobile-first, captions, contrast)
  7. Scope correct for v1?               —        No(med) Codex-only (Phase-2 widgets leaking in)
═══════════════════════════════════════════════════════════════════
5/7 CONFIRMED by both. Dims 6,7 single-voice → flagged regardless.

7-pass design scorecard (auto-decided, P5 explicit + P1 completeness)

Design — what was examined, nothing flagged

• Color/shape language: the flowchart legend (blue phase / green step / purple new / orange nudge) is a coherent inherited system — no change needed for v1.
• Certificate gating + locked-resources “visible-but-locked”: examined; the pattern is sound and drives return-to-platform. The only risk (LMS-gravity) is a CEO-phase metric concern, not a UI defect.

Design taste decisions → gate

• T1 (nudge tone calibration): how soft is too soft? Recommend warm-but-clear with a self-snooze; reasonable people could prefer more or less hand-holding. → final gate.

Phase 2 transition summary

Codex: 5 design concerns. Claude subagent: 6 findings. Consensus: 5/7 confirmed by both, 2 single-voice flagged. All structural fixes auto-decided (states matrix, success states, trust-safe microcopy, consent reframe). 1 taste decision (nudge tone) → gate. Passing to Phase 3 (Eng).

Phase 3 — Eng Review + Dual Voices

What already exists / leverage (greenfield)

No prior code. Reuse libraries, don’t hand-roll: Supabase (auth + Postgres + RLS + pg_cron), a durable job table + FOR UPDATE SKIP LOCKED worker (don’t invent a scheduler), a transactional email/in-app provider. DRY check passes (no codebase to duplicate).

Phase 3 dual voices — eng consensus

ENG DUAL VOICES — CONSENSUS TABLE
═══════════════════════════════════════════════════════════════════
  Dimension                              Claude   Codex   Consensus
  ────────────────────────────────────── ──────── ─────── ──────────
  1. Architecture / data model sound?    No(crit) No(crit)CONFIRMED (metric backbone missing joins)
  2. Test coverage sufficient?           No        No     CONFIRMED (scheduler/privacy/tz untested)
  3. Fire-on-absence implementable?      No(crit) No(crit)CONFIRMED (need durable due-job table)
  4. Privacy enforceable at DB?          No(crit) No(crit)CONFIRMED (RLS + k-anon + logged reveal)
  5. Timezone/window correct?            No(high) No(crit)CONFIRMED (school tz + calendar)
  6. Critical-path decisions resolved?   No(crit) No(crit)CONFIRMED (timer anchor deferred but blocking)
═══════════════════════════════════════════════════════════════════
6/6 flagged by BOTH. Exceptional agreement → all auto-decided (structural, one right answer).

Corrected architecture (supersedes the proposed entity list above)

                         ┌──────────────────────────────────────────────┐
   School ──< Engagement >── InstructionalStrategist                     │
     │           │  │                                                    │
     │           │  └──< EngagementStrategy >── Strategy   (NEW: mastery │
     │           │                                          curves need  │
     │           │                                          a 1st-class   │
     │           │                                          Strategy)     │
     │           ├──< Cohort/CohortSnapshot >──< Participant + LearnerProfile
     │           │                                    │                   │
     │           │   mark-complete ─────► ApplicationTrackingWindow (NEW) │
     │           │   (records metric ANCHOR = engagement-end, audited;    │
     │           │    NOT the late button-click time)                     │
     │           │        │                                               │
     │           │        ├─► enqueue intervention_job × {24h,48h,5d}     │
     │           │        │   (NEW: due_at, status, idempotency_key,      │
     │           │        │    locked_at, attempt_count, suppressed_reason)│
     │           │        └─► survey + certificate eligibility            │
     │           │                                                        │
   ActionPlan ──┴──< ApplicationEvent  (FK: action_plan_id NEW,          │
     (what/when/whom)    strategy_id→Strategy, evidence_type ∈            │
                         {self_report, artifact, observation},            │
                         attempt_number via unique constraint OR          │
                         ROW_NUMBER() — no stored race)                   │
                                                                          │
   Worker:  SELECT … FROM intervention_job WHERE due_at<=now()           │
            AND status='pending' FOR UPDATE SKIP LOCKED                   │
            → re-check absence in same txn → insert nudge_delivery        │
            (idempotency_key) → decrement weekly-cap ledger (txn)         │
   PRIVACY: IS/LA roles DENIED direct SELECT on pulse/application rows;   │
            only SECURITY DEFINER aggregate views w/ HAVING count(distinct│
            participant)>=5 (k-anon); individual reveal = logged function │
            writing individual_data_reveal in the same txn.               │
                         └──────────────────────────────────────────────┘

Auto-decided architecture fixes (P5 explicit + P3 pragmatic)

Failure modes registry

NOT in scope (Eng, v1)

Phase 2 context-layer tables (SchoolContextProfile versioning + pinning, PulseResponse, IntroVideo) — schema-stubbed only; their RLS policies designed now (E5) but UIs deferred. Phase 3/4 entirely out.

Test plan

Written to disk: ~/.gstack/projects/inspired-applied-learninh/brandon-main-test-plan-20260527-100703.md (test diagram + 8 critical cases + unit/integration/E2E breakdown).

Phase 3 transition summary

Codex: 6 findings (5 critical, 1 high). Claude subagent: ~12 findings across 6 areas. Consensus: 6/6 dimensions confirmed by both. All auto-decided (E1–E7 are structural). No eng taste decisions — the answers are determined. Passing to Final Gate.

Cross-Phase Themes (flagged independently in 2+ phases — high-confidence)

1. “Applied” ≠ “improved practice.” CEO (metric is a proxy that can drift) + Eng (timer anchor must be engagement-end, not button-click; add observation evidence) + Design (a 48h countdown reads as a test). All three phases. → addressed by premise gate (IS evidence) + E6.
2. The “not evaluative” trust posture is fragile and crosses the stack. Design (nudge/timer microcopy, no individual watchlists) + Eng (RLS k-anonymity + logged reveal, not app-code promises) + CEO (patterns-vs-coaching tension). All three. → addressed by E5 + design fixes
   • a “consent + explicit norms” note.
3. Absence is the core mechanic and the core risk. CEO (empty-dashboards 6-month regret) + Design (empty/success states unspecified — the IS “zero stuck” state IS the product) + Eng (fire-on-absence needs a durable due-job table). All three. → addressed by states matrix + E1 + E7 + the pilot’s log-rate validation.

Decision Audit Trail