Stop AI Hallucinations: Building Zero-Hallucination Inference Engines in TypeScript with json-rules-engine and N3

If you have spent any time building production applications with Large Language Models, you have likely hit the reliability wall. You prompt an LLM, tweak your system instructions, and carefully curate your few-shot examples. Everything looks pristine during local testing. Then, a user enters production edge cases, and your AI confidently hallucinates a compliance waiver, invents a pricing tier, or approves an unauthorized financial transaction.

The harsh reality of modern cognitive architectures is a fundamental dichotomy: Large Language Models excel at probabilistic pattern matching, but they fail at strict logic.

Probabilistic engines compute likelihood distributions over token vocabularies. Their outputs are educated guesses, not logical proofs. When your application demands absolute compliance, safety-critical business logic, multi-step logical deduction, or ironclad access control, stochastic neural architectures inevitably break down.

To solve this, we must look beyond the probabilistic paradigm and reintroduce deterministic reasoning. In this deep dive, we are going to build Rule-Based Inference Engines in TypeScript by combining json-rules-engine for lightning-fast procedural checks and the N3 Reasoner for semantic graph logic. By the end of this guide, you will know how to construct a neuro-symbolic pipeline that completely eliminates runtime hallucinations for safety-critical backend systems.

[The concepts and code demonstrated here are drawn directly from the comprehensive roadmap laid out in the book Generative Media & Visual Workflow Engines. Node-Based AI Canvases, Real-Time Media Streaming Pipelines, and WebGPU Processing in TypeScript, you can find it here. Check also the many other ebooks]

---

The What: Deconstructing Deterministic Inference Engines

A rule-based inference engine is a software system designed to execute computational reasoning by applying logical rules to a knowledge base. Unlike procedural code—where execution paths are hardcoded by developers inside deeply nested if/else statements—an inference engine completely decouples three distinct concerns:

1. The Working Memory (Fact Base): A dynamic repository of assertions, states, and objects representing the current state of the world. In our TypeScript stack, this maps directly to strongly typed JSON objects or RDF (Resource Description Framework) triples.
2. The Production Memory (Rule Base): A declarative collection of conditional statements, typically structured as IF-THEN blocks. These rules dictate how the system reacts when specific patterns are matched within working memory.
3. The Inference Engine (The Interpreter): The execution core that determines which rules are satisfied, resolves conflicts when multiple rules match, and executes corresponding actions through cycles like the Rete algorithm.

The Web Development Analogy

Think of a standard monolithic application with hardcoded business logic as a tangled client-side JavaScript bundle where routing, state management, and DOM rendering are permanently intertwined. When you inject an LLM into this messy monolith, it acts like an overzealous junior developer who dynamically rewrites UI components on the fly based purely on "conversational vibes."

Decoupling your application using a TypeScript rule-based inference engine is the architectural equivalent of adopting a Microservices Architecture with API Gateways and Strict Contract Testing. The LLM acts as the natural-language-driven API Gateway that parses unstructured human intent into structured parameters (utilizing advanced Tool Calling and Function Calling).

These structured parameters are then handed off to a downstream, highly specialized microservice—our deterministic inference engine—which enforces strict schema validation, security policies, and unbending business rules. If the parameters violate business invariants, the request is summarily rejected with a deterministic error code, leaving zero room for runtime hallucinations.

---

The Why: Eradicating Hallucinations Through Symbolic Grounding

Why must we bridge Large Language Models with symbolic inference engines? The answer lies in the fundamental math of vector spaces and continuous representations.

In modern AI systems, text is mapped into high-dimensional vector spaces using embedding models to compute cosine similarities and retrieve relevant context via vector databases. While this is exceptionally powerful for semantic search, vector embeddings are inherently lossy and continuous. They capture association and context, but they fail miserably at implication and negation.

An embedding model cannot mathematically prove that if $A \implies B$ and $B \implies C$ , then $A \implies C$ . It can only predict that the tokens for $A$ and $C$ frequently appear in similar paragraphs.

In financial compliance, medical diagnosis routing, legal contract verification, and multi-tenant authorization, a 99% accuracy rate is disastrous if that 1% failure rate triggers an illegal security breach or a multi-million-dollar compliance violation.

Symbolic reasoning systems are built entirely on formal logic and discrete mathematics. By coupling an LLM with a TypeScript-based inference engine, we achieve Symbolic Grounding. The LLM is strictly constrained to its domain of absolute competence—natural language understanding, entity extraction, and conversational formatting—while the inference engine assumes unyielding authority over state transitions, validation, and decision-making.

Furthermore, running these engines directly inside TypeScript environments bridges the gap between client-side intelligence and server-side determinism. Executing rule engines locally within Node.js or edge runtimes ensures zero network round-trip overhead, allowing applications to validate complex, multi-variable constraints instantaneously before committing state changes to a database or GraphDB.

---

Procedural vs. Semantic Reasoning: Choosing the Right Tool

To build an effective neuro-symbolic pipeline, we must understand the two primary flavors of rule-based inference engines we implement in TypeScript: Procedural Rule Engines and Semantic Web Reasoners.

1. Procedural Rule Engines (json-rules-engine)

Procedural rule engines are optimized for fast, deterministic evaluation of application-level business logic over structured JSON objects. They operate similarly to a high-performance decision tree or an event-processing pipeline.

Comparing this to web development, json-rules-engine is equivalent to a CSS Specificity and Cascade Engine combined with Form Validation Middleware. Just as CSS rules evaluate DOM elements against complex selectors and apply cascading styles deterministically, a procedural rule engine evaluates a set of facts (user profile, subscription tier, API usage) against a declarative JSON rule tree to trigger specific JavaScript callbacks.

The massive win for json-rules-engine in TypeScript is its serializability. Rules are defined as plain JSON, allowing them to be stored dynamically in a database, modified by administrators through a web dashboard, and evaluated at runtime without recompiling your TypeScript application.

2. Semantic Web Reasoners (N3 Reasoner and RDF Triples)

While procedural rule engines excel at application-level business logic, they struggle when dealing with complex, highly interconnected domain knowledge spanning disparate silos. This is where Semantic Web Reasoning and Knowledge Graphs shine.

In a semantic reasoning architecture, data is represented as RDF Triples containing a Subject, a Predicate, and an Object (e.g., [Patient-101, hasDiagnosis, Diabetes]). These triples form an interconnected web of semantic meaning anchored by formal ontologies like OWL (Web Ontology Language) and RDF Schema.

The N3 Reasoner (Notation 3 Reasoner) acts as a logical derivation engine operating over these RDF graphs. Unlike procedural engines that merely check matching conditions, a semantic reasoner can infer entirely new facts from existing facts using logical implication rules.

If a procedural rule engine is like a Static Route Matcher in an Express.js router, a Semantic Reasoner is like a Dependency Injection Container with Automatic Resolution. When you request a complex service, the DI container inspects type signatures, hierarchical inheritances, interface implementations, and transitive dependencies to prove the requested object graph is valid.

Similarly, if an N3 knowledge base contains the triples:

• Ex:Server-A ex:isDependentOn Ex:Database-Primary
• Ex:Database-Primary ex:status ex:Degraded

And the reasoner evaluates the logical rule:

$$\forall x, y \quad (\text{x} \text{ ex:isDependentOn } \text{ y}) \land (\text{y} \text{ ex:status } \text{ ex:Degraded}) \implies (\text{x} \text{ ex:requiresAttention } \text{ true})$$

The N3 Reasoner automatically computes and materializes the new triple:
[Ex:Server-A, ex:requiresAttention, true]

This newly inferred fact did not exist in the raw input data. It was derived purely through deterministic, logical deduction.

---

The Neuro-Symbolic Synthesis: Zero-Hallucination Architecture

When we synthesize procedural rule engines, semantic N3 reasoners, GraphDBs, and Large Language Models into a unified TypeScript architecture, we build a Neuro-Symbolic Zero-Hallucination Pipeline.

The workflow operates through a strict sequence of checks and balances:

1. User Interaction: The user submits a natural language request (e.g., "Can we upgrade user X to admin status and grant them access to the financial ledger?").
2. Stochastic Parsing (LLM & Tool Calling): The LLM intercepts the prompt. Instead of answering directly, the LLM invokes a structured tool call that extracts core entities: targetUser: "X", requestedRole: "Admin", targetResource: "FinancialLedger".
3. Ontological Grounding & Graph Querying: Extracted entities are passed to a GraphDB containing organizational ontologies to retrieve structural relationships and security clearances.
4. Semantic Reasoning (N3 Engine): The N3 Reasoner ingests graph data and applies formal security policies to evaluate whether the user logically satisfies required axioms.
5. Procedural Rule Execution (json-rules-engine): Once semantic validation passes, the procedural engine evaluates real-time business constraints (e.g., checking maintenance windows or suspension flags).
6. Execution or Rejection: Only if both the semantic reasoner and procedural engine return valid, mathematically proven affirmative results does the system execute the state change. Otherwise, it rejects the request with a deterministic audit log containing the exact rule violated.

---

Complete TypeScript Implementation: SaaS Entitlement & Access Engine

Below is a complete, self-contained TypeScript implementation that configures a runtime-validated evaluation context, executes a procedural rule engine using json-rules-engine, and bridges structural JSON facts into RDF triples processed via the N3 reasoner.

This code frames a SaaS access-control and automated billing entitlement engine, guaranteeing that enterprise tier upgrades, API credit allowances, and compliance checks are evaluated deterministically.

import { Engine, TopLevelCondition } from 'json-rules-engine';
import { Store, Parser, Writer, DataFactory } from 'n3';
import { z } from 'zod';

// Extract required factories for RDF manipulation
const { namedNode, literal, quad } = DataFactory;

/**
 * ============================================================================
 * 1. RUNTIME VALIDATION SCHEMAS (Zod)
 * ============================================================================
 * Runtime validation ensures data entering the inference boundary strictly 
 * conforms to expected business shapes, mitigating injection attacks and malformed states.
 */
const TenantContextSchema = z.object({
  tenantId: z.string().uuid(),
  tier: z.enum(['FREE', 'PRO', 'ENTERPRISE']),
  monthlyActiveUsers: z.number().int().nonnegative(),
  apiCallsMade: z.number().int().nonnegative(),
  featureFlags: z.array(z.string()),
  securityComplianceAttested: z.boolean(),
});

type TenantContext = z.infer<typeof TenantContextSchema>;

/**
 * ============================================================================
 * 2. DETERMINISTIC ENGINE SETUP (json-rules-engine)
 * ============================================================================
 * Construct a procedural rule engine instance using plain JSON objects.
 */
const proceduralEngine = new Engine();

// Rule: Enterprise tenants exceeding baseline API calls require an audit log flag
proceduralEngine.addRule({
  name: 'enterprise-audit-requirement',
  conditions: {
    all: [
      {
        fact: 'tier',
        operator: 'equal',
        value: 'ENTERPRISE',
      },
      {
        fact: 'apiCallsMade',
        operator: 'greaterThan',
        value: 100000,
      },
    ],
  },
  event: {
    type: 'trigger-security-audit',
    params: {
      severity: 'HIGH',
      message: 'Enterprise usage threshold exceeded; mandatory compliance audit triggered.',
    },
  },
});

// Rule: Non-enterprise accounts exceeding MAU limits must be rate-limited
proceduralEngine.addRule({
  name: 'enforce-mau-rate-limit',
  conditions: {
    all: [
      {
        fact: 'tier',
        operator: 'notEqual',
        value: 'ENTERPRISE',
      },
      {
        fact: 'monthlyActiveUsers',
        operator: 'greaterThan',
        value: 5000,
      },
    ],
  },
  event: {
    type: 'apply-rate-limiting',
    params: {
      action: 'THROTTLE',
      retryAfterSeconds: 3600,
    },
  },
});

/**
 * ============================================================================
 * 3. SEMANTIC RDF REASONER SETUP (N3.js)
 * ============================================================================
 * Instantiate an N3 quad store to process deterministic semantic triples and infer 
 * hierarchical relationships.
 */
const n3Store = new Store();

const saasNS = 'http://api.saas-platform.io/ontology#';
const tenantNS = 'http://api.saas-platform.io/tenant/';

function initializeOntology(tenantId: string, tier: string, securityAttested: boolean) {
  n3Store.addQuad(
    namedNode(`${saasNS}EnterpriseTier`),
    namedNode(`${saasNS}impliesRegulation`),
    namedNode(`${saasNS}HIPAACompliant`)
  );

  n3Store.addQuad(
    namedNode(`{% katex inline %}{tenantNS}{% endkatex %}{tenantId}`),
    namedNode('http://www.w3.org/1999/02/22-rdf-syntax-ns#type'),
    namedNode(`{% katex inline %}{saasNS}{% endkatex %}{tier}Tier`)
  );

  n3Store.addQuad(
    namedNode(`{% katex inline %}{tenantNS}{% endkatex %}{tenantId}`),
    namedNode(`${saasNS}securityAttested`),
    literal(securityAttested.toString(), namedNode('http://www.w3.org/2001/XMLSchema#boolean'))
  );
}

function executeSemanticInference(tenantId: string) {
  const tenantNode = namedNode(`{% katex inline %}{tenantNS}{% endkatex %}{tenantId}`);
  const enterpriseTypeNode = namedNode(`${saasNS}ENTERPRISETier`);
  const typeProperty = namedNode('http://www.w3.org/1999/02/22-rdf-syntax-ns#type');

  const hasEnterpriseType = n3Store.getQuads(tenantNode, typeProperty, enterpriseTypeNode, null).length > 0;

  if (hasEnterpriseType) {
    n3Store.addQuad(
      tenantNode,
      namedNode(`${saasNS}grantsEntitlement`),
      namedNode(`${saasNS}MasterEncryptionKeyAccess`)
    );
  }
}

/**
 * ============================================================================
 * 4. UNIFIED NEURO-SYMBOLIC PIPELINE EXECUTION
 * ============================================================================
 */
async function evaluateTenantPolicies(rawInput: unknown): Promise<{
  proceduralEvents: Array<{ type: string; params: Record<string, any> }>;
  semanticTriples: string[];
}> {
  const validationResult = TenantContextSchema.safeParse(rawInput);

  if (!validationResult.success) {
    throw new Error(`Tenant context validation failed: ${JSON.stringify(validationResult.error.format())}`);
  }

  const tenant = validationResult.data;

  const facts = {
    tier: tenant.tier,
    monthlyActiveUsers: tenant.monthlyActiveUsers,
    apiCallsMade: tenant.apiCallsMade,
  };

  const proceduralResults = await proceduralEngine.run(facts);
  const triggeredEvents = proceduralResults.events.map(event => ({
    type: event.type,
    params: event.params || {},
  }));

  initializeOntology(tenant.tenantId, tenant.tier, tenant.securityComplianceAttested);
  executeSemanticInference(tenant.tenantId);

  const quads = n3Store.getQuads(null, null, null, null);
  const writer = new Writer();
  const serializedTriples: string[] = [];

  writer.addQuads(quads);
  writer.end((error, result) => {
    if (!error && result) {
      serializedTriples.push(...result.trim().split('\n'));
    }
  });

  return {
    proceduralEvents: triggeredEvents,
    semanticTriples: serializedTriples,
  };
}

// ============================================================================
// 5. EXAMPLE USAGE / INVOCATION
// ============================================================================
async function runDemo() {
  const samplePayload = {
    tenantId: 'a0eebc99-9c0b-4ef8-bb6d-6bb9bd380a11',
    tier: 'ENTERPRISE',
    monthlyActiveUsers: 12500,
    apiCallsMade: 150000,
    featureFlags: ['beta-ai-agents', 'custom-domains'],
    securityComplianceAttested: true,
  };

  try {
    console.log('Evaluating Zero-Hallucination Pipeline...');
    const result = await evaluateTenantPolicies(samplePayload);

    console.log('\n--- Procedural Rule Engine Events ---');
    console.dir(result.proceduralEvents, { depth: null });

    console.log('\n--- Semantic RDF Reasoner Triples (Inferred World State) ---');
    result.semanticTriples.forEach(triple => console.log(triple));

  } catch (error) {
    console.error('Pipeline Evaluation Error:', error);
  }
}

runDemo();

---

Line-by-Line Code Breakdown

1. Imports and Factory Setup: We import Engine from json-rules-engine, graph storage modules from N3, and runtime validation utilities from Zod. We destructure RDF creation helpers (namedNode, literal, quad) directly from DataFactory.
2. Zod Boundary Enforcement: The TenantContextSchema ensures runtime type safety. Because TypeScript interfaces disappear at compile time, Zod guarantees that runtime payloads are sanitized before hitting our rule engine.
3. Procedural Rule Definitions: We instantiate json-rules-engine and register our declarative rules (enterprise-audit-requirement and enforce-mau-rate-limit), keeping business logic completely isolated from neural network inference.
4. Semantic Triple Store & Forward Chaining: Using N3.Store, we initialize ontological axioms (e.g., Enterprise tier implies regulation status) and use procedural checks (executeSemanticInference) to dynamically materialize new triples like master key access entitlements.
5. Pipeline Orchestration: The evaluateTenantPolicies function acts as our master gateway, validating payloads, executing procedural evaluations, running semantic reasoning, and returning an auditable state payload.

---

Conclusion

By mastering the integration of json-rules-engine, N3 Reasoners, and TypeScript-based semantic architectures, software engineers can finally transcend the limitations of probabilistic AI.

We move away from fragile prompt-engineered heuristics and embrace robust, verifiable, neuro-symbolic systems. This approach ensures that as enterprise AI applications scale to handle complex workflows, their core decisions remain transparent, completely deterministic, and entirely immune to hallucinations.

The concepts and code demonstrated here are drawn directly from the comprehensive roadmap laid out in the book Neuro-Symbolic AI & Knowledge Graphs, you can find it here. Check also the many other ebooks.