AXIOM CASCADE — ENGINE 03 ARCHITECTURE

Graph-Native Change Intelligence

Technical design document for the Axiom Cascade engineering change engine — covering the product knowledge graph traversal architecture, parallel approval orchestration, effectivity state machine, cross-system atomic propagation, and predictive change analytics pipeline.

CLASSIFICATION
INTERNAL — ENGINEERING
VERSION
3.0.1
ENGINES
8 CHANGE SUBSYSTEMS
RUNTIME
RUST / AXIOM CORE
01 — IMPACT GRAPH TRAVERSAL ARCHITECTURE
Change impact analysis is a graph traversal problem. Cascade solves it in sub-10 seconds across 50,000+ nodes.
Traditional PLM systems answer "what does this change affect?" by running recursive SQL queries against relational BOM tables — an approach that degrades exponentially with product complexity. Cascade operates directly on the Axiom product knowledge graph, using modified breadth-first search (BFS) with typed relationship filtering to traverse the complete impact surface in a single pass. The traversal is not limited to BOM hierarchy — it crosses domain boundaries to reach procurement orders, manufacturing routings, qualification records, supplier certifications, and regulatory submissions connected to the changed artifact.
BFS IMPACT TRAVERSAL — MULTI-DOMAIN REACH ANALYSIS
01
Seed Node
Changed artifact identified (component, material, specification, drawing). Seed node established in the product knowledge graph
02
Relationship Filter
Typed relationship filter configured: is_child_of, is_used_in, is_procured_by, is_manufactured_via, is_qualified_by, is_regulated_under. Each type selectable per analysis scope
03
BFS Traversal
Modified BFS with cycle detection (DAG enforcement). Visits every reachable node through the filtered relationship set. Depth-limited for performance (configurable max depth, default: unlimited)
04
Domain Classification
Each reached node classified by domain: BOM (eBOM/mBOM/sBOM/aBOM), Procurement (active POs), Manufacturing (open work orders), Quality (qualification records), Regulatory (submissions)
05
Impact cost estimated: material write-offs (from Lattice), requalification cost (from Meridian), schedule delay (from manufacturing calendar), supplier impact (from procurement)
Cost Estimation
06
Impact Report
Structured impact report: affected assemblies (count + list), affected POs (count + value), affected work orders, affected qualifications, affected regulatory submissions, estimated cost
// Cascade impact traversal — Rust implementation
pub fn compute_impact(
    graph: &ProductKnowledgeGraph,
    seed: NodeId,
    filters: &[RelationshipType],
    max_depth: Option<u32>,
) -> ImpactReport {
    let mut visited: HashSet<NodeId> = HashSet::new();
    let mut queue: VecDeque<(NodeId, u32)> = VecDeque::new();
    let mut report = ImpactReport::new(seed);
    
    queue.push_back((seed, 0));
    visited.insert(seed);

    while let Some((node, depth)) = queue.pop_front() {
        if max_depth.map_or(false, |d| depth >= d) { continue; }
        
        // Traverse all filtered relationships from current node
        for edge in graph.edges_from(node, filters) {
            let target = edge.target();
            if visited.insert(target) {
                // Classify the reached node by domain
                match graph.node_domain(target) {
                    Domain::BOM(view) => report.add_bom_impact(target, view),
                    Domain::Procurement => report.add_po_impact(target),
                    Domain::Manufacturing => report.add_wo_impact(target),
                    Domain::Quality => report.add_qual_impact(target),
                    Domain::Regulatory => report.add_reg_impact(target),
                    Domain::Supplier => report.add_supplier_impact(target),
                }
                queue.push_back((target, depth + 1));
            }
        }
    }
    report.estimate_cost(graph); // Roll up financial impact
    report
}
The BFS approach guarantees that every reachable node is visited exactly once, producing O(V+E) time complexity where V is the number of nodes and E is the number of edges in the reachable subgraph. For a typical aerospace product with 50,000 components, the traversal completes in under 10 seconds on a single Rust thread — because graph adjacency lookups in the Axiom knowledge graph are O(1) operations backed by hash-indexed adjacency lists, not O(n) SQL JOINs against relational tables. The typed relationship filter is the key architectural differentiator: by selecting which relationship types to traverse, the same BFS algorithm produces fundamentally different analyses. Filtering only "is_child_of" produces a pure BOM where-used analysis. Adding "is_procured_by" extends reach to active purchase orders. Adding "is_qualified_by" reveals regulatory requalification requirements. The filter set is configurable per change type: a cosmetic change might traverse only BOM relationships, while a material change traverses all domains.
<10s
Full impact analysis (50K+ components)
O(V+E)
BFS traversal complexity
6
Domains analyzed per traversal
O(1)
Adjacency lookup (hash-indexed)
02 — PARALLEL APPROVAL ORCHESTRATION
Approval routing is a DAG execution problem. Sequential chains are the architectural failure.
The single greatest bottleneck in engineering change management is approval latency. Traditional PLM systems route ECOs sequentially: engineering → quality → manufacturing → procurement. If any approver is unavailable, the chain stalls. Cascade models the approval workflow as a directed acyclic graph (DAG) and executes it with maximum parallelism.
Each approval gate in a Cascade workflow is a node in a DAG. Gates that have no dependencies on each other execute in parallel. Gates that depend on upstream decisions wait until their prerequisites are satisfied. The DAG is constructed dynamically based on the change classification: a cosmetic change generates a simple two-gate DAG (engineering → release). A material change generates a six-gate DAG with three parallel branches (engineering, quality, and manufacturing review in parallel, followed by procurement assessment, then regulatory evaluation, then final release). The critical path through the DAG determines the minimum possible approval time. Cascade identifies and reports the critical path, enabling change managers to focus attention on the gates that control schedule.
DAG-BASED APPROVAL EXECUTION
01
Classification
Change type classified (cosmetic, dimensional, material, process, safety). Classification drives template DAG selection
02
DAG Construction
Template DAG instantiated with actual approvers resolved from RACI matrix. Independent gates marked for parallel dispatch
03
Parallel Dispatch
All gates with satisfied dependencies dispatched simultaneously. Notifications via email, mobile push, and NFC badge tap for shop floor supervisors
04
SLA Monitoring
Each gate has configurable SLA. Exceeded SLAs trigger automatic escalation to delegate. Late approval rate tracked as KPI
05
Convergence
Dependent gates activate when all prerequisites are satisfied. Final release gate requires all upstream approvals + Sentinel e-signature
Conditional gate logic: Gates can be conditionally included or excluded based on impact analysis results. If the change does not affect any regulated component (determined by the impact traversal), the regulatory review gate is automatically skipped — reducing cycle time without compromising governance
Delegation chains: Each approver has a configured delegation chain (primary → delegate 1 → delegate 2 → escalation manager). When the primary exceeds their SLA, the system automatically routes to the next delegate without requiring manual intervention or re-routing
Approval by exception: For high-volume, low-risk changes (documentation updates, supplier information corrections), Cascade supports approval-by-exception: changes auto-approve after a configurable review period unless an approver explicitly objects. Exception-based approvals generate the same audit trail as active approvals
70%
Cycle time reduction vs. sequential routing
DAG
Directed acyclic graph execution model
6%
Late approval rate (down from 27%)
Auto
SLA-driven delegation escalation
03 — ENGINE ARCHITECTURE DEEP DIVES
Eight change engines. Full architecture documentation.
01
Effectivity & Disposition State Machine
Unit/date/lot/PO effectivity · WIP disposition optimization · Configuration collision prevention · Barcode enforcement
Effectivity is the most dangerous transition in the change lifecycle — the moment when old and new configurations coexist simultaneously. Cascade models effectivity as a finite state machine with four effectivity modes (date-based, unit-based, lot-based, production-order-based) and three disposition states for existing inventory (use-as-is, rework, scrap). The state machine prevents configuration collisions by enforcing that no assembly can contain components from incompatible effectivity ranges. At the database level, effectivity is implemented as a temporal validity range on each BOM relationship — enabling the system to resolve the "correct" BOM for any point in time or any serial number range without maintaining separate BOM copies.
// Effectivity state machine — temporal BOM resolution
pub enum EffectivityMode {
    DateBased { start: DateTime, end: Option<DateTime> },
    UnitBased { from_serial: u64, to_serial: Option<u64> },
    LotBased { lot_ids: Vec<LotId> },
    ProductionOrder { order_ids: Vec<OrderId> },
}

pub enum DispositionAction {
    UseAsIs,       // Existing stock acceptable under new revision
    Rework { instructions: WorkInstruction },
    Scrap { write_off_value: Currency },
    ReturnToVendor { rma_id: RmaId },
}

// Resolve BOM for a specific unit at a specific time
pub fn resolve_bom(
    product: ProductId,
    serial: Option<u64>,
    at_time: DateTime,
) -> ResolvedBOM {
    graph.bom_edges(product)
        .filter(|e| e.effectivity.is_valid_at(serial, at_time))
        .collect()
}
WIP disposition optimization: For each affected component in work-in-progress, Cascade calculates rework cost vs. scrap cost vs. use-as-is risk. The optimization considers production stage (earlier = cheaper to rework), remaining value (partially assembled = higher scrap cost), and quality risk (use-as-is acceptable only if change does not affect fit, form, or function)
Barcode enforcement at point-of-use: When a change takes effect, every affected work station receives updated component revision requirements. Barcode scanners at point-of-use verify that the operator is installing the correct revision. Incorrect revision scan triggers a hard stop with supervisor override requiring documented justification
4
Effectivity modes (date, unit, lot, PO)
55%
Mix-model scrap reduction (validated)
$2M+
Annual write-off avoidance per plant
Zero
Configuration collisions on floor
02
Cross-System Atomic Propagation
Event-driven architecture · Transactional outbox · ERP/MES/QMS synchronization · Idempotent consumers
An approved change that lives only in the PLM is a change that manufacturing will ignore. Cascade propagates approved changes to downstream systems using an event-driven architecture with transactional outbox pattern. When an ECO is approved and the effectivity conditions are met, Cascade publishes a structured change event to a durable message bus. Downstream consumers — Forge ERP (BOM update), MES (work instruction revision), QMS (CAPA linkage), and the supplier portal (notification dispatch) — process the event idempotently. The transactional outbox ensures that the change approval and the event publication are atomic: if the approval commits, the event is guaranteed to be published. If the event publish fails, the approval rolls back. No partial states. No orphaned changes.
TRANSACTIONAL OUTBOX — ATOMIC CHANGE PROPAGATION
01
ECO Approval Commit
Approval + audit trail + e-signature committed to Axiom graph. Change event written to outbox table in same transaction
02
Outbox Relay
Background relay process reads outbox table and publishes events to message bus (Kafka/NATS). Relay is idempotent — safe to replay
03
Consumer Processing
ERP consumer: BOM revision + cost roll-up. MES consumer: work instruction update. QMS consumer: CAPA linkage. Supplier consumer: portal notification
04
Acknowledgment
Each consumer acknowledges processing. Cascade tracks which systems have consumed the change. Closure requires all acknowledgments
Idempotent consumers: Every consumer is designed to be idempotent — processing the same change event twice produces the same result as processing it once. This enables safe retry on failure without risk of duplicate BOM updates, duplicate work instruction revisions, or duplicate supplier notifications
Dead letter queue with alerting: Events that fail processing after configurable retry count (default: 3) are routed to a dead letter queue. Alerts fire immediately to the change manager and the affected system administrator. No change event is silently lost
Operator acknowledgment enforcement: After MES receives the work instruction update, barcode scanners on the production line force each operator to acknowledge the new revision before work can proceed. Acknowledgment is logged in the Sentinel audit trail
4
Systems synchronized atomically
Outbox
Transactional pattern (no dual-write)
31%
Defect escape reduction (10-day closure)
Zero
Lost change events (DLQ + alerting)
03
Predictive Change Analytics Pipeline
NLP impact prediction · GNN propagation modeling · Revision anomaly detection · External trigger monitoring
The future of change management is prediction, not reaction. Cascade's predictive analytics pipeline uses three ML models operating on the product knowledge graph: (1) a natural language processing model that digests BOM hierarchies and CAD metadata to predict which downstream assemblies will break if a specification changes — before anyone submits an ECR, (2) a Graph Neural Network (GNN) trained on historical change propagation patterns to predict the likely impact scope of a proposed change based on the graph topology and historical change frequency, and (3) a time-series anomaly detector that monitors revision frequency per component and flags statistical outliers — components that are being revised at abnormally high rates, indicating unstable requirements, supplier quality drift, or design-for-manufacturability failures.
GNN impact prediction model: A Graph Neural Network (GraphSAGE architecture) is trained on historical change data: given a proposed change to node X, predict which nodes in the k-hop neighborhood will require modification. Training data is generated from the complete ECO history — every past change provides a labeled example of actual propagation. Inference produces a probability-ranked list of likely-affected nodes before the BFS traversal confirms the deterministic impact
Revision frequency anomaly detection: For each component in the product graph, Cascade tracks revision frequency over time and fits a baseline model. Components whose revision rate exceeds 2σ from baseline are flagged as "chronically unstable." Root cause analysis correlates instability with upstream factors: requirement volatility (from Meridian), supplier quality drift (from Echo), or manufacturing process issues (from Forge ERP quality module)
External trigger monitoring: Cascade continuously monitors component obsolescence databases (IHS Markit, Z2Data, SiliconExpert), regulatory standard update feeds (ECHA, OSHA, FAA), and supplier quality trends (incoming inspection DPPM from Forge ERP). When a trigger event is detected, Cascade pre-generates a draft ECR with preliminary impact analysis
83%
Assessment time reduction (NLP + GNN)
GNN
GraphSAGE propagation prediction
18%
ECO volume reduction from predictive signals
<24h
External trigger to draft ECR
04
Supplier Change Propagation
PCN/PDN auto-processing · Structured notification · Acknowledgment tracking · PPAP/FAI coordination
The supply chain is a bidirectional change propagation network. Internal changes affect suppliers. Supplier changes affect internal designs. Cascade manages both directions through the Forge supplier portal. When an internal ECO affects a purchased component, the affected supplier receives a structured change notification — not an email with a PDF, but a traceable, acknowledgment-required, revision-controlled package with updated specifications, drawings, and delivery requirements. When a supplier issues a Product Change Notification (PCN) or Product Discontinuation Notice (PDN), Cascade's auto-processing pipeline parses the notification, maps the affected supplier part numbers to internal BOMs (via Lattice), generates the impact analysis (via the BFS traversal), and routes a draft ECR to the responsible engineer — all automatically.
PCN/PDN parsing pipeline: Supplier notifications arrive in varied formats (PDF, email, Excel, EDI). An NLP extraction pipeline parses the affected part numbers, change description, effective date, and recommended action. Extracted data is mapped to internal BOM components via the supplier-part-to-internal-part cross-reference maintained in Lattice. Mapping failures (unknown supplier part number) are flagged for manual resolution
AVL risk intelligence: When a change affects a multi-source component, Cascade evaluates all Approved Vendor List alternatives: which alternates are qualified? Which have capacity? Which have pricing agreements? Single-source components with no qualified alternate are flagged as high-risk — triggering a qualification campaign for the next-best alternate before the change takes effect
Auto
PCN/PDN to ECR conversion pipeline
NLP
Multi-format supplier notification parsing
100%
Supplier acknowledgment tracking
AVL
Single-source risk flagging
05
Change Analytics & Cycle Intelligence
Cycle time decomposition · Bottleneck identification · Cost-of-change analytics · First-pass yield correlation
You cannot improve what you do not measure. Cascade decomposes the change lifecycle into five measurable segments: initiation-to-impact-analysis, impact-analysis-to-first-approval, first-approval-to-last-approval, approval-to-ERP-release, and ERP-release-to-shop-floor-verification. Each segment is benchmarked against configurable SLAs. Time spent in each segment is attributed to specific gates and specific approvers — enabling data-driven identification of systemic bottlenecks. The analytics engine also tracks cost-of-change per product family, per change category, and per initiating root cause — providing engineering leadership with the financial data needed to justify design-for-manufacturability improvements that reduce total change volume.
Lifecycle SegmentTypical Time (Before)Cascade TargetPrimary Bottleneck
Initiation → Impact Analysis2-5 days (manual BOM trace)<10 seconds (graph traversal)Manual where-used analysis
Impact Analysis → First Approval1-3 days (report distribution)Immediate (auto-dispatch)Report formatting and routing
First Approval → Last Approval5-10 days (sequential routing)1-3 days (parallel DAG)Sequential approval chains
Approval → ERP Release1-2 days (manual entry)Immediate (atomic event)Manual BOM re-entry in ERP
ERP Release → Floor Verification1-5 days (paper distribution)<1 day (barcode enforcement)Paper traveler distribution
First-pass yield correlation: Cascade correlates change management maturity (cycle time, closure rate, bottleneck frequency) with manufacturing first-pass yield. Plants with robust change culture achieve near-perfect FPY (95%+) despite frequent ECOs — proving that change frequency is not the problem; change management quality is
ROI dashboard: Quantifies Cascade's business value: cycle time saved × engineering hourly rate, scrap avoided through effectivity management, warranty cost avoided through closed-loop field feedback (via Echo), and compliance penalties avoided through automated regulatory packaging (via Sentinel). Enterprises recoup implementation costs within 12 months (4× ROI per Forrester 2024)
5
Lifecycle segments decomposed
ROI within 12 months (Forrester)
95%
FPY in mature change environments
Real
Time KPI dashboards with alerting
04 — CROSS-ENGINE INTEGRATION MAP
Cascade is the central nervous system. Every other Axiom engine connects through change governance.
Engineering changes are the mechanism by which the product definition evolves. Cascade governs that evolution by orchestrating interactions across every other Axiom engine — from requirements change impact (Meridian) to BOM revision propagation (Lattice) to simulation re-verification triggering (Nexus) to compliance package regeneration (Sentinel) to field feedback-driven corrective actions (Echo).
Meridian → Cascade
Requirement change triggers impact analysis across all implementing design artifacts. Re-verification scope auto-calculated. Draft ECR generated with requirement change as justification
NATIVE
Lattice → Cascade
BOM revision propagated atomically across all four views (eBOM/mBOM/sBOM/aBOM). Effectivity state machine manages configuration cutover across manufacturing lines
NATIVE
Nexus → Cascade
Design changes that affect simulation-verified parameters trigger re-simulation workflow in Nexus. Verification matrix updated when new simulation results are available
NATIVE
Sentinel → Cascade
Every ECR/ECO/ECN action passes through Sentinel's e-signature and audit trail interceptor. Regulatory change classification activates framework-specific approval workflows
NATIVE
Echo → Cascade
Field failures with design-related root causes auto-generate draft ECRs with failure evidence, affected population estimate, and proposed corrective action. CAPA-to-ECR loop closed
NATIVE
Forge ERP / MES
Approved ECOs propagate via transactional outbox to ERP (BOM + cost) and MES (work instructions + routing). Operator acknowledgment tracked. Closure requires downstream verification
EVENT-DRIVEN
05 — PERFORMANCE ARCHITECTURE
Sub-10-second impact analysis is not a benchmark. It is the architectural constraint that drove every design decision.
Cascade's performance target — full-scope impact analysis in under 10 seconds across 50,000+ component products — required architectural decisions that differ fundamentally from traditional PLM change management modules built on relational databases.
Three architectural decisions enable sub-10-second impact analysis. First, the product knowledge graph uses hash-indexed adjacency lists rather than relational foreign keys. Each node stores its outbound edges in a hash map keyed by relationship type — making edge lookup O(1) regardless of graph size. Second, the BFS traversal runs on Rust with zero-allocation hot paths. The traversal reuses a pre-allocated visited set and queue, avoiding garbage collection pauses that would introduce latency variance. Third, the graph is memory-mapped. For products up to 100,000 components, the entire product subgraph fits in resident memory (typically 2-4 GB). For larger products, memory-mapped file I/O provides near-memory access speeds with disk backing. These decisions mean that Cascade's impact analysis performance is bounded by graph topology (number of edges traversed), not by database query optimization or I/O latency.
O(1)
Edge lookup (hash-indexed adjacency)
Zero
Allocation in BFS hot path (Rust)
mmap
Memory-mapped graph for near-memory I/O
2-4GB
Resident memory for 100K component graph