Note
This repository publishes the architecture of a system running in production. It is a specification, not a deployable copy. The calibration is deliberately withheld — no thresholds, confidence cut-offs, guard patterns, classifier prompts or schedules — because documentation of a detector is a manual for evading it. Identifiers are placeholdered.
Axiom reads a live Discord gateway, classifies what it sees across text and images, and acts. Plenty of bots do that. Two things separate this one, and neither is the classifier.
Most people who dislike moderation bots do not dislike moderation. They dislike being flagged for a word. In a technical community that failure is near-guaranteed, because the vocabulary of solicitation is also the vocabulary of ordinary shop talk. "The API costs about the same as hosting it" is not an advertisement. "We moved off WhatsApp for support" is not a funnel. A keyword filter cannot tell the difference, so it punishes the conversation the community exists to have. Axiom carries a suite of named, individually-engineered guards whose only purpose is declining to act:
| Guard | What it protects |
|---|---|
| Technical-context guard | security and pentest vocabulary is not adult content |
| Reported-speech guard | quoting abuse in order to report it is not abuse |
| Hiring guard | a job post is not an advertisement |
| Free-software guard | sharing something free is not promotion |
| Exemption gate | declared exemptions are honoured |
| Deterministic guards | a whole non-AI layer dedicated to this alone |
| First-flag confidence floor | a first offence requires higher confidence than a repeat |
| Low-confidence nudge | uncertainty produces a private nudge, never a punishment |
| Escalation requires co-occurrence, never presence. A contact-channel mention alone | |
| does nothing; a contact-channel mention together with selling intent resolves | |
| immediately. Same vocabulary, different structure — and the structure is the signal. | |
| The reported-speech distinction is one that human moderation teams routinely get | |
| wrong. See FALSE-POSITIVES. |
- Bounded enforcement for three solicitation species in the general channel — recruiting-with-DM-funnel, off-platform commercial adverts, and begging — via a three-rung ladder that never bans (ENFORCEMENT-LADDER). Everything else stays escalate-only.
- A queue that tells you when it is stuck. Approved wipes run through an evidence-locker-first queue with a lease lock and an age tripwire that notifies the operator once per stall (OPERATIONS).
- A weekly dry replay that re-runs the deterministic detectors over the week's un-actioned messages and reports what would fire — so a detector silenced by a downstream guard cannot stay silent for long.
| Layer | Survives | |
|---|---|---|
| 1 | model ensemble — several text models, two independent vision models | normal operation |
| 2 | configurable fallback models | a primary being unavailable |
| 3 | deterministic backstop, no AI at all | total inference outage |
| 4 | retry queue on separate hardware | gaps left while the above were down |
| Layer 3 means coverage degrades instead of disappearing. Layer 4 exists because a | ||
| worker-side retry cannot run when the worker is the thing that is broken. | ||
| Both were built in response to measured failures, and both failures are published in | ||
| full in FAILURE-MODES — including the outage that left ten | ||
| messages permanently unjudged, and the health check that made a dead process invisible | ||
| for 112 restarts. Those two documents are the ones worth your time. |
moderation engine resident Discord gateway + scheduled worker + two databases
research gateway authenticated per-consumer research API over a corpus store
security scanner read-only web-security audit, invoked from chat
The gateway listener runs as a resident process on operator hardware, because a Worker cannot hold a resumable websocket across cold starts. Its own description of itself:
The brain does all judgment; this feeder is dumb plumbing. Auto-reconnect, resume, backoff. Never acts, never stores.
| Document | |
|---|---|
| FALSE-POSITIVES — the guard suite, and why single-signal matching fails | |
| FAILURE-MODES — two real failures, published in full | |
| ENFORCEMENT-LADDER — the one documented exception to escalate-only | |
| OPERATIONS — the scheduled tick, the wipe queue, and its self-checks | |
| ARCHITECTURE — components, data flow, the two-database split | |
| PIPELINE — harvest, judge, evidence, act — and backfill | |
| CLASSIFICATION — the ensemble and the verdict taxonomy | |
| THREAT-MODEL — scope, non-scope, acknowledged trade-offs | |
| TRUST-TIERS — authority derived from Discord permission bits | |
| COMMANDS — the command surface by required tier | |
| CONFIGURATION — operator-tunable behaviour | |
| GOVERNANCE — dated, attributed, forward-only policy changes | |
| PRIVACY — what is retained, and who can reach it | |
| SCANNER — the companion security scanner | |
| RESEARCH-GATEWAY — the corpus and research API |
This is a technical specification, not a deployable implementation — and for a detector that is a security requirement rather than a convenience. Documentation of a detector is a manual for evading it. So this repository publishes the architecture and withholds the calibration: no thresholds, limits, confidence floors, windows, model identifiers, guard patterns, prompts or scheduled cadences. No real identifiers of any kind. Every example is synthetic. You can judge exactly how it is built and why it works. You cannot derive what you would need to slip past it.
Dated, mechanism-level entries for every behaviour change — see CHANGELOG.
See LICENSE.