System 01 · Strategic decision layer

The Strategy System

The human-owned layer that converts an idea into a bounded, measurable strategic contract—safe for the Knowledge and Execution systems to elaborate.

Status · Exploration Version · 0.1 Audience · Product, Architecture, Engineering Updated · August 7, 2026

Strategy

Decides what is worth building—and why.

Knowledge

Defines what must be true.

Execution

Determines how to build and verify it.

01 · Responsibilities

Eight questions before specification begins

The Strategy System frames the initiative without drifting into detailed requirements, technical designs, implementation tasks, or test cases.

1Why does this exist?

Mission and problem statement.

2Who is it for?

Users, stakeholders, and beneficiaries.

3What outcome matters?

Measurable customer, business, and platform outcomes.

4What are we building?

Product and platform scope.

5What are we not building?

Explicit exclusions.

6What must remain true?

Principles, constraints, and non-negotiables.

7What do we need to prove?

Strategic hypotheses and validation milestones.

8Who can authorize it?

Owners, decision rights, and approval gates.

02 · Artifacts

A small Strategy Package—not one oversized charter

The approved collection becomes the input contract for the Knowledge System.

Artifact	Purpose	Required content
Project Charter	Authorizes the initiative	Mission, sponsor, owner, scope, status, target users
Outcome Model	Defines success	Outcomes, measures, baselines, targets, time horizons
Product Thesis	Explains intended value	User problem, experience promise, differentiator
Platform Thesis	Defines reusable value	Capabilities to reuse, expected consumers, reuse assumptions
Strategic Principles	Guides decisions	Ranked principles and conflict-resolution rules
Boundaries & Constraints	Limits the solution space	In scope, out of scope, hardware, cost, safety, schedule
Hypothesis Register	Captures uncertainty	Assumption, evidence needed, risk, validation method
Capability Roadmap	Establishes sequencing	Capabilities, dependencies, proof points, release horizons
Decision Rights	Establishes authority	Accountable human, reviewers, escalation and exception rules

Common metadata

Minimum artifact contract

Every strategic artifact carries identity, status, authority, lineage, and review history. Git remains the source of truth, so approvals and changes are reviewable—not silently overwritten.

Identity and version
Owner and approvers
Inputs and dependencies
Supported decisions
Downstream traceability

artifact_id: STRAT-001
artifact_type: project-charter
version: 0.3
status: approved
owner: product-strategy-owner
approvers:
  - executive-sponsor
  - chief-architect
created: 2026-08-07
last_updated: 2026-08-07
supersedes: 0.2
applies_to: [rp2350-platform]
source_inputs: []
dependencies: []
decisions_supported: []
downstream_artifacts: []
review_history: []

03 · Lifecycle

Approval is a state—not a suggestion

Only an approved Strategy Package authorizes OpenSpec exploration and proposal work.

Draft

Review

Rework

Approved

Active

Amended

Retired

Amendment trigger: reapproval is required when a change alters the mission, target user, platform boundary, non-negotiable constraint, success measure, funding or schedule assumption, risk class, human authority, or foundational platform principle. Routine requirement clarification stays downstream.

04 · Governance

Humans own intent. AI makes it legible and executable.

AI can recommend strategy, expose contradictions, and draft amendments. It cannot approve strategy or redefine platform boundaries autonomously.

Human authority

Human sponsorPurpose, investment, risk tolerance, final authorization

Strategy ownerCharter, outcomes, scope, and roadmap

Chief ArchitectFeasibility and architectural consequences

Engine StewardPlatform reuse and boundary protection

Human reviewersStrategic, architectural, experiential, and hardware-impact decisions

AI-enabled work

ChatGPTExplore, expose assumptions, draft artifacts, compare options

OpenSpecConvert approved intent into explicit specifications and change proposals

CodexRun the lifecycle, maintain traceability, coordinate bounded execution

Implementation agentsBuild only within approved specifications and work orders

Strategy Gate

What must be true before OpenSpec Explore

The gate produces a versioned authorization that names the next stage, any conditions, and the humans who approved the exact Strategy Package.

A named human owns the initiative.

Target user and problem are explicit.

Product and platform outcomes are measurable.

Scope and exclusions are documented.

Platform reuse expectations are defined.

Major assumptions and risks are visible.

Hardware and safety constraints are recorded.

Strategic conflicts have a resolution rule.

Approvers approved the same version.

The package is committed and traceable in Git.

gate: strategy-approval
decision: approved
authorized_next_stage:
  openspec-explore
strategy_version: 0.3
conditions:
  - validate_frame_timing_on_target_hardware
  - preserve_game_independent_lifecycle_api
approved_by:
  - human-product-owner
  - chief-architect

05 · Reference case

RP2350 game platform strategy

A preliminary definition that converts the platform-first philosophy into testable strategic intent.

Mission

Create a reusable RP2350 game platform that enables small, polished games to be developed efficiently through an AI-native engineering workflow.

Product outcome

Players can immediately understand, start, pause, resume, and enjoy a responsive game on target hardware.

Platform outcome

The first game proves reusable lifecycle, input, rendering, audio, timing, asset, and validation capabilities that future games can adopt without rewriting the engine.

Strategic principles

Platforms over projects.
Reusable core separated from game-specific behavior.
Target hardware is the truth.
Human creative direction remains authoritative.
AI-generated hardware-impacting changes require human approval.
Reliability earns the right to add innovation.
Every implementation leaves the platform easier to understand.

Initial proof points

Start, pause, and resume work predictably.
Lifecycle behavior survives repeated hardware testing.
Game code uses stable platform interfaces.
A second minimal game or harness reuses the lifecycle.
A new agent can enter cold and make a bounded change correctly.
Evidence and decisions trace from charter to implementation.

MVP exclusions

Persistent save games
Online multiplayer
General-purpose game editor
Unlimited asset formats
Unrelated hardware support
Abstraction without a second consumer

Repository blueprint

Git holds the strategic contract

Each artifact is independently reviewable, versioned, and traceable. Approvals live beside the package they authorize.

Recommended next design step: define the Project Charter schema as the root artifact for specifications, work packages, test evidence, and learning deltas.

strategy/
├── charter.md
├── outcomes.md
├── product-thesis.md
├── platform-thesis.md
├── principles.md
├── boundaries.md
├── hypotheses.md
├── roadmap.md
├── decision-rights.md
└── approvals/
    └── strategy-v0.3.yaml