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 forubx. From
here: Architecture for the trust chain end to end,
Concepts for the nine building blocks this system
is built from, Schema Constitution for the
ratified hashing rules, Repository Map for what
depends on what across the real repos, Provider System
and SDK and Codegen for how a schema becomes typed
bindings, Docs Pipeline for how those bindings become
a published page, Workflows for the sequences that tie
all of the above together in practice, Decisions for why
things are the way they are, and 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— 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— the proposal and IR wire schema, and the canonical hashing rules. The most load-bearing document in the project.docs/plan.md— the wedge plan, slices, milestones, and changelog.