rust-kgdb 0.6.82 → 0.6.84

package/README.md

@@ -4,7 +4,9 @@
 [![License](https://img.shields.io/badge/License-Apache%202.0-blue.svg)](https://opensource.org/licenses/Apache-2.0)
 [![W3C](https://img.shields.io/badge/W3C-SPARQL%201.1%20%7C%20RDF%201.2-blue)](https://www.w3.org/TR/sparql11-query/)
 
-> **Enterprise Knowledge Graph with Native Graph Embeddings**: A production-grade RDF database featuring built-in RDF2Vec, multi-vector composite search, and distributed SPARQL execution—engineered for teams who need verifiable AI at scale.
+> **Your knowledge is scattered. Your claims live in Snowflake. Your customer graph sits in Neo4j. Your risk models run on BigQuery. Your compliance docs are in SharePoint. And your AI? It hallucinates because it can't see the full picture.**
+>
+> rust-kgdb unifies scattered enterprise knowledge into a single queryable graph—with native embeddings, cross-database federation, and AI that generates queries instead of fabricating answers. No hallucinations. Full audit trails. One query across everything.
 
 ---
 
@@ -54,21 +56,35 @@ const { GraphDB, Rdf2VecEngine, EmbeddingService } = require('rust-kgdb')
 
 ## The Problem With AI Today
 
-Enterprise AI projects keep failing. Not because the technology is bad, but because organizations use it wrong.
+**Here's what actually happens in every enterprise AI project:**
 
-A claims investigator asks ChatGPT: *"Has Provider #4521 shown suspicious billing patterns?"*
+Your fraud analyst asks a simple question: *"Show me high-risk customers with large account balances who've had claims in the past 6 months."*
 
-The AI responds confidently: *"Yes, Provider #4521 has a history of duplicate billing and upcoding."*
+Sounds simple. It's not.
 
-The investigator opens a case. Weeks later, legal discovers Provider #4521 has a perfect record. **The AI made it up.** Lawsuit incoming.
+The **customer data** lives in Snowflake. The **risk scores** are computed in your knowledge graph. The **claims history** sits in BigQuery. The **policy details** are in a legacy Oracle database. And **nobody can write a query that spans all four**.
 
-This keeps happening:
+So the analyst does what everyone does:
+1. Export customers from Snowflake to CSV
+2. Run a separate risk query in the graph database
+3. Pull claims from BigQuery into another spreadsheet
+4. Spend 3 hours in Excel doing VLOOKUP joins
+5. Present "findings" that are already 6 hours stale
+
+**This is the reality of enterprise data in 2025.** Knowledge is scattered across dozens of systems. Every "simple" question requires a data engineering project. And when you finally get your answer, you can't trace how it was derived.
+
+Now add AI to this mess.
+
+Your analyst asks ChatGPT the same question. It responds confidently: *"Customer #4521 is high-risk with $847,000 in account balance and 3 recent claims."*
+
+The analyst opens an investigation. Two weeks later, legal discovers Customer #4521 doesn't exist. **The AI made up everything—the customer ID, the balance, the claims.** The AI had no access to your data. It just generated plausible-sounding text.
 
-- A lawyer cites "Smith v. Johnson (2019)" in court. The judge is confused. **That case doesn't exist.**
-- A doctor avoids prescribing "Nexapril" due to cardiac interactions. **Nexapril isn't a real drug.**
+This keeps happening:
+- A lawyer cites "Smith v. Johnson (2019)" in court. **That case doesn't exist.**
+- A doctor avoids prescribing "Nexapril" for cardiac patients. **Nexapril isn't a real drug.**
 - A fraud analyst flags Account #7842 for money laundering. **It belongs to a children's charity.**
 
-Every time, the same pattern: The AI sounds confident. The AI is wrong. People get hurt.
+Every time, the same pattern: Data is scattered. AI can't see it. AI fabricates. People get hurt.
 
 ---
 
@@ -91,29 +107,46 @@ A real solution requires a different architecture. One built on solid engineerin
 
 ## The Solution: Query Generation, Not Answer Generation
 
-What if AI stopped providing answers and started **generating queries**?
+What if we're thinking about AI wrong?
+
+Every enterprise wants the same thing: ask a question in plain English, get an accurate answer from their data. But we've been trying to make the AI *know* the answer. That's backwards.
+
+**The AI doesn't need to know anything. It just needs to know how to ask.**
+
+Think about what's actually happening when a fraud analyst asks: *"Show me high-risk customers with large balances."*
 
-Think about it:
-- Your database knows the facts (claims, providers, transactions)
-- AI understands language (can parse "find suspicious patterns")
-- You need both working together
+The analyst already has everything needed to answer this question:
+- Customer data in Snowflake
+- Risk scores in the knowledge graph
+- Account balances in the core banking system
+- Complete audit logs of every transaction
 
-**The AI translates intent into queries. The database finds facts. The AI never makes up data.**
+The problem isn't missing data. It's that **no human can write a query that spans all these systems**. SQL doesn't work on graphs. SPARQL doesn't work on Snowflake. And nobody has 4 hours to manually join CSVs.
+
+**The breakthrough**: What if AI generated the query instead of the answer?
 
 ```
-Before (Dangerous):
-  Human: "Is Provider #4521 suspicious?"
-  AI: "Yes, they have billing anomalies"      <-- FABRICATED
+The Old Way (Dangerous):
+  Human: "Show me high-risk customers with large balances"
+  AI: "Customer #4521 has $847K and high risk score"     <-- FABRICATED
+
+The New Way (Verifiable):
+  Human: "Show me high-risk customers with large balances"
+  AI: Understands intent → Generates federated SQL:
+
+      SELECT kg.customer, kg.risk_score, sf.balance
+      FROM graph_search('...risk assessment...') kg
+      JOIN snowflake.ACCOUNTS sf ON kg.customer_id = sf.id
+      WHERE kg.risk_score > 0.8 AND sf.balance > 100000
 
-After (Safe):
-  Human: "Is Provider #4521 suspicious?"
-  AI: Generates SPARQL query
-  AI: Executes against YOUR database
-  Database: Returns actual facts about Provider #4521
-  Result: Real data with audit trail          <-- VERIFIABLE
+  Database: Executes across KGDB + Snowflake + BigQuery
+  Result: Real customers. Real balances. Real risk scores.
+          With SHA-256 proof hash for audit trail.          <-- VERIFIABLE
 ```
 
-rust-kgdb is a knowledge graph database with an AI layer that **cannot hallucinate** because it only returns data from your actual systems.
+The AI never touches your data. It translates human language into precise queries. The database executes against real systems. Every answer traces back to actual records.
+
+**rust-kgdb is not an AI that knows answers. It's an AI that knows how to ask the right questions—across every system where your knowledge lives.**
 
 ---
 
@@ -149,18 +182,29 @@ The math matters. When your fraud detection runs 35x faster, you catch fraud bef
 
 ## Why rust-kgdb and HyperMind?
 
-Most AI frameworks trust the LLM. We don't.
+**The question isn't "Can AI answer my question?" It's "Can I trust the answer?"**
+
+Every AI framework makes the same mistake: they treat the LLM as the source of truth. LangChain. LlamaIndex. AutoGPT. They all assume the model knows things. It doesn't. It generates plausible text. There's a difference.
+
+We built rust-kgdb on a contrarian principle: **Never trust the AI. Verify everything.**
+
+The LLM proposes a query. The type system validates it against your actual schema. The sandbox executes it in isolation. The database returns only facts that exist. The proof DAG creates a cryptographic audit trail.
+
+At no point does the AI "know" anything. It's a translator—from human intent to precise queries—with four layers of verification before anything touches your data.
+
+**This is the difference between an AI that sounds right and an AI that is right.**
 
-### Core Capabilities
+### The Engineering Foundation
 
-| Layer | Feature | What It Does |
-|-------|---------|--------------|
-| **Database** | GraphDB | W3C SPARQL 1.1 compliant RDF store with 449ns lookups |
+| Layer | Component | What It Does |
+|-------|-----------|--------------|
+| **Database** | GraphDB | W3C SPARQL 1.1 compliant RDF store, 449ns lookups, 35x faster than RDFox |
 | **Database** | Distributed SPARQL | HDRF partitioning across Kubernetes executors |
-| **Embeddings** | Rdf2VecEngine | Train 384-dim vectors from graph random walks |
+| **Federation** | HyperFederate | Cross-database SQL: KGDB + Snowflake + BigQuery in single query |
+| **Embeddings** | Rdf2VecEngine | Train 384-dim vectors from graph random walks, 68µs lookup |
 | **Embeddings** | EmbeddingService | Multi-provider composite vectors with RRF fusion |
 | **Embeddings** | HNSW Index | Approximate nearest neighbor search in 303µs |
-| **Analytics** | GraphFrames | PageRank, connected components, motif matching |
+| **Analytics** | GraphFrames | PageRank, connected components, triangle count, motif matching |
 | **Analytics** | Pregel API | Bulk synchronous parallel graph algorithms |
 | **Reasoning** | Datalog Engine | Recursive rule evaluation with fixpoint semantics |
 | **AI Agent** | HyperMindAgent | Schema-aware SPARQL generation from natural language |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "rust-kgdb",
-  "version": "0.6.82",
+  "version": "0.6.84",
   "description": "High-performance RDF/SPARQL database with AI agent framework. GraphDB (449ns lookups, 35x faster than RDFox), GraphFrames analytics (PageRank, motifs), Datalog reasoning, HNSW vector embeddings. HyperMindAgent for schema-aware query generation with audit trails. W3C SPARQL 1.1 compliant. Native performance via Rust + NAPI-RS.",
   "main": "index.js",
   "types": "index.d.ts",