Bounded public-record packet, 9 September 2026. Six core records, including the existing government-published review. No customer data, accounts or moderation APIs were accessed. These are published specifications and standard terms, not proof of a particular customer's configuration, signed contract or enforcement history.
PUBLIC's example is documented as an integration of moderation vendors. The observed path is a customer submitting content for analysis, Sightengine returning classification scores, Checkstep applying the customer's configured policy, and a decision event returning to that customer's platform. The records do not establish a shared list of restricted people or automatic propagation of one platform's ban to another.
The distinction does not make the interface inconsequential: it can carry instructions that remove content or suspend an account. It also does not establish zero reuse. The published contracts contain two different machine-learning permissions: Checkstep's customer-data permission with an opt-out, and Sightengine's voluntary feedback-data route with a separate controller role and retention exception. Permission and actual use remain separate evidence states.
1. PUBLIC's framing and its source. The [Data Landscape Review 2024–2025](http[local research file] §6.1.1 / Case study 4, describes this as signal sharing that lets a moderation provider use classification outputs without acquiring another provider's proprietary datasets. Footnote 35 points directly to Sightengine's coauthored guide, labelled 2025. This is the report's characterization of the vendor example, rather than an independently observed exchange or a cross-platform enforcement agreement. Its phrase about no transfer of raw data must not be expanded into a claim that no submitted content is processed outside the customer's platform.
2. The coauthored interface account. [Sightengine, Ultimate Guide to GenAI Moderation—Part 2](http[local research file] “Detecting and moderating…” §§1.1, 1.3, 2.1–2.2, describes media submitted by URL or upload with selected models. Results include AI-generation/deepfake scores between 0 and 1. Sightengine recommends thresholds; users choose how scores map to their policies. Checkstep integrates those outputs, supports multiple scanning providers, and routes possible violations to automated decisions or human review. It returns results and enforcement decisions to the customer. The guide also describes appeals and community reports. Its privacy language about reference-based integration describes an architecture; it is not a sufficient basis for a universal no-storage claim. The current page displays “Guide, 2026” while its introduction anticipates 2025; the report cites it as 2025. No exact original publication date or historical version identity is established here.
3. Checkstep's actual integration specification. [Standard Integration](http[local research file] “Sending contents,” “Access delegation” and “Receiving Webhooks,” accepts content IDs, text or media references, author identifiers and optional metadata. Delegated access enables content analysis and display to moderators; examples include cloud-storage reads and streaming bytes. Returned data identifies content, policy, severity and confidence. analysed-content supports provisional withholding while a decision is pending. A decision event instructs the customer's integration to take down, restore or keep content down after an appeal. Human author-decision events can suspend/terminate an account, optionally remove its content, or restore it. The customer must implement the webhook handler for the decision to affect its platform. Thus Sightengine's score is not itself a takedown, but the configured Checkstep workflow can produce an actionable instruction. incident-closed reports appeal outcomes. These are documented capabilities, with no observed customer configuration or successful appeal in this run.
4. Checkstep's reuse, responsibility and retention terms. [Checkstep Terms of Service](http[local research file] definitions and §§5.1–5.5, 13.3(C), 14, retain customer ownership while permitting use of Customer Data for machine learning that develops service features. Section 5.5 treats this as a customer instruction and offers an email opt-out; the read clause does not state an anonymization condition or prove pooled training across customers. The terms contemplate archives/backups. On termination they require disposal of data held, subject to a backup-delivery request made within 30 days and legal retention; 30 days is the request window, not a universal deletion deadline. Section 14 identifies the contracting party as controller and Checkstep as processor, generally processing under agreed instructions. Subprocessors require protective contracts and notification with a five-working-day objection window. Data-subject requests are referred to the contracting party. These published terms do not establish which provider/terms a specific customer accepted or whether it opted out.
5. Sightengine's subscriber agreement. [Terms of Service](http[local research file] §§1, 3.5–3.6, 4.1–4.6, 9.1–9.3, identifies the operator as Kozelo SAS. Routine Subscriber Data is licensed for service provision and instructed interoperability. Section 9.3 first grants perpetual, irrevocable use permission for general suggestions/corrections. Its separate nonexclusive licence covers voluntary raw-media submissions, with or without labels, through the Feedback API or similar mechanism for model development, testing and training; the subscriber warrants the necessary rights and consents. The raw-media licence must not inherit the first sentence’s adjectives merely by proximity. This is not proof that normal scanning automatically supplies training media, or that Checkstep sends its customers' data into this route. Sightengine can also send service-compliance notices and suspend its subscriber's API access. That power concerns the provider/customer service relationship and must not be confused with direct control of an end user's account on an unrelated platform.
6. Sightengine's feedback exception and correction route. [Data Processing Addendum](http[local research file] PDF 2 / definition, PDF 3–4 / §§2.1–2.3 and PDF 6–7 / §§4–5, normally assigns Sightengine a processor role; a subscriber that is itself a processor must have the controller's authority. For voluntarily submitted Feedback Data, §2.3 instead makes Sightengine an independent controller, subject to privacy law and an appropriate lawful basis. Ordinary deletion instructions are to be completed as soon as reasonably practicable, within 90 days subject to legal retention; expiry provisions also describe a recovery period of up to 30 days. Section 4.4 exempts Feedback Data from those automatic return/deletion provisions and permits perpetual retention subject to its privacy policy and applicable law. Section 5 enables access, correction, restriction, export and assistance with data-subject requests, normally through the subscriber. This is not a finding that privacy rights disappear or that every correction propagates into a trained model.
| Interface | What can travel | What this packet does not establish |
|---|---|---|
| Customer → Checkstep → selected scanner | Content/reference access, selected model inputs and identifiers needed for that customer's moderation | An exchange of the scanner's proprietary training corpus |
| Sightengine → Checkstep | Detection scores/classification results for submitted media | A decision binding every other platform or a shared offender identity |
| Checkstep → customer platform | Policy-linked content/account decisions, provisional results and appeal outcomes | A deployed handler, its actual settings, enforcement against a particular user, or an independent appeal body |
| Customer data / voluntary feedback → model development | Published permissions for two distinct reuse routes | Whether a customer used either route, whether learning is pooled, the actual training corpus or a resulting cross-customer restriction |
The strongest rival to a cross-platform restriction interpretation is ordinary service composition: one vendor supplies classifiers and another supplies policy/workflow software for each customer's site. The explicit contract permissions leave a narrower cross-customer learning possibility open, but that is not the same mechanism as transmitting a ban or restriction signal. Affected people can face automated consequences even where formal policy choice remains with the customer; the discriminating evidence is the configured rule and its execution, not the mere presence of a classifier.
Original captures and SHA256 values are recorded in cs-captures.json. cs-standard.html, cs-sightengine-guide.html, cs-checkstep-terms.html, cs-sightengine-terms.html and cs-sightengine-dpa.pdf were acquired by ordinary HTTP 200 requests on 9 September 2026. The report uses the existing ../osdi-comparison-wave-2026-09-09/data-landscape-2025.html. Derived text copies support precise reading; cs-sightengine-dpa-extract.txt preserves the inspected PDF pages. Source states are read, with targeted scopes in the manifest; no statement claims every annex was audited.
The DPA's actual redirect target was http[local research file]; SHA256 4d67f249fce7d29c2d6e60bc1af43f9935a61d566131276c1ba03827214a1e7b. The filename identifies a 20260407 version cue. Its legally defined effective date depends on acceptance; the file name is not evidence of the Checkstep integration's historical terms. Current contractual clauses must not be backdated into PUBLIC's 2025 case study.
The auxiliary [Sightengine AI-video documentation](http[local research file] “Moderation result” and FAQ score/threshold sections, was read through the web reader; original bytes were not retained. The public Checkstep home and Sightengine FAQ pages served link discovery. They do not support an additional ownership, customer or deployment claim. No private dashboard, gated guide submission, customer content or test API request was used. No failed access route required a retry.
This example weakens the claim that every programme labelled signal sharing creates a cross-platform restriction system. It strengthens a more specific mechanism: policy choices become machine-readable workflows that can carry real content/account consequences, while contractual reuse can turn some moderation inputs or feedback into model-development resources.
Reopen on a public customer-specific integration/SOW, settings export or redacted decision-and-appeal audit that identifies the scanner, score thresholds, policy mapping, action handler and correction outcome. For the reuse question, the needed records are a customer opt-out/feedback configuration, the applicable controller/subprocessor terms and a documented training-use pathway. No outreach is authorized or proposed in this packet. Acquisition stops here for the forest review; no graph edits were made.