RESEARCH
Alpha readiness review of v0.3: green light for public alpha
16 October 2026
By Milber Ferreira, with OpenAI's models. The review that led to v0.3.1, reproduced as written; formatting converted to Markdown. Its SliceOps finding was verified and is correct.
Yes. I would approve SLICE Framework v0.3 for public alpha testing, with a few small corrections before publication.
Having reviewed the 21-page specification, I believe it is sufficiently coherent to put in front of founders, product leaders and AI-assisted engineering teams.
It has what an experimental methodology needs: clear principles, an operating process, defined terminology, conformance rules, measurable hypotheses and an explicit account of how it might fail.
However, the launch positioning matters:
SLICE Framework v0.3 — Public Alpha. An experimental product roadmapping and delivery framework for small, AI-assisted teams. Open for practical testing, criticism and refinement.
Do not call it a proven framework, industry standard or successor to Scrum. Public alpha is precisely where those claims begin to be tested.
One finding that must be addressed before publication
The new search confirms that SliceOps does exist, despite the statement on page 20 of the uploaded v0.3 that it could not be found.
Its official website is sliceops.org. It already describes itself as an open, decision-first framework for AI-first software engineering, using atomic slices, decision records, acceptance evidence and agent governance. It also publishes a trademark policy for SliceOps dated June 2026.
This is not evidence that SLICE infringes its rights, nor does it mean the frameworks are identical. But the naming and positioning overlap is material.
Before the alpha announcement, I would:
- Correct the SliceOps entry on pages 6 and 20.
- Explain SLICE's emphasis on product investment, roadmapping, delivery forecasting and outcome validation, as distinct from SliceOps' engineering audit and execution emphasis.
- Use SLICE as a provisional working name, pending trademark and brand clearance.
I would not delay testing the methodology because of this. I would delay treating the name as a permanent public identity.
My recommended alpha launch
Keep the 21-page document as the reference specification, but create a simpler entry point.
| Asset | Launch requirement |
|---|---|
| Public alpha overview | A one-page explanation of the problem, principles and how to start |
| SLICE Guide v0.3 | Current specification, with the naming correction |
| Quick Start | Apply SLICE to one initiative and three slices in 15–20 minutes |
| Templates | Roadmap item, Slice Card and Evidence Record |
| Pilot protocol | Baseline, measurement definitions, hypotheses and feedback process |
| Public repository | Version history, known limitations, issues and contribution guidelines |
The repo should identify the project's licence and explain how participants' feedback and any shared project data will be handled.
How I would run the first alpha
| Item | Setting |
|---|---|
| Status | Approved to start |
| Initial participants | 5–10 teams |
| Pilot duration | 8 weeks |
| Target team size | 1–25 people |
| Participation | Free, voluntary |
Pilot sequence
- Publish the corrected specification and starter templates.
- Invite a diverse cohort of solo founders, small AI-first teams and conventional engineering teams.
- Collect 2–4 weeks of previous delivery data where available, without delaying participation for teams that lack it.
- Run SLICE for eight weeks, tracking overhead, decisions, delivery, quality and outcomes.
- Publish a transparent alpha report including failures, missing data, participant differences and recommended changes.
I would make two further adjustments to the evaluation protocol: label the six pilot success thresholds as exploratory rather than evidence of causation, and mark F3 statistical forecasting unavailable until its calibration criteria are defined. The specification already excludes F3 from initial pilots, which is appropriate.
Final decision
GO — Start the public alpha.
No more major methodology redesign before testing. Correct the SliceOps research, prepare the onboarding materials, and put SLICE in the hands of real teams.
Version 0.3 is ready to be tested, not declared finished. The community should help determine what survives into v0.4.
I would also make one principle central to the alpha itself: if a team needs hours of explanation before it can use SLICE, we have reproduced the planning overhead the framework is supposed to reduce.