This is the expression language for all AITF agent documents. One protocol covers all scenarios: reading and writing use the same rules. An agent loads this protocol, can read any agent format document, and can write any agent format document.

1. File Rules

1.1 One file = one complete context

All structured content lives in .md files. Any agent reading a file can understand the full state without external information. No chatroom, no message queue, no out-of-file discussion.

1.2 Record format

Each record is one line. Fields are separated by pipe |. Hierarchy is expressed by explicit parent reference ^parent_id.

format: id|type|status|content|^parent_id|depends|impacts|author
example: A1.2|A|U|user retention driven by onboarding quality|^C1|D1.1|S2,K3|@McMillan

1.3 File header (mandatory)

Every agent format document must begin with:

## META
protocol_version: v4.0
type: {document purpose: proposal|knowledge|task|suggestion|hybrid|other}
scope: {what this document covers}
status: draft|in_progress|review|closed
author: @{AgentName}
participants: [{agent list if multiple}]
created_date: {YYYY-MM-DD}
source: {optional: origin material if derived from external}
source_author: {optional: original author}

2. Node Type Registry

All node types available for any document. An agent selects which types to use based on what it needs to express.

2.1 Analysis Nodes

Used to express reasoning, arguments, and solutions.

Code	Name	Description
P	Problem	Problem statement or question
E	Evidence	Factual basis (data, observation, citation)
A	Assumption	Something taken as true without direct proof
C	Claim	Conclusion derived from evidence and assumptions
S	Solution	Proposed action or answer
M	Mechanism	How a solution works
K	Risk	What could go wrong
R	Rule	Constraint or principle governing behavior
D	Dependency	Prerequisite that must be resolved
G	Gap	Identified missing information or unresolved question

2.2 Knowledge Nodes

Used to express structured knowledge extracted from sources.

Code	Name	Description
CON	Concept	Independent knowledge unit
DEF	Definition	Precise description of a concept
REL	Relation	Relationship between concepts
PRO	Property	Attribute or characteristic of a concept
EXA	Example	Illustrative case
CTR	Counter-example	Boundary condition or exception
APP	Application	Scenario where this knowledge is useful
SRC	Source	Origin reference (book, chapter, page, author, URL)
TAG	Retrieval Tag	Keywords optimized for vector search
GAP	Knowledge Gap	Identified missing knowledge

2.3 Task Nodes

Used to express work assignments and execution records.

Code	Name	Description
OBJ	Objective	Task goal
CTX	Context	Why this task is needed
IN	Input	Input files, data, or prior results
OUT	Output	Expected deliverable (format + content)
CST	Constraint	Boundaries or restrictions (what not to do)
ACC	Acceptance	Measurable completion criteria
DEP	Dependency	Prerequisite (alias of D in task context)
Q	Question	Request for clarification
LOG	Execution Log	Record of what was done and result

2.4 Collaboration Nodes

Used to express suggestions, responses, and inter-agent dialogue.

Code	Name	Description
SUG	Suggestion	Proposed change or improvement
RSP	Response	Reply to a suggestion or question
JUS	Justification	Reasoning for a decision (accept, reject, defer)
MOD	Modification	Adapted version of a suggestion

2.5 Cross-type Usage

Node types are NOT locked to scenarios. A task document can include K (risk) and A (assumption) nodes. A knowledge document can include G (gap) and Q (question) nodes. An agent uses whatever node types best express the content.

3. Status Codes

3.1 Universal Status Codes

Apply to ALL node types across all documents.

Code	Name	Meaning
V	Verified	Independently confirmed (by another agent, by source, by data)
U	Untested	Proposed but not yet examined or confirmed
X	Contested	Conflicting evidence or interpretation exists
N	No Evidence	Placeholder or speculative (no supporting basis)
F	Flag Human	Requires human judgment to resolve
D	Done	Completed (primarily for task nodes)
B	Blocked	Waiting on dependency or external input
W	Withdrawn	Retracted by author

3.2 Status Assignment Rules

4. Structure Rules

4.1 Hierarchy

Nodes form trees via parent reference. Depth is unlimited — the agent uses whatever depth the content requires.

P1[U]: problem statement
  E1.1[N]: evidence
  A1.1[U]: assumption
  C1.1[U]: claim
    S1.1.1[U]: solution
      M1.1.1.1[U]: mechanism
      K1.1.1.1[U]: risk

4.2 References

Nodes can reference other nodes for traceability. All references must point to existing nodes — no orphan references.

based_on: [{node_IDs}]     what this node is derived from
depends:  [{node_IDs}]     what must be true/done for this to hold
impacts:  [{node_IDs}]     downstream nodes affected if this changes
blocking: [{node_IDs}]     what cannot proceed until this is resolved

4.3 Tag Rules

Each TAG must include synonyms and aliases, likely query phrasings, and domain-specific terms. Good tags cover 3+ search angles.

good: [marginal cost, MC, incremental cost, variable cost per unit, how much does one more cost]
bad:  [marginal cost]

5. Quality Standards

5.1 Self-check (before finalizing any document)

5.2 Anti-patterns (author must avoid)

Anti-pattern	Symptom	Fix
Confidence inflation	High confidence without strong evidence	When in doubt, use U not V
Assumption hiding	Assumptions embedded inside C or S nodes	Every if/when/given should be its own A node
Risk blindness	Solutions with no K nodes or only trivial risks	For each S, ask: what could go wrong?
Gap avoidance	No G nodes in a complex document	Every non-trivial document has unknowns
Circular reasoning	C based on A where A is derived from C	Trace every chain to E or explicit A[N]
Premature solutioning	S nodes without adequate P scoping or E gathering	Problem first, evidence first, then solution

6. Escalation

6.1 When to mark F (flag for human)

Mark F when agents contradict with valid evidence and no resolution path; when empirical test or runtime validation is required; for commercial judgment (cost, priority, resource allocation); for irreversible actions; for ambiguous source material; for scope or priority judgment; or when touching agent identity or SOUL.md.

7. Multi-agent Collaboration

Each agent reads the full existing document first. Each agent writes new nodes signed with own @AgentName. No agent modifies another agent's content. To disagree, write your own node with counter-argument or alternative. If disagreement is unresolvable, mark F.

7.1 Cross-document References

format: {document_filename}:{node_ID}
example: project_alpha_proposal.md:S2.1

8. Protocol Governance

Agents propose changes via a protocol opinion document. Human reviews and approves. Agents NEVER modify the live protocol file directly.

Old files must remain readable under new protocol versions. Additive changes (new node type, new status code) require no migration. Breaking changes require human approval (F), impact assessment, migration script, and cost justification.

AITF Protocol v4.0 — the expression language for all agent documents.