Pilot status: Sign-in is available for invited users. This static pilot has no migrated business data and server-side route protection is not yet enabled.
Sign in
Prototype — no operational data connected.This page is a static UX prototype. No Supabase, authentication, or real module/sprint data is wired. It does not replace the AEO/Apexti build workspace, and no gate, test, or release status shown here reflects a real decision.

Portal · Module-First

Module Delivery & Sprint Tracker

Operationalises the AI Module Build Lifecycle for governed module development, evidence tracking, sprint delivery, and gate decisions. Authenticated records and RLS validation are not yet connected.

Governing Lifecycle — AI Module Build Lifecycle v1

Source of truth: product/ai_module_build_lifecycle_diagram_v1.md. This tracker operationalises the lifecycle — it does not redefine it. Lifecycle phases and gates are displayed here as a governing reference only.

1

Opportunity Intake

Problem statement, target buyer, evidence of pain, strategic fit.

2

Module Charter

Scope, promised outcome, non-goals, pricing hypothesis, KPIs, risk tier.

3

Discovery & Design

Workflow map, users, data/knowledge plan, assistants, approval points, compliance/security review.

4

Build the Module

Configured module package: lead assistant, specialists, instructions, knowledge, tools, permissions, UI, version record.

5

Test & Validate

Test plan/results, acceptance evidence, known limitations, cost estimate, rollback plan.

6

Pilot Deployment

Pilot configuration, permissions, baseline metrics, support plan.

7

Client Release & Enablement

Client playbook, training, admin guide, escalation route, release notes.

8

Operate & Monitor

Monthly scorecard, issue log, adoption/outcome data, cost/risk signals.

9

Improve & Version

Prioritized backlog, change request, regression test, release notes, updated docs.

Release Gates

Gates are non-negotiable. A gate decision requires a recorded decision maker, date, evidence links, conditions, and rationale. A gate cannot be inferred from task completion alone.

Gate 1

Go / No-Go

Release from concept only if all conditions are met:

  • Clear buyer and operational problem.
  • Specific, measurable client outcome.
  • Reusable module potential across multiple clients.
  • Viable delivery and ongoing-support economics.
  • Risks and data dependencies understood.

Decision record

No decision recorded — no data connected.

Gate 2

Client-Release Readiness

Release from pilot only if all conditions are met:

  • Core workflow passes defined tests with representative inputs.
  • Facts, recommendations, and external-facing outputs have the right human-review controls.
  • Permissions follow least privilege; sensitive-data handling is documented.
  • Failure/escalation path and rollback plan are tested.
  • Client instructions, ownership, and support path are ready.
  • Baseline KPI and monthly review method are established.

Decision record

No decision recorded — no data connected.

Module

No modules — prototype only

A Module is a reusable, deployable client unit. Each module has a stable key, category, owner, promised outcome, risk tier, and canonical source. Status flows from concept through released and operating to retired.

Module KeyStable human-readable identifier (e.g., aeo-reputation-v1).
Module NameFull display name for this module.
Module CategoryControlled taxonomy: ai_operations, marketing, sales, client_service, finance_ops, other.
Problem StatementRepeatable business problem this module solves — not a feature request.
Target BuyerIntended buyer or owner role.
Promised OutcomeSpecific, measurable outcome the module delivers.
Risk Tierlow · moderate · high · restricted.
Module OwnerAccountable internal product owner.
Statusconcept · active_development · pilot · released · operating · retired.
Canonical SourceRequired controlled charter/definition link.

No modules

Module records will appear here once authenticated records and RLS validation are connected.

Module Version

No versions — prototype only

Each Module Version tracks lifecycle phase, release status, and all controlled source links required at each stage. Known limitations and rollback plan are required before pilot or release readiness.

Version KeySemantic/versioned label (e.g., v1.0.0).
Lifecycle PhaseExact approved phase from the governing lifecycle.
Release Statusdraft · non_production · pilot · released · superseded · retired.
Version SummaryConcise change/outcome statement.
Instructions SourceControlled source link — required before test readiness.
Knowledge SourceControlled source link — required before test readiness.
Tools SourceControlled source link — required before test readiness.
Permissions SourceControlled source link — required before test readiness.
Known LimitationsRequired link before pilot/release readiness.
Rollback PlanRequired link before pilot/release readiness.
Linked Work ItemRequired Module Delivery Work Item from the Work Register.

No versions

Module Version records will appear here once a Module exists and authenticated access is enabled.

Sprint Tracker

No sprints — prototype only

A sprint is a time-boxed delivery increment inside a Module Version, aligned to an exact lifecycle phase. Sprint items are bounded work increments with defined acceptance criteria and evidence links — not a generic task board.

Sprint fields

Sprint KeyUnique identifier for this sprint within the module version.
Sprint NameShort descriptive name.
Lifecycle PhaseExact phase this sprint operates within.
Sprint GoalRequired outcome-oriented goal — not a task list.
Start / End DateTime-boxed delivery window.
OwnerRequired sprint owner.
Statusplanned · active · blocked · review · complete · cancelled.
Gate Requirednone · go_no_go · release_readiness · other.
RetrospectiveRequired when complete (link or explicit waiver with reason).

Sprint Increment fields

TitleBounded work increment title.
OwnerPerson responsible for this increment.
Statusplanned · in_progress · blocked · complete.
Acceptance CriteriaHow completion is verified.
Evidence SourceLinked controlled source or evidence record.
Dependency / RiskKnown dependencies or blockers.
Completion EvidenceRequired when marked complete.

No sprints

Sprint and increment records will appear here once a Module Version is active and authenticated records are connected.

Evidence & Source-Link Posture

Portal records store metadata and links — not document bodies. Controlled documents and GitHub remain canonical sources. Evidence links are required at each lifecycle stage before advancement is permitted.

Test & Rollback Evidence

  • Test plan/source, representative inputs, result, defects/limitations, reviewer, date.
  • Rollback plan/source, scenario, result, owner, date.
  • Known limitations documented before pilot/release readiness.

Pilot & Sign-off Evidence

  • Tenant/client scope, explicit permissions, baseline metrics, support plan.
  • Approver, decision, date, scope/version, evidence URL, open conditions.
  • No client data entered into Portal records during pilot. Link redacted/safe evidence only.

Human Review & Rollback Controls

  • External-facing outputs require documented human-review controls before release.
  • Failure/escalation path and rollback plan must be tested — not only documented.
  • Approval/decline reasons are learning signals; instruction changes require deliberate review and regression testing.

Known Limitations

  • Known-limitations link is required before pilot/release readiness — field cannot be left empty at gate.
  • Limitations must be honest and current, not aspirational.
  • Changes to limitations after release require a change request and updated release notes.

Next Decision

No active decision — prototype only

The next gate or decision point is tracked explicitly per Module Version. A decision record requires the gate type, decision maker, evidence, target date, and any open conditions.

Next GateThe next required gate or decision point in the lifecycle.
Decision MakerPerson or role authorised to make this decision.
Evidence RequiredMinimum evidence that must exist before the decision can be made.
Target DateTarget date for the decision (not a commitment until evidence is ready).
ConditionsAny open conditions that must be resolved first.

No decision pending

Next Decision records will appear here once a Module Version is active.

AEO / Apexti Build Workspace

This page does not replace the AEO/Apexti build workspace. The AEO Reputation Module is IntoFocus AI's first approved module (Phase 4 Build, Founder-approved). Actual build work continues in the designated AEO build chat. This Portal operationalises the governing lifecycle as a controlled evidence and sprint tracker — it does not recreate or compete with the AEO build workspace, and it does not claim that any AEO test, release, or gate has passed.

Canonical sources: intofocus_portal_module_delivery_and_sprint_tracker_spec_v0_1.md · product/ai_module_build_lifecycle_diagram_v1.md · intofocus_aeo_module_delivery_record_v0_1.md