Why Semantic Similarity Isn't Governing Precedence: What Makes KruschBiz Different From Generic Business RAG

1. The Four Fatal Traps of Naive "Business RAG"

In customer support, internal wikis, or general knowledge search, a naive Retrieval-Augmented Generation (RAG) pipeline works passably well: slice text into 500-token blocks, compute dense embeddings, retrieve nearest neighbors by cosine similarity, and ask an LLM to synthesize an answer.

When applied to commercial contracts, this architecture collapses. Here is why:

Trap 1: The Amendment Blindspot (Temporal Inversion)

Commercial relationships evolve as a directed hierarchy of legal instruments: Master Services Agreements (MSAs), Statements of Work (SOWs), and Amendments. Dense vector embeddings measure semantic volume and lexical resonance, not binding legal status.

An original 2021 Master Agreement often contains four verbose paragraphs detailing invoicing mechanics, disputed charges, and a "Net 60" payment term. In 2025, the parties sign a one-sentence Amendment: "Section 6.1 is hereby amended to replace Net 60 with Net 30."

When an analyst queries the vector database for "Acme payment terms," the 2021 clause easily wins the cosine similarity rank because it contains significantly more vocabulary related to commercial payments. The 2025 amendment is starved out of the context window. The LLM writes a confident briefing stating the firm has 60 days to pay—exposing the company to breach of contract.

Trap 2: Arbitrary Token Slicing & Amputated Carve-Outs

Generic RAG splits documents every 512 tokens using character splitters. Contracts are not written in arbitrary token chunks; they are written in interdependent clauses, conditional exceptions, and carve-outs.

When a fixed-window splitter cuts across a limitation of liability clause, Chunk A gets the general monetary cap ($1,000,000), while Chunk B gets the carve-outs ("The limitations in Section 11.1 shall not apply to breaches of confidentiality, gross negligence, or indemnification obligations"). If only Chunk A is retrieved, the LLM tells executive leadership that liability is strictly capped, missing the uncapped risk entirely.

Trap 3: Numerical & Slot Blindness in High-Dimensional Space

Dense embeddings compress sentence semantics into vector space. In dense vector space, these two sentences:

• "Payment shall be remitted within thirty (30) days (Net 30)"
• "Payment shall be remitted within sixty (60) days (Net 60)"

...have a cosine similarity score exceeding 0.96. To an embedding model, they express the identical conceptual thought. But to a CFO managing working capital across a $50M vendor portfolio, the difference between Net 30 and Net 60 is existential. Flat vector search cannot ensure that the correct numeric slot wins.

Trap 4: Hallucinated Provenance and the "Confident Brief"

Standard generative models optimize for plausible sentence flow. When asked to synthesize multi-party obligations, they routinely invent section numbers (citing "Section 14.2" in an agreement that ends at Section 10) or attribute obligations to the wrong counterparty. Without an external, deterministic proposition verification scanner, these errors enter executive decision workflows unnoticed.

2. The KruschBiz Architecture: 6 Structural Differentiators

KruschBiz treats contracts not as strings in vector space, but as an authoritative, typed relational graph of legal instruments, clause nodes, and quantitative slots.

Pillar 1: Relational Contract Graph & Graph Walk (resolve_controlling_clause)

Instead of flat embedding tables, KruschBiz introduces relational schemas in PostgreSQL 16:

• Instruments (agreements): Counterparty, execution date, effective date, expiration date, and governing law.
• Clauses (clauses): Explicit section identifiers, page coordinates, verbatim text, and canonical topic doctrine.
• Typed Relation Edges (agreement_relations): Explicit directional links: AMENDS, SUPERSEDES, INCORPORATES, SCHEDULE_OF, and CARVES_OUT.

When answering a query, KruschBiz executes a graph walk via resolve_controlling_clause(counterparty, topic, as_of_date). The engine discovers active root instruments, traces amendment chains chronologically as of the target date, and pinpoints the single terminal controlling clause.

Pillar 2: Ensemble Tagging & Exact Slot Boosting

To prevent numerical blindness, KruschBiz routes every document chunk through an Ensemble Tagging Pipeline (src/backend/tagger.py):

• Deterministic Regex Extraction: High-precision patterns extract rigid quantitative metrics: net-30, net-60, uptime-99.9pct, cap-12mo, sec-12.4.
• Local LLM Semantic Extraction: Local open-weight models (qwen2.5-coder:7b via Ollama) extract 3–5 conceptual domain tags and a 1-sentence micro-digest.
• Ensemble Union: Quantitative slots and semantic concepts are merged into an indexed metadata array.

During retrieval, KruschBiz combines dense vector similarity (bge-large, 1024-dim) with BM25 lexical ranking via Reciprocal Rank Fusion (RRF), applying an algorithmic +20% score boost when candidate chunk tags match the query slots. The quantitative commitments are never lost in vector space.

Pillar 3: The 13 Canonical Commercial Doctrines

Rather than allowing arbitrary prompt-time topic generation, KruschBiz maps every clause into a closed taxonomy of 13 Canonical Commercial Doctrines:

Structured slots (net_days, uptime_pct, late_interest_pct, cap_period_months) are stored in dedicated JSON columns, allowing deterministic SQL pre-filtering before vector ranking takes place.

Pillar 4: Assertion-Level Proposition Grounding Scanner

In KruschBiz, LLM generation is never delivered directly to human decision-makers. Every generated brief, memo, or contract audit is submitted to an automated Assertion Grounding Scanner.

The scanner decomposes the generated text into atomic propositions and audits each claim against the retrieved authorities using span overlap and slot value assertion, classifying them into a strict 4-Way Failure Taxonomy:

Pillar 5: Fail-Closed Agent Refusal Gates

Generic RAG suffers from "pleaser syndrome"—generating answers even when no authorities exist. KruschBiz enforces hardcoded, fail-closed refusal invariants:

• CANNOT_DRAFT_WITHOUT_AUTHORITIES: Refuses drafting when zero relevant governing agreements exist in the graph.
• REFUSAL_ALL_AUTHORITIES_SUPERSEDED: Refuses drafting if all retrieved authorities are expired, terminated, or superseded.

Pillar 6: Complete Air-Gapped Sovereignty & 6-Tool Canonical MCP Standard

In M&A transactions, confidential deal exhibits, executive compensation structures, and customer lists must never touch multi-tenant cloud APIs.

• Air-Gapped Loopback: Binds strictly to 127.0.0.1:8086 and 127.0.0.1:8506. No telemetry, no external calls.
• Sovereign PostgreSQL 16: Vector store (pgvector) and relational graphs run on-premise at port 5436.
• Anti-Tool-Bloat MCP Server: Standardizes tool exposure to strictly 6 canonical tools (~950 prompt tokens vs ~3,500 tokens of 16 legacy tools), protecting local 7B/14B models from context exhaustion while maintaining backwards-compatible routing.

3. Side-by-Side Comparison: Generic RAG vs. KruschBiz

4. Architectural Case Study: The M&A Diligence Test

Consider an M&A diligence audit where a buyer is evaluating the indemnification liability of an acquisition target:

Document History in Deal Room:
1. 2020 Master Agreement: Section 12 (Indemnity capped at $10,000,000; IP claims uncapped)
2. 2022 Amendment No. 1: Section 4 (Amends Section 12 to add Data Breach indemnification)
3. 2024 Amendment No. 2: Section 2 (Replaces Section 12 entirely; aggregate liability capped at $2,000,000)

What Happens in Generic RAG:

The analyst asks: "What is our indemnification cap for IP and data breaches?" The vector DB retrieves Section 12 of the 2020 Master Agreement because it contains 1,200 words discussing IP indemnification, whereas 2024 Amendment No. 2 is only 150 words. The LLM reads the 2020 clause and answers: "IP indemnification is uncapped, and general indemnity is capped at $10,000,000." The buyer miscalculates the target's contractual exposure by $8,000,000.

What Happens in KruschBiz:

The query triggers resolve_controlling_clause(counterparty="Acme", topic="INDEMNITY", as_of_date="2026-09-24"):

1. The graph walk discovers the 2020 Master Agreement root.
2. Follows the AMENDS edge to 2022 Amendment No. 1.
3. Follows the SUPERSEDES edge to 2024 Amendment No. 2, terminating at Section 2.
4. Retrieves the 2024 clause and its structured slots (cap_amount: $2,000,000).
5. The Assertion Grounding Scanner verifies that every sentence in the brief cites Amendment No. 2, confirming a verified text span.

The brief outputs with mathematical certainty: "As of September 24, 2026, Section 12 is governed by Amendment No. 2, establishing an aggregate indemnity cap of $2,000,000."

5. Conclusion: From Probabilities to Deterministic Governance

Generic RAG treats every enterprise document as an unstructured bag of words floating in high-dimensional probability space. That model is fine for customer service bots or conversational assistants.

It is unacceptable for corporate governance and commercial transactions.

Contracts are legal code. Like compiled software, they have parent-child dependencies, variable definitions, conditional branches, and override flags. You cannot understand software by taking a random cosine similarity of a GitHub repo; you must parse the Abstract Syntax Tree and walk the dependency graph.

KruschBiz brings AST-level rigor to corporate contracting. By uniting relational contract graphs, deterministic slot anchoring, and proposition-level assertion scanners within a completely sovereign on-premise architecture, KruschBiz provides what generic business RAG never could: an evidentiary guarantee that what the AI reports is what the contract actually governs.