Skip to main content
TruStacks

The record

What we decided, when, and what we decided against.

Every architectural decision here was written down before it was built, with a date on it. This page is the summary. It exists because the useful question about a young product is not what it does today — it is whether the shape was reasoned about or arrived at by accident.

A changelog tells you what was built. This tells you what was chosen, and what was turned down to choose it. The second one is the only one that predicts anything.

The first seventy-two hours

28 Apr 2026
Policy is Rego, evaluated by OPA — written in the repository’s first commit, before any code.
29 Apr 2026
The gate is running. Agent output is evaluated against signed rules before a pull request can open.
30 Apr 2026
Rules ship as cosign-signed OCI bundles, verified before they are extracted.

We are not claiming nobody thought of this before us — policy-as-code in delivery is older than this company. The claim is narrower and it is checkable: the gate was not retrofitted. It was the first thing built, and everything since has had to arrive through it.

  1. PolicyPROJECT_BRIEF.md @ fdb6d48

    Policy is Rego, evaluated by OPA

    The project brief in the repository's very first commit names Rego and OPA as the policy language and engine — before any code existed.

    Why

    The alternative was a bespoke rule format, which is faster to build and would have been a mistake. Rego was chosen because regulated and Red Hat estates already run it: the gate had to be legible to the buyer's security team, not just to us. A proprietary policy language would have made every audit conversation start from scratch.

  2. Where it runsADR-0001…0006

    Six architecture decisions recorded on the first day

    Ingress, per-repository deploy keys, customer-supplied connection profiles, per-provider variants, the model choice, and the control-plane to runner event contract — all written down on day one.

    Why

    Not because any of them was hard, but because the habit is the point. A team that starts recording decisions on day one still has the record in month four; a team that starts in month four has already lost the reasoning behind everything that matters most.

  3. Policycommit ba51fda

    The policy gate runs, with the first five constitution rules

    One day after choosing the engine, agent output was being evaluated against signed rules before a pull request could open.

    Why

    Building the gate first, with only five rules behind it, forced every later feature to arrive through it. Retrofitting a mandatory gate onto a system that already works without one is a migration nobody ever finds time for.

  4. Where it runsADR-0017

    Read and preserve — an agent may not erase your work

    Before emitting anything, the agent reads what is already in your platform repository, and the pull request states what it kept and why.

    Why

    The default behaviour for a generator is to overwrite. That is fine on a greenfield repository and catastrophic on one carrying two years of hard-won customisation — which is exactly the estate worth selling to. Preserving by default cost us generation quality early on and bought the right to be pointed at a real repository.

  5. EvidenceADR-0038

    Presence is not validity

    Emitted artifacts are validated before the pull request opens, rather than merely checked for existence.

    Why

    A gate that confirms a file exists is theatre. It passes on a syntactically valid workflow that could never run, which is precisely the failure mode AI-generated output produces — plausible shape, broken substance. Checking existence was the cheap version and we had shipped it; this decision replaced it.

  6. PolicyADR-0009

    How the policy layers aggregate

    The constitution, specialist packs, and the customer overlay each get their own subdirectory in the policy runtime, and are aggregated at evaluation time rather than merged at build time.

    Why

    This is the decision that made ratchet-only layering possible at all. Merging the layers into one flat bundle would have been simpler and would have destroyed the property: once flattened, there is no way to prove which layer a rule came from, and therefore no way to prove a customer rule only tightened ours.

  7. PolicyADR-0011

    Baseline Security is the first specialist, and specialists are consulted rather than chained

    Specialist agents are invoked through a delegation event contract, not wired into a fixed pipeline.

    Why

    A fixed chain would have made every new compliance domain a release. The contract meant SOC 2 could ship as an add-on later without touching the crew, and it is why specialist coverage is a packaging question today rather than an engineering one.

  8. PolicyADR-0014

    Rules can be scoped to particular agents

    A rule can declare which agents it applies to, rather than every rule being evaluated against every agent's output.

    Why

    Without scoping, a rule written for infrastructure output fires on application code and produces noise, and noisy gates get switched off. The scoping decision is what let the gate stay mandatory — a control people cannot disable is only tolerable if it is not wrong most of the time.

  9. PolicyADR-0015

    OPA runs embedded, with written triggers for splitting it out

    Policy evaluation shells out to the OPA binary inside the runner, and the three conditions that would justify moving to a sidecar were written down in advance.

    Why

    The interesting half is the second one. Recording the migration triggers up front means the question gets answered from a document instead of re-litigated every time a new architect reads the codebase. It also keeps one security boundary rather than exposing a policy API inside the pod.

  10. Supply chainADR-0019

    Every published image carries an SBOM and a signature

    Runner images are built with an SBOM attached to the manifest and signed with Sigstore keyless OIDC against the release workflow's identity.

    Why

    Keyless was chosen over a long-lived signing key specifically so that there is no key to leak, rotate, or be asked about in a security review. The answer to "how do you protect your signing key" is that there is not one.

  11. Where it runsADR-0020

    Customers bring their own LLM key

    The customer supplies their own Anthropic or OpenRouter credentials and pays the provider directly.

    Why

    The obvious commercial move was to resell inference at a margin. We chose against it: reselling would put customer prompts and source code through our billing relationship, and the moment we are a token reseller, the incentive to have agents talk more runs against the customer's interest.

  12. PolicyADR-0013

    The open-core boundary, and splitting out the policy repository

    The constitution and community packs sit on the open side of the line, in a separate repository from the product.

    Why

    Drawing this line early is what makes the portability claim real rather than aspirational. A policy artifact that lives inside a proprietary product is a configuration file with extra steps; one that lives in a separately licensed repository can outlive the vendor relationship.

  13. EvidenceADR-0022

    Audit evidence is aggregated read-only, never authored

    Auditor evidence reports are generated by reading what already happened, with control-family templates and PDF rendering on top.

    Why

    The decision was that the system may never compose evidence it did not observe. An evidence generator that can write is a liability the first time an auditor asks how a number was produced.

  14. PolicyADR-0023

    Rule creation is permissive; naming is enforced by the constitution itself

    Authoring a new rule is deliberately unrestrictive, while the naming standard is enforced by a rule in the constitution.

    Why

    Enforcing our own convention through the same mechanism customers are subject to, rather than through a special case in the tooling, was the point. A governance product that exempts itself from its own gate is telling you what it actually thinks of the gate.

  15. Where it runsADR-0024

    The runner pulls outbound; credentials travel sealed

    The runner in the customer's cluster reaches out to the control plane rather than accepting inbound connections, and credentials move envelope-sealed with per-tenant custody.

    Why

    This is why there is no inbound hole in a customer firewall and no shared secret store holding one tenant's credentials next to another's. It also settled the pricing question later: because LLM traffic goes from the customer's cluster straight to the provider, metering it was never an option we had.

  16. PolicyADR-0027

    Security velocity, and closing the loop without ever auto-merging

    The remediation direction was set as a closed loop that proposes and validates, with the no-autonomous-merge constraint restated as a hard boundary on it.

    Why

    This was the decision point where speed and autonomy could have been traded for each other. Faster remediation is worth a great deal, and the merge step is where accountability lives, so the loop closes right up to the merge and stops.

  17. PolicyADR-0030

    Findings have a governed lifecycle

    A security finding moves through an explicit lifecycle, with remediation proposed as a reviewable change rather than applied.

    Why

    The tempting version auto-applies low-risk fixes. Every definition of "low risk" we tried was a judgement call dressed as a threshold, and a judgement call the customer did not make is exactly what this product exists to prevent.

  18. EvidenceADR-0046

    Maturity is scored per application, and coverage must be earned

    The maturity score is calculated per application, and coverage counts only what has actually been demonstrated rather than what has been declared.

    Why

    A score that rises because someone filled in a form is a vanity metric, and an auditor will find that out faster than the customer will. Scoring per application also stops one well-governed service from flattering an estate.

What this page is not

It is not a claim to have invented anything. Policy-as-code in software delivery is older than we are, and several of these decisions are about how to apply an existing idea rather than about having one.

It is also not the primary source. Each entry summarises a dated decision record that lives in our product repository, and that repository is not open to the public yet — so today you have our restatement rather than the document. We would rather say that plainly than imply you can go and read something you cannot. When it opens, these entries link straight through.

Recorded decisions run from 2026-04-28 to 2026-08-11, and this summary was last checked against the source on 2026-08-11. If one of these is wrong, tell us and we will correct it.