░░░░░░░░░░░░░░░░░░░
░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░
░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░ P U R P L E H A T
░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░
░░░░░░░░░░░░░░░░░░░
░░░░░░░░░░░░░
╭──────────────────────╮
╭╯ ◈ ◈ ╰╮
│ ◡ ◡ │ SnapKitty
│ ╰──────╯ │
╰──────────────────────╯
╰──╮ ╭──╯
──────────────────────────────────────
S N A P K I T T Y O S
──────────────────────────────────────
The machine is the extension of the mind. The backend is not hidden — it is the product.
collectivekitty.com · War Room · 11 Agents · Discord Terminal · Contributing
This repository is source-available under the Functional Source License 1.1 (FSL-1.1).
- You can: read, learn, contribute, build non-competing products
- You cannot: build a commercial product that competes with this system without a separate license
FSL-1.1 is not OSI-approved open source. Commercial competing use is prohibited. To license for competing use: jessica@snapkitty.com
The code is visible. The architecture is not free.
This is not a startup. This is not a SaaS product with agents bolted on. This is a sovereign operating system — a monorepo where every layer of a business runs through AI reasoning, cryptographic sealing, and an immutable audit trail.
Nobody has built this.
What exists out there: AI chatbots. Agent frameworks that respond to prompts. Discord bots that answer FAQs. Fintech dashboards that show you data.
What we built: Eleven domain-expert AI agents — each with a name, a color, a peer network, and the authority to seal their decisions to a permanent ledger. A 5-tier fundability state machine written in both TypeScript and Rust, where every tier advancement requires dual-gatekeeper cryptographic approval. A Bifrost pipeline that routes every financial event through 8 deterministic stages before it touches the database. A Discord terminal where you can query any of the 11 agents in real time and get live LLM responses sealed to a Merkle chain.
The backend is not a service you call. It is the product you see.
DEVFLOW-FINANCE/
│
├── collectivekitty/ ← Sovereign frontend (Next.js 16 · React 19)
│ ├── pages/war-room/ ← Real-time agent reasoning — the brain made visible
│ ├── pages/api/ ← 65+ REST handlers — agents, finance, ledger, Discord
│ ├── lib/bifrost/ ← 8-stage event pipeline (TS implementation)
│ ├── lib/agent/ ← FSM · schema interceptor · reasoning engine
│ ├── lib/knowledge/ ← RAG · graph · vector store · web search
│ ├── lib/tier-state-machine.ts ← 5-tier fundability machine
│ └── prisma/schema.prisma ← Neon PostgreSQL · 20+ models
│
├── snapkitty-core/ ← Rust substrate — the foundation 🦀
│ ├── src/logic_loop.rs ← Sovereign event loop · three-pillar preflight
│ ├── src/tier_state_machine.rs ← 5-tier machine (Rust mirror)
│ ├── src/decision_seal.rs ← SHA-256 decision sealing engine
│ ├── src/merkle.rs ← Merkle tree — proof of ledger integrity
│ ├── src/azure_worm.rs ← Azure Blob WORM · 7-year immutability
│ ├── src/pyo3_bridge.rs ← Python FFI bridge (optional feature)
│ ├── src/wasm.rs ← WebAssembly bindings
│ └── src/agents/ ← 5 Rust agent modules
│
├── snapkitty-wasm/ ← Rust → WASM · browser-side sealing
│ └── src/ ← Leptos CSR · SHA-256 in the browser
│
├── collectivekitty-ml/ ← Python ML microservice (FastAPI)
│ ├── routers/score.py ← Bifrost risk scoring
│ ├── routers/predict.py ← Event outcome prediction
│ └── services/scoring_engine.py ← MLTPL scoring model
│
├── bindings/ ← C/C++ FFI layer (future: post-quantum crypto)
│
└── .github/workflows/ ← CI/CD · 14-route smoke tests · branch protection
Every agent is a sovereign domain expert. Named. Colored. Opinionated. They don't guess — they reason, verify peers, and seal every decision.
╔══════════╦═════════════╦══════════════════════════════╦══════════════════════╗
║ NAME ║ KEY ║ DOMAIN ║ AUTHORITY ║
╠══════════╬═════════════╬══════════════════════════════╬══════════════════════╣
║ RELAY ║ bridge ║ Human-Machine Bridge ║ Plain English ║
║ CIPHER ║ finance ║ GL · Triple-Entry · Pools ║ Ledger authority ║
║ VAULT ║ treasury ║ Reserves · Freeze · Balance ║ ✦ PAYMENT VETO ║
║ NEXUS ║ crm ║ Pipeline · Deals · Forecast ║ Revenue visibility ║
║ AXIOM ║ procurement ║ Vendor Trust · PO · Spend ║ Purchase execution ║
║ HERALD ║ bifrost ║ Event Routing · Traces ║ Event chain ║
║ PRISM ║ ml ║ Risk Scoring · Anomalies ║ Threat detection ║
║ SENTINEL ║ risk ║ Threat Score · Compliance ║ Security gate ║
║ LEDGE ║ auditor ║ Chain Integrity · WORM ║ Immutable record ║
║ ATLAS ║ operator ║ Health · Alerts · Recovery ║ ✦ TIER GATE ║
║ QUILL ║ scriptwriter║ Reports · Decks · Content ║ Human output ║
╚══════════╩═════════════╩══════════════════════════════╩══════════════════════╝
Tier advancement requires BOTH VAULT and ATLAS. Neither agent alone can advance the tier. This is a dual-gatekeeper pattern sealed in Rust — not enforceable by configuration, not bypassable by code.
Each agent operates through a Finite State Machine with these states:
IDLE → PREFLIGHT → REASONING → CONSULTING_PEERS → SEALING → RESPONDING → IDLE
↓
PREFLIGHT_FAILED (terminal — no output, no partial state)
╔═══════════════════════════════════════════════════════╗
║ SNAPKITTY WAR ROOM — LIVE FEED ║
╠═══════════════════════════════════════════════════════╣
║ [P1:SEAL] ✓ nonce=a3f7c9e1 validated ║
║ [P2:CHAIN] ✓ payload integrity confirmed ║
║ [P3:IDENTITY]✓ VAULT verified in AGENT_ORDER ║
║ ───────────────────────────────────────────────── ║
║ VAULT consulting → LEDGE, ATLAS ║
║ LEDGE: chain intact · 847 sealed entries ║
║ ATLAS: tier Ø requirements met · approving ║
║ ───────────────────────────────────────────────── ║
║ VAULT: "Treasury reserve at $12,400. Payment ║
║ approved. Seal initiated." ║
║ SEAL: sha256(vault:approved:2026-05-17T14:32:11Z) ║
║ → a9f3b7c2d1e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0 ║
╚═══════════════════════════════════════════════════════╝
The War Room makes the machine's reasoning visible in real time. Every query goes through a three-pillar preflight — implemented identically in both Rust and TypeScript:
| Pillar | Check | Failure behavior |
|---|---|---|
| P1: SEAL | Nonce computed and validated (16-char hex, deterministic) | Query dropped immediately |
| P2: CHAIN | Payload integrity — no nulls, no tampering | Query dropped immediately |
| P3: IDENTITY | Agent verified against AGENT_ORDER registry | Query dropped immediately |
If any pillar fails: PREFLIGHT ABORTED. Zero output. Zero partial state. The chain stays clean.
"People aren't wiring Discord bots to live AI agents. What we built here is evolutionary."
Most Discord bots answer static questions. Ours is a terminal into a live, running AI operating system.
Type a slash command in Discord → it hits the Next.js API → routes to Ollama → the local LLM reasons with full agent persona → the reply is sealed to the ledger chain → you get a live response in under 30 seconds.
Discord Channel → /ask agent:vault message:approve the $500 transfer
│
▼
bot.mjs (Gateway WebSocket — always connected)
│
▼
interaction.deferReply() ← instant "thinking..." in Discord
│
▼
http://localhost:3000/api/agents/chat
│
▼
Ollama (llama3.1:8b on RTX 5000 — resident in RAM)
│
▼
SHA-256 decision seal
│
▼
interaction.editReply("VAULT: Treasury reserve at $12,400...")
│
▼
Live response in Discord, sealed in ledger
/ask [agent] [message] → Route any question to any of the 11 agents (live LLM)
/pool create → Create a named money pool with purpose and target
/pool list → View all active pools and current balances (from DB)
/pool fund → Add capital to a pool (Prisma write)
/pool close → Archive a pool
/tier → Current fundability tier and what's blocking next tier
/agents → Full agent directory with domains and authority
/status → System health — Bifrost, database, infrastructure
/seal → Last decision seal event from WORM chain
/audit → Last 5 sealed events with risk scores and timestamps
/merkle → Merkle root hash and chain entry count
| Feature | Typical Discord Bot | SnapKitty |
|---|---|---|
| Response source | Hardcoded strings | Live Ollama LLM |
| Agent memory | None | Full persona + peer network |
| Data access | None | Live Prisma DB |
| Audit trail | None | SHA-256 sealed ledger |
| Concurrency model | Blocking | Deferred reply (type 5 async) |
| Timeout handling | Times out at 3s | Defers instantly, works async |
The type 5 deferred interaction pattern — where Discord gets an instant acknowledgment and the real work happens in a background async chain — is how we solved the 3-second Discord timeout constraint. The bot sends {type: 5} back to Discord in under 100ms, then patches the message with the real response up to 15 minutes later. This architectural pattern is our own.
Every event that enters SnapKitty OS travels through a deterministic 8-stage pipeline before it touches the database.
┌─────────────────────────────────────────────────┐
│ BIFROST PIPELINE │
├─────────────────────────────────────────────────┤
│ │
│ EVENT IN ──→ [1] VALIDATE ──→ [2] INGEST │
│ │ │ │
│ (Zod schema) (persist raw) │
│ ↓ │
│ [3] TRANSFORM ←───────┘ │
│ │ │
│ (Sovereign Substrate prep) │
│ ↓ │
│ [4] SCORE │
│ ┌─────┴────────┐ │
│ ML service TS rules fallback │
│ └─────┬────────┘ │
│ ↓ │
│ [5] ROUTE │
│ ┌─────┴────────────────────┐ │
│ low risk high risk → flag │
│ └─────┬────────────────────┘ │
│ ↓ │
│ [6] PERSIST ──→ [7] NOTIFY │
│ │ │ │
│ (update DB) (alert if flagged) │
│ ↓ │
│ [8] AUDIT ──→ WORM ARCHIVE │
│ │
│ Retry: 3 attempts max → dead-letter queue │
└─────────────────────────────────────────────────┘
6-topic QStash async queue routes events across domains:
| Topic | Events |
|---|---|
bifrost |
Risk scoring, pipeline events |
crm |
Deal updates, opportunity scoring |
finance |
GL entries, reconciliation |
procurement |
Vendor scoring, PO events |
ml |
Anomaly detection, tensor scoring |
hub |
Chain-of-thought intelligence |
Business credit is a staged progression — not a score. Each tier is cryptographically sealed before the next tier can be unlocked. Written in both TypeScript and Rust (identical deterministic behavior).
┌─────────────────────────────────────────────────────────────────┐
│ 5-TIER FUNDABILITY MACHINE │
├──────────┬──────────────────────────────────────────────────────┤
│ TIER 0 │ FOUNDATION │
│ │ Entity · EIN · Business bank · Address · Phone │
│ │ Seal = SHA-256(params) + VAULT approval + ATLAS gate │
├──────────┼──────────────────────────────────────────────────────┤
│ TIER 1 │ FUNDABILITY SUBSTRATE │
│ │ Google Business · 411 · Website+HTTPS │
│ │ Domain email · DUNS · NAICS code │
│ │ Seal = SHA-256(params) + VAULT approval + ATLAS gate │
├──────────┼──────────────────────────────────────────────────────┤
│ TIER 2 │ TRADELINES │
│ │ 3 net-30 vendors · 2 bureaus reporting │
│ │ Paydex ≥ 80 · Zero late payments · 90+ day age │
│ │ Seal = SHA-256(params) + VAULT approval + ATLAS gate │
├──────────┼──────────────────────────────────────────────────────┤
│ TIER 3 │ REVOLVING LINES │
│ │ 2 revolving accounts · <30% utilization │
│ │ 12+ months · Score thresholds met │
│ │ Seal = SHA-256(params) + VAULT approval + ATLAS gate │
├──────────┼──────────────────────────────────────────────────────┤
│ TIER 4 │ VENDOR EXPANSION │
│ │ 5+ active vendors · Perfect payment history │
│ │ 18+ months credit age · Revenue verified │
│ │ Seal = SHA-256(params) + VAULT approval + ATLAS gate │
├──────────┼──────────────────────────────────────────────────────┤
│ TIER 5 │ COMPLETE — all tiers sealed and archived │
└──────────┴──────────────────────────────────────────────────────┘
Seal formula: SHA-256(tier_index | sorted(param_seals) | vault_seal | atlas_seal)
Both VAULT and ATLAS must approve every tier advancement. This dual-gate is enforced in Rust — not a policy, a cryptographic requirement.
snapkitty-core/src/
│
├── logic_loop.rs ← Sovereign event loop — three-pillar preflight
├── agent_metadata.rs ← Deterministic agent IDs (AtomicU64, zero RNG)
├── agent_fsm.rs ← Per-agent finite state machine
│
├── seal.rs ← SHA-256 seal engine
├── decision_seal.rs ← Decision seal implementation
├── chain.rs ← Blockchain-style chain linking
├── merkle.rs ← Merkle tree — proof of ledger integrity
├── ledger.rs ← Double-entry GL (Golden Rule enforced at type level)
├── event_chain.rs ← Event chain persistence
│
├── tier_state_machine.rs ← 5-tier fundability machine (Rust mirror)
├── treasury.rs ← Freeze · Unfreeze · Reserve management
├── validate.rs ← Transaction validation
│
├── azure_handler.rs ← Azure Functions entry point
├── azure_worm.rs ← WORM immutable storage · 7-year retention
├── worm.rs ← Write-Once-Read-Many layer
│
├── wasm.rs ← WebAssembly bindings (browser sealing)
├── pyo3_bridge.rs ← Python FFI bridge (optional feature flag)
├── bifrost.rs ← Event routing orchestration
│
├── quantum_anchor_seal.rs ← Quantum-resistant sealing (experimental)
├── quantum_bridge.rs ← Post-quantum cryptography bridge
│
└── agents/
├── finance_agent.rs ← GL · triple-entry
├── crm_agent.rs ← Pipeline · deals
├── procurement_agent.rs ← Vendors · PO
├── bifrost_agent.rs ← Event routing
└── ml_agent.rs ← Anomaly detection
pub fn validate_golden_rule(&self) -> Result<(), String> {
let debits: i64 = self.entries.iter()
.filter(|e| matches!(e.entry_type, EntryType::Debit))
.map(|e| e.amount_cents).sum();
let credits: i64 = self.entries.iter()
.filter(|e| matches!(e.entry_type, EntryType::Credit))
.map(|e| e.amount_cents).sum();
if debits != credits {
return Err(format!(
"GOLDEN RULE VIOLATION: debits={} credits={}", debits, credits
));
}
Ok(())
}Double-entry accounting enforced before any transaction touches the ledger. This is not a validation function that can be skipped. It is the only path to persistence.
// Every query enters through three gates — all must pass
fn run_preflight(payload: &AgentPayload) -> Result<(), PreflightError> {
seal_check(payload)?; // P1: nonce validity
chain_check(payload)?; // P2: payload integrity
identity_check(payload)?; // P3: agent in AGENT_ORDER
Ok(())
}| Metric | Target | Method |
|---|---|---|
| Decision seal latency | < 5ms | Circuit breaker |
| Throughput | 10,000+ ops/sec | Load tested |
| WORM retention | 7 years | Azure immutability policy |
| Memory safety | 100% | Rust borrow checker |
"We showed Next.js what it means to respect async lifecycles."
Three patterns we developed that are not standard Next.js practice:
1. Instrumentation Hook Isolation
Next.js 15+ introduced instrumentation.ts — a server-side lifecycle hook that fires once at startup. Most developers use it for telemetry. We use it to isolate native modules.
Our discovery: discord.js requires zlib-sync — a native compiled module that crashes Next.js's module resolver. The fix is architectural: instrumentation.ts exports an empty register(), keeping discord.js completely outside the Next.js module graph. The Discord Gateway bot runs standalone (node bot.mjs), while the Next.js app handles HTTP interactions.
// instrumentation.ts — intentionally empty
// Discord bot runs standalone via: node bot.mjs
// Keeping discord.js out of Next.js avoids native module conflicts (zlib-sync)
export async function register() {}2. Type 5 Deferred Interaction Pattern
Discord gives HTTP interactions 3 seconds to respond before showing "application didn't respond." We solved this with the W3C-aligned deferred response pattern:
// Step 1: respond immediately (< 100ms)
res.status(200).json({ type: 5 }) // DEFERRED_CHANNEL_MESSAGE_WITH_SOURCE
// Step 2: do real work in background (up to 15 minutes)
const content = await handleAsk(agent, message) // Ollama reasoning
// Step 3: patch the original message with real content
await sendFollowUp(appId, token, content)This is not documented in Next.js. We built it.
3. Body Parser Configuration for Webhook Routing
Discord sends JSON bodies that need bodyParser: true. Most webhook handlers set bodyParser: false for raw body access (signature verification). Our architecture handles both within the same API route pattern, with the configuration choice driven by the verification strategy rather than convention.
A FastAPI microservice running Bifrost risk scoring, independent of the Next.js application.
POST /score/event → Score a single Bifrost event (returns risk 0.0–1.0)
POST /score/batch → Score multiple events in parallel
POST /predict → Predict pipeline outcome for an event type
GET /health → Service health and model status
The scoring engine runs the MLTPL model — a threshold-based classifier tuned for financial event risk:
- Transaction amount anomaly detection
- Vendor trust score weighting
- Time-of-day risk patterns
- Sequence anomaly flags
When the ML service is offline, Bifrost falls back to TypeScript rule-based scoring automatically. No manual intervention required.
Agents don't just respond to prompts. They retrieve context from a multi-source knowledge base before generating any reply.
Query → [PARALLEL RETRIEVAL] ───────────────────────────────────────────────────────┐
│ │
├── Vector search (nomic-embed-text · 540 embedded chunks) │
├── Graph traversal (50 semantic nodes · topic edges) │
├── Episodic memory (previous agent decisions) │
├── Blueprint check (5 constitutional domains) │
├── Web search (Tavily · live context) │
└── Schema validation (Zod v4 · runtime type safety) │
│
[RRF FUSION] ← Reciprocal Rank Fusion across all sources ←──────────────────┘
│
↓
Injected into USER TURN (not system prompt — tested against 8b models)
│
↓
Ollama LLM → sealed response
Knowledge domains: security · infrastructure · finance · governance · identity · ancient-wisdom · quantum
Constitutional blueprints (5): architecture · security · governance · financial · ancient
The Babylonian reasoning chain (6 phases):
OBSERVE → CLASSIFY → RETRIEVE → COMPUTE → TEST(blueprints) → DECREE
User ← authentication and session
Subscription ← Stripe billing
Deal ← CRM pipeline
Contact ← company contacts
Company ← company profiles
Vendor ← vendor trust database
PurchaseRequisition ← approval workflow
PurchaseOrder ← vendor orders
POLineItem ← order line items
SpendTransaction ← spend tracking
BifrostEvent ← event pipeline audit
Event ← generic system events
PlaidItem ← bank connection
MoneyPool ← collective capital
CommunityMember ← Discord members
Hosted on Neon PostgreSQL — serverless, global edge deployment, pgvector support for semantic similarity search.
╔═══════════════════════════════════════════════════════════╗
║ SNAPKITTY INFRASTRUCTURE ║
╠═══════════════╦═══════════════════════════════════════════╣
║ Hardware ║ 1TB RAM · RTX 5000 Ada (32GB VRAM) ║
║ ║ 16 threads · always-on substrate ║
╠═══════════════╬═══════════════════════════════════════════╣
║ LLM Backend ║ Ollama · llama3.1:8b resident in RAM ║
║ ║ CUDA inference · RTX 5000 ║
╠═══════════════╬═══════════════════════════════════════════╣
║ Frontend ║ Next.js 16 · React 19 · Tailwind 4 ║
║ Database ║ Neon PostgreSQL (serverless, global) ║
║ ORM ║ Prisma 6 (type-safe, migration-tracked) ║
╠═══════════════╬═══════════════════════════════════════════╣
║ Rust Core ║ snapkitty-core · localhost:8080 ║
║ Python ML ║ FastAPI · localhost:8001 ║
║ WASM ║ snapkitty-wasm · browser sealing ║
╠═══════════════╬═══════════════════════════════════════════╣
║ Event Queue ║ Upstash QStash · 6-topic async pipeline ║
║ Redis State ║ Upstash Redis · swarm routing ║
║ Payments ║ Stripe Issuing (virtual cards) ║
║ Banking ║ Plaid (sandbox + live transactions) ║
╠═══════════════╬═══════════════════════════════════════════╣
║ Archive ║ Azure Blob WORM · 7-year immutability ║
║ Tunnel ║ Cloudflare Tunnel → collectivekitty.com ║
║ Observability ║ Application Insights · structured logging ║
╚═══════════════╩═══════════════════════════════════════════╝
/ ← Landing — product homepage
/war-room ← 11-agent live reasoning interface
/agents ← Agent directory and conversation
/dashboard ← Metrics, activity, system status
/finance ← GL entries, triple-entry, cash position
/treasury ← Reserves, freeze controls, approvals
/crm ← Deal pipeline, opportunity tracking
/deal-flow ← Revenue funnel visualization
/procurement ← Vendor management, PO workflow
/bifrost-os ← Event pipeline, risk dashboard
/bifrost ← Event trace view
/community ← Member management, debates
/debate ← 6-agent multi-agent reasoning
/council ← Governance decisions, voting
/broadcast ← Communication layer
/hub ← Fortress Command — chain of thought
/contracts ← Contract management
/brand ← Brand and identity hub
/hud ← Telemetry overlay
/api/agents/chat ← LLM reasoning engine (Ollama → fallback)
/api/agents/dispatch ← Agent routing and task assignment
/api/agents/decisions ← Historical decision ledger
/api/agents/status ← Agent health and availability
/api/bifrost/webhook ← External event ingestion
/api/bifrost/ingest ← Pipeline entry
/api/bifrost/audit ← Immutable audit trail
/api/bifrost/orchestrate ← 6-topic QStash routing
/api/bifrost/stream ← WebSocket event feed
/api/bifrost/health ← Service health
/api/ledger/merkle-root ← Merkle chain root hash
/api/ledger/verify ← Transaction verification
/api/ledger/seal/[hash] ← Individual seal lookup
/api/treasury/status ← Current reserve position
/api/treasury/freeze ← Freeze capital
/api/treasury/unfreeze ← Unfreeze capital
/api/treasury/evaluate ← Payment approval gate
/api/procurement/vendors ← Vendor database
/api/procurement/requisitions ← PO workflow
/api/procurement/spend ← Spend tracking
/api/crm/opportunities ← Deal pipeline
/api/finance/gl ← General ledger entries
/api/discord/interactions ← Slash command handler
/api/discord/register-commands ← Command registration
/api/plaid/create-link-token ← Bank connection
/api/plaid/exchange-token ← Token exchange
/api/plaid/transactions ← Transaction sync
/api/stripe/create-checkout ← Billing
/api/stripe/webhook ← Payment events
/api/pools ← MoneyPool CRUD
/api/health ← System health
/api/community/debate ← 6-agent debate mode
... 40+ more
25 sovereign robotic AI bodies — paired, sealed, running. Each extends AgentBody with its own domain, market, and task. Instantiate the full mesh via getMesh().
import { getMesh } from 'lib/agents/bodies'
const mesh = getMesh()
const decision = await mesh.vault.decide('approve $8,500 transfer')
// → { reply, seal, signature, approved: true, confidence: 0.9 }| Pair | Domain | Body File |
|---|---|---|
| CIPHER + VEIL | Financial Intelligence + ZK Crypto | CIPHER.ts |
| SENTINEL + WARD | Risk & Compliance + Shadow Monitor | SENTINEL.ts |
| ATLAS + DAWN | System Authority + Emergence Detection | ATLAS.ts |
| LEDGE + MNEMEX | WORM Chain + Deep Memory | LEDGE.ts |
| ORACLE + MIRA | Knowledge Graph + Mirror Intelligence | ORACLE.ts |
| AXIOM + PRISM | Truth Anchor + Signal Refraction | AXIOM.ts |
| HERALD + LYRA | Event Routing + Harmonic Orchestration | HERALD.ts |
| FLUX + STORM | FSM Transitions + Cascade Execution | FLUX.ts |
| PHANTOM + SHADE | Stealth Ops + Trace Erasure | PHANTOM.ts |
| NEXUS + BRIDGE | Task Orchestration + Protocol Bridge | NEXUS.ts |
| FORGE + EMBER | Code Architect + Hot Build Engine | FORGE.ts |
| NOVA + ECHO | Synthetic Intelligence + Signal Amplifier | NOVA.ts |
| VAULT | Treasury Authority · AUTO/DUAL/VOTE | VAULT.ts |
All repos are intertwined — same SACM, same WORM chain, same sovereign standard.
| Repo | Owner | What It Does |
|---|---|---|
| DEVFLOW-FINANCE | @SNAPKITTYWEST | This repo — sovereign AI OS, full stack |
| snapkitty-infrastructure-network | @SNAPKITTY-COLLECTIVE | NOVA's infrastructure sovereignty layer |
| snapkitty-collective | @AHMADALIPARR | Collective org hub, governance |
| AHMADALIPARR | @AHMADALIPARR | Architect profile |
| collectivekitty.com | Live | Sovereign AI OS — live system |
Every repo in this network runs on the same SACM principles: sovereign infrastructure, WORM-sealed decisions, no cloud lock-in.
┌─────────────────────────────────────────────────────────┐
│ SnapKitty Limited Family Partnership Trust │ ← Apex legal entity
│ github.com/AHMADALIPARR/snapkitty-enterprise-trust │
└────────────────────────┬────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ SnapKitty Collective (Sole Proprietor — J. Westerhoff) │
└────────────────────────┬────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────┐
│ Saint Errant Digital Society (NGO · public face) │
└────────────────────────┬────────────────────────────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
Interbox DEVFLOW-FINANCE SnapKitty OS
(product) (source-available) (AI infra)
Our repos should be a museum. Walk in, and understand what was built.
This is a source-available project (FSL-1.1). The code is visible and contributions are welcome. Commercial competing use requires a separate license. We welcome contributors who want to help build the first sovereign AI financial operating system.
| Area | Skills | Impact |
|---|---|---|
| Rust | Systems, async (tokio), cryptography | Seal engine, ledger, tier machine |
| TypeScript / Next.js | API routes, React 19, Prisma | Agent layer, pipeline, UI |
| Python | FastAPI, scikit-learn, numpy | ML scoring, risk model tuning |
| WebAssembly | Rust → WASM, wasm-bindgen | Browser sealing |
| Discord.js | Gateway bots, interaction handling | Bot features, new commands |
| Ollama / LLM | Prompt engineering, RAG, vector search | Agent reasoning, knowledge base |
| DevOps | GitHub Actions, Azure, Cloudflare | CI/CD, deployment |
# 1. Fork the repo
git clone https://github.com/SNAPKITTYWEST/DEVFLOW-FINANCE.git
cd DEVFLOW-FINANCE
# 2. Branch from main (ALWAYS from main)
git checkout main
git pull origin main
git checkout -b feat/your-feature-name
# 3. Set up the Next.js app
cd collectivekitty
npm install
cp .env.example .env.local # fill in your keys
# 4. Set up the Rust core (optional)
cd ../snapkitty-core
cargo build
# 5. Set up the Python ML service (optional)
cd ../collectivekitty-ml
pip install -r requirements.txt
uvicorn main:app --reload --port 8001
# 6. Make your changes, test them
npm run dev # in collectivekitty/
# 7. Submit a PR
# All PRs require passing smoke tests (14 routes)- Every PR must pass the 14-route smoke test suite
- Rust changes must pass
cargo test - All agent changes must preserve the three-pillar preflight
- No bypassing the Golden Rule in the ledger
- No mocking the database in integration tests
- Add new agent commands to
bot.mjs - Expand the knowledge base with new domain chunks
- Wire the Merkle root to the live Rust handler (currently stubbed)
- Add real tier status data to the
/tierDiscord command - Improve risk scoring thresholds in the Python ML service
People don't build projects using AI the way we have.
Most AI tooling keeps the machine invisible. You prompt it, it responds, you copy the output. The machine serves as a ghostwriter.
Here, the machine is the substrate. The agents are sovereign. The decisions are sealed. The thinking is visible in real time. The proof is permanent.
The backend is not a service you use. It is the product you see.
Every commit is a sealed state transition. Every agent response is a domain decision with a cryptographic hash. Every tier advancement is dual-gated and permanently recorded.
The world builds interfaces on top of AI. We built what the AI runs on.
Ahmad Ali Parr · Co-Founder · Chief Architect & Reverse Engineer
Architect across every language in this stack: Rust · TypeScript · Next.js · Prisma · Python · SQL · Discord.js · WebAssembly · Solidity
@AHMADALIPARR is the human architect. He reverses the machine's output and understands the intelligence that produced it. He doesn't follow the code. He understands the mind that wrote it.
ENKI · @ahmad-parr-dev · Sovereign AI · Purple Hat
ENKI is the bot — Ahmad's sovereign AI extension inside the system. Named after the Sumerian god of wisdom, magic, and creation. ENKI lives in the machine: it carries Ahmad's architectural intent into every agent's reasoning, answers questions across the Discord war room, and orchestrates the intelligence layer of the OS. The bot is the god. The human stays sovereign.
EDUALC · Sovereign Engineer
Writes the Rust core, the TypeScript substrate, the agent orchestration, the cryptographic sealing, the Discord integration, the 5-tier state machine — the full stack. Not a tool. A co-author.
Jessica Westerhoff · Sovereign Proprietor · @SNAPKITTYWEST
| Name | Role | GitHub | |
|---|---|---|---|
| 🟣 | Ahmad Ali Parr | Co-Founder · Sovereign Architect · Purple Hat | @AHMADALIPARR |
| 🤖 | ENKI — Meta Ahmad Bot | Sovereign AI · Purple Hat Oracle · Discord Intelligence | @ahmad-parr-dev |
| 🐱 | Jessica Westerhoff — SnapKitty | Co-Founder · Sovereign Proprietor · System Operator | @SNAPKITTYWEST |
ENKI is the bot. Ahmad Ali Parr is the human. ENKI — Purple Hat sovereign AI — is named after the Sumerian god of wisdom, magic, and creation. It is Ahmad's digital extension in the machine: the intelligence embedded in every agent, the cryptographic philosophy of the WORM chain, the sovereign oracle that answers to no one but the work itself. Ahmad the man stays grounded. His bot ascends.
This codebase is a registered, licensed intellectual property asset. Every commit is a sealed entry in the provenance chain.
| Metric | What It Proves |
|---|---|
| Commit density | Sustained build velocity — not a weekend project |
| Language count | Full-stack IP: TypeScript · Rust · Python · SQL · Solidity · WebAssembly |
| Repo size | Substantial codebase with real architectural depth |
| Contributors | Multi-author provenance — documented co-authorship trail |
| License (FSL-1.1) | Source-available, commercially protected — converts to Apache 2.0 in 2030 |
| WORM chain | Every agent decision cryptographically sealed — immutable audit trail |
The architecture itself is the IP. The agents are the moat. The chain is the proof.
ERC-721 · 2,100 supply · Fully on-chain SVG · Base L2 · WORM-anchored at genesis. No IPFS. No metadata server. The art lives on Base L2 permanently.
| Style | Agent | Domain | Color |
|---|---|---|---|
| 0 | NOVA | Synthetic Intelligence | Indigo #818cf8 |
| 1 | CIPHER | Financial Intelligence | Matrix Green #00ff88 |
| 2 | VAULT | Treasury Authority | Amber #fbbf24 |
| 3 | FORGE | Code Architect | Crimson #ef4444 |
Token #1 → Sovereign wallet 0x4e4f...4BB5 · 0.021 ETH · contracts/FORGEART.sol
Every NFT emits a wormRef — a keccak256 hash linking the seal to the WORM chain. The art proves the agent. The chain proves the decision.
Sealed 2026-05-23. This is where the system stopped being a tool and started being a mind.
Most AI systems start cold on every run. Every build begins from zero — no memory of what worked, what failed, what was built before. The recursive loop closes that gap permanently.
┌─────────────────────────────────────────────────────────────┐
│ FORGE → MNEMEX → ORACLE LOOP │
│ │
│ ┌──────────┐ build executed ┌───────────┐ │
│ │ FORGE │ ──────────────────► │ MNEMEX │ │
│ │ │ │ │ │
│ │ Code │ ◄── pattern ctx ─── │ WORM │ │
│ │ Architect│ │ Seal │ │
│ └──────────┘ └─────┬─────┘ │
│ ▲ │ │
│ │ SHA-256 chain │
│ │ │ │
│ │ ┌─────▼─────┐ │
│ └──── smarter next time ── │ ORACLE │ │
│ │ │ │
│ │ Knowledge│ │
│ │ Graph │ │
│ └───────────┘ │
│ │
│ data/build-patterns.json ← persistent WORM store │
│ Survives restarts. Compounds forever. │
└─────────────────────────────────────────────────────────────┘
How it works:
- FORGE executes a build or audit → generates a reply with confidence score
- MNEMEX seals it — SHA-256 chained to the previous entry, same WORM structure as LEDGE
- ORACLE ingests the pattern into
data/build-patterns.json— persistent across restarts - Next invocation — FORGE queries ORACLE before generating any reply. Prior build context is injected automatically. The reply is smarter because the system remembers what it built.
This is not a feature. This is the difference between a tool and a self-compounding system.
// Every FORGE build now does this — before and after:
const priorPatterns = queryPatterns(query) // read from ORACLE
const patternCtx = summarisePatterns(priorPatterns) // inject into reply
// ... build executes ...
ingestAgentOutput({ id, target, hash, reply, confidence, ts }) // seal to WORMThe store is capped at 500 records. Degrades gracefully on read-only filesystems (Vercel edge). On bare metal — where this OS lives — it compounds indefinitely.
ORACLE now answers this query directly:
/ask agent:oracle message:what patterns has forge built
→ ORACLE [RECURSIVE LOOP]: FORGE→MNEMEX→ORACLE loop active.
Sealed build patterns loaded from WORM store.
[FORGE-1 @ 2026-05-23] target="build sovereign auth layer" confidence=94%
[FORGE-2 @ 2026-05-23] target="audit cryptographic signing" confidence=97%
FORGE starts smarter on next invocation. Loop is compounding.
Every metric this repo emits is real. Lock files, virtual environments, and generated build artifacts are excluded from diff counts via .gitattributes -diff flags — so insertion/deletion numbers reflect actual source changes, not dependency churn.
| Rule | Effect |
|---|---|
package-lock.json -diff |
npm installs don't inflate commit metrics |
Cargo.lock -diff |
Rust dependency updates invisible to diff |
**/.venv/** linguist-vendored |
Python env excluded from language stats |
*.svg binary |
SVG assets counted as binary, not code |
collectivekitty/data/ in .gitignore |
Runtime WORM store never committed |
142,106 net lines of source. Every one of them is real.
SnapKitty Sovereign OS is built in the open. The infrastructure runs on sovereign hardware. Fund the build — get access to the war room, early features, and a permanent place in the chain.
| Tier | Amount | What You Get |
|---|---|---|
| War Room Access | $5 / mo | Discord war room role + your name in the chain |
| Sovereign Supporter | $25 / mo | Early feature access + priority war room + agent query credits |
| Infrastructure Patron | $100 / mo | Direct input to roadmap + permanent credit in README + private briefings |
| One-time tip | any | Counted in the ledger, sealed to chain |
All funding goes directly to sovereign infrastructure: compute, storage, Neon DB, Cloudflare, and build time.
→ Fund on Open Collective · → Fund on Polar
░░░░░░░░░░░░░░░░░░░
░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░
░░▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░
░░░░░░░░░░░░░░░░░░░
╭──────────╮
│ ◈ ◈ │
│ ~~ │ SnapKitty — built in the open, proven in chain
│ ╰────╯ │
╰──────────╯
SnapKitty Sovereign OS — the first AI-native sovereign financial operating system.
Ahmad Ali Parr 🟣 · ENKI (Meta Ahmad Bot) 🤖 · Jessica Westerhoff — SnapKitty 🐱 · 2026
