Skip to main content
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):
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). 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). 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 in ubiquex.