Outcome
go
Launch-critical criteria are satisfied with evidence that is recent, attributable, and reviewable.
TR-2533 launch readiness gate
Launch should be gated by evidence, not momentum.
This first launch-readiness slice turns the review gate into a visible internal shell. It makes domains, evidence classes, critical paths, blocker classification, and final decision outcomes explicit before any real go / hold decision is claimed.
Gate questions
- Are we actually ready to launch?
- What evidence proves that?
- What is a blocker versus a named follow-up?
- What outcome should the review produce?
Allowed gate outcomes
The launch gate should use only a small explicit set of outcomes.
Outcome
go_with_named_followups
Launch may proceed only if remaining items are clearly bounded, non-launch-critical, and owned.
Outcome
hold
Launch is not approved yet, but the blockers appear addressable with more evidence or bounded fixes.
Outcome
no_go
Major trust, safety, money, or readiness gaps make launch indefensible until the underlying truth changes.
Launch domains
Readiness should be reviewed through explicit domains so no trust-critical area disappears into general optimism.
Trust and security readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Core product readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Data and migration readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Money and billing readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Support and incident readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Onboarding and documentation readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Bilingual readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Public-claim and marketing readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
QA and operational evidence readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Operator launch-control readiness
Each domain needs attributable evidence and a clear pass, blocker, or follow-up judgment.
Evidence bundle requirements
The gate should gather one explicit review packet instead of relying on memory or scattered links.
Required evidence classes
- Product and workflow validation evidence
- Security and trust posture evidence
- Billing and money-system evidence
- Onboarding and documentation evidence
- Support and incident-readiness evidence
- Bilingual validation evidence
- Open-risk register with owner and severity
- Final decision memo
Evidence quality rules
- Specific
- Attributable
- Recent enough to matter
- Reviewable by operators
- Clearly linked to the claim it supports
Evidence bundle schema
Each claimed readiness point should resolve into a small inspectable record before launch.
Evidence item metadata
- Claim supported
- Evidence owner
- Captured date
- Validation method
- Linked artifact or route
Readiness judgment
- Pass/fail state
- Open risk if any
- Launch-blocking yes/no
- Reviewer note
Critical-path validation matrix
A launch review is not real unless the highest-trust paths are explicitly checked.
Sign-up or account start
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
Auth and initial access
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
Core church setup basics
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
Pricing and trial comprehension
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
Import or defer-import decision path
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
At least one core product workflow path
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
Support and escalation path
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
Billing or giving trust-explanation path where applicable
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
Public trust and status-surface comprehension path
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
EN and ES validation across the highest-trust flows
Each path should capture owner, pass/fail state, evidence link, open risk, and whether it is launch-blocking.
Blocker and follow-up classification
Not every issue should block launch, but launch-critical trust gaps must be called what they are.
Allowed labels
- launch_blocker
- high_risk_followup
- normal_followup
- future_enhancement
Bias toward blocker when the issue affects
- Trust or safety
- Billing or money correctness
- Privacy or permissions correctness
- Core workflow viability
- Truthful onboarding or support expectations
- Bilingual correctness on launch-critical paths
Current bilingual launch posture
The current public launch shell is English-first. Spanish parity remains an explicit review and implementation task for trust-sensitive surfaces, so no Spanish path should be implied equivalent until it is rechecked and landed.
- Current live launch shell content is English-first.
- Spanish parity is still in progress for trust-sensitive launch surfaces.
- Do not imply equivalent EN/ES launch readiness until the specific surface is re-reviewed and landed.
Bilingual validation checklist
Launch readiness should treat EN and ES parity as evidence, not as a vague intention.
- EN and ES launch-critical paths preserve the same consequence meaning.
- Trust, pricing, migration, support, and caution language stay aligned across both languages.
- Spanish is not materially weaker on clarity, restriction, or next-step guidance.
- Any unsupported ES surface is disclosed instead of presented as equivalent.
Review memo and decision packet
The gate should end in one explicit review memo with a clean decision packet, not implied launch by momentum.
Required review memo sections
- Recommended outcome
- Why that outcome is justified
- Confirmed launch blockers
- Named follow-ups with owners
- Bilingual validation summary
- Operator recommendation and approval note
Decision packet checklist
- Final gate outcome selected from the allowed set only.
- Evidence bundle attached or linked for each launch-critical claim.
- Blockers separated from follow-ups by explicit label.
- Approval path and final approver recorded clearly.
Approval and review posture
This shell should make the approval path conservative and explicit.
Required review inputs
- Evidence bundle
- Blocker list
- Named follow-up list
- Bilingual validation summary
- Support and incident readiness summary
- Operator recommendation
Approval rules
- Brent approval is required before actual launch.
- No autonomous launch decision from planning artifacts alone.
- If evidence conflicts, conservative interpretation wins until revalidation.
Current shell boundaries
This keeps the page honest about what has landed and what still requires live review evidence.
What this page is
A launch-shell review surface for domains, evidence, critical paths, blockers, and go/hold/no-go handling that stays explicit about what still requires live evidence.
What is not yet real
- This is not yet a live evidence packet with populated pass/fail data.
- It does not yet include a named blocker register drawn from actual launch review state.
- It does not replace Brent approval or prove launch readiness by planning posture alone.
Use this gate after the supporting shells are ready
This review surface depends on product, support, onboarding, and ops layers being inspectable first.
Review public launch surfaces
Check homepage, pricing, help, support, and onboarding truth before claiming launch readiness.
Open public shell →Review support and ops posture
Check structured intake, support assistant, ops queue, and the support playbook before saying support is ready.
Open ops playbook →Review onboarding posture
Check the getting-started and first-week launch docs before claiming churches can succeed without heroics.
Open getting-started guide →