← Red Threads

Altitude: product governance and correction boundaries

Observed 9 September 2026. This is a bounded static inspection of the public implementation linked by Tech Against Terrorism (TAT), not an installed or deployed system test. Acquisition is closed. No product/API calls, accounts, forms, content feeds, terrorist-content files, dependency installation or repository test suite were used. Canonical cases, readers and ZIPs were untouched.

Result

The public records establish a real route from privately supplied classifications into a platform's review queue. In the inspected version, TCAP is explicitly treated as a trusted source when calculating confidence for prioritisation. They also establish platform choices over source connections, feedback sharing, authentication and the moderation verdict. These are different decision points: source authority influences attention; the inspected workflow does not make the source's flag an automatic removal order.

There are concrete correction facilities, but they must not be collapsed into an end-user remedy. A moderator can cancel a draft review before publication; the inspected create endpoint can append another review to an existing case. The generic importer contains a source-redaction hook. Optional feedback can return platform verdicts to TCAP. None of these inspected paths establishes that an upstream correction automatically restores removed content, notifies its author, or reopens every affected case.

Public identity, maintenance and version

TAT's [22 July 2024 stewardship announcement](http[local research file] says Altitude was built with Google Jigsaw, TAT will lead maintenance and development, and Jigsaw will continue advisory support. It describes prior testing with small and medium platforms, but provides no independently verified deployment, participant list or measured acceptance result in the body read. The announcement and [current product page](http[local research file] offer free access/onboarding through the Bronze support tier, with additional support/features at higher tiers. No financial amount or Canadian grant allocation is stated in these sources.

The product's exact public repository link is [Jigsaw-Code/altitude](http[local research file] Its observed main commit was 496951f7d7a83508e9fac5709d4db2e91c654685, authored/committed 8 August 2024, message “Fix typo.” All retained source files are pinned to that commit. A repository still under the Jigsaw-Code namespace is not proof of Google's present operational veto, and this observation of main does not establish that no other development or deployed version exists.

The [contribution instructions](http[local research file] require a contributor agreement and review of submissions, including those by project members. They say contributors or employers retain copyright. The actual signed CLA, repository permissions, branch protections and named final approvers were not acquired. The retained [Apache 2.0 licence](http[local research file] permits reproduction/modification/distribution subject to its conditions; it disclaims warranty and allows separately accepted support obligations. These software permissions do not grant access to restricted signal databases or establish a support contract's terms.

Who configures access and source use

The [README](http[local research file] requires the platform to obtain TCAP and GIFCT credentials. The product page describes the platform installing the tool, comparing its content to consolidated signals, and a moderator reviewing and selecting action. The [overview](http[local research file] distinguishes signals, the client's target content, cases and human reviews. The inspected public software is therefore not proof that TAT has unrestricted access to every customer dataset or chooses every target.

The [FAQ, lines 90–104](http[local research file] assigns authentication to the integrator and says the tool itself supplies no user accounts. This is a documented deployment responsibility, not a finding that any actual production instance is unauthenticated. No deployed role assignments or separation between administrator and reviewer was inspected.

The [UI service configuration routes, lines 617–707](http[local research file] expose separate enabled and diagnostics-enabled settings for TCAP and GIFCT connections. The [importer creation endpoint, lines 73–133](http[local research file] defaults a new import connection to active and diagnostic sharing to inactive, subject to successful credential pre-check. This establishes configurable connections in the source, not a particular customer's consent setting or the upstream organisations' admission rules.

Classification and priority: a specific implementation of trust

The [TCAP adapter, lines 141–182](http[local research file] imports source identifiers and report dates, associated organisation text, personal-information and extreme-content flags, a URL and its checked availability status. Those are input metadata, not an independent adjudication by Altitude.

The [priority implementation, lines 24–135](http[local research file] has TRUSTED_SOURCES containing TCAP. A signal from that source qualifies for the highest confidence component (3), as can multiple source names or sufficient trust metadata. Severity is calculated separately from tags and features. TCAP's confidence boost does not alone guarantee the highest overall queue priority, and neither score is a moderation verdict. The term confidence here denotes the implemented heuristic; no calibration study was inspected.

The [FAQ, lines 29–64](http[local research file] says cases are ranked by combined confidence/severity, with severity weighted and absent flagger data shown as N/A. Its example table is illustrative. The inspected scoring choices are source-code constants; no customer-facing editor for those rules was established. Apache modification rights make adaptation possible, but do not show that a customer changed these defaults or that TAT approves every local change.

Verdict, delivery and undo are separate

The review endpoint, lines 47–87.

The [publication/delivery code, lines 522–604](http[local research file] publishes the draft and sends client context, APPROVE/BLOCK and decision time to a configured action receiver. Without that receiver, the inspected branch writes a local verdict log. A successful receiver response, or that local log branch, produces the code's ACCEPTED delivery status; it is not proof of removal from a live service. The README's general statement that all decisions are logged should therefore not replace this conditional implementation detail. A platform must implement what receipt of a verdict does.

The [FAQ, lines 106–113](http[local research file] explicitly allows “Remove” to be renamed for platforms whose action differs. The retained client config maps APPROVE to “Leave up” and BLOCK to “Remove.” Labels are not evidence of execution. The FAQ also says uploaded content remains archived locally after platform removal and needs separate database deletion (lines 22–27).

Feedback and upstream correction: partial paths

The task exporter, lines 701–738.

The [TCAP exporter, lines 227–254](http[local research file] sends URL plus decision, translating BLOCK to REMOVE and APPROVE to APPROVE. It demonstrates a feedback mechanism, not that TCAP accepts a disagreement, changes a label or propagates a correction. The FAQ's claims about improved accuracy and effectiveness are product claims, not measured results in this review. GIFCT's adapter payload was not inspected; its existence must not inherit TCAP's exact payload semantics.

The generic importer, lines 156–195.

Custody, reading scope and finite frontier

altitude-captures.json records 24 retained public originals, exact URLs, retrieval times, byte lengths, SHA-256 values, pinned commit and per-file reading scope. Five GitHub tree captures were used only for exact path discovery. Announcement/product bodies, README, overview, FAQ, CONTRIBUTING, the full priority/review/importer/TCAP-adapter/base-importer files, and the specified task/UI route passages were read. Licence sections 2–9 were read. No fixtures, image examples or underlying harmful content were opened. The GitHub docs-directory reader cache miss was closed; exact linked static files were available. Successful ordinary GETs were retained without claiming a full repository audit.

The next discriminator is a named deployment's operative configuration and acceptance/correction receipt: version and changes, source and diagnostics choices, reviewer authentication/authority, action-receiver behaviour, and an upstream withdrawal carried through to a logged decision and restored or retained content. TAT/platform custodians would hold those records. The historical funder's accepted output or code-version record would separately connect grant-funded delivery to this implementation. No Canadian allocation, donor instruction, universal platform execution or live correction result is inferred from this public code.