SpecCascade：製造變更影響分析

One supplier change, 120 batches: building SpecCascade with FalkorDB

A project write-up for Graph Hacks: Context for AI Agents. Manufacturing records and enterprise actions described here are synthetic demonstrations.

The question a recipe cannot answer

A food manufacturer receives a supplier correction: two previously delivered cocoa lots contained a milk-derived component omitted from the original declaration.

Searching current recipes for cocoa gives an incomplete picture. The operational decision depends on history: which lots were consumed, which recipe and artwork versions were used, and which customer shipments depend on the resulting stock?

SpecCascade investigates those connected facts, applies a targeted response and checks the execution independently.

Model the history behind the decision

Our FalkorDB graph links supplier notices to applicable ingredient lots, then connects those lots to historical production batches. Each batch links to its exact recipe and packaging version, allergen declaration, facility, warehouse, reservations and shipments. Shipments connect to orders and customers.

Recipe membership and actual consumption are separate facts. Two batches can share a product family while consuming different delivered lots. Stopping both merely because they look similar would lose the precision the product is meant to provide.

Parameterized Cypher retrieves the connected manufacturing evidence. Stable source identifiers and versioned records preserve the provenance behind each finding.

A controlled response with three classifications

We created Northstar Foods with 120 synthetic batches, 12 products, three suppliers and two manufacturing facilities. The primary notice concerns two exact ingredient lots.

Graph traversal and policy evaluation identify 24 confirmed affected batches, four with unresolved consumption evidence and 92 unaffected by this notice. The unknown cases remain explicit. Twenty-eight batches require containment, while the other 92 retain eligibility.

These are measured results for a constructed dataset. We do not translate them into invented factory savings or claim real-world detection accuracy.

Agents need bounded tools and shared evidence

The application separates investigation, response coordination, recovery planning, independent verification and memory. Its OpenAI Agents SDK integration exposes bounded tools for policy inspection, memory retrieval, historical traversal, batch evidence, task creation, containment and verification.

Findings and tasks are shared through FalkorDB. Models receive actual tool results. Human QA authority and evidence requirements govern inventory disposition.

A reproducible local workflow executes the operational steps without a model credential, with the active mode visible in the product. The acceptance report records which provider behavior was actually verified; integration code alone is not treated as a successful model request.

A plan does not prove an ERP changed

FalkorDB records source evidence, decisions and intended actions. A separate transactional SQLite store records actual simulated inventory, holds, dispatches and dispositions.

The coordinator applies holds, and dispatch of held stock is rejected. QA reviews supporting evidence and records a specific disposition. The verifier then re-queries source relationships and compares them with actual inventory, shipment and approval state.

Tests deliberately remove a required hold and fail an ERP write. A correct investigation cannot automatically pass execution verification.

Useful memory has an applicability boundary

A verified incident becomes a persistent episode connected to its investigation and evidence. A reusable procedure is recorded alongside it.

Follow-up retrieval checks supplier, allergen, causal mechanism and memory validity. Prior experience can guide what to inspect; it cannot authorize clearance of new lots. The new investigation still traverses current relationships, and outdated episodes are excluded.

That boundary is visible in the demo: retrieved experience explains what can be reused and which previous conclusions must be rejected.

Proving the graph does real work

Restricted-context mode cannot establish exposure or apply containment. During an actual FalkorDB outage, dependent endpoints return 503 instead of manufactured answers.

Other tests change consumed lots, historical declarations, source completeness and shipment state. Outcomes change with those relationships. An ordinary restart check compares persisted graph, memory and enterprise state before and after restart.

The Evaluation & Proof screen exposes executed Cypher, parameters, row counts and measured durations. A judge can inspect the evidence behind a result rather than rely on a confident explanation after the fact.

What we learned

The hardest engineering question was which evidence could justify an action. Historical causality, uncertainty and source versions mattered more than adding another metric.

We also learned to distinguish containment from resolution: an incident can be contained while lot documentation remains unresolved. Independent verification reports that boundary.

Finally, bounded tools and explicit authority make agent behavior easier to test, explain and trust within the scope of a synthetic demonstration.

Next steps

Future work includes ERPNext and supplier-mail adapters, reviewed document extraction, production identity and approval signatures, and stronger recovery of multi-system writes. Those are future integrations, not capabilities claimed by the current app.

SpecCascade targets Agents That Act on Connected Data and Agent Memory and Coordination. It was developed with Codex AI coding assistance; participant review, verification and technical understanding remain essential.

Source, local setup, graph schema and verification evidence.