The release gate: features that ship when they're real, not when you say so

A status field is the easiest lie in software. Anyone can drag a card to Done or flip a feature to released — the label moves, nothing is checked, and the word now means whatever the last person to touch it wanted it to mean. By the time the gap surfaces it’s a production incident, not a column on a board.

Zensu inverts that. released isn’t a state you assign — it’s a state you earn. Every status transition runs through a release gate, and if the feature can’t clear the bar, the transition simply doesn’t happen.

What the gate checks

When a feature tries to move to released, the gate evaluates it against an org-level policy and collects every reason it isn’t ready:

• docs — documentation must be complete (on by default).
• coverage — test coverage must clear the floor, if your policy sets one.
• journey health — the critical user paths this feature sits on must be green, not failing.
• security — and here it gets interesting.

Each unmet condition becomes a concrete violation. You don’t get a red X with no explanation; you get the list.

The security bar scales with risk

A throwaway internal toggle and a credentials-handling auth endpoint should not face the same scrutiny — so they don’t. The gate is risk-proportional: it reads the feature’s security classification and applies a different bar to each.

• public / internal — no extra security requirements out of the box.
• confidential — security score ≥ 3.0 and an approved security review.
• restricted — score ≥ 5.0 and a completed threat model and an approved review and a passed pentest.

Low-risk features sail through on docs alone. The expensive checks attach only to the features that actually carry the risk — so the gate stays out of your way exactly where it should, and stands firm exactly where it must.

$ zensu features status AUTH-7 released     # classification: restricted
  ✗ gate  transition denied — 3 blockers
          • security score 3.2 below minimum 5.0
          • threat model must be completed for restricted features
          • documentation must be complete before release

  ... threat model completed · docs published · score now 6.1

$ zensu features status AUTH-7 released
  ✓ gate  released — every blocker cleared

Releases bundle it

A single feature passing its gate is one thing. Shipping a release — a first-class entity in Zensu that groups many features — is the harder promise, because a release is only as ready as its weakest member.

So the publish transition is an AND across every feature in the release. Each member walks its own path to released; the release ships only when all of them have. Try to publish early and you get a per-feature breakdown of exactly who’s holding the line:

release 2026-Q3  →  released
  ✗ publish gate — 2 of 5 features not ready
          AUTH-7    threat model incomplete
          PAY-3     documentation incomplete
          ZEN-42    ✓     BILL-9 ✓     API-2 ✓

No more chasing five tabs to assemble the readiness picture by hand. The gate assembles it for you, and refuses to lie about it.

You own the policy

The bar is yours to set. The default is deliberately light — docs required, everything else opt-in — so the gate helps from day one without becoming a bureaucracy. Tighten it when you’re ready: raise the coverage floor, require journey health, demand a pentest on restricted features. The policy lives at the org level, versioned and explicit, instead of in the head of whoever reviews PRs.

Why a gate beats a convention

“We don’t ship without docs” is a convention, and conventions erode under deadline pressure — the one time you skip it is the time it mattered. A gate doesn’t negotiate. It keys off the feature’s actual recorded state — its score, its review status, its linked docs, the health of its journeys — so the rule holds on a quiet Tuesday and the night before a launch alike.

That’s the whole point of treating features as first-class citizens with a real lifecycle: released stops being a hopeful label and becomes a verified fact. From roadmap to release, the last step is the one you can’t fake.