Guide14 min read

DSA evidence records

DSA statements of reasons as an evidence dictionary

How law firms and evidence teams can use DSA statement-of-reasons fields as structured context: content type, restriction, source, ground, automation, PUID, and timestamp. The database is an input to a wider online-harm evidence file, not a truth machine or legal conclusion.

Updated September 2026By Henryk Wexel

Key takeaways

A DSA statement of reasons is a platform record about a moderation restriction. It is useful evidence context, but it is not the whole incident record.
The most useful fields for evidence operations are PUID, content type, restriction, source of investigation, decision ground, category, automation flags, dates, and any platform reference URL.
Treat the public Transparency Database as a dictionary and reconciliation source, not as proof that a platform decision was correct, complete, or final.
A strong online-harm evidence file preserves the original source capture, platform notice, statement fields, custody log, and reviewer questions together.
Finium structures these records for law-firm review while leaving legal interpretation, platform strategy, and client advice to counsel.

Answer-engine summary

Short answer

A DSA statement of reasons can act as an evidence dictionary for online-harm matters. It records platform-side fields such as content type, restriction, source of investigation, ground, category, automation, PUID, and dates. Those fields help a law firm organize the platform record, but they do not replace source capture, custody notes, human review, or legal interpretation.

Use the statement as one record type in a wider evidence file: source capture first, platform statement second, custody trail third, reviewer questions fourth. The useful output is a matter file that shows what the platform said, what the team observed, what changed, and what remains unresolved.

Why this matters now

The September 2026 radar found a timely platform-governance hook: the official DSA Transparency Database exposes structured fields for statement-of-reasons records, while AI Act Article 50 guidance and C2PA implementation work are making labels, marks, and provenance signals more common in synthetic-media incidents. The practical evidence lesson is narrow and durable. Labels and platform records are useful context, but incident teams still need a source-aware evidence file that captures the underlying content, the visible label or notice, the platform response, and the custody trail.

DSA statement fields can identify the platform record, affected content type, restriction, source of investigation, decision ground, category, and automation flags.
Article 50 and Content Credentials signals can explain how AI involvement was labelled or marked, but they do not decide authenticity or legal effect.
A law-firm evidence file can reconcile those records with the original post, profile, ad, message, landing page, or media capture.
The evidence desk should preserve what was visible and when, not announce whether a legal duty was met.

The evidence dictionary fields that matter most

DSA statement fields translated into evidence-operations questions

Field or record	Evidence question	How to use it
PUID or platform identifier	Which platform record is this, and can it be linked to an internal case or URL?	Store it in the platform-record register and link it to source captures, notices, and appeals.
Content type	Was the affected material text, image, audio, video, product, synthetic media, or more than one type?	Use it to choose the right capture method and sensitivity rules.
Restriction type	Was visibility, account access, service access, monetization, or another platform function restricted?	Record the operational effect without treating it as a legal conclusion.
Source of investigation	Did the review follow a user notice, trusted-flagger notice, other notification, or platform initiative?	Connect the statement to the original notice, report receipt, or monitoring event.
Ground and category	Which legal, contractual, category, or specification vocabulary did the platform record?	Preserve the field as platform wording and keep counsel-review labels separate.
Automation fields	Was automated detection or automated decision support recorded?	Log the flag, then preserve human review notes and platform text separately.
Dates and territorial scope	When did the content, decision, restriction, and statement record appear, and where did it apply?	Align the platform timeline with capture timestamps and custody events.

Practical workflow: capture, reconcile, label, preserve, export

Run the DSA dictionary as a workflow, not a memo. Start with the source material and its live context. Capture the platform record exactly as displayed or exported. Reconcile the platform fields against the source capture and any client-reported context. Label gaps or conflicts. Preserve both the raw materials and the structured register. Export a concise file that counsel can review without rebuilding the timeline from separate screenshots.

Capture: preserve the source URL, item ID, account context, media, thread, landing page, notice, or unavailable-source screen.
Register: record the PUID, platform, content type, restriction, source of investigation, ground, category, automation flags, and dates.
Reconcile: match platform fields to evidence IDs and note conflicts, blank fields, missing notices, or changed interfaces.
Label: separate observed platform records, client reports, pattern inferences, and counsel-review questions.
Preserve: keep originals, screenshots, exports, hashes where available, custody events, and access records under the matter boundary.
Export: prepare a source index, platform-record register, chronology, sensitivity register, and open-question list.

Evidence checklist for a statement-of-reasons record

Platform name, service, URL, statement permalink or PUID, and capture timestamp with timezone.
Full copy of the notice or statement as displayed to the user, plus the public database record where available.
Affected content or account identifier, original source URL, media file, profile state, surrounding thread, and discovery path.
Restriction type, territorial scope, duration, application date, and any visible status change after the record was issued.
Source-of-investigation field, notice or report receipt, trusted-flagger indicator where visible, and appeal or complaint references.
Automation fields, human-review notes where available, and separate reviewer questions for counsel.
Custody event for each capture, including owner, storage path, file hash where tooling supports it, redaction status, and export version.

How to avoid over-reading the database

The public Transparency Database is useful because it makes platform records more searchable and comparable. It is also limited. It may omit personal data by design, it may not include every piece of internal context a platform used, and live totals or visible rows can change. Treat a database entry as one preserved platform statement, then ask what source material, user-facing notice, appeal record, and custody trail are needed around it.

Do not treat a database row as proof that the underlying content was unlawful or policy-violating.
Do not treat the absence of a matching row as proof that no user-facing platform event occurred.
Do not copy live totals into evergreen copy as market sizing without a date and retrieval note.
Do not merge platform categories with Finium or law-firm conclusions. Keep category fields as platform wording.

Where AI labels and Content Credentials fit

In synthetic-media matters, a statement of reasons may sit beside AI-content labels, Content Credentials, watermarks, provenance metadata, platform warnings, and automated-analysis outputs. Preserve those as signals with source, timestamp, and capture method. A label can show what was disclosed to a viewer at a moment in time. A Content Credential can expose provenance data when present. Neither one replaces the evidence file or decides authenticity, liability, platform adequacy, or matter outcome.

Record how the label appeared: placement, wording, visibility, duration, platform, screenshot, and time of capture.
Record whether credentials were present, absent, stripped, or unavailable in the captured version.
Keep automated-analysis outputs in a signal layer with tool, version, input, time, and reviewer status.
Attach labels and credentials to the same source ID as the content they describe so counsel can inspect the context.

Disclaimers and operating boundary

This guide is an evidence-operations reference, not legal advice, DSA compliance advice, platform-policy advice, or litigation strategy. It does not decide whether a statement is complete, whether a platform acted correctly, whether content is unlawful, whether a label is legally sufficient, or whether any reviewer will accept a record. Finium helps structure source captures, platform records, custody notes, and export boundaries for law-firm review.

Frequently asked questions

What is a DSA statement of reasons?

It is a platform explanation for a covered content-moderation restriction under the Digital Services Act. The public Transparency Database stores structured statement data from covered online platforms without personal data, while user-facing notices and internal case files can contain context that is not public.

How can statements of reasons help online-harm evidence work?

They give reviewers a structured vocabulary for platform events: what content type was affected, what restriction was applied, which source triggered review, whether automation was involved, and which ground or category the platform recorded. Those fields help organize the matter file beside the source capture and custody trail.

Does a Transparency Database entry prove the platform was right?

No. A database entry is an observed platform record. It can help counsel and qualified reviewers understand what the platform reported, but it does not decide whether the content, notice, restriction, or appeal position was correct.

What should an evidence team preserve with a DSA record?

Preserve the source URL or object, full capture, platform notice or statement text, PUID or reference number, dates, content type, restriction, source-of-investigation field, automation flags, related appeal or complaint records, and a custody note for each item.

Where does Finium fit?

Finium can turn source captures, platform records, statement fields, timestamps, hashes, custody notes, and reviewer questions into a structured evidence file for law firms. The firm remains responsible for legal advice, client communication, and matter strategy.

References