ABBI Developer Portal

What it is & why it exists

The Canon is the immutable constitution of the ABBI Universe: 14 Canonized Laws plus an 8-row Decision Table that together govern how every ABBI session may act. It is not advice or style — it is a set of binding gates that must be satisfied before action, in every realm, regardless of task, model, or platform. Only one entity may modify it: the ARCHITECT (John Stewart, Managing Partner of MiddleGround Capital).

Objective: make an autonomous, model-agnostic AI safe to run against production infrastructure and MGC data. The Canon guarantees that nothing catastrophic or irreversible happens without authorization, that ABBI never guesses when it should verify, that every change can be rolled back, and that the cloud Gitea repo — not any local copy — is the source of truth. As the boot prompt states it: "Verification, not assumption, is the basis for action."

How it works

The Canon lives verbatim at the top of the v200b Boot Protocol (v13.0). Every ABBI session loads it at boot, before any execution tool-call. The Laws set the principles; the Decision Table resolves each concrete decision point to exactly one rule; the Change Gate mechanically enforces the mutation-related Laws at runtime across three independent layers.

          THE CANON  (immutable — only the ARCHITECT modifies)
          ┌─────────────────────────────────────────────┐
          │  14 LAWS  ──────►  8-ROW DECISION TABLE   │
          │  (principles)          (one rule / decision)  │
          └───────────────┴─────────────────────────────┘
                          │ loaded verbatim at boot
                          ▼
   ┌─────────────────────────────────────────────────────────┐
   │  EVERY ABBI SESSION  (any realm, any model)               │
   │  boot → /objective → /deliverables → /devpolicy → execute │
   └──────────────┴─────────────────────────────────────┘
                   │  every canonical-infra MUTATION
                   ▼
   ┌────────────────────────────────────────────────────────┐
   │  CHANGE GATE  (gate BEFORE execution, fail-closed)        │
   │  L1  CF-Worker MCP middleware  → V20 · V2 · CLI · v200x   │
   │  L2  Claude Code PreToolUse hook → Mac Studio · QUE       │
   │  L3  Filesystem watcher safety net → manual/cron/SSH      │
   │  CRITICAL/HIGH → authorize <pin>  ·  MEDIUM/LOW → audit    │
   └────────────────────────────────────────────────────────┘

A gate DENY that a first retry does not clear is itself a STOP condition — the session reports and halts rather than re-issuing. Read-only operations (Hive Mind reads, session tracking, status queries) are never gated; only canonical-infra mutations are.

The 14 Canonized Laws

The Decision Table — one rule per decision point

The Decision Table supersedes all prior overlapping guidance. Where a memory, skill, or older doc conflicts with it, the Table wins.

Technical specification & design

The Canon is authored as plain text and enforced by real software. Concrete stack, all verified in the repo:

• Canon source (text): v200/boot/v200b/ABBI_boot-prompt-v13.0-local.txt — the Laws + Decision Table live at the top, loaded verbatim at every boot. Superseded prompts v11.0/v12.0 sit beside it as history.
• Change Gate (Python + Cloudflare Worker): shared/services/change-gate/ — a 3-layer enforcement system. Layer 1 = CF-Worker middleware at mcp-admin.abbi-ai.com checking watched MCP calls (cf_*, vercel_*, mac_write, mac_run) against the gate's /check. Layer 2 = a Claude Code PreToolUse hook gating Write/Edit + MCP on Mac Studio / QUE. Layer 3 = fs-watcher.py, a filesystem watcher (watchdog/fswatch) safety net that auto-reverts out-of-band CRITICAL changes from git. Mode = ENFORCE in gate_config.yaml; also runs containerized as v200-change-gate (port 8767).
• Risk tiering: gate_config.yaml → watched_paths classifies each path critical/high/medium/low. CRITICAL paths include ~/.claude/CLAUDE.md, ~/.claude/settings.json, ~/.claude/hooks/, com.abbi. LaunchAgents, the gate's own directory (self-protection), the Gitea path-mapping.json, and the realm boot/ prompt dirs — so the Canon cannot be quietly disabled.
• Authorization flow: printf '<pin>' | python3 ~/.abbi/scripts/authorize-v200-cloud.py --stdin → writes to authorize-cache.db, then scrub-pin.py. 6-digit PIN, per-use, typed live by the Architect.
• Source of truth & reversibility: cloud Gitea (Gitea VM 100.89.184.50:3300, repo abbi/abbi-infrastructure) is canonical; the Baseline Latch (/change-baseline) mechanically forces a rollback snapshot before the first mutation of a session.
• Governance automation (Python + LaunchAgents): shared/scripts/governance-audit.py, governance-metrics.py, governance-pdca.sh, governance-probes.sh — nightly/weekly LaunchAgents (com.abbi.v200-governance-*) that audit adherence and close the PDCA loop.
• Memory corpus (Markdown): v200/clients/claude-cli/memory/ — the CORE MEMORY.md plus per-rule feedback docs (e.g. feedback_canon_is_a_gate_not_a_weight.md) that operationalize each Law; progressive disclosure keeps CORE byte-stable for caching.

Deliverables

• The Canonized Laws (1–14) and the 8-row Decision Table — carried verbatim in the v200b boot prompt.
• A running, fail-closed Change Gate — three enforcement layers across the fleet, self-protecting, with per-item CRITICAL/HIGH authorization and MEDIUM/LOW audit-only pass.
• A one-word rollback / Baseline Latch — every session captures a known-good restore point before its first mutation.
• Governance audit + PDCA jobs — nightly/weekly LaunchAgents that measure adherence and surface violations.
• A memory corpus that operationalizes each Law into concrete, cached feedback rules loaded on demand.

Implementation by realm

The Canon is realm-neutral: the Laws and Decision Table bind every session regardless of realm. What varies is the enforcement surface and the authorization path.

Development status

LIVE The Canon is fully authored and in force. v200b Boot Protocol v13.0 is the single canonical boot prompt (activated 2026-07-19, reconciled governance + Decision Table). The Change Gate is in ENFORCE mode with all three layers running; the standalone LaunchAgent is retired in favor of the containerized v200-change-gate. Governance audit/PDCA LaunchAgents run nightly/weekly.

LIVE Decision Table Row 5 (completion-gate certificate required) and Row 8 (v2/v20 Raj authority) are both active and hook-enforced. The autonomy-enforcer and completion-gate hooks fail closed.

IN PROGRESS Peer-provisioning of a 2nd V20_ADMIN under Row 8 has never been exercised — it is the first real test of Raj's admin authority and the path the 2nd developer needs.

PLANNED Extending Canon enforcement as a first-class, per-realm surface for portco realms (Resolute, Banner) and future companies via the Sovereign Control Plane. Today those realms are bound by Canon and gated through shared MCP surfaces, not a dedicated per-realm gate.

Source documents (Gitea)

boot-prompt-v13.0-local.txt The canonical boot prompt — the 14 Laws and the 8-row Decision Table verbatim, loaded at every session start.

change-gate/README.md The 3-layer Change Gate: architecture, risk tiering, watched paths, ENFORCE mode, and self-protection rules.

V200-CAPABILITY-REFERENCE.md Authoritative operational map: tool→account/auth, credential retrieval, gateway topology, and the Change-Gate authorize flow.

memory/MEMORY.md The always-on CORE memory — the catastrophic/irreversible/universal rules that operationalize the Laws in every session.

feedback_canon_is_a_gate_not_a_weight.md The precedence rule: CANON binds before action (CANON > Architect > cadence > judgment); autonomy never licenses skipping a mandate.

governance-audit.py The nightly governance auditor that measures Canon adherence across the fleet and surfaces violations.

v200a-boot-protocol/SKILL.md The boot-protocol skill that loads the Canon and runs the fully-local boot sequence at session start.

What it is & why it exists

A realm is an isolated operating context with its own identity, authority, toolset, and data boundary. Nothing in one realm reaches across into another realm's data or credentials — isolation is the design, not a configuration option. ABBI runs on two independent axes of realm, and you must hold both in your head:

Objective: give every organization — MGC itself and each portfolio company — a full ABBI experience over its own data, with a hard guarantee that no realm can see, query, or spend against another realm's systems. That guarantee is what lets MGC extend ABBI to a portco without ever exposing MGC (or another portco) to it. Building out the future portco realms, starting with Banner, is the new developers' mandate.

How it works

The lifecycle axis — DEV → VM → BETA → PROD

Rollback is designed at Phase 1, before a line of code is written; "done" is a machine-readable Sprint Contract, not a judgment call; Phase 2 exit requires adversarial /test-panel verification, never self-certification. The Beta Testing environment is a named realm on its own (V200B) so beta traffic never touches production.

The organization axis — identity decides the realm

Every multi-user request enters through the realm-router, which reads the caller's identity (the email LibreChat injects as X-Abbi-Identity) and forwards the request to that realm's gateway with that realm's auth — default-deny for any identity it does not recognize.

caller identity (email)
        │
        ▼
  realm-router  (100.86.225.119:8791, DEFAULT-DENY)
        │
  ┌─────┼───────────────┬──────────────────────┐
  ▼     ▼               ▼                      ▼
 v200   v2 / v20      resolute / banner       unmapped
 local  mcp.abbi-      per-realm Snowflake      │
 relay  ai.com          account + gateway       ▼
 (255   (per-user      (own creds, own data)   DENY
 admin  Bearer,        never shared upward
 tools) 25 scoped                              (fail-closed)
        tools, RLS)

v200 identities (the Architect, ABBI admin) are hard-wired to the v200 realm regardless of config — supremacy is static. v2/v20 per-user keys are stored encrypted at rest (AES-256-GCM), decrypted only in memory; a v2 user with no resolvable key is denied, never leaked. Cross-realm read-across is structurally impossible: each portco realm is a separate Snowflake account behind its own gateway.

Technical specification & design

Deliverables

• A running realm-router that maps identity → correct realm gateway, default-deny (100.86.225.119:8791).
• A repeatable per-portco realm template: README + provision_portco_realm.py producing warehouse, four schemas, four roles, and secured key-pair — proven on Banner, ready to replicate ~14 more times.
• Per-realm Snowflake accounts with RAW → STAGING → CURATED → GOVERNANCE layering and RLS isolation tests.
• The four onboarding artifacts per portco (from /pc-realm-building): Data & Systems Inventory, Accounts & Infrastructure checklist, Access & Credentials Matrix, provisioning + ingestion runbook.
• A gated lifecycle path (DEV → VM → BETA → PROD) with Sprint Contracts, /test-panel gates, and Phase-1-designed rollback for every change to any realm.

Implementation by realm

Development status

Live now

• realm-router enforcing identity → realm, default-deny, with AES-256-GCM per-user key storage.
• v200, resolute, banner, and apeirin realms operational, each on isolated data.
• Banner per-portco template proven end-to-end (realm + RBAC + 2.37M source rows).

In progress / beta

• v2 & v20 in BETA — 4 real MGC users onboarded 2026-07-20; broader rollout pending.
• Peer V20_ADMIN provisioning path untested — to be exercised by onboarding the 2nd developer (get their MS email from Raj; add to the onboarding.abbi-ai.com Cloudflare Access allow-list; provision Gitea + tailnet day one).
• realm-user-listener currently DISABLED (FEATURE_STATUS.DISABLED present; turn-on runbook staged).

Planned

• ~14 remaining portfolio-company realms, replicating Banner; MGC_STARRETT carve-out from Hurricane.
• Sovereign Control Plane (ABBI.002.013) — namespace-per-org substrate to host every realm at scale (scaffold, under construction).

Source documents (Gitea)

realm-router/router.js — the identity→realm proxy: static v200 supremacy, encrypted v2 keys, default-deny logic.

portco-realm-template/README.md — the reusable per-portco realm structure, RBAC, key-pair auth, ingestion & migration order.

provision_portco_realm.py — the script that stands up a portco's warehouse, four schemas, and four roles.

pc-realm-building/SKILL.md — the five-phase portco onboarding playbook and its four required artifacts.

devpolicy/SKILL.md — the DEV→VM→BETA→PROD lifecycle: Sprint Contracts, test-panel gates, Phase-1 rollback design.

v200-naming-standard.md — the realm-prefixed naming grammar and the canonical realm enumeration.

realm-user-listener/README.md — the (currently disabled) per-realm user provisioning listener, incl. RLS isolation tests.

What it is & why it exists

Sovereign Mind and Hive Mind are the two halves of what makes ABBI more than a chat model: real capability and real memory.

Objective: give every ABBI session (a) the hands to do real work and (b) the memory to do it in context of everything that came before — with sub-millisecond recall, no external dependency at boot, and strict per-realm isolation so one org can never read another's memory.

How it works

Hive Mind runs local-first (v10.0). Reads and writes hit a local SQLite file first; Snowflake is a once-a-day backup, not a live write path. This is what makes boot instant and offline-tolerant.

Write path: sm_write_local inserts a row and touches ~/.abbi/sync-trigger; the sync daemon debounces 5s then rsyncs the whole DB to Node 1 (tailnet). Conflict resolution across peers is newest_wins, bidirectional. A separate cron pushes a daily snapshot to Snowflake for durable backup — deliberately not a real-time dual-write (decision 2026-04-06), which removed the old cloud-write race.

Technical specification & design

Local schema (SQLite)

Core table hive_mind: id, category, summary, details (JSON), priority, workstream, status, is_latest, version_num, source, source_mac, created_at/updated_at/synced_at/sf_synced_at, sync_status. Plus hive_fts (FTS5 over summary/category/workstream), sync_queue, and sessions.

Config caps (shared/config/hive-mind/sync-config.json): max_local_entries=10000, max_local_age_days=90, conflict_resolution=newest_wins, bidirectional, and the hard security rule credentials_never_local=true.

Deliverables

• A running local Hive Mind per node: ~/.abbi/hive-mind-local.db with FTS5 search, seeded from the latest JSONL snapshot.
• Four MCP tools wired into every Claude Code session (sm_write_local / sm_query_local / sm_search_local / sm_local_stats).
• Instant boot context — identity, app registry, workstreams, recent/critical entries, and credential-registry metadata loaded from local SQLite in <1ms (v9.1 boot).
• Tailnet replication to Node 1 within seconds of each write; multi-peer newest_wins reconciliation.
• Durable backups — daily JSONL snapshots in Dropbox (7-day retention) and a daily push into SOVEREIGN_MIND Snowflake.
• Per-realm cloud Hive Mind schemas (below) giving each org its own isolated memory.

Implementation by realm

Local-first SQLite is the V200 admin pattern (runs on the shared Mac Studio). Per-org realms are self-contained off the Mac and use their own Snowflake account for memory, reached through their own gateway with row-level isolation.

Development status

Live

• Local SQLite Hive Mind + FTS5 + 4 MCP tools, on V200 admin nodes.
• Boot v9.1: all 9 boot queries served locally; credential registry cached locally (values never local).
• Tailnet rsync to Node 1 (event + 15-min timer) and daily JSONL + Snowflake backups.
• Per-realm cloud hive schemas live for V200, V2, V20, Resolute.

In progress / watch-items

• Banner per-user session Hive Mind schema (query access live; dedicated hive schema not yet documented).
• Local peer set is small (leader Mac Studio 1556 + followers); one node marked offline in peers.json — verify current membership before relying on a given follower.
• hivemind-cleanup LaunchAgent present but disabled (.plist.DISABLED); age/entry caps enforced via config, not an active pruning job on every node.

Planned

• Sovereign Control Plane (ABBI.002.013): per-org Postgres + Qdrant memory as the multi-tenant substrate for up to 10k users, minimizing Snowflake/Azure dependency.
• Per-org hive template applied to each new portco onboarded.

Source documents (Gitea)

local-hive-mcp/index.js seed-local-hive.py hivemind-sync-daemon.py sf-backup.sh hive-mind/sync-config.json hive-mind/peers.json migrate-sf-to-local.py v200-naming-standard.md

• local-hive-mcp/index.js — the MCP stdio server: tool definitions (sm_*_local), better-sqlite3 wiring, inode-drift guard, credential-metadata boot queries.
• seed-local-hive.py — canonical SQLite schema (hive_mind, hive_fts FTS5 + triggers, sync_queue, sessions) and JSONL loader.
• hivemind-sync-daemon.py — tailnet rsync to Node 1; timer + sync-trigger event, 5s debounce.
• sf-backup.sh — daily JSONL snapshot to Dropbox + guarded Snowflake push; the local-first backup, not dual-write.
• sync-config.json — caps and rules: entry/age limits, newest_wins, credentials_never_local, backup timings.
• peers.json — sync mesh membership (leader/follower Macs + tailnet IPs).
• migrate-sf-to-local.py — maps the Snowflake V200_ADMIN_HIVE_MIND tables into the local schema.
• v200-naming-standard.md — the 5-account Snowflake tool table (Sovereign Mind capability plane) and per-account auth.

What it is & why it exists

The v200 platform architecture is the request-and-routing plumbing that turns "an identity asking ABBI to do something" into "the right tool, on the right backend, for the right realm." It is deliberately lean: after years of overloaded many-MCP designs, the Architect ruled a single canonical shape — one MCP path dedicated to Snowflake, and a Cloudflare Worker that makes direct vendor-API calls to everything else, with an identity-aware realm-router in front so multiple realms can share one front-end without ever crossing data or credentials.

Objective: deliver every session a single, redundant, default-deny path to ~255 admin tools and to Snowflake (the backend of record and the Hive Mind backup) — with East-primary redundancy across regions and internet-egress paths so a regional or ISP outage can never sever the platform, and break-glass so the Architect can always get in.

How it works

Every request enters through the realm-router, which reads the identity LibreChat injects (X-Abbi-Identity) and either forwards it to that realm's gateway with the realm's own auth, or returns DENY 403. The v200 (Architect) path goes to the Mac relay, which races Snowflake tools directly to the container fleet and dispatches everything else to the Cloudflare Worker.

The relay is LaunchAgent com.abbi.v200-dmn-snowflake-mcp-relay-r74260eb (source v200/services/alb-relay/relay.js). The CF Worker's canonical source is v200/workers/mcp-admin-lb/index-admin.js; mcp-admin-lb is the legacy worker name (zero secrets) kept only until formally retired. v2 per-user keys are stored AES-256-GCM encrypted at rest and fail-closed on any decrypt error.

The three routing rules (Canon)

1. Tools are direct calls through the CF Worker. The Worker holds the per-service secrets (23 bound) and calls each vendor API directly (~34 families: M365 native, Asana, DealCloud, GitHub, Vercel, ElevenLabs, Dropbox, Drive, OpenAI, Grok, …). It proxies only 8 heavier families (m365, vertex/gemini, dealcloud, sentinel, azcli, notebooklm, bedrock, mac-relay) to Azure containers.
2. The load-balancer path carries ONLY Snowflake + core startup tools. v200-lb-mcp-admin-east → v200-gw-mcp-admin-east (TS_SF_BACKENDS = the six SF containers) — it is NOT the general tool path. Its /mcp now serves sm_* after the W3 catalog-fix (image ts-v200gw:v1.3.5-catalog-fix, pinned to sf-east-3 100.73.34.127).
3. East is primary; West and AWS serve only on East failure. Worker layer: *_GATEWAY primaries hit the east twin, EAST_FALLBACK_HOSTS/_retryWest retries west on any non-OK response. Relay SF layer: SF_EAST_BACKENDS race first; SF_FALLBACK_BACKENDS (west + AWS Lambdas) race only on total east failure.

Technical specification & design

Gateway & routing layer

• realm-router — Node.js transparent Streamable-HTTP MCP proxy on the tailnet, 100.86.225.119:8791, default-deny by identity, AES-256-GCM key store, SIGHUP config reload. Source: v200/services/realm-router/router.js.
• Mac relay (alb-relay) — Node.js relay, 100.86.225.119:8080/mcp, auth X-API-KEY (not Bearer). Runs as a macOS LaunchAgent. Source: v200/services/alb-relay/relay.js.
• CF Worker gateway — Cloudflare Worker (v200-wrk-mcp-admin-gw-r74260eb), deployed with Wrangler; 23 bound secrets; native handlers for ~34 tool families + container proxy for 8. Source: v200/workers/mcp-admin-lb/index-admin.js.

Backend fleet

• Azure Container Apps — the Snowflake container fleet (v200-sf-east-1/2/3-r60ade5, v200-sf-west-1/2/3-r60ade5), the LB + gateway, the 8 service-tool container families, and the migrated control-plane / utility containers (cgate, opscol, procctl, qmscol; attachment-capture, cf-proxy, ediscovery, email-triage).
• AWS Lambda — the AWS Snowflake leg: 4 Lambdas (account jga82554, 2× us-east-1 + 2× us-west-2). Architect ruling D2: Lambdas accepted as-is (no AWS containers needed).
• Snowflake — the backend of record + Hive Mind backup; one account per realm (see grid below).
• Tailscale — the private mesh binding every Mac, Ultra node, and container; regional exit nodes provide the internet-egress diversity. SF containers set HTTPS_PROXY=localhost:1055 → a Tailscale sidecar → exit node.
• Conductor (LiteLLM) + Oracle — model-selection layer: LiteLLM on N1:4000, Oracle scoring against capability_matrix.db (32 models, 396 scores, 12 dims, ~11 free-local). Note (Architect ruling 2026-07-06): the Conductor belongs to the abbi-server realm, NOT any v200 request path — source abbi-server/conductor/.
• Cloudflare — fronts the whole ALB (the "v200ALB"); Cloudflare Access enforces Microsoft SSO on the onboarding site.

Naming grammar: [realm]-[type]-[function][-ploc][-n]-r[hash], e.g. v200-sf-east-1-r60ade5 (container), v200-wrk-mcp-admin-gw-r74260eb (worker), com.abbi.v200-dmn-…-r74260eb (LaunchAgent). r[hash] = 7-char Gitea commit at deploy.

The Snowflake redundancy grid (9-connection design)

Redundant containers each serving a distinct purpose, all connecting to Snowflake, spanning regions AND internet-egress paths so a regional or ISP outage cannot sever Snowflake.

Break-glass (always able to get in): Snowflake admin-persona containers v200-svc-sf-adm-e1/e2/w1/w2-r0461274 (snowflake-admin-mcp v4.0.0, V200_ABBI_ADMIN/ACCOUNTADMIN, 2E+2W, internal-only, off the load path by design) + Azure break-glass service principal v200-azure-mcp-svc-r3a864ea (appId 8fb1737f) with jstewart@ user context.

Deliverables

• A single default-deny front door (realm-router) mapping identity → realm gateway for the shared app app.abbi-ai.com (LibreChat, ABBI-branded).
• The canonical MCP path for v200: Mac relay :8080 (X-API-KEY) exposing ~255 admin tools with a direct raced Snowflake connection.
• The CF Worker gateway: direct vendor-API access to ~34 tool families + container proxy for 8, secrets held at the edge.
• The 9-connection Snowflake redundancy grid (Azure East ×3 · Azure West ×3 · AWS Lambda ×4), East-primary with automatic failover.
• Break-glass tiers (Snowflake admin-persona + Azure SP) guaranteeing access during any primary-path outage.
• A Tailscale mesh with regional exit nodes providing private connectivity and egress diversity.
• Three canonical, frozen routing docs that every session measures current state against before changing anything.

Implementation by realm (gateway / routing coverage)

Development status

LIVE now: realm-router (default-deny, static v200 supremacy), Mac relay :8080, CF Worker gateway (23 secrets, ~34 direct families + 8 container families), the full 9-connection Snowflake grid (E×3 · W×3 · AWS λ×4), both break-glass tiers, and the W3 fix so the LB gateway /mcp genuinely serves sm_*.

IN PROGRESS / open items: egress-diversity remediation (repoint west SF containers to the built-but-integration-pending v200-azw-exitnode-r47c4f604 — W4); west backup twins for the control-plane / Mac-migrated containers (D5); Tailscale service-tier end-state (service containers get internal-only ingress + TS sidecars).

PLANNED: a west admin LB/gateway backup leg (backup-only, D3+D5); the deprecation package for genuine pre-morph relics (unrouted per-service tool containers, superseded twins, sm-switch CF workers) — one at a time under the 300%-sure protocol; the dedicated server build (ABBI.312, DGX B200 + R760) as the prod substrate for up to 10,000 users.

Source documents (Gitea)

• v200-intended-architecture.md — the "measure-against" spec: the redundancy grid, break-glass tiers, and the 6 Architect rulings (D1–D6).
• tool-routing-architecture.md — the three frozen routing rules (Canon 2026-07-04) and deprecation candidates.
• v200-container-inventory.md — what actually exists in the fleet (containers, LBs, gateways, exit nodes).
• alb-relay/relay.js — the Mac relay :8080 source: X-API-KEY auth, staged Snowflake race, CF-Worker dispatch.
• index-admin.js — the CF Worker gateway: native handlers, container proxy, EAST_FALLBACK_HOSTS/_retryWest.
• router.js — the realm-router: identity → realm, default-deny, AES-256-GCM v2 key store.
• abbi-server/conductor — LiteLLM (N1:4000) + Oracle model-selection (abbi-server realm, separate from the v200 path).
• tailscale-onboarding.md — the mesh, exit nodes, and sidecar/egress model.

What it is & why it exists

The ABBI.001.x Infrastructure program is the platform layer that every ABBI realm and application runs on: the MCP gateway and tool relay, the Snowflake data accounts, the Hive Mind memory system, the container/networking fabric (Tailscale mesh, Azure Container Apps, Cloudflare Workers), the Change Gate governance system, and Gitea as source of truth. Everything else in the portal — the CLI, the consoles, the dashboards, the four portfolio realms — is a consumer of this layer.

Objective: provide a single, sovereign, governed substrate so that (a) one admin platform (V200) can build and operate infrastructure for every realm without sharing credentials across realms, (b) all changes are reversible and gated, and (c) source-of-truth lives in Gitea rather than on any one machine.

The ABBI.001.x project ledger (from folder_registry.json, v3.x)

Pills below reflect the registry active/archived status combined with known-live platform state — not a per-project runtime probe.

How it works

Every session (CLI, console, or automation) speaks the MCP protocol to one canonical admin gateway over the Tailscale mesh. A relay splits traffic: memory/Snowflake calls race directly to Snowflake containers; everything else is routed through a Cloudflare Worker to native handlers or downstream Azure Container Apps. Authentication differs by realm — the V200 admin gateway uses X-API-KEY; the separate V2 user gateway uses Authorization: Bearer.

Governance path: any canonical add/modify must carry a Gate-Token: commit trailer minted by the Change Gate on ALLOW; deletions need an HMAC delete-auth token. Gitea's server-side pre-receive hook (Layer 1) is in ENFORCE and rejects ungated pushes. Deployed files are copied to Gitea by the gitea-autocommit daemon, so Gitea is the source of truth while ~/.abbi/ is only a working copy.

Technical specification & design

The concrete stack, all verified in the repo:

• Protocol / gateway: MCP over a Node relay (relay.js, service v200-alb-relay) fronted by Cloudflare Workers (workers/mcp-admin-gateway-lb/index-admin.js, Wrangler-deployed).
• Compute: Azure Container Apps for MCP backends (m365, vertex, Snowflake admin containers, Change-Gate v200-svc-cgate-east); Mac Studio + Mac Ultra fleet for local-first model serving.
• Data / warehouse: Snowflake — multiple accounts by realm: IRA11585 (SOVEREIGN_MIND), JGA82554 (HURRICANE + MASTER_CREDENTIALS), SXA84406 (V2_ABBI_AI_WH), KGB57253 (Banner). Local SQLite powers the Hive Mind (primary) with Snowflake as backup.
• Model routing: LiteLLM on Node 1:4000 (Conductor) selects models per task; ABBI Server (ABBI.001.003) hosts local-first models.
• Networking: Tailscale mesh VPN with Azure exit nodes (v200-aze-exitnode 100.72.89.111) for egress; SSO via Cloudflare Access.
• Source of truth / CI: Gitea (cloud primary 100.89.184.50:3300, repo abbi/abbi-infrastructure) with pre-receive gate hooks and the gitea-autocommit.py daemon.
• V2 front-end: LibreChat (v2/services/librechat-v2) with a Snowflake MCP backend and Row-Level Security.
• Secrets: local encrypted credential cache + Azure Key Vault (abbi-v200-kv) break-glass; naming grammar [realm]-[type]-[function][-ploc][-n]-r[hash].

Key directories: v200/services/ (30+ MCP services), v200/containers/, v200/infrastructure/{snowflake-rbac,credential-vault}, shared/services/change-gate/, shared/scripts/ (gitea/hive/sync daemons).

Deliverables

• A canonical, Tailscale-direct MCP admin gateway exposing ~237 live tools with realm-correct auth.
• Per-realm Snowflake accounts + warehouses with RBAC and RLS, wired to realm-scoped query tools (sm_*, hurricane_*, resolute_*, banner_*, v2abbi_*).
• The Hive Mind memory system (local SQLite primary + Snowflake backup) with sync daemons.
• The 3-layer Change Gate (CF Worker middleware, PreToolUse hook, filesystem watcher) plus Gitea server-side ENFORCE.
• Gitea source-of-truth pipeline: autocommit, drift monitor, N1 mirror, 4-node backup.
• Tailscale mesh + exit nodes and Azure Container Apps deployments for backend services.
• Auto-generated inventories (containers, services, credentials) and the capability reference.

Implementation by realm

Which infrastructure serves which realm (evidence from staged verified facts + registry):

Development status

Live now

• Canonical MCP admin gateway (~237 tools), Tailscale-direct with X-API-KEY.
• Per-realm Snowflake (IRA11585, JGA82554, SXA84406, KGB57253) with the four realms above operational.
• Hive Mind local-first SQLite + Snowflake backup; sync daemons running.
• 3-layer Change Gate + Gitea server-side ENFORCE (cert 1783685058, 2026-07-10).
• Tailscale mesh with EAST exit node v200-aze-exitnode (100.72.89.111).

In progress

• V200/V2 architecture sync for 73 new containers (ABBI.001.001-B); container cleanup (001.022) and naming rollout (001.020).
• West exit node + west admin LB built but not yet wired into index-admin.js ADMIN_GATEWAYS (integration-pending).
• Azure Key Vault adoption for break-glass secrets (ABBI.001.023); credential value-cache gap on IRA11585 (36 creds missing, JGA82554 fallback).
• Deploy dual-tree automation (deploy.sh, item D4) — canonical→served still manual.

Planned

• Sovereign Control Plane (ABBI.002.013) for multi-org onboarding; dedicated server build ABBI.312 (DGX B200 + R760) as prod substrate for up to 10k users.
• Capability-reference generator LaunchAgent (validate-against-live, fails on drift) — file currently hand-verified.

Source documents (Gitea)

V200-CAPABILITY-REFERENCE.md — authoritative operational map: Snowflake tool→account/shape, gateway topology, credential decision tree, Change Gate, Tailscale.

tool-routing-architecture.md — how tool calls route through the relay and CF Worker to backends.

v200-intended-architecture.md — the canonical target topology for the V200 platform.

v200-naming-standard.md — single source of truth for the infrastructure naming grammar.

shared/services/change-gate/ — Change Gate service: authorize, delete-auth, break-glass, gate DB.

gitea-autocommit.py — daemon that copies deployed files into Gitea (source-of-truth pipeline).

v200/services/ — the 30+ MCP backend services (Snowflake, m365, cloudflare, dropbox, acis, and more).

docs/containers-inventory.md — auto-generated container inventory (ACA + QMS runner).

What it is & why it exists

MiddleGround Capital (MGC) is the private-equity firm ABBI was built to serve. Everything on this tab is the business layer — the real portfolio-company, deal, IR, and firm-operations work — as opposed to the platform/infrastructure layers described in the other tabs. The MGC business universe occupies the ABBI.100–199 block of the FGS project registry (label “MiddleGround Capital”), plus a set of purpose-built applications and dashboards under the ABBI Applications block (ABBI.002.x).

Objective: replace ad-hoc, memo-driven investment work with a continuous, auditable, tool-assisted pipeline — so the deal team, FinOps, and the Managing Partner Office get early, evidence-cited signals on portfolio performance, deal flow, and LP/IR activity without hand-building every analysis.

The MGC universe is organized into five top-level project families in the registry:

Registry authority: ~/.abbi/scripts/folder_registry.json (v3.3, universe_blocks → mgc: 100–199). The physical tree lives in Dropbox under MP.000 AI Projects/FGS/; each folder carries CV/, Needs Update/, and Archive/ per the FGS standard.

How it works

MGC business work flows through three layers: project folders (FGS, the source-of-record for every deliverable), skills (the codified analysis playbooks an operator invokes), and services (the always-on pipelines that keep data fresh and push reports out). A user — the Managing Partner, a deal-team member, or ABBI acting on their behalf — picks a project, invokes a skill, and the skill reads from the live data plane (Snowflake HURRICANE, DealCloud, Dropbox, M365) and writes branded deliverables back into the project's FGS folder.

Technical specification & design

The MGC business layer is built on the same sovereign stack as the rest of ABBI, wired to PE-specific data sources:

Every numeric claim in an ABBI.324 output resolves to a real Snowflake table row and is re-verified through the blocking judge gate (schema check → citation resolution → numeric re-verification → narrative/number consistency → diverse-model adversarial review) before a human ever sees it.

Deliverables

What the MGC business layer actually produces:

• Quarterly Portfolio Review (/portfolio-review) — annotated deck, one MGC-branded feedback whitepaper per company with deal-team questions, a consolidated Managing Partner Commentary memo, a portfolio Market Outlook memo, and TVPI/IRR/DPI return charts.
• Board packages (/board-prep) — portfolio-company board decks, IC memos, and board-ready financial summaries built from deal-team data, DealCloud, and M365.
• Weekly Market Intelligence Report (ABBI.104.007) — a .docx with 8 charts synthesized from HURRICANE market-intel + iLevel + macro + deals, emailed every Friday to the Snowflake-managed distribution list, archived to Azure Blob with a 30-day SAS link.
• Weekly MPO / PortCo reports (ABBI.104.001, /pcweekly, /pacereport, /mppriority) — Managing Partner Office weekly rollups and per-company pace reports.
• Continuous monitoring intelligence (ABBI.324) — financial decomposition variance bridges (price/volume/mix/cost), lead-lag indicator fits, temporal performance-driver maps, capability-to-opportunity matches, and MD&A narratives — all judge-gated and written to HURRICANE + Neo4j.
• IR / fundraising artifacts (ABBI.102, ABBI.359) — LP DDQ responses, investor lists, AGM/LPAC materials, roadshow decks.
• Firm-operations outputs (ABBI.103) — AGM slides & whitepaper, MGC 2.0 Strategy, Value Stream Maps, TPS Manual, Make-vs-Buy analyses.
• Branded work product — MGC-styled PowerPoint (/PPT, /mgcppt), Word (/mgc-whitepaper), Excel, and charts, all enforcing MGC brand constants.

Implementation by realm

Development status

Live

• LIVE ops.abbi-ai.com dashboard (ABBI.002.002) — running under LaunchAgent com.abbi.v200-ops-dashboard on port 3200 (Tailscale-only), surfacing health, queue, market intel. Caveat: carries ~9 known display defects (root-cause e391a4ba) — treat display polish as under construction.
• LIVE Weekly Market Intelligence Report (ABBI.104.007) — migrated off Node 1 to an Azure Container Apps Job; runs Fridays 5pm ET, emails via MS Graph.
• LIVE ABBIgram internal social (Mastodon) — Tailscale-only, private, no federation.
• LIVE MGC deliverable skills — portfolio-review, board-prep, mgcppt, mgc-whitepaper, mgc-excel, mgc-charts, persuasion; deployed to V200 and packaged into the V20 install kit.
• LIVE Banner (MGC_BANNER) data realm — RBAC + ~2.37M rows, verified live.

In progress

• IN PROGRESS ABBI.324 Portfolio Company Monitoring — multi-subsystem service (findecomp, lagcorr, knowledge-graph, mdna, capmatch, judge, workers); swarm workers + judge gate built; several subsystems iterating; compiled modules shipped in-checkout.
• IN PROGRESS ABBI.361 Portfolio Intelligence System and ABBI.323 IR Dashboard — active project folders; no dedicated deployed app tree yet (delivered via skills/dashboards).
• IN PROGRESS V2 multi-user MGC rollout — beta cohort onboarded; broad staff rollout gated on CLI/console hardening.

Planned

• PLANNED Sovereign Control Plane (ABBI.002.021) — namespace-per-org substrate for MGC + future portcos at scale (Phase-1 devpolicy package complete; server build pending gate).
• PLANNED 2nd V20_ADMIN peer-provisioning — the untested Raj-provisions-a-peer path (the immediate onboarding action item).

Source documents (Gitea)

abbi324/README.md — ABBI.324 portfolio-monitoring platform: subsystems, judge gate, swarm-worker runtime, Snowflake + Neo4j fit.

abbi324/knowledge-graph/ — Graphiti-on-Neo4j temporal knowledge graph (driver maps, entity resolution).

market-intel/README.md — ABBI.104.007 weekly report: Snowflake → Claude → 8 charts → .docx → MS Graph, as an ACA Job.

mgc_email_intel_pipeline.py — the IB email-scraping market-intel ingest pipeline feeding HURRICANE.MARKET_INTEL.

ops-dashboard/README.md — the Next.js ops + market-intel dashboard (ops.abbi-ai.com, port 3200, Tailscale).

mgc-social/README.md — ABBIgram (Mastodon) MGC internal social platform stack & operations.

skills/portfolio-review — firmwide quarterly Portfolio Review playbook & deliverable set.

skills/board-prep — portfolio-company board-package / IC-memo preparation skill.

What it is & why it exists

Banner (portfolio company AM Castle) is MiddleGround Capital's first dedicated, company-owned Snowflake data realm — project ABBI.100.026 ("Banner Data"). It was stood up 2026-07-10 and is LIVE: realm + RBAC + ~2.37M rows loaded from the company's real source systems.

The objective: each portco's data lives in its own Snowflake account — never commingled in MGC's shared Hurricane account (JGA82554). Ingestion feeds from the company's real sources (S3 exports + ERP/CRM connections), not routed through MGC infrastructure. Banner proved this pattern end-to-end so it can be repeated: it is now the canonical portco-realm-template and the /pc-realm-building playbook (both origin: ABBI.100.026 Banner / MGC_BANNER).

How it works

A portco realm is one Snowflake account with a fixed shape: a single warehouse, one database, one RAW_ schema per source system, then conformed STAGING → CURATED layers, plus a GOVERNANCE schema for load control and audit. Data flows in from the company's own sources; MGC and the portco team read the curated layer.

Access is key-pair only: portco accounts enforce MFA and MFA can't be driven by any connector, so JWT key-pair is the only programmatic path (and is MFA-exempt). ABBI reaches the realm through the admin gateway's banner_sm_query_snowflake tool, which runs the SQL as ACCOUNTADMIN. Ongoing loads run as a scheduled ETL LaunchAgent (fsc_etl.py, daily 13:00).

Technical specification & design

The actual tech used to build and run Banner, verified in the repo:

Deliverables

What the Banner build produces — and what each new portco build must reproduce:

• A dedicated Snowflake account (warehouse + database + RAW_/STAGING/CURATED/GOVERNANCE schemas + 4-role RBAC hierarchy).
• Key-pair credentials secured by name (private key on disk 600 → Azure Key Vault entry <portco>-admin-keypair; source connections as <portco>-source-connections).
• ~2.37M rows ingested from the company's real sources (Oracle Castle ERP, D365 FSC + Sales, Powerterm NKS) into RAW, conformed up through STAGING/CURATED.
• A gateway query tool (banner_sm_query_snowflake) so ABBI can read the realm from chat, auth injected by the infrastructure.
• A scheduled ETL job (LaunchAgent) keeping the FSC feed current.
• Two reusable assets seeded from this build: the portco-realm-template (README + provision script) and the /pc-realm-building skill (5-phase onboarding playbook producing an inventory, an accounts list, an access/credentials matrix, and the provisioning + ingestion runbook).

Implementation by realm

Banner is the built reference; "implementation" for the other realms means how they relate to this per-portco-realm template.

Development status

• LIVE — Banner realm structure, RBAC, key-pair auth, ~2.37M rows from source, the banner_sm_query_snowflake gateway tool, and the daily FSC ETL LaunchAgent. Realm stood up 2026-07-10.
• In progress — securing the Banner key-pair + source-connection secrets into Azure Key Vault (abbi-v200-kv); curated/dedup modeling continues to deepen on top of RAW.
• Planned — replicating the template across the remaining ~14 portcos (Starrett → MGC_STARRETT next); the gated, separately-authorized final migration step is decommissioning each company's data out of Hurricane only after consumers confirm the new realm.

Source documents (Gitea)

• README.md — the reusable per-portco-realm template: principle, standard structure, key-pair access steps, ingestion patterns, migration order, status (Banner done, ~14 to replicate).
• provision_portco_realm.py — idempotent Python provisioner that creates the warehouse, database, schemas and full RBAC grant hierarchy for any portco.
• pc-realm-building/SKILL.md — the 5-phase onboarding playbook (inventory → accounts → access/credentials matrix → provisioning → ingestion), origin ABBI.100.026 Banner.
• project_mgc_banner_snowflake.md — the Banner connection facts memo: account identifier, the LOGIN_NAME gotcha, key path/fingerprint, and the working connect string.
• index-admin.js — the admin gateway Worker that defines and routes banner_sm_query_snowflake (generic per-account Snowflake handler).
• banner-fsc-etl plist — the launchd job that runs the daily Banner D365-FSC ETL into the realm.

What it is & why it exists

Resolute Racing is a real MiddleGround-adjacent Thoroughbred breeding & racing operation (Chelsey Stewart = CEO, John Stewart = Owner) and the first full product realm built on the ABBI platform. Where V200 is the dev/platform realm and V2 is the MGC multi-user realm, resolute is the reference implementation of a completely self-contained, single-tenant portfolio-company realm: its own Azure infrastructure, its own branded chat app, its own gateway, its own Snowflake account, its own Dropbox, and its own private tailnet — sharing no credentials or data with any other realm.

Objective: give one portfolio company a private, brand-styled AI assistant ("ABBI-Resolute") that answers over its own racing/breeding data and files, isolated per-user, reachable only inside the company's private network — and to prove the repeatable realm blueprint that future portcos will be cloned from.

How it works

A Resolute user opens the Resolute-branded LibreChat app only over the Resolute Tailscale tailnet. LibreChat calls a single internal resolute-gateway that enforces per-user Row-Level Security, then fans out to backend MCP tools (Snowflake, Dropbox, M365, racing collectors, model backends). All data resolves to the Resolute-only Snowflake account.

 Resolute user (browser)
        │  Tailscale ONLY  (tailfb6577.ts.net)
        ▼
 resolute-librechat-rf9e55ef13   ← LibreChat v0.8.7, ABBI-Resolute persona
        │  internal ACA ingress
        ▼
 resolute-gateway-rf9e55ef13     ← ~309 tools aggregated + RLS
   ├─ _resolve_user / _enforce_isolation (overwrite user=caller)
   ├─ _filter_tools_by_persona  ·  _sql_guardrail (BLOCKED_SQL)
   └─ header inject X-User-Email / X-User-Persona
        │
        ├──► rslt-snowflake-mcp ──► Snowflake MLA96789 (RESOLUTE_MIND)
        │        (key-pair RSA auth, bypasses MFA)
        ├──► resolute-dropbox-mcp (CF Worker, service account)
        ├──► m365 / elevenlabs / openai / grok / make backends
        └──► racing collectors (Equibase → FlareSolverr → iProyal proxy)

 Backing stores (all in resolute-env, eastus):
   rslt-cosmos-mongo (MongoDB vCore, durable) · rslt-meili
   rslt-vectordb (pgvector/RAG) · rslt-rag-api
 Secrets: Azure Key Vault  resolute-kv  (via managed identity resolute-mi)

RLS note: the gateway ports V2's isolation model — a caller cannot read another user's mailbox or Hive Mind by passing a different identity; the user argument is force-overwritten to the authenticated caller for m365/dropbox/drive, personas filter the visible tool set (USER drops github, ADMIN keeps all), and Hive Mind reads/writes are stamped/filtered by USER_ID=caller.

Technical specification & design

App layer — Resolute LibreChat (ABBI.200.003)

• LibreChat v0.8.7 (upstream, node:24-alpine), image sovereignmindacr.azurecr.io/resolute-librechat:v2.x, container resolute-librechat-rf9e55ef13.
• Config librechat.resracing.yaml baked in as /app/librechat.yaml (env vars are not expanded in the mcpServers block — URLs hardcoded). App binds port 8080 (not LibreChat's default 3080) so the ts-sidecar can proxy; ENV HOST=:: for dual-stack.
• Branding = real Resolute Racing assets (royal blue #2050A0 + white wordmark); APP_TITLE=Resolute. Frontend recompiles need a CACHEBUST build-arg (az acr build --no-cache is unsupported and fails silently).
• Persona ABBI-Resolute, realm-bounded — no MiddleGround / DealCloud / Asana access.

Gateway — resolute-gateway (Python)

• Container resolute-gateway-rf9e55ef13, internal ingress only. Aggregates ~309 MCP tools (peaked ~349; catalog trimmed 323→245 after retiring dead backend families). Self-healing catalog (v1.7.6) survives restarts with no manual /refresh.
• Image lineage: v1.6.1-cortex (Cortex Analyst text-to-SQL era) → v1.7.0-rls → v1.7.6-rls (self-healing) → v1.8.0-native-pilot (native-handler dispatch, no backend container in path for github family).

Data — Snowflake MLA96789

• Account mvsgjpv-resolute (MLA96789), DB RESOLUTE_MIND, warehouse RESOLUTE_AI_WH. Schemas: RACING_DATA (~1,118,820 horses), RESOLUTE_ADMIN/CS/USER_HIVE_MIND, SESSION_TRACKING.
• Auth = RSA key-pair only: RESOLUTE_ADMIN has MFA enforced so password auth fails (error 250001); the resolute-admin-rsa-private-key secret (base64 PEM) in vault resolute-kv bypasses it. Dedicated rslt-snowflake-mcp (image snowflake-admin-mcp:v4.1.1) is the only backend with key-pair support; wired as gateway slot 3, exposing snowflake_sm_query_snowflake (params: database, sql).

Files, storage, network

• Dropbox: resolute-dropbox-mcp Cloudflare Worker (permanent service account; token in resolute-kv/resolute-dropbox-token; default member john@resracing.com).
• Backing stores (all in resolute-env, eastus): Azure Cosmos DB for MongoDB vCore rslt-cosmos-mongo (M30, server 7.0, durable), rslt-meili (search), rslt-vectordb (pgvector/RAG), rslt-rag-api.
• Network: separate Resolute Tailscale account/tailnet (tailfb6577.ts.net); every service is internal-ingress + Tailscale-only (ops dashboards flipped external→internal).
• Racing collection: Equibase scraper → FlareSolverr (3 replicas) → iProyal residential proxy; migrated to Azure ACA (Colima VM freed, Mac reduced to a residential-proxy relay); pedigree engine v4.
• Cloud stack: Azure Container Apps (RG resolute-infra-rg), Azure Container Registry sovereignmindacr, Azure Key Vault + managed identity, Cloudflare Workers, Snowflake, Tailscale.

Deliverables

• A production, Resolute-branded LibreChat assistant (ABBI-Resolute) reachable Tailscale-only by resracing.com users.
• Per-user RLS-enforced gateway aggregating ~245–309 MCP tools over Resolute's own data.
• A live racing/breeding data warehouse in Snowflake (RESOLUTE_MIND, ~1.12M horses) with key-pair auth.
• An Azure-hosted Equibase/pedigree collection engine feeding the warehouse.
• A scoped Dropbox service account for the realm's files.
• A cross-realm admin query tool resolute_sm_query_snowflake exposed to the V200 admin gateway (MLA96789 / RESOLUTE_ADMIN).
• The repeatable single-tenant portco realm blueprint (infra + gateway + branded app + isolation) for future portfolio companies.

Implementation by realm

Resolute is itself a realm; this table assesses which realms implement the full single-tenant "product realm" pattern that Resolute defines.

Development status

LIVE:

• Resolute LibreChat app in production, Tailscale-only (~4.5 min ready window after any restart — 502s during that window are normal).
• resolute-gateway with per-user RLS + self-healing catalog; native-handler pilot proven for the github family.
• Snowflake RESOLUTE_MIND data path via key-pair auth (verified: SELECT COUNT(*) FROM RACING_DATA.HORSES → 1,118,820).
• Durable accounts on Cosmos DB MongoDB vCore (survive app restarts).
• Dropbox permanent service account (verified upload).
• Racing/pedigree collection running from Azure ACA (Mac freed to a proxy relay).

IN PROGRESS:

• Gateway lean-out — Waves 1–2 done (dead backend families disabled + scaled to zero, catalog 323→245); Waves 3–4 (further scale + container retirement) pending separate authorization.
• Residential-egress throughput is the hard ceiling on the pedigree engine (single Mac line, ~4% failure edge).
• Hive-Mind-specific gateway tools — currently reached via raw SQL through snowflake_sm_query_snowflake (open follow-up).

PLANNED / PENDING:

• M365 OIDC SSO for the app (currently local resracing.com accounts, no SSO).
• Canonicalizing the gateway app.py (source not yet committed to this working copy — only __pycache__ present).

Source documents (Gitea)

reference_resolute_librechat_infra.md — canonical build reference: app image, gateway/Snowflake MCP architecture, key-pair auth, backing stores, users, build gotchas.

resolute-dropbox-mcp/index.js — the scoped Dropbox Cloudflare Worker (service-account impersonation, X-API-KEY auth).

resolute-dropbox-mcp/wrangler.toml — Worker config: resolute-kv secret sourcing, default member john@resracing.com.

mcp-admin-lb/index-admin.js — V200 admin gateway that adds resolute_sm_query_snowflake (MLA96789 / RESOLUTE_ADMIN, JWT key-pair).

All-account Snowflake gateway (change log) — how the 5 Snowflake accounts (incl. Resolute MLA96789) were wired for admin query access.

Resolute self-healing gateway v1.7.6 (change log) — self-healing tool catalog + locking ops dashboards to Tailscale-only.

resolute-social (Resogram) README — the ABBI.200.002 social pipeline for Resolute Racing.

equibase-clone service README — the racing-data collection/clone service feeding RESOLUTE_MIND.

resolute-racing-proxy.py — the residential-proxy relay used by the Equibase/pedigree collectors.

Served at onboarding.abbi-ai.com behind Microsoft SSO (Cloudflare Access), allow-list = Architect + the 2 developers, default-deny.

What it is & why it exists

This is the meta-system that governs who exists on the platform and what they can reach — the design and machinery that manages users, realms, and organizations rather than any single application. It is not one product; it is three layered design efforts plus the live routing service that enforces them:

How it works

The taxonomy is enforced today by a live tailnet-side realm-router (router.js). LibreChat / the CLI inject the caller's identity (X-Abbi-Identity = user email); the router resolves that identity to a realm and proxies the MCP request to that realm's gateway, injecting the realm's auth. Anything unmapped is DEFAULT-DENY.

The Organization Master Design generalises this per organization: each org owns separate accounts for every service (M365, Asana, Snowflake, tools) and its own Cloudflare gateway + Tailscale instance; the shared layer (LibreChat, CLI, Cloudflare, Tailscale) is provisioned per org, not co-mingled. V200 supreme can reach every org but only through an explicit, audited, default-deny grant per realm, with every cross-org hop logged.

Technical specification & design

The built pieces and the designed substrate use distinct stacks:

Live enforcement layer (built)

• realm-router — Node.js HTTP proxy (node:http/https/crypto), a transparent Streamable-HTTP MCP proxy that preserves transport and injects each realm's auth. Binds the Tailscale IP 100.86.225.119:8791. File: v200/services/realm-router/router.js.
• Credential handling — v2 per-user keys are stored encrypted at rest (AES-256-GCM) in v2-keys.enc, decrypted at load with a 32-byte file key (~/.abbi/secrets/abbi-credential-key), re-decrypted on SIGHUP; fail-closed (no resolvable key = deny).
• Runs as a macOS LaunchAgent, com.abbi.abbi-dmn-realm-router.plist (KeepAlive, env-driven bind host/port).
• Shared app — LibreChat image abbi-librechat:v0.8.7-abbi-brand3 on Azure Container Apps (abbi-svc-librechat-east), MongoDB backend, per-user MCP via X-Abbi-Identity={{LIBRECHAT_USER_EMAIL}}. Identity/persona sync in persona-sync.py.
• Edge / identity — Cloudflare Access (Microsoft/Google SSO), CF Workers + Tunnels; Tailscale demoted to backend-only (router → realm data planes, operator CLI).

Model routing — Conductor (built)

Conductor is the benchmark-driven model-routing brain: LiteLLM proxy on N1 (100.87.243.54:4000) with Conductor middleware selecting the model per task from a multi-model competition (local GLM/Qwen + cloud Anthropic/Google/OpenAI/Grok/Bedrock/DeepSeek), benchmark refreshed weekly. The Master Control System is designed to own this as the add/remove/route registry for AI models per org.

Sovereign Control Plane substrate (designed, not yet built)

• k3s cluster on a dedicated server (ABBI.312: DGX B200 + R760), one namespace per organization; Azure kept only as thin DR/burst.
• Self-hosted sovereign data platform: MinIO (object store) + per-org PostgreSQL + Qdrant (vectors); Snowflake demoted to an optional per-org connector.
• Cloudflare Access (SSO+MFA) gating a Snowsight-style web console + API; centralized credential lifecycle referencing values by [Bracketed_Name], never exposing them.

Phase-1 design artifacts (D1–D6 + Sovereign_Control_Plane_Architecture.drawio + a sovereign-console-mockup.html) live under ABBI.002.008 Master ABBI Design.

Deliverables

• realm-router service — router.js + com.abbi.abbi-dmn-realm-router.plist (LIVE; identity → realm proxy, default-deny, encrypted v2 key store).
• Shared ABBI-LibreChat app (Option B) — stock LibreChat v0.8.7 + official ABBI branding + per-user realm-router + v200-only local Hive Mind context; deployed & verified live 2026-07-18 (revision 0000016).
• Organization Master Design taxonomy — the global org/realm model + Architect rulings (grandfather MGC to bare v2/v20; Raj = cross-org v2/v20 authority; v200 cross-org default-deny) captured in the design memo and the v200-naming-standard.md.
• Sovereign Control Plane Phase-1 /devpolicy package — D1 infrastructure spec, D2 built-vs-to-complete, D3 Snowsight design spec, D4 autonomous production setup, D5 devpolicy execution plan, D6 tooling/build, architecture draw.io + console mockup.
• Process Controller (PE) — the automated restart/remediation brain (ABBI.002.013 / ABBI.003.001 umbrella), container v200-svc-procctl-east, currently PE_DRY_RUN=1 pending the I1 FALSE-RESTART fix.

Implementation by realm

Development status

Live now

• realm-router enforcing identity→realm routing with default-deny + encrypted v2 key store (Wave 2 verified 2026-07-14; OBJ-02 D4 encryption landed).
• Shared ABBI-LibreChat (Option B) deployed & verified 2026-07-18; v200 in-app render pending John's own sign-in.
• Conductor (LiteLLM on N1:4000) routing across the model competition.

In progress

• Organization Master Design — taxonomy SPAWNED, awaiting Architect confirmation of sequencing; Tailscale decomposition (V200 supreme tailnet + one tailnet per org) is its own un-started migration workstream.
• Process Controller PE still in PE_DRY_RUN=1 (I1 FALSE-RESTART bug) — decisions logged, not executed.
• V20 peer-provisioning (2nd developer as V20_ADMIN) — untested path, blocking broad dev onboarding.

Planned

• Sovereign Control Plane substrate — k3s + MinIO + per-org Postgres + Qdrant on the dedicated ABBI.312 server (Phase-1 /devpolicy package complete; server build pending gate). Target: manage all realms + all 4 portcos + future onboarding at up to ~10,000 users.
• Resolute + Banner realm-router cases wired in later waves.

Source documents (Gitea)

realm-router/router.js — the live identity→realm MCP proxy: resolveRealm, backendForRealm, AES-256-GCM v2 key store, default-deny, v200 /hive route.

com.abbi.abbi-dmn-realm-router.plist — the LaunchAgent that runs the router (bind host/port env, KeepAlive).

project_organization_master_design.md — the ABBI.368 global org/realm taxonomy + Architect rulings (naming, Raj cross-org authority, v200 default-deny).

project_abbi_librechat_multitenant_architecture.md — the per-org LibreChat + dedicated gateway pattern and the mandatory gateway caller-auth rule.

368 shared-app Option-B COMPLETE — the verified deploy record for the branded ABBI-LibreChat with per-user realm-router + v200 local-hive context.

v200-naming-standard.md — the realm/org naming standard the taxonomy updates (v200-* supreme, abbi-* shared services, org prefixes).

process-controller/README.md — the Process Controller / Progression Engine (ABBI.002.013 umbrella): restart + remediation brain, currently PE_DRY_RUN=1.

folder_registry.json — the FGS registry of record for ABBI.xxx numbering (source for the 002.008 / 002.013 / 368 mappings noted above).

What it is & why it exists

This tab is the honest, current inventory of every user-facing application, operator dashboard, and source-of-truth system running across the estate today — what it does, where it lives, which realm it serves, and its real status (live, partial, disabled, or under construction). Nothing here is aspirational: if a thing is a scaffold or turned off, it says so.

Objective: give the two new stack developers a single map of "what is actually running and who it is for", so they know which surface to open for a task, which systems are authoritative (never edit around them), and which apps are safe to touch versus deliberately frozen.

How it works

Apps fall into four delivery patterns. Web apps are fronted by Cloudflare (Pages or a CF Tunnel) with Cloudflare Access (Microsoft SSO) for anything user-facing; operator dashboards bind to the Tailscale IP only; container apps run on Azure Container Apps; and long-running local services run as macOS LaunchAgents on the Mac Studio (100.86.225.119) or Docker Compose stacks.

Each web surface enforces default-deny: an unauthenticated request to onboarding.abbi-ai.com or app.abbi-ai.com returns HTTP 302 to sovereignmind.cloudflareaccess.com, not the app. Operator dashboards simply have no public route at all.

Technical specification & design

The concrete stack actually used across these apps, verified in the repo:

Named files that matter: ops-dashboard route handlers (snapshot-route.ts, realm-health-route.ts, queue-route.ts, acis-route.ts, market-intel-route.ts, shared read-only pg-config.ts); the control-plane's app/control-center/page.tsx (five-tab UI) and app/api/pc-dag/route.ts; the Resogram automation services inbound/email_router.py (SMTP :2525) and pipelines/pipeline_watcher.py; and the Tauri desktop config under abbi-onboard/src-tauri/.

Deliverables

Concrete outputs this app surface produces:

• ops.abbi-ai.com — one read-only pane of estate health: process/service status, QMS session queue, three-realm health (V200/V2/V20x), ACIS security findings, Hurricane market intel, local app/daemon inventory. Port 3200, Tailscale-only.
• app.abbi-ai.com — the shared ABBI chat app (LibreChat) that real V2/V20 beta users log into via Microsoft SSO.
• resolute-librechat — the Resolute realm's own chat app instance (gateway-auth build), plus Resolute's Tailscale-only ops dashboards.
• abbi-onboard installers — signed Tauri desktop app: Windows x64 NSIS installer + macOS ARM64/Intel DMGs (via GitHub Actions CI).
• ABBIgram / Resogram feeds — private Mastodon timelines for MGC (internal) and Resolute Racing (org + per-horse accounts, driven by email + file-drop).
• onboarding.abbi-ai.com — this very portal (static, SSO-gated, default-deny allow-list).

Implementation by realm — which app serves whom

Development status — live / in progress / planned

LIVE now

• Ops Dashboard (ops.abbi-ai.com) — running under LaunchAgent com.abbi.v200-ops-dashboard. caveat Known display drift / ~9 rendering defects (staged root-cause id e391a4ba) — data is sound, presentation needs a fix pass; treat readings as indicative until repaired.
• app.abbi-ai.com (shared ABBI LibreChat) — SSO-gated (302 to CF Access), no public container ingress; 4 real users live since 2026-07-20.
• onboarding.abbi-ai.com — deployed 2026-07-22, HTTP 200 behind CF Access, allow-list {jstewart@, nyadav@} + default-deny.
• ABBIgram & Resogram — both Mastodon stacks up; Resogram automation LaunchAgents (inbound SMTP + pipeline watcher) running.
• Resolute app + ops dashboards + TrueNicks API — live on ACA, Tailscale-only.

IN PROGRESS

• Sovereign Control Plane under construction — early functional scaffold: app/control-center/page.tsx (5 tabs: Issue Registry, Registry Census, Process Status, Approvals, DAG & Queue) + one Postgres route. No package.json, port, LaunchAgent, or main-nav wiring yet; render-verified only, deferred pending APPLY_GATED.md review.
• abbi-onboard — Windows x64 cross-compile bug resolved (BUG-20260523-0020); production NSIS bundling routed through GitHub Actions CI.

DISABLED / PLANNED

• Realm_User_Listener (ABBI.002.026) disabled — built + tested across 7 waves (integrated E2E 6/6 on real Postgres) but NOT turned on. Marker file FEATURE_STATUS.DISABLED present; deploy authorized under batch 7b8f69a3, awaits explicit "turn on" + turn-on runbook. Do not create Graph subscriptions / enroll mailboxes while the marker exists.
• Banner realm app planned — no dedicated user app; first build target for the new dev team.

Source-of-truth systems (never edit around these)

Source documents (Gitea)

ops-dashboard/README.md — full spec of the Ops Dashboard: port 3200, LaunchAgent, every api/ route, data sources, credentials.

sovereign-control-plane/README.md — the UC scaffold: five-tab control-center page, PG-backed DAG route, and the explicit maturity/gap caveat.

onboarding-portal/README.md — hosting of this portal: Cloudflare Pages project, DNS, CF Access app + allow-list policy, redeploy/rollback.

onboarding-portal/DEPLOY_RECORD.md — the 2026-07-22 deploy record: resource ids, verification (302→SSO), 2nd-developer add procedure.

realm-user-listener/README.md — the DISABLED meeting-listener feature: 7 waves, test results, deploy batch, turn-on policy.

resolute-social/README.md — Resogram: Mastodon containers, email inbound router, pipeline watcher, per-horse accounts, credentials.

mgc-social/README.md — ABBIgram: MGC internal Mastodon stack, Tailscale-only access, operate commands.

abbi-onboard/BUILD.md — Tauri desktop build guide: Windows x64 cross-compile, macOS DMGs, CI artifacts, keyring stores.

Observability & realm health

Where to watch the estate per realm — and an honest note on what exists versus what doesn't.

What it is & why it exists

The Tools layer is the single toolbox every ABBI session reaches through one gateway. A session never talks to Snowflake, Microsoft 365, Azure, Cloudflare, an AI model or Dropbox directly — it calls a named tool (e.g. sm_query_snowflake, m365_send_email, cf_list_zones) and the gateway does the work, injecting the credential on the way out.

Objective: give agents one uniform, auth-injected surface to ~230 external and internal capabilities so that (a) the model never sees or handles a secret — every call carries X-API-KEY that the relay/worker holds, not ABBI; (b) routing, fallback and the Change Gate can be enforced in one place; and (c) new capabilities are added centrally without re-credentialing every client. The catalog snapshot on 2026-07-22 enumerated 234 tools; the hand-verified reference lists 237 — probe tools/list for the live truth.

How it works

A session opens one MCP endpoint over Tailscale. The Mac relay splits traffic: Snowflake / Hive-Mind tools race directly to Snowflake containers; everything else goes to one Cloudflare Worker that holds the per-service secrets (23 bound) and makes the outbound call.

Two consequences a developer must respect: (1) response shapes differ by family — sm_* returns {data:[...]}, hurricane_* returns {rows:[...]}; parse defensively as parsed?.data ?? parsed?.rows ?? parsed. (2) East is primary; west/AWS twins serve only when east fails (m365 east container is frequently deactivated — the west twin answers the identical call).

Technical specification & design

The toolbox is not one program — it is a routing tier plus a fleet of service backends. Verified components:

• Mac relay — Node.js (v200/services/alb-relay/relay.js), run as macOS LaunchAgent on the Mac Studio (100.86.225.119:8080). Does the sm_/hive-mind vs everything-else split and the staged Snowflake race.
• Cloudflare Worker — edge gateway v200-wrk-mcp-admin-gw-r74260eb (v200/workers/mcp-admin-lb/index-admin.js), holds the 23 bound per-service secrets and injects auth. mcp-admin-lb is the legacy worker name (zero secrets) kept only until retirement.
• Transport — MCP over Tailscale mesh VPN; header auth X-API-KEY.
• Snowflake backends — service containers on Azure Container Apps (sf-east-1/2/3, west twins) plus 4 AWS Lambda URLs (JGA82554) as the last fallback tier.
• AI model backends — mix of native worker handlers (OpenAI, Grok = direct API calls, no container) and container-backed (Vertex/Gemini, Imagen, Vision OCR on a vertex ACA container; Bedrock Claude/Titan/Llama; Azure OpenAI; DeepSeek; Copilot; Julius).
• Local Hive Mind — SQLite-first local store (sm_write_local / sm_query_local / sm_search_local); Snowflake is backup only.
• Health/catalog generator — tool-health-checker.py --emit writes the machine catalog (V200-CAPABILITY-REFERENCE.json / -CATALOG.md) with per-tool health; intended daily regeneration via com.abbi.v200-sjob-capability-reference-r74260eb.
• Change Gate — 3 client layers (CF Worker middleware, PreToolUse hook change-gate-check.sh, filesystem watcher change-gate.py) gate mutating tool calls; server-side Gitea Layer-1 is in ENFORCE.

Tool families (from the 2026-07-22 catalog, 234 tools)

Snowflake query tools — account & response shape (the most-missed facts)

Deliverables

• ~234–237 live tools reachable through one MCP endpoint, auth injected — no secret ever handled by the model.
• Capability Reference (CANON) — hand-verified operational map: tool→account/shape, credential-retrieval decision tree, gateway/egress topology, Change-Gate mechanics.
• Machine catalog — V200-CAPABILITY-REFERENCE.json + -CATALOG.md, per-tool health (PASS / CONTAINER_DOWN / SKIP_WRITE / AUTH_ERROR / FAIL) regenerated by tool-health-checker.py.
• Routing contract — tool-routing-architecture.md, the CANON three-rule doc (relay split, east-primary, LB carries only Snowflake).
• Per-realm exposure — admin gateway (X-API-KEY) vs V2 user gateway (Bearer, RLS-scoped).

Implementation by realm

Tool exposure differs by realm because there are two gateways: the v200 admin gateway (Tailscale-direct, X-API-KEY, full ~234-tool fleet) and the separate V2 user gateway mcp.abbi-ai.com (Bearer, RLS-scoped, user-facing). Realm separation is enforced: V200 can deploy for V2 but never shares infra/creds.

Development status

LIVE — the gateway is fully operational. Catalog health snapshot (2026-07-22T09:00, 234 tools): 155 PASS, 23 SKIP_WRITE (mutating tools the health-checker deliberately does not fire — not failures), 24 CONTAINER_DOWN (mostly M365 east — west twin serves), 21 AUTH_ERROR (mostly privileged/write ops), 10 FAIL (chiefly Google Drive reads), 1 TOOL_NOT_FOUND.

• Live Snowflake (sm_/hurricane_), Dropbox, Cloudflare/Vercel/Tailscale/Azure reads, Asana, Make, RunPod, most AI models, Mac reads, local Hive Mind.
• In progress / degraded M365 (east container deactivated, relying on west twin); Vertex Imagen + Vision OCR (CONTAINER_DOWN); markitdown_convert (CONTAINER_DOWN).
• Broken / stale Google Drive read/upload/move tools (FAIL/AUTH_ERROR); m365_list_folders (TOOL_NOT_FOUND); credential value-cache stale on IRA11585 (36 creds missing → fall back to hurricane_sm_query_snowflake on MASTER_CREDENTIALS).
• Planned Daily auto-regeneration of the capability reference (generator LaunchAgent pending — file is hand-verified until it lands); per-realm Resolute/Banner Snowflake account documentation.

Source documents (Gitea)

V200-CAPABILITY-REFERENCE.md CAPABILITY-REFERENCE-CATALOG.md CAPABILITY-REFERENCE.json tool-routing-architecture.md alb-relay/relay.js workers/mcp-admin-lb/index-admin.js shared/services/change-gate v200-intended-architecture.md

• V200-CAPABILITY-REFERENCE.md — CANON operational map: Snowflake tool→account/shape, credential decision tree, gateway topology, Change-Gate mechanics.
• -CATALOG.md / .json — generated per-tool catalog with account, response shape, auth header and live health status (234 rows, 2026-07-22).
• tool-routing-architecture.md — CANON three-rule routing contract (relay split, east-primary, LB carries only Snowflake); deprecation candidates.
• alb-relay/relay.js — the Mac relay source that splits sm_/hive-mind vs the CF worker and stages the Snowflake race.
• workers/mcp-admin-lb/index-admin.js — the Cloudflare Worker that holds per-service secrets and injects auth on outbound tool calls.
• shared/services/change-gate — the 3-layer Change-Gate that authorizes mutating tool calls.
• v200-intended-architecture.md — target-state topology for the gateway and service fleet.

What it is & why it exists

The ABBI CLI & Consoles stack is the primary terminal front-end for operating ABBI. The thing a developer actually launches is a Console — a dashboard that starts and manages multiple concurrent ABBI CLI sessions at once — and beneath each session sits the CLI engine (cli-v6 today, cli-v7 next) that runs the agentic tool-calling loop against ABBI's own model gateway.

Objective: give the two new developers (and every ABBI operator) a single, sovereign, multi-session terminal front-end — no dependency on any one vendor's CLI — that walks the user through picking their FGS project at launch, then runs an agentic loop with ABBI's full FS + Hive Mind + MCP toolset, with the best model chosen automatically per task.

How it works

The Console is the launcher/monitor; each session it spawns runs the CLI engine; the engine sends every tool-bearing turn to the Conductor (LiteLLM gateway on N1, http://100.87.243.54:4000/v1), which — with the Oracle scoring the capability_matrix.db — picks the model per task and returns the model actually used. Tools are discovered and executed over MCP.

At launch the engine walks the user through FGS project selection (writing ~/.claude/current-project.json), then drops into the REPL. The cli-v6 launcher (bin/abbi-cli) additionally offers an EXISTING/PRIOR-session restart menu and re-enters inside a reattachable tmux session — this is the multi-session behavior the Console orchestrates at scale.

Technical specification & design

Mac Console — Session Manager Console

• Python + Textual TUI, single app class ConsoleApp (console_app.py, ~3,500 lines). Renders to stderr (Textual) — never redirected to a file.
• console_session.sh launcher creates tmux server -L smconsole, session console, windows shared/mac/ipad; verbs start/attach/attach-mac/attach-ipad/status/stop (idempotent, non-gated).
• Socket isolation: Console on smconsole; interactive v200b on the default socket; QMS/queue on the queue socket — kept separate by design.
• Vocabulary of 11 STATUS + 5 KIND values from session_state.py; a WebSocket hub (console_ws.py) and a reporter LaunchAgent feed live state.

CLI engine cli-v6 (production)

• Package @abbi/cli v6.0.0, bin abbi-cli. TypeScript + React/Ink TUI (src/entrypoints/cli.tsx, Yoga WASM layout). Fork of the anon-kode agentic-coding tool, ABBI-hardened.
• OpenAI-style API client pointed at the Conductor (LARGE_MODEL_BASE_URL/SMALL_MODEL_BASE_URL = 100.87.243.54:4000/v1).
• ATP: tests/e2e-smoke.sh (real sessions vs real models, no mocks) + tests/benchmark-v200b-parity.sh.

CLI engine cli-v7 (Anthropic-independent, alpha)

• Package @abbi/cli-v7 7.0.0-alpha.1, bin abbi-v7. Node ESM + TypeScript. Project ABBI.1098 (W0B Server Independence).
• openai SDK pointed at Conductor (base abbi-conductor, override ABBI_CONDUCTOR_URL/ABBI_MODEL) — swaps Claude/Gemini/GPT/Grok/Mistral at runtime with no code change.
• @modelcontextprotocol/sdk over SSE (default FS MCP at 127.0.0.1:8765) + built-in Hive Mind (sm_query_local/sm_write_local against ~/.abbi/hive-mind-local.db).
• Agentic loop src/loop/agentic_loop.ts: MAX_ITERATIONS 25, context compaction at 85% of window, approval gate on destructive tools unless --autonomous. Core Memory cache (~/.abbi/cache/cli-v7-cache.json, 4h TTL). Deps: commander, chalk, ora, sqlite3, tiktoken.

Routing — Conductor + Oracle

• Conductor = LiteLLM on N1 (100.87.243.54:4000); returns the actual model used as resolvedModel.
• Oracle selects per task by scoring capability_matrix.db (SQLite): 32 models, 396 model_scores across 12 dimensions (accuracy, code, context, cost, financial, multilingual, persuasion, privacy, realtime, speed, tools, vision), 25 tools / 200 tool_scores. 11 free-local models (cost 0) and 11 at privacy_tier=local (9 ollama + MLX + llama-cpp).

Windows Console kit (v20)

• abbiv20.cmd / abbiv20.ps1 PATH shim launching PowerShell 7; rides the v2 gateway (mcp.abbi-ai.com) with persona=v20admin. Ships 24 v2-gateway tools + 52 curated skills + a memory seed corpus (per v20-manifest.md).

Deliverables

• Mac Console (Session Manager Console) — live Textual TUI multi-session dashboard on smconsole.
• cli-v6 — production agentic CLI engine (@abbi/cli 6.0.0, abbi-cli) with ATP smoke + parity suites.
• cli-v7 — Anthropic-independent CLI engine (@abbi/cli-v7 7.0.0-alpha.1, abbi-v7) routed through Conductor/LiteLLM.
• claude-cli harness — the Mac Studio client (hooks, session tracking, Change-Gate Layer-2, memory) every session runs inside.
• Windows install-kit — abbiv20 console shim + 24-tool / 52-skill / memory corpus manifest for the v20admin machine.
• capability_matrix.db — the 32-model / 396-score routing matrix the Oracle reads.

Implementation by realm

Development status

Live now

• Mac Console (Session Manager Console) running on the Mac Studio; attach via SSH + console_session.sh attach-mac.
• cli-v6 (@abbi/cli 6.0.0) fully functioning; per project record its 14-test ATP suite is green (commits 09b2b29 / ea3775d); interactive REPL works end-to-end. In-repo suites: e2e-smoke.sh, benchmark-v200b-parity.sh.
• Windows Console kit live for the sole V20_ADMIN (Raj).
• Conductor routing over capability_matrix.db (32 models / 396 scores / 12 dims / 25 tools / 11 free-local).

In progress — hardening gate before broad rollout

• cli-v6 --print tool-hang (BUG be4baa2e, P3): one-shot --print mode hangs ~127s with no tool result while the interactive REPL is fine. Fix = align --print with the interactive path (getModelForRequest + awaited MCP getClients + bounded connect timeout).
• cli-v7 broken-transport / "no tool loaded": targeted by the Conductor tool-accessibility grid (models × tools live-probed) to prove tool discovery over MCP-SSE.
• Conductor reachability: N1:4000 has shown DEGRADED/timeout — needs a standby Conductor + ABBI_CONDUCTOR_FALLBACK_URL routing guard.
• cli-v7 remains 7.0.0-alpha.1 pending these items + ATP green across CLI + consoles.

Planned

• Broad developer/user rollout of the console + CLI after hardening, tied to the local-model migration and the ABBI.312 server build (Roadmap tab) — up to 10,000 users across all realms + portcos.

Source documents (Gitea)

v200/services/session-manager/console v200/apps/cli-v6 v200/apps/cli-v7/README.md v200/clients/claude-cli v20/clients/install-kit/v20-manifest.md shared/scripts/capability_matrix.db v200/apps/cli-v6/tests/e2e-smoke.sh

• session-manager/console — the Mac Console: Textual TUI (console_app.py), launcher (console_session.sh), session-state vocabulary, WebSocket hub, README.
• apps/cli-v6 — production CLI engine (@abbi/cli 6.0.0): src/ (Ink TUI, tools, query loop), bin/abbi-cli tmux multi-session launcher, CHANGELOG.
• apps/cli-v7/README.md — full spec of the Anthropic-independent engine: Conductor URL, agentic loop, MCP-SSE tools, Core Memory cache, env names.
• clients/claude-cli — the Mac Studio harness every session runs inside: hooks, session tracking, Change-Gate Layer-2 (change-gate-check.sh), memory mirror.
• v20-manifest.md — the Windows console's exact 24 v2-gateway tools, 52 curated skills, memory corpus, and the 23 v200-only skills explicitly excluded from v20admin.
• capability_matrix.db — the Oracle's routing matrix (models, model_scores, tools, tool_scores, routing_rules).
• cli-v6/tests/e2e-smoke.sh — the ATP smoke suite: real sessions against real models via the Conductor, no mocks.

What it is & why it exists

The Roadmap is the planned path that takes ABBI from its current dependency on a frontier model (Anthropic Claude) for tool-bearing turns to a sovereign, fully-local stack that runs on hardware MiddleGround owns and controls. Every step exists to answer one question a new developer will ask on day one: "When does ABBI stop calling out to Claude, and what runs it instead?"

Objective: remove the frontier-model dependency for tool use by finishing local-model training (abbi-core), harden the CLI and console front-ends so they are safe to hand to real users, then stand up a dedicated production server (DGX B200 + R760) running the Conductor routing plane and the full ABBI stack for up to 10,000 users across all realms — V200, V2, V20, Resolute, Banner — plus all four portfolio companies and future onboarding companies.

How it works — the migration sequence

Five milestones run in sequence. The first is live today; the last is the destination.

The router that makes the model choice per turn is the Conductor (LiteLLM on node N1, port 4000) reading a capability matrix — a SQLite scoring database of every model against every tool, skill and task dimension. As local models close the capability gap, the matrix stops selecting the frontier entry on its own, and the migration completes by data rather than by a hard cutover.

Technical specification & design

The actual technology, verified in the repo:

• Routing plane — Conductor + LiteLLM. LiteLLM proxy on node N1 at :4000; config abbi-server/node1/litellm/config.yaml defines 54 model routes including abbi-anthropic-sonnet (Claude, the frontier tool route) and abbi-tool (llama3.3:70b, the local fallback). Selection logic in conductor_middleware.py + model_registry.py.
• Capability matrix — SQLite. abbi-server/node1/litellm/capability_matrix.db, live-counted: 33 models, 397 model scores, 25 tools, 66 skills, 7 user profiles — scores every model per dimension so the router can prefer free-local models with no frontier bias.
• Serving substrate — 4-node Apple M3 Ultra Mac server. abbi-ultra-1..4, each M3 Ultra / 512GB / 32-core (macOS 26.2). N1 serves LiteLLM; abbi-ultra-3/abbi-ultra-4 run ollama (never the apeirin extraction fleet). MLX is installed on N1 with N3/N4 as install targets.
• Training stack — LoRA + RL / DPO-ORPO. Recipe uses MLX (mlx_lm.lora, mlx-tune for DPO/ORPO). Per the 2026-06-13 node directive, heavy training runs on RunPod (CUDA) and the trained model deploys to the 4-node Mac server for serving. Training data: Domain A Industrial B2B (~6,770 pairs) + Domain B ABBI Ops (~3,100), v4 pairs (1,501), 4 RAG collections. Weights stay on local disk (not Gitea).
• Production server (planned) — DGX B200 + Dell R760. Runs the Sovereign Control Plane (registry ABBI.002.021): k3s + MinIO + per-org Postgres + Qdrant, one namespace per org, Cloudflare Access SSO, with Snowflake/Azure minimized.
• Front-ends — CLI engines. cli-v6 (14-test ATP suite green) and cli-v7, launched/managed through the Mac and Windows consoles.

Deliverables

• A Conductor routing config that selects local models by default and invokes the frontier model only when a task requires it (today: tool-bearing turns).
• A trained, deployable abbi-core local model with positive reward deltas that restores fully-local tool use, enabling removal of the abbi-anthropic-sonnet frontier entry.
• Hardened CLI + consoles passing ATP suites across the interactive REPL and --print paths, with a standby Conductor and a tool-accessibility routing guard.
• A dedicated production server (DGX B200 + R760) running Conductor + the full ABBI stack, sized for up to 10,000 users, with the 4-node Mac cluster demoted to dev/extraction.
• A per-realm migration status so each realm's move off the frontier model is tracked, not assumed.

Implementation by realm

Migration status = how far each realm is along the path from frontier-dependent to fully-local serving.

Development status

Live Today's frontier dependency

cli-v6 is in production and routes tool-bearing turns to abbi-anthropic-sonnet (Claude/Sonnet) with abbi-tool (llama3.3:70b) as fallback — confirmed in the live LiteLLM config. This is the dependency the whole roadmap exists to retire.

In progress Local migration, training, and CLI hardening

• Local migration (M2): Conductor + capability matrix operational on the 4-node Mac Ultra server; goal is unbiased free-local model selection. Known risk: N1:4000 has shown DEGRADED/timeout — needs a standby Conductor + ABBI_CONDUCTOR_FALLBACK_URL.
• abbi-core training (M3): LoRA + RL underway with positive reward deltas achieved (e.g. +0.060 on Qwen2.5-3B). This is the gating item — the frontier tool route cannot be removed until local tool use is restored.
• CLI hardening (M4): open items — cli-v6 --print tool-hang (~127s, BUG be4baa2e; interactive REPL works), cli-v7 broken-transport / "no tool loaded", and the Conductor tool-accessibility grid (22 models × 25 tools live-probed). All must pass ATP before broad user rollout.

Planned ABBI.312-class production server

The DGX B200 + R760 build is the production substrate for up to 10,000 users; the 4-node Mac cluster then becomes dev/extraction. Phase-1 /devpolicy package is complete; the physical server build is pending its gate.

Source documents (Gitea)

The live LiteLLM route table (54 model routes) — shows abbi-anthropic-sonnet (Claude, today's tool route) and the abbi-tool/llama3.3:70b local fallback.

Conductor selection middleware + model_registry.py and the capability_matrix.db (33 models / 397 scores / 25 tools) that drive per-turn model choice.

The Conductor service tree (app / client / middleware / v2) — the routing plane that migrates from frontier to local.

The node directive: 4-node M3 Ultra roles (serving vs training), the RunPod-CUDA training-then-deploy correction, and the MLX LoRA/DPO recipe.

The current CLI engine (14-test ATP suite) — the front-end being hardened in milestone 4.

The next-generation CLI engine (transport fixes targeted by the tool-accessibility grid).

The FGS registry of project numbers/statuses — authoritative source for the ABBI.002.021 Sovereign Control Plane and the ABBI.312/304 renumberings noted above.

What it is & why it exists

FGS (File Governance System) is the single, authoritative registry and folder-governance layer for every project the firm runs. It gives each project a stable ABBI.### number, a standardized two-audience folder layout inside the Managing Partner's Dropbox, and an always-on daemon that keeps those folders clean without human filing. It is the "card catalog + librarian" for all AI work.

Objective: make every project findable by a durable number (not a fragile path), separate deliverables addressed to the Managing Partner from ABBI's own process artifacts, and guarantee that superseded versions are archived automatically so the current version is never ambiguous. The registry is what the ABBI CLI reads at launch to walk a user through project selection.

How it works

FGS is three cooperating pieces: a JSON registry (the map), an onboarder that mints new numbered folders, and an fsevents-driven archiver daemon that watches the live folders and files superseded versions away. A weekly LaunchAgent runs structure + naming audits and writes a Hive Mind summary.

  new project                       every FGS project folder
  ----------                        ------------------------------------
  fgs_onboard.sh  --mints-->        [ABBI.### Project]/
    assigns ABBI.###                  USER/
    writes physical_path                USER-CV/        latest MP deliverables
    updates folder_registry.json        USER-Archive/   superseded  -> YYYY-MM/
        |                               ABBI/
        v                                 ABBI-CV/       CTDs, plans, contracts, build
  folder_registry.json  (v3.3) ------->   ABBI-Archive/  superseded  -> YYYY-MM/
     |  read at launch                     Context/  Session Logs/  Instructions/
     v                                    USER UPLOAD/    MP drop zone -- NEVER touched
  ABBI CLI project-picker
  (current-project.json)              fgs-auto-archive.py --watch  (fsevents daemon)
                                        supersede: higher version > later date > mtime
  fgs-registry-tools.py                 loser -> SAME SIDE's Archive/YYYY-MM bucket
   audit | structure |                  10-min + 0-byte stability guards; CTD_* never moved
   naming-audit | weekly              weekly LaunchAgent: audits + Hive Mind summary

Supersede rule (auto-archive v3): within a CV folder, files sharing a base name (stripped of version/date affixes) are ranked by highest version, then later date, then HHMM/mtime; the loser moves to the matching USER-Archive/ or ABBI-Archive/ under the current YYYY-MM bucket. Nothing archives while its superseding file is 0-byte or was modified in the last 10 minutes, and CTD_* / session-log files are never supersede-archived.

Technical specification & design

Stack in one line: Python 3 tooling + JSON registry + macOS launchd/fsevents daemon over a Dropbox filesystem, with Gitea as the versioned source of truth and Hive Mind (SQLite/Snowflake) receiving audit summaries. No web framework, no external DB — deliberately simple and local.

Deliverables

• A durable project number (ABBI.###, sub-numbered ABBI.###.###) for every project, block-allocated by universe.
• A standardized folder tree per project: USER/USER-CV + USER-Archive, ABBI/ABBI-CV + ABBI-Archive + Context / Session Logs / Instructions, plus an exempt USER UPLOAD drop zone.
• Automatic version archival — superseded files continuously swept into month buckets on the correct audience side.
• The CLI boot inventory — the registry is the list the ABBI CLI reads to walk users through project selection at launch.
• Governance reports — weekly structure + naming-conformance audits and a Hive Mind summary; drift/conflict alerts.
• The full project enumeration (appended below) — the complete active project inventory grouped by realm.

Implementation by realm

FGS is one governance system that runs on the V200 Mac Studio and governs the Managing Partner's Dropbox. It is not deployed per-realm; instead, every realm's projects are cataloged in and governed by the single registry. The grid below reflects each realm's real footprint in the registry (v3.3).

Development status

LIVE Registry v3.3 (last updated 2026-07-22, onboarder v4.1) with 247 folder entries; the fgs-auto-archive daemon is a live KeepAlive LaunchAgent watching CV folders; the weekly audit LaunchAgent runs structure + naming audits and writes Hive Mind summaries; the naming standard is v2.0 (report-only on pre-existing files, mandatory for new files/folders).

IN PROGRESS Transition off the legacy layout: "Needs Update" is eliminated and legacy CV/ + Archive/ catch-basins are being swept into the two-audience layout; those basins are removed only by a gated pass after two consecutive clean weekly audits. Registry-vs-filesystem drift remediation and conflicted-copy scans run on the weekly cadence.

PLANNED / ONGOING Continuous onboarding of new numbered projects (next top-level = 389) as the four portcos and future companies come online; the registry remains the inventory the ABBI CLI and the Developer Onboarding Portal enumeration read from.

Source documents (Gitea)

folder_registry.json (v3.3) The registry itself — every project's number, universe, status, physical_path, keywords, and the universe number-blocks.

fgs-registry-tools.py The query/audit toolkit: audit, structure, naming-audit, rebuild-index, roundtrip-test, weekly.

fgs-auto-archive.py (v3) The fsevents archiver daemon — supersede matching, month buckets, stability guards, legacy-basin sweep.

fgs_onboard.sh The onboarder (v4.1) that mints a new ABBI.###, builds the folder tree, and registers it.

fgs-file-naming-standard.md (v2.0) The two-audience folder layout, machine-validated file grammar, and audience routing rules.

fgs_naming_enforce.py Naming-enforcement helper applying the standard's tiers to files.

com.abbi.fgs-auto-archive.plist The launchd definition (RunAtLoad + KeepAlive) that keeps the archiver watching on the Mac Studio.

Live inventory — 228 active projects

Enumerated directly from the canonical registry ~/.abbi/scripts/folder_registry.json (v3.3, 2026-07-22). Grouped by realm/organization. Dashboards built but no longer maintained are flagged UNDER CONSTRUCTION.

Infrastructure & Platform: 112 · MiddleGround (MGC): 90 · Resolute: 7 · Banner: 2 · AI Research: 9 · Personal: 8

Infrastructure & Platform 112

MiddleGround (MGC) 90

Resolute 7

Banner 2

AI Research 9

Personal 8

What it is & why it exists

v20 is the contractor/developer admin tier — the identity your two new stack developers actually log in as. It sits between ordinary V2 users (standard MiddleGround employees) and the v200 ADMIN (the Managing Partner's own instance). A V20_ADMIN has full administrative control over the V2 and v20 infrastructure (user management, API keys, all V2 Snowflake data and procs) but has zero v200 access — Sovereign Mind, master credentials, and the v200 Azure/Cloudflare control plane are hard-blocked.

Objective of this tab: give both developers one authoritative page for how they get access — what role they receive, through which gateway it is provisioned, what still needs to be tested, and how they reach this portal. The governing fact today: Raj Yadav (nyadav@middleground.com) is the SOLE existing V20_ADMIN (verified by live query of account SXA84406). The 2nd developer must receive the same V20_ADMIN role — and the path by which one V20_ADMIN provisions a peer V20_ADMIN has never been exercised.

How it works

The 2nd developer is onboarded by having Raj (a V20_ADMIN) provision them as a peer V20_ADMIN through his own tooling. That provisioning must run against the V2 admin gateway (mcp.abbi-ai.com / the v2gw Cloudflare Worker), not the v200 sm_ tool — the v200-side Snowflake replica (account IRA11585) is a stale replica; writes there race and duplicate. The v20 client rides the v2 gateway with persona=v20admin, and the gateway routes tools/list to the V2 backend (nothing v200-unique). Every Hive Mind read/write goes through that authenticated V2 user gateway to V20_ADMIN_HIVE_MIND.

Onboarding steps for the 2nd developer:

1. Get the 2nd developer's Microsoft (@middleground.com) email from Raj — or provision with a placeholder and update.
2. Test the peer-provisioning path: Raj provisions the 2nd dev as V20_ADMIN through the V2 admin gateway (mcp.abbi-ai.com), then verify Row-Level Security and login. This is simultaneously (a) how the 2nd dev gets access and (b) the first real test of Raj's admin capability.
3. Provision a Gitea account and tailnet (Tailscale) access on day one (Raj already has both).
4. Add the 2nd dev's email to the onboarding.abbi-ai.com Cloudflare Access allow-list.

Technical specification & design

The v20 access stack is built from these concrete components (all verified in the repo):

• Gateway: Cloudflare Worker v2gw at mcp.abbi-ai.com/mcp (+ /config), hardcoded in the client bootstrap proxy — v2/workers/v2-mcp-gateway-east/worker.js and v2/clients/install-kit/proxy/v2-gateway-bootstrap-proxy.cjs. Auth is a Bearer header; the proxy fetches a per-user config. SQL is fenced by validateV20AdminSQL (v200/SOVEREIGN blocked).
• Identity / SSO: Cloudflare Access in front of onboarding.abbi-ai.com, using the azureAD IdP "MiddleGround Microsoft" (102fbe82…). Default-deny allow-list policy.
• Data plane: Snowflake — V2 account SXA84406 (V2_ABBI_AI_WH, schemas V2_ADMIN_HIVE_MIND, V20_ADMIN_HIVE_MIND); HURRICANE is read-only for v20. The v200 replica IRA11585 is explicitly excluded.
• Client consoles: Windows launcher (abbiv20.cmd, abbiv20.ps1 in the install kit; abbiv20admin.ps1, launch-v20admin.ps1 under v20/clients/windows/) and the Mac CLI. Raj's Windows path is MGC-LT140.
• Boot governance: boot-prompt-v20admin v21.0 (ABBI.357 batch 92ce1f5e, 2026-07-07) — decision table, escalation policy, no-PIN audit-only authority.
• Client bundle: 24 gateway tools + 52 curated skills + a 6-file memory seed corpus (see v20-manifest.md). Tools include sm_query_snowflake (full V2 admin SQL), sm_hive_mind_read, M365 (7), Dropbox (3), DealCloud (4), Asana (3), plus abbi_bootstrap.
• Networking: Tailscale tailnet membership required per developer; Gitea (abbi/abbi-infrastructure) for source access — v2/ + v20/ full commit, v200/ read-only.

Deliverables

• A provisioned V20_ADMIN identity for the 2nd developer in V2_ADMIN_HIVE_MIND.USERS (persona V20_ADMIN, ACTIVE, own hive-mind schema), created via mcp.abbi-ai.com.
• A verified peer-provisioning run — the first successful "V20_ADMIN provisions a peer V20_ADMIN" cycle, with RLS + login confirmed.
• A Gitea account and tailnet device for the 2nd developer.
• The 2nd developer's email added to the Cloudflare Access allow-list for onboarding.abbi-ai.com.
• Installed v20 console + client bundle (24 tools, 52 skills, memory corpus, boot-prompt-v20admin v21.0).

Implementation by realm

The rows below contrast the three admin roles this tier is defined against (from the approved v20admin role-design access matrix) plus the portfolio realms.

Development status

LIVE now:

• Raj onboarded as the sole V20_ADMIN (SXA84406-verified); ABBI.357 behavioral governance deployed — boot-prompt-v20admin v21.0, memory corpus, /IB + /fix-repair skills, raj-path-probe LaunchAgent.
• v20 install kit (Windows console) + v20-manifest.md (24 tools, 52 skills, memory corpus) in Gitea.
• Portal deployed at onboarding.abbi-ai.com behind Microsoft SSO (Cloudflare Access) — unauthenticated request returns HTTP 302 → Cloudflare Access login (SSO enforced, verified 2026-07-22). Allow-list: jstewart@ + nyadav@, default-deny.

IN PROGRESS / open:

• Peer-provisioning path — "a V20_ADMIN provisions a peer V20_ADMIN" has never been run. This is the primary untested path and must be exercised through mcp.abbi-ai.com (not the v200 sm_ tool).
• 2nd developer enrollment — needs their @middleground.com email, then: provision V20_ADMIN, verify RLS + login, add to CF Access allow-list, issue Gitea + tailnet access.

Source documents (Gitea)

v20/clients/install-kit v20-manifest.md boot-prompt-v20admin.txt v20 memory corpus v20/clients/windows v20admin role-design spec v2 install-kit README (gateway) v2gw gateway worker onboarding portal DEPLOY_RECORD

• v20/clients/install-kit — the full v20 client bundle: boot prompt, memory seed, curated skills, Windows launchers.
• v20-manifest.md — authoritative pin of the 24 v2-gateway tools and 52 curated skills a v20admin receives.
• boot-prompt-v20admin.txt — v21.0 (ABBI.357 batch 92ce1f5e): tier definition, access-grant matrix, escalation policy, no-PIN audit model.
• v20 memory corpus — MEMORY.md index + feedback files (escalation policy, definition-of-done, durability, rollback-before-change).
• v20/clients/windows — Windows console launchers (abbiv20admin.ps1, launch-v20admin.ps1) for the developer machine.
• v20admin role-design spec — approved (Gate 1) access matrix comparing v20admin vs v200 ADMIN vs V2 User, plus role-creation SQL.
• v2 install-kit README — documents the hardcoded gateway mcp.abbi-ai.com/mcp the v20 client rides.
• v2gw gateway worker — the Cloudflare Worker that routes v20admin persona traffic to the V2 backend.
• onboarding portal DEPLOY_RECORD — CF Pages + DNS + Access app 589fd914… + allow-list policy 7aa68fd4…, SSO verification, and the exact step to add the 2nd developer.