Goals & evolution

Part of Ops — Goals declare intent; Runs, Events, and Issues complete the loop.

Software has always required humans to notice, decide, and rewrite. On a product graph, the noticing and drafting can move into the runtime — with the deciding kept firmly human.

Goals

A Goal is a first-class DataObject: what the product should be pulling toward. Business, marketing, product, technical, or ops; optionally scoped to one Experience; with a lifecycle (draft → active → completed / paused / abandoned).

Define Goals in the console under Goals, or through the API/IDE. They aren't OKR decoration — they're inputs the runtime reads.

Evolution proposals

Approve a Goal and the platform runs a workflow that drafts a Change request — a detailed, executable prompt (plus work plan) that your IDE or a governed build can actually run. Approving a Goal does not rename it into a proposal; the Goal stays intent, the Change request is the work order.

Two things keep this honest:

• Change requests are drafts. Approving one starts a governed build with the CR prompt as the brief; HITL / IDE continues in Runs. Nothing self-mutates behind your back.
• Goals themselves are scanned. The goals drift scan files Issues for stale, thin, or duplicate goals — and for having no active goal at all.

The loop

Events (memory) ─┐
                 ├─→ Evolve → proposals → you approve → governed build → graph versions
Goals (intent) ──┘

This is the same governance as human edits: identity, audit, SIV checks, and the promote gate all apply.

Where

• Console: Goals (Change requests tab)
• API: GET/POST /api/goals, POST /api/evolution/recommendations
• Plan: evolution runs on Team and above; see Plans