> ## Documentation Index
> Fetch the complete documentation index at: https://developer.ubiquex.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Proposal

> The typed, hashed, signed unit of change the whole system is organized around.

A proposal is the object every other concept in `ubx` is built around. It
is not a plan, and it is not a diff against a state file — it's a
self-contained, typed record of one change: what it does (`delta`), why
someone wanted it (`intent`), what it cost and how big its blast radius
was, which policies it was checked against, who accepted it, and a
content hash binding all of that together. Nothing applies to real
infrastructure that isn't first a signed proposal.

## Shape

A proposal's real wire shape (from `docs/schema.md`, lightly trimmed):

```json theme={null}
{
  "id": "<content-hash, short form for display>",
  "stack": "payments",
  "parent": "<previous ledger head hash>",
  "kind": "change | adoption | drift_adopt | drift_revert | revert",
  "intent": { "summary": "...", "sources": [ /* dialogue, manual_edit, issue */ ] },
  "delta": { "creates": [], "modifies": [], "destroys": [] },
  "resolution": { "resolved_at": "...", "inputs": [ /* live_state, cross-stack pins, ... */ ] },
  "cost_delta": { "monthly_usd": 59 },
  "blast_radius": { "creates": 0, "modifies": 1, "destroys": 0 },
  "invariants_checked": [ { "policy": "no_public_db", "verdict": "pass" } ],
  "acceptance": { "method": "pr_merge | local | crypto", "approvers": ["..."] },
  "status": "draft | refined | accepted | applied | stale | rejected"
}
```

`kind` is what distinguishes a genuinely new change (`change`) from a
proposal generated by observing reality rather than authoring intent
(`adoption`, `drift_adopt`, `drift_revert` — see [Drift](/concepts/drift)).
An adoption's `blast_radius` is always zero by construction: it records
what's already true, it never changes anything.

## The lifecycle is one-directional

`status` moves `draft → refined → accepted → applied`, or diverts to
`stale` at any point before `applied` if something the proposal depended
on moved out from under it (see [Staleness](/concepts/staleness)). A
proposal's own content, once it has a hash, never changes — a stale
proposal isn't edited back to freshness, it's re-resolved into a new one.

## Why intent is recorded, not just the diff

`intent.sources` exists so a proposal answers not just "what changed" but
"why," with provenance: which dialogue produced it, which manual edit,
which tracked issue. This is what makes `ubx why` on any live resource
able to trace back through a real chain to the reasoning behind it, not
just the mechanical diff.

Full detail, every `kind`'s exact shape, and the amendment history behind
each field: [`docs/schema.md`](https://github.com/Ubiquex/ubiquex/blob/main/docs/schema.md)
in `ubiquex`.