Invite-only access
The private beta is not open enrollment. Access is granted by invite, can be constrained by cohort, and may be paused or narrowed when operator capacity, evidence quality, or risk posture requires it.
Preview terms
Private beta access is real, but it stays inside an explicit operating boundary.
These terms make the preview clear: invite-only access, bounded automation, operator-mediated support, and the right to hold, freeze, or roll back the environment when control quality matters more than surface smoothness.
Core terms
The preview boundary is easy to understand before the first mission starts.
A disciplined private beta tells invited users what kind of access they have, what kind of operator intervention remains normal, and how the system behaves when safety and evidence quality outrank convenience.
Hold-first operating model
Guided missions and support intake are designed to stay inside explicit approval, handoff, and operator review. Beta access does not imply unrestricted automation or silent release.
Change and rollback authority
The platform may freeze, hold, or roll back staging changes without notice when a release would otherwise weaken tenant safety, evidence integrity, or the authority boundary.
What to expect
The preview operates in four simple phases.
The goal is to remove ambiguity from the first-run experience so a serious evaluator can distinguish bounded preview behavior from product failure.
Before access
Read the docs, trust, status, and preview terms surfaces first so the private beta is entered with the right operating assumptions.
During use
Use the guided workflow, expect review-sensitive steps to remain operator-aware, and treat the beta as a disciplined preview rather than a generally available contract.
When something breaks
Use the support path. The system is built to convert customer friction into explicit operator work, not to rely on hidden exception paths or informal DM support.
When evaluation deepens
If the beta survives product fit and trust inspection, the next step becomes tighter diligence, private evaluation, or a higher-assurance review rather than casual scope creep.
Interpretation
Read the beta as a governed preview, not as a soft promise of GA.
Assume
- The product is real enough to use and inspect.
- Operator-visible control is part of the product, not a temporary workaround.
- Support, review, freeze, and rollback remain legitimate beta behaviors.
Do not assume
- General availability, unrestricted scale, or long-term backward compatibility.
- Silent fulfillment of every task without approval, hold, or review.
- That preview access changes the public documentation or security boundary.
Next move
The correct next step depends on what is still unresolved.
If the product proof is compelling, move into tighter evaluation. If the trust model is still unclear, stay inside docs and trust. If the environment is sensitive, use the higher-assurance path instead of stretching the standard technical review past its limit.
Access path
Preview terms close the trust loop before access widens.
Preview terms make private-beta use feel deliberate instead of provisional. They clarify the boundary, then route the evaluator toward the next justified step.
Before this
Status
The status contract explains the current operating posture and degradation boundary.
Open StatusCurrent step
Preview terms
Invite-only access, support posture, and rollback authority are explicit here.
You are here
Next step
Request access
Once the preview boundary is acceptable, the next move is to request access with the right evaluation context attached.
Open Request access