Waypoint™

Waypoint™ Lifecycle and Operating Model

1. Purpose

This specification defines Waypoint™'s end-to-end operating model.

The lifecycle is:

Design → Plan → Execute → Deliver

Allocation, dispatch, reporting/analytics, governance, and human oversight remain critical but are modeled as responsibilities within the lifecycle and Control Plane rather than as independent peer lifecycle stages.

2. Lifecycle model

2.1 Design

Input: human intent and available context.
Purpose: determine what should be accomplished and what solution is being authorized.
Primary output: versioned Project Design Package.
Exit condition: Design Gate approved.

2.2 Plan

Input: approved Project Design Package.
Purpose: determine how the approved solution will be implemented.
Primary output: versioned Execution Plan and synchronized work hierarchy.
Exit condition: Plan Gate approved.

Planning includes decomposition, estimation, dependency modeling, streams, timeboxing, required capabilities, performer recommendations, and allocation forecasting.

2.3 Execute

Input: approved Execution Plan and authorized execution scope.
Purpose: perform and validate planned work.
Primary output: completed work plus execution/test evidence.
Exit condition: execution completion criteria for the delivery unit are satisfied.

Execution includes dispatch and dynamic allocation of workers. Allocation is therefore a major subsystem spanning Plan and Execute rather than a separate lifecycle outcome.

2.4 Deliver

Input: completed, validated work and delivery instructions.
Purpose: place the result into its intended operational state and verify it.
Primary output: delivered outcome, delivery evidence, acceptance/handoff record.
Exit condition: Delivery/Acceptance Gate satisfied.

3. Control Plane

The Control Plane spans every lifecycle stage.

+-------------------------------------------------------------------+
|                    WAYPOINT CONTROL PLANE                         |
| Governance | Policy | State | Audit | Evidence | Identity | UI   |
| Workers | Capacity | Cost | Integrations | Events | Reporting    |
+-------------------------------------------------------------------+
        |              |              |              |
        v              v              v              v
     DESIGN --------> PLAN --------> EXECUTE ------> DELIVER

The Control Plane owns or coordinates:

  • project lifecycle state;
  • artifact registry and versions;
  • gates and approvals;
  • policies;
  • worker registry and capabilities;
  • execution authorization;
  • orchestration and scheduling;
  • events;
  • run state;
  • audit;
  • evidence;
  • observability;
  • reporting and analytics;
  • governed reporting/query APIs;
  • notifications;
  • secrets/credential references;
  • integration adapters;
  • exception management;
  • recovery and reconciliation.

4. Engine contracts

Engines should exchange explicit artifacts rather than depend on each other's internal databases or implementation details.

4.1 Design → Plan contract

The approved Project Design Package must provide, as applicable:

  • objectives and success measures;
  • scope and non-goals;
  • stakeholders and approvers;
  • functional requirements;
  • non-functional requirements;
  • constraints;
  • assumptions;
  • architecture/solution design;
  • environments;
  • integrations;
  • data considerations;
  • security/compliance requirements;
  • delivery expectations;
  • acceptance criteria;
  • risks;
  • decisions;
  • unresolved items explicitly accepted for planning;
  • traceable requirement identifiers.

4.2 Plan → Execute contract

The approved Execution Plan must provide:

  • planned work hierarchy;
  • source requirement traceability;
  • dependencies;
  • estimates;
  • priority/order;
  • streams;
  • release/sprint/timebox structure where used;
  • required capabilities;
  • performer type/recommendation;
  • execution constraints;
  • expected artifacts;
  • work-item acceptance criteria;
  • test/validation expectations;
  • required gates;
  • delivery association;
  • concurrency constraints;
  • initial worker/allocation forecast.

4.3 Execute → Deliver contract

The completed delivery unit must provide:

  • completed work-item state;
  • produced artifacts;
  • test results;
  • review evidence;
  • unresolved defects/exceptions;
  • change/release metadata;
  • delivery instructions;
  • environment target;
  • rollback/recovery requirements;
  • required delivery approvals;
  • traceability to plan and design.

5. Lifecycle gates

A gate is a governed decision, not merely a workflow status.

G1 — Design Gate

Confirms the project is sufficiently understood to plan.

Possible decisions:

  • approve;
  • approve with recorded conditions;
  • return to Design;
  • cancel/hold.

G2 — Plan Gate

Confirms scope decomposition, estimates, dependencies, streams, delivery strategy, and proposed execution model are acceptable.

Possible decisions:

  • approve full plan;
  • approve a bounded increment/release;
  • return to Plan;
  • return to Design because the plan exposed a design deficiency;
  • hold/cancel.

G3 — Execution authorization

Execution may be authorized at project, release, sprint, stream, or work-package scope according to policy.

This permits incremental autonomy rather than requiring a single all-or-nothing start button.

G4 — Review/quality gates

Execution may contain required human or automated gates, including:

  • architecture review;
  • security review;
  • code review;
  • test threshold;
  • infrastructure plan review;
  • data reconciliation;
  • compliance review.

G5 — Delivery Gate

Confirms a delivery unit is allowed to affect the target operational environment.

G6 — Acceptance Gate

Confirms the delivered outcome meets agreed acceptance criteria and may be closed or handed off.

No worker may self-approve a gate whose policy requires an independent approver.

6. Lifecycle is iterative, not strictly linear

The primary direction is forward, but Waypoint™ must support controlled backward transitions.

Examples:

  • Planning discovers an architectural omission → return to Design.
  • Execution exposes a requirement ambiguity → create a design clarification and replan affected work.
  • Delivery validation fails → return to Execute for remediation.
  • Owner changes scope → version Design and Plan while preserving completed execution history.

Backward movement must:

  1. record the reason;
  2. identify impacted artifacts/work;
  3. preserve prior approved versions;
  4. determine whether previous approvals remain valid;
  5. prevent unaffected work from being unnecessarily invalidated.

7. Change model

Waypoint™ must distinguish:

  • clarification — improves understanding without changing approved outcome/scope;
  • design change — changes the approved solution;
  • plan change — changes decomposition, sequencing, estimate, assignment, or schedule without changing design;
  • execution variance — actual execution differs from forecast;
  • delivery exception — delivery cannot proceed as designed/planned.

Material changes create new artifact versions and may reopen gates.

8. Project state versus work state

Project lifecycle state and Jira issue state are different concepts.

Example project states may include:

draft
designing
design_review
design_approved
planning
plan_review
plan_approved
executing
delivery_ready
delivering
acceptance_review
completed
on_hold
cancelled

Work items have their own states and may be represented in Jira.

Waypoint™ must not infer project lifecycle state solely from aggregate Jira statuses.

9. Execution readiness

A work item is executable only when all applicable conditions are true:

  • it belongs to an approved plan/increment;
  • execution is authorized;
  • predecessor dependencies are satisfied;
  • required inputs/artifacts exist;
  • required gates are satisfied;
  • an appropriate worker is available/authorized;
  • environment/tool prerequisites are satisfied;
  • concurrency/exclusivity constraints permit execution;
  • the item is not blocked, superseded, cancelled, or already complete.

Execution readiness should be implemented as a lifecycle service rather than as a Jira-status convention.

10. Streams and parallel work

Streams organize parallel execution.

A stream may represent:

  • application frontend;
  • API/backend;
  • database;
  • infrastructure;
  • documentation;
  • QA;
  • security;
  • migration wave;
  • geographic/environmental rollout;
  • another coherent work lane.

Streams are not necessarily sprints.

Relationships may be N:N:

  • one worker may operate across multiple streams;
  • many workers may operate in one stream;
  • one sprint may contain multiple streams;
  • one stream may span multiple sprints.

Dependencies, capability needs, and collision constraints govern parallelism.

11. Worker model

The lifecycle operates on a generic Worker abstraction.

Worker
├── Human
├── AI Agent
├── Agent Team / Swarm
├── Automation
└── External System

A worker profile may describe:

  • capabilities;
  • skills;
  • tools;
  • execution environment;
  • availability/capacity;
  • cost;
  • permissions;
  • data classifications allowed;
  • supported project/work types;
  • concurrency limits;
  • reliability/history;
  • human-review requirements.

Planning expresses what work requires. Allocation/Execution chooses who should perform it.

12. Human interaction model

Waypoint™ should use human attention where it adds value.

Humans are primarily needed for:

  • defining intent;
  • resolving ambiguity;
  • selecting among consequential alternatives;
  • approving lifecycle gates;
  • reviewing high-risk or policy-controlled work;
  • resolving exceptions;
  • accepting delivered outcomes.

Routine coordination should be automated.

The Overseer UI must make the following immediately visible:

  • current lifecycle stage;
  • next gate;
  • decisions waiting on the user;
  • active streams/workers;
  • progress;
  • blockers;
  • forecast changes;
  • failures/retries;
  • budget/capacity concerns;
  • delivery readiness;
  • evidence and audit history.

13. System-of-record model

Waypoint™ is the lifecycle authority.

External systems remain authoritative for their own native facts:

  • Jira: issue/work-management representation;
  • GitHub: repository, branch, commit, PR, merge facts;
  • cloud provider: deployed resource facts;
  • CI/CD system: pipeline/run facts;
  • deployment platform: deployment facts.

Waypoint™ stores durable references, projections, lifecycle semantics, evidence, and reconciliation state.

Synchronization must assume drift is possible.

14. Reporting and analytics operating model

Reporting spans Design, Plan, Execute, Deliver, and the Control Plane.

Waypoint™ must not depend on Jira reporting as the primary analytics layer. Jira is one operational projection and does not contain the complete Waypoint™ lifecycle, artifact, execution, evidence, approval, allocation, forecast, and delivery model.

The Control Plane should provide:

  • a reporting-ready semantic/domain layer;
  • stable governed query/reporting APIs;
  • project and portfolio metrics;
  • current-state and historical reporting;
  • estimate-versus-actual and forecast reporting;
  • worker/agent/capacity reporting;
  • execution and exception reporting;
  • delivery and quality reporting;
  • audit, approval, evidence, and traceability reporting.

A first-party Reporting Module should be able to consume the same APIs exposed to authorized external reporting clients. This keeps reporting extensible and prevents the core lifecycle engines from becoming tightly coupled to presentation-specific reporting logic.

15. Failure and recovery model

External operations can partially succeed.

Waypoint™ should use execution-hardening principles:

  1. durable run state;
  2. deterministic idempotency keys where possible;
  3. probe external state before retry;
  4. reconcile silently successful operations;
  5. resume only outstanding steps;
  6. preserve event/audit history;
  7. expose failure and recovery status to the user.

Recovery is a normal operating capability, not an afterthought.

16. Completion model

There are multiple levels of completion:

Work complete — the work item's acceptance/evidence requirements are satisfied.

Execution unit complete — all required work for a delivery unit is complete and validated.

Delivered — the output is implemented/published/deployed in the target state.

Accepted — the owner or required approver confirms the delivered outcome satisfies the Project Design Package.

A project is complete only when the applicable acceptance conditions are satisfied or an authorized closure exception is recorded.

17. Implications for initial Waypoint™ implementation

The implementation plan generated from the final specification should preserve the engine boundaries while allowing incremental delivery.

The architecture should avoid reproducing legacy coupling merely to preserve current command structures.