Project Forge operates from a strict authority hierarchy. Every surface in the system — canonical files, validated external artifacts, and runtime operator input — has a defined place in that hierarchy. When two surfaces appear to conflict, authority determines which one governs. When a runtime override is attempted, authority determines whether it is allowed. Understanding the authority model is what makes the difference between using Project Forge correctly and quietly rewriting its rules through accumulated pressure.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.
The Authority Hierarchy
Authority closes in this order. No lower surface may overrule a higher surface.1 — 00_SCOPE.md
The highest authority in the system. Closes system identity, scope, non-scope, target, and final output. Nothing below this file may redefine these. The frame set here governs everything else.
2 — 01_RULES.md
Highest on criteria. Closes the authority hierarchy itself, stability and residence classes, source validation criteria, promotion eligibility, readiness criteria, and the peer authority conflict rule. Lower files apply these rules; they may not redefine them.
3 — 02_PROTOCOL.md
Highest on procedure. Applies the criteria closed in
01_RULES.md and the artifact grammar closed in 03_ARTIFACTS.md. Defines states, output minimums, and stop conditions. Does not invent new criteria.4 — 03_ARTIFACTS.md
Highest on artifact surface and artifact grammar. Defines which artifact classes exist, their schemas, triggers, and freshness rules. May define artifact-local authority. May not redefine canonical truth, scope, criteria, or procedure.
5 — Validated external artifacts within delegated local authority
Artifacts carry state and have local, delegated, subordinate authority only. A validated artifact governs its own local surface. It does not govern the system as a whole. An artifact may never redefine system frame, canonical rules, or protocol.
The Cross-Reference Rule
A lower file may reference a higher rule. A lower file may not redefine a higher rule. This distinction is not subtle — it is the mechanism by which the system remains coherent.02_PROTOCOL.md frequently references rules closed in 01_RULES.md. That is correct operation. If 02_PROTOCOL.md were to introduce its own, different version of a stability class or promotion criterion, that would be a collision, not a reference.
Reference is not decision. Citing a rule does not give a lower surface authority to modify it.
The Collision Rule
A collision exists only when:- a lower surface introduces autonomous criteria on a question already closed by a higher surface, or
- a surface decides outside its own authority quadrant — answers a type of question that belongs to a different file
Immutable vs. Overrideable Fields
Project Forge draws a hard line between fields that are permanently fixed and fields that may adapt at runtime.| Category | Immutable Fields | Overrideable Fields |
|---|---|---|
| System definition | System identity, system frame | — |
| Governance model | Authority hierarchy | — |
| Classification model | Stability model, residence model | — |
| Promotion model | Promotion model | — |
| Artifact model | Artifact grammar | Artifact choice already allowed by canonicals |
| Readiness model | Readiness model | — |
| Operational scope | — | Current-turn objective, temporary priorities, temporary exclusions |
| Runtime materials | — | Current materials under evaluation, run-local constraints |
Two Conflict Shapes
Project Forge distinguishes two fundamentally different kinds of conflict, because they require different resolution strategies.Higher-vs-Lower Contradiction
A lower surface introduces a claim that contradicts a higher surface on the same point. This is resolved by canonical precedence: the lower surface does not authorize the point. No negotiation is needed. The hierarchy closes it.Peer-Authority Divergence
Two surfaces at the same authority level — two validated external artifacts, or two peer-authority validated sources — diverge on the same point.Peer-authority divergence cannot be resolved by automatic precedence. Between peer-authority surfaces, no surface outranks the other. The minimum outcome is
CONFLICT until higher-surface validation or explicit revalidation closes the point. This conservative rule exists to prevent the system from pretending that order, recency, or file proximity creates authority when they do not.