The architect who knows why the legacy service deploys on Sunday nights is retiring

To keep tribal knowledge after the person who holds it leaves, turn each mechanical constraint they carry into a rule that is enforced, not just written down: drafted with them, tested, version-controlled, and checked against every proposed change. Documentation records the rule. Enforcement is what keeps it true once nobody remembers why it exists.

That is the short answer. The long one starts with a person.

Every organization has one

There is a service — billing, ledger, settlement, something old and quietly load-bearing — that only goes to production on Sunday nights. Nobody new knows why. It is not in the README. If you ask, you get pointed at one architect, who will tell you, patiently and for the fortieth time, that a nightly export reads that service's tables partway through its run, and a deploy during the week once left the export half-written.

That architect has been right about this for years. They are also, at some point, going to retire, or move teams, or take a well-earned sabbatical. That is good news for them. It is only bad news for the organization if the organization has been storing a production constraint in one person.

The Sunday rule has siblings everywhere. This service cannot restart during market hours. That migration needs the DBA on call. This integration breaks if it ships before the batch job finishes. Each one is true, each one was learned the hard way, and each one lives somewhere no tool can see.

When the person leaves, the rule leaves

Nobody deletes a rule like this. It simply stops being enforced, because the enforcement was a person reading a pull request and saying not on a Tuesday.

The rule is then rediscovered the way these rules always are: as an incident. And the postmortem's action item is, almost invariably, add this to the runbook.

Why the runbook is not the fix

Documentation fails here for a structural reason, not a diligence one. Documentation is consulted by people who already suspect there is a problem. The change that breaks a tribal rule comes from someone who has no reason to suspect anything — which is exactly why it breaks the rule. Nobody looks up the Sunday constraint at four on a Friday, because nobody at four on a Friday knows there is one.

There is a newer version of this problem, too. More of the changes reaching your pipeline are now drafted by AI agents, and an agent works from what is in front of it: the repository, the stack, the request. A constraint that exists only in a person, or in a wiki page nobody linked, is invisible to it. That is not the agent misbehaving. It is the agent being exactly as informed as everyone else who never met the architect.

The fix for both is the same. The rule has to sit where every change passes through it, not where a careful person might go and look.

What the rule looks like

Here is the Sunday constraint, written as a customer overlay rule in Rego. The service and the acme. namespace are illustrative; the shapes are the real ones TruStacks evaluates.

package overlay.acme_billing_rollup_sunday_window

import rego.v1

rule_metadata := {"acme.billing_rollup_sunday_window": {
	"description": "billing-rollup syncs to prod only inside the Sunday-night window. The nightly ledger export reads its tables mid-run; a sync during the week corrupts the export.",
	"required_tooling_categories": [],
	"practice_dimensions": ["change_management"],
	"tier_scope": ["prod"],
}}

rule_index := rule_metadata

deny contains msg if {
	some f in input.proposal.files
	f.path == "argo-apps/argo-apps-prod/billing-rollup-application.yaml"
	doc := yaml.unmarshal(f.content)
	not _in_sunday_window_project(doc)

	msg := {
		"rule_id": "acme.billing_rollup_sunday_window",
		"message": sprintf(
			"%s must use the billing-sunday-window ArgoCD project, which only opens a sync window on Sunday nights",
			[f.path],
		),
	}
}

_in_sunday_window_project(doc) if doc.spec.project == "billing-sunday-window"

Three details are doing the real work.

The rule reads the proposed change, not a clock. The check runs when an agent proposes a change, before any pull request exists — so it cannot know when someone will eventually press sync. What it can do is make sure the service never leaves the ArgoCD project whose sync window only opens on Sunday night. The window itself is configured on your AppProject and enforced by your own ArgoCD. TruStacks emits configuration; you run it on your stack. The rule's job is to stop any proposal from quietly moving the service out from under that window.

The why travels with the rule. The description is not a comment for whoever opens the file in five years. It is part of the rule's metadata, which is what the agents read when they cite a rule, and a denial comes back as an object carrying its rule_id rather than a bare string. When a proposal trips this rule, the person reviewing it sees which rule objected and the architect's reason, in the architect's words.

It tightens a rule that is already there. The constitution — the signed policy bundle we author and ship at every tier — already includes practice.argocd_prod_requires_manual_sync: an ArgoCD Application targeting production must not sync automatically, so a human approves the sync. The architect's rule does not replace that. It adds to it. The constitution's own gate gathers every overlay rule's denials into the same set as its own, so an overlay rule is one more reason a change can be refused. You can read both the manual-sync rule and that aggregation step in the constitution as published.

And it ships with tests, because a rule with no test is a rule nobody can safely change:

package overlay.acme_billing_rollup_sunday_window_test

import data.overlay.acme_billing_rollup_sunday_window as r
import rego.v1

_path := "argo-apps/argo-apps-prod/billing-rollup-application.yaml"

test_default_project_is_denied if {
	r.deny with input as {"proposal": {"files": [{
		"path": _path,
		"content": "spec:\n  project: default\n",
	}]}}
}

test_window_project_passes if {
	count(r.deny) == 0 with input as {"proposal": {"files": [{
		"path": _path,
		"content": "spec:\n  project: billing-sunday-window\n",
	}]}}
}

We ran both files with opa test, and then again alongside the published constitution: a production manifest in the wrong project, with automated sync switched on, is refused by both the architect's rule and the constitution's manual-sync rule; a compliant one clears both. You can repeat that with the two files above, the published constitution, and OPA. Being able to rerun it is the point of writing the rule as code instead of prose.

The architect still does the important part

None of this works if codifying knowledge means someone else transcribing the architect. Most of the value is in the questions only they can answer: which service, which window, what counts as a violation, which exceptions are real.

So the workflow puts them in the chair. In the TruStacks chat, an architect types /rule new followed by the constraint in plain English. The Coordinator proposes a rule id, then drafts the Rego and its metadata. The architect reads the draft and decides whether it says what they meant — and it is usually their objection to the first draft that captures the knowledge that was never written anywhere. The agent does the syntax; the human does the judgment.

From there it is an ordinary piece of code in the team's overlay repository:

trustacks rule new acme.billing_rollup_sunday_window   # scaffold the rule and its test file
trustacks rule test acme.billing_rollup_sunday_window  # run the tests with OPA
trustacks rule lint                                    # naming standard, required files, metadata, opa check
trustacks rule sign                                    # build, push, and cosign-sign the overlay bundle

The team commits and opens the pull request themselves. Humans merge rules the same way they merge everything else.

What changes when they leave

The rule is still there, and it is still doing what the architect did: reading every proposed change and saying not that way. It is version-controlled, so the history says who wrote it and when. It is tested, so the next person can change it without guessing. It is signed, and the runner checks that signature before it loads the bundle.

It can still be changed, and it should be. One day the nightly export will be retired and the Sunday window will be pointless. Removing the rule then is a reviewed diff in the overlay repository with somebody's name on it — not a forgotten conversation, and not a constraint that silently stopped applying because the one person enforcing it was at their leaving drinks.

What a rule can't hold

The honest version of this argument concedes something. A rule holds a constraint. It does not hold judgment: the instinct for which of five odd behaviours matters this week, the history of why the constraint exists, the sense that a technically compliant change is still a bad idea. Those live in people, and a policy engine is the wrong instrument for them.

That is the reason to do this while the architect is still here. Sit with them and ask a plain question about each system they own: if you saw a pull request touching this, what would you check? Each answer that is mechanical — a path, a project, a field, a window — is a rule. Each answer that is judgment stays a conversation, and is worth recording too, in the runbook where judgment belongs.

The first rule takes an afternoon. Most of that afternoon is listening.

Where this sits

TruStacks is AI delivery governance — the control layer between the agents that write your software and the systems that run it. The constitution sets a floor every proposal must meet. The customer overlay is where your organization's own context goes: the things that are true about your systems and nobody else's, written by the people who learned them.

Codify tribal knowledge before it walks out the door.

Agents propose. Policy decides. Humans approve.

Customer overlay authoring — the trustacks rule CLI and Coordinator-assisted drafting in chat — is part of the Team tier, listed as coming soon on /pricing. The constitution's rules, including the manual-sync rule above, apply at every tier. See the facts page for what is live versus roadmap, each entry with a verification date, and /product/policy for the policy model in more depth.