Skip to main content

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.

Project Forge is governed by four stable files called the canonical core. Each file closes a different type of question: frame, criteria, artifact grammar, and procedure. Together they form a complete authority surface. None of them holds live case state, artifact instances, or runtime decisions — those belong in external artifacts. Understanding the canonical core means understanding not just what each file says, but why the four files are kept separate and how they relate to one another when a conflict arises.

​
The Four Canonical Files

Each file has a declared authority domain. A file governs questions inside that domain and is not permitted to be overruled by files below it in the hierarchy.
FileAuthority DomainCloses
00_SCOPE.mdHighest on system frameSystem identity, scope, non-scope, target, final output
01_RULES.mdHighest on criteriaAuthority hierarchy, stability classes, residence classes, source validation, promotion, readiness criteria
03_ARTIFACTS.mdHighest on artifact surfaceArtifact classes, schemas, triggers, freshness rules, artifact grammar
02_PROTOCOL.mdHighest on procedureMinimum working procedure, states, output minimums, stop conditions
The four files do not overlap in their authority claims. If a question can be answered by 00_SCOPE.md, no lower file may reopen it. If an artifact-grammar question arises, 03_ARTIFACTS.md is the governing surface — not 02_PROTOCOL.md.

​
Read Order vs. Precedence

These are two distinct concepts that are frequently conflated. Project Forge separates them deliberately.

Read Order

For comprehension. Read canonicals in this sequence to build the correct understanding of the system before applying it.
  1. 00_SCOPE.md
  2. 01_RULES.md
  3. 03_ARTIFACTS.md
  4. 02_PROTOCOL.md
This order is optimized for legibility: frame first, criteria second, artifact grammar third, procedure last.

Precedence Order

For conflict closure. When two canonical surfaces appear to conflict, this order determines which one governs.00_SCOPE.md > 01_RULES.md > 02_PROTOCOL.md > 03_ARTIFACTS.mdNote that 02_PROTOCOL.md outranks 03_ARTIFACTS.md in precedence, even though 03_ARTIFACTS.md is read before it.
Read order is about comprehension. Precedence is about conflict closure. The difference is intentional. 03_ARTIFACTS.md is read before 02_PROTOCOL.md because the protocol applies artifact grammar — you need to know the grammar before reading the procedure that uses it. But if 02_PROTOCOL.md and 03_ARTIFACTS.md ever diverge on a non-artifact-grammar question, 02_PROTOCOL.md governs.
Do not start from 02_PROTOCOL.md alone — without frame, rules, and artifact grammar, procedure can be misread as permission. The protocol applies criteria already closed above it. Read alone, it looks like a complete operating manual. It is not.

​
Why There Are Four Separate Files

A single canonical file would collapse four different types of closure into one surface, which makes conflict detection and authority assignment much harder. Each file answers a different kind of question:
1

00_SCOPE.md — What kind of system is this?

Closes the frame. Defines what Project Forge is, what it is for, what it is explicitly not for, what its target is, and what final output it produces. It does not tell you how to operate the system. It tells you what kind of system you are operating.
2

01_RULES.md — What are the tests that action must obey?

Closes the criteria. Defines the authority order, how information is classified by stability and residence, what counts as validated, what counts as promotable, and what counts as ready. It does not sequence action — it defines what correct action must satisfy.
3

03_ARTIFACTS.md — What external surfaces are allowed?

Closes the artifact grammar. Defines which artifact classes exist, what each artifact is for, what authority each artifact carries, what schemas and triggers each uses, and the order in which artifacts are read. It does not decide truth for the system as a whole.
4

02_PROTOCOL.md — How does the system work step by step?

Closes the working procedure. Applies the criteria already closed in 01_RULES.md and the artifact grammar already closed in 03_ARTIFACTS.md. Defines states, output minimums for each state, and stop conditions. It does not invent new criteria.

​
What the Canonical Core Does NOT Contain

The canonical core is intentionally kept clean of runtime material. It does not hold:
  • Live case state — belongs in external artifacts, not in canonicals
  • Artifact instances — the canonical core defines grammar; instances are external
  • Runtime decisions — decisions made during a specific run are not stable system structure
  • Domain examples — the core is domain-agnostic by design
  • Handoff content — handoff material is temporary and artifact-resident, never canonical
This separation is what makes the system recoverable. If case state leaked into the canonicals, reopening a project would require untangling live content from governing rules.

​
The Frame Rule

00_SCOPE.md carries a specific and absolute constraint:
Nothing below 00_SCOPE.md may redefine system scope, non-scope, target, or final output.
This means that 01_RULES.md, 02_PROTOCOL.md, and 03_ARTIFACTS.md may reference what 00_SCOPE.md defines. They may apply it. They may not expand it, contract it, or reframe it. The same applies to validated external artifacts and runtime operator input — both are below the canonicals in the authority hierarchy, and neither may touch the frame. The frame rule exists because frame drift is how systems quietly become something other than what they were designed to be.

Build docs developers (and LLMs) love

Get started for freeTalk to us