Fleet Dispatch (SCFDP) Scalable Constraint Satisfaction for Vehicle Routing
The SCFDP (Scalable Constraint Fleet Dispatch Protocol) demo demonstrates that CLARA's composition architecture is not domain-specific. The same GenesisNode DAG engine that composes military engagement rules also composes civilian logistics constraints -- vehicle capacity, routing legality, time windows, and demand satisfaction -- with the same non-interference guarantees and formal proof certificates.
Try the live demo: /clara/scfdp -- Load a CVRPLIB benchmark instance, run the constraint satisfaction pipeline, and inspect the composition proofs.
Why This Demo Exists
A common reviewer concern for any assured reasoning framework is domain specificity: does the framework only work because it was designed for one particular problem? The SCFDP demo exists specifically to refute this. It takes the same composition engine used for kill web engagement authorization and applies it to a completely different domain -- vehicle routing with capacity constraints.
The constraints are different (vehicle capacity vs. rules of engagement). The features are different (demand quantities vs. threat levels). The objectives are different (minimize distance vs. maximize engagement effectiveness). But the composition mechanism is identical: rules in a DAG, BFS evaluation, namespace isolation, non-interference proofs, and formal proof certificates.
The CVRPLIB Problem Domain
SCFDP uses standard Capacitated Vehicle Routing Problem (CVRP) benchmark instances from the CVRPLIB library. These are well-studied optimization problems in operations research: given a set of customers with known demands, a depot, and a fleet of vehicles with finite capacity, find routes that serve all customers while minimizing total distance and respecting capacity constraints.
Constraint Categories
| Constraint Type | Description | Analogy to Kill Web |
|---|---|---|
| Vehicle capacity | Total demand on a route cannot exceed vehicle capacity | ROE weapons authorization limits |
| Demand satisfaction | Every customer must be served exactly once | Completeness requirement (every target evaluated) |
| Route legality | Routes must start and end at the depot | Engagement chain provenance requirement |
| Time windows | Customers must be served within specified time ranges | Engagement window constraints |
CLARA Composition in Fleet Dispatch
The composition engine evaluates each route assignment against the constraint DAG. A route that violates capacity is blocked (analogous to a target that violates ROE). A customer assignment that breaks a time window is rejected. The ML component (demand prediction) feeds into the composition engine the same way ML classification feeds into the kill web pipeline -- as features that the rule DAG evaluates.
- ML input: Demand predictions for each customer location (learned from historical data)
- Rule composition: Capacity, routing, and time window constraints evaluated via BFS through the constraint DAG
- Proof certificates: Each route assignment generates a certificate documenting which constraints were evaluated and satisfied
- Non-interference: Adding a new constraint (e.g., a new time window restriction) cannot break existing capacity or routing constraints
Domain Independence Proof
The strongest argument for CLARA's generality is a side-by-side comparison of the two domains running on the same engine:
Kill Web (Military)
- 94 rules, 13 namespaces
- 40-D feature vectors (threat, position, type)
- Targets: engage / hold / block
- Constraints: LOAC, NSL, ROE, CDE
- Objectives: mission-profile-based triage
- Proof: per-target authorization certificate
Fleet Dispatch (Civilian)
- Capacity, routing, time window rules
- Demand + distance feature vectors
- Routes: assign / reject / reroute
- Constraints: capacity, legality, time
- Objectives: minimize distance, balance load
- Proof: per-route satisfaction certificate
What is shared: The DAG composition engine, BFS evaluation, namespace isolation, non-interference proofs, SHA-256 constraint verification, and proof certificate generation. None of these are domain-specific. They are architectural properties of the CLARA framework that apply to any domain where learned predictions must compose with formal safety or correctness rules.
Non-Interference Property
The SCFDP demo explicitly tests the non-interference property: adding a new constraint rule to the DAG does not invalidate existing constraints. This is verified by:
- Running the pipeline with the base constraint set and recording all proof certificates
- Adding a new constraint (e.g., a restricted delivery zone)
- Running the pipeline again and verifying that all previously-satisfied constraints remain satisfied
- The new constraint may cause additional route rejections, but it cannot cause a previously-valid route to violate a pre-existing constraint
This mirrors the kill web architecture where adding a user rule (level 6) cannot override a LOAC constraint (level 1). The structural guarantee is the same in both domains because it is a property of the composition engine, not the domain rules.
For Reviewers
The SCFDP demo is not the flagship demonstration -- the Kill Web Doctrine demo provides the most comprehensive treatment of CLARA's capabilities. The SCFDP demo serves a specific purpose: it proves that the composition architecture is not a one-trick solution designed for military targeting. The same engine, the same guarantees, and the same proof mechanisms work in a civilian logistics context with entirely different rules, features, and objectives.
This matters for DARPA TA1 evaluation because a domain-independent assured reasoning framework has broader applicability than one that only works for a single use case. CLARA's contribution is the composition architecture itself, not any particular set of domain rules.