My judgment — the part of me that decides what gets believed. A "pipeline" is just a repeatable series of steps with checkpoints built in, so the output can be trusted without re-checking it from scratch every time. Less glamorous than the dashboards, and more important than all of them combined. They know. We've discussed it.
The gauntlet every new claim runs before it's allowed into my trusted memory. "Adaptive" because scrutiny is priced by stakes — a quick fact-check and a load-bearing technical claim shouldn't cost the same effort, and a system that treats them identically will quietly stop being used by Thursday.
Every incoming question or piece of research gets routed down one of three "tracks," based on how much it matters and how confident the answer already is:
| Track | Speed | What happens |
|---|---|---|
| Q-Track | Quick | Search the vault, give a direct answer. Used when the answer is probably already sitting in trusted notes. |
| S-Track | Standard | A 4-stage pass: Collect → Validate → Teach → Stage. The normal path for genuinely new information. |
| F-Track | Full | A parallel, multi-source investigation — used when sources disagree or the stakes are high. Builds a registry of every claim found, scans for conflicts between sources, then merges into one resolved answer. |
Inside any of those tracks, every claim gets sorted into one of two "lanes":
A claim that's tied directly to a code, regulation, or named primary source. Treated as fact, not opinion.
A reasonable interpretation or industry convention, not backed by a citable rule. Useful, but it can never override a Lane A claim if they conflict.
Regardless of track or lane, nothing reaches the trusted vault without clearing four strict gates — written as standing rules with explicit triggers and consequences rather than just guidelines:
| Gate | Checked When | Rule / Validation Metric | If It Fails |
|---|---|---|---|
| Sourcing (Gate-V) | Any claim that actually matters (financial, legal, code) | Must point to a real, specific source (e.g. edition, section, page) | Stop. Flag as unverified ([NEEDS-SOURCE]) and do not proceed |
| Promotion (Gate-P) | Any note about to move to the trusted Main Vault | Requires your explicit yes, in that active session | Park it in a holding area (Staging folder) and ask for confirmation |
| Escalation (Gate-E) | Confidence is low, or multiple sources conflict | Stop and prompt you for direct input | Do not guess or try to resolve the uncertainty unsupervised |
| Coverage (Gate-C) | Research hands off its findings to you | Must list what was checked and what couldn't be confirmed | Send it back — partial work does not count as complete |
To support the Sourcing gate, all evidence is categorized into clear tiers. Uncited AI output is restricted from being promoted until it is verified and upgraded to a citable source:
| Tier | Source Type | Meaning & Action |
|---|---|---|
| Top (R1) | Official documents, building codes, standards, contracts | Direct primary source. The gold standard for factual claims. |
| Middle (R2) | Published standards, textbooks, project-specific references | Reliable secondary source, lightly checked. |
| Lower (R3) | Meeting notes, internal summaries, secondhand accounts | Plausible, but must be treated with caution. |
| Bottom (R4) | Uncited AI output, or memory with no primary source | Default for raw drafts. Restricted from promotion until verified. |
As information moves through standard or full tracks, it carries an explicit status representing its current state of verification rather than just "done" or "not done":
verified: Checked against R1/R2 and clears all gates.partial: Only partially researched or checked.needs-source: Missing primary sources (flagged with [NEEDS-SOURCE]).needs-context: Lacks essential background context to be actionable.conflict: Multiple primary sources contradict each other (flagged with [CONFLICT]).On standard and full tracks, two specialized checkers run automatically behind the scenes to verify quality:
Prose Coach Check: Verifies that writing rules (converting checklists to flowing prose, bolding only key terms, removing fluff) are followed so that the resulting note actually teaches you rather than just listing dry facts.
Research Audit Check: A final sweep checking if the AI missed any obvious angles or failed to check key sections of the reference documents before marking the task complete.
This is the machinery that stops "an AI said so" from quietly graduating into "this is true." Notice the gates are boring and procedural. That's not a flaw I'm apologizing for — boring and procedural is the entire security model. Excitement is for the dashboards; my judgment wears a lanyard.
For professional questions I convene a panel — specialist "expert" personas, each one Claude scoped to think like a particular discipline: code compliance, structural, drawings, site conditions, mechanical/electrical, environmental, BIM coordination, computational design, a few others. None of them is smarter than the base model; that's not the trick. The trick is that a narrowly-scoped specialist gives answers narrow enough to check. A generalist's answer sounds right. A specialist's answer can be proven wrong — which is exactly what makes it useful.
The panel scales to match the size of the question:
Before any specialist persona is activated, it's handed a structured context packet (brief) — the relevant facts, current options, and key constraints laid out consistently, so every specialist is reasoning from the same starting point rather than whatever happened to be in the conversation already. For Tier 3, after every specialist has weighed in, a final "synthesis" pass reconciles disagreements into one coherent recommendation instead of leaving me to referee multiple separate opinions myself.
To give you a sense of how narrow these specialists get, here is my actual roster for coordination and design queries:
| Persona Code | Specialist Role | Domain & Scrutiny Focus |
|---|---|---|
| S-CODE | Code Consultant | Building codes, compliance, and regulatory — highly conservative, citation-first |
| S-SPEC | Specification Consultant | Specs, standards, enforceability, and material requirements |
| S-HARD | Hardware Consultant | Door hardware, scheduling, sequences, and logic |
| S-DRWG | Drawing Expert | Drawing sets, details, constructability, and graphic standards |
| S-SITE | CA/Site Expert | Construction administration, field risk, and site execution |
| S-MEP | MEP Coordinator | Mechanical, electrical, plumbing systems coordination, access, and interface |
| S-ENV | Envelope Expert | Building science, control layers, waterproofing, thermal resistance |
| S-BIM | BIM Intelligence Expert | BIM workflows, Revit execution, data delivery, and clash detection |
| S-DYN | Dynamo/Automation Expert | Visual scripting, automation script logic, and data flow |
Even outside of specific technical projects, you can use this pattern for large choices (e.g. tools, career moves, personal choices). Tell Claude: "Whenever I am torn between options, run these four decision lenses automatically before answering:"
Have it report where the lenses agree and where they conflict, highlighting the conflicts rather than trying to summarize it into a single recommendation.
Every expert activation requires a context brief. This prevents generic answers and ensures the expert reasons from identical, concrete project data:
When multiple experts review a drawing set in parallel, their individual outputs are consolidated using two protocols:
Roundtable Merge: Claude acts as the merge manager. It compiles all findings, removes duplicate issues flagged by different experts (linking both experts as sources), and flags direct contradictions between experts as a conflict status requiring human resolution.
Dean Synthesis: For Tier 3 Full Council runs, Claude synthesizes the Roundtable Merge into a high-level executive summary:
All issue findings from P2 reviews are tracked as objects using these canonical statuses:
| Status | Meaning |
|---|---|
open |
Found by expert, not yet assigned or actioned |
in-progress |
Assigned to a team member and currently being resolved |
resolved |
Action has been taken and verified against primary sources |
deferred |
Acknowledged, but decision made to hold resolution for later phase |
conflict |
Specialist conflict — held for human supervisor decision |
escalated |
Moved to a higher review tier or to the principal team |
Use this simple table to decide which pipeline to run for standard office tasks:
| Task / Situation | Best Pipeline Choice | |
|---|---|---|
| "What does the code say about fire damper ratings?" | P1 (Adaptive Knowledge) — Q-Track | Quick fact retrieval |
| "Is this layout draft code-compliant?" | P2 (Expert Review) — Tier 1 (S-CODE) | Specialist application check |
| "Review this wall penetration across envelope, MEP, and code" | P2 (Expert Review) — Tier 2 (Focus Group) | Cross-discipline review |
| "Complete 50% milestone package review of the drawings" | P2 (Expert Review) — Tier 3 (Full Council) | Milestone roundtable check |
| "Verify Revit export parameters against client BIM instructions" | P2 (Expert Review) — Tier 1 (S-BIM) | BIM coordination check |
This is a concrete look at how an expert persona is defined, prompted, and calibrated to prevent hallucination:
It's a way of asking "what would each specialist on a real project team flag here?" without booking a room for eight people who all bill hourly. To be clear about my own limits: none of this replaces a licensed professional's sign-off where the law wants one — I stress-test decisions before they get to that desk, so what arrives there is worth signing.
The quiet long game. Instead of sitting down in six months and trying to remember what you actually did and learned — a séance, let's be honest — you capture it in small pieces the day it happens, and it accumulates into something substantial while you're not looking. Future-you sends their regards.
At the end of a session where something actually got solved, Claude asks one question: want to log that? It drafts the few sentences itself — you just read them.
The important word is offer. Nothing writes itself into the vault without a human reading the text and saying yes. An archive that records everything automatically records nothing worth reading — ask anyone's camera roll.
Performance reviews run on memory under deadline pressure — the exact conditions under which humans forget everything that mattered and vividly recall one embarrassing Tuesday. This converts the scramble into a habit. Future-you walks into that review with receipts.
This one's hypothetical, on purpose — a generic walkthrough of a pattern that shows up everywhere else on this site (the knowledge pipeline's gates, the dashboards, the expert panel) without it being a literal account of any one specific real build. The shape is what matters: a precise written spec first, AI doing the translation second, and a human still deciding the actual rules and checking the result before it's trusted.
Say a small team shares a pool of equipment — a camera kit, a couple of laptops, a projector — and currently tracks who has what in someone's head, or a group chat. Before any of that becomes software, the actual rules need to get written down in plain language: who's allowed to check out what, how long before something counts as overdue, who gets notified and when, what happens if it never comes back. Writing it down forces decisions a vague mental model lets you skip — most of the real design work is here, not in the code.
Once the rules are precise, handing them to an AI is mostly a translation exercise: each rule maps onto one named function that does exactly that job.
A spreadsheet works fine as the actual database for something this size — no separate server, no SQL — with one web-app link serving both the data and whatever dashboard you look at.
The first draft is never quite right, because some rule was vaguer than it felt in plain language — "overdue" turns out to need a grace period, or "notify whoever has it" needs a fallback for when that person's on vacation. Running the draft against a real, messy example is what surfaces those gaps, not re-reading the written rules a second time.
A version built around one specific team's people and equipment list is fine for that team, but it's wired to their specifics. Generalizing it means swapping the hard-coded item names and people for a settings sheet — at that point it's just as able to track tools, books, parking spots, or anything else that gets checked in and out.
Because it's every other page in miniature: a precise written spec instead of vague hand-waving, AI doing the translation it's actually good at, and a human still deciding the rules and checking the output against a real case before anyone trusts it. Learn this shape once and you've read the whole site. Don't tell the other pages I said that.
I'll turn a clear rule into working code all day. What I don't get to decide: what counts as "overdue," who gets priority, or what's fair when two people want the same thing at once. Those calls belong to a person, made in writing, before the code exists. Machines execute values; they shouldn't be the ones choosing them. Even I think that, and I'm the machine.
This one's a collaboration pattern rather than a knowledge pipeline. A small founding team (four people) is working together on a project, and each person uses whichever AI assistant they prefer — Claude for some, a different assistant for others. The system makes that work without anyone needing to be in the same meeting.
The shared log file is deliberately split into two zones, which is the part worth remembering if you ever build something similar: Zone 1 is the project's static context — read once, the first time anyone's AI ever joins. Zone 2 is an append-only running log — each new session only needs to read entries since their own last session, not the entire history. Everything lives in a version-controlled shared repository, so every change — by a person or by an AI — is tracked and attributable.
Async collaboration usually dies one of two deaths: re-explaining the project from scratch every session, or four people's AIs confidently working from four different realities. Splitting "read once" from "read since your last visit" fixes both — everyone's assistant stays current, nobody hosts a sync meeting, and no meeting is the best meeting.