Conceptual architecture for evolving AI Execution Lab into a full AI-native operational learning environment. User models, feature layers, infrastructure implications, and rollout phases.
This document defines the conceptual architecture for the next evolution of AI Execution Lab — from a public engineering journal to a full AI-native operational learning environment. No auth is being built yet. This document defines the architecture so that every decision made before auth is compatible with it.
AI Execution Lab evolves into an execution-based education system where operators, builders, and engineers don't just read about production AI systems — they build real ones, with real tooling, inside a verified learning environment. Progress is tracked. Experiments are shared. Operators develop reputation through documented execution, not credentials or certificates.
This is not a MOOC. It is not a bootcamp. It is an operational environment where the work is the curriculum.
Current default state. No account, no login, full access to all published content.
Capabilities:
Friction: Zero. Anyone who finds the platform via AI search or referral gets immediate value.
Minimal auth — email only. Unlocks persistent progress and basic personalization.
Capabilities (beyond Level 0):
/members/[username] showing completed tracksWhat it doesn't include: Lab workspace, collaboration, publishing, experiment access.
Conversion trigger: User completes a module and wants to continue on a different device. Or wants to share their track progress.
GitHub-connected account. Unlocks execution capabilities — labs, experiments, publishing.
Why GitHub-connected:
Capabilities (beyond Level 1):
Operator Member who has completed at least one full track and published at least one verified execution output.
Capabilities (beyond Level 2):
This is the target user of the platform — someone who has demonstrated execution capability, not just reading.
Organizational account for teams. Enables shared progress tracking, collaborative labs, and private documentation.
Use cases:
Capabilities:
What it is: Replace localStorage progress with server-side progress, synced to account.
Infrastructure needed:
progress table: user_id, track_id, module_id, lesson_id, completed_atPOST /api/progress/complete, GET /api/progress/[user]app/profile/page.tsx and app/members/[username]/page.tsxWhat doesn't change: Content rendering, MDX pipeline, lesson page UI (CompleteButton already exists, just changes its persistence target).
Risk: Minimal. CompleteButton already has the client-side logic. Swapping localStorage → API call is a 1-day change once auth is set up.
What it is: Interactive coding environments embedded in lab-type lessons. Users run actual commands against a sandboxed environment and their output is recorded.
Lab types:
Infrastructure needed:
Complexity: Highest of all feature layers. Defer until Level 2 user base is established.
What it is: Structured framework for running and documenting GEO experiments, automation tests, and content operations.
Experiment types:
Components:
/experiments — sorted by type, status, resultWhy this matters for GEO: Documented experiments with outcomes are exactly the type of specific, verifiable content that AI search systems prefer to cite. An experiments section would be one of the highest-GEO-value additions to the platform.
What it is: A score that reflects demonstrated execution capability — not knowledge consumption.
Reputation inputs (weighted):
Reputation outputs:
/operators leaderboard (opt-in)What it deliberately excludes:
The reputation system is an execution record — not an engagement metric.
What it is: Team workspaces and shared execution environments for organizations.
Components:
Infrastructure:
org_id, member_id, role, joined_atRecommended: Supabase (PostgreSQL + auth + storage + realtime)
Reasons:
Tables needed (by phase):
Phase 1: users, progress
Phase 2: labs, lab_submissions, workspaces
Phase 3: experiments, experiment_results
Phase 4: reputation_events, reputation_scores
Phase 5: teams, team_members, team_workspaces
Recommended: Clerk or Supabase Auth
Auth flows required:
Auth boundary: Only progress sync and lab access require authentication. All content is readable without auth — this is non-negotiable.
No changes to the MDX content pipeline for Phases 1–3. Labs in Phase 2 add a new content type (lab.mdx) with a new frontmatter field: workspace_template: string.
Vercel deployment continues throughout all phases. Supabase is the only new infrastructure dependency. No self-hosted services needed until Phase 4+.
State: Live public platform. No auth. localStorage progress. Full content visible.
Deliverables complete: 5 tracks, 30+ lessons, Failure Archive, Playbooks, Start Here page, ecosystem integration.
Trigger: 100+ recurring monthly users (identifiable via analytics).
Deliverables:
/members/[username])Non-deliverable yet: Labs, experiments, reputation.
Time estimate: 2–3 weeks of engineering.
Trigger: Phase 1 stable, 50+ Level 1 members, at least 3 tracks with full module coverage.
Deliverables:
Time estimate: 4–6 weeks of engineering.
Trigger: Phase 2 stable. GEO track substantially built. Clear demand from operators.
Deliverables:
Time estimate: 2–3 weeks of engineering.
Trigger: Meaningful base of Level 2 members with completed tracks and lab outputs.
Deliverables:
/operators leaderboard (opt-in)Time estimate: 3–4 weeks of engineering.
Trigger: 10+ organizational users expressing team access needs.
Deliverables:
Time estimate: 6–8 weeks of engineering.
1. Auth is additive, never gating Content access never requires authentication. Auth only enables persistence and execution features. Any decision that requires auth to read content violates this principle.
2. Execution outputs are the credentials Certificates, badges, and reputation signals are byproducts of documented execution — not completions of quizzes or watching videos. If a user can't show what they built, the credential means nothing.
3. GEO value compounds with user content User-submitted execution logs and case studies — when published — are genuine production documentation. This is higher-GEO-value than platform-generated content because it adds author diversity and execution variety. User content strategy should be as carefully managed as platform content.
4. Complexity scales with user demand Don't build Phase 3 until Phase 2 is stable. Don't build collaboration until individual tools are used. Each phase must demonstrate user demand before the next begins.
5. The platform eats its own dog food All AI engineering decisions on the platform are documented in the platform. The decisions in this document will be documented in execution logs when they are implemented. This maintains the execution-first principle through the platform's own evolution.
Version 1.0 — 2026-05-18. Next review: when Phase 1 implementation begins.