> ## 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.

# Overview

> What ubx is, the ledger-over-state-file thesis, and how it differs from Terraform and Pulumi.

## What ubx is

`ubx` (repo: `ubiquex`, renamed from `ubiquex-cli` once the product grew past
a CLI into an SDK monorepo, a conformance harness, and an MCP server) is an
infrastructure change management tool. It manages the same problem
Terraform and Pulumi manage — describing cloud infrastructure and applying
changes to it safely — but starts from a different unit of meaning.

Terraform and Pulumi are built around **state**: a file (or backend) that
records what currently exists, diffed against a desired configuration to
produce a plan. `ubx` is built around **change**. Every infrastructure
change, however it's authored — by hand, generated by an LLM, drawn as a
diagram — becomes a typed, resolved, hashed, signed proposal before it ever
touches real infrastructure. Current infrastructure isn't read from a
state file; it's the fold of every proposal the ledger has accepted and
applied. The ledger is the source of truth. Everything else — the files
you write, the diagrams you draw, the chat you have with an assistant, the
docs you read — is a frontend onto it.

One sentence for the whole system: a compiler where code, diagrams,
documents, and conversation are all frontends to one typed, signed
intermediate representation.

## Why a ledger instead of a state file

A state file answers "what exists now." It doesn't answer who decided a
resource should exist, what they were trying to accomplish, or what
tradeoffs they accepted. Those answers live in commit messages, PR
descriptions, and tribal memory — if they're recorded at all, and if
they survive the state file being regenerated, migrated, or manually
edited by someone under pressure.

`ubx`'s ledger is append-only, per-stack, and typed. Every entry is a
proposal: the resolved change, its cost delta, its blast radius, the
invariants that were checked, a hash binding all of it together, and a
signature — a PR merge, or an explicit local acceptance — proving someone
with authority approved exactly that hash. Nothing applies that wasn't
signed. Nothing gets attributed to a human that an LLM actually decided;
the model that helps author a change operates entirely in intent space,
and a deterministic resolver computes every concrete value before a human
ever signs off. Ask `ubx why` about any resource in the fleet and the
answer traces back through a real, hash-verified chain to the proposal,
the intent behind it, and the approver.

This has a consequence Terraform-style state files don't have by
construction: staleness is detected, not silently ignored. If a proposal
referenced live state, or a piece of infrastructure it depends on in
another stack, and that dependency has since moved, the hash the proposal
was signed against no longer matches reality. The proposal is stale and
must be re-resolved before it can ship — not applied against
infrastructure it no longer accurately describes.

## Where to go next

This is the first page of the developer documentation for `ubx`. From
here: [Architecture](/architecture) for the trust chain end to end,
[Concepts](/concepts/proposal) for the nine building blocks this system
is built from, [Schema Constitution](/schema-constitution) for the
ratified hashing rules, [Repository Map](/repository-map) for what
depends on what across the real repos, [Provider System](/provider-system)
and [SDK and Codegen](/sdk-and-codegen) for how a schema becomes typed
bindings, [Docs Pipeline](/docs-pipeline) for how those bindings become
a published page, [Workflows](/workflows) for the sequences that tie
all of the above together in practice, [Decisions](/decisions) for why
things are the way they are, and [Conventions](/conventions) for the
rules this project's own real incidents produced.

For the full, current detail behind any of this, the real source is the
repo that owns it:

* [`docs/architecture.md`](https://github.com/Ubiquex/ubiquex/blob/main/docs/architecture.md) —
  the complete system model: IR, ledger, proposals, execution layer, drift
  and revert, fleet status, and every slice built since, in the order it
  was built.
* [`docs/schema.md`](https://github.com/Ubiquex/ubiquex/blob/main/docs/schema.md) —
  the proposal and IR wire schema, and the canonical hashing rules. The
  most load-bearing document in the project.
* [`docs/plan.md`](https://github.com/Ubiquex/ubiquex/blob/main/docs/plan.md) —
  the wedge plan, slices, milestones, and changelog.

Those stay next to the code they describe. This site's job is to explain
*why*, in prose, for a reader meeting the system for the first time — not
to duplicate them.