Architectural anchors¶
Three anchors run beneath every tool card and every decision tree in the toolkit. They are not declared rules in the sense that a reader needs to memorise the wording. They are operational logic the cards and trees encode, and a reader who walks through any 1A tier card, any 1C institutional card, or the T5 escalation tree will recognise the anchors in operation even without reading this page. This page makes the anchors legible as anchors – the discipline running across the workflow – so a reader who is extending or contesting the toolkit's framing can see what would change if any of the three were dropped.
The anchors were settled after a strategic review of a draft tool inventory that contained substantial detector-class density. The review surfaced the problem the anchors solve: a toolkit that lists detectors as if they were the operational answer to AI-powered disinformation will be used as if they were the operational answer, and the field evidence on detector reliability does not support that use. The anchors codify the alternative. The four-pillar workflow (provenance, source-history, behaviour, cautious-detector), the two-non-detector-signals floor on publishable claims, and the one-signal-class wrapping on multi-detector products together produce a toolkit whose centre of gravity is non-detector work, with the detector class wrapped, framed, and consistently positioned as one input class among the four pillars.
Anchor 1 – The toolkit is not a directory of detectors¶
Detection is one of four signal classes. Provenance, source-history, behaviour, and cautious-detector together form the workflow the toolkit teaches. The detector pillar is the last resort, not the first move, and the cards' organisation encodes that ordering operationally.
The four pillars surface in three places in the cards. Every card's YAML frontmatter carries a pillar_service field naming the pillar or pillars the tool serves. Multi-pillar tools (InVID-WeVerify across provenance, source-history, and cautious-detector; ExifTool across provenance and source-history) are positioned as multi-pillar in the card prose and in the tool-card pivot view. The In the toolkit's workflow section on every card names the pillar service explicitly and describes how the tool combines with tools serving other pillars. The standard-combinations bullets on every card link tools across pillars: Sensity (cautious-detector) with InVID-WeVerify (source-history and provenance) and Meedan Check (source-history) in the Rappler / #FactsFirstPH workflow on the Doc Willie Ong case, for example.
Anchor 1 surfaces sharpest in the 1A.4 cell, where provenance and watermark verification is the primary mode. Content Credentials Verify, SynthID Detector, and the C2PA Conformance Explorer are all non-detector tools. The cell deliberately precedes 1B.2 (AI text detection, contracted to two cards with detector-as-weak-signal framing binding) in the user's pillar-1 reading order. The order is part of the anchor in operation: the reader meets provenance-as-primary before meeting detector-as-fallback.
The anchor surfaces in 1B.4 (metadata / ELA forensics) as a different expression of the same logic. ExifTool, Sherloq, and FotoForensics cover the source-history pillar with three different privacy postures: command-line standard for evidentiary chain-of-custody, offline desktop for surveillance-environment work, and web ELA with the cloud-upload caveat for sensitive material. None of the three are detectors. The cell is a Pillar 1 tier where non-detector tools handle what a less disciplined toolkit would route to detectors.
The anchor surfaces in 2C.1 (automated claim monitoring) at the behaviour pillar. Information Tracer, Media Cloud, Sinar Project iMAP, and FactFlow AI are all non-detector tools producing behavioural signals at scale. The behaviour pillar's expression at 2C.1 demonstrates that "is this content AI?" is not the only question the toolkit teaches the reader to ask; "what behavioural patterns surround this content's spread?" is the parallel question, and it is answered through non-detector signals.
The position the anchor embeds is that detector results are useful as one input among the four pillars, and become misleading the moment a verifier treats them as the load-bearing signal. The position is not anti-detector. The 1A.1, 1A.2, 1A.3, 1B.2, 1B.3, 1C.2, and 1C.3 cells all ship detector tools. The position is anti-detector-as-load-bearing. The detector cards carry the framing through the detector-as-weak-signal caveat; the non-detector cards carry the load-bearing role explicitly in their workflow sections.
The four signal classes, as a quick reference:
| Signal class | What it answers | When it matters most | Strength and weakness |
|---|---|---|---|
| Provenance | What the file's manifest says about who made it and how: creator, edit history, AI-use disclosure, signing chain | When a clean original file is in hand carrying C2PA / Content Credentials or a vendor watermark such as SynthID; check it first | The most reliable class and the only one that travels with the file. Regional adoption is patchy and platform re-encoding strips manifests, so most TikTok, WhatsApp, LINE, and Facebook reposts arrive stripped |
| Source-history | Where the file has been before: reverse-image hits, archived versions, prior debunks, metadata and timestamps, outlet reliability | The productive non-detector mode on most cases; it often resolves the question before any detector tab | Works language-agnostically. Cloud tools carry a source-protection exposure, so an upload-safety check binds before sending an identifying file |
| Behaviour | What coordination patterns surround the content's spread: posting cadence, account-creation overlap, narrow template space, synchronised bursts across unrelated accounts | When source-history or tipline volume surfaces a coordination signal, or the case scales to cross-platform pattern work | Catches network-level operations a single-artefact read misses. The work is largely institutional and partner-mediated, and no ready-made SEA-specific worked-example casebook exists for this class |
| Cautious-detector | A probability that the artefact is AI-generated or manipulated | Last resort, after the non-detector signals are exhausted; a fast triage signal alongside non-detector evidence | Fast and multimodal as one input among the four. It is one weak signal, never sufficient alone; multi-detector consensus counts as one class, and the best commercial video detector sits at 0.78 accuracy |
Anchor 2 – Two non-detector signals required for any strong public claim¶
The second anchor is editorial policy, not advisory. Every decision tree's terminal "publish" node enforces it. Every tool card identifies whether its output is a detector signal or a non-detector signal so the editorial layer can apply the rule operationally.
The rule comes from the field evidence on detector reliability. The published benchmark evidence documents the category-level upper bounds: the best commercial video detector reached only zero point seven eight accuracy and zero point seven nine AUC on two thousand and thirty-six in-the-wild 2024 deepfakes (Lyu et al., Deepfake-Eval-2024). The Stanford 2023 study on GPTZero recorded sixty-one percent false positive on non-native English writing. The DW Innovation November 2025 audit on voice-clone detectors concluded that none of Hiya / Loccus, Deepfake Total, or DeepFake-O-Meter reliably identifies AI voices across SEA languages. The category ceilings are too low for a single detector pass to anchor a publishable claim against named subjects, above all public figures whose defamation defence depends on the strength of the underlying evidence.
The rule's operational expression sits in the tool cards' signal-class declarations and in the decision trees' terminal nodes. Every tool card carries a signal_class field in its YAML frontmatter: detector, non-detector, or mixed-with-declaration. A card declaring mixed-with-declaration (ImageWhisperer, TruFor) explains how the uncertainty band is presented to the reader and which class the output should be read as for editorial purposes. The decision trees' publish nodes route the reader through an "at least two non-detector signals confirmed?" check before any terminal-state action. T1 image triage, T2 video triage, and T3 audio triage each carry the gate.
Anchor 2 surfaces most sharply in 1B.2 (AI text detection, contracted). The independent benchmark evidence on text detectors is consistent: Turnitin at zero point six one, Originality at zero point six nine, GPTZero at twenty-six and four-tenths and sixteen and seven-tenths percent in different studies, ZeroGPT at thirty-one and three-tenths and seventeen and three-tenths percent, Copyleaks at seventy-three and nine-tenths percent with fifty percent false positive on small human-control samples. The cell ships two detector cards (Pangram as primary, GPTZero as cautionary case) with the binding "do not use as standalone evidence" framing. The anchor's operational expression in 1B.2 is the cell-level pin: even where the field has dozens of candidate detector tools, the cell deliberately ships thin and frames the detector class as unreliable for high-stakes use. The corresponding country-page guidance routes the reader to non-detector alternatives: tipline-database matching, provenance verification on the original publication, source-history reverse-image search.
The anchor surfaces in T6 (source-protection) at the S6 detector-only-accusation gate. S6 is rendered globally on T6 instead of on every individual detector card because the gate binds on every detector in the toolkit equally; rendering it sixty-five times would dilute the binding. The source-protection-aggregation page carries the editorial-position statement at depth. The statement is that the detector class is not a publishable signal class on its own; a verifier on deadline who gets a ninety-two percent AI-generated reading from a detector and treats it as sufficient evidence to publish has violated Anchor 2 and is about to be wrong.
The position the anchor embeds is that publishable claims about AI-generated, deepfake, voice-clone, bot, or coordinated-inauthentic-behaviour content require evidence the detector class alone cannot supply. The two non-detector signals must come from different pillars: a provenance match plus a reverse-image hit, a tipline-database match plus an original-archive recovery, a behavioural-pattern match plus a content-language analysis. The rule does not require that the detector be wrong; it requires that the detector's verdict not be the only thing standing between the reader's case and publication.
Anchor 3 – Detector plus detector is one signal class¶
The third anchor is the multi-detector wrapping rule. Tools that aggregate multiple detection models inside one product (Sensity's multilayer pixel / acoustic / metadata / behavioural analysis, Reality Defender's "massive ensembles", Hive's multimodal stack) are scored as one signal class collectively, not as a multiplier of detector signals.
The rule comes from the false-confidence pattern documented across the toolkit's source literature. A working fact-checker runs an image through three detectors – Hive's multimodal detector, Sensity's deepfake module, and InVID-WeVerify's deepfake tab – and gets three "AI" verdicts at high confidence. The fact-checker treats the three verdicts as three independent confirmations and publishes. The treatment is wrong: the three detectors share training-data overlap, similar architectures, and convergent failure modes. The three verdicts are one signal class with three rendering surfaces, not three independent signals.
The rule's operational expression sits in the cards' G3 declarations and in the decision trees' Anchor-3-reset branches. The Sensity card carries the rule explicitly in its workflow section: "Counted as one detector signal class under Architectural Anchor 3, regardless of how many of Sensity's internal modality scores contribute to the verdict." The Reality Defender card carries the matching declaration. The 1C.2 cell's editorial framing in the pivot view names the rule at the cell level: an enterprise platform that internally aggregates ten ensemble models is still one detector signal class.
Anchor 3 surfaces in the T5 escalation tree at the Anchor-3-reset branch. When a verifier escalates a case because "two tools disagree" and the two tools are both detectors, T5 resets the verifier's signal-class accounting: the two detectors' disagreement is one signal class in internal disagreement, not two signal classes failing to align. The reset routes the verifier to seek a non-detector signal as the tie-breaker, not to treat the detector-detector disagreement as evidence of the underlying truth being uncertain in the first place.
The rule carries an exception clause: "independent methods and explanations" can permit multi-detector treatment as more than one class. In practice, single-vendor multi-model products do not meet the exception. The exception applies more naturally to a workflow that combines, say, a peer-reviewed academic detector run with explainable-AI heatmap output (XAI-Deepfakes) and a commercial detector with a different training corpus and different output modality. Even there, the exception is a careful judgement, not a default.
The position the anchor embeds is that multi-detector consensus is a confidence illusion when the underlying detectors share architecture, training, or failure modes. The illusion is consequential because a fact-checker who treats multi-detector consensus as multi-signal confirmation will publish on weaker evidence than the editorial position thinks. The rule is hard-coded against the illusion. Its operational form is the per-card declaration plus the decision-tree reset; together they make the rule's enforcement visible to the reader at the card layer and at the workflow layer.
How the three anchors operate together¶
The three anchors interact as one operational discipline. A reader applying the discipline on a working case runs through three checks. First, which of the four pillars does the candidate signal come from? Second, is the candidate signal sufficient on its own (which it is not if it is a detector signal) or does it require a second non-detector signal to clear Anchor 2's floor? Third, if the case has multiple detector tools in play, do they count as multiple signal classes (which they do not under Anchor 3) or as one signal class in collective uncertainty?
The interaction renders in the decision trees. T1 image triage routes the verifier through provenance (1A.4 cell) before any detector pass (1A.1 cell). T4 provenance triage routes the verifier toward the C2PA / SynthID / Content Credentials pathway as the primary mode. T5 escalation carries the Anchor-3-reset branch and the source-disagreement node. T6 source-protection carries the S6 detector-only-accusation gate. T7 tipline routing carries the routing into non-detector tipline-database matching that supplies the second non-detector signal Anchor 2 requires.
The interaction renders in the country pages. The Philippines page Doc Willie Ong case is the worked Pillar 1 ladder running the four-pillar workflow alongside the Sensity / Hive / InVID combination, with non-detector signals (Rappler's tipline-database match, the original-publication archive) carrying load-bearing weight alongside the detector pass. The Thailand page Anutin / Mauerberger case is the worked provenance-first non-detector case: Thai PBS used SynthID Detector (1A.4 cell) as the primary verification instead of running a detector pass at all, demonstrating that Anchor 1's pillar-ordering surfaces operationally at the country level when the case admits a provenance route.
A toolkit that dropped one of the three anchors would change shape substantially. Without Anchor 1, the cards would re-organise around detector taxonomy and the non-detector tools would lose their primary-pillar framing; the toolkit would become a directory of detectors with workflow notes attached, the reverse of the current shape. Without Anchor 2, the decision trees' publish nodes would not carry the two-non-detector-signals floor and the toolkit's editorial position on defamation defence would weaken substantially; the field-evidence base on detector reliability does not support the weakening, and the toolkit would mislead its audience on what claims are publishable. Without Anchor 3, the multi-detector consensus illusion would re-enter the cards and the decision trees, and the false-confidence pattern that drove the anchor's introduction would return.
The anchors are stable. They are named as immutable from the framework's side: no criterion in the selection framework can override them, and any new criterion that would weaken an anchor is dropped or rewritten. The change log records that no anchor has been revised since they were first set. The editorial-patterns codified (the five patterns the cards embed) operate beneath the anchors, not parallel to them. A reader who internalises the three anchors and the five editorial patterns has the operational basis for the toolkit's framing of the detector class, the signal architecture, and the editorial-honesty system that runs across the sixty-five cards and seven decision trees.