CHIMERA Reasoning Engine: Technical Reference & Integration Guide

01 — Motivation

Standard retrieval-augmented generation works well for questions answerable from a single document or a small set of related passages. It works poorly for questions like:

• "Which suppliers in our network have connections to entities sanctioned in the last 90 days, and what is our contractual exposure?"
• "Summarize the evolution of this threat actor's TTPs across all reports filed in the last 18 months, noting any correlation with geopolitical events in the region."

These questions require multi-hop reasoning: retrieving an initial set of facts, using those facts to formulate secondary queries, resolving entity references across different data schemas, and synthesizing a coherent answer with proper attribution. This is what CHIMERA was built to do.

We want to be precise about what CHIMERA is not. It is not a general-purpose reasoning system. It does not perform mathematical proofs, physical simulations, or formal logic beyond what its underlying language model supports. It is a retrieval and synthesis orchestrator that decomposes complex queries into manageable steps and chains them together with citation tracking.

02 — Architecture

2.1 — Query Decomposition

When CHIMERA receives a query, the first step is decomposition. A lightweight classifier determines whether the query can be answered in a single retrieval pass or requires multi-hop reasoning. Single-hop queries are routed directly to the standard RAG pipeline — CHIMERA adds no value for simple factual lookups and we avoid the latency overhead.

For multi-hop queries, the decomposition module generates a query plan: an ordered sequence of sub-queries, each with a specified data source and expected output type. The plan is generated by the language model itself, using few-shot examples tuned to the client's data schema.

  User Query
      │
      ▼
  ┌──────────────┐
  │   Classify   │──── Single-hop ───▶ Standard RAG
  │   (is this   │
  │   multi-hop?)│
  └──────┬───────┘
         │ Multi-hop
         ▼
  ┌──────────────┐
  │  Decompose   │ Generate sub-query plan
  │  into steps  │ [Q1] → [Q2] → ... → [Qn]
  └──────┬───────┘
         │
         ▼
  ┌──────────────┐     ┌──────────────┐
  │  Execute Q1  │────▶│  Execute Q2  │────▶ ...
  │  (vector DB) │     │ (graph DB)   │
  └──────────────┘     └──────────────┘
                              │
                              ▼
                       ┌──────────────┐
                       │  Synthesize  │ Merge evidence
                       │  + Cite      │ Generate answer
                       └──────────────┘

2.2 — Heterogeneous Retrieval

A key design decision in CHIMERA is that each sub-query can target a different data backend. The system currently supports four retrieval modes:

• Vector retrieval — semantic similarity search over embedded documents
• Graph traversal — structured queries over entity-relationship graphs (Cypher/SPARQL)
• SQL execution — read-only queries against relational databases
• Temporal index — time-range filtered retrieval for event sequences

The decomposition model selects the appropriate retrieval mode for each sub-query based on the data type needed. This selection is imperfect — in our evaluation, the model correctly selects the optimal retrieval mode approximately 94% of the time. The remaining 6% typically results in slower but still correct answers (e.g., using vector search when a direct SQL query would be more efficient), rather than incorrect results.

2.3 — Citation Chain

Every fact in CHIMERA's output is annotated with a citation chain tracing it back to one or more source documents. Unlike simple RAG citations that point to retrieved chunks, CHIMERA citations track the reasoning path: which sub-query produced the evidence, which intermediate results informed the synthesis, and which source documents contributed to each claim.

This is important for our primary use cases. An analyst reviewing a CHIMERA-generated briefing needs to verify not just that a claim appears in a source document, but that the logical chain connecting multiple sources is sound.

03 — Evaluation

3.1 — Methodology

We evaluate on three benchmarks. CHIMERA-Bench is an internal benchmark of 2,400 multi-hop questions constructed from unclassified versions of real analyst workflows. HotpotQA and GPQA Diamond are public benchmarks included for external comparability.

Table 1 — Accuracy on evaluation benchmarks. CHIMERA uses ACX-Reason-70B as the base model. Competitor results use their respective APIs with equivalent RAG infrastructure where possible. GPQA results are close to GPT-4 — the difference is not statistically significant at our sample size.

3.2 — Failure Analysis

We manually reviewed 200 incorrect CHIMERA-Bench responses to identify failure patterns:

Temporal confusion is our largest failure mode and the one we consider most important to address. Many real-world analytical questions are inherently temporal ("How has X changed over time?"), and our current temporal reasoning capabilities are insufficient. This is an active area of research.

04 — Integration Patterns

4.1 — API Usage

CHIMERA is accessed through the AIC API. The interface is intentionally simple — a query string and an optional configuration object:

from aic import ChimeraClient

client = ChimeraClient(endpoint="https://aic.internal:8443")

result = client.query(
    question="Which vendors in our supply chain have had "
             "security incidents in the past 6 months?",
    sources=["vendor_docs", "security_reports", "contracts"],
    max_hops=3,
    require_citations=True
)

for claim in result.claims:
    print(f"{claim.text}")
    for cite in claim.citations:
        print(f"  └─ {cite.source} (confidence: {cite.score:.2f})")

4.2 — When Not to Use CHIMERA

CHIMERA adds latency (typically 3-8 seconds for multi-hop queries vs. sub-second for standard RAG) and consumes more compute. It should not be used for:

• Simple factual lookups answerable from a single document
• Real-time conversational interactions where latency matters
• Tasks requiring precise numerical computation (use SQL directly)
• Questions about information not present in the indexed corpus

05 — Conclusion

CHIMERA addresses a specific gap in current RAG systems: the ability to answer questions that span multiple data sources and require multi-step reasoning. It does this reasonably well for the analytical workflows we designed it for, and poorly for tasks outside that scope.

The system's primary value is not in the sophistication of any individual component — query decomposition, heterogeneous retrieval, and citation tracking are all well-studied problems — but in the integration of these components into a reliable, auditable pipeline suitable for high-stakes environments. Whether that integration constitutes a meaningful contribution or merely competent engineering is a judgment we leave to the reader.

References