OpSpot GTM
The proof standard
Advancement is evidence-gated. The kernel requires the evidence types for the requested transition, and every matching item must be current and unexpired. Payment and fulfillment add stricter authority, proof-tier, and non-fixture checks.
Eight states, in order
candidatevalidatingoffer-readylaunch-readyexternally-liverevenue-verifiedfulfillment-verifiedscaling
Any active state may move to parked or killed only through an explicit command. Neither destructive recommendation is ever executed automatically.
What each transition must prove
| Transition | Minimum evidence class |
|---|---|
candidate → validating | Problem, buyer, founder boundary, and source-reference evidence. |
validating → offer-ready | A priced offer, buyer validation evidence, and supportable claim boundaries. |
offer-ready → launch-ready | An acquisition path, payment path, fulfillment plan and capacity, policy bounds, and rollback or kill evidence. |
launch-ready → externally-live | A current, unexpired external-surface-live evidence item. |
externally-live → revenue-verified | An authoritative successful payment or collection event. |
revenue-verified → fulfillment-verified | An authoritative promised-delivery event tied to that payment or customer order. |
fulfillment-verified → scaling | Repeated acquisition and delivery within agreed economics, quality, and founder-intervention thresholds. |
What the engine checks before it advances
- The expected current state matches.
- The requested transition edge is allowed.
- Every named evidence type exists for the same venture.
- Every candidate item for a required evidence type is current and unexpired; stale, conflicting, superseded, and unavailable candidates block the transition.
- Payment and delivery evidence must additionally carry payment or fulfillment authority, the matching proof tier, and must not be a fixture.
- The idempotency key has not already produced a different effect.
Every allow and every deny is written to a transition receipt and recorded in an audit event. A denied request leaves lifecycle state unchanged; an allowed state change is committed in the same storage transaction as its stored result.
Evidence fields, conflicts, and freshness
Evidence records its authority, observation time, optional expiry, status, and content hash. Readiness reports a requirement as conflicting when a referenced source is already marked conflicting. Stale, superseded, and unavailable source conditions also surface as readiness gaps.
Founder language beside the lifecycle
| Plain language | Internal state | Boundary |
|---|---|---|
| Idea | candidate | Only after a venture exists. A pre-venture idea is not represented. |
| Validate | validating | The problem and buyer are being tested against evidence. |
| Build | No exact state | A finished build alone does not earn launch readiness. |
| Launch | externally-live | launch-ready means prepared; externally-live requires current, unexpired external-surface-live evidence. |
| Revenue | revenue-verified | Requires an authoritative successful payment or collection event. |
| Fulfill | fulfillment-verified | Requires promised delivery tied to the payment or customer order. |
| Scale | scaling | Requires repeated acquisition and delivery within the agreed bounds. |
| Exit-ready | No exact state | Exit readiness is a founder destination, not a lifecycle stage. |
Want to operate a company against this standard? See pricing.