Waypoint™ Design Engine Specification

1. Purpose

The Design Engine transforms an ambiguous human objective into a complete, internally consistent, reviewable Project Design Package containing sufficient information for the Planning Engine to autonomously construct a meaningful execution plan.

This is not a form wizard and not a ticket generator.

The engine is a collaborative design partner that discovers missing information, develops alternatives, records decisions, creates and maintains project documentation, identifies uncertainty, and determines when the project is ready to plan.

2. Primary outcome

Input: intent, conversation, supplied files, existing systems/context, constraints, templates, organizational standards, and optional prior project artifacts.

Output: versioned Project Design Package.

Gate: explicit Design approval.

The Planning Engine must not require a human to reconstruct undocumented design context from the Design conversation.

3. Design Engine responsibilities

The Design Engine shall:

capture the desired outcome;
determine project type/domain;
discover stakeholders and decision authority;
identify scope and non-goals;
elicit functional requirements;
elicit non-functional requirements;
identify constraints and assumptions;
identify existing-state context;
develop solution options when needed;
recommend and document architecture/design decisions;
identify integrations and dependencies external to the project;
identify environments and operational constraints;
identify security, privacy, compliance, and data concerns;
define delivery and acceptance expectations;
maintain risks, issues, assumptions, decisions, and open questions;
generate and revise authoritative documentation;
detect contradictions and gaps;
assess design readiness;
present unresolved material issues to the user;
produce the Design Gate review package;
version the approved Project Design Package;
hand the approved artifact to Planning.

4. Conversational design model

The Design Engine should behave as an iterative structured conversation.

Intent
  ↓
Understand
  ↓
Discover
  ↓
Model / Explore
  ↓
Propose
  ↓
Decide
  ↓
Document
  ↓
Validate
  ↓
Ready?
  ├─ No → targeted discovery / revision
  └─ Yes → Design Gate

The engine should not ask every possible question. It should ask the questions whose answers materially affect the design or plan.

4.1 Progressive elaboration

Early information may be incomplete.

The engine should progressively move statements through states such as:

idea → candidate → clarified → decided → documented → approved

A statement should retain provenance: user statement, inferred proposal, imported fact, organizational standard, or system observation.

4.2 Questions

Questions should be prioritized by impact.

High-value questions include those that:

block architecture;
materially change scope;
affect security/compliance;
alter delivery method;
affect major cost;
determine external dependencies;
create mutually exclusive design paths;
prevent meaningful acceptance criteria;
prevent Planning from decomposing the work.

Low-impact details that can safely be deferred should not stall the Design Gate.

5. Project classification

The engine should classify the project sufficiently to load relevant design knowledge/templates.

Possible project categories include:

software/application;
data/analytics;
infrastructure/cloud;
migration;
integration;
documentation/knowledge;
operational/process;
hybrid.

Classification is extensible and may be multi-valued.

A hybrid project may require multiple domain design modules.

6. Project Design Package structure

The Project Design Package is a logical artifact that may be rendered as several Markdown documents.

A baseline Design Package should support the following sections.

6.1 Executive definition

project name;
problem/opportunity;
objective;
desired outcomes;
success measures;
owner;
stakeholders;
approvers.

6.2 Scope

in scope;
out of scope;
non-goals;
project boundaries;
known future considerations.

6.3 Requirements

Requirements should have stable identifiers and include:

description;
type;
rationale;
priority;
source/provenance;
acceptance criteria or verification method where applicable;
status;
dependencies/relationships.

Requirement types may include:

business;
functional;
non-functional;
technical;
security;
compliance;
data;
operational;
delivery.

6.4 Existing state

As applicable:

systems;
architecture;
repositories;
cloud resources;
environments;
processes;
data stores;
constraints;
known technical debt.

6.5 Proposed solution

solution overview;
architecture;
components;
boundaries;
interactions;
technology choices;
data flows;
deployment/operational model;
design rationale.

6.6 Integrations

For each material integration:

system/provider;
purpose;
direction;
protocol/interface;
authentication;
data exchanged;
rate/availability constraints;
ownership;
failure behavior.

6.7 Environments and delivery targets

development/test/preview/production or domain equivalents;
target subscriptions/accounts/projects;
environment promotion model;
access constraints;
delivery expectations.

6.8 Security and governance

identities;
roles;
secrets;
sensitive data;
authorization boundaries;
required approvals;
audit expectations;
policy/compliance requirements.

6.9 Quality and validation

test strategy;
quality criteria;
validation approach;
acceptance criteria;
evidence expectations.

6.10 Risks and assumptions

Each entry should have:

identifier;
statement;
impact;
likelihood/confidence where useful;
mitigation/validation;
owner/status.

6.11 Decisions

Architecture/design decision records should include:

decision;
context;
alternatives;
rationale;
consequences;
decision maker;
date/version;
supersession relationship.

6.12 Open questions

Open questions must be explicitly classified as:

blocking Design approval;
acceptable to defer to Planning;
acceptable to defer to Execution;
external dependency;
owner decision required.

7. Artifact management

The Design Engine should create maintainable artifacts rather than a single generated narrative.

The default documentation format should be Markdown-friendly and suitable for source control and MkDocs Material.

The engine should:

maintain a document manifest;
use stable section/document identities;
update documents instead of generating uncontrolled duplicates;
preserve revision history;
identify changed requirements/decisions;
link related artifacts;
support diagrams using a portable textual notation where practical;
produce human-readable and machine-readable representations where useful.

8. Design memory and context

Project context should not depend on the LLM conversation window.

The engine needs durable project memory containing:

facts;
requirements;
decisions;
assumptions;
open questions;
artifact versions;
user feedback;
imported source references;
design state.

The conversation is an interface to the design model, not the design database itself.

9. Source ingestion

The Design Engine should eventually accept:

natural-language conversation;
Markdown/text;
PDFs/documents;
diagrams;
screenshots/images;
source repositories;
existing Jira projects;
cloud/environment inventory;
organizational standards/templates;
API specifications;
data models.

Imported content should retain source provenance.

The engine must distinguish imported facts from generated recommendations.

10. Design intelligence

The engine should perform continuous consistency checks, including:

requirement contradictions;
requirement with no acceptance method;
architecture component with no requirement rationale;
stated integration absent from architecture;
environment requirement absent from delivery design;
security requirement with no control;
unresolved decision blocking planning;
non-goal contradicted by requirement;
acceptance criterion not achievable by proposed design;
duplicate/conflicting terminology;
missing ownership for external dependencies.

11. Readiness assessment

The Design Engine should calculate or reason over a Design Readiness assessment.

This should not be a simplistic percentage. It should identify dimensions such as:

objective clarity;
scope clarity;
requirement completeness;
architecture sufficiency;
integration sufficiency;
security/governance sufficiency;
delivery clarity;
acceptance clarity;
unresolved blockers;
external dependency clarity.

A project may be ready with documented uncertainty if Planning can safely represent that uncertainty.

Design-ready rule

A design is ready for approval when:

the desired outcome is unambiguous enough to test;
project boundaries are understood;
material requirements are documented;
the proposed solution is sufficiently defined for decomposition;
material constraints and dependencies are known;
acceptance can be evaluated;
no unresolved question makes planning misleading;
remaining uncertainty is explicitly recorded.

12. Design Gate review

The engine should generate a concise review experience rather than ask the user to reread every document.

The review should show:

objective/outcomes;
major scope;
proposed architecture/solution;
consequential decisions;
major requirements;
known risks;
deferred/open items;
acceptance model;
readiness findings;
documents changed since prior review.

The approver may:

approve;
approve with conditions;
request changes;
answer outstanding decisions;
place on hold;
cancel.

Approval must identify the exact Project Design Package version.

13. Change after approval

Approved designs can change.

When a change request occurs, the Design Engine should:

classify the change;
identify affected requirements/decisions/artifacts;
assess impact on the existing plan and execution;
create a new draft Design Package version;
preserve the previous approved version;
require reapproval according to change policy;
notify Planning of the exact delta.

Minor clarifications may not require full gate reopening if policy permits.

14. Design Engine and AI

AI is central to the user experience but should not be the system of record.

The engine should separate:

conversation/orchestration;
structured project state;
artifact generation;
validation;
policy;
persistence.

Model/provider selection should be replaceable.

Different design tasks may use different agents/models, for example:

requirements analyst;
solution architect;
security reviewer;
data architect;
documentation editor;
design critic.

A supervising Design Agent may coordinate specialists while presenting one coherent conversation to the user.

15. Human authority

The Design Engine may recommend a solution, but consequential choices remain visible.

It must not silently invent and approve:

material business scope;
destructive migration choices;
security exceptions;
production authority;
significant cost commitments;
compliance decisions;
acceptance waivers.

Where a safe default is used, the default and rationale should be recorded.

16. Planning handoff

The Design Engine must produce a machine-consumable handoff manifest containing at minimum:

Project Design Package ID/version;
approval record;
requirement inventory;
artifact inventory;
decision inventory;
constraints;
acceptance criteria;
open/deferred items;
delivery targets;
traceability identifiers.

Planning should be able to cite the design element that caused each material work item to exist.

17. Initial Waypoint™ implementation consideration

For the first Waypoint™ build, this human/ChatGPT design exercise serves as a reference workflow for the Design Engine.

The implementation should capture useful behaviors demonstrated by this design workflow:

collaborative elaboration before Jira;
multiple documents generated in reviewable batches;
owner review between batches;
stable package structure;
eventual consolidated handoff to the planning system.

The future experience should make this process durable, structured, and repeatable inside Waypoint™ rather than dependent on a long chat.