How to Build an AI Second Brain That Preserves Evidence and Context

I started with a practical problem: the periods when I most needed a record of my decisions were often the periods when I had the least time to write one. Meetings, email and messages already left traces. I wanted those traces to remain usable after a conversation with an AI ended. In my earlier description, I called the input REAL and drew a path through collection, memory and ontology to a single source of truth, or SSOT. That explained the idea. It left the difficult part inside the arrows. Here is a narrower account of how my meeting pipeline handles those arrows, including the boundary between receiving evidence and deciding what it means. What the layers actually do Layer Concrete responsibility in this example REAL / source A Google Meet transcript-generation event and the original utterance records it identifies. Collection An existing Workspace/Pub/Sub receiver validates and stores the event. A Node.js worker handles transport separately from dashboard work. Memory Local source and review records preserve references, utterances, versions and processing states. Derived experience retrieval has a separate responsibility. Ontology The logical relationships between source, meeting, review, role and task. The term does not establish that a graph database is installed. SSOT The shared Star canonical ledger, accessed through AgentOS. Writes carry identity, version and evidence checks. An input receipt and a substantive judgment remain different records. These responsibilities are not five mandatory products. For this path, the visible implementation uses JavaScript, Node.js worker threads, local atomic JSON persistence and API calls to the shared ledger. The existing Slack input path also uses SQLite and an outbox; it is a separate intake path. 1. A notification points to evidence A transcript-generation event identifies an artifact. It is not the transcript itself. My receiver decodes the event, checks the event type and resource identity, and preserves its ID and time. Smart-note events are treated separately; their arrival does not supply the actual utterances required for a transcript review. This distinction matters when a dashboard says “received.” Received can mean that a source notification was safely captured. It does not mean the transcript was read, a judgment was reached, or a follow-up action was approved. 2. Preserve the event before acknowledging it The intake path stores a valid event before acknowledging its delivery. Atomic JSON writes use a temporary file, flush it and rename it into place. Event identity and persisted state provide a way to recognize a repeated delivery instead of treating it as new work. Consider a crash after storage but before acknowledgement. The source can deliver again. The system should inspect the existing event and its state. Replaying the business action simply because the delivery repeated would confuse delivery recovery with work authorization. Malformed events have a separate rejected-input record. Failed source reads remain pending with a retry state. These are useful states: they show what still needs recovery without inventing completion. 3. Keep transport independent of a busy interface One failure in the integration changed the architecture. Synchronous dashboard work delayed Google requests in the same event loop. A dashboard could appear active while its source transport was falling behind. The correction was to move the transport loop into a Node.js worker. That worker handles reception and source reads; the parent workflow retains responsibility for review admission. Requests between them are correlated by ID. If the transport restarts, outstanding source-read requests are rejected rather than silently treated as completed. // Abridged from meeting-transport-worker.mjs const provider = new MeetGoogle(workerData.config); const history = new MeetingHistory({root: workerData.root}); await startMeetingReceiver({ history, provider, signal: abort.signal, checkpoint: workerData.checkpoint, drain: false, onCycle: connection => parentPort.postMessage({type: 'cycle', connection}) }); The associated October 13 integration record documents the fault and the worker correction. It is a historical verification record, not an uptime claim for every component today. 4. Read utterances and bind review to a source version The source reader requests transcript entries and keeps the speaker, text, start and end times. Review uses actual utterance records rather than an automatic meeting summary. The meeting history hashes the utterance set and tracks versions. Before adopting a review result, it checks that the current source version still matches the version that was reviewed. If a document revision changes while the API utterances remain unchanged, the implementation can hold the record for source reconciliation. It does not assume that the old API text incorporates the edit. That is an operational reason to retain provenance. A fluent summary cannot tell me whether the underlying document changed after it was produced. 5. Give a canonical write a precise meaning My input synchronization writes a small receipt to the shared ledger. It contains source identity, a source hash, a version and processing state. The original private text stays with its source. This receipt makes intake and processing traceable; it does not automatically turn every statement in the meeting into a current belief or policy. The canonical client reads the exact key, verifies schema, source hash and version, then writes with the expected revision. It rereads after the attempt, including when the request times out. // Abridged from CanonicalClient.saveInput; receipt description translated. const prior = await exactTask(this.call.bind(this), key); // Validate sourceHash, schema and incoming version. const body = { key, title: record.title, status: 'done', next_action: 'Input receipt; not business completion or execution approval.', evidence, expected_revision: prior?.revision ?? 0 }; try { await this.call('agent_save_task', body); } catch (error) { failure = error; } // A timeout may have committed. Read before retrying. const check = await exactTask(this.call.bind(this), key); if (check?.payload.evidence === evidence) return {key: check.key, revision: check.revision, canonical: 'verified'}; A successful receipt has a limited meaning. The receipt's “done” state confirms that record, not completion of the business task described by the source. Canonical persistence, review, dashboard projection and external execution each need their own evidence. 6. Evidence does not adopt itself The companion paper How Do Divided Judgments Become One Action? separates a factual claim, an adopted rule, an individual decision and permission to execute. I use that distinction to ask four questions: What happened? What interpretation is justified? Who may adopt it as a current rule or decision? What action is actually authorized? A second companion paper, How Do We Become One Organization?, adds a related test: a reference can exist without supporting the judgment that cites it. An exact source ID or matching hash establishes identity and integrity. It cannot establish that a quoted rule permits the proposed action, or that the source statement is true. Those papers propose broader governance designs, including review and adoption paths. Their fictional cases are not measurements of my deployed pipeline. The implementation evidence here is the narrower intake, version and receipt path described above. A useful way to build the next piece In my draft FDE Delta curriculum, each stage starts with three questions: what the previous stage made possible, what the person still has to supply, and what structure that burden calls for. Its data foundation asks that a record retain who spoke, when it applied, whether it is opinion or decision, and its scope. For an implementation exercise, I would take one source and define seven items before adding autonomy: Goal, Context, Evidence, Rules, Criteria, Loop and State. What is the job? Which sources may it use? What counts as a valid result? What can it change? When should it retry, stop or ask? Where is progress recorded? This is a proposed exercise, not a claim that a seven-day curriculum has already produced measured outcomes. The next useful test is small: receive one event twice, interrupt processing once, change the source version, and check what the system preserves, repeats and refuses to call complete. A system that can explain those states gives me a firmer foundation for memory than a diagram whose arrows have no implementation behind them. Limits and sources Capture covers configured, authenticated sources. Subscription expiry, network outages, a stopped PC, storage failures and transcription errors remain possible. Captured records require interpretation and can still be wrong. No accuracy gain or time saving is claimed here. Implementation reviewed: meeting-google.mjs, meeting-history.mjs, meeting-transport-worker.mjs, and the canonical input-sync client in my private Star dashboard repository. The companion whitepapers and the Delta curriculum are design sources, with fictional examples and proposed exercises identified as such. Super Second Brain is Hanul Lee's ongoing work on memory, judgment, and human agency. This article expands the architecture discussion in the original Chapter 2. The conceptual diagrams and companion whitepapers belong to the author's ongoing series.