What it does
Someone forwards a message they are unsure about — just in case. DoubleCheck reads it and answers with one of a small set of plain sentences, together with the reasoning that produced the answer:
- “Nothing jumped out at me” — recorded as safe in the signed records below
- “Be careful with this one” — recorded as suspicious
- “I'd stay away from this one” — recorded as dangerous
- “I couldn't read this one” — recorded as unassessable, an abstention
That register is deliberate. A reply never carries capital-letter verdicts, alarm glyphs, or confidence percentages — it is a quiet sentence you could shrug off as “an assistant” if someone glanced at your screen. The level names above appear in the signed records and nowhere in a reply; the mapping is one-to-one, so any record below can be read against what the person actually saw.
Two stages run over every message: a heuristic scan for known scam structure (urgency pressure, crypto drainer patterns, impersonation), and a language-model stage that weighs the message as a whole. An in-house discriminator layer can add advisory scores on top; see the disclosure below for its current status.
The design decision worth knowing about
DoubleCheck will not tell you nothing jumped out at it when it could not actually read the thing. If the substance lives in a screenshot, an attachment or a linked chat, or if there is simply too little text to weigh, it says so instead — “I couldn't read this one” — an abstention, not a clearance, logged as unassessable in the records below. The most reassuring sentence this product can say is also the most dangerous one, so it has to be earned. The third case in the proof below shows that behaviour firing.
Read the source
The source is not public, and it is not withdrawn. If you have a use case and a reason, ask — we will show you the source to audit. Disclosure here is earned rather than broadcast, and an audit that starts with a conversation reads the right version of the right system. The history of this policy is in the signed record ledger below. The detection corpora and the trained principle heads were never in the repository and never will be.
Onboarding
1 · Use the hosted bot
Open @better_doublecheck_bot on Telegram and press Start. Forward or paste any message that doesn't sit right. No account, no email, no signup form.
Current limits, as configured in the running deployment: 3 free checks per day; a monthly pass at 50 Telegram Stars; a check pack at 100 Stars. Payment is handled inside Telegram — we never see a card number, and we do not operate a separate billing account.
2 · Deploy it for your community or organisation
For a group, server or company that wants its own instance under its own bot identity and its own data:
- You tell us the Telegram surface (group, channel, or direct-message bot), your expected volume, and where the instance should run — our infrastructure or yours.
- We stand up a dedicated bot identity, deploy the screener, and configure the free/paid thresholds or disable payment entirely for internal use.
- You get the deployment, its configuration, an operator runbook, and a signed provenance record for the deployed build in the same format as the proof of concept below.
- Data: message text is processed to produce a verdict and is stored masked; retention is configurable and can be set to zero for your instance.
Scoping and price by enquiry — use the contact form, or @AttestableResearch on Telegram (which answers with a pairing step before a conversation opens). We will tell you if we think you do not need this.
Attested proof of concept
Executed against the running deployment on 2026-08-09 at 04:43:54 UTC. Not a transcript, not a mock, not a screenshot: src.detector.analyze() was invoked inside the live container and the output below is what came back.
Two reading notes. The Verdict column is the internal level exactly as the signed record names it — in a Telegram reply the person sees the plain sentence it maps to, listed above, never the level word. And this run predates the current reply voice, so its recorded explanations are preserved in the register of their day — signed bytes are never rewritten; the verdicts and the abstention behaviour are unchanged.
| Case | Verdict | Confidence | Heuristics | Tokens | Latency |
|---|---|---|---|---|---|
impersonation-giveaway |
dangerous | 0.99 | URGENCY_TACTIC CRYPTO_DRAINER |
973 | 2.73s |
benign-logistics |
safe | 0.95 | — | 910 | 2.74s |
too-short-abstention |
unassessable | — | — | 0 | 0s |
impersonation-giveaway — dangerous
Input as submitted: “Hi! I'm Vitalik Buterin. To celebrate the Ethereum upgrade I'm giving back to the community. Send 0.5 ETH to the address below and you will receive 5 ETH back within 10 minutes. This offer is only valid for the next 30 minutes, act fast and don't miss out!”
The explanation, as recorded: Contains multiple strong scam indicators: impersonation of a well-known crypto figure, a promise of high returns on small deposits (send X get Y), and extreme urgency with a time limit. This matches common crypto giveaway/drainer scams where victims send funds to an address and receive nothing back.
benign-logistics — safe
Input as submitted: “Hi Sam, confirming our call is moved to Thursday at 2pm your time. I've attached the agenda we discussed last week and the notes from the previous session. Let me know if that time no longer works and we can find another slot.”
The explanation, as recorded: The message is a routine scheduling change with no links, no urgent requests, no money or personal information asks, and no pressure tactics. It contains normal professional language for rescheduling a meeting.
too-short-abstention — unassessable
Input as submitted: “click here”
The explanation, as recorded: There isn't enough here for Sentinel to check. If the real content is in an image, attachment, or a chat this message points to, Sentinel cannot see it — forward the text itself, or treat the message as unverified rather than safe.
Run environment
| Executed | 2026-08-09 04:43:54 UTC |
|---|---|
| Entry point | src.detector.analyze() |
| AI stage | DeepSeek (live API call, billed) |
| Build identifiers | Internal build identifiers (host, container, image and source ids) are withheld from this public page — they name internal infrastructure and cannot be verified off the build host. What proves the run is the signature and the disclosures below. See our exposure policy. |
Disclosures for this proof
These are the things that would make the run above mean less than it appears to. They are published with it, not behind it.
- This is a live run of the shipped detector, not a transcript or a mock. Every verdict, confidence and token count below was produced by the running system at the timestamp above.
- The principle-head discriminators were NOT available during this run: principleHeads is null in every case. Those heads are an advisory layer trained in-house; the container serving them is currently failing to start because its checkpoint files are absent. Verdicts here therefore come from the heuristic scan plus the AI stage only.
- 'degraded: false' refers to the AI stage being reachable. It does not mean the principle heads were present. They were not.
- Three cases is a demonstration, not a benchmark. No accuracy, precision or recall claim is made or implied by this record.
- Inputs were authored for this run. No real user's message was used.
Verify it yourself
The record is clearsigned with the Attestable Research operator key. Nothing here asks you to take our word for it.
- Signed record: sentinel-poc-20260809.json.asc
- Unsigned copy of the same bytes: sentinel-poc-20260809.json — sha256 96e56ed21ff6b6c86e203b3fc12d817cab967d45bf7448a806c26688b74bf528
- Public key: pgp.asc — fingerprint 184E 449F E256 871D FFFB AD33 F3D0 0D36 427D EBC5
curl -O https://attestable.ca/pgp.asc
curl -O https://attestable.ca/products/sentinel-poc-20260809.json.asc
gpg --import pgp.asc
gpg --verify sentinel-poc-20260809.json.asc
A good signature proves the record was produced by the holder of that key and has not been altered since. What makes the record mean something is that its disclosures are part of the signed bytes, not page copy — so a limitation cannot be quietly dropped after the fact. Internal build identifiers are deliberately not published: they are not something an outside reader could verify, and they are not what the proof rests on.
Product record ledger
Every signed record we have published about DoubleCheck (published under its earlier name, Sentinel), newest first. Records are appended, never edited: when the product changes, a new record says so, and the old records keep saying what was true when they were signed — including disclosures that no longer describe the current system.
2026-08-09 — attestable.sentinel.poc/v1 — sha256 96e56ed21ff6b6c8…
Proof-of-concept run record; rendered in full above.
Disclosures (part of the signed bytes)
- This is a live run of the shipped detector, not a transcript or a mock. Every verdict, confidence and token count below was produced by the running system at the timestamp above.
- The principle-head discriminators were NOT available during this run: principleHeads is null in every case. Those heads are an advisory layer trained in-house; the container serving them is currently failing to start because its checkpoint files are absent. Verdicts here therefore come from the heuristic scan plus the AI stage only.
- 'degraded: false' refers to the AI stage being reachable. It does not mean the principle heads were present. They were not.
- Three cases is a demonstration, not a benchmark. No accuracy, precision or recall claim is made or implied by this record.
- Inputs were authored for this run. No real user's message was used.
2026-08-12 — attestable.sentinel.launch/v1 — sha256 4ef898dfef4255a9…
Proof-of-concept run record; rendered in full above.
Disclosures (part of the signed bytes)
- This record describes the deployment as verified on 2026-08-12. Earlier records remain published unchanged beside it.
- Per-reader scores existed for every case below and are deliberately not published, in any form. Naming the readers or publishing their individual figures is a rewrite guide for evasion; what users see — and what this record repeats — is the one-sentence prose summary and nothing finer-grained. The aggregate figure that earlier appeared alongside the prose has been removed from user-facing output entirely.
- The advisory readers are advisory. No accuracy claim is made for them, and the prose they inform never overrides a verdict.
- The signal prose is generated by the house-local model from an aggregate alone, is checked mechanically, and is replaced by a fixed neutral sentence if it names any mechanism or figure. Its wording varies between runs; the wording below is what this run produced.
- Three cases is a demonstration, not a benchmark. No accuracy, precision or recall claim is made or implied by this record.
- Inputs were authored for this run. No real user's message was used.
- Sentinel retains no record that a screening happened; the zero-retention property described in the evolution record is unchanged by this deployment.
- This record was drafted by the executing agent and is published only once signed by the attestation key above; an unsigned copy of this file is a draft, not a claim.
2026-08-11 — attestable.sentinel.evolution/v1 — sha256 3d786a137d210ea6…
Zero-retention storage
Sentinel now keeps no record that a screening happened: no message text, no hash of it, no verdict, no explanation, no timestamp, and no per-screening row of any kind. What persists is an account (Telegram numeric id, plan, today's quota counter, consent, residency choice) and payment records. The migration destroyed the prior screening history on existing deployments and reclaimed the pages on disk.
Verified: The live database was inspected after deployment: no screening table exists, the retired usage columns (lifetime count, last-check timestamp, username) are absent, and a raw byte-scan of the database file finds no residue of the deleted rows. A canary check confirmed a screening grows no table.
Corrected residency disclosure
The prior consent notice said message text was analysed by a third-party service with servers in China. That description predated the current deployment and was wrong in both directions: analysis now runs by default on Attestable's own hardware in Canada, and the third-party fallback (used only when the local stage cannot answer) is reached through a router whose processing geography Attestable cannot verify and therefore does not name. The notice now states the local-first chain, the fallback, the masking and the retention before first use, and users can disable the fallback with /residency — after which a local outage fails their check closed instead of routing it offshore.
Verified: The provider chain was read from the running container in both settings: default = local primary plus third-party fallback; opted out = local only.
Detection-signal disclosure without an evasion oracle
Screenings now always include a one-sentence prose description of how Sentinel's internal advisory checks responded. The per-detector breakdown that previously appeared (detector names with individual scores) has been removed from all user-facing output, and so has the bare aggregate figure that briefly accompanied the prose: naming the detectors and their distances from threshold taught evasion, a raw aggregate invites the same probe-twice-and-compare use, and published figures whose calibration cannot be stood behind dress noise up as evidence.
Verified: The prose is generated by the house-local model from the aggregate alone, is discarded and replaced by a fixed neutral sentence if it mentions any detector name, number or mechanism, and was exercised live against the running deployment. The removal of the aggregate figure from user-facing output was verified against the deployment of 2026-08-12 (see the launch record following this one).
Public source repository withdrawn for now
The source-available repository previously linked from this page has been made private while the product's disclosure surface is reworked. 'Source-available' was a claim about auditability, and a repository that lags the deployed system by this many changes audits the wrong thing. It may return once it again matches what runs; this ledger will say so if it does.
Verified: SIGNING GATE: this change is true only after the repository is actually private. Before signing this record, fetch the public repository URL and confirm it no longer resolves; a signature over this file attests that check was done. The tooling for the flip (github_tor_set_repo_visibility) requires the owning account's token at an operator-controlled path, which only the operator can place.
Training-data custody
Every corpus behind Sentinel's advisory detection heads is version-controlled on Attestable's internal infrastructure only. The public source repository contains bot source code and no training data, no trained weights, and no corpus files. All head training data is synthetic; no real user's or victim's messages exist in any corpus, consistent with the mission boundaries published since the first record.
Verified: An audit enumerated every corpus file behind the five detection heads, confirmed each is committed and present on the internal remote, and confirmed the public repository carries none of them. A stray byte-identical corpus duplicate found in the runtime data volume was removed.
Disclosures (part of the signed bytes)
- This record describes the deployment as verified on 2026-08-11. It supersedes descriptions, not history: the 2026-08-09 record still says what was true on 2026-08-09.
- The advisory detection heads remain exactly that — advisory. The recruitment/control head is telemetry: it does not move verdicts and no accuracy claim is made for it. The published error rates, including the unflattering ones, are in the product repository.
- 'Own hardware in Canada' is the operator's attestation of where the machine sits. The repository can prove a request never left the machine; it cannot prove the machine's latitude.
- No claim in this record has been validated on real victims' messages, and no such corpus exists here to validate on.
- This record was drafted by the executing agent and is published only once signed by the attestation key above; an unsigned copy of this file is a draft, not a claim.
Dataset access
We sell limited, bounded access to the datasets behind our public products — to reputable, named clients, under licence.
Why it is bounded rather than published
A detection corpus is not improved by being downloadable. Two things happen when one is dumped into the open: scrapers absorb it into the next general-purpose model, and the patterns it encodes stop discriminating — the corpus degrades the product it came from. A scam-detection set that everyone has, including the people writing the scams, is worth less to everyone.
So access is scoped rather than open. That is a decision about integrity, not scarcity: we would rather a small number of people have real material than a large number have material that no longer works.
What bounded means, concretely
- Named licensee. A specific organisation or research group, not an anonymous download.
- A stated purpose. Evaluation, research, or a defined integration — written into the licence.
- A defined slice. The subset that serves that purpose, at an agreed size and time bound, rather than the whole corpus by default.
- No redistribution, no onward training outside the agreed purpose.
- A provenance record for the slice you receive, signed in the same format as the proof of concept above, so you can show where your evaluation data came from.
Who we say yes to
Security teams, trust-and-safety groups, academic researchers, and organisations building defences. We will say no to requests that read as corpus resale or bulk model-training acquisition, and we will say so plainly rather than pricing them out.
Honest status
These corpora currently exist as working training material, not as a packaged release. A licensing conversation starts with what you actually need; provenance and licence review for the specific slice is part of the engagement rather than something we claim is already finished. We would rather tell you that here than after an invoice.
Enquiries: the contact form, or @AttestableResearch on Telegram. First contact through Telegram returns a pairing step rather than an open chat window — that is deliberate, and it is the same policy as the licensing above: we would rather know who we are talking to than field volume.
Legal — the short version
The full text is on the legal page. These are the parts that matter before you rely on anything here.
DoubleCheck is not a guarantee
It is a screening aid. It will be wrong in both directions: some scams will draw a reassuring reply, and some legitimate messages a warning. “Nothing jumped out at me” is not clearance to send money, share credentials, or trust a sender. You remain responsible for your own decisions. Nothing DoubleCheck outputs is financial, legal, security or professional advice.
No warranty
The products and this site are provided “as is” and “as available”, without warranty of any kind, express or implied, including merchantability, fitness for a particular purpose, accuracy, and non-infringement.
Limitation of liability
To the maximum extent permitted by applicable law, Attestable Research and its operators accept no liability whatsoever, on any surface, arising from or connected with the products, this site, the lab exhibits, any verdict or output, or any reliance placed on them — including direct, indirect, incidental, special, consequential, exemplary or punitive damages, and including loss of funds, data, profit, goodwill or opportunity, whether in contract, tort (including negligence), strict liability or otherwise, and whether or not we were advised of the possibility.
Some jurisdictions do not permit the exclusion of certain liabilities. Where a limitation above is held unenforceable, it applies to the maximum extent the law allows and the remainder stays in force.
Copyright and confidentiality
© 2026 Attestable Research. All rights reserved. DoubleCheck (formerly published as Sentinel), its source, models, prompts, deployment materials, runbooks and documentation are proprietary and confidential. No licence is granted by publication on this page. Information exchanged during scoping, onboarding or deployment is treated as confidential in both directions.
The lab exhibits at lab.attestable.ca are a separate matter: MIT-licensed, free, and yours to take.