Building an Inner-Enterprise Loop with Kilter

For twenty years the system of record for software was the git repository. Source was the scarce, hard-won thing; everything downstream — build, deploy, run — was a function you re-applied to it. Manage the source well and the running system followed.

That assumption is quietly inverting. Source is no longer the scarce input — agents write it, refactor it, regenerate it on demand. What determines whether your software actually works has moved downstream, into the part git was never designed to hold: the orchestration and configuration of the running system. Which image, by which digest. Which database, provisioned how, with which credentials. Which reconciler owns desired state, and what it will and won't self-heal. A git log of your source tells you how the code changed. It does not tell you how production got its database.

Nowhere is that inversion more visible than inside a large enterprise — because a large enterprise doesn't have one software loop. It has two.

The two loops

There's an outer loop: the systems with real exposure to the outside world. Customer-facing, regulated, revenue-bearing, or high-blast-radius. These go through production engineering as it should be — change control, PRs, RBAC, sync windows, audit, a human accountable for every mutation. Slow on purpose. The slowness is the feature.

And there's an inner loop, which is most of the actual surface area of the company: the departmental app three people use, the internal harness that runs the nightly evals, the coordination portal for a project that ships in a quarter and is gone in two, the per-PR preview environment that exists for ninety minutes. Transient. Low blast radius. High velocity. Nobody needs a change advisory board to stand up a staging environment for a tool that four humans will touch.

Most platforms force these two loops onto one set of rails. Either they drag the outer loop's ceremony onto the inner loop — and now spinning up a departmental tool takes a ticket and a week — or they let the inner loop's imperative magic leak into the outer loop, and now a machine is co-authoring your production source of truth. Both are failures. The inner loop suffocates, or the outer loop loses the trust that was its whole point.

The interesting problem is not making either loop faster. It's the seam between them.

Why source-code management isn't the bottleneck anymore

Walk the inner loop and ask where the time actually goes. It is almost never in writing the source. It's in everything between "the code exists" and "the thing is running the way it's supposed to":

• A database that exists, with a user scoped to this environment, with grants.
• A workflow namespace registered, a bucket cut, a message topic with an ACL.
• Ten secrets materialized and wired into the pods that need them.
• An image pinned by digest so the thing running is provably the thing built.
• A reconciler that will keep it that way, and hand it back if it drifts.

None of that lives in the source repository, and none of it should. It's the configuration of running software — the desired-state graph — and it is now the scarce, error-prone, governance-critical artifact. Source-code management solved the wrong half of the problem for the world we're in. The half that's left is orchestration and configuration management of running systems, and it's where the leverage now sits.

This is the quiet thesis under everything Kilter does: treat the running system's desired state as the primary artifact, and treat source as upstream of it.

Kilter's inner loop: provisioned, disposable, instant

For the inner-enterprise loop, Kilter leans all the way into imperative magic — because that's the right tradeoff for something transient. You run one command and an operator does the tedious, stateful work for you:

Behind that, the controller builds and pushes the image, renders the kilter-app chart, provisions a database and a scoped user, registers a workflow namespace, cuts an object-store bucket, writes the per-app secrets, and commits the result for Flux to take live. Namespace, ServiceAccounts, backing credentials — synthesized at runtime, not hand-written, not in git. For a preview environment that lives ninety minutes, hand-authoring any of that would be madness. This is the inner loop working as it should: fast, magical, disposable.

That same magic is exactly what you do not want touching the outer loop.

kilter package: the seam, made into a command

The outer loop wants the opposite of magic. It wants the deployed state to be precisely what a human reviewed in a pull request — pure declarative Kubernetes, no hidden imperative layer, reconciled by your ArgoCD behind your RBAC. No kilter operator, no CRD, no kilter-server, no Flux on production. Nothing of ours in your change-control boundary.

So the seam between the loops becomes a first-class verb. kilter package takes a provisioned inner-loop environment and transmutes it into a declared, operator-free bundle:

Four things happen, and every one of them is an act of configuration management, not source-code management:

1. Render to plain manifests. The same kilter-app chart the inner loop runs is materialized to vanilla Deployment / Service / HTTPRoute / Job — no Helm wrapper, no operator. Declared, not injected.
2. Materialize the credentials. The provisioners that mint databases and users and buckets run once, at promotion time, on the kilter plane — and their output is frozen into the bundle as real, referenced secrets instead of being conjured at runtime on production. The thing production runs on is inspectable, not summoned.
3. Pin the image by digest. The exact image is retagged by @sha256 into the production registry. Digest-only, never a floating tag. What ships is provably what was built.
4. Open a pull request into your production GitOps repo — with an ArgoCD Application and a self-heal/prune policy — where your process gates the merge and ArgoCD reconciles on the other side.

The artifact that crosses the boundary is a reviewed diff of running state. Not a source diff — a desired-state diff. After it merges, a git log of the production repo genuinely tells you how production got its database, because the database's existence is now a declared, reviewed fact rather than a side effect of a controller nobody watched. Configuration management of the running system is the source of truth. The application source is one input to it, upstream and increasingly cheap.

Why this is the shape of the next decade

The inner-enterprise loop is going to explode in volume. When source is cheap to produce, the number of small, purposeful, transient systems a company runs goes up by an order of magnitude — one per team, per project, per experiment, per agent. Every one of them needs to be orchestrated and configured and, when it matters, promoted across the seam into governed production. The scarce skill and the scarce tooling is no longer "manage the code." It's "manage the running system's desired state, at volume, without losing the ability to trust the parts that face the world."

That's the bet. The inner loop is where velocity lives; the outer loop is where trust lives; the promotion between them is where the value is. Source-code management got us here. Orchestration and configuration management of running software is what carries us forward — and the seam between the two loops is the most important interface in the enterprise.

Kilter is being built exactly on that seam. The inner loop ships today. The package command that walks the boundary is landing now — the design is written down in ADR-0028, and the first slice of the command is already in the tree.

---

This is the enterprise-adoption companion to GitOps Is the Control Plane, which walks the promotion mechanism in detail, and to Modern Kubernetes Is Delightfully Elegant — and Almost Even Small, which named the seam in the first place.