Architecture

Warburton is structured in three workstreams — WS1 Platform Core, WS2 Community Operating System, and WS3 Operations and Governance — deployed as a single platform with 4,183 passing tests.

What is it?

Warburton's architecture is organised into three workstreams that together form the complete Community Operating System. WS1 handles the platform foundation — how Warburton connects to Telegram and Discord, processes messages, and generates responses in character. WS2 contains the nine capability areas that make up the Community Operating System. WS3 provides the operational infrastructure and governance layer that ensures everything is monitored, auditable, and controllable.

Not a chatbot with guardrails. Not a moderation bot with a personality. An operating system for the entire lifecycle of community management.

Why does it exist?

Most community tools are point solutions — a moderation bot here, an analytics dashboard there, a separate knowledge base somewhere else. These tools don't talk to each other, don't share context, and create gaps where community problems grow undetected.

Warburton's architecture exists because community management is a systems problem, not a features problem. The nine capability areas need to share context, feed into each other, and operate under a unified governance framework. A pile-on detected by Protection Protocols needs to be visible in Community Health, reflected in the Daily Digest, and logged in the Governance audit trail — all automatically, all from the same event.

Why is it different?

The three-workstream architecture separates concerns cleanly while maintaining tight integration. WS1 handles the "how" — platform connectivity and response generation. WS2 handles the "what" — the nine capability areas that protect, monitor, and serve the community. WS3 handles the "prove it" — metrics, dashboards, audit trails, and governance. Each workstream can evolve independently, but they operate as a single deployment.

How does it work?

WS1 — Platform Core

WS1 is the foundation layer. It handles:

• Platform adapters: Telegram, Discord, and WhatsApp integration, handling the specific APIs, message formats, and interaction patterns of each platform. All three adapters wire through the same fixed-order safety pipeline, including edit handlers that close the edit-evasion attack vector.
• Character engine: The system that maintains Warburton's consistent authored voice across all interactions. The character is the interface — every community-facing message goes through the character engine.
• Message pipeline: Incoming messages are classified, routed through relevant capability modules, and responses are generated. The pipeline is the central nervous system that connects platform input to system output.
• Multi-model response generation: A tiered model architecture — local Ollama models handle most requests, with automatic fallback to Granite and escalation to Claude for complex queries. Deterministic safety rules are enforced at the system level (not the prompt level). Cross-model quality judging validates that safety constraints hold across different model behaviours.
• SSRF-protected fetch pipeline: All external fetches (URL paste, Reddit search, Wikipedia search) use manual redirect following with per-hop private-IP validation, DNS rebinding protection, and allowlist enforcement. Image fetches use a separate safe-fetch function with size caps.

WS2 — Community Operating System

WS2 contains the nine capability areas that form the COS:

• COS-001 — Community Health Monitoring: Temperature monitoring, silence detection, moderator burnout, exclusion patterns.
• COS-002 — Operational Assurance: Decision provenance, circuit-breaker alerting, Prometheus metrics.
• COS-003 — Protection Protocols: PP1 pile-on, PP2 absent-person, PP3 pattern-break — all deterministic.
• COS-004 — Knowledge Capture: Provenance-weighted cache, 71% cosine quality, quarterly promotion gates.
• COS-005 — Welfare Ladder: Per-user sentiment, multi-rung escalation, crisis-level human routing.
• COS-006 — Governance: Consent ledger, policy engine, kill switches, hash-chained audit.
• COS-007 — Daily Digest: Structured daily/weekly summary delivered to admin DMs.
• COS-008 — Deterministic Safety: Eight hard rules, no AI in the loop.
• COS-009 — Contributor Recognition: Federated threat intel, confidence scoring, promotion recommendations.

WS3 — Operations & Governance

WS3 provides the infrastructure that makes WS1 and WS2 accountable:

• Decision provenance: Every AI response is recorded with full routing provenance using a Context Accumulator Pattern — 12 fields per response including routing path, model used, retrieval sources, middleware intercepts, token counts, cost, and a decision-reason classification across 12 deterministic categories. See Operational Assurance for details.
• Prometheus metrics: Nineteen safety-trigger call sites across five moderation modules, plus operational telemetry across all subsystems, exposed as standard Prometheus metrics.
• Grafana dashboards: Real-time visualisation of system performance, decision volumes, escalation rates, and subsystem health.
• Circuit-breaker alerting: Automatic degradation and operator notification when system health thresholds are breached. Health checks cover Ollama, Claude, and Redis — not just the database.
• Consent ledger: 2,562-day FCA-aligned retention of all consent events.
• Hash-chained audit trails: Tamper-evident record-keeping where each audit entry is cryptographically linked to its predecessor.
• Kill switches: 9 kill switches for immediate subsystem disablement.
• AI attack surface audit: Six attack surfaces audited — tool misuse, permission boundaries, memory poisoning, workflow manipulation, cross-session persistence, and data exfiltration — with residual risks explicitly documented and severity-rated. See Governance for details.
• Incident governance: PostMortem, Timeline, and Operations views for every incident — board-reportable by design.

Why should anyone care?

The architecture is what makes Warburton a platform rather than a collection of features. The nine capability areas share context because they run on the same infrastructure. An event detected by one module is immediately available to every other module. The governance layer covers everything because it sits beneath everything. And the whole system is observable through standard monitoring tools — no black boxes, no trust-me-it-works.

4,183 passing tests. Every decision auditable. Every safety rule deterministic.