Standalone HTML Viewer

A docs file you can sync to Cloudflare as its own URL.

This file is generated from the real repo docs and can be deployed separately from the app. It is useful when you want a simple public status/docs URL backed by one HTML file.

Start with the plain-English summary Jump to the live docs

What This Is

The platform is being built to teach one real AI-assisted workflow well before it tries to teach everything.

In plain English: instead of a giant generic AI course, we are building a product that understands the learner's job, teaches a small number of useful skills, and helps them apply those skills to recurring work like reporting and presentation prep.

Done

  • The product direction is locked around one clear first slice instead of a broad MVP carryover.
  • The platform contracts are written down, including learner fingerprint, planner boundaries, module rules, and evaluator output.
  • A clean web app scaffold exists with overview, onboarding, workspace, docs, and now a standalone HTML docs file.
  • The first four Level 1 modules are seeded and the bounded starter-path planner seam exists in code.

Next

  • Save learner data in a real database instead of demo seed objects.
  • Turn onboarding into a real flow that captures and confirms the learner's workflow.
  • Generate and store the starter path through an API, not hardcoded demo state.
  • Connect the workspace to real lesson state, evaluator results, and progression rules.

What You Need To Do

  • Review the docs and tell me where the product feels unclear, too technical, or too broad.
  • Use the preview pages and react like a real learner or buyer: what feels strong, weak, generic, confusing, or exciting?
  • When you want a UI change, describe the outcome you want in plain language. That feedback can be translated into product and code changes.

Build Outline

A non-technical version of the build plan

1. Understand the learner

We first capture who the learner is, what job they do, and which real weekly task matters most to them.

2. Build a starter path

The system then chooses a small sequence of lessons that fits that learner's workflow instead of showing a giant generic course.

3. Practice in a live workspace

The learner tries prompts, sees results, and gets coached feedback instead of only reading theory.

4. Track real progress

The platform decides whether the learner should retry, get a small reinforcement step, or move forward.

Live Docs

These cards are generated from the current repo files

README README.md Project Status docs/PROJECT_STATUS.md Decision Log DECISIONS_LOG.md Changelog CHANGELOG.md Preview And Review docs/PREVIEW_AND_REVIEW.md Platform Core Contracts Platform/01_Canonical/PLATFORM_CORE_CONTRACTS.md First Platform Slice Platform/01_Canonical/FIRST_PLATFORM_SLICE_SPEC.md Implementation Sequence Platform/01_Canonical/IMPLEMENTATION_SEQUENCE.md

README

README.md

The simplest overview of what this repo is, what is inside it, and how to preview it.

AI Native Academy Platform

Fresh-build workspace for the real AI Native Academy platform.

This repo is intentionally not an extension of the old MVP architecture. It starts from locked platform contracts, a bounded first slice, and a clean-room app scaffold aligned to the capability-first product direction.

What This Repo Contains

  • canonical build docs in [Platform/01_Canonical](/Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical)
  • a Next.js 15 + TypeScript application shell in [app](/Users/Ali/conductor/repos/ainativeplatform/app)
  • typed domain contracts in [src/domain](/Users/Ali/conductor/repos/ainativeplatform/src/domain)
  • first-slice seed data and demo state in [src/seeds](/Users/Ali/conductor/repos/ainativeplatform/src/seeds)
  • contract tests in [tests](/Users/Ali/conductor/repos/ainativeplatform/tests)

Current Product Boundary

The active product target is:

- META-CLARITY-01 - META-CONTEXT-02 - META-CONSTRAINTS-03 - META-WORKFLOW-06

  • Track 1
  • Level 1
  • one workflow-aware starter path
  • one anchor persona: marketing manager
  • one bounded reporting/presentation workflow corridor
  • four canonical modules:

Canonical Docs

Start here:

  • [PLATFORM_CORE_CONTRACTS.md](/Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/PLATFORM_CORE_CONTRACTS.md)
  • [FIRST_PLATFORM_SLICE_SPEC.md](/Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/FIRST_PLATFORM_SLICE_SPEC.md)
  • [LEARNER_FINGERPRINT_SCHEMA.md](/Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/LEARNER_FINGERPRINT_SCHEMA.md)
  • [MODULE_AND_EVALUATOR_CONTRACTS.md](/Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/MODULE_AND_EVALUATOR_CONTRACTS.md)
  • [IMPLEMENTATION_SEQUENCE.md](/Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/IMPLEMENTATION_SEQUENCE.md)

App Status

Implemented so far:

  • clean-room Next.js app scaffold
  • overview page
  • onboarding contract surface
  • workspace shell
  • typed learner, lesson, evaluator, and planner schemas
  • bounded starter-path planner seam
  • four first-slice module seeds
  • passing contract tests
  • successful production build

Not implemented yet:

  • database persistence
  • auth
  • real onboarding forms
  • real planner API
  • real lesson state transitions
  • real LLM sandbox/evaluator integration
  • dashboard read models

Local Preview

Use local staging for every UI iteration until Cloudflare preview deployment is added.

Install:

corepack pnpm install

Run local staging:

corepack pnpm preview:local

Local preview URL:

  • http://localhost:3001

More detail:

  • [docs/PREVIEW_AND_REVIEW.md](/Users/Ali/conductor/repos/ainativeplatform/docs/PREVIEW_AND_REVIEW.md)
  • [docs/CLOUDFLARE_DOCS_SYNC.md](/Users/Ali/conductor/repos/ainativeplatform/docs/CLOUDFLARE_DOCS_SYNC.md)

Standalone docs HTML:

  • local file route: http://localhost:3001/docs-viewer.html
  • generated from: public/docs-viewer.html
  • regenerate with: corepack pnpm docs:html
  • Cloudflare URL: https://ainativeplatform-docs.pages.dev
  • redeploy with: corepack pnpm docs:cloudflare:deploy

Quality Checks

Run:

corepack pnpm test
corepack pnpm build

Workflow

This repo follows the gstack workflow in [AGENTS.md](/Users/Ali/conductor/repos/ainativeplatform/AGENTS.md) and [CLAUDE.md](/Users/Ali/conductor/repos/ainativeplatform/CLAUDE.md).

Normal sequence:

  • shape the feature
  • run plan review
  • implement
  • review
  • preview and QA
  • ship

Current Priority

The next priority is not more UI polish.

The next priority is turning the current scaffold into a real first-slice loop:

  • persistence schema
  • onboarding API and normalization
  • starter-path planner API
  • lesson/workspace data flow
  • evaluator integration

Project Status

docs/PROJECT_STATUS.md

A snapshot of what is done, what is still missing, and where the project currently stands.

Project Status

Status date: 2026-04-16

Current State

The repo has moved from planning-only into early implementation.

Done

- / - /onboarding - /workspace

- /docs

- /docs-viewer.html

- https://ainativeplatform-docs.pages.dev

  • canonical planning layer created
  • first slice bounded and documented
  • learner fingerprint schema documented
  • module and evaluator contracts documented
  • implementation sequence documented
  • app scaffold created
  • first three routes created:
  • docs viewer route created:
  • standalone docs HTML generated:
  • standalone docs HTML deployed to Cloudflare Pages:
  • domain schemas implemented with Zod
  • first-slice module seeds implemented
  • bounded starter-path planner seam implemented
  • tests passing
  • production build passing

In Progress

  • turning the scaffold into a real first-slice loop

Not Started

  • database schema and persistence
  • auth and identity
  • onboarding submission flow
  • planner API
  • lesson instance persistence
  • sandbox model integration
  • evaluator integration
  • dashboard read models
  • Cloudflare preview deployment

Biggest Risks

  • over-investing in UI before the data and engine loop is real
  • letting demo seed state masquerade as product progress
  • widening the module corridor before the first loop is proven

Recommended Next Priorities

  • persistence schema and storage layer
  • onboarding normalization and confirmation flow
  • planner API and stored starter-path generation
  • workspace data loading from real state
  • evaluator integration and progression transitions

Decision Log

DECISIONS_LOG.md

The key product and engineering decisions that have already been locked.

Decisions Log

This file records the highest-signal product and engineering decisions for the fresh build.

2026-04-16

Decision: Build the platform fresh instead of extending the MVP

Reason:

  • the MVP validated the direction
  • the MVP architecture should not become the company architecture
  • the new platform needs clean contracts, bounded engine logic, and workflow-fingerprint personalization

Decision: Use a 3-source merge for the platform definition

Sources:

  • canonical Platform/ and repo docs as referee layer
  • downloaded Claude planning docs as operating-spec layer
  • MVP/reference evidence as proof-and-learning layer

Decision: Workflow fingerprint is the primary personalization object

Reason:

  • job title and O*NET remain useful scaffolds
  • the real personalization signal is the learner’s workflow reality

Decision: First slice is bounded to one workflow-aware Level 1 corridor

Scope:

- META-CLARITY-01 - META-CONTEXT-02 - META-CONSTRAINTS-03 - META-WORKFLOW-06

  • anchor persona: marketing manager
  • anchor workflow: recurring reporting and presentation preparation
  • corridor modules:

Decision: Intake is confidence-gated before planning

Reason:

  • planner quality depends on typed, confirmed learner/workflow data
  • low-confidence interpretation must fork into a lightweight confirmation step

Decision: Planner is bounded and snapshot-based

Reason:

  • the platform should not regenerate curriculum on every page load
  • the first slice should sequence from the bounded eligible set only

Decision: Evaluator receives typed payloads, not raw user intake as instructions

Reason:

  • protects the trust boundary
  • keeps scoring tied to canonical rubric contracts

Decision: Reinforcement stays inside the corridor

Reason:

  • first-slice progression must stay understandable and testable
  • no full in-level replanning

Decision: Local staging is the default preview path until Cloudflare preview is added

Reason:

  • it gives every new UI a stable review URL immediately
  • it avoids waiting on deployment plumbing before product iteration

Current local preview URL:

  • http://localhost:3001

Changelog

CHANGELOG.md

A running record of what changed in the repo.

Changelog

All meaningful repo changes should be recorded here in short, product-relevant language.

2026-04-16

Added

  • canonical platform planning docs for the fresh build
  • learner fingerprint schema
  • module and evaluator contracts
  • implementation sequence for the first slice
  • clean-room Next.js 15 + TypeScript application scaffold
  • overview, onboarding, and workspace shell routes
  • typed schemas for learner, lesson, planner, and evaluator domains
  • first-slice seed data for the four Level 1 modules
  • bounded starter-path planner seam
  • contract tests and build verification
  • project README
  • decisions log
  • preview and review guide
  • project status snapshot
  • HTML docs viewer route at /docs
  • standalone generated docs HTML at public/docs-viewer.html
  • Cloudflare docs sync guide
  • Cloudflare Pages deployment for standalone docs viewer

Changed

  • locked the first production corridor to the four Level 1 modules
  • formalized confidence-gated intake and typed trust-boundary rules
  • formalized snapshot-based starter-path generation instead of runtime replanning
  • standardized local preview on http://localhost:3001
  • added one-command docs deploy flow for Cloudflare Pages

Verified

  • corepack pnpm test
  • corepack pnpm build

Preview And Review

docs/PREVIEW_AND_REVIEW.md

How to preview the UI, review it, and give feedback in a way that helps iteration.

Preview And Review

This project should always have a live preview path for UI work.

For now, the required preview path is local staging.

Current Preview Mode

Default preview mode:

  • local Next.js dev server

Preview command:

corepack pnpm preview:local

Preview URL:

  • http://localhost:3001

Review Loop

When a new UI is added or changed, use this loop:

  • run corepack pnpm preview:local
  • open http://localhost:3001
  • compare the UI against the canonical docs
  • capture feedback in plain language
  • revise the route or component
  • rerun corepack pnpm test and corepack pnpm build

How To Give Feedback

The fastest useful feedback format is:

  • page or route
  • what feels off
  • what outcome you wanted instead
  • whether the issue is structure, copy, hierarchy, spacing, or workflow realism

Examples:

  • “On /workspace, the evaluator panel feels too secondary. Make it feel like the core feedback loop.”
  • “On /onboarding, this reads too generic. Make it feel more like reporting and deck-prep reality.”
  • “The top section is clear, but the visual hierarchy is too flat.”

What To Review

For every UI pass, review:

  • workflow realism
  • hierarchy and readability
  • whether the page reflects the bounded first slice
  • whether the learner context feels typed and intentional, not generic filler
  • whether the page supports the actual product loop

Next Upgrade

The next preview upgrade should be Cloudflare preview deployment.

When added, this doc should be updated with:

  • preview deploy command
  • preview URL pattern
  • how to share preview links
  • how to test production-like behavior

Until then, local staging is the required preview path.

Platform Core Contracts

Platform/01_Canonical/PLATFORM_CORE_CONTRACTS.md

The high-level rules that define what the platform is and how it must behave.

Platform Core Contracts

Status: Draft Repo: ainativeplatform Purpose: lock the minimum permanent contracts for the fresh platform build.

Contract Method

Every section carries a provenance marker:

  • Adopted means pulled over essentially as-is from an existing source.
  • Adapted means the source was strong but needed normalization or conflict resolution.
  • New means this planning pass is making an explicit decision not yet locked elsewhere.

Source Precedence

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/CANONICAL_DOCS_INDEX_2026-04-16.md
  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/LOCKED_PLATFORM_DECISIONS_2026-04-16.md
  • /Users/Ali/Documents/GitHub/anacademy/docs/ANA_CLAUDE_VISION_TO_PLATFORM_REPORT_2026-04-16.md

If sources conflict, resolve in this order:

  • Platform/01_Canonical/ docs in the source repo
  • canonical synthesis docs in /Users/Ali/Documents/GitHub/anacademy/docs/
  • downloaded Claude planning docs in /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/
  • MVP and prototype code as reference-only evidence

The implementation in this repo should inherit only from locked contracts, not from old scaffolding.

Product Scope Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/LOCKED_PLATFORM_DECISIONS_2026-04-16.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Academy_Vision_Locked_v1.md

The platform is:

  • a capability-first AI fluency platform
  • personalized by workflow fingerprint, readiness, goals, blockers, and role reality
  • delivered through a split-screen guided practice workspace
  • governed by evaluator-based practice and mastery-based progression

The platform is not:

  • a generic AI course library
  • a role-pack-first engine
  • a prompt-hack repository
  • an extension of the old MVP architecture

Track boundary:

  • Track 1 is the primary initial product, covering Levels 1-3
  • Track 2 is a later, gated expansion covering Levels 4-5

Learner Profile Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/PLATFORM_BUILD_ACTION_PLAN_2026-04-16.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Academy_Strategy_Working_Doc.docx
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Parallel_Execution_Plan.md

The learner profile stores durable and updateable learner context.

Required fields:

  • learner_id
  • full_name
  • email
  • job_title_raw
  • company
  • industry
  • seniority
  • canonical_role_id or onet_code when available
  • readiness_label
  • mindset
  • pace
  • primary_goal
  • time_commitment
  • tool_environment
  • current_stage
  • created_at
  • updated_at

Rules:

  • job_title_raw is market-facing input, not the deepest product identity
  • the learner profile may reference a canonical role scaffold, but must not collapse into role-pack logic
  • learner profile persistence is required in v1, not optional

Workflow Fingerprint Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/LOCKED_PLATFORM_DECISIONS_2026-04-16.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Academy_Strategy_Working_Doc.docx
  • /Users/Ali/Documents/GitHub/anacademy/docs/ANA_CLAUDE_VISION_TO_PLATFORM_REPORT_2026-04-16.md

The workflow fingerprint is the primary runtime personalization object.

Required fields:

  • primary_workflow
  • secondary_workflow
  • tertiary_workflow
  • recurring_outputs
  • key_stakeholders
  • common_inputs
  • common_tools
  • friction_points
  • high_leverage_opportunities
  • risk_sensitivity
  • confidence_level

Rules:

  • workflows must be described in plain-English work language, not ontology language
  • O*NET and market data can suggest likely workflows, but the learner-confirmed fingerprint wins
  • the fingerprint is a product object, not just an intake artifact
  • if intake confidence is low, the system must fork into a lightweight confirmation step before plan generation
  • raw learner text must be normalized into typed fields before it reaches planner or evaluator prompts

Capability Spine Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Static_Spine_v1.html
  • /Users/Ali/Documents/GitHub/anacademy/docs/ARCHITECTURE_PIVOT_CAPABILITY_FIRST_2026-04-14.md
  • /Users/Ali/Documents/GitHub/anacademy/docs/ANA_CLAUDE_VISION_TO_PLATFORM_REPORT_2026-04-16.md

The capability spine is static, tool-agnostic, and versioned.

Rules:

  • the spine contains durable cognitive and workflow capabilities only
  • tool names do not live on the spine
  • delivery methods do not live on the spine
  • module content expresses the spine using current tools and examples
  • the evaluator checks demonstrated capability, not just completion

Canonical level model:

| Level Code | Canonical Title | Legacy Alias | Purpose | |---|---|---|---| | L1 | Meta Thinker | MetaPrompting | deliberate communication and prompt judgment | | L2 | Operator | — | daily workflow application | | L3 | Centaur | — | human-AI workflow design | | L4 | Builder | — | tools, systems, and controlled automation | | L5 | Orchestrator | — | multi-step AI systems and governance |

Decision:

  • Meta Thinker is the canonical display name
  • MetaPrompting remains an accepted migration alias in old materials and seed templates

Module Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Level1_Modules_Complete.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Parallel_Execution_Plan.md

Every module must contain:

  • template_code
  • level_code
  • track
  • module_order
  • title_template
  • description_template
  • learning_objective
  • sidebar_lesson_markdown
  • sandbox_prompt_starter
  • sandbox_system_prompt
  • evaluator_criteria
  • required_capabilities
  • tags
  • estimated_minutes
  • pass_threshold

Optional but recommended:

  • mindset_variants
  • example_good_prompt
  • example_bad_prompt
  • success_criteria

Rules:

  • modules teach one clear concept at a time
  • modules are fixed-bones templates with personalized placeholders
  • personalization changes examples, framing, workflows, and tone, not the underlying lesson purpose
  • the first-slice planner may only choose from the canonical eligible module set defined by the slice spec

Lesson Delivery Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/docs/CONTENT_DELIVERY_MODEL.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Build_Strategy_Master.md

Every lesson instance must provide:

  • lesson sidebar content
  • a realistic starter prompt or task
  • a live sandbox attempt area
  • evaluator output after each attempt
  • retry guidance
  • completion state when pass threshold is met

Canonical interface:

  • left panel: concept, explanation, examples, exercise framing
  • right panel: prompt attempt, AI response, evaluator feedback, retry/completion actions

Evaluator Output Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Level1_Modules_Complete.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Parallel_Execution_Plan.md

Every evaluator result must return:

  • score_total
  • max_score
  • is_passing
  • dimension_scores
  • strengths
  • gaps
  • required_fixes
  • suggested_next_attempt
  • concept_focus

Rules:

  • evaluator criteria are module-specific, not generic
  • evaluator output should feel like coaching, not exam prose
  • evaluator results must be persisted as evidence, not transient UI decoration
  • evaluator prompts receive typed payloads plus canonical template text, never raw untrusted learner text as instruction-bearing context

Mastery And Progression Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/LOCKED_PLATFORM_DECISIONS_2026-04-16.md
  • /Users/Ali/Documents/GitHub/anacademy/docs/MVP_VS_FUTURE_ENGINE_DECISION_MEMO_2026-04-14.md
  • /Users/Ali/Documents/GitHub/anacademy/docs/ANA_CLAUDE_VISION_TO_PLATFORM_REPORT_2026-04-16.md

Progression is mastery-based, not completion-based.

Required concepts:

  • attempt_history
  • mastery_score
  • pass_threshold
  • module_completion
  • level_completion
  • promotion_rule
  • reinforcement_rule

Rules:

  • a module completes only when the evaluator pass threshold is met
  • level progression can depend on both module completion and mastery sufficiency
  • re-planning is allowed between levels, not as free-form curriculum chaos
  • weak mastery should trigger reinforcement, not silent advancement
  • inside a bounded corridor, weak mastery should trigger corridor-local reinforcement before progression, not full in-level re-planning

Planner Contract

Provenance: New

The planner is dynamic, but bounded.

Rules:

  • use a two-stage planner
  • stage 1 filters eligible modules from canonical templates using deterministic rules
  • stage 2 ranks and sequences those eligible modules
  • an LLM may assist with ranking or rationale generation, but it may not invent new modules or new curriculum structure
  • planner output must pass a strict schema validator before persistence
  • the starter path is snapshotted at generation time and only re-planned at explicit checkpoints

Explicit re-plan checkpoints:

  • corrected role/workflow confirmation after low-confidence intake
  • end-of-level checkpoints
  • manual reset or admin-triggered rebuild

State Ownership Contract

Provenance: New

Use a three-tier state model.

Tier 1, durable state:

  • learner profile
  • workflow fingerprint
  • attempt history
  • evaluator evidence

Tier 2, derived persistent state:

  • starter path snapshot
  • module progression snapshot
  • reinforcement decisions

Tier 3, derived recomputable state:

  • dashboard summaries
  • next-step messaging
  • display-oriented rollups

Rule:

  • if a value can be recomputed deterministically from Tier 1 and Tier 2, do not persist it as a separate source of truth

Naming Contract

Provenance: New

Use a canonical-code, display-label, alias-map split.

Rules:

  • persist only stable machine codes such as L1
  • render canonical display labels such as Meta Thinker
  • keep legacy aliases such as MetaPrompting only in a translation map for import, migration, and compatibility
  • aliases are forbidden in persisted product state

Role And Market Context Contract

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/PERSONALIZATION_DATA_FOUNDATION_PLAN_2026-04-16.md
  • /Users/Ali/Documents/GitHub/anacademy/docs/MULTI_SOURCE_ROLE_INTELLIGENCE_PIPELINE_2026-04-16.md

Role and market data is an overlay layer.

Allowed uses:

  • title normalization
  • role-family matching
  • tool and workflow overlays
  • market-language enrichment
  • industry context

Forbidden use:

  • redefining the curriculum spine from noisy job-market data

Fresh-Build Contract

Provenance: Adopted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/README.md
  • /Users/Ali/Documents/GitHub/anacademy/Platform/03_Archive_Map/REPO_RESET_ARCHIVE_MAP_2026-04-16.md

This repo is a clean-room build target.

That means:

  • old code may inform implementation
  • old code may not define contracts
  • any borrowed structure must first be named in canonical docs

Immediate Follow-On Docs

Provenance: Adopted Primary source:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/PLATFORM_BUILD_ACTION_PLAN_2026-04-16.md

The next docs that should exist after this one are:

  • FIRST_PLATFORM_SLICE_SPEC.md
  • LEARNER_FINGERPRINT_SCHEMA.md
  • MODULE_AND_EVALUATOR_CONTRACTS.md
  • IMPLEMENTATION_SEQUENCE.md

First Platform Slice

Platform/01_Canonical/FIRST_PLATFORM_SLICE_SPEC.md

The first end-to-end product slice the build is currently aiming at.

First Platform Slice Spec

Status: Draft Repo: ainativeplatform Purpose: define the first real end-to-end slice for the fresh platform build.

Slice Summary

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/PLATFORM_BUILD_ACTION_PLAN_2026-04-16.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Curriculum_MarketingManager_Curious.html
  • user evidence from MVP/community sessions

The first slice is:

Track 1, Level 1, workflow-aware starter path for a manager with a recurring reporting and presentation workflow.

This slice proves:

  • onboarding and learner profile capture
  • workflow fingerprint capture
  • first personalized path generation
  • first Level 1 module delivery
  • live sandbox attempt
  • evaluator feedback
  • completion and unlock behavior
  • persistence of learner state and evidence

Why This Slice

Provenance: Adapted

This is the best first slice because:

  • it is grounded in a real observed workflow, recurring reporting and presentation work
  • it is repeated, measurable, and time-sensitive
  • it fits the current Track 1 promise, one workflow that used to take hours now takes much less time
  • it exercises the exact contracts the platform says matter

Persona Anchor

Provenance: Adapted Primary sources:

  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Curriculum_MarketingManager_Curious.html
  • user evidence from Noor

Anchor persona:

  • title: Marketing Manager
  • recurring workflow: weekly performance reporting and stakeholder presentation preparation
  • current pain: gathers inputs from multiple systems, synthesizes manually, builds decks by hand
  • desired outcome: reusable AI-assisted reporting workflow with better insight quality and significant time savings

This persona is the anchor, not the entire market.

In-Scope User Journey

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/PLATFORM_BUILD_ACTION_PLAN_2026-04-16.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Parallel_Execution_Plan.md

The slice starts when a new learner lands on onboarding.

Step 1: Intake

Collect:

  • name and email
  • raw title
  • industry
  • self-described AI familiarity
  • mindset
  • pace preference
  • time commitment

Step 2: Workflow Fingerprint

Collect:

  • primary workflow
  • secondary workflow
  • typical outputs
  • stakeholders
  • common tools
  • friction points

The fingerprint should be plain-English and learner-confirmed.

If intake confidence is low:

  • do not generate a plan yet
  • show 2-3 suggested role/workflow interpretations
  • require lightweight user confirmation or correction first

Step 3: Starter Path Generation

Generate a bounded Level 1 starter corridor personalized to the learner’s workflow.

The first slice should not generate the whole platform. It should generate a clear starter sequence.

Planner shape for this slice:

  • two-stage bounded dynamic planner
  • stage 1 filters from the canonical first-slice eligible set
  • stage 2 sequences and lightly personalizes within that set
  • output is snapshotted after generation and not recomputed on every page load

Step 4: Module Experience

Show the first module in the split-screen workspace.

The learner:

  • reads the lesson
  • runs the starter prompt
  • reviews AI output
  • receives evaluator feedback
  • retries if needed

Step 5: Completion And Unlock

When the module reaches passing score:

  • mark module complete
  • store evaluator evidence
  • unlock the next module
  • show the learner their progress and why the next module exists

First Release Corridor

Provenance: New Reason: the source material provides many module options, but the first implementation slice needs a bounded corridor.

The first release corridor includes four Level 1 modules:

  • META-CLARITY-01
  • META-CONTEXT-02
  • META-CONSTRAINTS-03
  • META-WORKFLOW-06

Why this corridor:

  • it teaches explicit intent
  • then context injection
  • then constraint design
  • then combines those into a real Monday-morning workflow

This is a complete miniature transformation, not a random module sampler.

For this first slice, these four modules are the canonical eligible set.

The planner may:

  • sequence them
  • attach rationale
  • insert one bounded reinforcement step tied to the same concept

The planner may not:

  • choose modules outside this set
  • synthesize new modules
  • silently widen the corridor

Personalized Workflow Expression

Provenance: Adapted Primary sources:

  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Curriculum_MarketingManager_Curious.html
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Level1_Modules_Complete.md

For the anchor persona, the product should feel like:

  • “this is built for my reporting and deck-prep reality”
  • “the examples sound like my stakeholders and my work”
  • “the evaluator is checking whether I can produce a prompt I would actually use on Monday”

Examples should bias toward:

  • performance summaries
  • stakeholder briefings
  • leadership updates
  • presentation draft support
  • reusable reporting templates

What The Learner Must Achieve

Provenance: Adapted

By the end of this slice, the learner must be able to:

  • write a structured, context-rich prompt for a real reporting task
  • add constraints that make the output usable for a stakeholder audience
  • explain why the first output was weak and how the revision improved it
  • build one reusable workflow for a recurring reporting or presentation task

The final proof artifact is:

one reusable workflow that the learner could actually use for next week’s reporting or presentation prep

Required Data Objects

Provenance: Adapted Primary sources:

  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Parallel_Execution_Plan.md
  • /Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/PLATFORM_CORE_CONTRACTS.md

The first slice requires these persisted objects:

  • learner profile
  • workflow fingerprint
  • user plan or starter path
  • user curriculum rows
  • sandbox attempt history
  • evaluator results
  • module completion state

State ownership for this slice:

  • durable: learner profile, workflow fingerprint, sandbox attempts, evaluator evidence
  • derived persistent: starter path snapshot, progression snapshot, reinforcement snapshot
  • derived recomputable: dashboard summaries and next-step UI messaging

Minimal State Machine

Provenance: Adapted Primary source:

  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Build_Strategy_Master.md

The first slice lesson flow should follow:

  • MODULE_UNLOCKED
  • IN_LESSON
  • ATTEMPT_SUBMITTED
  • AI_RESPONSE_SHOWN
  • EVALUATOR_SHOWN
  • CAN_RETRY or CAN_COMPLETE
  • MODULE_COMPLETE
  • NEXT_MODULE_UNLOCKED

Weak mastery policy inside Level 1:

  • no full re-plan inside the corridor
  • if the learner fails repeatedly or barely passes, inject one bounded reinforcement step tied to the same concept/workflow
  • full re-planning begins only at explicit between-level checkpoints

Non-Goals

Provenance: New

This slice does not need:

  • Track 2
  • full multi-level adaptive re-planning
  • every role family
  • full market-data ingestion
  • complex enterprise features
  • a full prompt library
  • a generalized LMS feature set

Implementation Boundaries

Provenance: Adapted Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/LOCKED_PLATFORM_DECISIONS_2026-04-16.md
  • /Users/Ali/Documents/GitHub/anacademy/Platform/03_Archive_Map/REPO_RESET_ARCHIVE_MAP_2026-04-16.md

Allowed:

  • borrow good ideas and data from MVP and reference layers
  • reuse module and evaluator patterns from the downloaded docs
  • keep the slice narrow and explicit

Not allowed:

  • inherit old MVP contracts because they happen to exist
  • broaden the slice into “all white-collar professionals” at implementation time
  • collapse workflow fingerprint back into simple title routing

Success Criteria

Provenance: Adapted

This slice succeeds if:

  • a learner can onboard and see a path that feels specific to their workflow
  • the first module’s examples clearly reflect their reporting/presentation reality
  • evaluator feedback reliably distinguishes weak attempts from passing attempts
  • the learner completes at least one reusable workflow artifact
  • the product can credibly support the claim that one recurring task can be done faster and with more structure

Test Strategy For This Slice

Provenance: New

The first slice requires a full test pyramid:

  • unit tests for normalization, confidence gating, planner rules, alias mapping, and progression logic
  • integration tests for state persistence and transition integrity
  • one critical E2E flow from onboarding to next unlock
  • eval tests for planner boundedness, evaluator pass/fail stability, and reinforcement triggering

Open Questions For /plan-eng-review

Provenance: New

The next planning pass should resolve:

  • exact storage model for learner plans and module progression
  • exact payload shape for evaluator input and output
  • whether the first slice ships with mocked role overlays or real O*NET-backed matching
  • how to separate canonical level names from migration aliases in code and content
  • how dashboard and lesson views load progression state without pulling full evaluator payloads on every request

Implementation Sequence

Platform/01_Canonical/IMPLEMENTATION_SEQUENCE.md

The planned build order from scaffold to real first slice.

Implementation Sequence

Status: Draft Repo: ainativeplatform Purpose: translate the locked contracts into an execution order for the fresh build so implementation starts from stable interfaces and a bounded first slice.

Source Basis

Primary sources:

  • /Users/Ali/Documents/GitHub/anacademy/Platform/01_Canonical/PLATFORM_BUILD_ACTION_PLAN_2026-04-16.md
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Academy_Strategy_Working_Doc.docx
  • /Users/Ali/Downloads/ANA - Claude - Vision & Planning Docs/AINative_Parallel_Execution_Plan.md
  • /Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/PLATFORM_CORE_CONTRACTS.md
  • /Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/FIRST_PLATFORM_SLICE_SPEC.md
  • /Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/LEARNER_FINGERPRINT_SCHEMA.md
  • /Users/Ali/conductor/repos/ainativeplatform/Platform/01_Canonical/MODULE_AND_EVALUATOR_CONTRACTS.md

Build Principle

Build the first slice end to end before broadening the surface area.

The order is:

  • lock canonical contracts
  • build data shapes and state transitions
  • build the app shell around those contracts
  • build the bounded planner and evaluator loop
  • prove one complete user journey
  • only then widen the corridor or persona set

Recommended Technical Baseline

For the fresh platform build, the recommended baseline is:

  • Next.js 15
  • TypeScript
  • Supabase for application persistence
  • Clerk for auth
  • one LLM adapter layer for sandbox and evaluator calls

Rules:

  • keep the app architecture clean-room and capability-first
  • do not drag MVP route structure or old role-pack assumptions into the new implementation
  • use the MVP only as a reference layer for evidence and data assets

Phase 1: Repository Foundation

Goal: make the workspace implementation-ready.

Deliverables:

  • base app scaffold
  • environment contract
  • linting, formatting, and test runner
  • typed domain folders for learner, planner, lesson, evaluator, and progression

Suggested folders:

  • app/
  • src/domain/learner/
  • src/domain/planner/
  • src/domain/lesson/
  • src/domain/evaluator/
  • src/domain/progression/
  • src/lib/llm/
  • src/lib/db/
  • src/lib/validation/
  • tests/

Phase 2: Data And Validation Layer

Goal: implement the canonical objects before UI flow.

Build in this order:

  • learner profile types and validators
  • workflow fingerprint types and validators
  • starter-path snapshot types
  • module template and lesson instance types
  • evaluator request/result types
  • progression and reinforcement decision types

Required outputs:

  • runtime validation schemas
  • persistence mappers
  • canonical seed data format for the four first-slice modules

Rule:

  • no page should own these contracts locally; they belong in the domain layer

Phase 3: Persistence Layer

Goal: persist the first slice without overbuilding.

Minimum tables or collections:

  • learner_profiles
  • workflow_fingerprints
  • fingerprint_resolutions
  • starter_path_snapshots
  • module_templates
  • lesson_instances
  • sandbox_attempts
  • evaluator_results
  • reinforcement_decisions

Rules:

  • durable and derived-persistent state must be stored separately from recomputable display state
  • canonical codes must be persisted, not aliases

Phase 4: Onboarding And Fingerprint Resolution

Goal: build the intake flow and confidence gate.

User-facing flow:

  • collect identity, role, readiness, mindset, pace, and goal
  • collect workflow signals
  • normalize and infer candidate role/workflow interpretations
  • if confidence is low, show 2-3 confirmation options
  • persist confirmed learner profile and workflow fingerprint

Required logic:

  • title normalization
  • confidence scoring
  • confirmation gating
  • planner input snapshot creation

This phase is complete only when the system can reliably produce a planner-safe snapshot.

Phase 5: Bounded Starter-Path Planner

Goal: generate the first stored starter corridor.

Planner design:

  • stage 1 deterministic filter from the four-module eligible set
  • stage 2 bounded sequencing and rationale generation
  • snapshot the output once generated

Stored outputs:

  • ordered lesson instance rows
  • rationale for the chosen sequence
  • unlock state for the first module

Rules:

  • no whole-platform generation
  • no free-form lesson synthesis
  • no runtime widening of the corridor

Phase 6: Lesson Workspace And Sandbox Loop

Goal: deliver one complete split-screen lesson experience.

Build surfaces:

  • lesson rail
  • left-panel lesson content
  • right-panel sandbox
  • AI response view
  • evaluator feedback panel
  • retry and completion states

This phase should ship first for one module, then generalize to all four module codes.

Phase 7: Evaluator And Progression Engine

Goal: implement scoring and bounded progression.

Required logic:

  • build typed evaluator request payloads
  • call the evaluator through one adapter
  • validate evaluator output
  • persist evaluator evidence
  • compute pass/fail
  • decide retry, reinforcement, or unlock-next

Rules:

  • evaluator output must be checked for shape and score integrity before it affects progress
  • progression logic must use canonical thresholds from the module contract

Phase 8: Dashboard And Progress Read Model

Goal: show progress without coupling UI to raw evaluator payloads.

Build:

  • dashboard summary queries
  • current module / next module view
  • simple progress indicators
  • module completion history

Rules:

  • dashboard reads from stored progression snapshots and summary-friendly read models
  • do not load full evaluator blobs just to paint basic UI

Phase 9: Quality Gate

Goal: prove the first slice before expanding scope.

Must-have automated coverage:

  • unit tests for normalization, planner rules, canonical code handling, and progression logic
  • integration tests for persistence and state transitions
  • one end-to-end path from onboarding to second-module unlock
  • evaluator contract tests for score consistency and bounded reinforcement behavior

Manual review checklist:

  • the first slice feels workflow-aware, not generic
  • the examples sound like real reporting and deck-prep work
  • evaluator feedback is specific enough to cause a better retry
  • the user can understand why the next module unlocked

Phase 10: Controlled Expansion

Only after the first slice is stable:

  • add more Level 1 modules
  • add more role/workflow starter examples
  • add richer dashboard and artifact history
  • add pricing and launch plumbing
  • add later levels only after Level 1 activation quality is proven

Explicitly Deferred

Do not build these before the first slice works:

  • Track 2
  • generic course-library browsing
  • unbounded planner generation
  • broad multi-role launch surface
  • enterprise features
  • advanced artifact memory beyond what the first loop needs

Definition Of Ready For Coding

Implementation can begin immediately when:

  • contracts are present in Platform/01_Canonical/
  • domain schemas are derived from those contracts
  • one canonical seed set exists for the four-module corridor
  • one engineer or LLM can explain the first end-to-end slice from the docs alone in under five minutes

Generated from repository docs. Regenerate with corepack pnpm docs:html.