Fourth page in Operation Scarecrow. If you haven't read The Company Brain Is Four Different Problems yet, start there. Source citations at the foot of this piece.
The metrics dictionary that defines what "active account" actually means. The entity model an agent uses to know what a customer, a deal, or a ticket even is. Security and compliance policies. The product glossary. Pricing and business rules. None of these are decisions with a date attached the way the last tier's records are — they're facts with the originating episode stripped away, true everywhere, for everyone, until someone with the authority to change them says otherwise.
That's exactly what makes this tier expensive to get wrong. A bad episodic entry is a bad precedent one team might follow. A bad semantic fact is wrong everywhere it's used, silently, for as long as nobody notices — which is the whole reason this is the one tier that actually deserves the heaviest governance in the entire framework, not as a default instinct toward caution, but because the blast radius genuinely is the widest of the four.
Where it already lives, and why it's usually already wrong
At Meridian — the illustrative mid-market SaaS company this section's worked example uses throughout — this tier exists, and it's the tier most likely to be silently stale. The metrics dictionary lives in dbt docs the data team can see and nobody else opens. The product glossary is a wiki page nobody trusts anymore. Compliance policies live in Vanta, visible only to Security. Pricing rules live in Confluence, quietly out of sync with whatever the actual rules engine does. This is the tier the framework says deserves the most careful ownership, and in practice it's the tier most likely to be wrong, precisely because in most organizations nobody's job is specifically to keep it current.
What's already built
Domain-Driven Design's ubiquitous language and bounded context — Eric Evans' 2003 formulation — is the pre-AI version of this tier: a shared, rigorous vocabulary built jointly by domain experts and engineers, deliberately scoped so the same term can mean something different in a different bounded context without silent conflict. On the AI-memory tooling side, Zep's semantic entity subgraph and Mem0's graph storage treat entities and relationships as first-class graph objects instead of free text. Enterprise data catalogs — Collibra, Atlan, and comparable platforms — are the fully governed, commercial version of the same idea: stewardship workflows, policy modeling, and column-level lineage sold as a category in their own right, which is itself evidence that a real market already believes this tier needs exactly the ownership model this page argues for.
Palantir's Semantic Data Layer is a fourth, independent arrival at the same tier, built for a different reason entirely: objects, properties, and links described as "operational truth," engineered specifically so an agent can't hallucinate a fact it's actually able to query live. Worth adopting directly if an organization already runs on Foundry; worth noting regardless, because it's one more independent confirmation that this tier needs a governed, queryable structure rather than a wiki page.
Hardest to write to, easiest to read from
Access here should be broad on the read side — every agent and every team should be able to see it — and narrow on the write side, gated by a real steward rather than open to anyone with edit access to a wiki. Collibra's own positioning makes the point better than a hypothetical would: it markets itself explicitly as a "governance orchestration engine" for regulated environments, with formal stewardship roles, approval chains, and policy modeled as code. That's not caution for its own sake. It's what a real commercial category has already concluded this specific tier requires.
A fact shouldn't be promoted into this tier on anyone's say-so, including a confident one. The bar is evidence, not opinion — the same distinction the argument page draws between a consolidated memory and a single confident judgment: a pattern independently confirmed across separate contexts earns promotion, and a hunch that "this seems like it should apply everywhere," voiced once by whoever happens to be reviewing that week, does not. The full mechanics of that promotion process, and what happens when someone wants to challenge a fact that's already settled, get a real worked example later in this section rather than a compressed summary here.
The leverage, and why it's a different kind of case than the other tiers
The business case for this tier isn't speed, and it isn't non-repetition — it's risk reduction and consistency. An agent computing churn on the wrong definition of "active" is wrong in every downstream report it touches, not just once. That makes this the tier where governance spend has the highest return of any of the four, and it's also why the case for funding it has to be made differently than the case for working or episodic memory: this isn't an efficiency argument, it's a "what does it cost us the day this is wrong in a board deck" argument, and it needs to be made to whoever owns that risk, not just to whoever owns the platform budget.
The part nobody's benchmarked yet
The case for why this tier needs a steward, real approval authority, and explicit versioning is solid — a real commercial market already sells exactly that governance model, and this page isn't hedging on that part. What's genuinely unsolved, industry-wide and not just in this research, is the maintenance mechanism underneath it. A 2026 survey of shipping agent-memory systems is direct about it: how memories actually get consolidated, promoted, demoted, and eventually retired is "the dimension most tools have addressed least." Real benchmarks now exist that test whether a system prefers updated information over stale information — a real improvement over having nothing. But the sharper distinction this tier's whole evidentiary bar depends on — telling three independent, non-coordinated corroborating signals apart from one loud, repeated complaint — still doesn't appear to be what any named benchmark tests directly. This page can state with confidence what semantic memory needs. It can't yet point to a benchmark proving any shipping system verifies it correctly.
Sources. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (2003); ubiquitous language summary via Agile Alliance, agilealliance.org/glossary/ubiquitous-language. Zep / Graphiti semantic subgraph: arxiv.org/abs/2501.13956. Mem0 graph storage architecture: mem0.ai/blog/graph-memory-solutions-ai-agents. Data governance platforms: Atlan, "What is Collibra Data Governance?," atlan.com/collibra-data-governance; comparative analysis at promethium.ai/guides/data-governance-tools-comparison. Palantir's Semantic Data Layer: Palantir Foundry documentation, "Overview • Ontology," palantir.com/docs/foundry/ontology/overview. On consolidation as the least-addressed dimension of shipping agent-memory systems: Zylos Research, zylos.ai/research/2026-04-20-memory-consolidation-ai-agents. On 2026 memory benchmarks and the contradiction-resolution gap: "AI Memory Benchmarks 2026: LoCoMo, LongMemEval & BEAM," mem0.ai/blog/ai-memory-benchmarks-in-2026; "TOKI: A Bitemporal Operator Algebra for Contradiction Resolution in LLM-Agent Persistent Memory," arxiv.org/pdf/2606.06240. Meridian is an illustrative, composite company invented for this section — not a real business — standing in for the shape most mid-market software organizations are already in.