How to Use Institutional Memory (Cerebro) in the ORIA Reasoner

Cerebro is ARPIA's persistent institutional memory layer. Inside an ORIA Reasoner session it appears as Institutional Memory — a first-class panel section, not a tool you attach. It is on by default in every session.

That default matters more than anything else on this page. Unless you turn it off, Oria answers from your organization's recorded decisions, rules and procedures — not just from general knowledge — and it can also write to that memory during the session. This page covers how that works, how to scope it, and how to work with it safely.

For the Reasoner itself, see How to Use the ORIA Reasoner. For the authoring-side counterpart, see How to Use Cerebro in the Oria Workbench.

Where to find it. Right-hand panel, first section, labelled Institutional Memory with a count badge. The gear icon opens its settings; the power icon toggles it for the session. It is a sibling of Ontology Nodes, Tools in this session, Artifacts and Files — not an entry inside Tools, and not an MCP collection you connect.

Overview

The mental model in one line:

Institutional Memory is on, scoped by domain, and can write. The three things you control are whether, where, and when you're asked.

Why This Matters in the Reasoner

The Reasoner is where business users meet institutional memory. That is both the point and the pressure.

The value. A question that would otherwise require finding the right colleague — "what did we decide about domain naming?", "what's the standard for deprecating a table?", "why is ELCONIX configured differently?" — becomes a direct question with an auditable answer. No query language, no ontology expertise, and no need to know whether the answer lives in a node or a memory. Oria consults both.

The shift in risk. Because the Reasoner cannot author structures, a wrong memory here cannot corrupt your ontology. It can still corrupt a decision. The propagation path is the pinned Artifact that gets dropped into a deck, an Acta, a committee minute, or a compliance narrative — where it acquires the authority of a document and loses the attribution that made it checkable.

The default-on consequence. Because Institutional Memory is enabled without being requested, grounding in Cerebro is the normal path rather than an opt-in. Every quality property of your memory store — and every defect in it — is therefore inherited by every session by default. Worth internalizing alongside the confidence trap.

The audience effect. The Workbench guidance assumes a reader who knows what an attribution block is and why it matters. The Reasoner is explicitly built for end business users who have no reason to know that. Verification discipline that is a habit in the Workbench has to be a default here.

Prerequisites

1. Cerebro is enabled for the work-area by an ARPIA admin.
2. Your user holds at least read_only scope on the domains you'll query, and read_write on any domain you intend to save to.
3. ORIA Reasoner itself is configured — a Model Group must be set for it, or the Reasoner is disabled entirely. See the Reasoner prerequisites.

Two access facts worth knowing before you request more scope:

• Access is granted, never revoked. There is no action to remove a user from a domain or to change an existing scope (read_only → read_write). Both require an administrator.
• read_write on a domain is what lets a memory be moved into it. Domain moves are validated against the target domain, not the source.

The Institutional Memory Panel

Open it with the gear icon on the Institutional Memory section header. Three controls:

1. Use institutional memory in this session

A checkbox, checked by default. Turning it off means Oria answers from your session data and the conversation only — general knowledge plus whatever you've attached, with no organizational grounding.

Turn it off when you want a deliberately unGrounded answer: a brainstorm you don't want anchored to prior decisions, a sanity check on whether the model's general knowledge agrees with your institutional record, or a session where you're testing the model rather than consulting the organization.

2. Limit to these domains

A multi-select. Leave it empty — the placeholder reads All my domains… — and Oria may read any domain you have access to. Choose specific domains and it cannot read outside them.

The panel states that organization-wide rules are included either way, whether or not you narrow the selection.

⚠️

Verify this before you rely on it. A confirmed defect at the tool layer has the global domain silently excluded when exactly one domain is passed — meaning organizational immutable rules were not applied in the single-domain case. The panel's assurance may reflect a fix in how the Reasoner constructs the query, or it may not yet hold end-to-end. Until it's confirmed, treat a single-domain selection as the risky configuration: select two or more, or leave the picker empty.

Scoping deliberately is good practice regardless: a narrow selection produces sharper answers and a smaller surface for stale or irrelevant memory to intrude on.

3. Ask me before saving anything

A checkbox, unchecked by default. The consent model underneath it is asymmetric:

So out of the box, the Reasoner can write to your personal memory during a session without surfacing a confirmation. Nothing is silently written to a shared domain, but personal memory accumulates quietly.

Turn this on if you audit your own memory, you're in a regulated or evidentiary workflow, you're evaluating Oria's behavior rather than using it, or you simply want every write to be a decision you made rather than one you allowed. The cost is one extra click per save; the benefit is that your personal domain reflects intent rather than drift.

This matters more than it looks, because memory is hard to unwrite: a memory is editable for 15 days from creation and frozen after that, and the correction tool may not be reachable at all (see Known Limitations). Silent accumulation plus a hard edit window is how a personal domain becomes an unauditable pile.

Conceptual Model

Organization (tenant boundary — no memory crosses it)
   └── Domain (arpia_product, arpia_oria, personal, global, ...)
          └── Memory (mid_xxxxxxxx)
                 ├── knowledge_type_id  (from the org's available types)
                 ├── parent_mid          (causal antecedent — forms a tree)
                 ├── references[]        (external URLs with a role)
                 ├── expires_at          (auto-expiration)
                 └── status              (APPROVED | INACTIVE)

On knowledge types: you will see types like Immutable Rule, Business Rule, Procedure, Customer Knowledge, Product Knowledge, Fact, Tip, and Todo Item. Treat that as illustrative — the authoritative list is your organization's own.

Knowing the types helps you read an answer. An Immutable Rule is a constraint; a Tip is someone's field note. They are not the same weight of evidence, and a synthesized answer can blend them without saying so.

Asking Good Questions of Memory

You don't call the underlying tools by hand in the Reasoner — you ask, and Oria selects. But knowing which mode your phrasing triggers changes the quality of what you get back.

Two phrasings worth learning:

• Ask for the attribution. A targeted question returns a synthesized answer and a structured block listing the contributing memories and their external references. That block is presented as-is — never paraphrased or trimmed. It is the verification mechanism, not decoration. If you don't see it, ask for it.
• Ask for the source, not the summary. "Show me the memory that says that" retrieves the record itself. Synthesis can invert a fact (see below); the source memory cannot.

If memory has nothing on a topic, Oria says so explicitly rather than filling the gap from general knowledge.

Saving From a Reasoner Session

Reasoner sessions produce decisions, and you can persist them here. A few rules govern how.

Saves are reactive. Cerebro writes when you say "save," "remember," or "persist." Finishing a line of analysis does not by itself write a memory.

Shared-domain saves always prompt. You will see the confirmation regardless of your settings. Personal-memory saves will not, unless you checked Ask me before saving anything.

Check for a duplicate first. Ask what already exists in the target domain before saving. If a matching memory is there, what you want is a correction, not a new save.

Continuations are new saves, not edits. An addition to existing knowledge becomes a new memory, optionally linked to its antecedent. Corrections to the existing record are the only case for an edit.

Save what you were shown, verbatim. If Oria displayed draft text before saving, the saved title and content must be character-identical to what you approved. No re-summarizing at save time — otherwise you approved one thing and the record says another.

Don't save personal preferences. Cerebro is organizational. "I prefer bullet points" is not institutional knowledge, and the existence of a personal domain is not an invitation to treat it as configuration.

The 15-day window is why to slow down. A memory is editable only within 15 days of creation — no exceptions, and re-parenting does not extend it. After that the record is frozen; the only path is to mark it INACTIVE and save a corrected memory in its place. Combined with the possibility that the correction tool isn't reachable at all, the practical rule is: get the save right the first time.

If you can't fix a bad memory, escalate it. A read_only user who finds a wrong, stale, or empty memory should route it to someone with read_write on that domain so it can be retired. Readers are usually first to notice bad memory and least able to correct it — and the 15-day clock makes that escalation time-sensitive.

Working Safely

Read-first is safer. It is not safe.

1. Treat a single-domain selection as the risky configuration

Select two or more domains, or leave the picker empty. See Limit to these domains — the panel promises organization-wide rules are always included; the tool layer has been observed dropping them in the single-domain case. Until that's reconciled, don't stake a decision on the one configuration where they diverge.

2. Treat any answer without attribution as unverified

Not wrong — unverified. It may be correct. You have no way to tell, and neither does the next person who reads it in your deck.

3. Verify anything specific before you repeat it

Every number, date, identifier, ticket reference, or CVE that Oria cites from memory should be checked against its source before it leaves the session. Structure is usually right; specifics are where fabrication lives.

4. Watch what you pin

Artifacts are the propagation path. A pinned artifact is a snapshot: it does not re-verify, it does not follow later corrections, and it does not disappear when the underlying memory expires or is retired. Once it's in a slide, the attribution is usually gone.

Practical rule: if an artifact will be reused outside the session, keep the attribution inside the artifact. A relationship diagram with a source list is evidence. The same diagram without one is an assertion.

5. Memory is not approval

Cerebro records that a decision was made. It does not make one, and reading it does not authorize anything. An answer that says "the procedure is X" is a record of a procedure, not a sign-off to execute it. Normal change management still applies.

6. Turn memory off deliberately, not accidentally

Because it's on by default, the meaningful act is switching it off — and that's a real tool, not a failure state. An unGrounded second opinion is useful precisely because it isn't anchored to what you already believe. Just know which mode you're in when you quote the answer.

Known Anti-Patterns

The confidence trap

The most important finding from the Oria evaluations (August 2026): models learn institutional structure accurately and then fabricate specific details — CVE IDs, metrics, dates — without flagging that they are extrapolating.

The risk isn't that the model doesn't know. It's that it sounds exactly as confident when it knows as when it invents. In the Reasoner that confidence doesn't reach your ontology — it reaches your audience. And because memory is on by default, this is the standard path, not an edge case.

Fact inversion in the synthesis layer

Cerebro's search synthesis has produced fact inversions — asserting the opposite of what the source memory says. This is why attribution matters: it's the only way to catch the inversion before acting on it. When a memory-grounded answer contradicts what you believed, that is the moment to open the source memory, not the moment to update your beliefs.

Empty memories and phantom duplicates

Memories marked [HIDDEN — EMPTY] or [HIDDEN — DRAFT DUPLICATE] in their titles remain retrievable. Structure present, substance absent — which feeds the confidence trap directly. Marking the title does not remove them from retrieval; only expiration or INACTIVE does.

Silent personal accumulation

Default consent settings let personal-memory saves happen without a prompt, while a 15-day edit window and a possibly-unreachable correction tool make them hard to undo. The result is a personal domain nobody deliberately built and nobody can easily clean. Check Ask me before saving anything if you'd rather own each write.

Scratch domains in the picker

Test and working domains appear in the same list as authoritative ones. Scoping a session to a scratch domain produces confident answers grounded in throwaway content. Read the domain names before you select them, and expire or retire test domains you're finished with.

The frozen artifact

A pinned artifact keeps circulating after its source memory is corrected, retired, or expired. Nothing links them. Date your artifacts, and re-run the query before reusing one in a decision context.

The single-reader domain

Several high-value domains have exactly one reader. Institutional memory with a single reader is personal memory with infrastructure overhead — and the business users who would benefit most are often the ones without access. Worth auditing periodically.

Typical Workflow

1. Create a session with a name that reflects the question, not the date.
2. Open the Institutional Memory panel. Confirm it's on, set your domain scope (two or more, or empty), and decide whether you want save prompts.
3. Add the Ontology Nodes relevant to your question. Scope narrowly; the whole ontology is not a scope.
4. Ask the question. Read the attribution block.
5. Verify any specific figure or identifier against its source memory.
6. Ask follow-ups. Memory and ontology answer different halves of most questions — memory tells you why it was decided, nodes tell you what is true now.
7. Pin what's reusable to Artifacts, with attribution included.
8. If a durable decision came out of the session, say so explicitly — review the draft, then save it.

Leverage Points

Small habits with disproportionate effect on answer quality:

1. Never scope to exactly one domain. One extra selection; avoids the one configuration where immutable-rule enforcement is in question.
2. Ask for the source on anything specific. The cheapest available defense against the failure mode that actually causes damage.
3. Attribution travels with the artifact. Strip it for brevity and you destroy the audit control and the fabrication check simultaneously.
4. Turn on save prompts. Converts memory accumulation from drift into intent, at one click per save.
5. Name sessions by question. The difference between institutional memory and institutional archaeology.
6. Escalate bad memories you can't fix. For most readers this is the only hygiene action available — and the 15-day window makes it urgent.

Known Limitations

• No structural authoring from the Reasoner. It cannot create or modify tables, nodes, or repository structures. This is by design.
• The correction tool may not be reachable. cerebro_update is fully specified in the API but was not exposed as invocable in the MCP session verified on Aug 14, 2026. Where that gap applies, a badly saved memory cannot be corrected from the agent at all.
• 15-day edit window, no exceptions. Past 15 days from creation a memory is frozen. Re-parenting does not extend it. The only path is INACTIVE plus a corrected new save.
• Single-domain scoping has excluded global. Confirmed defect at the tool layer. The panel states organization-wide rules are always included; that reconciliation is pending verification.
• Personal saves are unprompted by default. Shared-domain saves always ask; personal memory does not until you opt in.
• Fact inversion in search synthesis. Confirmed. Verify against attribution.
• Empty memories remain retrievable. Hidden-marked memories still surface until expired or retired.
• No access revocation. Domain access can be granted but never removed, and existing scopes cannot be changed. Both require an administrator.
• References cannot be cleared. On update, a references list is fully replaced, and an empty list is rejected.
• Validation is server-side only. Malformed calls surface as runtime errors rather than being caught up front.
• Requires admin setup. The Reasoner is disabled until a Model Group is configured at the work-area level; Cerebro requires separate work-area enablement.