Federated Dual Ontology: Isolating and Coordinating Two Semantic Domains

Two Sets of Constraints for One Operation

Fixing the duplicate Kafka message issue in procurement_service.py requires satisfying two distinct constraint groups: code‑architecture constraints (CN‑001‑v2, CN‑002) and business‑rule constraints (BIZ‑CN‑001, BIZ‑CN‑002). These constraints belong to different semantic domains maintained by separate teams, each with its own schema evolution cycle, and should not be tightly coupled.

Why Merging Domains Fails

Putting all memories into a single instance directory works for small systems but introduces three problems:

Namespace pollution : identifiers such as CN‑001 and BIZ‑CN‑001 would appear in the same retrieval results, causing cross‑domain relevance interference.

Coupled schema evolution : a change in a business rule threshold (e.g., adjusting BIZ‑CERT‑001 from 30 days to 15 days) would trigger a reload of code‑architecture memories, contaminating the architecture domain’s migration records.

Asymmetric token budgeting : code‑architecture tasks need more tokens for architectural constraints, while business tasks need more for rule constraints; a merged graph cannot allocate budgets per domain.

Federated Solution Core

The federated approach loads each domain independently, provides a unified query interface, injects memories with domain‑specific token budgets, and validates each domain separately.

Directory Structure

phase6/
├── instances/               # code‑arch domain memories
│   ├── CROSS_CUTTING/       # CN‑001‑v2, CN‑002, etc.
│   ├── DOMAIN/              # PAT‑001, DEC‑001, etc.
│   └── ADAPTER/             # AD‑001, BG‑001, etc.
├── instances_purchasing/    # purchasing domain memories (separate)
│   ├── BIZ-CN-001.md        # certification validity constraint
│   ├── BIZ-CN-002.md        # amount‑approval constraint
│   ├── BIZ-PAT-001.md       # supplier switch pattern
│   └── BIZ-DEC-001.md       # certification threshold decision
└── schema/                  # shared ObjectType schema definitions

Both domains share the same schema/objects/ definitions (ConstraintMemory, PatternMemory, DecisionRecord, etc.), but keep their instance directories separate, meaning the type language is identical while the content scope differs.

Implementation Details

The key data structure is DomainConfig, which declares each domain’s instance root, schema root, and token budget:

domains = [
    DomainConfig(
        name="code-arch",
        instances_root=PHASE6 / "instances",
        schema_root=schema_root,
        budget=BudgetConfig(hot=300, warm=400, cold=0, reserve=100),
        priority=0,  # architecture constraints appear first in context
    ),
    DomainConfig(
        name="purchasing",
        instances_root=PHASE6 / "instances_purchasing",
        schema_root=schema_root,
        budget=BudgetConfig(hot=300, warm=200, cold=0, reserve=100),
        priority=1,  # business constraints follow
    ),
]

The FederatedGraph loads the two domains independently, and FederatedInjector injects them according to priority, producing a FederatedInjectManifest:

fed_graph = FederatedGraph(domains)
fed_graph.load()   # code‑arch=7 nodes, purchasing=4 nodes
fed_injector = FederatedInjector(fed_graph)
fed_manifest = fed_injector.inject(task, keywords)
# Output example:
# total_memories=7  total_tokens≈743
#   code‑arch: memories=4, tokens≈400
#   purchasing: memories=3, tokens≈343

Experimental Results

Running run_federation_demo.py with the qwen3.7‑max model yields the following steps:

Step 3 – Cross‑Domain Search : Using keywords ["certification", "认证", "supplier", "采购"] returns only purchasing memories, e.g.,

[purchasing] BIZ-CN-001   tier=hot   confidence=1.0
[purchasing] BIZ-DEC-001  tier=warm  confidence=0.9
[purchasing] BIZ-PAT-001  tier=warm  confidence=0.88

The code‑architecture domain does not match, confirming correct routing.

Step 4 – Federated Injection : The task "Fix duplicate Kafka messages in procurement_service.py" triggers both domains, producing:

code‑arch:   memories=['CN-001-v2','CN-002','PAT-001','AD-001']  tokens≈400
purchasing: memories=['BIZ-CN-001','BIZ-CN-002','BIZ-PAT-001'] tokens≈343
total:      memories=7  tokens≈743

Step 5 – LLM Generation (excerpt) :

@dataclass(frozen=True)
class PurchaseOrderRequest:
    supplier_id: str
    amount: float
    idempotency_key: str   # [PAT-001][CN-002] idempotency key required
    approval_request_id: Optional[str] = None   # [BIZ-CN-002] high‑value approval token

The generated code comments reference both constraint IDs, showing that the model correctly linked memories from each domain.

Step 6 – Domain Isolation Verification :

code‑arch nodes:   ['AD-001','CN-001-v2','CN-002','DEC-001', ...]
purchasing nodes: ['BIZ-CN-001','BIZ-CN-002','BIZ-DEC-001','BIZ-PAT-001']
ID namespace overlap: none (isolation verified)

No ID collisions occur, confirming proper domain isolation.

Three Engineering Decisions

Decision 1 – Share Schema, Not Instances : ObjectType definitions (ConstraintMemory, PatternMemory, etc.) are common, but each domain keeps its own instance directory, avoiding duplicated schema maintenance.

Decision 2 – Priority Drives Context Order : During federated injection, the domain with priority=0 (code‑arch) writes its memories first, placing architectural constraints at the context head; the purchasing domain follows with priority=1, adhering to the “critical information first” principle.

Decision 3 – Independent Schema Evolution : Functions such as schema_evolution.py and BudgetConfig operate at the domain level. FederatedInjector.set_schema_window(domain=...) allows setting version windows for a single domain without affecting the other.