Surface 02 · CanaryRAG
Inject a trap fact
A trap fact is a plausible, fictional detail woven into your document — a budget figure, a codename, a date. Humans skim past it, but a model that ingested your content reproduces it, even paraphrased. When it surfaces in a completion, that's proof of ingestion.
Feed any assistant's output you can query to the monitor; when a trap fact comes back above a confidence of 75, the hit is recorded and you are alerted over Telegram and email, with the canary id, the matched fact and the document it was planted in.
A trigger is not sealed. It is an ordinary row holding the confidence, the matched fact and a 500-character snippet of the output — it carries no content hash, and the public verifier has nothing to resolve for it. CanaryVaults tripwires, CanaryHoneypot hits and CanaryAudit records are what reach the hash-sealed evidence log; a trap-fact trigger lives in its own table and does not. If you need an evidenced record of a leak, write one yourself through CanaryAudit.
Documents, checks, and the daily and per-minute allowances
Two metrics meter CanaryRAG, each of them at more than one horizon. rag_documents is a total — how many trap documents may exist on the account at once — and it is 2 on Free, 25 on Shield, 200 on Pro and 500 on Enterprise. rag_checks_per_month is a monthly meter, spent by every /canaryrag/monitor call: 10 on Free, 500 on Shield, 2,000 on Pro and 6,000 on Enterprise. Either one answers a structured 402 naming the metric, your plan and your reset date.
Underneath the monthly quota sits a shorter per-account daily allowance, and it is the one you are likely to meet first. Monitor checks are capped at 5 a day on Free, 40 on Shield, 100 on Pro and 300 on Enterprise; injections at 2 a day on Free, 5 on Shield, 20 on Pro and 50 on Enterprise. You can hit either while the monthly quota still has plenty left — 100 checks a day on Pro reaches the 2,000 monthly figure only across 20 days — so a backfill that would fit comfortably inside a month can still be refused this afternoon. The daily 402 names the same metric, with resets_at set to the next UTC day rather than the first of next month.
The daily meter is the one thing here that fails closed. If your usage cannot be checked the call answers 503 with daily_quota_unavailable rather than running unchecked — retry shortly, and read it as not run rather than as refused.
Above both sits a per-minute burst limit, again per metric and per plan: monitor checks allow 10 a minute on Free, 60 on Shield, 240 on Pro and 600 on Enterprise, and injections 2, 5, 20 and 50. Crossing it answers 429 with retry_after_seconds and a Retry-After header rather than a 402 — the burst check runs before either meter, so a request it turns away has spent no quota and needs no refund. Which of the two you meet depends on the metric: for monitor checks the daily allowance is the smaller number on every plan, so the day runs out inside a single minute of full-rate calling, while for injections the per-minute and daily figures are identical on every plan, so a burst is turned away by the 429 first and the daily 402 only arrives once the minute has rolled over.