Pressure Release Readiness Playbook

Release readiness for Pressure is treated as a decision gate, not a general feeling that the build seems stable. The question is not whether the plugin sounded good during informal use. The question is whether the same evidence chain that protects engineering also supports a buyer-facing claim of production reliability.

That standard matters more for Pressure than for a throwaway utility release because it is positioned as a flagship product. If the flagship has fuzzy acceptance criteria, every later quality claim on the site becomes weaker.

The release rubric starts with the published lane model in BPTS. The fast lane is there to catch obvious regressions early, but it is not enough to justify release. Gate has to stay clean on the full whitebox regression set, and release candidate lanes have to show that the build is stable in conditions that look like actual delivery, not just local development convenience.

For Pressure specifically, the release review also expects rc and rc_gui evidence to agree on the basics: the whitebox suite stays green, Pluginval is either satisfied or explicitly skipped for documented headless reasons, and the BOL gate confirms that characterization expectations still match committed baselines.

Lab evidence matters too. Pressure exposes enough nonlinear and timing-sensitive behavior that transfer curves, THD analysis, and envelope-response verification are not side material. They are part of deciding whether the release still behaves like Pressure.

The Gauntlet is the easiest result to communicate because the framing is simple: one million randomized parameter mutations at 192kHz with 32-sample buffers, zero tolerance for crashes, zero tolerance for glitches. That makes it a strong stress signal, and it should absolutely stay in the release conversation.

But stress survival alone is not enough. A plugin can survive abuse and still regress in characterization, drift from expected timing, or carry a known test-framework blind spot that needs to be called out publicly. Shipping decisions get worse when one dramatic benchmark replaces a fuller evidence review.

The rule we want is straightforward: treat The Gauntlet as a necessary signal, not a sufficient signal.

One clean run is emotionally persuasive and operationally dangerous. Teams naturally want to believe the most recent successful pass, especially when a release is close and the build feels stable. But good release process should resist that instinct. Fast, gate, rc, rc_gui, and lab exist precisely so one impressive pass does not get mistaken for a release system.

That is also why repeatability matters. A release candidate should not be trusted because it once passed under ideal conditions. It should be trusted because the surrounding lanes agree, the evidence is recent, and no unresolved caveat is being quietly pushed out of scope to make the timeline feel cleaner.

Observatory adds the operational view that turns a pile of test outputs into a release narrative. It is where lane behavior, run status, and execution history become inspectable enough to answer the boring but important questions: which run are we trusting, was it rerun after the last risky change, and are we looking at one clean pass or a stable pattern.

That matters because release meetings usually fail at record-keeping before they fail at technical detail. If evidence is scattered across CI logs, local notes, and memory, the process quickly becomes personality-driven. Observatory reduces that drift by making run behavior part of the system instead of part of somebody's recollection.

Research Notes are the product-facing evidence layer. They keep a named version attached to the checks that were completed, the measurements that were published, and the limits of those results.

This is the practical release rule: product copy must not imply broader qualification than the versioned record supports. Known release blockers stay blockers instead of being rewritten as confidence.

The buyer-facing takeaway is not that Bellweather enjoys building elaborate testing theater. It is that Pressure moves through a release process where lane results, characterization work, stress evidence, and release identity all have to agree before the product is described as ready.

That is the useful kind of rigor. If a user wants to skim, they can see the result. If they want to inspect the process, the supporting surfaces exist and the claims resolve into something concrete.