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 sessions fail in recognizable patterns. Most failures do not announce themselves as failures. The session continues producing output, the artifacts look plausible, and the protocol appears to be running. The problem is that the output is being built on a compromised foundation — a canonical that has absorbed live case state, an artifact that is doing the job of three different surfaces, or a handoff that was emitted by habit rather than by criteria. The failure modes below cover both the six technical failure patterns identified in the Operator Technical Reference and the four operational failure patterns from the Operator Guide.
When in doubt, prefer the smaller move. Prefer NOT_READY over fake readiness.

​
Technical Failure Modes

What it is: Case state begins to leak into the canonical files. Live project details, case-specific constraints, or operational state ends up inside 00_SCOPE.md, 01_RULES.md, 03_ARTIFACTS.md, or 02_PROTOCOL.md.Why it happens: The operator or AI treats the canonicals as a convenient place to store information that matters right now, rather than separating protocol-core from operational state.Effect: The protocol core becomes mixed with live project state. The canonicals stop being stable, reusable authority and start carrying case-specific content that belongs in an artifact. Future sessions that read the canonicals pick up case state as if it were system rules.Signs to watch for:
  • A canonical file contains a named project, specific metric, or case-specific constraint
  • The same canonical file reads differently from session to session because case details have been added
  • The AI treats a case-specific rule as if it were a system-wide rule because it found it in a canonical
Corrective move: Externalize the state into the correct artifact. Case-specific material belongs in EXTERNAL_ARTIFACT residence — typically the target brief or initial SSOT. The canonical should contain protocol, not project content. Strip the case state out of the canonical and put it where it belongs.
What it is: The four baseline artifact classes — TARGET_PROJECT_BRIEF_ARTIFACT, INITIAL_SSOT_ARTIFACT, HANDOFF_ARTIFACT, and SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT — are treated as interchangeable. Project brief content ends up in the SSOT, handoff content ends up in the brief, transfer material ends up in the SSOT.Why it happens: It feels faster to put everything in one place. The distinct roles of each artifact are not obvious in the moment when the operator is trying to produce output quickly.Effect: Authority becomes muddy. The target project cannot tell which content is the opening brief, which is the official basis, which is continuity state, and which is candidate material that has not been validated yet. Reopening the case later becomes harder because there is no clean reading order.Signs to watch for:
  • One artifact contains both “what the project must do” and “what the current operational state is”
  • The operator cannot point to a single artifact and say exactly what its role is
  • The AI has to read multiple artifacts to determine what counts as official basis
Corrective move: Keep artifact roles separate. Each artifact class has a specific job. The brief says what the target project is and what it must do. The initial SSOT says what counts as official basis at opening. The handoff carries continuity state when the criteria require it. The transfer artifact carries candidate material that has not been promoted. These are different answers to different questions — they belong in different surfaces.
What it is: Material enters stable basis — the initial SSOT, a canonical, or the target brief — before it has been validated or before it has been shown to be non-case-specific.Why it happens: Useful material is nearby and convenient. The operator or AI promotes it because it is helpful for the current run, without checking whether it has met the promotion criteria: stabilized, normative, and non-case-specific.Effect: Local convenience hardens into fake structure. Notes become rules. One useful case pattern becomes a general policy. The opening package contains material that only belongs in one specific case but is now being treated as stable basis for future runs.Signs to watch for:
  • The SSOT contains material that was generated during the current run without going through source validation
  • A canonical or SSOT field contains content that only makes sense for one specific case
  • The AI treats a draft or candidate observation as if it were validated official basis
Corrective move: Keep candidate material in the transfer artifact until it earns promotion. The SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT exists precisely for this — it holds material that is worth passing to the target project without yet counting as official basis. Apply the promotion tests before promoting: is it stabilized? Is it normative? Is it non-case-specific? If any test fails, the material stays in transfer.
What it is: HANDOFF_ARTIFACT is emitted at the end of every session because it “feels safe” or “provides continuity,” rather than because the handoff criteria say HANDOFF_REQUIRED.Why it happens: Emitting a handoff feels like good practice. It provides a record, it carries state forward, it feels thorough. The cost of unnecessary handoff is not immediately visible.Effect: Operational residue accumulates across sessions. Each run carries the stale operational state of the previous one. The target project opens with continuity content that may no longer be accurate. Duplicate state exists in multiple surfaces. What should be a clean opening becomes a layered reconstruction problem.Signs to watch for:
  • Handoff is always the last artifact emitted, regardless of the state or run type
  • The handoff contains content that is already captured in stable artifacts
  • The target project is reading the handoff to get information that should be in the brief or SSOT
Corrective move: Use handoff only when the criteria say HANDOFF_REQUIRED — when the next run would depend on state, tests, decisions, or materials that cannot be reconstructed reliably from canonicals and already-stable artifacts alone. If the canonicals and existing artifacts are sufficient to reopen the work, the correct designation is HANDOFF_NOT_REQUIRED. Do not emit handoff as a default safety measure.
What it is: Temporary constraints — run-local rules, session-specific priorities, or in-context operator instructions — are used to justify changes to stable system rules that are not marked overrideable in 01_RULES.md.Why it happens: Something about the current case feels unusual. The standard rules feel like they do not fit. The operator or AI finds a workaround via runtime override rather than accepting that the honest state is NOT_READY or BLOCKED.Effect: The system quietly stops being itself. Core fields that are supposed to be immutable — the authority hierarchy, the stability model, the residence model, the promotion model, the readiness model — get silently rewritten through accumulated runtime pressure. The protocol appears to be running, but it is running against a different contract than the one the canonicals define.Signs to watch for:
  • A runtime instruction changes how authority is determined, not just what is being worked on
  • An override modifies the classification or promotion criteria for a specific case, not just local priorities
  • The AI accepts a runtime override that rewrites a rule in 01_RULES.md without flagging the conflict
Corrective move: Override only the fields already marked overrideable in 01_RULES.md. The overrideable scope covers current-turn objective, temporary priorities, temporary exclusions, current materials under evaluation, run-local constraints, and artifact choices already allowed by the canonicals. It does not cover the system’s identity, frame, authority hierarchy, stability model, residence model, promotion model, artifact grammar, or readiness model. If a runtime instruction touches immutable fields, the correct outcome is CONFLICT, not silent compliance.
What it is: The model behaves as if it has stable, continuous memory of the case when it is actually interpolating from a mix of provided files, ambient session context, prior chat history, and plausible inference. The output sounds like it is grounded in a coherent shared understanding, but the basis is mixed and unverified.Why it happens: GPT systems are very good at maintaining consistent tone and filling in plausible details. This fluency creates the impression of reliable continuity even when continuity is not actually present. The model does not signal when it is inferring versus citing.Effect: False confidence in the current context. Incorrect basis for artifact content. Subtle drift from the explicit canonicals toward implicit chat-derived assumptions. The system appears to be working while the actual basis has shifted away from the intended starting ground.Signs to watch for:
  • The AI refers to details from prior sessions that were not provided in the current one
  • The AI “knows” the case at a level of specificity that was not in the provided files
  • Artifacts contain content that cannot be traced back to an explicitly provided source
  • See also: all six drift signals in the Session Hygiene guide
Corrective move: Start from AI_START.md and explicit files every time. Never assume the model “already knows the case.” Provide only what you intend to count as basis. If the current session shows signs of continuity illusion, apply the drift reset procedure: stop the current move, restate the object, restate the active authoritative files, restate what does not exist, and reopen cleanly if trust in the session is gone.

​
Operational Failure Modes

What it is: The operator already understands the case well from prior discussion or internal context, and begins producing artifacts before completing object closure, target closure, and output closure.Why it happens: The case feels obvious. The operator knows what the output should look like. Closing the object, target, and output set feels redundant when the answer seems clear.Effect: Artifacts end up vague, underspecified, or missing structural fields. The target project receives an opening package that requires reconstruction rather than enabling clean startup. The closing steps that were skipped were not redundant — they were producing the explicit ground the artifacts need.Signs to watch for:
  • An artifact was produced before the target’s objective, scope in, and scope out were explicitly stated
  • The brief or SSOT contains fields left as placeholders or implicit
  • The AI skipped the object-closure check and moved straight to output generation
Corrective move: Go back to object and target closure. State the object explicitly. Close objective, scope in, and scope out before generating any artifacts. The 8-step startup in the Operator Guide defines the correct sequence — the first three steps exist precisely to prevent this pattern.
What it is: The operator acts as if something is safe because it was discussed — a source evaluation, a scope decision, a classification call — without externalizing it into an artifact or file.Why it happens: Chat discussion feels like it establishes shared understanding. The information was covered. Both the operator and the AI appear to know it. Externalizing it feels like extra work for something already settled.Effect: Hidden dependency on conversational memory. Fake continuity. The next session — or even later in the same session — does not have access to the “settled” information because it was never written down. The model reconstructs it from context or fills the gap with plausible inference.Signs to watch for:
  • A decision made in conversation is not reflected in any artifact
  • The AI refers to a prior discussion as if it were stable basis when no artifact was produced
  • A source evaluation was done verbally but the source was never formally validated
Corrective move: Externalize the state into the correct artifact. If a classification decision matters, it belongs in the artifact that records the classification. If a source was validated, that validation belongs in the SSOT or the transfer artifact. If an operator decision matters for the target project, it belongs in the brief. Chat is temporary. Artifacts are the record.
What it is: A required field or piece of information is missing, and the model fills the gap with a plausible answer rather than marking it explicitly as missing and stopping.Why it happens: GPT systems generate plausible completions by design. When a field is absent, the model has a natural tendency to supply something reasonable-sounding. The operator may not notice because the output looks complete.Effect: Hidden assumptions enter the artifact. The opening package contains invented content presented as if it were explicit basis. The target project starts from a false readiness signal — the package appears complete but contains fabricated fields.Signs to watch for:
  • An artifact field contains specific content that was never provided or validated in the session
  • A scope boundary or constraint that the operator never stated appears in the brief
  • The AI resolves an open question without flagging it as a gap
Corrective move: Mark missing as missing. Stop if the gap changes the move. The correct state when required information is absent is NOT_READY — not “here is my best guess at what was probably meant.” If the AI fills a gap without flagging it, use the session hygiene reset procedure: restate what does not exist, restate the authoritative files, and verify that every field in the artifact can be traced to an explicitly provided source.
What it is: Brief, SSOT, handoff, and transfer material end up in a single artifact, or the wrong content ends up in the wrong surface. This is the operational-level version of the technical failure mode described as Artifact Role Collapse above.Why it happens: When there is pressure to produce output quickly, combining surfaces feels efficient. The distinctions between what the brief does versus what the SSOT does versus what the handoff does are not always obvious in the flow of a session.Effect: Muddy authority. The target project cannot determine a clean reading order. It cannot tell what it is (brief), what it may treat as official basis (SSOT), what continuity state it needs to carry (handoff), or what candidate material is still under evaluation (transfer). Verification becomes harder. Errors become harder to trace.Corrective move: Keep artifact roles separate. Each artifact answers a specific question: the brief answers what the target project is and what it must do; the SSOT answers what counts as official basis at opening; the handoff answers what operational state must carry forward; the transfer artifact answers what candidate material exists but has not yet been promoted. When output is going into the wrong surface, stop and assign it to the correct one.

Build docs developers (and LLMs) love

Get started for freeTalk to us