Committed order. No promised dates.
Surfil ships in a fixed sequence where each product is blocked until the previous one's foundation gate passes. That makes the order trustworthy - and makes date promises dishonest.
Why the next thing waits for the last thing
Gating is the anti-drift device: it stops us shipping product nine badly to announce product ten early.
One spine, extended in order
Every product is a stage on the same interception pipeline. Building stage N+1 on an unproven stage N would compound every defect.
Gates are closure criteria
A gate is a written checklist - measured behavior, CI assertions, signed outputs working end to end. Passing it is binary, not vibes.
Dates would corrupt this
The moment a date is promised, the pressure is to soften the gate. So we commit to the order and stay honest about the timing.
Shipped · in progress · planned
Three columns, three different strengths of claim. Only the first one is a fact.
Shipped
4Gate passed. Live and verifiable today.
In progress
3Gate open. Being built and measured now.
Planned
4Gate not yet open. Order is committed; timing is not.
What actually reprioritizes things
The roadmap listens to three inputs, in this order.
Measured pain
A signed receipt showing where users lose the most tokens or catch the most close-calls outranks any opinion - ours included.
Early-team constraints
Teams running Surfil in anger shape gate criteria directly. A blocking constraint from a real rollout moves faster than a feature request.
The invariants
Anything that would compromise zero-trace, signed outputs, one-layer or fail-closed doesn't get prioritized. It gets declined.
Judge the roadmap by the log
The best evidence this roadmap means something is the list of gates already passed. Read it, then tell us what your team needs next.