# Goals Domain

**Status:** Canonical target-state specification  
**First realization:** I1 compact Goal context; I2 full Goal management.

## Purpose

`Goal` is the durable Project-owned primitive for a current or future outcome the Project intends to achieve. It replaces `GOLIVE` as a generic project primitive.

```text
ProjectVision
  enduring purpose / direction / constraints

Goal
  current or future outcome the Project is pursuing

Plan
  bounded body of work that advances one or more Goals

Task
  executable work inside a Plan
```

A go-live milestone is represented as a normal Goal when relevant. There is no special `GOLIVE` primitive.

## Primitive

```text
Goal {
  id
  projectId
  title
  description?
  status: draft | active | future | parked | achieved | abandoned
  priority?
  targetDate?
  successCriteria[]
  owner?
  createdAt
  updatedAt
}
```

A Goal may be qualitative or quantitative. A percentage is authoritative only when it is derived from explicit criteria and the derivation is inspectable.

## Relationships

```text
Project 1 -> Goal*
Goal * <-> Plan*
Plan 1 -> Task*
```

A Project may have zero, one, or multiple active Goals. A Plan may advance one or more Goals. A Goal may span multiple Plans, releases, and operational phases.

Tasks inherit Goal context through their Plan and may explicitly link to a narrower subset only when useful for prioritization/explainability.

## Commands

```text
CreateGoal
UpdateGoal
SetGoalStatus
SetGoalPriority
LinkPlanToGoal
UnlinkPlanFromGoal
```

Material Goal changes that invalidate accepted Plans, commitments, or owner intent create normal Decision/provenance records.

## Read Models

Required projections include:

```text
Project -> active/future/completed Goals
Goal -> linked Plans + aggregate work state
Plan -> linked Goals
Task -> owning Plan -> Goal context
Queue -> Goal context for dispatch explanation
Dependency graph -> Goal filter/overlay
```

## Goal Readiness

A Goal may expose gate/evidence readiness where the outcome has explicit prerequisites, including a launch Goal. That readiness remains a projection of authoritative Planning, Policy, CI, Release, Deployment, Connection and Approval state; it is not a second editable checklist.

Example:

```text
Goal: First production launch
state: active
readiness: blocked
blocked by:
  production connection approval
  release artifact verification
```

## UI Implications

Project Overview prioritizes active Goals because they explain why current work exists. Future/completed Goals use progressive disclosure.

The Project Overview target scan order is:

```text
Goals
Needs your attention
Blockers
Queue / Next to factory
Current Plans
Current FactoryRuns
Recent progress
```

Vision and Settings remain Project destinations but do not dominate the operational Overview.

Queue entries expose Goal linkage where it helps explain priority. Graph view can filter/focus by Goal without making Goals mandatory dependency nodes.

## Invariants

- `GOLIVE` is not a first-class primitive.
- Going live is one possible Goal.
- ProjectVision, Goal and Plan have distinct authority.
- Multiple active Goals are legal.
- Plans may advance multiple Goals.
- Goal state does not duplicate Plan, Task, FactoryRun, CI, Release or Deployment lifecycle state.
- Goal progress/readiness is explainable from explicit criteria/evidence.
- Manual Goal priority never overrides hard Task dependency legality.

## Increment Realization

| Increment | Realization |
|---|---|
| I1 | compact Goal identity/linkage sufficient to orient Project/Plan/Task/Queue. |
| I2 | full create/edit/status/criteria/Goal-aware Planning UX. |
| I3 | Decision/Approval/autonomy relationships deepen. |
| I5–I8 | CI/delivery/incident evidence contributes to Goal readiness where relevant. |
| I9 | organization/tenant governance if required. |

## Acceptance

A live or pre-live Project can continue using the same Goal model throughout its lifetime; Plans can link to Goals; the Project Overview can explain current outcomes; and no implementation requires a special post-launch replacement for `GOLIVE`.