Brain V2

• The engineering challenge

  • Knowledge about many projects has to live in one place that people and AI can both read.
  • Original sources must stay untouched, and what is derived from them must stay traceable.
  • An AI that can use tools needs hard limits that a clever prompt cannot talk around.
  • The knowledge, the app that shows it, the skills the AI may use and the rules around them have to fit one repository.

• Why a chat is not enough

  • A long chat forgets and drifts.
  • It cannot say where a claim came from.
  • A bigger prompt does not fix that; the reliability has to be engineered.
  • Knowledge has to stay useful across several projects without leaning on conversation history.

• What it has to guarantee

  • One canonical copy of each fact, with links instead of duplicates.
  • Answers that can be traced to a note and a version.
  • No private text in the browser, in logs, or in anything public.
  • Anyone reading a claim can check it against its source note.

• What I wanted to improve

  • Make the knowledge base the source of truth, not the chat.
  • Keep AI actions small, listed and permissioned.
  • Test the privacy boundaries instead of trusting them.
  • Keep knowledge reliable across several projects, not just one conversation.

How knowledge gets in and an answer gets out

• One canonical source

  The note vault is the source of truth. The dashboard, the answers and the skills all read from it. Nothing is copied into the chat and trusted from there.

• Provenance on every answer

  Retrieval is pinned to one fixed version of the notes and returns the note it used, so a claim can be checked later.

• Retrieval before generation

  The model sees only approved notes. When the notes do not cover a question, the answer fails closed instead of guessing.

• Small, specialized tools

  Each skill does one job and is described in a reviewed file. The file explains the tool; it never grants permission to run it.

• Permissions the AI cannot edit

  What may run is decided by the server through status and approval checks, not by the text of a skill or a note. Notes, web pages and documents are treated as untrusted data.

• 12

  Skill manifests

• 3

  Skills working

• 12

  Test files

• 6

  Security documents

• Dashboard

  A React and TypeScript app with a Node API. The 3D visual, charts, note graph, chat, skills and voice panels are all fed by owner-only requests.

• Server

  Separate modules for conversation, retrieval, memory, skills and security, so each can be tested alone.

• Checks

  Tests for the API, privacy, the vault boundary, retrieval, memory, skills and the lockdown switch, plus a continuous-integration run and a secret-scan run.

• Three layers that never overwrite each other

  Curated notes hold what I know. Approved memory holds what I chose to keep from conversations. Engineering notes hold how the AI coding tools should work. Each has one job.

• Memory that starts as a proposal

  A new memory is stored encrypted and marked proposed. Only approved, unexpired memories reach a conversation, and secrets are rejected before they are saved.

• Keyword retrieval first

  Retrieval today matches keywords across approved notes and returns citations. Searching by meaning is a goal, held back until the storage and privacy review is done.

• A counts-only snapshot

  The dashboard is built from a snapshot of counts and anonymous labels. It is served only to the signed-in owner and is never copied into public files.

• Skill registry

  The browser receives each skill's description, status and permissions. It never receives the skill's instructions, note text, credentials or memory.

• Bounded execution

  A skill runs through a dispatcher that limits time, can be cancelled and writes a redacted audit record. There is no autonomous loop, no shell access and no way to send a file path from the browser.

• A switch that turns skills off

  A deployment setting disables chosen skills, and it holds across restarts. A toggle in the dashboard is a convenience that lasts only for one running process, and the page says so.

• Voice, kept at arm's length

  The planned worker has no access to notes, memory, credentials or skills. It can only talk to the voice service and to one backend endpoint.

• Private by default

  Owner-only access, protected sessions, read-only note access, no way to write to the vault from the app, and no raw source files in answers.

• Fail closed

  If a check cannot confirm something, the request is refused. A missing note or an unapproved memory leads to no answer, not a guess.

• Tested boundaries

  Privacy and the vault boundary have their own tests, and a secret scan runs on every change. Test fixtures are built at run time so the scan stays clean.

• Verified locally

  Sign-in, reading approved notes, grounded answers, encrypted memory and skill execution have each passed local checks, some against real accounts.

• Built and tested locally

  Dashboard, owner-only access, approved-notes retrieval with citations, encrypted approval-first memory, three skills, the kill switch, audit logging and the policy documents.

• In progress

  The voice worker, durable skill controls (the deployment switch is durable, dashboard history is not yet) and a review of my own profile notes before any model may use them.

• Goals

  A hosted memory database, a model provider approved for private notes, search by meaning, a measured voice round trip, the nine blocked skills and a production deployment after the security checklist passes.

• Technical learnings

  • A skill file is documentation, not authority. Keeping the two apart made the permission model much easier to reason about.
  • A dashboard needs less data than it seems to. A counts-only snapshot kept the overview useful with no note text in the browser.
  • Failing closed is a feature. An assistant that says the notes do not cover something is easier to trust than a fluent guess.
  • A small local model proves grounding works, but speed decides whether it is usable. About 22 seconds an answer is too slow for conversation.
  • Small environment details matter. Folder links do not carry over well on Windows, so the reviewed skills are copied from one canonical source.

• What I did

  • Designed the knowledge structure and its rules.
  • Defined the permission and privacy model.
  • Developed the dashboard and API, working with AI coding assistants under my direction.
  • Set up the engineering notes that keep those assistants on task.

• What this shows

  • Full-stack work: React, TypeScript and a Node API.
  • Systems thinking: where truth lives, and who may do what.
  • Security habits: least privilege, fail-closed design and tested boundaries.