Governance

Consent ledger with 2,562-day FCA-aligned retention, programmable policy engine, 9 kill switches, hash-chained audit trails, and board-reportable incident governance.

What is it?

Governance (COS-006) is Warburton's system for recording not just what happened, but why it happened, who authorised it, and what policy applied. It provides a consent ledger, programmable policy engine, kill switches for immediate subsystem disablement, hash-chained audit trails, and incident-level governance views.

Computers forget why they made decisions. That seemed unwise.

Why does it exist?

AI systems making decisions that affect real people need governance structures that can withstand scrutiny. When a regulator asks "why did your system take this action?", the answer needs to be precise, documented, and tamper-evident — not a best guess reconstructed from log files.

Warburton's governance layer exists because community management at scale creates the same accountability requirements as financial services, healthcare, and other regulated industries. The fact that most community platforms ignore this doesn't mean the requirement doesn't exist.

Why is it different?

Most community platforms have no governance layer at all. They log events but not decisions. They record actions but not policies. They can tell you what happened but not why, and they certainly can't prove the record hasn't been altered after the fact.

Warburton's governance is built to a financial services standard. The consent ledger uses FCA-aligned retention periods. The audit trails are hash-chained — each record cryptographically linked to its predecessor, making tampering detectable. The incident views are designed to be board-reportable without translation or reformatting.

How does it work?

• Consent ledger: Every consent event is recorded with a timestamp and retained for 2,562 days, aligned with FCA regulatory requirements. Consent records are immutable once created.
• Programmable policy engine: Community policies are defined in configuration, not buried in code comments. The policy engine evaluates incoming events against defined rules and produces deterministic outcomes. Policies can be updated, versioned, and audited.
• 9 kill switches: Each kill switch disables a specific subsystem immediately. No ambiguity. No delay. No need to deploy code or restart services. Kill switches provide operators with emergency control over every aspect of the system.
• Hash-chained audit trails: Every audit record is cryptographically chained to its predecessor. If any record in the chain is altered, the chain breaks and the tampering is detectable. This provides tamper-evident record-keeping suitable for regulatory inspection. The audit logging function never throws — it retries without the caller's transaction on failure, ensuring audit records are never silently lost.
• Incident governance: Each incident generates three views — PostMortem (what happened and why), Timeline (chronological event sequence), and Operations (system behaviour and decision chains). These views are structured for direct board reporting without manual summarisation.

AI Attack Surface Audit

Governance includes a comprehensive AI attack surface audit covering six categories — tool misuse, permission boundaries, memory poisoning, workflow manipulation, cross-session persistence, and data exfiltration. Each surface is audited, mitigated, and documented with residual risks explicitly recorded and severity-rated.

• Permission boundaries: Every privileged action (blocklist bans, role assignment, federation operations) is gated with caller authorisation. Discord blocklist buttons check both bot-level admin status and platform-level ModerateMembers permission — unauthorised users receive ephemeral rejection messages.
• Tenant isolation: All data paths are scoped by tenant — memory queries, learned cache responses, and audit records are isolated per-deployment. Cross-tenant data leakage is prevented by tenant-context wrappers applied consistently across all three platform adapters.
• Data exfiltration prevention: Memory scoping is per-user and per-tenant. Learned cache replies are sanitised (usernames stripped). Web fetch is allowlist-only with SSRF defences. The dashboard is tenant-scoped with CSRF protection.
• Residual risk documentation: Accepted residual risks are documented with severity ratings and mitigation context — not hidden, not ignored. This includes known limitations of the injection detection system (does not cover encoded forms or non-English imperatives) and race conditions in rate limiting (low practical risk, documented).

Example

Why should anyone care?

If you operate an AI system that makes decisions about people, you are already subject to governance requirements — whether you've built the governance infrastructure or not. Warburton provides that infrastructure as part of the platform, not as an afterthought. When the audit comes — and it will — the records are there, they're complete, and they're tamper-evident.