17 KiB
Release and Freeze Policy v1 📦
First formal policy for release timing, freeze boundaries, and version discipline
Quick links:
- Back to Atlas landing page
- Back to Atlas Hub
- Open Atlas Final Freeze v1
- Open Atlas Negative Space Report v1
- Open Atlas v1 Integrated Handoff
- Open Patch Governance v1
- Open Patch Wave 2 Freeze Note v1
If Patch Governance v1 explains how later growth should happen, this page explains when something is ready to be published, when it is ready to be frozen, and how those states should be read without confusion.
That is the real job of this file.
This document is not here to add new structure to the Atlas.
It is here to keep release language, freeze language, and version boundaries clean enough that the system stays readable as it grows.
Short version:
release means ready to enter official system navigation
freeze means stable enough to stop silent rewriting
patching means later growth now has to happen explicitly
Quick start 🚀
I am new to release and freeze policy
Use this path:
- read Atlas Final Freeze v1
- read Atlas Negative Space Report v1
- read Patch Governance v1
- read this page
- then read any relevant freeze note or patch-wave note
I already know the Atlas and want the shortest route
Start here:
- read Section 2 for the core policy distinction
- read Section 5 for the four major states
- read Section 6 and Section 7 for release and freeze criteria
- read Section 11 for what should never happen
- read Section 13 for the practical rules
Shortest possible reading:
released does not mean universally complete
frozen does not mean unpatchable
and version boundaries must stay visible
What this file protects 🛡️
This page protects the Atlas system from a very common kind of documentation drift.
Without a clear release and freeze policy, people start to blur together things that should stay distinct:
- work in progress
- released
- frozen
- patched
- superseded
That creates confusion fast.
This policy exists so the system can grow without making readers guess:
- what is official
- what is stable
- what is still open
- what changed
- what did not change
That clarity is part of system trust.
1. Why this document exists
A system like the Atlas can become confusing very quickly if release language is sloppy.
Without a formal policy, people may start to confuse:
- released with complete
- frozen with permanent
- public with fully validated
- patched with unstable
- work-in-progress with official structure
Those confusions damage trust.
This document exists to prevent that.
It establishes a disciplined reading:
release is about formal publication readiness
freeze is about structural stability boundaries
patching is about controlled later growth
and none of these automatically imply universal completion
That distinction is essential.
2. Core policy distinction ✨
The most important distinction in this document is this:
Release
A release means a document, layer, or system component is ready to be used, referenced, and entered through official system navigation.
Freeze
A freeze means a document, layer, or system component is stable enough that later changes should no longer happen through silent rewriting.
These two states are related, but not identical.
A component may be:
- released and frozen
- released but not yet strongly frozen
- internally stable but not yet released
- open and still under construction
The policy must preserve those differences.
3. What “released” means in this system 📣
In the Atlas system, a release means the following:
- the asset is real enough to be linked from official system navigation
- the asset has a clear role
- the asset has enough coherence to be read on its own terms
- the asset is ready for public or semi-public reuse in its intended scope
- the asset is no longer only an internal rough draft
A release does not automatically mean:
- final
- exhaustive
- unpatchable
- globally complete
- universally validated
This matters because many strong systems need to release before they are globally complete.
That is healthy.
4. What “frozen” means in this system 🧊
In the Atlas system, a freeze means the following:
- the asset now has a stable interpretation boundary
- the asset should not be silently rewritten
- later growth should proceed through explicit notes, patches, or later version nodes
- readers may safely treat the current wording and structure as a stable reference point
A freeze does not automatically mean:
- finished forever
- immune to future patching
- maximally expanded
- final across all possible domains
A freeze is a stability statement, not an eternity statement.
That is the correct reading.
5. The four major states 🗂️
For practical use, Atlas assets should be read through four main states.
State 1 · Work in progress
This means:
- the asset is still under active construction
- its role may still shift
- its wording may still change substantially
- it should not yet be treated as a stable reference
This state is normal for new branches, exploratory pages, and early work layers.
State 2 · Released but light-freeze
This means:
- the asset is coherent enough to publish
- the role is already readable
- the system may officially link to it
- but the structure is still expected to receive meaningful short-term tightening
This state is useful for materials that are ready to be seen but not yet ready for stronger freeze claims.
State 3 · Released and frozen
This means:
- the asset is coherent enough to publish
- stable enough to serve as a reference
- strong enough that later change should proceed through explicit patch discipline
This is the strongest normal status for a stable Atlas layer.
State 4 · Archived or superseded
This means:
- the asset remains part of lineage or version history
- but a later document or note now serves as the preferred current reference
The Atlas system should preserve this status carefully to avoid confusion.
6. Release criteria 📌
An Atlas asset should usually be released only when the following conditions are satisfied.
6.1 Role clarity
The document must have a clear job.
A document should not be released if a reader cannot tell whether it is:
- core structure
- teaching layer
- adapter layer
- bridge layer
- patch note
- governance page
- support page
6.2 Structural readability
The document must be readable enough to stand on its own.
That does not mean it must be small.
It means its internal logic should be understandable.
6.3 Consistent system placement
The document must fit the current system map.
Its location, naming, and link position should make sense inside the Atlas folder structure.
6.4 Claim discipline
The document must clearly signal what it does and does not claim.
This is especially important for bridge documents, repair-facing documents, and future-facing pages.
6.5 Stable enough wording
The document must not still depend on obvious placeholder wording or unresolved role confusion.
A release can still be patchable.
But it should not feel like an internal scratchpad.
7. Freeze criteria 🔒
An Atlas asset should usually be frozen only when the following stronger conditions are satisfied.
7.1 Stable interpretation boundary
Readers should be able to tell what the asset means without relying on unstable side context.
7.2 Stable role in the system
The asset should no longer be drifting between roles.
For example, a document should not be frozen if it still feels half like a patch note and half like a core document.
7.3 Sufficient pressure survival
The asset should have survived enough conceptual, structural, or system-level pressure to justify stability.
This does not always mean benchmark pressure.
It may mean:
- boundary pressure
- teaching pressure
- routing pressure
- bridge pressure
- governance pressure
7.4 Negative-space compatibility
A frozen document should be able to coexist with explicit limits.
If it can only look strong by hiding what remains open, it is probably not ready to freeze.
7.5 Patchable without silent rewrite
A frozen document should be strong enough that future growth can happen around it without constantly rewriting it from inside.
That is one of the most practical freeze criteria in the whole system.
8. When to use paired documents 🔗
Some Atlas layers are strongest when they are frozen as paired documents rather than as a single text.
This is already visible in the system.
Example
Atlas Final Freeze v1 and Atlas Negative Space Report v1
This pair works because one document defines:
- what is stable
and the other defines:
- where stability intentionally stops
This is often the correct pattern when a system must be both strong and honest.
Paired freezing should be considered when:
- one document would otherwise overclaim
- one document defines positive structure and the other defines limits
- the layer is important enough that stability and openness both need explicit wording
This is a feature, not a weakness.
9. Release and freeze by layer 🧱
Different Atlas layers should not all be judged by exactly the same release or freeze threshold.
9.1 Core Atlas layer
This layer requires the strongest freeze threshold.
Examples include:
- mother table
- major boundary rules
- canonical node structure
- frozen top-level interpretation
This layer should be released carefully and frozen only after serious structural confidence exists.
9.2 Teaching layer
This layer may often be released earlier than the deepest structural layer, as long as its role is clear and it does not overclaim core finality.
Examples include:
- casebook pages
- negative teaching packs
- demo explanation pages
9.3 Adapter layer
This layer often benefits from staged release:
- release once usable
- freeze once output discipline and behavior stabilize
- patch later through explicit versioning
9.4 Bridge layer
This layer requires especially careful wording.
Bridge documents may be released once evidence exists, but frozen only when:
- the bridge is real enough to cite
- the limits are explicit
- the claims remain disciplined
9.5 Product-support layer
This layer may release relatively early, but should still preserve consistency with the frozen system.
Examples include:
- onboarding pages
- product positioning
- public copy
- demo storyboards
These can be more flexible, but should still remain version-aware.
10. Relationship to patching 🔄
Release and freeze policy must work together with patch governance.
The clean relationship is:
- release says something is ready to enter the system map
- freeze says something is stable enough to stop silent rewriting
- patching says how later change should happen after that boundary exists
That means later patching is not a contradiction of freezing.
On the contrary:
patching becomes healthier once freezing exists
because the system now has stable reference points.
11. What should never happen ⛔
The following are policy failures and should be avoided.
11.1 Release inflation
Do not release every rough page just because it exists.
That makes the system noisy.
11.2 Freeze inflation
Do not freeze pages just because they feel useful.
Freeze is a stronger claim than usefulness.
11.3 Silent supersession
Do not allow a new page to quietly replace an older frozen page without explicit version signaling.
11.4 Frozen-core drift
Do not keep a frozen title while slowly rewriting its actual meaning.
That is one of the most dangerous policy failures.
11.5 Hidden status ambiguity
Do not leave readers unsure whether a page is:
- experimental
- official
- released
- frozen
- patch-only
- superseded
Status ambiguity is governance debt.
12. Recommended status language 🏷️
To reduce confusion, Atlas assets should use a small number of consistent status phrases.
Recommended release phrases
- in progress
- released
- released in MVP form
- released as first formal version
- released as official entry layer
Recommended freeze phrases
- frozen
- formally frozen
- frozen at first-release level
- frozen as patch node
- frozen as bridge layer
- frozen with open edges
Recommended caution phrases
- does not claim universal closure
- remains patch-sensitive
- remains open for later thickening
- not a final end-state document
- should not be silently rewritten
Consistency here matters more than style.
13. Practical release rules for current work 📎
For current Atlas work, the most useful operational rules are these.
Rule 1
Do not link a document from the main Atlas hub until its role is clear enough to stand on its own.
Rule 2
Do not freeze a document until its interpretation boundary is strong enough to resist silent drift.
Rule 3
If a document needs a strong “does not claim” section to stay honest, that is fine.
That may mean it is ready for a paired or cautious freeze, not that it is weak.
Rule 4
If a layer is growing quickly, release can happen before stronger freeze.
But that status should be explicit.
Rule 5
If later work materially changes how a frozen page should be read, write a patch note or later version node.
Do not quietly rewrite history.
These five rules already prevent many future problems.
14. Relationship to system trust 🤝
Release and freeze policy matter because trust is not built only by content.
Trust is also built by version behavior.
A reader trusts the Atlas more when they can see:
- what is stable
- what is new
- what is still open
- what changed
- what did not change
That visibility is part of the product, part of the documentation system, and part of the AI-facing reuse discipline.
This is why policy matters.
15. Recommended official wording 📣
When you need one short release-and-freeze statement for a new window, support page, or collaboration thread, use wording like this:
In the Atlas system, release means a document is ready to enter official system navigation, while freeze means its interpretation boundary is stable enough that later growth should proceed through explicit patching rather than silent rewrite.
Released does not mean universally complete, and frozen does not mean unpatchable.
The system grows by making those boundaries explicit.
This wording is strong, accurate, and reusable.
Next steps ✨
After this page, most readers continue with:
If you want the broader Atlas surface:
16. One-line status 🌍
This document defines how Atlas documents and layers become released, frozen, patchable, or superseded without losing version clarity or structural trust.
17. Closing note
A system becomes easier to trust when it knows how to name its own states.
That is what release and freeze policy does.
It does not make growth slower.
It makes growth readable.