A supplier corrects an allergen declaration. Two delivered cocoa lots contained an undeclared milk component.
The correction is one sentence. The manufacturing response is a network of questions.
Which batches consumed those lots? Which packaging versions were used? Does the artwork declare milk? Is the inventory reserved for a customer? Who can authorize its release?
Stopping everything disrupts unaffected production. Stopping too little can leave affected inventory moving.
I built SpecCascade to explore a more precise response: connect the change to historical manufacturing evidence, coordinate containment, verify the resulting state, and preserve what the agents learned.
The application uses FalkorDB for connected evidence and persistent agent context, alongside the OpenAI Agents SDK for model-driven tool execution.
All manufacturing records, enterprise operations and QA authority shown here are synthetic simulations.
Watch the three-minute walkthrough
View the source and installation instructions on GitHub.
The difficult question is historical
A current recipe tells you what a product contains today. It does not establish which ingredient lot a particular batch consumed last month.
A current packaging file does not prove which artwork version was used when that batch was packed.
That distinction shaped the project.
SpecCascade connects supplier notices to delivered lots, historical consumption, recipe versions, packaging declarations, inventory and customer shipments. An investigation follows those relationships before deciding which batches require a response.
Consider two batches made from the same recipe. One consumed a notified cocoa lot. The other consumed an unrelated delivery.
Their recipes may look identical. Their exposure is different.
Why I put FalkorDB at the center
The investigation follows a connected path:
Supplier notice
→ Ingredient lot
← Historical batch
→ Recipe version
→ Packaging version
→ Allergen declaration
→ Shipment
→ Customer order
→ Customer
FalkorDB lets the investigation traverse these relationships through parameterized Cypher.
For example, this query follows a notice to consuming batches, their packaging declarations and associated shipments:
MATCH (n:ChangeNotice {id:$notice})
-[:APPLIES_TO_LOT]->(l:IngredientLot)
MATCH (b:ProductionBatch)-[:CONSUMED_LOT]->(l)
MATCH (b)-[:PACKAGED_WITH]->(p:PackagingVersion)
-[:HAS_DECLARATION]->(d:AllergenDeclaration)
OPTIONAL MATCH (b)-[:INCLUDED_IN_SHIPMENT]->(s:Shipment)
RETURN b.id, l.id, p.id, d.allergens, s.id
This is an illustrative evidence path. The full investigation also preserves unaffected batches and handles missing provenance conservatively.
That matters: a system that finds affected products but cannot explain why other products remain unaffected still leaves a quality team with substantial work.
The investigation follows actual historical relationships, with source evidence available for inspection.
FalkorDB also stores findings, assigned tasks, tool events, approvals and verified memories. The graph connects the evidence behind an investigation to the work performed because of it.
How the agents know what they know
An agent cannot establish manufacturing exposure from its general knowledge. It needs access to the relevant records and a clear distinction between evidence, interpretation and completed action.
SpecCascade exposes bounded function tools through the OpenAI Agents SDK. Those tools inspect notice scope and policy, traverse historical consumption, retrieve batch evidence, propose recovery work, apply containment and verify enterprise state.
The agents receive actual tool results.
Their findings and execution events persist in FalkorDB, allowing the investigator, coordinator, planner and verifier to work from shared context. A model summary cannot substitute for a required tool result.
This became one of my most useful engineering lessons: a fluent explanation is not an execution receipt.
A model can describe a sensible response without completing the operation. SpecCascade checks for the tool results required by each stage before accepting that stage as successful.
What happened in the 120-batch scenario
The primary scenario contains 120 synthetic production batches across two manufacturing facilities.
| Classification | Batches |
|---|---|
| Confirmed affected | 24 |
| Unresolved exposure evidence | 4 |
| Unaffected by this notice | 92 |
| Requiring containment | 28 |
The response requires containment for the 24 confirmed affected batches and the four whose evidence remains unresolved. The other 92 retain their eligibility under this notice.
Scenario results are derived from the connected manufacturing facts. This screen shows the investigation before containment is applied.
These are controlled scenario outcomes, rather than measured factory savings. Their value is that the result can be inspected, reproduced and challenged against the underlying relationships.
The four uncertain batches are particularly important. Missing evidence does not become a declaration of safety. Their uncertainty remains visible even after containment succeeds.
A graph finding must produce an operational consequence
Finding a dependency is useful. Acting on it makes the dependency operational.
SpecCascade writes targeted holds into a separate, persisted enterprise-system simulation implemented with SQLite. FalkorDB remains authoritative for connected manufacturing context, investigations and evidence.
That separation creates an important distinction: an investigation saying “hold this batch” is different from inventory actually being held.
A held batch cannot proceed through dispatch. Attempting shipment dispatch produces a visible rejection backed by enterprise state.
The response also creates work for relevant owners: supplier reconciliation, packaging review, warehouse restrictions and customer-order review. The graph connects the correction to both the affected inventory and the people responsible for resolving it.
Recovery needs evidence and authority
Containment is only part of the response. Teams also need a controlled path toward recovery.
SpecCascade requires explicit QA authority, a recorded rationale and supporting prerequisites before an eligible batch can be released.
The release workflow includes supplier reconciliation, label review, quality review and relabeling validation. Selecting QA authority alone is insufficient. A corrected label alone is insufficient. Unresolved lot exposure remains ineligible for release.
Successful decisions become separate evidence-linked records. Original consumption and packaging history remain unchanged.
This preserves the difference between what happened during manufacturing and what was later authorized as a corrective action.
Verification closes the loop
The independent verifier revisits the source relationships and compares required containment with actual enterprise restrictions and authorized dispositions.
It checks whether the intended response took effect.
A passing result can account for both remaining holds and a valid QA-authorized release. It can also coexist with unresolved exposure investigations.
Those are different questions:
- Was the required containment executed?
- Has every underlying uncertainty been resolved?
Combining them into one green status would hide useful information.
Memory should preserve judgment without inheriting permission
A verified investigation becomes a persistent episode in FalkorDB.
For a later supplier correction, the memory agent retrieves applicable experience using supplier, allergen and causal relevance. The next investigation receives procedural guidance, along with an explicit boundary: earlier batch conclusions and approvals do not authorize the new incident.
It must traverse the new lot relationships.
Reuse the investigation procedure. Recheck the new incident's facts.
This changed how I thought about agent memory. A saved answer is often less useful than a saved procedure connected to the evidence that justified it.
The reusable knowledge is how to investigate and verify the response. Yesterday's clearance belongs to yesterday's batch.
What building this taught me
The strongest part of building SpecCascade was connecting three things that are easy to demonstrate separately: graph reasoning, operational action and persistent memory.
FalkorDB provided a common structure for them. Source facts connect to findings; findings connect to tasks and decisions; verified outcomes connect to reusable experience.
I also learned to test consequences. Does changing the consumed lot change the classification? Does missing provenance remain uncertain? Does a hold actually block dispatch? Can the verifier detect a missing enterprise write?
The current application runs locally with Docker Compose. Live OpenAI Agents SDK tool execution was verified during development. Production identity, real ERP adapters and supplier-document ingestion are future work.
SpecCascade was developed with Codex coding assistance, with implementation review and runtime verification as part of the development process.
The central workflow is running today: investigate, contain, approve, verify and remember.
One supplier change.
Only the right batches get stopped.
Top comments (0)