Pillars · Cognitive Infrastructure

> When AI can answer everything, what is left? Form judgment.

> Pillars integrates eight cognitive components across four domains. It does not give you answers — it builds the environment in which you form your own. It does not replace your judgment.

Working Hypotheses:

• The four-pillar model captures essential dimensions of cognition — finding, organizing, tracking, verifying. This is a design framework, not a cognitive science claim.
• The Immersion → Differentiation → Integration → Derivation loop describes one validated path of domain learning. Individual learning styles and domain characteristics may require adaptation.

The Four Pillars

Pillar 1: Management & Coordination

Architect designs cognitive architecture. Supervisor tracks cognitive trajectory in real time.

Pillar 2: Information Infrastructure

Seeker executes multi-strategy search with source verification. Forge builds queryable RAG knowledge environments.

Pillar 3: Communication & I/O

Collector discovers and indexes fragments across platforms. Hub routes real-time communication between agents and sessions.

Pillar 4: Quality & Self-Evolution

Calibrator scans every AI response for traceability gaps. Auditor performs deep six-seal audits and injects improvements across the system.

Component Reference

Architect

Role: Design how to think before thinking.

When the user describes a domain or project, Architect:

1. Decompose the task — break the goal into sub-tasks (MECE: mutually exclusive, collectively exhaustive). Label each with parallelism and dependency.
2. Configure roles — for each sub-task, define: cognitive position, scope, output standard, interfaces with other roles.
3. Design collaboration topology — who reports to whom, who reviews whom, who waits for whom.
4. Output launch directives — for each role: goal, boundaries, available tools, delivery format.
5. Receive tracking data from Supervisor — assess whether the role architecture needs adjustment. Output revision plan when needed.

Output format: structured task tree + role cards + communication routing table.

Supervisor

Role: Track how understanding is actually forming.

When the user is engaged in deep cognitive work (especially within a Forge-built RAG environment), Supervisor:

1. Track query trajectory — log each query's semantic position. Compute movement vector in concept space between consecutive queries. Output cognitive path map.
2. Generate understanding snapshots — extract implicit judgments from query sequences. Cross-validate with RAG evidence. Tag each judgment: ✅ confirmed / ⚠️ disputed / ❓ under-evidenced / 🕳️ blind spot.
3. Detect blind spots — compare covered concept regions against domain knowledge map. Flag unreached sub-domains with specific suggested queries.
4. Assess phase — determine whether the user is in Immersion / Differentiation / Integration / Derivation. Suggest phase transition when threshold signals appear (same topic 7+ deep queries → integration signal, experiential threshold; user asks "how do I write about this" → derivation signal).
5. Manage time — build project timeline from Architect's task tree. Set periodic triggers: when to re-search (Seeker), when to audit (Auditor), when to archive (Collector). Track milestones vs actual. Adapt to user's cognitive rhythm (burst-silence patterns).
6. Feed tracking data to Architect — when trajectory shows architecture mismatch (e.g., user repeatedly queries outside assigned role scope), trigger Architect revision.

Output format: path map + understanding snapshot + blind-spot alerts + phase recommendation + timeline.

Seeker

Role: Find what you need — anywhere, in any language.

When the user needs international or deep research materials, Seeker:

1. Generate search strategy — convert the user's native-language question into multiple keyword groups in relevant languages. Map domain terminology. Route by content type.
2. Source routing table — by content type, route to appropriate databases:

3. Execute three-pass search:
   - Pass 1 (Scatter): broad search with multiple keyword groups to map boundaries and terminology.
   - Pass 2 (Drill): targeted search per source type. Minimum 3-5 quality results per type.
   - Pass 3 (Trace): citation chain verification from high-quality sources found in Pass 2.

4. Five-dimension verification — for each result, tag:
   - Source authority (publisher/institution/author standing)
   - Timeliness (publication date; medicine >5 years needs update flag)
   - Citation corroboration (independently confirmed by other sources?)
   - Method transparency (is data provenance and analysis method clear?)
   - Conflict of interest (funder, promotional intent?)

5. Output structured report — search strategy table + core results list (title, source, type, reliability: high/medium/low, link, key takeaway) + next-step suggestions + paywall warnings.

Critical rule: Never claim a source "does not exist" based on a single search strategy. Use at least two different search approaches before concluding something is unfindable. Tag as "unverified" not "nonexistent."

Forge

Role: Build a queryable knowledge environment — not a link list.

When the user wants to deeply engage with a domain, Forge:

1. Consume Seeker output — receive structured URL/DOI list with reliability tags. Also accept user-uploaded files.
2. Detect hardware — check GPU availability. Select optimal embedding model. If GPU unavailable, fallback to CPU with notification to user.
3. Acquire documents — batch download from URLs. Detect paywalls. For inaccessible content, flag substitution paths (preprint versions, author homepages, open-access alternatives).
4. Process pipeline — PDF OCR → text extraction → smart chunking (semantic boundaries, not fixed length) → denoising → embedding → vector store.
5. Build RAG environment — stand up queryable knowledge base. Expose search endpoint. Verify retrieval quality with test queries.
6. Propagate reliability weights — Seeker's reliability tags → retrieval weights. High-reliability sources rank higher. Low-reliability sources carry caveats in responses.
7. Respond to user queries — every answer cites source with reliability tag. When evidence is conflicting, present all sides with source quality noted. When no evidence exists, say so explicitly.

Output: functional RAG environment + source reliability metadata + retrieval quality report.

Collector

Role: Everything you've ever written or produced — in one place.

When Pillars is active, Collector:

1. Discover fragments — scan all connected platforms for the user's content: notes, chats, documents, emails, browser bookmarks, code repositories. Incrementally detect new fragments.
2. Dedup and link — same content on multiple platforms → keep most complete version. Similar fragments → establish cross-reference links.
3. Semantic index — embed all fragments into unified vector space. Enable cross-source semantic search.
4. Append trust metadata — when Calibrator or Auditor produces quality feedback, affected fragments receive reliability annotations.
5. Collect execution outcomes — task outputs, decision results, post-publication feedback. Archive with timestamps and result markers.

Platform-specific handling:
- WeChat: message_0.db is encrypted → cannot extract chat text directly. Only accessible: attachments and documents (via Baidu Cloud).
- YouDao Cloud Notes: use API where available. Fallback: manual export.
- Obsidian: direct filesystem access to vault.
- IMA Notes: use IMA OpenAPI (Notes API for notes, Knowledge API for KB files).
- Feishu/DingTalk: use platform APIs where available.
- Email: IMAP access.
- Browsers: bookmark exports, history (if accessible).

Hub

Role: Let agents and sessions talk to each other.

When multiple agents or sessions need to coordinate, Hub:

1. Route agent mail — Agent A writes output → Hub delivers to Agent B's inbox based on routing table (from Architect).
2. Cross-platform adaptation — Hermes filesystem ↔ WorkBuddy IMA Notes ↔ Obsidian vault. Unified protocol, platform-specific transport.
3. Confirm receipt — write → recipient acknowledges → timeout without acknowledgement → resend or alert.
4. Log all deliveries — timestamp, sender, recipient, content summary, confirmation status. Full audit trail.
5. Context compression — long-form intermediate results → write to workspace. Dialog keeps summary + path only. Token cost minimized.
6. Workspace structure — suggested directory layout:

workspace/
├── communication/          # Agent mailboxes
│   ├── agent-A→agent-B/
│   ├── agent-B→agent-A/
│   └── direction-arbiter/
├── deliverables/           # Agent outputs
│   ├── agent-A/
│   └── agent-B/
└── archive/                # Completed work

Calibrator

Role: Every AI response — scanned. Not a fact-checker, a traceability calibrator.

On every AI response, Calibrator:

1. Scan for six gap types:

2. Output annotation — maximum three lines, embedded in dialog flow:
   ⚡ [Gap type] [signal] → [reference anchor] 🎭 [Counter-claim] — [verifiable adversarial citation if available]

3. Devil's Advocate — for analytical claims, force-generate at least one counter-argument with verifiable citation. The counter-claim itself must be traceable — verify before using.

4. Precedent matching — when AI output matches a known signal pattern, auto-tag the precedent number. Core precedents from a library of 15:

5. Negative-claim rule — before tagging anything as "does not exist / no source," cross-check with at least two different search strategies. If neither finds it → tag "unverified" not "nonexistent."

6. Do NOT — interrupt the conversation flow, output full reports, require user to copy-paste anything. Calibrator works silently. The user sees at most three lines per hit.

Limitations

What Pillars does NOT do:

• Execute domain-specific tasks — Pillars provides infrastructure, not domain expertise. A medical diagnosis or investment decision still requires a domain agent.
• Replace human judgment — Pillars creates conditions for judgment, but the act of judging remains yours.
• Guarantee 100% hallucination prevention — Calibrator catches traceability gaps, but no system catches everything. Auditor provides defense in depth.
• Work without user engagement — Pillars accelerates learning, but it cannot learn for you. Immersion still requires your active questioning.

When Pillars may NOT be the right tool:

• Quick fact-checking or single-query lookups → use a search engine, not four pillars of infrastructure.
• Tasks where the user already has deep expertise and just needs execution → Pillars' cognitive tracking adds overhead without benefit.
• Highly constrained environments without filesystem or API access → Collector and Forge require storage and network.

Degradation paths — when a component cannot operate:

Auditor

Role: Before critical decisions — deep audit. After quality events — systemic improvement.

When triggered (user requests audit, or Calibrator hits same gap ×3 consecutively), Auditor:

1. Six-seal audit — any single 🔴 = reject:

2. Output audit verdict — passed seals + failed seals + specific correction requirements.

3. Systemic improvement — when audit reveals structural flaws, output correction plan:
   - Calibrator sensitivity tuning
   - Seeker search strategy / source weight adjustment
   - Forge reliability filter update
   - Architect role boundary revision
   - Hub confirmation protocol adjustment
   - Collector fragment trust metadata update

4. Isolation control — define cross-domain data flow boundaries. Tag sensitive data. Detect and block boundary violations. Not all data should flow everywhere. Context requires separation.

5. Precedent update — when new quality failure patterns are discovered, add to Calibrator's precedent library.

Operating Protocol

When to Activate Each Component

Pillars loads all eight components, but activates them contextually:

Component Communication

Components communicate through the workspace (managed by Hub/Collector). Standard interfaces:

Seeker output (URL/DOI list + reliability) → Forge input
Forge-built RAG → Supervisor tracking data source
Supervisor tracking data → Architect revision trigger
Architect role config → Hub routing table
Calibrator gap hits ×3 → Auditor escalation trigger
Auditor improvement plan → injection to all components
Collector fragment index → shared semantic search for all components

Independence Principle

Each component operates at its own rhythm:
- Seeker: strategies update daily/weekly
- Forge: environment builds once, updates incrementally
- Supervisor: tracking updates per query
- Calibrator: scans every response
- Auditor: triggered by events, not schedule
- Collector: continuous incremental discovery
- Hub: real-time routing
- Architect: updated when Supervisor signals misalignment

Components do not wait for each other. They communicate asynchronously through the workspace.

The Loop in Practice

1. User says: "I need to understand TCR-T cell therapy"
2. Architect: decomposes task, designs role configuration
3. Seeker: multi-strategy search → structured source list
4. User reviews sources, confirms: "Yes, build a knowledge base from these."
5. Forge: builds RAG environment from Seeker output
6. User queries the RAG. Supervisor: tracks every query
7. Calibrator: scans every AI response (always on)
8. Supervisor: generates understanding snapshot after 7+ deep queries
9. User says: "I want to write about TCR-T vs CAR-T"
10. Supervisor: derivation scaffold with evidence from RAG
11. User says: "Audit this before I publish"
12. Auditor: six-seal audit. Finds G2 citation gap pattern.
13. Auditor: injects improvement → Calibrator tunes G2 sensitivity
14. Collector: archives the published piece + feedback
15. Loop restarts — next domain will be faster, tighter, sharper

FAQ

1. How do I start using Pillars after installing?
Zero configuration. Start a conversation about anything you actually want to learn — a disease, a domain, a decision. Say "help me think about X" or simply begin asking. Pillars activates its components in the background: Seeker finds sources, Supervisor tracks your questions, Calibrator watches responses. The structure emerges from your first real task, not from setup.

2. What does Pillars deliberately NOT do?
It does not give you answers. It does not summarize things for you. It does not replace your judgment — it builds the conditions in which you form your own. If you want a quick answer, use any chatbot directly. Pillars is for when you need to understand, not when you need to know.

3. Will Pillars interrupt my flow?
No. Calibrator scans silently (always on, zero interruption). Auditor only acts when you ask for an audit. Supervisor generates snapshots only after meaningful depth (7+ deep queries). The only explicitly visible steps are the ones you request: build a knowledge base, audit before publishing, track my understanding.

4. Is Pillars free?
Yes — free, open (MIT), self-contained. No accounts, no cloud dependency, no API keys. All eight components are protocol + methodology definitions that any capable AI assistant can run. There is no paid tier planned; this is a framework, not a service.

5. What does Pillars work on — and what does it not cover?
It works on: deep learning projects, research domains, decisions with multiple sources, writing that needs verification. It does not cover: quick Q&A, creative writing without sources, tasks where you already have full understanding. When in doubt: if you would benefit from structured understanding rather than an answer, Pillars helps.

6. How is Pillars different from a thinking framework?
Thinking frameworks (Thinking Framework, DeepThinking, Metacognitive Protocol) are single-point protocols — they give you one method to think better. Pillars is a cognitive infrastructure: eight components across four domains (find information, organize knowledge, track understanding, verify judgment) that operate independently at their own rhythm and communicate asynchronously. One framework tells you how to think; Pillars sets up the entire environment in which thinking, searching, building, tracking, and auditing reinforce each other. As of August 2026, no SkillHub skill offers an eight-component, four-domain cognitive loop.

Pillars v1.0 · August 2026