Products · DoubleCheck

A second look, just in case.

DoubleCheck is a Telegram bot that gives any forwarded message a second look and answers in plain language, with the reasoning that produced the answer. It is held to the house standard — show the mechanism, state the limits, say what is paid and what is not.

signed provenance stated limitations no ads, no tracking

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:

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:

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.

CaseVerdictConfidenceHeuristicsTokensLatency
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

Executed2026-08-09 04:43:54 UTC
Entry pointsrc.detector.analyze()
AI stageDeepSeek (live API call, billed)
Build identifiersInternal 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.

Verify it yourself

The record is clearsigned with the Attestable Research operator key. Nothing here asks you to take our word for it.

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.

signed record · same bytes, unsigned

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.

signed record · same bytes, unsigned

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.

signed record · same bytes, unsigned

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

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.