A worked example of [[Build a Shared Brain|building a shared second brain]] at cross-team scale, traced through [[Knowledge mapping|the three acts]]: decompose, place in containers and judge state, then match a method. Extends the [[Shared second brain example - ADR log|ADR log example]] - same organisation, six months later, having outgrown a decision-only log. ![[Shared second brain example - Expertise Radar.canvas]] ## Summary 1. Prompt *"we have a notification problem - who's solved this, and with what?"* - the ADR log has decisions but not experts, tools, or problem classes 2. Experts 🟣 tacit, tools 🟡 buried in decision prose, problem classes 🔴 absent as first-class entities - the decision log cannot answer it 3. Linked databases ([[Expertise Radar]]) - problems, tools, experts, projects, decisions as cross-referenced entities 4. [implementation] [[Notion]] with linked databases ^summary ## Starting point ![[Shared second brain example - ADR log#^summary]] That works for *what did we decide?*. It fails when the question shifts. ## The acts in one line each Prompt *"who's solved a notification problem, and with what?"* decomposes into the problem class, the projects that hit it, the experts who worked them, the tools they tried, and the decisions made - but only *decisions* are written as entities; the rest is implicit. ^trail-line Where each piece lives: the decisions sit in the shared ADR log (🟢); the **experts** ("who knows X") are 🟣 tacit, in people's heads; the **tools tried** are 🟡 - buried inside decision prose with no way to query across; the **problem classes** are 🔴 absent as first-class entities. Bus factor: the same senior engineers who track it all informally. ^profile-line Promote experts, tools, and problems to first-class, cross-referenced entities in a linked-database graph ([[Expertise Radar]]) - traversable from any direction, single-sourced, stewarded by the engineers who already track them. ^method-line ## Full walkthrough ### Act 1 — dependencies Same organisation as the ADR log example, six months later. The shared decision log answers *what did we decide, and why?* Now a different question arrives: *"We have a notification problem on this new project - who has solved one before, and with what?"* Decompose what answering it depends on: - the **problem class** - "notifications" as a recurring thing, not a one-off; - the **projects** that hit that problem; - the **experts** who worked those projects; - the **tools** they tried, and the **decisions** they reached. The cone needs experts, tools, and problems as things you can name and follow. Traced down, only the *decisions* are written as such; everything the question actually pivots on - the who, the what-tool, the what-problem-class - is implicit. What state each is in is the next act. ### Act 2 — containers Place each leaf in its container, and colour it: - **The decisions** - in the shared [[Decision log|ADR log]] from the previous layer: 🟢 defined. - **The experts** ("who knows event buses / notifications") - written nowhere as data; held in people's heads: 🟣 tacit. - **The tools tried** - present, but buried inside decision-rationale prose with no way to query across them: 🟡 no single source. - **The problem classes** - not modelled at all; only decisions are entities: 🔴 absent. The board shows the gap precisely: the decision log solved *one* dimension, and the new question needs four more - each either tacit, buried, or unmodelled. The same brokers from the ADR log example - senior engineers who already track tool usage and expertise informally - are the bus factor and the steward candidates. A board for this example: [[Shared second brain example - Expertise Radar.canvas|the cone, coloured]]. ### Act 3 — method Read the move off each colour: - 🔴 absent problem classes → **author** them as first-class entities; - 🟡 buried tools → **single-source** them into their own queryable database; - 🟣 tacit experts → **capture** who-knows-what as expert entries; - and **link** every entity to the others so the graph is traversable from any node. The moves converge on a linked-database pattern following the [[Expertise Radar]] convention - one database per entity (problems, tools, experts, projects, decisions), cross-referenced. The discipline: every decision tagged with its problem and the tools considered; every expert tagged with their projects and hands-on tools; every problem tagged with the projects where it appeared. Query by traversal - pick any starting node, walk the graph. The senior-engineer brokers are the containers accountable for keeping it current. ### Tool (illustrative, after the workshop) [[Notion]] with linked databases - relations between Problems, Tools, Experts, Projects, and Decisions; queryable from any entry; comfortable for non-engineers to read; in the same workspace as task management. The same workshop would land on a different tool if the room's non-negotiables included offline-first ([[Obsidian]] with graph plugins) or a compliance-grade audit trail (a more rigid DMS).