Module · Private Vault

A private knowledge graph queried by a foundation model that the customer owns outright.

Vault is the consolidated retrieval and generation layer of the Intelligine platform, in which customer proprietary documents, customer databases, and customer application programming interfaces are ingested into a private knowledge graph, and every natural language answer is produced by a foundation model that has been trained from scratch on the customer corpus and formally handed over to the customer engineering organization on the 30th calendar day of the engagement.

CUSTOMER KNOWLEDGE GRAPH · TENANT 042
PRIVATE
MODELPOLICYOBLIGORMEMOTRADEDESK
A private knowledge graph rather than a flat vector store

Documents, entities, relationships, and access policy modeled in one graph that is queried by the customer-owned model.

Vault constructs a tenant-scoped knowledge graph in which every document, every named entity, every relationship between entities, and every access control policy is explicitly modeled, and the customer private model is trained against that graph rather than against a flat collection of embedded passages, with the result that the model reasons over the structure of the customer organization rather than only over the surface text of customer documents.

  • A typed knowledge graph in which entities, relationships, and access control policies are first-class citizens rather than free-text fields
  • Foundation model trained from scratch on the customer corpus and the customer knowledge graph, with full customer access to model weights, embedding model, and tokenizer
  • No application programming interface dependency back to Intelligine and no shared training infrastructure between customers
Citation-bound retrieval over the graph

Every answer is traceable back to a node, an edge, and a permitted source document.

When a customer user submits a natural language question, Vault traverses the customer knowledge graph using the customer private model, returns an answer bound to citations that name the source document, the relevant paragraph, and the timestamp at which the source was last revised, and respects the customer existing access control list configuration so that each user observes only the subset of the graph that the customer has already permitted them to see.

  • More than 60 enterprise source connectors covering Microsoft SharePoint, Amazon Simple Storage Service, Atlassian Confluence, customer databases, and customer application programming interfaces
  • Citation-bound responses with paragraph-level attribution, document timestamp, and policy classification surfaced on every output
  • Per-user retrieval that respects the customer existing access control list configuration and the customer information barrier rules
  • Persistent contextual memory shared across sessions, across users, and across long-running customer agents
Query against the customer knowledge graph
“What are the customer exposure limits for energy sector counterparties, and on what date were they last revised?”
Answer (generated by the customer private model)
Energy sector single-name exposure is capped at $85M, and Tier-1 obligor limits were revised on 14 March 2024 after the first quarter risk review.
📄 Risk-Policy-v4.2.pdf · paragraph 17📊 Q1-Review-2024.xlsx · row 42🔗 graph edge · POLICY ↔ OBLIGOR
Engagement process for the customer-owned model

4 sequential phases between customer data and a customer-owned trained model that operates over the customer knowledge graph.

01

Discovery and scoping

Confirmation of customer data sources, customer engagement domain, and customer success criteria, with an architecture review attended by the customer chief information security officer and chief information officer.

02

Data curation and graph construction

Cleaning and labeling of customer proprietary datasets and construction of the tenant-scoped customer knowledge graph, with a documented audit trail covering every individual document that enters the corpus.

03

Foundation training and graph fine-tuning

Foundation model training and subsequent fine-tuning of the model against the customer knowledge graph, executed on graphical processing units that sit inside the customer cloud account.

04

Handover to the customer engineering team

Trained model weights, supporting runtime, embedding model, customer-specific tokenizer, and operating runbook handed over to the customer engineering organization on the 30th calendar day of the engagement.

Operating guarantees

Engineered for privileged customer information.

/01

Customer information remains inside the customer environment

All ingestion, graph construction, training, and inference operations are performed inside the customer virtual private cloud, customer on-premises data center, or customer air-gapped environment, and customer data never crosses the customer-defined network boundary.

/02

Bound to citations and graph edges

Every factual statement returned by the customer private model is traced back to a specific source document and a specific edge in the customer knowledge graph, and unsourced output is filtered out of the response before it reaches the customer user.

/03

Customer ownership of trained weights and the knowledge graph

The customer retains full ownership of the trained model weights, the embedding model, the customer-specific tokenizer, and the customer knowledge graph, with no recurring application programming interface dependency back to Intelligine infrastructure.

Begin owning the customer knowledge graph and the model that queries it.

A discovery call between the customer technology leadership and an Intelligine architect produces a documented scope for the Vault engagement within two conversations, including a documented mapping between customer source systems and the proposed tenant-scoped customer knowledge graph.