The seven engines CID222 runs over prompts and replies, what each one finds, which service it lives in, and where to read the detail.

Detection is CID222's own: models the product ships and a decision maker the product owns. Each model runs in its own container and is called over HTTP, so one can be scaled or replaced without touching the gateway. This page is the map; the security guide is the detail.

The problem

One detector is either too loud or too quiet. A regular expression misses a name it has never seen and fires on a number that merely looks like an identifier. A classifier cannot prove that a card number is real and cannot explain itself. And an attacker who knows one detector exists encodes around it. What is needed is several detectors reading one decoded text, a way to confirm or demote what each of them found, and a single rule for turning disagreement into one action.

How CID222 does it

Engine	What it finds	Where it runs	Service	Detail
Language detection	The language of the text, so every other detector gets a hint instead of guessing	Ahead of detection	`language-detector`	Detection pipeline
PII — patterns	Structured identifiers and secrets: e-mail, phone, card, national identity numbers, bank accounts, API keys, private keys	Request and response	In the gateway, from the filter rules	PII detection
PII — neural	Entities no pattern can catch: person names, organisations, locations, addresses	Request and response	`ml-detector`	PII detection
Toxicity	Thirteen harm labels including violence, hate, self-harm, sexual content, weapons and cyber crime	Request and response	`hap-guard-v2`	Detection pipeline
Attack guard — models	Prompt injection and jailbreak, scored independently so both can fire on one prompt	Request	`attack-guard`	Detection pipeline
Attack guard — scan	SQL injection and cross-site scripting, deterministically, with `libinjection`	Request	`attack-guard`	Detection pipeline
Code safety	Secrets and destructive commands by rule, plus one finding per reported software weakness from the auditor	Request, and coding-assistant tool calls	The auditor, on its own host	Code Safety
Hallucination	Whether a reply is supported by the context it was supposed to use	Response, in the background	`hallucination-guard`	Detection pipeline

Everything in the request column runs in parallel over the same normalised text, and nothing is sampled: a detector that runs, runs on every request. What can remove a detector is your own policy. Before the fan-out the gateway resolves a detector plan per tenant, and a detector family whose every filter resolves to allow for that tenant is not called at all — switching a family off removes the network call rather than discarding its answer. Code safety is the one family that is off unless it is enabled.

Before the detectors: normalisation

Evasion decoders run first — ROT13, base64, leetspeak, Unicode homoglyphs and case — so a detector reads what the text means rather than how it was disguised. The detection response reports which decoders fired.

After the detectors: one action

A validation layer confirms or demotes each finding — a checksum on a card or a national identity number, context rules on the rest — and the decision maker folds what survives into a single action. The strongest wins: reject beats mask, mask beats flag.

Beyond text

Images and documents are not a separate detection stack. Text is extracted first — optical character recognition for images, a parser for PDF and DOCX — and then the same engines run over the result, with a redaction service producing a cleaned copy of the file where the policy calls for one.

Beyond a single message

Repeated jailbreak and injection detections against one user fill a sliding window. Crossing it opens one review of that user by the local risk-analyst model, which reads the detection history rather than re-reading traffic. This is not a per-message job and adds nothing to the request path.

Limits and known gaps

Hallucination detection is background-only, and its scores are relative. It runs after the reply has been delivered, so it never blocks one. Its two checkpoints were trained for token-level classification and are loaded for sequence-level classification, carried over unchanged so that scores stay comparable with archived analyses. Treat the score as a ranking signal, not as a probability.
Hallucination routing ignores the detected language. The service routes by the language the caller declares, and the gateway currently always declares English, so Turkish replies are scored by the English model.
Code safety is off unless it is configured. The auditor is a separate service that is disabled by default (CODE_SAFETY_SERVICE_ENABLED) and licensed with Enterprise. A degraded or failed audit means unknown, never clean.
Language coverage is not uniform. Toxicity and attack scoring cover a fixed set of languages; the PII model is multilingual on one set of weights; the language detector recognises far more languages than the detectors behind it are trained for.
Every number is conditional. Latency and accuracy depend on text length, language, which detector fired and how the filter is configured. The performance and accuracy reference states the conditions; a bare percentage anywhere else is unverified.

Security and compliance — the entity catalogues, the label sets, the thresholds and the data handling.
The content safety pipeline — the order things happen in and how competing verdicts resolve.
Architecture — where the detection services sit relative to the gateway.

Detection engines at a glance