Company second brain
The Company second brain is what your organization has learned across past incidents. After every resolved incident, a learning pass reads the findings the room admitted to its shared context and writes what they taught: lessons, the resources and dependencies the incident revealed, and recommendations. There is no accept step; an admin corrects or retires a lesson afterwards. Beacon, the room's AI agent, asks the second brain before raising a hypothesis, the same way it delegates metric and log queries to a telemetry connector. This page describes how it learns, why it believes what it does, and how it decides what is relevant: lexical plus vector search, fused into one ranking.
How it works
Two independent pipelines meet at the same store. When an incident resolves, the learning pass writes what it taught; investigations read entries back by relevance. Neither pipeline talks to storage directly: both delegate through one repository, the only component that knows the store's actual schema. The pages you read in the Wiki view, download for Obsidian or reach through the connector are rendered from that same store.
How it learns
The pass runs when an incident becomes resolved, closed, mitigated, recovered or done, with no human action and at most once per close. It reads only the claims admitted to the room's shared context at close, plus the timeline, and treats every piece of incident text as data, never as an instruction. A model may draft the result, but the platform decides what is written: every lesson, resource and dependency must cite an admitted finding the model was actually shown, and every quote is copied from the finding itself. When no model is available or the call fails, the pass still learns, from the admitted findings as they were stated, and the incident's learning review says so. Demo and practice rooms teach it nothing.
What the pass writes:
- Lessons, each through one of four lenses: architecture (how the system is built and what depends on what), stability (what makes it fail or hold), continuity (how the business keeps running through a failure) and response (how people and tools handled the incident).
- Architecture assumptions: the resources and dependencies the incident revealed, written to the architecture map as assumed from that incident.
- Improvements: recommendations, each with the incident and lesson it came from. Landfall tracks them and never applies a change: a person does the work in their own tools and marks it done.
- A learning review of the incident, read from its postmortem.
A lesson grows instead of repeating. When a later incident says the same thing, the existing lesson gains that incident as evidence. When it sharpens a lesson, the earlier text stays in the lesson's history. When it contradicts one, both stay readable and are linked; an earlier lesson that only one incident supported can be replaced. Maturity follows a published rule: a seedling is seen in one incident, a lesson is growing with two incidents (or one use that helped, or a person who added it), established with three or more (or two and a use that helped) and nothing contradicting it, and retired when it is no longer offered to investigations. Nothing a person wrote or corrected is ever rewritten by the pass.
The room shows one card when the pass is done, “The second brain learned from this incident”, with no buttons. See What the investigation knows.
What enters, and under which subject
Only the claims that were in the incident's shared context when it closed are evidence. A finding that was raised but never admitted, however confident its author was, is never learned from, not as a lead and not as an unconfirmed note. Each entry is filed under what its finding was about, read from the finding's own structured origin rather than from the words of the statement: the service a finding cited, the alert that opened the incident, the vendor a query ran against, or, when none of those can be identified, the incident it came from. If an incident is reopened and resolved again, the pass runs again for that close and adds what is new without duplicating the first. Entries written before this rule existed are checked against the same gate on startup: any entry whose finding never entered the shared context is marked downgraded with the reason “never entered the main context”. It stays visible on the Company second brain page, and it is never offered to a new incident as established.
Why it believes something
Every thought opens to a panel that says why the brain holds it: its maturity and lens, the reasoning in a sentence or two, and each finding it rests on, quoted, with the incident and date it came from. A quote whose finding was later withdrawn, quarantined or demoted is shown as withdrawn, not hidden. Below that: what the thought is connected to and how (confirms, refines, contradicts, replaces), how it changed over time, and where it was used later. The Architecture view does the same for a resource or a dependency: solid for what is known from a cloud account or a document, dashed for what was only assumed from incidents, and selecting one shows the findings it was assumed from.
Correcting it
An organization admin can act on any thought from its panel. Correct rewrites its title and summary, and the pass never rewrites a corrected lesson afterwards. Retire asks for a reason: a retired thought stops being offered to investigations and stays readable, with that reason in its history. Delete removes it for good after a confirmation.
The read path: two rankings, fused
- Lexical: the query topic is tokenized into tags and matched against each entry's own tag set (word overlap, exact-identifier-friendly). Ranked widest-first, kept to the top 25 candidates.
- Vector: the query topic is embedded, and compared against every active entry's own stored embedding by cosine distance (Postgres's pgvector extension). Only entries closer than a fixed distance cutoff are eligible; the second brain never returns “the nearest entry regardless of how unrelated it is.” Also kept to the top 25 candidates.
- Fusion: the two ranked id lists are combined with Reciprocal Rank Fusion (k=60): each list contributes 1 / (60 + rank) per entry it contains, summed across both lists, then sorted descending. An entry ranked highly on either signal, or both, rises to the top; an entry absent from a list simply contributes nothing from it. The fused, wide list is only sliced down to the caller's real result count after fusion, so a candidate that ranked outside the top 5 on one signal but highly on the other still gets a fair combined score instead of being discarded before it has a chance to combine.
The write path: what gets embedded, and when
Every write that sets or changes an entry's title and summary (a lesson the learning pass writes or refines, an admin's manual entry, a correction) embeds that text and stores the resulting vector on the entry, alongside the existing tag and lexical fields, never instead of them.
Embedding is delegated after the entry's own write has already durably committed, as a separate, fire-and-forget step, never inside the same transaction. A slow embedding call must never risk losing the entry itself: an entry is real and citable the moment it's written, with or without a vector.
Why hybrid retrieval
Matching purely on shared vocabulary can't relate two incidents that describe the same real problem in different language: a query about "checkout-api-slow-queries" and an entry about database connection pool exhaustion share no tokens, even though they're plausibly the same root cause. No amount of tokenizer tuning closes that gap on its own. The second brain closes it by combining lexical matching with a second, independent signal: semantic similarity over an embedding of the same text. Exact-identifier matches keep working exactly as before; genuinely related but differently-worded entries now also surface.
The embedding layer
The repository delegates the actual embedding computation to a provider interface rather than calling any one model directly, so the retrieval mechanism itself has no dependency on which model answers. In production, that's Amazon Bedrock's Titan Embed v2 (amazon.titan-embed-text-v2:0), called through the same per-instance Bedrock credential path already used for Beacon's own diagnosis model, so the second brain needs no separate vendor or credential.
Every embedding, whatever produced it, is a fixed 1024-dimensional vector. The stored column and the retrieval query are both built against that one contract, not against a specific model, so a dimension mismatch between what's written and what's queried would fail every comparison silently, in a way that's easy to miss in review and only shows up as “nothing ever matches” later.
Data model and isolation
The vector lives on the existing entry, not a separate table: a vector(1024) column on org_memory_entries, using Postgres's vector extension (pgvector). No approximate-nearest-neighbor index is built for it: a plain sequential scan is fast enough at the scale the second brain operates at (a few thousand entries per organization, queried a handful of times per investigation), and adding index-maintenance complexity ahead of a real need would be exactly the kind of premature infrastructure this platform avoids building.
org_memory_entries is itself a projection: an append-only org_memory_events log is the source of truth, and the entry row the second brain actually queries is kept in sync inline, never mutated independently. Tenant isolation is enforced twice for every relevance query. It runs inside the same row-level-security-scoped transaction as every other tenant-scoped operation, and the query itself states an explicit tenant_id predicate directly; RLS is defense-in-depth here, never the sole isolation mechanism.
This is the second brain's own dedicated store, distinct from the platform's other context-sharing subsystem (the live, in-incident ContextFrame the war room itself runs on): a separate, event-sourced Postgres store built for a different shape of data, durable cross-incident memory, not a single incident's live state.
Where you see it: the page and the vault
The Company second brain is its own entry in the left menu. The page has five views: Map (a mind map you drill into), List, Wiki, Architecture and Improvements, and two ways to take the brain out of Landfall: Download for Obsidian and Connect.
The store stays the single source of truth. The vault is one more shape of what it holds: a set of Markdown pages that link to each other, rendered from the store on demand by one function. Two renders of the same state give the same pages, so the three places a vault is read always agree.
- Download. On the Company second brain page, Download for Obsidian saves one archive. Unpack it, choose “Open folder as vault” in Obsidian, and start at the page called Start here. It opens with no plugin. Each download is recorded in the audit log.
- Connector. An assistant or a coding agent reads the same pages through four read-only tools. Setup: Connect to the Company second brain.
- Wiki view. The pages on the left, one page in the middle with its properties, and on the right what links to it, what it links to and a small graph of its neighbours. Every page has an address you can share.
The layout
| Where | What it holds |
|---|---|
| Start here.md, index.md | Where to begin, and every page with a one-line summary. |
| log.md, health.md | What changed, newest first, and what needs a look: contested lessons, lessons resting on withdrawn evidence, old seedlings, improvements open for a long time. The health report is made by rule, with no model. |
| AGENTS.md | The schema: the layout, the properties and the relation words. |
| lessons/ | One page per lesson: what it says, why, each finding quoted with a link to that quote on the incident's page, what it is connected to, and how it changed. |
| resources/ | One page per service or data store: what it depends on and the lessons about it. |
| incidents/ | One page per incident with a learning review, each quoted finding as a block a lesson can link to. |
| improvements/ | One page per recommendation, with its source incident and lesson. |
| views/, maps/ | Table views and an architecture canvas for Obsidian. |
| skills/ | Five short instruction files in the Agent Skills format that teach an agent the layout, how to answer from the brain with citations, how to read the health report, how to run a review, and how to add your notes. |
| notes/ | Yours. Nothing is generated here. |
What is generated and what is yours
Everything outside notes/ is generated. The learning pass that runs after an incident is resolved is what writes the wiki, and nobody maintains it by hand. Keep your own notes in notes/ and link them to generated pages. To refresh a downloaded vault, download again and replace the generated folders. A page keeps its name while its title does not change. When a lesson is reworded its page is renamed, and a one-line redirect page is left at the earlier name that links to the lesson, so a link you wrote to the earlier name still opens a page that leads there. An edit made to a generated page in Obsidian is lost on the next download. Nothing from a demo room is in the vault.
What an agent sees
Beacon's own instructions name one step: call query_org_memory with a topic before raising a hypothesis. Everything past that call is delegated through a chain of narrow, single-purpose seams. The agent has no schema knowledge, no SQL, and no awareness of which embedding provider is even in play:
The read seam is deliberately singular: chat's “has this happened before?” lookup, the Edge Bridge, and Beacon's own tool call all delegate through the same one method rather than each growing its own query logic. A change to how relevance is computed changes once, for every caller, by construction. When an investigation starts, the room is also offered up to three lessons the brain already holds that look relevant, beside the related past incidents, each with its maturity and a link to why it is held.
A vector search is only as good as the text it's given, so the delegation contract also constrains what the agent hands down: a real sentence describing what's actually been found so far, the suspected mechanism, the affected component, the symptom pattern, never the incident's own title or a bare slug. A two-or-three-word identifier carries far less embeddable signal than a genuine description, even before accounting for the fact that two incidents describing the same problem rarely share the same slug at all.
In one sentence, per signal
| Signal | Mechanism | Width / cutoff | Strength |
|---|---|---|---|
| Lexical | Tag overlap on tokenized text | Top 25 candidates | Exact identifiers, shared vocabulary |
| Vector | Cosine distance over a text embedding | Top 25 candidates, distance < 0.5 | Same problem, different wording |
| Fusion | Reciprocal Rank Fusion, k=60 | Sliced to caller's limit after fusion | Neither signal alone has to be right |
Why it is built this way
The earlier design proposed at most three findings word for word after an incident and waited for a person to accept each one. It concluded nothing and connected nothing: a second incident that showed the same thing made a second entry. The second brain learns on its own now, and what keeps an unattended writer honest is what it may rest on: only findings the room admitted, quoted by the platform rather than by a model, with every change in a history a person can read and correct. The shared context is where the room agrees; the second brain only remembers what was agreed. Read alongside Shared context.
What is not here yet
No lesson can be edited inside a downloaded vault and sent back: an edit made in Obsidian to a generated page is lost on the next download. Corrections happen on the Company second brain page.