# OFC - OPERATIONAL FLOWS CANON
version: v1.1
status: ACTIVE
parent: master_architecture_index.md
phase: 09
phase_name: Operational Flows Canon
document_role: operational_flow_authority

## 1. OBJECTIVE
Define how Devon executes real operational flows end-to-end.

This file owns:
- required flow shape
- mandatory evidence path
- required checkpoints for real operations

This file does not redefine:
- deterministic control semantics
- latency budgets
- security boundaries

Those belong to:
- cfc.md
- lpc.md
- sec.md

## 2. CORE PRINCIPLE
Every operation must follow a structured, deterministic and auditable flow.

## 3. REQUIRED FLOW STRUCTURE
Every flow must include:
- objective
- trigger
- inputs
- modules involved
- state progression
- validation points
- execution points
- outputs
- evidence
- failure path
- audit path

## 4. CANONICAL FLOW ORDER
1. trigger
2. input capture
3. context scope resolve
4. retrieval if needed
5. interpretation
6. decision and policy check
7. validation
8. execution
9. evidence emit
10. audit close

## 5. FLOW GOVERNANCE
A valid operational flow must:
- use legitimate states
- pass deterministic control points
- respect security boundaries
- emit observable evidence

## 5.1 AUDIT EXECUTION BOUNDARY
Operational flow audit belongs to the operational side.

Operator Panel responsibilities:
- validate runtime execution sequence
- validate emitted evidence for real operations
- validate operational checkpoints and runtime materialization
- expose PASS / FAIL / MISSING only from materially observable execution evidence

Documentation Hub responsibilities:
- summarize the canonical flow definition
- summarize required checkpoints, evidence and audit closure rules
- expose documentary coverage of the operational flow canon
- never claim that runtime execution is complete without operational evidence

## 6. PRECEDENCE
On flow conflicts:
- CFC governs cognitive flow behavior
- LPC governs latency budget
- SEC governs security boundaries
- STS governs state legitimacy