Build timeline — where we are
Eight slices, each with a hard exit gate — the same discipline as Ranger's build. One story runs through them: Bristlecone Outfitters, a fictional Colorado gear retailer, taken from a Monday interview to a Friday demo by Sam — a sharp but junior operator who has never opened a terminal. Every slice makes another piece of that week push-button. Click any block for the full technical deep-dive.
Open decisions gating later slices: where HQ's services run (ADR drafted) · LLM gateway & transcription supply chain (gate W4) · the guardrail file format (lands with W2) · pricing shape (before the first HQ-run pilot).
One hub, one engine — how HQ and Ranger fit
◆HQ is the hub
Everything an engagement needs, in one place: runbooks that drive the week, a source hub that connects and profiles customer systems, a model studio that proposes and publishes the DAL, a launchpad that provisions private deployments, and an app composer that generates the Friday demo. HQ's own domain — engagements, steps, verifications, artifacts — is itself a DAL running on an internal Ranger deployment: we operate our own product with our own product.
◆Ranger is the engine
The data abstraction layer platform HQ deploys and operates: the public OSDK wire contract, event-sourced writes, database-enforced isolation, and one gapped cloud deployment per customer. Its build has its own status page — phases 0–4 shipped, first production stamp live on AWS, hardening drills in progress.
◆The contract between them
HQ consumes only Ranger's published artifacts — the wire API, the management API, typed api-types, the model-as-code format, the deployment module, and guardrail data. Never its internals: the ban is enforced by CI, the Ranger version is pinned in ranger.lock.json, and a cross-repo compatibility suite proves the pairing green on every merge.