Project evidence
Understand how TCAF uses ordinary project material and repository evidence as durable context across tools and sessions.
TCAF does not depend on one chat session to remember how a project works. It re-reads repository and project evidence.
Framework instructions live in the installed TCAF runtime. Project truth comes from the target project and its evidence.
Ordinary material is valid source evidence
A project may already contain README files, specifications, architecture notes, ADRs, plans, roadmaps, backlog items, issues, runbooks and working code.
TCAF does not require you to convert this material into a special format before using it. Existing authoritative material remains source evidence.
This is true for both bootstrap and adopt.
Canonical state is derived only when useful
Some workflows benefit from a compact project state that maps important facts such as:
- project boundaries and application roots;
- current architecture and capabilities;
- project-specific rules;
- authoritative task sources;
- relevant build, test or validation commands;
- known limitations and open questions.
TCAF can derive that state from the available evidence. It should not duplicate an existing authoritative document just to make it look like a TCAF document.
Evidence must describe reality
A detailed document is not automatically correct. Check that paths and commands really exist, current and planned capabilities are separate, unknowns remain visible, and architecture describes the repository rather than an invented ideal version.
Structural validation can check schema and consistency. It cannot prove every statement is semantically true.
Preserve source material and history
Historical documents, developer edits and existing source evidence should not be rewritten merely to normalize formatting or fit a template.
When project reality changes outside the current run, use tcaf sync to re-read the repository and propose the smallest needed reconciliation. A new specification is evidence to inspect, not automatically approved project truth.
Keep current and desired state separate
Plans and specifications often describe what the team wants while code describes what exists now. TCAF keeps those categories explicit so planned work is not mistaken for implemented behavior.
Useful distinctions include current state, desired state, confirmed decision, proposal, open question and historical context.
Why this supports model independence
Durable project evidence can be inspected again by another model or tool. That reduces dependence on private chat memory, one vendor’s rules format or a previous agent’s summary.
The goal is not more documentation. The goal is reliable continuity from evidence that belongs to the project.