# Epic 4: Validation Pipeline (Deterministic Analysis + Cross-Layer Consistency Engine)

**status:** completed
**date:** 09.05.2026 (May)
**scope:** `:core:validation` (depends on `:core:events`, `:core:sessions`, `:core:transitions`, Epic 3 analysis outputs)

---

## context

With deterministic event sourcing (Epic 1), session projection (Epic 2), and workflow transition semantics (Epic 3) in place, Correx now has a complete execution and reconstruction model.

However, there is no formal layer that ensures:

* graph integrity
* transition consistency
* session projection correctness
* configuration validity (cycle policies, semantic rules)
* cross-layer coherence under replay

Without a validation layer:

* invalid workflow graphs can still be constructed
* inconsistent transitions can pass unnoticed
* session projections can diverge semantically from graph structure
* cycle governance (policy binding) is not enforceably checked
* system correctness is only implicitly trusted, not verified

Epic 4 introduces a deterministic validation system to close this gap.

---

## goal

Introduce a **deterministic, replay-safe validation pipeline**:

> a pure analysis engine that validates workflow structure, execution projections, and configuration consistency without influencing execution behavior

The system must remain:

* deterministic
* stateless
* replay-safe
* non-executing
* side-effect free

It is NOT an orchestration engine and does NOT participate in runtime control flow.

---

## scope (what IS included)

---

### 1. validation model layer

Define unified validation representation:

* `ValidationReport`
* `ValidationSection`
* `ValidationIssue`
* `ValidationSeverity`
* `ValidationContext`

Validation context is a full system snapshot:

* `WorkflowGraph`
* `DetectedCycle` (Epic 3 output)
* `CyclePolicyBinding`
* `SessionState`

Properties:

* immutable
* replay-safe
* fully deterministic input contract

---

### 2. graph validation

Validate structural correctness of workflow topology.

Checks:

* start node existence
* dangling transitions (invalid stage references)
* structural consistency of graph definition
* cycle presence reporting (pass-through only)

Important:

* cycles are allowed by design (Epic 3)
* cycle detection is informational only
* no enforcement or interpretation of cycles occurs here

---

### 3. transition validation

Validate deterministic consistency of transition engine inputs.

Checks:

* transition endpoints exist in graph
* condition presence and structural validity
* deterministic ordering correctness per source node
* ambiguity detection in transition resolution ordering

Important:

* transition conditions are NOT executed
* no resolution logic is invoked
* no runtime decisioning occurs

---

### 4. session validation

Validate projection consistency against event-derived state.

Checks:

* temporal consistency (`createdAt ≤ updatedAt`)
* session state sanity (invalid transition counts)
* consistency between session state and graph structure
* lightweight anomaly detection over projection output

Important:

* no event replay is performed
* no projection recomputation occurs
* session state is treated as immutable derived artifact

---

### 5. semantic validation layer

Validate configuration and cross-domain consistency rules.

Includes:

* cycle-policy binding completeness (mode-dependent enforcement)
* configuration consistency checks
* cross-layer structural coherence rules

Cycle semantics:

* `CycleSignature` derived from normalized node sets
* edges are not part of identity
* policy binding is evaluated against cycle signatures only

Important:

* cycles remain structurally valid (Epic 3 rule preserved)
* semantic layer does NOT enforce execution behavior
* policies are treated as configuration constraints, not runtime logic

---

### 6. validation pipeline executor

Define deterministic orchestration of validation layers.

Pipeline behavior:

* strictly ordered execution
* no hidden parallelism
* fully deterministic evaluation order
* stateless execution model

Execution flow:

```text
Graph → Transition → Session → Semantic → ValidationReport
```

Important:

* pipeline aggregates results only
* no control flow decisions beyond aggregation
* no mutation of input context

---

### 7. approval trigger integration point

Introduce boundary layer between validation and external decision systems.

Responsibilities:

* evaluate `ValidationReport`
* compute risk summary
* decide whether approval request is required
* emit `ApprovalRequest` artifact

Important constraints:

* no execution coupling
* no workflow control logic
* no system orchestration responsibility
* strictly output transformation layer

Output artifacts:

* `ApprovalRequest`
* `RiskSummary`

Behavior:

* errors or missing cycle-policy bindings trigger approval requirement
* acts as deterministic gating boundary, not execution controller

---

### 8. deterministic testing requirements

Validation system must be fully testable under replay constraints.

Coverage includes:

* graph validation determinism
* transition validation consistency
* session projection sanity validation
* semantic rule enforcement consistency
* pipeline ordering determinism
* approval trigger stability
* full system replay equivalence

Invariant:

> identical input context must always produce identical ValidationReport and ApprovalRequest outcome

---

## explicit exclusions

Epic 4 does NOT include:

* workflow execution
* transition evaluation or resolution
* scheduling or orchestration
* runtime policy enforcement
* execution retry logic
* system control flow decisions
* async or distributed validation execution
* event mutation or emission

Those belong to future runtime/orchestration layers.

---

## consequences

### positive

* introduces explicit correctness boundary for entire system
* makes workflow + session consistency verifiable
* decouples analysis from execution
* enables safe pre-execution validation gating
* formalizes configuration governance (cycle policies)
* improves replay debugging and system observability

---

### negative

* adds another full abstraction layer over already complex system
* increases conceptual separation between “valid structure” and “valid execution”
* introduces potential duplication of logic if misused outside boundary
* requires strict discipline to avoid leaking execution semantics into validation
* makes system reasoning more layered (analysis vs execution vs policy)

---

## rationale

Epic 4 exists because deterministic execution alone is insufficient.

Even with:

* event sourcing (Epic 1)
* projection layer (Epic 2)
* workflow engine (Epic 3)

the system still lacks:

> a formal correctness boundary over structure, configuration, and derived state

This epic ensures:

* workflows are structurally valid before execution
* session state remains consistent with graph semantics
* configuration constraints (cycle policies) are explicitly governed
* system behavior remains fully replay-verifiable

It completes the shift from:

* “deterministic execution system”
  to
* “deterministic + verifiable workflow system”

---

## status

Epic 4 is considered complete once:

* validation model is defined ✔
* graph/transition/session/semantic validators exist ✔
* pipeline executor is deterministic ✔
* approval trigger boundary is implemented ✔
* replay tests confirm stability ✔

It is the final analysis layer before runtime orchestration and execution-control systems are introduced in future epics.
