Sixth page in Operation Scarecrow. If you haven't read The Company Brain Is Four Different Problems and the four memory-type pages that follow it yet, start there — this page assumes the four-way split and spends its time on one company's actual artifacts instead of re-explaining the framework. Source citations at the foot of this piece.
Meridian is a composite, illustrative mid-market B2B SaaS company — roughly 400 people, sells a workflow and operations platform, with Product, Engineering, Data, Support, Sales, and Security functions. It isn't real. It stands in for the shape most mid-market software organizations are already in, and it's shown up already in each of the four memory-type pages in this section. This page is where it gets the full treatment: every artifact, sorted at once, plus the case that doesn't sort cleanly into any of the four.
The raw inventory, before anyone sorts anything
Here's what actually exists at Meridian today, unsorted, the way it shows up in a real company: sprint tickets, the on-call schedule, the #incidents Slack channel, feature-flag rollout state, postmortems, product decision one-pagers, closed customer escalation write-ups, A/B test result summaries, sales call notes tied to specific deals, Architecture Decision Records, a metrics and data dictionary, API and schema contracts, security and compliance policies, a product glossary, an org chart, pricing and business rules, the production codebase, CI/CD pipeline definitions, a deploy runbook, an incident-response runbook, a customer-onboarding runbook, the design system and component library, sales battlecards, Zendesk support macros, project budgets, burn rate, resource allocation plans, and the weekly status reports that roll all of it up.
That's a normal mid-size company's knowledge base. Almost none of it was built with the other pieces in mind, and it lives in a dozen different tools — Jira, Slack, PagerDuty, LaunchDarkly, Confluence, Notion, Salesforce, Gong, Zendesk, GitHub, dbt, Vanta, Figma, Highspot — each with whatever review process, often none, that tool's owning team happened to adopt.
The four-way sort, briefly
Each tier got its own full page already, so this is the compressed version rather than a repeat. Working memory is the sprint board, the active-incident channel, on-call state, and feature-flag rollout — cheap, disposable, and correctly ungoverned; see Working Memory. Episodic memory is the postmortems, decision one-pagers, closed escalations, and ADRs — dated, reasoned, and scattered across five tools with no shared shape; see Episodic Memory. Semantic memory is the metrics dictionary, the glossary, compliance policy, and pricing rules — the tier most likely to already be silently wrong, because nobody's specifically responsible for it; see Semantic Memory. Procedural memory is the codebase and CI/CD on one hand, runbooks and battlecards on the other — one label already split into a well-governed half and an ungoverned half; see Procedural Memory.
Incident channel
On-call state
Feature flags
Decision one-pagers
Closed escalations
ADRs
Glossary
Compliance policy
Pricing rules
CI/CD
Runbooks
Battlecards
Sixteen of Meridian's artifacts, sorted — the fifth case (budget, burn rate, percent-complete) isn't pictured here because it splits across tiers rather than living in one, which is the whole point of the section below.
The fifth case: financial and status metrics don't belong to one tier at all
Project budgets, burn rate, and percent-complete are the one part of Meridian's inventory that resists the four-way sort cleanly, because each one is actually four different objects wearing a single name.
Take Meridian's Project X budget. The original approval — "$2M approved, on this date, for these reasons" — is episodic: a dated decision with rationale, the same shape as an ADR. The number everyone downstream should treat as authoritative once approved is semantic — settled, owned by Finance or the PMO, scoped to that one project rather than firmwide, which means it needs a steward and an approval chain, just a smaller-blast-radius one than a firmwide pricing rule. The live, currently computed burn rate or remaining percentage is working memory — cheap, recomputed constantly from actuals, thrown away and replaced the moment new numbers land. But the formula for computing burn rate is itself semantic and needs the same governance as any other glossary term, because Finance and the PMO computing "burn rate" two different ways is exactly the "active account" ambiguity problem in a different costume — two dashboards disagreeing about the same project, with people quietly picking whichever number supports what they already wanted to say.
Percent-complete follows the same logic with an extra wrinkle. The live number is almost always working memory — either a rollup from ticket completion or a PM's subjective estimate, updated constantly. But the moment someone files Friday's status report, that act freezes a piece of working memory into an episodic snapshot, the same way a monthly close turns mutable in-progress actuals into an immutable closed record nobody edits again. That's a real transition between tiers, simpler and more mechanical than the evidence-based episodic-to-semantic promotion this section argues for elsewhere — no independent-context requirement, just a scheduled freeze.
Resource allocations add a third pattern. The planned allocation — "Engineer A at 50% on Project X this quarter" — is an episodic decision made at planning time, and rolls up into something closer to Walsh and Ungson's structures bin if it hardens into a standing policy rather than a one-off call. What people are actually spending time on this week is working memory, the same tier as the sprint board — and it routinely disagrees with the plan, which is useful signal about where reality has drifted, not noise to be corrected away.
An agent asked "what's our remaining budget" has to know whether to apply a governed formula to live data, pull last month's closed snapshot, or read this week's still-moving estimate — and those three can legitimately disagree without anything being wrong. Getting the tier wrong here isn't a data bug, it's a category error, and it's the single most common way a finance dashboard and a product dashboard end up telling two different stories about the same project.
Where the value leverage actually differs by tier
The business case for building each tier out isn't the same case, which is itself the strongest argument for not governing all four under one rule. Working memory buys speed — less re-briefing, less context lost at every handoff between a human and an agent, or between two agents. Episodic memory buys non-repetition — the same debate doesn't get re-litigated from scratch by a different team six months later. Semantic memory buys consistency and risk reduction — one wrong settled fact propagates everywhere it's used, which is why governance spend has its highest return here. Procedural memory buys direct automation — the only tier where the payoff is an agent doing the work itself, not a human or agent deciding faster.
An organization building this out doesn't need to fund all four tiers equally, or in the same order. It needs to know which kind of leverage it's actually short on right now. Meridian's inventory is a reasonably normal starting point for figuring that out: working memory is usually fine as-is, episodic is usually scattered but cheap to fix, semantic is usually the quiet risk nobody's been assigned to own, and procedural is usually split unevenly between a well-run code half and an ungoverned everything-else half.
What happens when the org wants to challenge a settled fact
Everything discussed on this page's companion pages assumes memory only flows one direction — episodic evidence accumulates, gets promoted, becomes semantic law. Real organizations also need the reverse: revising or retiring a fact that's already settled, and cognitive science has an answer for this that isn't "just edit the record."
Reconsolidation is the mechanism, not consolidation in reverse. When a consolidated memory is retrieved, it briefly becomes labile — chemically re-open to revision — before it re-stabilizes, a finding that traces back to Nader, Schafe, and LeDoux's fear-conditioning research in 2000. The organizational parallel: a settled fact shouldn't be silently overwritten, and it shouldn't be permanently locked either. Retrieving it under active challenge is what legitimately reopens it — a principled answer to "how do you unmake a firmwide fact" that's symmetric with how this section already answers "how do you make one."
Four conflicts show up in practice, and they don't get resolved the same way. Evidence-driven contradiction is independent episodic records, generated in separate contexts by people with no reason to have coordinated, starting to point away from a settled fact — treated with the same evidentiary bar as promotion, inverted: not one loud complaint, but repeated, independent, traceable contradiction. Hypothesis-driven challenge is someone believing a fact is wrong before there's evidence for it; it doesn't get to touch semantic memory directly, it gets filed as an episodic hypothesis that has to earn its way to evidence, the same separation a hunch and a tested claim always deserve. Silent procedural drift is nobody filing a challenge at all — the org's actual behavior already disagrees with the stated fact, discovered after the fact rather than argued before it. Episodic-vs-episodic conflict is two teams making opposite calls with equally defensible dated rationale — usually a symptom that a semantic entry is missing or being silently violated, and it should trigger a coherence check rather than get settled locally by whichever team argues harder.
Worked example: Meridian's ICP
Meridian's semantic memory has long held a governed fact: the ideal customer profile is mid-market IT operations teams, 200 to 2,000 employees. It's baked into sales battlecards, pricing tiers, onboarding copy, and marketing targeting rules — all procedural memory downstream of one semantic entry.
Over two quarters, three independent episodic records start pointing the same direction without having coordinated: Sales' win/loss call notes, a CS churn postmortem, and a Marketing landing-page test all suggest the real traction is with platform-engineering teams, and that IT ops accounts churn at roughly twice the rate. Provenance shows these three don't trace back to one shared meeting or one person's opinion repeated three times — that check matters, because five teams "confirming" an assumption they all inherited from the same all-hands slide isn't independent evidence, it's one contaminated source echoing. Without tracking where each episode actually originated, a steward can't tell the difference between real convergence and an echo.
That clears the bar for a formal challenge, not an automatic rewrite. It gets filed as an episodic entry — "we believe the ICP is wrong; here's the evidence" — and routed by blast radius: a glossary term can be revised by a domain steward, but a firmwide strategic fact like the ICP needs sign-off at the top of the ownership chain, the same escalation logic ADR practice already uses — owner priority: CEO, then CTO or equivalent, then the team, then the subject-matter experts. The fact is now in its reconsolidation window, open to revision and actively being retested, rather than either quietly ignored or silently overwritten. Meridian runs a deliberate test: reposition messaging and targeting toward platform engineering for a quarter, and watch whether the signal holds under a real experiment rather than a boardroom argument.
If it holds, the ICP entry gets superseded, not deleted: the old fact's validity interval closes, the new one opens, and the three triggering episodes stay attached as the recorded rationale — the same supersede-don't-edit pattern episodic memory already uses, applied one level up. Then lineage does the unglamorous part: every procedural artifact that baked in the old ICP — battlecards, pricing tier design, onboarding copy, targeting rules, any lead-scoring logic in the product itself — gets flagged as stale and routed for update, and any in-flight campaign or sales sequence still running on the old assumption gets a stale-context flag rather than finishing out unaware anything changed. That last step is the one most organizations skip: the fact changes on the glossary page, and Sales keeps pitching the old ICP for another year because nothing told the procedural layer the ground had moved.
One override is worth naming explicitly. If the CEO wants to change the ICP on conviction, with no evidence yet, the governance chain should still allow it — but it has to be logged as an override, not disguised as evidence. A future reader of that semantic entry needs to know whether it was revised because three independent signals converged, or because someone senior overruled them. Treating the two as equivalent is how an organization loses the ability to tell its own good calls from its lucky ones.
What follows from here
This page is the last stop before the pieces get assembled into one picture. The next page in this section pulls the org chart, the day-to-day practice, and the technical architecture for all four tiers — plus the consolidation engine and routing layer this walkthrough assumes exist — into a single answer for what a fully built-out version of this actually looks like.
Sources. Reconsolidation research: Nader, K., Schafe, G.E., and LeDoux, J.E., "Fear memories require protein synthesis in the amygdala for reconsolidation after retrieval," Nature, Vol. 406 (2000), pp. 722–726. Meridian's full artifact inventory, four-way sort, fifth-case decomposition, and the ICP conflict walkthrough are original composite illustrations built for this section — not a real company, real dataset, or real dispute. The financial/status-metrics decomposition draws on the same category-error logic Palantir's own "operational truth" claims get tested against in production settings, per Palantir Foundry documentation, palantir.com/docs/foundry/ontology/overview.