Making the work easier to follow
Protocol is giving product progress, research, and future direction clearer public labels so readers can tell what changed, what is being tested, and what remains an idea.
The decision
Protocol has been moving faster than its public story. The product has a detailed build record, but people should not need commit history or internal plans to understand what changed and what the team is still exploring.
We are making that work easier to follow through one Updates timeline. Releases, engineering notes, founder decisions, and research can live together as long as each piece says what kind of update it is and where the boundary sits.
Why it matters
A release note should explain behavior someone can use. A dev log can show work taking shape before it reaches the public product. A research note should make the question visible without turning the answer into a promise.
Those distinctions matter more as Protocol grows beyond one Training surface. Coach work can be real engineering without being publicly available. Supplements can be serious product research without becoming a recommendation engine or a shipped module. Clear labels make the build-in-public trail more useful and keep future direction from being mistaken for current behavior.
What changes here
The Updates page will carry more of the operating record: small releases, larger product foundations, research boundaries, and the decisions behind them. Dates will follow documented milestones instead of being invented to make the page look busy.
The aim is a record a lifter, coach, or early customer can read without translating internal language. Progress should feel current because the work is current, not because the timeline has been polished into false certainty.
Next
The next entries will catch the public record up with Training reliability, the Coach workspace, and the Supplements adoption study while keeping released, in-development, and research-only work visibly separate.