A correction needs a provenance trail

A rapid response to disinformation has a systems problem: a team must react quickly without turning an unverified claim into a more widely seen one. That is especially difficult when evidence is incomplete or discussion moves between languages.

Lustro is a source-linked response layer for documented disinformation clusters. Its operating cadence is a rolling six-hour ingest and classification cycle, with immediate recalibration for high-risk clusters. The classification considers harm, audience, evidence quality, and spread potential. The resulting response may be a correction, a prebunk, or restrained satire; it must not repeat an unverified claim or become political persuasion.

For platform engineers, the interesting question is how to make those decisions inspectable. The operator brief defines the cadence and obligations, but not a software architecture. What follows is an implementation sketch, not a description of Lustro’s deployed internals.

From cluster to response

Current cluster feed
|
v
Six-hour ingest and classification
|----------------------------|
| |
v v
Evidence and risk review High-risk recalibration
| |
|-------------+--------------|
v
Response or no publication
|
v
Source links + decision log

I would keep classification separate from publication. Ingest can identify a cluster that deserves attention without deciding that its underlying claim is verified or safe to quote. A publication gate can then require source links, a recorded evidence assessment, and an explicit decision about whether describing the claim would amplify it.

A decision-log record could look like this:

{
"cluster_id": "feed-provided-id",
"reviewed_at": "timestamp",
"review_trigger": "six-hour-cycle-or-high-risk",
"harm_assessment": "recorded assessment",
"intended_audience": "recorded audience",
"evidence_quality": "recorded assessment",
"spread_potential": "recorded assessment",
"source_links": [],
"decision": "correction-prebunk-satire-or-no-publication",
"rationale": "why this decision follows from the evidence",
"reviewer": "accountable reviewer identifier"
}

That is a proposed schema, not a published Lustro schema. The brief requires retained source links and decision logs; it does not specify their storage system, retention period, access controls, or reviewer workflow. Those are questions an implementation must settle rather than details an article should invent.

The same distinction matters for automation. A scheduler can reliably trigger the six-hour review, and a high-risk flag can route a cluster for immediate recalibration. Neither mechanism should silently turn weak evidence into a public correction. The log needs to preserve why the team published, held, or changed a response so that a journalist, researcher, practitioner, or public official can inspect the reasoning later.

The cross-language constraint

Cross-language drift is one reason to retain that context rather than publish a detached screenshot. For the research behind this concern, see Jakub Sikora’s “Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets,” published under the ProjektLustro.eu Open Research Initiative: reading version or PDF.

For EU/PL audiences, a useful response needs to make its sources and scope clear without asking readers to trust a classification label on its own. That creates a trade-off: adding context takes time, but stripping it away makes a fast response harder to check. The six-hour cycle supplies a regular review point; immediate high-risk recalibration prevents that cycle from becoming a reason to wait.

I’m sharing this as a community advocate, not as an author of the paper or a creator of the project. If you work on evidence pipelines, incident response, or verification workflows, the implementation questions are worth discussing: What belongs in the publication gate? What would make a decision log auditable without exposing unnecessary information? And when is no publication the safer output?

Explore Lustro and find its volunteer signup path at ProjektLustro.eu. The available brief does not define the signup verification process, so I won’t guess at it here.