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.

SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT is the material-transfer artifact. It solves a practical middle problem that comes up in nearly every real project opening: there is material worth passing along that is not yet trustworthy enough to count as official basis. Without a dedicated surface for that material, it either gets left behind (and lost) or absorbed into the SSOT prematurely (and corrupts the official basis). The transfer artifact holds candidate material in a clearly subordinate, explicitly non-normative position — available for the target project to inspect and use for analysis, but not authorized as basis until explicit validation occurs.
Source proximity is not authority. Being present in the package is not the same as being approved as official basis. Material in SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT is candidate material only. It must pass validation under 01_RULES.md before it can be named in INITIAL_SSOT_ARTIFACT.

​
Artifact Properties

PropertyValue
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
Promotion ConditionsPromotable only after validation under 01_RULES.md

​
Schema Fields

​
candidate_materials
list
required
The explicit list of materials being transferred. Each entry should identify the material clearly enough that the target project can locate, read, and evaluate it. Do not describe materials vaguely — each candidate material should be named specifically. The target project uses this list to know what candidate material exists, not to determine which materials are approved.
​
source_type
string
required
The type or category of the sources being transferred. Examples: primary document, secondary reference, internal draft, external dataset, operator-supplied notes, prior session output. This field helps the target project calibrate how to read the material before validation closes the authority question.
​
validation_state
string
required
The current validation state of the candidate materials. Record the honest state — not what you hope the validation will find. Common values: unvalidated, partially_validated, validation_in_progress, validated_pending_promotion. If the validation state is unknown, say so. Do not leave this field blank or set it to TBD without explanation.
​
attach_or_review_flag
string
required
Whether each material is intended to be attached (included in the package for direct reading) or only reviewed (examined without becoming part of the package context). This flag controls how the target project treats the material in its startup process. attach means the material is present and should be read. review means the material is referenced and should be evaluated but is not directly attached.

​
Candidate Material vs. Official Basis

The distinction between candidate material and official basis is the foundational protection that the transfer artifact provides. Official basis (lives in INITIAL_SSOT_ARTIFACT):
  • Explicitly validated under 01_RULES.md
  • Authority, relevance, role, and freshness are all closed
  • The target project may cite it without qualification
  • Provides the starting ground for decisions
Candidate material (lives in SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT):
  • Potentially useful but not yet validated
  • Authority, relevance, or role may not be fully closed
  • The target project may read and analyse it, but must not treat it as authoritative
  • Cannot be cited as basis until promoted
Without this split, one of two things happens. Either potentially useful material is withheld from the target project because it cannot be officially approved yet — which is too conservative. Or candidate material enters the SSOT alongside validated material — which corrupts the official basis. The transfer artifact makes a third path available: pass the material along under a clearly subordinate label, let the target project inspect it, and require explicit validation before any promotion occurs.

​
What the Transfer Artifact Must NOT Do

  • Must not count as official basis by default — presence in the package does not confer approval; only explicit naming in INITIAL_SSOT_ARTIFACT after validation does
  • Must not override approved basis — if the transfer material conflicts with the SSOT, the SSOT wins; the transfer artifact does not authorize that conflict point
  • Must not force promotion by presence — the fact that material exists in this artifact does not create pressure or obligation to validate it; the operator decides when and whether validation occurs
  • Must not become a fake SSOT — if a transfer artifact starts accumulating more content than the actual SSOT, that is a signal that promotion discipline has collapsed

​
The Validation Pipeline

Material travels from candidate to official basis through a defined pipeline:
1

Transfer

Material is named in SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT with its source type, validation state, and attach/review flag. It is now available to the target project as candidate material.
2

Validation under 01_RULES.md

The material is evaluated against the validation criteria: authority, direct relevance, explicit role, freshness (when time-sensitive), and contradiction status. All closures must be reached.
3

Promotion decision

If validation passes, the operator decides whether the material should be added to INITIAL_SSOT_ARTIFACT as official basis. This is an explicit decision — it does not happen automatically from a passing validation.
4

SSOT update

The validated, promoted material is named in INITIAL_SSOT_ARTIFACT. From that point, it counts as official basis. The SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT entry may remain as a record, with validation_state updated to reflect the promotion.

​
Template

Use this template to instantiate SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT. Each materially new transfer set should produce an updated version of this artifact. Do not accumulate multiple transfer sets in a single artifact without updating the validation states. 
# SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT

## candidate_materials
- TBD

## source_type
TBD

## validation_state
TBD

## attach_or_review_flag
TBD
The freshness rule for SOURCE_OR_MATERIAL_TRANSFER_ARTIFACT is tied to transfer sets rather than to time or runs. This is intentional: the artifact’s job is to represent the current state of candidate materials accurately. If a materially new set of materials is introduced, the artifact must be updated to reflect that set — including its source type, validation state, and attach/review flag. A stale transfer artifact that no longer reflects the actual candidate material in play is worse than no transfer artifact, because it creates false clarity about what is and is not being transferred.

Build docs developers (and LLMs) love

Get started for freeTalk to us