01
A replayed ticket.
A redemption ticket presented a second time must be refused. One-shot means one shot on the live deployment, not in a test double.
A small senior practice with a factory. The reach comes from here, not from headcount.
Every deployment comes from a tagged release and a clean checkout.
You are not buying a bespoke build with your name on it. You are buying a version of a product, deployed into your own account from a tag that exists in a repository, with the version stamped into the running system so it can tell you itself what it is.
One command, and it refuses early.
THE COMMAND · TEN THINGS IN ORDER
A deployment is not a copy of the product. It is your parameter file layered over a tagged release of one shared codebase, put into your account by a separate factory that holds no product code of its own. Two of the first three things the command does are refusals.
Automated by the command
Still needs a person
Refused by the command
Resolve, refuse, stamp, deploy
What the command actually does, in the order it does it.
- 01Resolve the release tag. Named, or the newest one after a fetch.
- 02Refuse a tag that is not on the mainline. A release that forked from the shared line does not reach your account.
- 03Materialize a clean checkout. The tag becomes its own worktree with its own dependency install. A dirty tree is refused.
- 04Stamp version and commit, so two health endpoints, a stored parameter and a tag on the deployed stack all report the same thing afterwards.
- 05Match the front-end bundle to the release. If none matches the tag, it stops rather than shipping a mismatch.
- 06Layer your parameters over the product's. Your file wins on every key it sets.
- 07Discover your module stacks from your admissions. What you admitted is what gets built.
- 08Deploy. One stack set for the platform, one more per admitted module with a back end.
- 09Emit a discovered architecture model from the built templates, reconciled against the drawn diagram, so the picture in your evidence pack is checked against what was deployed.
- 10Append one line to your ledger. Deployment, tag, commit, when.
factory · deploy
RUNNING
deploy -Deployment your-org -Tag v0.32.1
[factory] fetch · resolve v0.32.1
Tag on the mainline✓ ancestor
Clean checkout✓ worktree, fresh install
Version stamp✓ v0.32.1 · 9f2c1ab
Front-end bundle for tag✓ matched
Parameters✓ yours over product
Module stacks from admissions2 discovered
Architecture model✓ emitted, reconciled
Deploy ledger✓ 1 line appended
v0.32.1 deployed · health endpoints report the same
Illustrative outputexit 0
Factory deploy·Ten automated steps·Illustrative
A tag is not a git command. It is a tool with refusals in it.
RELEASES · HOW A TAG IS CUT
Releases are annotated semantic-version tags on the mainline, cut by a tool rather than by hand. It fetches first, proves the mainline is already contained in what is being tagged, runs the test suite, renames the changelog section and pushes branch and tag atomically. A tag push is never fast-forward checked by the version control system itself, so the discipline lives in the tool. That is why cutting a release is a command with refusals in it rather than two lines somebody types.
72tags
Releases · 28 Jul to 18 Sep 2026
52days
Elapsed · that window
2,700tests
Suite · automated cases
170files
Suite · test files
What the test gate is
The suite includes assertions that fail the build if a governance deny is weakened, so the denies that make your content policy mandatory cannot be quietly relaxed by a refactor. The release tool runs that suite before it will cut a tag, and that run is the gate: no tag exists until it passes. The denies themselves →
One tag, into separate accounts.
ROLLOUT · ONE AT A TIME
Rolling a release across the deployments we operate is a serial loop that asks yes or no for each one, in an order somebody chose, skipping any deployment carrying a pin. No update agent lives inside your account. Nothing reaches your deployment because a schedule fired somewhere else, and every roll is confirmed against your deployment before the next one starts.
org{•}tech / factory / rollout-topology.v1One tag · separate accounts · confirmed one at a time
Our factory
OperatorHand-run, confirmed per deployment
Parameter fileOne folder per deployment, yours
The release
Annotated tagMainline proved, tests run, pushed atomically
Clean checkoutMaterialized per tag
Cloud accounts you own One organization · one account · no shared plane
DeploymentStamped version, health reports it
Module stacksDiscovered from your admissions
Pinned deploymentHeld at a version on purpose. The roll skips it
Deploy ledgerOne line per deploy, in your folder
Illustrative. The red node is the only thing that crosses every boundary: one tag, the same bytes, deployed into accounts that share nothing with each other. Each deployment carries its own parameter file, its own pin and its own ledger.
What we can see, and what we refuse to guess.
FLEET STATUS · ACROSS SEPARATE ACCOUNTS
Fleet status is one console table read across separate client accounts, each through its own credentials. A recorded mode reads what the ledgers say; a live mode goes and asks each deployment. Where those two disagree, the live answer wins and the difference is the finding.
| Column | What it reports | Why it is there |
|---|---|---|
| Recorded version | The tag the last recorded deploy wrote into that deployment's ledger. | What we believe is running |
| Release lag | How far that version sits behind the newest tag. | Whether an update is owed to you |
| Declared divergences | Every recorded departure from the standard pattern for that deployment, named. | So a deployment that is different is different on purpose |
| Pin | A deliberate hold at a version, with the reason. | So a roll skips you rather than surprising you |
| Last deploy | The date of the last recorded deploy. | The simplest question a reviewer asks |
| Live health probe | Optional. Reads each deployment's health endpoint and version through that account's own profile, then exits non-zero if any probe cannot report healthy. | The difference between recorded and actual |
| Infrastructure diff | Optional. Compares the deployment against what was actually deployed at the recorded reference. | Change detection before a change |
A deployment with no reachable target carries a written reason rather than a dead address. Every declared divergence and every deliberate hold is named in the table with its reason, so a deployment that is different is different on purpose, and we will tell you which yours is.
Four things a real request must be refused for.
CHECKS · BEFORE AND AFTER
Before a change: drift and diff checks run with two different tools, with written guidance on which to believe when they disagree. After a deploy: acceptance scripts that exercise the real deployment over its own address, the way a person or an attacker would. A unit test checks the code somebody wrote. An acceptance script checks the deployment you have.
02
A forged session.
A session assembled by hand rather than issued by the shell must be refused, with the signature check doing the refusing.
03
The wrong host.
One module's session presented at another module's host must be refused. This is the check that proves the audience pin is real.
04
A corrupted upload.
A bundle whose bytes do not match the declared hash must be refused, and the access record must exist for every grant along the way.
Why they run against the live deployment
Unit tests check the code against the assumptions its author held. An acceptance script presents a real request to a real address over HTTPS and reads what comes back. All four of these must be refused by your own deployment, after every deploy, before the change is called done. The runtime they are testing →
The steps around the command.
LIMITS · WHAT STILL NEEDS A PERSON
The command automates the deploy itself. Around it sit steps a person carries out, and they sit at the start of an engagement rather than in the weekly rhythm. Here is the list, so you can see it before you meet it.
What still needs a person
A documented checklist of manual steps surrounds the command. Cloud account creation and a working profile; per-account and per-region model access, including a use-case form for some vendors; identity configuration beyond the bootstrap, meaning sign-in domain, callbacks, second factors, branding and passkeys; certificates, including the wildcard module origins need; DNS zone creation, delegation and module-origin aliases; authoring your parameter file; creating the first users, groups and roles.
We quote no fixed number of days. Deploy time is not instrumented, so any figure would be invented. If a proposal tells you how many days a governed AI environment takes, ask what measured it.
Rollout is deliberate. A person runs it, confirms each deployment and writes a dated journal entry afterwards. Nothing rolls into your account on a schedule you did not agree to.
A
What this costs you.
Very little. The manual steps sit at the start of an engagement rather than in the weekly rhythm, and they are ours to carry as part of the deployment engagement.
B
What it buys you.
A versioned product rather than a bespoke build. The same tag runs elsewhere, the tests ran before it existed, and the thing in your account can tell you which version it is.
Why this matters to a buyer
You are buying a version of a product, not a bespoke build.
A bespoke build is a snapshot of one person's attention. A versioned product accumulates: the fix someone else needed reaches you through a tag, the tests guarding the denies ran before that tag existed, and the architecture model is reconciled against what was deployed into your account.
- 01Provable. Health endpoints, a stored parameter and a tag on the stack all report the same version.
- 02Separate. One organization, one account, no shared plane between deployments.
- 03Yours. The parameter file, the ledger and the infrastructure code are deliverables, not our private state.
What an IT lead checks.
QUESTIONS · FACTORY AND FLEET
01Could a deploy come from somebody's working copy?
No. The tag is materialized as its own clean checkout with its own dependency install, and a dirty tree is refused. An override exists, it is loud, and it marks the deploy record as dirty, which is the point of having it.
02How do we know what version is actually running?
Ask the deployment. Version and commit are stamped into the environment at deploy time, and two health endpoints, a stored parameter and a tag on the deployed stack all report them. Fleet status reads them across accounts and exits non-zero if any cannot answer.
03Is every deployment held at the same version?
No. Every deploy is from a pinned tag, and each deployment moves on its own schedule: some are held deliberately, some are simply not yet rolled. Fleet status reports each one's recorded version and how far it sits behind the newest tag, so the answer for your deployment is a row you can read rather than a reassurance.
04How long does a deployment take?
We do not answer with a number, because nothing in the factory measures it. We can tell you what the command does, what still needs a person, and what previous engagements looked like in sequence. We cannot tell you a day count, and a firm that can should be asked what instrument produced it.
05What happens before you change anything in our account?
Drift and diff checks with two tools, and written guidance on which to believe when they disagree. After the change, the acceptance scripts run against the deployment itself. The whole managed-operations rhythm →
06If you disappeared, could someone else run this?
The platform, its data and its infrastructure code are in your account, and runbooks and infrastructure-as-code are deliverables so that sentence means something. Running it afterwards needs a competent cloud engineer, not just an account login. Continuity, in detail →
- 01Managed operationsWhat $500 a month actually buys, described as a rhythm rather than a promise.→
- 02Evidence packThe architecture model, the controls matrix and what your security review receives.→
- 03Developer modulesThe other half of the release story: what your own people can ship without us.→
- 04Ownership and exitWhat you keep if the service stops, stated without softening.→
⎯⎯ Book the strategic assessment ⎯⎯
Your private AI, inside your control ·
A bounded first step that ends with your deployment's shape written down: the tier, the parameters, the modules and the manual steps somebody has to do before the command runs.