How FDRP Works

Manufacturing quality control for planning decisions. Statistical process control, 5S workplace organization, RAMS reliability analysis, Andon stop-the-line signals, and configuration freeze — all applied to the planning process itself.

Overview

FDRP treats every planning decision as a manufactured artifact. Just as a machined part passes through quality gates with measured tolerances, each decision in FDRP passes through a six-phase lifecycle with quantified convergence metrics. When a decision fails its gate criteria, the system triggers an Andon stop — halting forward progress until the root cause is resolved.

The architecture draws on six decades of manufacturing discipline: SPC control charts track decision stability over time, 5S organization classifies and structures the decision workspace, RAMS (Reliability, Availability, Maintainability, Safety) quantifies system dependability, and configuration freeze prevents uncontrolled changes after convergence. Cross-model verification with N≥3 independent LLMs provides the final quality assurance layer.

The result is a planning system with the same measurability guarantees that manufacturing achieved in the 1960s — applied to decisions rather than physical parts.

Convergence Velocity Tensor

The CVT is the core metric that drives FDRP phase transitions. It quantifies how rapidly a planning run is converging toward a stable configuration by measuring three independent signals: domain exploration saturation, expert agreement, and contradiction resolution.

CVT = (1 − new_domain_ratio) × avg_confidence × (1 − contradiction_rate)

Convergence Velocity Tensor

Variables

new_domain_ratio

Fraction of domains in the current wave that did not appear in any previous wave. Approaches 0 as exploration saturates.

avg_confidence

Mean confidence score across all expert findings in the current wave. Range [0, 1]. Higher values indicate stronger expert agreement.

contradiction_rate

Fraction of findings where two or more experts produced contradictory conclusions. Approaches 0 as conflicts are resolved.

Phase Thresholds

CVT < 0.3

Seed

High exploration. Many new domains, low consensus, active contradictions.

0.3 ≤ CVT < 0.6

Growing

Expansion plus refinement. Domain coverage stabilizing, contradictions decreasing.

0.6 ≤ CVT < 0.8

Mature

Refinement dominant. Few new domains, high confidence, minimal contradictions.

CVT ≥ 0.8

Converged

Ready for configuration freeze. Stable baseline, verified by cross-model consensus.

Six-Phase Gate Lifecycle

Every FDRP run progresses through six phases. Transitions are governed by the CVT metric and explicit gate criteria. Phases enforce monotonic convergence — decisions can only tighten, never regress. A regression triggers an Andon stop and root cause analysis.

Phase 1

Seed

Initial problem decomposition. The system analyzes the brief, identifies relevant domains, and nominates the first wave of expert specialists. High exploration, low convergence.

Phase 2

Growing

Wave dispatch and parallel expert analysis. Each wave expands coverage through blind spot detection — experts nominate domains the current team cannot cover. The spiral-out pattern ensures no critical perspective is missed.

Phase 3

Mature

Cross-model verification and contradiction resolution. N≥3 independent LLMs review HIGH and CRITICAL findings. Contradictions are surfaced and resolved through structured debate. CVT tracks convergence toward stability.

Phase 4

Converged

Configuration freeze candidate. CVT ≥ 0.8 and cross-model verification passes. The system generates a frozen baseline proposal for human review. All findings are traceable to their originating expert and wave.

Phase 5

Frozen

Locked baseline. The configuration is frozen after human approval. Any change requires formal review: the proposer must demonstrate that the change improves convergence without regressing other metrics. Change control is strict.

Phase 6

Released

Published artifact. The frozen baseline is released as a versioned deliverable. A retraction and correction protocol remains active indefinitely — errors discovered post-release trigger formal correction notices with full provenance.

Framework Comparison

FDRP occupies a different design point from existing multi-agent frameworks. Where most frameworks focus on task orchestration, FDRP focuses on decision quality measurement and convergence guarantees.

Feature	FDRP	AutoGPT	CrewAI	LangGraph	MAPE-K
Convergence Metrics	CVT + SPC charts	None	None	None	Partial (feedback loop)
Traceability	Finding-level provenance	None	Task-level logs	State snapshots	Knowledge base
Clash Detection	Cross-expert contradiction	None	None	None	None
Grounding Discipline	VL-0 to VL-4 levels	None	None	None	None
Self-Evolution	Lessons-learned daemon	Plugin system	None	None	Adaptation loop
Cross-Model Verification	N≥3 models, expert-framed	Single model	Single model	Single model	Not applicable
SPC Integration	Control charts, drift detection	None	None	None	Monitor phase
Expert Expansion	Spiral-out blind spot detection	Agent spawning	Crew assignment	Fixed graph	Fixed architecture

Native support

Partial support

Absent

Plan Evidence ContractR23

Any plan that proposes new persistent infrastructure — a CREATE TABLE, a new daemon, a new hook, a new SOP — must carry a structured markdown evidence block before it leaves plan-mode. The contract closes the gap between "well-argued plan" and "plan grounded in measured production data."

Four PreToolUse hooks validate the block at write time: preplan-schema-evidence, preplan-daemon-evidence, preplan-wave-protocol-evidence, preplan-monitoring-evidence. Hooks deny the write when the required evidence keys are missing or unparseable. The /plan-validate slash command runs the same checks on-demand, and a Rust evidence indexer keeps the plan_registry table in sync with proposals on disk.

plan_registry

One row per active plan with extracted evidence keys, target substrate, risk tier, and authoring agent. Source of truth for plan-mode review.

relevance_scores

Per-plan scoring against current backlog and historical waves. Drives WSJF reordering and surfaces near-duplicate proposals.

intersection_proposals

Detected overlaps between plans that share substrates, hooks, or schema deltas. Forces consolidation before parallel execution.

Phase-1 substrate live since 2026-05-10. Risk tier: BIND-043 LOW for plan-validate dispatch; MEDIUM for new hook installation.

Context Injection RoutingR22

Selecting the right specialist is necessary but not sufficient. The adjacent failure mode — right specialist, wrong context bundle — produces fluent answers that do not match the project's actual state. R22 adds a deterministic mapping (task_type, project_track, specialist_type) → ordered context bundle on top of the dispatch table.

agent_dispatch_table

Selects which specialist handles the task. Inputs are keyword triggers, risk tier, and current load.

context_injection_policy

Decides what context the specialist receives: which memory files are pinned, which schema views attach, which prior-wave artifacts pre-load. Ordered, deterministic, audited.

The two tables are jointly versioned. A change to dispatch without a corresponding context update fails the council gate, because the new specialist would arrive context-starved. This is the routing equivalent of an interface-implementation mismatch.

Core Router Memory + Multi-CC OrchestrationR21

When the router holds many simultaneous tracks, attention drifts to whichever track produced the most recent signal. R21 makes the memory surface explicit and budgets it.

PINNED

Always loaded. Identity, BIND rules, active prime directives, live project pointers.

ADAPTIVE

Loaded when a relevance signal fires — matching task type, recent activity, or explicit slash command.

ARCHIVED

Indexed but not pre-loaded. Reachable by query when needed. Keeps the working set bounded.

A tasklist autonomy daemon auto-completes tasks when verifiable receipts are present, removing the human in the loop for routine checkbox sweeps. The multi-CC TMUX router pattern spawns one Claude Code instance per active project track, so a stalled track does not starve a fast-moving one. The pattern was adopted after the 2026-05-03 correction where the irrigation track stalled while PS-S6E4 dominated the single-session attention budget.

Encoded-Physics KernelsR20

The engineering backbone is deterministic. LLM calls drive the conceptual surface, but the load-bearing computation lives in encoded-physics kernels — Rust crates that take a typed spec and emit a reproducible artifact through standard solvers. 72 Cargo.toml manifests across 7 parent projects today.

interceptor-gen

Noyron-pattern parametric drone-design generator. Spec → forward-parametric → SDF substrate → solver gates.

airguard-dsp

EKF tracking, TDoA localisation, CFAR detection, FFT, ACIR. Real-time DSP primitives for sensor stacks.

flexibil rubber-rec

Rubber-recipe formulator with cure-window and mechanical-property gates. Spec-typed, audit-trailed.

lih roi_compute_v2

Investment ROI kernel with deterministic discounting and sensitivity sweeps. No probabilistic narration in the math path.

The pipeline is uniform: typed-spec → forward-parametric-generator → SDF-or-equivalent substrate → standard-solver gates → manufacturing/eval gate → deterministic audit trail. Every spec-to-artifact pair carries a SHA chain so any output can be re-derived bit-for-bit from its inputs.

Per-Tick Relevance + Priority Measurement

AFK loops can degrade silently — a session keeps emitting ticks while doing nothing of substance. bin/tick-work-meter.sh measures work-density per /loop tick and gates the loop when the signal collapses.

Volume class (4)

DEAD · THIN · NORMAL · DENSE. Counts tool calls, file edits, and governance events per tick window.

Relevance class (5)

DEAD · VOLUME_INFLATION · LOW_LIFT · ALIGNED · HIGH_LIFT. Scored against the active backlog and roadmap, not raw activity.

A DOUBLE GATE halts AFK loops when both signals collapse: a DEAD volume reading or a VOLUME_INFLATION relevance reading is enough to stop emission until human review. Substantive evo_log entries credit relevance lift even when the underlying work happened outside the repo, provided the governance trail records it.

Dynamic Priority + Roadmap ReorderingR9

The roadmap is a live ordering, not a static plan. WSJF (Weighted Shortest Job First) provides the formula:

WSJF = (cost_of_delay + reuse_leverage + external_urgency + upstream_blocker) ÷ effort

Weighted Shortest Job First

The roadmap_items table currently holds 96 rows across FDRP-core and 13 client tracks. The discipline is hybrid: waterfall rigour within a wave (gates, governance, configuration freeze) and agile re-prioritization between waves. The roadmap_decisions table records every reorder with inputs, score deltas, and approver, so the ordering is auditable.

GPT-5.5-Leader Cross-Model VerificationWave R11

The default cross-model panel uses Opus as primary author with two critique models. Wave R11 inverts the seat assignments for architectural-design dispatches: GPT-5.5 leads the design, Opus mirrors with the critique role, and Gemini (gemini-pro-latest) RED-teams the combined output. The protocol was validated empirically on the PS-S6E4 EXP-8 architectural redesign, where the GPT-5.5-led panel surfaced a structural blind spot that an Opus-led panel had missed across two prior runs.

Explore the Methodology

Core Algorithms

Pseudocode for CVT computation, gate progression, wave dispatch (spiral-out), and cross-model verification. Copy-ready reference implementations.

View pseudocode →

Full Paper

The complete FDRP research paper with formal definitions, production data from 58 runs, and the antimatter building case study.

Read the paper →

Live Dashboard

Real-time CVT tracking, SPC control charts, and phase progression across active FDRP runs. Production metrics updated continuously.

View dashboard →