CoreStory for Dummies: Plain Language Guide to the Technology and the Moat

CoreStory is built from five connected capabilities: polymorphic agents, an ontology, a knowledge graph, a trust engine, and living intelligence. This guide explains each one in language a buyer can repeat.

The thirty second version

Large enterprises run software that nobody left in the building fully understands. The people who wrote it are gone. The documentation, where it exists, is wrong. AI coding tools have made this sharper rather than softer: they write more code, faster, on top of a system nobody has mapped.

CoreStory builds a persistent intelligence model from source code and related project artifacts. People query it in CoreStory, and compatible coding agents can reach the same project intelligence through CoreStory's MCP server.

AI coding tools generate code. CoreStory generates the understanding they are missing.

01 — The problem that does not have a name yet

Every AI coding tool assumes the hard part is writing code. In a large enterprise estate, the hard part is knowing what the code does.

The understanding gap is expensive. In October 2025, Pega reported that Savanta had surveyed more than 500 IT decision makers worldwide. Pega estimated that the average global enterprise wastes more than $370 million each year because it cannot modernize outdated systems efficiently. Pega describes that figure as an estimate built from survey responses and industry benchmarks.

02 — Five pieces, one loop

CoreStory is usually described as a set of pillars. It is easier to understand as a loop, because that is the order things actually happen in, and because the last step feeds the first one.

The five steps: 01 Read it — Polymorphic agents follow the reasoning chain wherever it goes. 02 Normalize it — The ontology puts every finding in the same shape. 03 Connect it — The knowledge graph fuses findings into one map. 04 Prove it — The trust engine verifies each claim back to source. 05 Keep it true — Living intelligence re-reads what changed, and the loop restarts.

Each capability is useful on its own. CoreStory connects them so that extraction, normalization, relationships, evidence, and refresh can reinforce one another.

Pillar 01 — Polymorphic agents

The analogy. The only way anyone has ever really understood an unfamiliar enterprise system is to send an engineer to go and live with it. They read code, but they also run the thing, watch the screens, trace one transaction end to end, and follow the question wherever it leads, picking up whatever tool the next step needs. That person is scarce, expensive, and eventually leaves. A polymorphic agent is that engineer, instantiated as many times as the estate needs.

A useful description is a virtual forward-deployed engineer: an agent that can use different tools as a question crosses files, languages, and system boundaries. It is broader than a parser and less rigid than a fixed pipeline.

Important behavior in an enterprise system rarely lives in one file. It may span application code, batch jobs, databases, services, and operational artifacts. Repository-only tools can miss those relationships when the evidence sits outside the repository they can see.

polymorphic agent — NOUN. An AI agent that can select and use different analysis tools as a reasoning chain crosses files, languages, and system boundaries.

What repository-only analysis can miss: behavior represented outside source files; values and thresholds embedded in code; batch jobs and schedules; relationships that cross applications or runtimes; and gaps between documented intent and implemented behavior.

Pillar 02 — The generalized ontology

The analogy. Every hospital records a patient's blood pressure the same way, in the same units, in the same field. That is why any doctor can pick up any chart and read it. Software has never had that chart format. We built one.

Agents reading different parts of a system produce differently shaped findings. The ontology is what makes them comparable. A business rule found in a batch job and a business rule found in a service land in the same structure, with the same fields, in the same place. The normalized model is then cast back into the customer's own vocabulary, so a claims organization reads about claims and a bank reads about accounts.

The ontology makes findings comparable. It lets teams ask a business question and connect the answer to the code evidence that implements the behavior.

generalized ontology — NOUN. A shared vocabulary for representing software behavior so findings from different languages and systems can be compared, connected, and queried. CoreStory calls this the Software Application Ontology (SAO).

Second-order questions only work with an ontology: "If we change the eligibility rule for beneficiaries aged fifty and over, which downstream reports become wrong?" / "Which customer-facing behaviors depend on logic that only exists in a stored procedure?" / "Which user types can trigger this transaction, and what authorization governs each one?" / "What business rules would change if we deprecated this table?"

M&A and technical due diligence: "How much of the target's business logic duplicates what we already run, and where is it genuinely differentiated?" / "What in this system depends on the seller's own infrastructure, and therefore has to be rebuilt after close?" / "If we merge their billing into ours, what breaks, and how long does it take?"

Every one of those is phrased in business terms and can only be answered from code. That gap is the ontology's job.

Pillar 03 — The knowledge graph

The analogy. Satellite photos of a city show you every building. A street map shows you how to get from one to another and what closes when. Retrieval gives you photos. We give you the map, with the streets labelled and a route an agent can follow.

The graph connects normalized findings: call relationships, data flows, business rules, execution paths, architecture, deployment patterns, and external dependencies. CoreStory exposes that persistent intelligence to people and AI tools.

The model persists beyond one chat or analysis session. Teams can refresh it as the underlying system changes, so prior analysis becomes reusable rather than disposable.

knowledge graph — NOUN. A connected model of system entities and relationships, including business rules, data flows, architecture, and execution paths. It gives people and agents a queryable map instead of a pile of retrieved fragments.

Pillar 04 — The trust engine

The analogy. The difference between a claim and a footnote. Anyone can assert that a rule exists. We show you the line of code that proves it, and we tell you how sure we are.

CoreStory is designed to connect important claims to inspectable evidence and to carry explicit confidence boundaries. Teams can check the source behind a claim instead of accepting an unsupported answer.

trust engine — NOUN. The evidence and evaluation layer that records how a claim was derived, links it to supporting material, and makes uncertainty visible.

Pillar 05 — Living intelligence

The analogy. A survey of a building tells you what was there on the day the surveyor visited. A building management system tells you what is there now. Everyone else in this market sells surveys.

A customer ingests a codebase and CoreStory builds an intelligence model. The code then keeps moving: pull requests merge, features ship, and logic changes. Without a refresh process, the model eventually describes an older version of the system.

Living intelligence is CoreStory's approach to keeping the model useful as the code changes. The platform can track the version on which the model is based and refresh affected intelligence when the underlying system moves.

living intelligence — NOUN. The processes that keep a persistent intelligence model aligned with a changing codebase through version tracking and targeted refresh.

03 — Why five beats one

The product advantage comes from how the capabilities work together. Extraction without normalization produces disconnected findings. A graph without evidence can preserve bad assumptions. A verified model without a refresh path becomes stale.

The reasoning loop: agents follow a question across the available evidence, then return their findings in a common structure.

The account loop: the persistent model preserves prior understanding and can be refreshed as the customer's system changes.

The quality loop: evidence and evaluation expose gaps that teams can review and improve.

The ontology and refresh path do quiet structural work. The ontology gives findings a shared shape; living intelligence keeps that shared model useful after the first analysis.

04 — The alternatives, honestly

Teams can build parts of this stack themselves or combine specialized tools. The useful comparison is architectural: which system can follow the required evidence, represent the findings consistently, connect them, preserve provenance, and keep the result current?

Option one: build it internally. A team can combine parsers, retrieval, graph storage, and agent tools. The difficult work is not producing a demo. It is maintaining coverage, a stable data model, evaluation, evidence, access controls, and refresh over time.

Use the five stages as a build checklist: Can the system inspect every relevant artifact? Does it normalize findings into a stable model? Can it connect relationships across boundaries? Can users inspect the evidence? Can the model be refreshed without rebuilding everything?

An internal build may fit a narrow, one-time question in a small and well-understood codebase. The work grows when the estate spans languages, repositories, runtime artifacts, or repeated use over time.

Option two: combine adjacent tools. Coding agents, code search, modernization assistants, documentation systems, and general-purpose chat products solve useful parts of the problem. Evaluate them by the evidence and system boundaries they can reach, the structure they preserve, and what survives the session.

05 — What CoreStory is not

Not a coding agent — We do not write the code. We tell the agent where to change it, why, and what to test against. We are the layer underneath.

Not RAG over a repo — Retrieval finds text that looks like the question. A graph knows what connects to what, which is the only way to answer an impact question.

Not static documentation — Documentation is useful, but it can drift. CoreStory builds queryable intelligence from system evidence and supports refresh as the system changes.

Not a code scanner — Static analysis and SAST tools look for defects and vulnerabilities. We model behavior and business rules, which is a different question.

Not a consultancy — There is no body shop attached. It is a product, deployed self hosted, on tenant, or fully air gapped.

Not limited to repository text — Where the required tools and artifacts are available, analysis can incorporate evidence beyond a single repository, including operational and runtime material.

06 — The cheat sheet

If somebody has thirty seconds, say the first line. If they push, use the answers below.

AI coding tools generate code. CoreStory generates the understanding they are missing.

07 — Words we want the market using

the understanding gap — The distance between the code an enterprise runs and what anyone still there knows about it. The problem we named.

polymorphic agent — NOUN. An AI agent that can select and use different analysis tools as a reasoning chain crosses files, languages, and system boundaries.

intelligence model — The persistent, verified model of a customer's system. Not a report, not an index.

spec — A unit of extracted understanding: a business rule, a data flow, an execution path, each indexed to source. Say spec, not specification.

second-order question — A question whose answer only exists once two or more facts that live apart are connected. The class of question retrieval cannot answer and we can.

SAO — Software Application Ontology. The standard vocabulary every finding is normalized into, and what lets a business question be answered from code.

trust engine — NOUN. The evidence and evaluation layer that records how a claim was derived, links it to supporting material, and makes uncertainty visible.

living intelligence — NOUN. The processes that keep a persistent intelligence model aligned with a changing codebase through version tracking and targeted refresh.

spec drift — The accumulated gap between what a spec says and what the system actually does. The thing living intelligence exists to close.

incremental re-ingestion — Re-analyzing only the parts of a codebase that changed rather than the whole estate. What makes continuous operation affordable.

grounding — What CoreStory does for a coding agent. An ungrounded agent guesses from a window. A grounded agent queries a map.

screen to spec — Deriving structured system understanding from an application's screens and runtime artifacts when source evidence is incomplete or unavailable.

code intelligence — The category. Persistent understanding of a system, served to both humans and agents.

FAQ

Is CoreStory a coding agent?

No. CoreStory supplies persistent system intelligence that coding agents and engineering teams can query while they work.

What does MCP do in CoreStory?

MCP gives compatible AI clients a standard way to query CoreStory project intelligence, including project documents, conversations, architecture, and code-index results.

How is a knowledge graph different from RAG?

RAG retrieves text that is likely to be relevant. A knowledge graph represents entities and their relationships, which supports dependency and impact questions that text similarity alone cannot answer.

Why does the intelligence model need refresh?

Software changes. Version tracking and targeted refresh help keep the persistent model aligned with the system it describes.