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.

The canonical core is the authority of Project Forge. Every decision the system makes — about scope, criteria, artifact grammar, or working procedure — traces back to one of four canonical files. These files do not hold live case state. They define the frame, the rules, and the allowed surfaces. Nothing below them may redefine them. Nothing outside them may override them without explicit delegation. If you need to know what the system is allowed to do, what counts as ready, or what an artifact is permitted to contain, the answer is in the canonicals.
A lower file may reference a higher rule but may not redefine it.

​
Read Order vs. Precedence Order

These are two distinct concepts that are easy to confuse. Understanding the difference is essential for working with the canonical core correctly. Read order is the practical order in which you rebuild the system in a new session. It is optimized for comprehension — frame first, then criteria, then artifact grammar, then procedure. This is the order you give to an AI or follow yourself when entering the system fresh. 
1. 00_SCOPE.md
2. 01_RULES.md
3. 03_ARTIFACTS.md
4. 02_PROTOCOL.md
Precedence order is the authority order used to resolve conflicts. If two canonical surfaces appear to contradict each other on the same point, precedence determines which surface governs. This is not the same as read order because 03_ARTIFACTS.md is read before 02_PROTOCOL.md for comprehension purposes, but 02_PROTOCOL.md outranks 03_ARTIFACTS.md in authority. 
00_SCOPE.md > 01_RULES.md > 02_PROTOCOL.md > 03_ARTIFACTS.md
Read order is about comprehension. Precedence is about conflict closure. Never conflate the two.

​
Canonical File Reference

​
Purpose

Define the identity, scope, non-scope, target, and final output of Project Forge.

​
Authority

Highest on system frame. No lower file may redefine this file on any point it closes.

​
Read Order

Read first.

​
Contains

  • System identity
  • System scope
  • System non-scope
  • Target of the system
  • Final output of the system
  • General use perimeter

​
Does Not Contain

  • Classification rules
  • Residence rules
  • Procedural flow
  • Artifact grammar
  • Readiness logic
  • Source validation rules
  • Runtime override rules
  • Live case state
  • Handoff content
  • Domain examples

​
Key Rules

Identity Project Forge is a permanent preparation system for opening target projects in ChatGPT. Project Forge does not execute the target project. Project Forge prepares the target project.Scope Project Forge may: define what project is being prepared; define what the prepared project must receive to start correctly; define the frame that the core protocol must obey; externalize case state into controlled artifacts.Non-Scope Project Forge must not become: the live target project; a case archive; a long-term mixed notebook; a memory substitute; a raw source dump; a domain-shaped framework pretending to be general.Target The system targets projects that must start from explicit structure instead of reconstruction from chat.Final Output The system produces: a stable canonical core; external artifacts for target-project opening; external artifacts for case state transfer when required.Frame Rule This file closes the frame of the system. Nothing below this file may redefine system scope, non-scope, target, or final output.Success Condition Project Forge succeeds only if: the system remains domain-agnostic; the core remains free of live case state; the target project can open from explicit materials; ambiguity is reduced without being hidden.Final Rule Project Forge exists to prepare projects without becoming one.

​
Purpose

Define the stable criteria of Project Forge.

​
Authority

Highest on criteria. Lower files may apply these rules. Lower files may not redefine these rules.

​
Read Order

Read after 00_SCOPE.md.

​
Contains

  • Canonical precedence
  • Cross-reference rule
  • Collision rule
  • Authority hierarchy
  • Stability classes
  • Residence classes
  • Stability-to-residence relation
  • Source validation criteria
  • Promotion eligibility criteria
  • Documentary readiness criteria
  • Measurable readiness trigger
  • Observability completeness tests
  • Measurable gate pass tests
  • Peer authority conflict rule
  • Handoff criteria
  • Immutable fields
  • Overrideable fields

​
Does Not Contain

  • Procedural sequencing
  • State transitions
  • Artifact instances
  • Live case content
  • Handoff instances
  • Domain examples

​
Key Rules

Canonical Precedence 00_SCOPE.md > 01_RULES.md > 02_PROTOCOL.md > 03_ARTIFACTS.md. If a lower file contradicts a higher file on the same point, the lower file does not authorize that point.Collision Rule Collision exists only if: a lower surface introduces autonomous criteria on a question already closed above; or a surface decides outside its own authority quadrant.Stability Classes
  • PERSISTENT
  • VOLATILE
Residence Classes
  • CANONICAL
  • EXTERNAL_ARTIFACT
  • RUNTIME_OPERATOR_INPUT
  • DO_NOT_STORE
Allowed Stability-to-Residence Combinations
PERSISTENT -> CANONICAL
PERSISTENT -> EXTERNAL_ARTIFACT
PERSISTENT -> RUNTIME_OPERATOR_INPUT  (explicit exception only)
VOLATILE   -> EXTERNAL_ARTIFACT
VOLATILE   -> RUNTIME_OPERATOR_INPUT
VOLATILE   -> DO_NOT_STORE
Forbidden Combinations
VOLATILE   -> CANONICAL
PERSISTENT -> DO_NOT_STORE
Source Validation Criteria Validate sources by: authority; direct relevance; explicit role; freshness when time-sensitive; contradiction status. No unvalidated source may become official project basis.Promotion Eligibility Material is eligible for promotion only if all three conditions are true:
  • stabilized — content is confirmed stable by the operator, or recurs coherently across at least two cycles without contradiction and without depending on a single run.
  • normative — content authorizes, constrains, or governs downstream decisions.
  • non_case_specific — content does not depend on a single machine, anomaly, run, or temporary state.
Immutable Fields System identity, system frame, authority hierarchy, stability model, residence model, promotion model, artifact grammar, readiness model.Overrideable Fields Current-turn objective, temporary priorities, temporary exclusions, current materials under evaluation, run-local constraints, artifact choice already allowed by canonicals.

​
Purpose

Define the grammar of allowed external artifacts.

​
Authority

Highest on artifact surface and artifact grammar. This file may define artifact-local authority. This file may not redefine canonical truth, scope, criteria, or procedure.

​
Read Order

Read after 01_RULES.md and before 02_PROTOCOL.md.

​
Contains

  • Allowed artifact classes
  • System artifact baseline
  • Local artifact authority
  • Artifact surface
  • Artifact schema
  • Write triggers
  • Read triggers
  • Freshness rules
  • Artifact-specific promotion conditions
  • Custom artifact requirements
  • Artifact read order

​
Does Not Contain

  • Live artifact instances
  • Live SSOT content
  • Live handoff content
  • Live target brief content
  • Case state
  • Canonical criteria
  • Procedural sequencing

​
Artifact Read Order

1. TARGET_PROJECT_BRIEF_ARTIFACT
2. INITIAL_SSOT_ARTIFACT
3. SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT
4. HANDOFF_ARTIFACT

​
Baseline Artifact Classes

TARGET_PROJECT_BRIEF_ARTIFACT
FieldValue
PurposeTransmit the minimum project-specific operational brief of the target project
AuthorityLocal to the target project; may not redefine the frame of Project Forge
SurfaceProject-opening artifact
Write TriggerWhen documentary readiness requires a target-project brief
Read TriggerAt target-project opening
Freshness RuleUpdate only when the target-project brief changes
PromotionNever promotable to system canonical
Schema: objective, scope_in, scope_out, required_outputs, project_specific_constraints
INITIAL_SSOT_ARTIFACT
FieldValue
PurposeFreeze the initial official basis of the target project
AuthorityLocal to the target project; initial reference authority for the starting basis
SurfaceOfficial-basis artifact
Write TriggerWhen an initial official basis exists and must be frozen
Read TriggerImmediately after TARGET_PROJECT_BRIEF_ARTIFACT
Freshness RuleUpdate only when the initial official basis changes
PromotionMay be updated only from material already validated under 01_RULES.md
Schema: official_materials, approved_sources, base_constraints, version_or_date
HANDOFF_ARTIFACT
FieldValue
PurposeTransfer operational continuity across runs without redefining frame or SSOT
AuthorityLocal and temporary only; not normative
SurfaceOperational-continuity artifact
Write TriggerOnly when 02_PROTOCOL.md closes HANDOFF_REQUIRED
Read TriggerWhen reopening the immediately following run
Freshness RuleValid only for the immediately following run unless explicitly renewed
PromotionNever promotable to canonical or SSOT
Schema: current_state, recent_tests, open_points, next_move
SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT
FieldValue
PurposeTransfer candidate materials or sources without promoting them to stable basis
AuthorityLocal and subordinate only; not normative until validated
SurfaceMaterial-transfer artifact
Write TriggerWhen materials must pass to the target project without immediate promotion
Read TriggerAfter INITIAL_SSOT_ARTIFACT and before HANDOFF_ARTIFACT, if present
Freshness RuleUpdate on each materially new transfer set
PromotionPromotable only after validation under 01_RULES.md
Schema: candidate_materials, source_type, validation_state, attach_or_review_flag

​
Custom Artifact Rule

A custom artifact is valid only if it explicitly declares all eight of the following fields:
purpose
authority
surface
schema
write_trigger
read_trigger
freshness_rule
artifact_specific_promotion_conditions
If any one of these fields is missing, the custom artifact is not valid.

​
Purpose

Define the minimum working procedure of Project Forge.

​
Authority

Highest on procedure. This file applies criteria already closed above. This file may not redefine criteria, frame, or artifact grammar.

​
Read Order

Read after 01_RULES.md. Read after 03_ARTIFACTS.md when artifact grammar is required for the current move.

​
Contains

  • Intake
  • Target closure
  • Output closure
  • Stability classification
  • Residence assignment
  • Source validation application
  • Promotion flow
  • Readiness gate application
  • Handoff need application
  • Runtime override handling
  • DO_NOT_STORE sink handling
  • Measurable readiness application
  • Peer conflict handling
  • State definitions
  • State outputs
  • Stop conditions

​
Does Not Contain

  • New criteria
  • New authority hierarchy
  • Artifact grammar
  • Live case state
  • Live handoff content
  • Scope redefinition

​
State Definitions

StateMeaning
READYAll required gate conditions for the current opening decision are satisfied
NOT_READYRequired material is still missing or weak, but the frame and procedure remain coherent
BLOCKEDA structural condition is missing, invalid, or unavailable — the flow cannot continue safely
CONFLICTTwo or more surfaces produce incompatible claims that cannot be closed at the current authority level

​
Output Minimums Per State

READY
  • readiness_basis
  • authorized_next_move
  • artifacts_to_read
  • artifacts_to_emit
NOT_READY
  • missing_items
  • weak_items
  • blocking_or_non_blocking
  • minimum_next_move
BLOCKED
  • blocking_cause
  • governing_owner
  • minimum_unblock_move
CONFLICT
  • conflicting_sources
  • resolution_rule_applied
  • suspended_point
  • minimum_unblock_move
  • peer_authority_status

​
Stop Conditions

The protocol stops immediately if any of these conditions is true:
1. The real object is not closed
2. Authority is not closed
3. Target closure changes the move materially
4. A lower-surface rule attempts to redefine a higher-surface rule
5. A required artifact class is undefined
6. A forbidden stability-to-residence combination is attempted
7. Immutable fields are targeted by runtime override
8. Peer-authority conflict remains unresolved
Stop conditions are a control mechanism. In conversational systems, many errors come not from wrong answers but from unearned forward motion.

Build docs developers (and LLMs) love

Get started for freeTalk to us