> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corelayer.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Organization Memory
> Corelayer remembers your feedback and what it learns from incidents, then uses that memory to suppress noise and sharpen future analysis.
## What is Organization Memory?
Corelayer keeps a per-organization memory of what it has learned about your systems. Every time you give feedback — closing an issue as a false positive, telling the assistant to ignore a class of alerts — and every time an incident is investigated, Corelayer distills the lesson into a durable memory.
That memory is then applied automatically: it stops Corelayer from re-alerting on things you've already told it to ignore, and it gives every new investigation the context of what has happened before.
Memory is scoped to your organization and isolated from every other tenant. Each memory is either **anchored to a specific resource** (a database, service, or integration) or kept **organization-wide**.
## Kinds of Memory
| Kind | What it captures | Example |
| ------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| **Failure pattern** | A recurring failure, its root cause, and the fix | "Connection pool exhaustion on the orders DB during peak traffic — raise `max_connections`." |
| **Preference** | What you want surfaced or ignored | "Don't alert on staging timeouts." |
| **Fact** | Stable context about your systems | "The payments service runs on Postgres 14." |
| **Decision** | A standing policy | "Retry three times before escalating." |
Memory is **canonical, not a log** — when Corelayer learns the same thing again, it reinforces the existing memory and records the new evidence rather than creating a duplicate.
## How Memories Are Created
### From your feedback on issues
When you close an issue with feedback, Corelayer reads the intent:
* Feedback that means **"don't alert me about this again"** — false positive, expected / by design, won't fix, don't alert — becomes a **preference** anchored to that issue. Corelayer will suppress matching signals going forward.
* Feedback that means **"fixed / resolved / duplicate / still investigating"** is **not** treated as suppression. A recurrence after a fix is a regression worth surfacing, so Corelayer keeps watching.
Reopening an issue is treated as a correction. If a memory was created or reinforced by closing that issue, reopening it weakens or removes that memory — so a mistaken "ignore" doesn't keep hiding real problems.
### From the assistant
You can teach Corelayer directly in chat. Tell the assistant something like *"Remember that the nightly ETL job is expected to spike row counts on Mondays"* and it saves the statement as the right kind of memory (preference, fact, or decision). If the new statement contradicts something Corelayer already believes, it surfaces the conflict for you to confirm rather than silently overwriting it.
### From incidents
Corelayer consolidates resolved issues on a recurring basis, turning repeated incidents into **failure patterns** with a root cause and fix. These accumulate over time so that the next occurrence of a known failure is recognized immediately.
## How Memory Is Used
### Suppressing noise
Before Corelayer creates a new issue, it checks the signal against your **preferences** — both the exact recurrence of something you've closed before and anything semantically similar. If a standing preference clearly says to ignore it, the signal is suppressed and no issue is created. This is what keeps "I already told you about this" from happening twice.
### Sharper analysis
When Corelayer investigates a new signal, it recalls the most relevant memories for the systems involved — past failure patterns, known facts, and decisions — and feeds them into the analysis. Recall is ranked by relevance, confidence, and recency, so older or less certain memories fade in influence over time.
### Preflight: checking a change before you ship
Memory isn't only applied after a signal arrives — you can ask it about a change *before* it ships. Preflight takes a pull request's description and returns the failure modes, facts, and preferences the org has hit before for a change like that, as concrete reminders to double-check.
Run it from the CLI inside a repository, with no arguments — it derives the PR context from the current branch:
```bash theme={null}
corelayer preflight
```
It returns at most a few grounded reminders — each citing the memory behind it, its severity, and how often the org has hit it — or nothing when memory has no relevant lesson. Preflight is advisory and never blocks a push.
Agents can run it too: the [`corelayer.preflight`](/cli/mcp-server) MCP tool takes a PR description, and with the [Corelayer skill](/cli/corelayer-skill) installed, asking your assistant to "check this PR against Corelayer" routes to it. See the [CLI reference](/cli/overview#preflight) for flags and output.
## Reviewing and Managing Memory
Open **Cortex** from the sidebar to see your organization's memory. Cortex visualizes each system and the lessons attached to it, alongside organization-wide preferences, facts, and decisions.
From Cortex you can:
* **Read** what Corelayer has learned about each system
* **Edit** a memory's wording
* **Archive** a memory to stop it from influencing suppression and analysis
* **Restore** an archived memory
Memory is also reachable over the [MCP server](/cli/mcp-server) via `corelayer.search_org_memory`, so agents and MCP-compatible tools can read your organization's history for prior decisions and context.
## Related
Search organization memory from AI agents and MCP-compatible tools.
The signals that feed Corelayer's investigations and memory.
Need help? [Contact support](mailto:support@corelayer.com).
## Related topics
- [June 2026](/changelog/june-2026.md)
- [Corelayer CLI](/cli/overview.md)
- [Corelayer MCP Server](/cli/mcp-server.md)