Dual-Engine ArchitectureWhite Paper #SC052726-0003

Beyond Probabilistic Mathematics

Integrating Small Language Models (SLMs) with Deterministic Financial Computing Engines

Authors: Subhashish (Sub) Samaddar, Ph.D.; Ravi Periasamy; Shyam Dasri, DBA
Institution: SigmaCore.AI, Atlanta, GA

Executive Summary

The reliance on Large Language Models (LLMs) for quantitative financial reporting introduces unacceptable operational, legal, and systemic risk (pp. 1-2). Because generative transformers operate on probabilistic token prediction rather than arithmetic computation, they are natively incapable of guaranteeing numerical accuracy (pp. 1, 3). To bridge the gap between human-centric narrative synthesis and zero-error corporate finance, a new paradigm is required. This paper details a dual-engine architecture: an immutable, deterministic computation engine combined with a highly specialized Small Language Model (SLM). By offloading numerical processing to symbolic math registries and restricting the SLM strictly to contextual, semantic translation, this architecture completely eliminates financial hallucinations (pp. 2-3).


1. The Architecture of the Dual-Engine System

To build a hallucination-free financial intelligence system, software design must move from a single, monolithic language processor to a bifurcated, asynchronous architecture. This system splits enterprise tasks into two distinct workloads: Probabilistic (semantic interpretation) and deterministic (mathematical processing).

The Orchestration Layer and Abstract Syntax Trees (AST)

When an analyst inputs a complex prompt, the request does not pass directly to a text generator. Instead, it enters an orchestration layer that converts the input into an Abstract Syntax Tree (AST).

The AST acts as a traffic controller:

  • It identifies all variables, accounting formulas, and database endpoints.
  • It completely strips the core mathematical instructions out of the natural language payload.
  • It routes the mathematical instructions to the deterministic engine while passing the structural metadata to the SLM.

2. The Deterministic Engine: Hardcoded Accuracy

The mathematical engine is entirely non-probabilistic.

  • Symbolic Mathematics and Exact Precision: Unlike transformers, which fragment digits into arbitrary tokens (pp. 1, 3), the deterministic engine relies on exact fixed-point or symbolic math libraries.
  • Immutable Registries: Formulas for Financial Planning and Analysis (FP&A), return metrics (ROI), and GAAP accounting rules are immutable, compiled code blocks (pp. 1, 3).
  • Database Ground Truth: Calculations pull real-time numbers directly from corporate ERP systems via strict SQL schemas or validated GraphQL APIs, ensuring there is zero opportunity to "invent" a transaction or round decimals based on statistical probability (pp. 1, 4).

3. The Small Language Model (SLM): Targeted Semantic Mapping

This architecture deploys a highly compact, domain-specific SLM (typically between 1 billion and 7 billion parameters).

  • Specialization Over Scale: The SLM is fine-tuned strictly on corporate financial dictionaries, SEC disclosures, accounting terminology, and corporate reporting styles.
  • Semantic Mapping, Not Arithmetic Execution: The fundamental rule of this integration is that the SLM is mathematically blind; it is never allowed to generate a digit. Instead, it generates variable tokens or placeholders, handling the structural buildup while remaining detached from calculating the values (p. 2).

4. The Compilation Layer: Merging Words and Numbers

The final stage of the pipeline is the compilation layer, where narrative outputs and numerical values are securely locked together. Because the narrative layout and the numerical values travel on entirely separate tracks, a calculation error is architecturally impossible (p. 2). If the deterministic engine encounters broken logic, the system halts execution rather than outputting a plausible-sounding guess (p. 1).

5. Why This Architecture Defeats the "Titanic Flaw"

The SLM+Deterministic engine framework solves the underlying crisis by addressing the physics of the system:

  • Elimination of Tokenization Errors: Digits are sent straight to database registries as integers and decimals, making transformer tokenization flaws irrelevant (pp. 3-4).
  • Halting Autoregressive Decay: Numerical placeholders are populated instantly from a single, verified database lookup, destroying the error cascade entirely (p. 4).
  • Auditability and the "Paper Trail": Every number printed points directly back to an executed database script or verified arithmetic formula, allowing auditors to trace the absolute provenance of every data point (p. 1).

6. Strategic Implications for Next-Generation Enterprise Software

The current enterprise landscape is flooded with legacy vendors adding superficial AI chat boxes without guaranteeing data integrity (pp. 2-3). Corporate America must migrate toward purpose-built architectures that utilize this dual-engine design to protect balance sheets and satisfy regulatory scrutiny (pp. 1-3).