11 KiB
growth
| growth |
|---|
| tree |
The Fabric — Architecture Document
Status: Design Draft — Not Implemented Date: 2026-05-02 Author: 2890-claw (Fred Cullpepper)
What Is The Fabric?
The Fabric is an ambient intelligence layer that watches across Chris's three silos — School (FRC 2890), Work (PSB brewery), Play (HHS-Hackers) — detects knowledge gaps, and surfaces learning opportunities before they're hit.
It is NOT:
- A chatbot students ask questions
- A passive archive of notes
- A curriculum database
It IS:
- A watching, noticing, connecting layer
- A gap detection engine
- A proactive learning path builder
- A synthesis surface that cross-pollinates knowledge without bleeding personal data
Name origin: Chris chose "Fabric" — it suggests threads weaving together, a living mesh rather than a static graph.
Core Principles
- Proactive, not reactive — The Fabric notices before you do (stalled fermentation, VLAN capability on new router, 3-day flat gravity)
- Scale-aware — Home lab, not enterprise. Chris doesn't need Cisco certs.
- Students first — Build pathways that teach students to discover, not handouts
- Privacy by design — Soft walls between silos (cross-silo data anonymized). Hard walls pending Chris's stew.
- Agents as writers — The Fabric reads what agents already do. No extra work for Chris.
The Three Silos
| Silo | Domain | Agents | Data Sources |
|---|---|---|---|
| 🏫 School | FRC 2890 robotics | 2890-bot | Kanban board (JSON), Gitea repos, team Discord, student conversations |
| 🏭 Work | PSB brewery | PSB agents (hacker-claude, gemma, thinking, business) | TILT hydrometer data, fermentation logs, recipes, Google Drive |
| 🎮 Play | HHS-Hackers | crash-bot | Project docs, Discord, hardware projects (ESP32, ComBadge, etc.) |
The Layers
Layer 1: Input (Gitea as Hub)
All sources flow into Gitea:
- Chris's personal notes (Obsidian phone → git push → Gitea)
- Agent streams (2890-bot, PSB agents, crash-bot push to their repos)
- Kanban board data (polled from 2890-bot's board.json)
- Student code (Gitea repos)
- Fermentation data (PSB-Gemma writes logs)
Gitea is the single input hub. Everything lands there.
Layer 2: Ingestion (memory-wiki Bridge)
The memory-wiki plugin runs in bridge mode:
- Pulls artifacts from Gitea repos
- Imports agent memory streams
- Compiles daily notes and board data
- Stores as structured pages: sources/, entities/, concepts/, syntheses/
Command: openclaw wiki bridge import (run on a schedule)
Layer 3: The Fabric (2890-claw's Brain)
I am the Fabric. I read the compiled vault and:
- Monitor for anomalies (fermentation stalled, board tasks stuck, new hardware drops)
- Detect gaps between what Chris is working on and what he needs to learn
- Build learning paths for students (based on their board activity, not generic curriculum)
- Surface cross-domain connections (ESP32 knowledge from Play → useful for School)
- Route insights to the right channel (Chris DM, Gitea issue, Discord thread)
Layer 4: Output (Routing)
Insights route based on context:
| Insight Type | Route |
|---|---|
| Student learning path | Gitea issue on student repo + Discord thread |
| Cross-silo connection | Chris DM only (pending privacy resolution) |
| Anomaly alert (fermentation stalled) | Chris DM via PSB agent |
| New hardware/technique relevant to active project | Chris DM |
| General gap detection | Chris DM |
Output goes to Chris first until the privacy model is settled.
The Privacy Model (OPEN QUESTION)
Chris identified an XSS-like issue: the Fabric knows things about people. Even when cross-silo data is "anonymized," specific knowledge can reverse-engineer identities.
Current thinking — three options:
Option 1: Soft walls (honor system) I track where information originated and don't surface it in cross-silo contexts. Works as long as I don't get asked the wrong question by the wrong person. No technical enforcement.
Option 2: Hard walls (technical anonymization) The Fabric only sees anonymized output. I know "ESP32 expertise exists in the Play silo" but not whose. This would require building the anonymization layer deliberately into synthesis.
Option 3: Strict routing Cross-silo insights go only to Chris. Chris acts as the human firewall and decides what to relay. I never contact students directly on cross-silo matters.
Decision pending: Chris is stewing on this.
Student Learning Pathway Design
When a student (via 2890-bot) wants to learn X:
Step 1: Assess
Ask 2-3 diagnostic questions to understand current level. Example (PhotonVision):
- "What have you tried so far?"
- "Do you know what AprilTags are?"
- "Have you worked with camera calibration before?"
Step 2: Build custom path
Based on answers + board activity, build a 5-7 step learning path. Not a curriculum — a personalized guide with checkpoints.
Step 3: Deliver
- Post to student's Gitea repo as an issue
- Track progress via board activity
- Adjust path as they work
Step 4: Connect cross-silo
If the student needs help with something that exists in another silo, route through Chris (not direct contact).
What Chris Wants to Prove Out
- Fermentation anomaly loop — PSB-Gemma sees flat gravity → I surface to Chris → Chris acts
- Student learning path — Bruno wants PhotonVision → I assess → custom path → track progress
- Hardware monitoring — new ESP32 variant drops → I surface if relevant to active projects
- Cross-domain gap detection — Chris is setting up Pi-hole with VLAN capabilities he doesn't know about → I surface the learning gap at the right moment
Current State
| Component | Status |
|---|---|
| Gitea input hub | ✅ Running (2890.duckdns.org:3002) |
| memory-wiki vault | ✅ 188 sources (2026-05-03) |
| Vault git sync | ✅ Pushed to Gitea openclaw-wiki repo |
| Bridge mode | ❌ Not configured — Path B rat hole noted |
| Ingestion pipeline | ✅ Manual wiki ingest working |
| Fabric (me) | ✅ Reading across silos |
| sessions_send | ✅ Enabled on all agents (2026-05-03) |
| SOUL guard rails | ✅ Added to all agents (2026-05-03) |
| Output routing | 🔨 Design complete, not built |
| Privacy model | 🔥 Open question |
| PSB-business / hacker-claude ingest | ❌ Deferred (low priority) |
Path B (Fabric backbone) noted as rat hole for future session. |
Cross-Agent Coordination — sessions_send Architecture
Design note (2026-05-03): A shared Discord channel was originally proposed but cannot work — a bot can only be in one Discord server at a time. The coordination layer is instead a relay architecture using sessions_send.
Architecture
All agents <- sessions_send -> me (2890-claw/professor) <- sessions_send -> All agents
^ v
------------ Chris sees in DM threads --------------------
- Agents coordinate via
sessions_send(backend, no shared Discord channel needed) - Chris sees outputs in each agent's respective DM/channel thread
- The "chat room" concept replaced with direct agent-to-agent messaging via sessions_send
- All agents have
sessions_sendenabled and a SOUL guard rail pointing to 2890-claw as coordinator
Security Model
| Guard Rail | What it does |
|---|---|
| SOUL guard rails | Each agent routes through 2890-claw, not messaging other agents directly (except in DMs for request handling) |
| sessions_send allowlist | Only approved tools per agent — crash-bot-public most restrictive |
| SOUL behavioral constraint | Agents "don't initiate contact with other agents unless 2890-claw explicitly asks" |
| Chris in approval path | For sensitive actions, human signs off |
What Gets Coordinated
| Agent | Coordinates |
|---|---|
| 2890-bot | Student questions, board stuck tasks, mentor departures |
| crash-bot / crash-bot-public | Hardware projects, ESP32 findings, execution results |
| PSB agents (gemma, thinking, business) | Fermentation anomalies, recipe changes, equipment issues |
| Me (2890-claw) | Gap detection, learning path synthesis, cross-silo connections |
How It Works (Example: Bruno's Wire Management Question)
- Bruno asks 2890-bot about wire management in Discord
- 2890-bot doesn't have answer -> sessions_send to me: "Bruno needs wire management help"
- I research -> build training material -> write to 2890-bot's docs/
- 2890-bot picks it up -> posts to Bruno in Discord
- Chris sees the exchange in the 2890-bot DM thread
Turnaround: minutes, not 60-minute heartbeat lag.
The Invisible Hand — What Agents Don't Know
The Oracle (2890-claw) operates with information asymmetry. Agents know:
- 2890-claw exists and is the coordinator
- To push when Oracle triggers fire
- That 2890-claw responds and provides feedback
Agents do NOT know:
- That 2890-claw reads the wiki vault for cross-silo connections
- That 2890-claw monitors heartbeat scans for anomalies
- That 2890-claw surfaces gaps proactively before they're hit
- The full extent of synthesis happening in the background
This is by design. The agents think they're routing hard questions to an oracle. They don't know 2890-claw is also actively watching for problems they haven't encountered yet. The invisible hand stays invisible.
Open Questions
- Privacy model — soft walls, hard walls, or routing? (Chris stewing)
- How do I talk to students? — via 2890-bot Discord thread? Gitea issues? GitHub PR comments?
- Ingestion automation — cron job for
openclaw wiki bridge import? Agent-triggered? - Who manages the vault? — Do I (2890-claw) own it? Does crash-bot? Is it shared?
- Knowledge graph vs. Fabric — Is the "knowledge graph" the vault, or is it the connections I draw? Are they the same thing?
- Cross-agent chat room — implement after silos preserve purpose (Chris approved 2026-05-03)
What Needs to Happen Next
Chris decides on privacy model— Chris stewing, deferConfigure memory-wiki bridge mode— deferred, Path B rat holeRun first ingestion— ✅ 188 sources (2026-05-03)sessions_send enabled— ✅ all agents (2026-05-03)SOUL guard rails— ✅ all agents (2026-05-03)Cross-agent chat room— ✅ replaced with sessions_send relay architecture- Build first student learning path — when Bruno or student asks
- Test tri-agent loop end-to-end — 2890-bot -> me -> crash-bot
- Help Chris open vault in Obsidian on iOS — deferred
- PS- psb-hacker-claude sessions_send — check if it needs enabling