Artifacts are the external, state-bearing surfaces of Project Forge. Every piece of case state, project-specific context, or operational continuity lives in an artifact — not in the canonical core. This separation is a deliberate design choice: the canonical core defines how the system works; artifacts carry what a specific project needs. The canonical core stays clean. The artifacts carry the weight. The core artifact principle is simple: artifacts may carry state; artifacts may not redefine canonicals. Every artifact has local, delegated, subordinate authority only. No artifact can redefine system frame, override canonical rules, create system-level authority, or alter protocol. Authority flows downward from the canonicals. Artifacts live at the bottom of that hierarchy, within their clearly bounded scope.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 Four Artifact Classes
Project Forge defines four baseline-supported artifact classes. All four are known to the system; none of the four is required in every opening. The system uses whichever classes the current opening genuinely needs.TARGET_PROJECT_BRIEF_ARTIFACT
The project-opening brief. Transmits the minimum project-specific operational context to the target project: objective, scope, required outputs, and constraints.
INITIAL_SSOT_ARTIFACT
The official-basis artifact. Freezes the initial official basis of the target project so it cannot be silently absorbed or overridden by proximity.
HANDOFF_ARTIFACT
The operational-continuity artifact. Transfers run state across sessions when continuity cannot be safely reconstructed from canonicals and stable artifacts alone.
SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT
The material-transfer artifact. Moves candidate materials to the target project without promoting them to official basis until explicit validation occurs.
Artifact Authority Rule
Every artifact operates under a strict authority rule sourced from03_ARTIFACTS.md:
Every artifact has local, delegated, subordinate authority only. No artifact may redefine system frame, redefine canonical rules, override protocol, or create system-level authority.This rule is not a formality. It is the structural reason the canonical core can remain stable across every target project opening. Project-specific objectives, approved sources, operational state, and candidate materials all live in artifacts — bounded, temporary, and subordinate.
Artifact Read Order
When a target project opens a package, the four artifact classes are always read in a specific order. This order governs how each surface is interpreted relative to the others.TARGET_PROJECT_BRIEF_ARTIFACT
Read first. Establishes what the target project is, what it must do, and what is in or out of scope.
INITIAL_SSOT_ARTIFACT
Read second. Establishes what the target project may treat as official basis at startup.
SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT
Read third, if present. Exposes candidate materials available for review — not yet official basis.
Artifact Summary Table
| Artifact Class | Purpose | Write Trigger |
|---|---|---|
TARGET_PROJECT_BRIEF_ARTIFACT | Transmit the minimum project-specific operational brief | When documentary readiness requires a target-project brief |
INITIAL_SSOT_ARTIFACT | Freeze the initial official basis of the target project | When an initial official basis exists and must be frozen |
HANDOFF_ARTIFACT | Transfer operational continuity across runs | Only when 02_PROTOCOL.md closes HANDOFF_REQUIRED |
SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT | Transfer candidate materials without promoting them | When materials must pass to the target project without immediate promotion |
The Minimum Practical Opening Pack
Not every opening needs all four artifact classes. The system is designed to start small and add surfaces only when the criteria justify them. In most clean openings, the minimum useful pack is:- ENTRY_POINT.md — the package startup surface (not one of the four artifact classes, but always present)
- TARGET_PROJECT_BRIEF_ARTIFACT — defines what the project is
- INITIAL_SSOT_ARTIFACT — defines what the project may treat as official basis
- HANDOFF_ARTIFACT — only when
HANDOFF_REQUIREDis closed by the protocol - SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT — only when candidate material must travel without promotion
Custom Artifact Rule
The system allows custom artifact classes beyond the four baseline types, but only under strict conditions. A custom artifact is valid only when all eight of the following fields are declared:| Required Field | What It Closes |
|---|---|
purpose | What the artifact is for |
authority | What scope the artifact can speak to |
surface | What type of surface it represents |
schema | What fields it must contain |
write_trigger | When it is emitted |
read_trigger | When it is consumed |
freshness_rule | When it must be updated |
artifact_specific_promotion_conditions | Under what conditions its content can be promoted |
Why the Artifact Split Matters
Keeping the four artifact classes separate is not bureaucracy. It is boundary protection. When brief, SSOT, handoff, and transfer material all collapse into one file, the operator and the target project both lose:- Role clarity — each artifact answers a different question; mixing them makes every question harder to resolve
- Reading order — the defined read order only functions when each surface is distinct
- Verification — auditing a clean brief is fast; auditing a blob of mixed content is unreliable
- Promotion discipline — candidate material can only be kept subordinate if it lives in a surface that is structurally subordinate