Hangar

SDLC · Stage 01 of 07

Plan and design

Agree on what good looks like once, write it down as an API, and write down why.

Principles: An API-driven control plane, ready for AI, Honest by design

Good platforms start with a shared understanding of what "good" looks like. When that lives in people's heads, every team ends up guessing, and the platform spends years quietly cleaning up after the guesses.

Most platform drift starts at design time: every team decides for itself what a "service" is, and the platform spends years reconciling the differences. Hangar settles it once. Airframe's XRDs are the definition of a compliant service, and every other part of the platform (the portal, the pipeline, the chart, the agents) consumes that one contract rather than restating it.

Decisions are written down as they are made, dated, and never quietly rewritten. Glidepath has seventeen architecture decision records; Hangar's design docs are kept as dated narrative on purpose, including the first attempts that did not survive contact with a real cluster. Every claim carries a status (Built, Draft or Proposal), so a reader always knows whether they are looking at the platform or at a plan.

Where Hangar does this

Sequence · 03 of 10 · Golden path contractGolden path as a contract: discover, invoke, verifyOpen full page ↗
Architecture · 05 of 08 · The contractThe contract: one source, generated artifacts, four consumersOpen full page ↗

And for AI agents

An agent is designed like a service: a reviewed definition, then a disposable run

Agent definitions are durable, schema-validated files in git, with baseline deny paths that cannot be removed. A run is created from a definition and thrown away afterwards. Designing the definition is the reviewed, slow part; running it is cheap.

Architecture · 05 of 19 · Definition to runFrom a reviewed definition to a disposable runOpen full page ↗

The full Autopilot walkthrough →