Constitution

The constitution is the Rego policy TruStacks writes and every proposal is judged against. It is Apache 2.0, lives in the public trustacks-policy repository, and is published as a signed OCI artifact. Free at all tiers.

The runner evaluates it with OPA inside your cluster, after the DevOps Engineer emits a proposal and before anything is written to your platform repo. A proposal with any deny never becomes a pull request.

The rules

Twenty-four rules in three kinds. The kind decides what a rule can do. Eight of them apply only to ECS Fargate targets (Beta), and four only to Kubernetes targets; see Which targets a rule applies to.

Gate rules

Is the artifact the right shape, in the right place?

Only the renderer check that matches your Application’s renderer applies, and only on a Kubernetes target. A Fargate target has no renderer.

Behavior rules

Is the artifact doing the right thing? Each one maps to a practice key in your environment profile.

The test-step and lint-step rules judge CI workflows. A Fargate deploy workflow applies an artifact and has no suite to run, so it is skipped; the CI workflow beside it is still judged.

Why most Fargate rules score nothing yet. A practice key is a row on every customer’s score. Adding one that only Fargate can check would add a row Kubernetes customers could only self-attest, and lower their coverage for a check that does not apply to them. So these rules refuse bad Fargate proposals today and score nothing. ecs_task_runs_as_nonroot is the exception: its intent is the same as the Dockerfile rule’s and it is enforced in the artifact, so it feeds non_root_containers.

Why the prod-environment rule never scores. It proves the deploy job names a GitHub environment. Whether that environment has required reviewers is a repository setting TruStacks does not read, and on private repositories it depends on your GitHub plan. If the rule’s silence counted as “a human approves promotion to prod: verified”, the score would claim something nobody checked. For a Fargate Application, that practice can only be claimed, by your attestation.

Tags are not image identity. A commit-SHA tag can be overwritten by anyone who can push to your registry, and ECS resolves the tag when it deploys. ecs_task_image_is_pinned guarantees there is no floating tag. It does not guarantee the image that runs is the one that was reviewed. Until deploys pin a digest, that guarantee does not exist.

Which targets a rule applies to

Every rule declares the target kinds it applies to in its metadata (target_kinds), beside the tiers it applies to (tier_scope). A rule without target_kinds applies to every kind.

argocd.repoURL_is_canonical declares no kind, but it only inspects ArgoCD Applications, so it never fires on a Fargate proposal. The runner tells the policy which kind and tier a proposal targets (input.context.target). A target with no kind is Kubernetes, so policy judges older runners exactly as before. A policy bundle older than 1.3.0 knows nothing about Fargate and refuses a Fargate proposal for having no ArgoCD Application: it fails closed.

Posture rules

Do you run the tools? These never refuse a proposal. A missing scanner is a gap in your posture, not a broken artifact, so it shows up in your gap report and your score instead of blocking delivery.

The naming rule

constitution.overlay_rule_naming checks the IDs of your own overlay rules against the rule-naming standard. It judges overlay rule metadata, not proposals.

How the score uses the rules

Two rule fields drive the maturity score:

• required_tooling_categories puts a tooling row on the scorecard. Today that is six categories: ci_cd_platform (from proposal.has_workflow), gitops_controller (from proposal.has_argocd_application), and the four posture categories.
• practice_dimensions puts a practice row on the scorecard: the five practice keys above. Two rules feed non_root_containers (the Dockerfile rule and the ECS task rule); the other Fargate rules feed none yet.

Gate rules with neither field are enforcement only. They never move your score.

How the policy reaches your runner

The constitution is published from the trustacks-policy repository.

Hosted runners follow the :1 tag. Fixes in the 1.x line reach your runner on its next start, without a runner upgrade. A 2.0 that needs a newer runner never arrives on a tag your runner follows.

At start, the runner’s load-policy-bundle init container resolves :1 to a digest, pulls that digest, and verifies its signature. If anything fails it falls back to the copy of the constitution baked into the runner image and reports why. See Policy in force.

Policy versions independently of the product. The constitution is on the 1.x line; runner and control-plane releases are on 0.2.x. See Versioning.

Verify the policy yourself:

cosign verify \
  --certificate-identity-regexp '^https://github\.com/TruStacks/trustacks-policy/\.github/workflows/publish\.yml@refs/tags/v.*$' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/trustacks/policy/constitution:1

Your own rules

Overlay rules let you add your own reasons to refuse a proposal. Their denies are unioned into the constitution’s (data.proposal.deny), so an overlay can only add refusals. It has no way to cancel a constitution deny. That holds by how the policy is assembled, not because a tool proves it.

What works today:

• Drafting. Type /rule new <id> in the Workspace chat and the Coordinator drafts a rule grounded in your environment profile. Drafts are not saved; copy or download them.
• Authoring and testing. trustacks rule new, test, and lint work on a local checkout. See the Rule CLI.

What is not in the constitution

• Rules about approvals, review counts, or who may merge. Merge control belongs to your git provider’s branch protection.
• Rules about credentials, data residency, or citations.
• Waivers. There is no waiver mechanism.
• SOC 2, HIPAA, PCI, or FedRAMP rules. See Specialist Packs.

Where to go next

• Maturity scoring · how rules become a score
• Policy in force · what your runner is actually enforcing
• Proposal lifecycle · where the gate sits
• Supply-chain verification · every artifact and its signing identity