Every piece of information that passes through Project Forge is evaluated on two axes before it is allowed to settle anywhere: stability and residence. These are related but distinct properties. Getting them right — in the right order — is what keeps case state out of the canonical core, prevents temporary reasoning from leaking into durable surfaces, and ensures that material earns its place before becoming project basis.Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/gpt-pf-chat-gpt-project-forge/llms.txt
Use this file to discover all available pages before exploring further.
Stability and residence are kept as separate axes because stable information does not automatically become canonical, and volatile information does not automatically become runtime-only. Residence depends on stability, authority, role, and operational consequence — not on stability alone. Conflating the two is a common source of premature promotion.
The Two Axes
Stability
Stability answers: is this information stable enough to persist across runs or contexts? Project Forge defines exactly two stability classes:PERSISTENT— the information is confirmed stable by the operator, or it recurs coherently across at least two cycles without contradiction and without depending on a single runVOLATILE— the information is session-local, run-specific, or transient
Residence
Residence answers: where is this information allowed to live? Project Forge defines four residence classes:CANONICAL— inside the governing canonical files; permanent, normative, non-case-specificEXTERNAL_ARTIFACT— in a defined artifact outside the canonical core; may carry stateRUNTIME_OPERATOR_INPUT— provided explicitly by the operator at each run; not storedDO_NOT_STORE— must not be serialized, promoted, or carried forward
The Stability-to-Residence Rule
Stability is decided first. Residence is assigned second. This order matters because assigning residence before stability is closed creates false structure — it gives information a home before knowing whether it deserves one. The allowed and forbidden combinations are exhaustive and fixed:| Stability | Residence | Allowed? |
|---|---|---|
PERSISTENT | CANONICAL | ✅ Allowed |
PERSISTENT | EXTERNAL_ARTIFACT | ✅ Allowed |
PERSISTENT | RUNTIME_OPERATOR_INPUT | ✅ Only through the explicit exception |
VOLATILE | EXTERNAL_ARTIFACT | ✅ Allowed |
VOLATILE | RUNTIME_OPERATOR_INPUT | ✅ Allowed |
VOLATILE | DO_NOT_STORE | ✅ Allowed |
VOLATILE | CANONICAL | ❌ Forbidden |
PERSISTENT | DO_NOT_STORE | ❌ Forbidden |
The Forbidden Combinations
The two forbidden combinations are not edge cases — they represent the system’s two main failure modes:VOLATILE → CANONICAL would allow transient or session-specific content to contaminate the governing files of the system. Even if it looks useful in the moment, volatile material in canonicals destroys recoverability and authority clarity.
PERSISTENT → DO_NOT_STORE would erase stable, normative information that should be available for future use. DO_NOT_STORE is for temporary residue — not for information that governs downstream decisions.
The PERSISTENT → RUNTIME_OPERATOR_INPUT Exception
This exception exists for a narrow class of cases where information is stable in nature but must still be reaffirmed explicitly by the operator at each run. It is allowed only when all required positive conditions are true and no disqualifier is active. Required positive conditions:operator_confirmation_required— the information must be explicitly reaffirmed each run because of operational risk, explicit human responsibility, or a non-delegable local choice
operator_preference_only— repetition by habit or preference is not sufficient to keep material at runtime-only residencecanonical_or_artifact_mandatory— if the information stably governs downstream decisions, runtime-only residence is insufficient regardless of operator preference
CANONICAL or EXTERNAL_ARTIFACT.
DO_NOT_STORE
DO_NOT_STORE material leaves no authorized trace in the system’s persistent surfaces. It is consumed in the current run and goes no further. If material ends up here, there is no path back from it to official basis.
Source Validation Criteria
Before material can become official project basis — regardless of where it will eventually reside — it must pass source validation. Project Forge defines five validation criteria from01_RULES.md:
- Authority — does the source carry legitimate authority for this question?
- Direct relevance — is the source directly relevant to the current objective?
- Explicit role — is the source’s role explicitly defined, not assumed?
- Freshness — when the question is time-sensitive, is the source current?
- Contradiction status — does the source contradict other validated material?
Promotion Eligibility
Promotion moves material into a more durable or authoritative residence. It is intentionally conservative. Material is eligible for promotion only when all three of the following conditions are true:Stabilized
The content is confirmed stable by the operator, or it recurs coherently across at least two cycles without contradiction and without depending on a single run. One useful result from one session is not stabilized.
Normative
The content authorizes, constrains, or governs downstream decisions. Descriptive or contextual material that does not govern anything does not qualify.