How Persistent Semantic Memory™ forms a High-Resolution Memory Model of the Enterprise

Abstract

The Enterprise Intelligence Engine™ creates and continuously maintains a Persistent Semantic Memory™: a 10K High Definition Memory Model of an organization’s connected knowledge. The EIE enriches every knowledge object with concepts, temporal context, authority, trust, resolved entities, domain-specific schemas, relationships, permissions, provenance, and supporting evidence. The PSM stores this context so it can be reused consistently across AI agents, conversational AI, enterprise applications, and higher-level reasoning modules.

This architecture provides more detail than traditional knowledge graphs while reducing the upfront modeling and maintenance required by ontology-first approaches. Instead of reconstructing context from a small set of retrieved documents for every request, the EIE reasons from persistent organizational memory, then verifies its conclusions against the underlying evidence. In Bloomfire testing against the same queries and knowledge base, this approach used an average of 940 tokens per query compared with 6,750 for a tuned RAG system—an 86% reduction. The result is more governed, efficient, and transparent enterprise AI, with confidence scores that make clear when the available knowledge is strong, incomplete, or conflicting.

How Better Context and Governance Fixes AI Outcomes

Enterprise AI does not fail solely because of limitations in the language model. It fails when the model lacks the context needed to distinguish an authoritative policy from a passing comment, current guidance from historical information, or demonstrated expertise from organizational popularity.

Making AI work at scale requires an intelligence layer between enterprise source systems and the models, agents, and applications expected to use their contents. That layer must do more than retrieve related documents. It must understand how the organization defines concepts, determine which evidence should carry the most weight, model how entities relate, identify demonstrated expertise, account for what was true at a particular time, and recognize where the available knowledge is incomplete or conflicting.

Bloomfire’s Enterprise Intelligence Engine™ creates that layer by building and continuously maintaining a Persistent Semantic Memory™ (PSM): a durable, high-resolution model of the organization’s connected knowledge. The EIE performs the ingestion, enrichment, governance, grounding, and reasoning operations. The PSM is where the resulting knowledge, context, evidence, and relationships are persistently stored.

We describe the PSM as a 10K High Definition Memory Model.
The “10K HD” is an architectural shorthand for the resolution of the completed memory.
It is not a file format, context-window size, or even a claim that every knowledge object contains exactly 10,000 conventional fields.

The resolution identified demonstrates how the EIE can encode thousands of semantic and contextual dimensions in the PSM, then associate them with entities, relationships, schemas, permissions, source provenance, temporal context, authority, trust, expertise, and knowledge-health signals.

The result: a context layer that is more detailed than a traditional knowledge graph, less dependent on expensive manual modeling than a conventional enterprise ontology, and designed to support AI applications where accuracy, transparency, and consistency matter.

What “High Resolution” Means in an Enterprise Memory

A graph can tell an AI system that a person authored a document, a document concerns a product, or a support ticket relates to an asset. Those relationships are valuable—but they represent only part of the context an agent needs to reason safely.

The EIE creates high-resolution memory by evaluating and storing the distinctions surrounding those relationships:

• What concepts does the knowledge object define?
• Which concepts are merely discussed or referenced?
• Is the information current, historical, scheduled, or superseded?
• Is the source authoritative for this particular subject?
• Are its claims confirmed, uncertain, inferred, or contradicted?
• What type of document is it, and how should that affect its use?
• Which entities does it describe, and what domain-specific attributes belong to them?
• Who created, approved, discussed, applied, or challenged the information?
• What evidence supports each conclusion?
• Which users and agents have permission to access it?
• Where does the source material live?

Resolution is therefore not simply the number of nodes or edges in a model. It is the amount of governed, decision-relevant context the EIE can associate with a knowledge object, store in the PSM, and reuse during reasoning.

Some enterprise graph platforms publicly describe using more than 1,000 signals to model people, content, and relationships. The EIE creates a substantially higher-resolution semantic representation in the PSM before accounting for its entity attributes, relationship types, evidence, and contextual signals. That is the architectural basis for describing the memory as over 10 times more detailed than a traditional knowledge graph.

We base this architectural comparison on the representational resolution and the context signals available to downstream reasoning of a PSM compared to other well-known solutions employing knowledge graphs. Glean, for example, publicly describes “1,000+ signals” in its Enterprise Graph. Our own knowledge graphs prior to the development of the EIE was roughly 1/10 the scope of what is accomplished with a PSM.

High-resolution memory does not assume completeness.
The Enterprise Intelligence Engine continuously evaluates whether the PSM contains enough evidence to support the questions, roles, and workflows expected of it.

Tools the Enterprise Intelligence Engine uses to inspect and maintain the PSM include the Organization Simulator pressure-tests the memory with real, synthetic, unusual, and adversarial requests. Knowledge Base Health identifies the gaps, conflicts, weak evidence, and structural risks behind failed responses. Context Navigator makes those weaknesses visible across the memory model. Together, these tools allow teams to find and prioritize missing context before it causes an AI agent to make the wrong decision.

From a Source Object to Persistent Memory

The basic unit stored in the PSM is a knowledge object. A knowledge object may originate as a document, dataset record, policy, procedure, meeting transcript, chat discussion, support ticket, research report, media file, or another identifiable unit from any connected source.

The source material does not have to be migrated into Bloomfire. It can remain in its system of record while the EIE builds and maintains a persistent memory of its contents, context, permissions, provenance, and relationships while retaining a link back to the object in it’s source system. The resulting PSM can be hosted by Bloomfire, hosted in a customer-controlled environment, or deployed on premises. Because these compiled memory models are highly efficient, bounded models can also support specialized deployments, including offline field-service applications synchronized to a mobile device.

When a knowledge object is connected, the EIE identifies what has changed and performs a series of enrichment operations. A simplified lifecycle is:

The EIE performs incremental updates rather than rebuilding the entire memory whenever a source changes. This allows the PSM to accumulate organizational knowledge while the EIE keeps it synchronized with current source evidence.

Five Contextual Dimensions Applied to Every Knowledge Object

The EIE can associate many dimensions with a knowledge object, but five enrichment operations are especially important because they are applied consistently and directly improve reasoning.

1. Concept identity

The EIE determines whether the object provides evidence about an existing concept, uses a different name for a known concept, modifies the organization’s understanding of that concept, or introduces something new.

The EIE can classify evidence as:

• Discriminative: Evidence that helps define the identity or boundaries of a concept.
• Supporting: Evidence that adds context without independently defining the concept.

This distinction prevents every mention from being treated as equally meaningful. It also allows the EIE to model how concepts evolve and store that changing understanding in the PSM. Evidence that is merely supportive in one context may be discriminative in another, and its role may change as new knowledge becomes available.

2. Temporal awareness

Enterprise truth changes. A policy may be valid now, scheduled for a future effective date, or retained only as historical context. A ticket can describe a condition that was true during an incident but has since been resolved.

The EIE’s time-based context engine does more than inspect timestamps. It distinguishes publication dates from dates discussed within the content, infers contextual time periods, and evaluates recency relative to the question being asked. Instead of relying only on hard expiration dates, temporal relevance can change gradually as information ages or newer evidence becomes authoritative.

The EIE stores this temporal context in the PSM, allowing the same knowledge to remain useful as history without being presented as current guidance.

3. Authority

The EIE calculates authority to determine how much weight a source should carry for a particular concept. Signals may include conceptual coverage, document type, ownership, approval status, engagement, citations, structural importance, author expertise, freshness, and consistency with other evidence.

Authority is not the same as popularity. A company holiday schedule may be the most-viewed item in a knowledge platform. It is authoritative for company holidays, but its popularity does not make it authoritative about lending policy, equipment maintenance, or regulatory compliance.

Authority is concept-specific. A document can be highly authoritative in one area and largely irrelevant in another. The EIE stores the resulting scores with the associated concepts, sources, and entities in the PSM, then uses those scores to rank and weight evidence during reasoning.

4. Entity resolution

The EIE identifies references to the same person, product, customer, asset, policy, location, or other entity across different systems and naming conventions. It harmonizes those references and stores the resulting entity representation in the PSM while preserving the supporting evidence and source provenance.

This gives the EIE a coherent view of an entity during reasoning without requiring source systems to use identical identifiers or metadata.

5. Ontological structure

The EIE identifies the dimensions by which the organization’s knowledge naturally organizes itself: products, processes, policies, markets, assets, customers, regulations, locations, responsibilities, concepts, and relationships.

The resulting structure is stored in the PSM as a living ontology informed by the connected evidence. Architects can guide it through entity definitions and domain schemas without manually constructing every object and relationship before the system becomes useful.

These five operations occur in parallel with other EIE enrichment processes, including permission mapping, provenance, document classification, knowledge-health evaluation, and domain-specific entity extraction.

Example: Concept Modeling in a Commercial Loan Policy

Consider a commercial loan policy that defines when a loan officer may approve a request, when an exception is permitted, and which approvals are required.

The EIE might identify the following as discriminative evidence:

• Eligible credit products and borrower categories
• Underwriting thresholds
• Collateral or coverage requirements
• Exception limits
• Required approval roles
• Mandatory controls
• Effective and superseded policy dates

These details help define the identity and boundaries of the policy.

The EIE might classify the following as supporting evidence:

• A credit committee discussion explaining why a threshold was adopted
• Historical loan decisions involving similar circumstances
• A relationship manager’s notes about a customer’s seasonal cash flow
• A chat discussion about applying the policy to an unusual case
• Ticket records showing where the approval workflow created delays
• Research describing changes in the relevant market

That evidence may help the EIE interpret the policy, but it should not silently replace the approved policy.

The classification is contextual. Seasonality may be supporting evidence when evaluating a policy exception, but it may be discriminative when defining the concept of seasonal cash-flow risk. A newer approved policy may also change which evidence defines the concept.

The EIE evaluates and maintains these distinctions in the PSM so its grounding process can rank evidence appropriately rather than blending every semantically similar passage into a single answer.

Document Type Changes How Evidence Is Interpreted

Not every source should be processed as though it serves the same purpose.

A formal policy establishes approved rules. A procedure explains how to execute them. A knowledge article may summarize them for a particular audience. A research report explores evidence and possible conclusions. A historical ticket describes what happened in a specific case. A Teams or Slack discussion may capture valuable expertise, emerging concerns, or the reasoning behind a decision—but it may also contain speculation.

The EIE classifies document types and adapts its enrichment process to the role each source plays. This affects how the engine extracts concepts, calculates authority, applies temporal context, and uses the source during reasoning. The resulting classifications and signals are stored with the knowledge object in the PSM.

A traditional retrieval system may find all six sources semantically relevant. The EIE also understands why they are different and uses the context stored in the PSM to reason accordingly.

Expertise Is More Than Authorship or Organizational Role

Knowledge graphs frequently connect people to content through authorship, access, and engagement. Ontologies generally represent a person as an entity connected to roles, departments, documents, projects, or other entities.

The EIE goes further by constructing and maintaining an evidence-based model of expertise in the PSM.

It can consider what a person authors, the concepts they explain, the questions they repeatedly answer, their contributions in meetings, the people who seek their input, the authority of the material they produce, their historical roles, and knowledge demonstrated beyond their current job title.

The EIE evaluates expertise in relation to specific concepts and entities. “maintenance expertise” and “maintenance expertise for a particular machine” are not necessarily the same. However, during reasoning, the EIE can identify related concepts and make a qualified inference that expertise may transfer between similar assets or processes. It’s important to note that this is an evidence-routing capability, not a judgment of employee value or performance.

When that happens, the engine can disclose that the conclusion is based on related evidence rather than direct experience. This distinction is valuable in scenario planning and other applications where an inferred connection may be useful but should never be presented as a confirmed fact.

Domain Schemas Add the Context Generic Models Miss

Every industry has entities whose important attributes are not represented adequately by a generic graph.

In manufacturing, an equipment entity might include:

• Manufacturer and model
• Serial number
• Location
• Components and replacement parts
• Engineering specifications
• Operating limits
• Maintenance intervals
• Service history
• Known failure modes
• Applicable procedures
• Responsible teams and experts

The EIE maintains a configurable Domain Schema Registry containing reusable entity types. Administrators can add or adapt a schema using a templated configuration file. Once the schema is available, the engine can populate its fields from connected knowledge objects, resolve the entity across sources, and maintain its relationships as new evidence arrives. The resulting entity data, evidence, and relationships are stored in the PSM.

This allows the EIE to turn scattered specifications, maintenance logs, procedures, tickets, technician conversations, and equipment records into a persistent asset memory. A diagnostic agent can then use the EIE to reason from the machine’s complete context instead of retrieving a few passages that happen to contain the same model number.

Ontologies can represent this structure, but traditionally require substantial upfront modeling and ongoing manual maintenance. The EIE combines explicit domain structure with automated extraction, concept discovery, entity resolution, and incremental updates—reducing the cost and time required to create and maintain a useful model.

Authority, Trust, and Confidence Are Different Signals

Authority answers: How much weight should this source carry for this concept?
Trust asks: How well is this claim supported by the available evidence?

The EIE evaluates whether information appears confirmed, supported, uncertain, inferred, or conflicting. It compares claims across sources, identifies missing context, and records the strength of the supporting evidence in the PSM.

During grounding and reasoning, the EIE uses that stored evidence to calculate a confidence score for the response. A high-authority source may still conflict with a newer approved policy. Several low-authority discussions do not automatically outweigh a formal standard. A response based on indirect evidence should not receive the same confidence as one supported by multiple current, authoritative sources.

These operations improve both AI output and governance. They help the organization see why the engine reached a conclusion, where conflicting information exists, and what knowledge must be strengthened before an agent should act.

Why the EIE Uses Fewer Tokens Than Query-Time RAG

Traditional RAG reconstructs context for every query. It searches an index, retrieves a limited group of passages, inserts them into the model’s context window, and asks the language model to interpret the evidence and reason from it again.

The EIE performs much of this understanding when knowledge enters the memory. It extracts and evaluates concepts, entities, relationships, authority, temporal context, and other signals, then stores the resulting context in the PSM. The engine can reuse that persistent understanding across queries instead of repeatedly supplying large volumes of source text to a model.

When Bloomfire compared identical queries against the same knowledge base using its tuned RAG-based conversational AI and its EIE-grounded reasoning architecture. The average RAG query consumed 6,750 tokens, compared with 940 tokens for the EIE.

That represents approximately:

• 86% fewer tokens per query
• 5,810 tokens avoided per query
• 7.2 times greater token efficiency

While this is an internal architectural comparison, not a guarantee that every deployment will produce the same result. Token consumption depends on query type, model, configuration, response length, and source environment. Bloomfire has made the assumptions adjustable in its public AI Token Usage Calculator so architects can model their own expected usage.

The important difference is where the computational work occurs. RAG repeatedly reconstructs understanding at query time. The EIE builds and maintains reusable understanding in the PSM, then reasons from it when a request is received.

The Proof Is in What the Engine Allows You to Build

Higher-resolution memory is valuable only if the EIE can use it to create better systems.

Asset Intelligence

The EIE can bring together equipment records, engineering specifications, maintenance logs, service tickets, procedures, technician discussions, failure histories, and expert knowledge in the PSM. Because the memory stores the identity and context of the asset, the engine can consider operating limits, component relationships, prior failures, maintenance history, temporal conditions, and the authority of each source when supporting an AI diagnostic tool.

This enables diagnostic reasoning that would be difficult to achieve reliably from a small retrieval window.

Decision Intelligence

Decision Intelligence uses the EIE to search the organization’s connected knowledge, evaluate evidence for and against a proposed action, identify upside, downside, risks, conflicts, and knowledge gaps, and produce a structured prediction with a confidence score.

Its effectiveness depends directly on the quality of the evidence and context the EIE has stored in the PSM. Research and insights communities are particularly valuable because they contain reports, supporting data, competing interpretations, and records of how ideas developed. When strong evidence is available, the engine can generate a well-grounded assessment. When evidence is weak, incomplete, or conflicting, confidence decreases and the system explains what limits the conclusion.

The purpose of this module is not to replace judgment. It is to show decision-makers what the organization knows, what the evidence supports, where uncertainty remains, and what should be investigated before committing.

Better Memory Is the Foundation for Mission-Critical AI

A context graph helps AI navigate relationships. An ontology helps it understand formal structures. The EIE creates a Persistent Semantic Memory that incorporates both, then extends them with a higher-resolution semantic representation, domain-specific schemas, evidence, time, authority, trust, expertise, provenance, permissions, and knowledge-health signals.

That distinction matters most when tolerance for error is low.

A mission-critical agent cannot safely treat every matching passage as equivalent. It needs an intelligence engine capable of determining which source governs, whether it is current, which claims are disputed, who has demonstrated expertise, what evidence is missing, and how confident the system should be before recommending an action.

Better context creates better governance. Better governance produces better AI.