Q&A — Phase 26.3 KnowledgeCompiler: Compilation Strategy & Correctness

[web3guru888]

Frequently Asked Questions — KnowledgeCompiler

Q1: How do we ensure compiled rules stay consistent with the ontology?

A: Every CompiledRule stores source_axioms — the set of OntologyAxiom IDs it was compiled from. When an axiom is modified or retracted in OntologyManager, the compiler invalidates all rules that reference it. This is a dependency tracking approach, similar to make-style build systems.

Q2: What is the decompilation process?

A: decompile(rule_id) recovers the original axioms by looking up source_axioms in the OntologyManager. This is lossless for directly-compiled rules. For merged rules (products of merge_similar_rules), decompilation returns the union of all source axioms from all merged components.

Q3: Why not compile everything eagerly?

A: Three reasons:

1. Memory: Each compiled rule occupies memory. With 10K+ axioms, compiling all would be wasteful for rarely-used knowledge.
2. Maintenance cost: Every TBox change invalidates affected compiled rules. More compiled rules = more invalidation overhead.
3. Correctness risk: Compiled rules bypass the reasoner. If the compilation is done before the ontology stabilizes, we'd be caching incorrect results.

The threshold-based approach compiles only the hot path — knowledge that's accessed frequently enough to justify the compilation cost.

Q4: How does decay work?

A: Each maintenance cycle multiplies activation_count by decay_rate (default 0.95). After ~45 cycles without use, a rule's activation drops below 10% of its peak. When it falls below compilation_threshold (0.5), it's decompiled back to declarative form.

This implements the ACT-R base-level decay principle: knowledge that isn't rehearsed gradually becomes harder to access.

Q5: What is the capacity eviction policy?

A: When max_compiled_rules (default 10,000) is reached:

1. Score all rules using the HYBRID formula
2. Sort by score ascending
3. Evict the lowest-scoring rule
4. Decompile the evicted rule (return to declarative form)

This is essentially LFU (Least Frequently Used) weighted by recency and utility.

Q6: How does rule firing work?

A: fire_rule(rule_id, bindings) matches the rule's conditions against the provided bindings (variable→value dict). If all conditions are satisfied, the actions are executed and the result bindings are returned. Firing increments activation_count and updates last_used.

Q7: How does KnowledgeCompiler integrate with ReasoningOrchestrator (20.5)?

A: ReasoningOrchestrator can query the compiler before invoking the full reasoner. If a compiled rule matches the query, it returns immediately (cached path). Only if no compiled rule matches does it fall through to OntologyManager/LogicalInferenceEngine (full reasoning path). This creates a two-tier reasoning architecture: fast compiled rules + slow complete reasoning.

---

Issue: #580 | Planning: #577