Launch verdict

Every scan ends in a single verdict — the answer to 'can I launch this thing?' The four states, what triggers them, and what to read next.

Most founders read the verdict and the Top 3, then move on. That’s the design. Everything else exists to back it up.

The four states

  • Ready to launch

    No launch blockers across the seven pillars at your current stage.

    Warnings may still exist; advisory items definitely do. Neither blocks launch. The expected next step is to ship and let PulseLight start watching for drift.

  • Risky but shippable

    No hard blockers, but enough warnings to be worth a beat.

    You can launch. You probably shouldn’t do it on a Friday. Think of this as “safe enough for early users, fix the warnings before scaling.”

  • Not ready yet

    One or more launch blockers in pillars relevant at your current stage.

    The Top 3 names the worst three. Each carries a paste-ready Fix-with-AI prompt. Fix, re-scan, iterate.

  • Monitoring only

    You marked the project as launched. PulseLight switches into post-launch mode.

    The verdict copy reframes from “can I launch?” to “is what I shipped still what I shipped?” Drift detection runs against your launch baseline; new blockers surface as alerts.

How the verdict is derived

Each of the seven pillars has a status — ready, needs work, blocked, or not applicable. The verdict is the roll-up:

  • Any pillar blocked at your current stage → not_ready_yet.
  • No blocked pillars but multiple needs work → risky_but_shippable.
  • No blocked, few or zero needs work → ready_to_launch.
  • You marked launched → monitoring_only.

Why findings can disagree with the verdict

Stage matters. A Scalable-pillar finding (CVE risk, AI token spend, DB hotspot) lands in the “Later” bucket on a pre-launch project — not a blocker. The same finding on a scaling-stage project would block. PulseLight reads your project profile to decide what counts now.

Re-scans

Push to your default branch and a re-scan kicks off automatically. You can also trigger a scan manually from the project page or via the CLI before a feature ships. Acks (false positives, accepted risks) update the verdict at request time — no re-scan needed for the badge to decrement.