Skip to main content
TruStacks

For spec-driven shops

Specs declare intent. Policy decides outcome.

The policy substrate spec-driven development left missing.

Spec-driven development tools (GitHub Spec Kit, AWS Kiro, Claude Code plan mode, Cursor commands) gave teams a way to declare what their software should be. None of them answer what it is not allowed to do. TruStacks is the policy-as-code layer for the spec-driven stack.

Your spec can be complete, reviewed, approved, and perfectly implemented, and still ship an unsigned image to production. Nothing in a spec says no.

Where SDD stops

Intent and constraint are different layers.

Specs · Intent

What should the system be?

Markdown specs, structured intent, AI-readable templates. SDD tools converted product requirements into agent-consumable artifacts. Spec Kit alone hit ~97K GitHub stars in less than a year.

Policy · Constraint

What is the system not allowed to do?

Signed, layered, version-controlled Rego rules. The answer your security and compliance teams already trust. The layer SDD tools didn't ship.

The gap

Three layers between an idea and production. Two have owners.

Spec-driven development solved the first. Coding agents solved the second, at a volume nobody expected. The third is the one your auditor asks about, and in most stacks it belongs to nobody.

  1. Layer 1 · Intent

    What should the system be?

    Spec Kit, Kiro, Claude Code plan mode, Cursor commands

  2. Layer 2 · Implementation

    What got built?

    Your coding agents and your engineers

  3. Layer 3 · ConstraintUnowned

    What is it not allowed to do?

    Usually nobody. A wiki page and a reviewer having a good day.

Layer 3, with TruStacksSigned · versioned · tested

A signed Rego bundle your own architects extend.

Evaluated on every proposal, before a human ever opens the pull request. Your overlay rules can tighten it and never loosen it, and a linter proves that at compile time.

Same change, two artifacts

A spec is a wish. A rule is a constraint.

Here is a perfectly good spec, and the rule it cannot express. The spec is not wrong. It is just not the kind of thing that can say no.

order-service.spec.md — intent

## Requirements

- Expose a REST API for order lookup
- Persist orders in Postgres
- Emit an audit event on every write
- Deploy to the staging cluster

Complete, reviewable, and agent-consumable. It describes the system you want.

acme.requires_image_scanning.rego — constraint

deny contains msg if {
  data.env.tooling_categories.image_scanning == []

  msg := {
    "rule_id": "acme.requires_image_scanning",
    "message": "EnvironmentProfile declares no
      image_scanning provider. Add one before
      the next deploy.",
  }
}

Signed, versioned, and tested — this one is a real rule from the sample overlay. It describes what the system may never do, and it is written by your architects rather than by us.

The spec and the rule are both correct. Only one of them fails the build.

The fit

TruStacks layers under your SDD tooling.

Spec your application with your SDD tool of choice. Spec your platform target and governance with TruStacks. Both get evaluated under the constitution before anything merges.

Your SDD tool produces an artifact: a spec, a plan, a draft implementation. TruStacks reads the resulting pull request, evaluates it against your constitution, your Specialist Packs, and your customer overlay, and proposes changes that bring the artifact into compliance. The customer overlay is where your policy authors encode what your specific organization considers allowed. The crew respects all of it.

The boundary

We’re not replacing your SDD tooling.

  • We don't read Spec Kit specs.

    Your SDD tooling owns spec authoring and intent capture. TruStacks evaluates the resulting pull request, not the spec file format.

  • We don't ship Markdown-spec authoring.

    That's a job SDD tools already do well. We complement them at the policy and platform-target layer, not at the spec layer.

  • We're not an SDD product.

    We're the policy-as-code layer SDD tools left missing. Different category, complementary surface.

  • Existing customers don't switch.

    Teams already running Spec Kit, Kiro, Claude Code plan mode, or Cursor commands keep them. TruStacks plugs in at the pull-request layer where policy belongs.

Add policy to your SDD stack.

Bring your SDD tooling. Bring your Rego policies. We’ll walk you through a crew run that evaluates your spec output against your constitution end to end.

Request a demoHow policy works