# CFC - COGNITIVE FLOW CANON
version: v1.4
status: ACTIVE
parent: master_architecture_index.md
phase: 03
phase_name: Cognitive Flow Canon
document_role: deterministic_orchestration_authority

## 1. OBJECTIVE
Define the canonical cognitive flow of Devon.

This file owns:
- deterministic orchestration
- LLM role in flow
- retrieval role in flow
- validation order
- execution gating

## 2. CORE PRINCIPLE
The system is composed of deterministic and probabilistic layers.

Deterministic control governs the flow.
Probabilistic interpretation supports the flow.

## 3. FLOW LAYERS

### 3.1 Interpreter Layer
- interpret input
- extract structured meaning
- produce bounded candidate output

### 3.2 Decision Layer
- FSM
- policy gate
- state progression

### 3.3 Validation Layer
- enforce rules
- validate outputs
- block invalid actions

### 3.4 Execution Layer
- executor
- command dispatch
- audit-linked action

### 3.5 Memory Layer
- working context
- canonical memory linkage
- evidence continuity

### 3.6 Retrieval Layer
- retrieval
- embeddings
- context recall support

## 4. DETERMINISTIC ORCHESTRATION RULE
The flow must be governed by deterministic control points.

Minimum deterministic control points:
1. state legitimacy
2. policy eligibility
3. validation pass
4. execution permission

No protected execution is allowed without these control points.

## 5. FSM RULE
FSM is the deterministic governor of:
- allowed transitions
- progression order
- invalid state blocking

FSM may not:
- create sovereign policy
- bypass validator
- rewrite canonical architecture authority

## 6. LLM RULE
The LLM is an interpreter.
The LLM is not the governor.

The LLM may:
- interpret intent
- extract structure
- generate bounded proposals

The LLM may not:
- decide final policy
- authorize protected execution
- create hidden state

## 7. RETRIEVAL STRATEGY RULE
Default retrieval mode:
- scoped retrieval
- bounded context recall
- simple or hybrid RAG when required

Rule:
GraphRAG is not part of this project.

Retrieval may:
- enrich context
- support reasoning inputs
- recover relevant evidence

Retrieval may not:
- decide flow
- override FSM
- override policy
- authorize execution

## 8. MEMORY SCOPE ENFORCEMENT
Memory-aware flow must enforce namespace compatibility before retrieval or mutation.

Scope validation is flexible.
It must validate the applicable namespace set for the target memory class.

Possible namespace dimensions include:
- org scope
- tenant scope
- client scope
- project scope
- workspace scope
- agent scope
- user scope
- session scope

Rule:
if protected memory requires scope and compatible scope is not present, retrieval and mutation must be denied.

Global YEFF memory may be accessed only through explicit policy-approved memory class.

## 9. HOT PATH RULE
Production hot path should remain bounded.

Hot path target shape:
1. trigger
2. scope/context resolve
3. namespace compatibility resolve
4. minimal retrieval if needed
5. single main interpretation step
6. deterministic decision
7. validation
8. execution
9. audit emit

Rule:
hot path should avoid unnecessary multi-step cognitive chains.

## 10. CONFLICT RULE
If another file conflicts with this file on flow behavior:
- this file wins on cognitive flow
- STS wins on state legitimacy
- SEC wins on security boundary
- LPC wins on latency budget