Freedom without rules is chaos. Freedom with rules is boring.

To enforce delivery standards without slowing engineers down, take the rule-following work off their plate instead of adding gates in front of it. Standards rarely fail because people disagree with them. They fail because complying is tedious. When the pinned actions, non-root containers and rollback notes are written for you and checked before review, the rules hold and the freedom stays.

Our founder put the whole idea in two lines:

Freedom without rules is chaos. Freedom with rules is boring.

And then a third, which is the job description:

We handle the boring mundane so you don't have to.

The rest of this post is what those three lines mean in practice.

Freedom without rules is chaos

It doesn't feel like chaos at first. It feels like speed. You push on a Friday afternoon. The workflow uses some-action@v3 because that's what the README said. The container runs as root because the base image did and nobody changed it. The secret goes in an environment variable because it was the quickest place to put it. It ships. It works. Everyone goes home.

That's the trap: chaos is fun for the person shipping, for a while. Then production finds the thing nobody checked. A tag is a pointer, and pointers can be moved to different code. A root container turns a small bug into a large one. A secret in an environment variable shows up in places secrets shouldn't.

None of that was a bad engineer. It was a fast one, with nobody whose job it was to do the boring part.

Freedom with rules is boring

So the organization does the reasonable thing and writes rules. Then it adds a person to enforce each one. A ticket to get a new pipeline. A change board that meets on Thursday. A checklist in a PDF that nobody can find.

Now delivery is boring. And honestly, boring is the goal: a good deploy is a boring deploy. The trouble is who has to do the boring part. When it lands on the engineers, by hand, every time, it stops being a safeguard and starts being a tax.

And people avoid taxes. When the approved path is slower and duller than the work, people route around it. They copy a workflow from the repo next door, stale pins and all. They stand up a side pipeline that nobody reviews. They paste the problem into whatever AI assistant is open in another tab, which is how shadow AI becomes shadow IT that writes code.

Which is how you end up back at chaos, with extra paperwork. Not too few rules, but rules nobody can afford to follow, so the real work happens somewhere the rules can't see.

Less freedom→More freedom

Many rules, little freedom

Bottleneck

Every rule enforced by hand, through a ticket or a board. The approved path is slower and duller than the work, so people route around it.

✗Ships fast: No

✗Checked before it ships: On paper only

Many rules, lots of freedom

Boring, on purpose

Freedom with rules is boring, and boring is the goal. The chores are done for you and checked before review. A person still merges.

✓Ships fast: Yes

✓Checked before it ships: Yes

Few rules, little freedom

Gatekeeper

One person knows how to deploy, and none of it is written down.

✗Ships fast: No

✗Checked before it ships: No

Few rules, lots of freedom

Chaos

Freedom without rules is chaos. It feels like speed until production finds the thing nobody checked.

✓Ships fast: Yes

✗Checked before it ships: No

Top row: many rules. Bottom row: few rules.

Boring is the only square with two checkmarks, and you can’t get there by adding rules. You get there by taking the boring work off the people who are supposed to be building.

The rules aren't the problem. The chores are.

Ask an engineer whether third-party actions should be pinned to a SHA and they will say yes. Ask them to do it for the fortieth workflow, looking up each commit hash by hand, and watch the enthusiasm leave the room.

Most delivery standards are like that. Nobody disagrees with them. They're just chores: correct, small, repetitive, and easy to skip at 6pm. So the fix isn't a louder rule. It's someone else doing the chore, every time, and something checking that it was done.

That's the part we take.

The boring list

TruStacks is AI delivery governance: the control layer between the agents that write your software and the systems that run it. In plain terms, a crew of agents does the delivery chores, a policy checks the result, and a person decides.

Here is the list, with what checks each item.

The choreWho does it nowWhat checks it

• Write the CI workflow

  ✓The crew writes it, as GitHub Actions

  Checked by: proposal.has_workflow

• Add the test step and the lint step

  ✓The crew writes them

  Checked by: practice.workflow_has_test_steppractice.workflow_has_lint_step

• Pin every third-party action to a SHA

  ✓The crew pins them

  Checked by: practice.workflow_pins_action_versions

• A Dockerfile that doesn't run as root

  ✓The crew writes it

  Checked by: practice.dockerfile_runs_as_nonroot

• The Helm chart and the ArgoCD Application

  ✓The crew writes them

  Checked by: proposal.has_helm_chartproposal.has_argocd_applicationpractice.argocd_prod_requires_manual_sync

• An ECS task definition with a read-only root filesystem and secrets out of env (Fargate, Beta)

  ✓The crew writes it

  Checked by: practice.ecs_task_readonly_root_filesystempractice.ecs_task_secrets_not_in_environment

• Bump the image tag

  ✓TruStacks proposes it as a pull request

  Checked by: The same policy check and human merge as any other change

• Write the PR description: blast radius, rollback, rule citations

  ✓Written on every allowed proposal

  Checked by: Only an allowed proposal becomes a pull request

• Gather audit evidence for a time window

  ✓The product exports it, as JSON or a PDF

  Checked by: Recorded events mapped to six SOC2 controls. The merge itself is in your git history

• Decide what to build. Review the pull request. Merge it.

  ●You

  Your judgment. There is no path that merges without a person.

The crew takes the chores. The judgment stays with you. Rule ids are copied from the public constitution in trustacks-policy. The policy check covers what the crew proposes; commits your people make directly are governed by your own branch protection.

The rules in that list aren't ours to paraphrase, so here are two in their published words:

practice.workflow_pins_action_versions: Every third-party uses: action in a workflow pins to a SHA, not just a tag.

practice.ecs_task_secrets_not_in_environment: No credential-like value in an ECS container's environment; every secrets[].valueFrom is a full Secrets Manager or SSM ARN.

Every proposal the crew makes is evaluated against the constitution before a pull request exists. If it fails, it stops there. The denial is recorded with the rule id behind it, and nothing is opened. If it passes, it arrives as a pull request whose description has Summary, Blast radius, Rollback and Rule citations sections, the last naming the rules it was checked against. The image tag works the same way: when a service's main branch moves, the new tag shows up as an ordinary proposal, not a CI job quietly writing to your deploy state.

And at the end of an audit window, the evidence is an export, not a project. The recorded events map onto six SOC2 controls and come out as JSON or a PDF. The merge itself lives in your git history, which is where an auditor should look for it.

What you keep

The freedom. Boring stays boring, it just isn't your job anymore.

What to build. How to build it. Which framework, which service boundary, which trade-off is worth making this sprint. Whether a pull request is good enough to merge. There is no path that merges without a person, and we haven't built a setting that adds one.

The crew is a coworker, not a replacement. It takes the chores, not the jobs, and not the judgment. The agent does the syntax; the human does the judgment.

One honest boundary, so this stays checkable: the policy check covers what the crew proposes. Commits your people make directly to the platform repository are governed by your own branch protection, not by us. If someone still wants to hand-pin forty actions on a Friday, that's their freedom too.

Rules that hold, freedom that stays

The couplet sounds like a choice most teams think they have to make. Skip the rules and you get speed until production sends the bill. Keep the rules and delivery gets boring, and the people doing the boring part by hand start going around it.

The way out is not a better balance between the two. Boring is right. It just needs to happen somewhere it gets done every time, so the rules hold without anyone giving up the interesting part.

Freedom without rules is chaos. Freedom with rules is boring. We handle the boring mundane so you don't have to.

Agents propose. Policy decides. Humans approve.

The rule texts above are copied from the published constitution in trustacks-policy, where you can read every rule and run its tests with stock OPA. See the facts page for what is live versus roadmap, each entry with a verification date, and /solutions/pipeline-generation for the CI side in more detail.