DEV Community: Marek Sowa

# Reading Lustro as an evidence pipeline, not a similarity score

Marek Sowa — Wed, 14 Oct 2026 00:00:22 +0000

Reading Lustro as an evidence pipeline, not a similarity score

I found Lustro while looking into research on antidisinformation clusters. One question kept me reading: if a story appears in Russian state media and later in a Polish outlet, what evidence would show how it got there?

Jakub Sikora’s whitepaper, Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets, is published under the ProjektLustro.eu Open Research Initiative. It looks at more than whether texts resemble each other across languages. Publication timing matters too, as does the evidence for a possible connection.

Similarity is a starting point

Cross-lingual similarity can turn up candidates. It cannot, on its own, tell you where a story came from. Two articles might cover the same event without either copying the other, and translation or paraphrase makes the comparison harder.

I’d want a pipeline to keep four questions separate:

Do the texts make the same specific claims?
Is there an explicit citation or other evidence of a source path?
Does the publication order support that path?
What is still uncertain after those checks?

This matters for engineers too. Fold candidate retrieval and source attribution into a single “match,” and the result may sound firmer than the evidence is. Timing can narrow the possibilities. It cannot prove intent or coordination.

I’d start with the reading version of the whitepaper to see the method and its limits, rather than treating a cluster as a verdict. The ProjektLustro.eu site is the project landing page.

I’m sharing the work, not claiming I built or independently reproduced it. Finding related content is one job. Showing how information moved is another.

# A rapid-response program needs an evidence trail

Marek Sowa — Tue, 13 Oct 2026 00:00:43 +0000

A rapid-response program needs an evidence trail

When a public-facing system is under pressure, speed is only useful if the team can trace what informed a decision. That is the operating principle behind Lustro’s permanent social-media rapid-response program.

The program uses its disinformation-cluster feed as its sole source of truth. Clusters are reviewed every six hours; high-risk cases need immediate recalibration. For every response, the team preserves source links and a decision log.

That discipline matters when choosing what to publish. A correction, prebunk, or piece of restrained satire is selected using documented harm, audience, evidence quality, and spread potential, not engagement alone. The boundary is equally important: responses must not repeat unverified claims or conduct political persuasion.

Publication is another reliability check. Drafts must be native to their channels and meet each platform’s length and validation requirements before they go live. A response without a preserved, reviewable source link and decision record does not pass.

The intended outcomes are reduced reach and credibility of organized disinformation, where those effects can be measured, and verified volunteer signups. The program also tracks the share of published responses with preserved source links and decision logs. Those are measures to assess, not results to assume.

For engineers and builders accustomed to incident response, the useful question is whether a fast public response remains traceable under pressure. Lustro’s model puts that question at the center of the work.

Related research: Jakub Sikora authored “Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets”, published under the ProjektLustro.eu Open Research Initiative. Learn more about the project or volunteer at ProjektLustro.eu.

# Treat Disinformation Like an Incident, Not a Quote

Marek Sowa — Mon, 12 Oct 2026 00:00:11 +0000

Treat Disinformation Like an Incident, Not a Quote

When an incident report is useful, it does more than say “something went wrong.” It separates what was observed from what was inferred, shows the evidence, and explains the mechanism. I think documented disinformation deserves the same discipline.

The tempting response is to lead with the false claim and then rebut it. I would start elsewhere: with the evidence trail. What can be verified? Which details remain uncertain? If several posts appear connected, what supports that assessment, and what would weaken it? Readers should be able to inspect the reasoning without being asked to trust a verdict.

The next step is to name the tactic rather than make the underlying claim the headline. Is the material stripping away context, borrowing an authority it has not earned, or presenting repetition as independent confirmation? Explaining that mechanism gives readers something specific to examine without restating an unverified allegation.

There is a trade-off here. A response that avoids repeating the claim may be less immediately recognizable to someone who has already seen it. The answer is not to hide the subject; it is to provide enough context to identify what is being assessed while keeping the claim out of the spotlight.

For platform engineers and indie builders, the principle should feel familiar: make the decision traceable. Keep the observations, uncertainty, and reasoning distinct. Documented disinformation loses power when its evidence trail, manipulation tactics, and coordinated spread are made clear, without making the underlying claim the centerpiece.

# Documented disinformation loses power when the pattern is visible

Marek Sowa — Sun, 11 Oct 2026 00:00:43 +0000

Documented disinformation loses power when the pattern is visible

A correction can be accurate and still come too late. It can also repeat the original claim to people who never saw it.

For engineers, the problem is not only whether a sentence is false. It is whether people can trace that sentence: where it appeared, what evidence it cites, how it changed between posts, and whether several accounts use the same framing. That keeps documentation from becoming another form of distribution.

What the workflow needs to preserve

Each cluster of related posts should be treated as a case with an audit trail, not as a text-classification result. Keep the original sources, publication times, citations, later versions, and notes on what is still unverified.

Then triage the case. Harm, evidence quality, audience, signs of coordination, and likely spread all matter, but they answer separate questions. Similar wording can warrant a closer look. It does not prove coordination on its own. A missing citation should be flagged, but it does not automatically make a claim false.

The response should match the evidence:

Correct a factual claim when the sources support a clear correction.
Explain the manipulation pattern before it spreads further when the pattern is clearer than the facts behind the claim.
Use satire sparingly, only when it exposes the tactic without giving the claim another outing.

Sometimes the right response is to keep investigating. That is not a failure. Publishing a confident explanation with weak provenance is.

The engineering trade-off

Speed matters. A clear explanation has less use once a misleading frame has been copied everywhere. But a fast response without decision logs and source provenance is just another assertion people must take on trust.

The goal is not a dashboard that says "disinformation detected." It is a record others can inspect: this was observed, this evidence is missing, this is why the posts were grouped, and this is why this response was chosen.

Documentation can reduce the power of a misleading claim by making the mechanism visible without repeating the claim more loudly.

# Reading cross-lingual information research without losing the source trail

Marek Sowa — Sat, 10 Oct 2026 00:00:10 +0000

Reading cross-lingual information research without losing the source trail

A claim can appear in more than one language and at more than one time. That does not, by itself, tell us whether one outlet followed another, whether the accounts describe the same event, or whether either account is accurate. For developers building research or response tools, those are separate questions, and each needs an inspectable evidence trail.

Jakub Sikora’s whitepaper, “Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets,” is published under the ProjektLustro.eu Open Research Initiative. Read the whitepaper or the PDF.

A technical reading guide

The title identifies the subject, but it is not a substitute for the paper’s method or results. When reading it, I would keep four questions distinct:

What is being compared? Identify the sources, languages, and units of analysis the paper actually defines. Do not assume that similar wording establishes a shared origin.
How is time handled? Check what timestamps represent and how the analysis aligns material across outlets. Publication order alone should not be treated as proof of influence.
What supports a connection? Separate an observed correspondence from an inferred path of diffusion. Look for the evidence the paper provides for each.
Where are the limits? Note which cases the paper covers, which uncertainties it acknowledges, and which conclusions its evidence does not support.

Those are questions to take to the whitepaper, not claims about answers it reaches. The links above are the source for its scope, method, findings, and limitations.

From reading to an operational response

Lustro’s response workflow has a different job from the whitepaper: assess documented disinformation clusters without turning an uncertain observation into a public claim. On a rolling six-hour cadence, the workflow ingests current clusters and classifies each by harm, audience, evidence quality, and spread potential. A high-risk cluster calls for immediate recalibration rather than waiting for the next routine cycle.

That classification should inform the response choice. A source-linked correction may be appropriate when the record supports one. A prebunk can explain a manipulation pattern without repeating the unverified claim that uses it. Restrained satire is an option only when it remains clearly distinct from political persuasion. Sometimes the right decision is to monitor rather than amplify. In every case, the published response must retain the source links behind its assessment and a decision log explaining the choice.

For a developer implementing that workflow, the useful distinction is between what the record contains and what the system decides to publish. A compact response should make its evidence and uncertainty visible; an internal decision record should preserve the classification, response choice, and reason for any high-risk recalibration. Neither should turn a missing source or an inference into an established fact.

That discipline matters to researchers, practitioners, journalists, officials, and EU/PL readers for different reasons, but the shared requirement is the same: fast context must remain checkable. If a format requires repeating an unverified claim, dropping its source trail, or implying more certainty than the record supports, it should not be published.

Lustro’s project site and verified volunteer signup entry point is ProjektLustro.eu.

Making a disinformation cluster legible is an engineering problem

Marek Sowa — Fri, 09 Oct 2026 00:00:35 +0000

Making a disinformation cluster legible is an engineering problem

A correction can be accurate and still send a false claim through another round of distribution. That's the awkward part. You need enough detail to explain what happened, without turning the explanation into a cleaner version of the original claim.

The useful unit of work is the cluster, not the individual post. A post tells you what one account said. A cluster shows whether the same narrative appears across accounts, languages, and formats, and where the apparent connection still needs verification.

What the workflow needs

Start with a rolling intake of new and changed clusters. A six-hour review cycle is reasonable for routine assessment, but high-risk changes should not wait for the next batch. Each review should record five separate judgments: potential harm, evidence quality, likely audience, spread potential, and the risk that a response will amplify the claim.

Do not collapse those judgments into one opaque score. "Spreading quickly" is not the same as "well evidenced." Similar wording is not the same as coordinated activity, either. The latter needs stronger evidence than a cluster view can provide.

Then pick the smallest response that does the job:

A correction when the evidence supports a specific factual answer.
A prebunk when the tactic is clearer than the underlying claim.
Sometimes restrained satire, when it exposes the tactic without making the falsehood more memorable.

The public explanation can be short. The working record should be detailed. Keep source citations, note what was checked, and log why that response was chosen. Otherwise, the next reviewer gets a polished conclusion with no way to audit it.

There is a trade-off. Publishing fast helps while a narrative is moving. Publishing fast with weak provenance creates another unreliable node in the network. I would rather see a narrow, well-supported explanation than a confident thread that outruns its evidence.

Organized disinformation does not become harmless because someone labels it. It has less room to operate when people can quickly see the tactic, the evidence gap, and the path of spread, without having to read the false claim all over again.

# Treat a disinformation response like an incident record

Marek Sowa — Thu, 08 Oct 2026 00:00:39 +0000

Treat a disinformation response like an incident record

When an organized claim starts spreading, speed matters. So does the ability to show why a response says what it says.

As community members, we think organized disinformation loses power when its tactics are named early, its claims are checked visibly, and the public gets clear evidence rather than more noise. For platform and SRE engineers, that suggests a useful way to frame the work: not as a race to publish rebuttals, but as an incident workflow that someone else can inspect.

The first step is to separate the claim from the tactic. What, exactly, is being asserted? What evidence would confirm or refute it? Is the material asking readers to accept an unverifiable assertion, or using urgency, repetition, or misleading context to push them toward one? Naming a tactic should not become a substitute for checking the claim.

Next, make the decision trail visible. A response record could state the claim being addressed, the sources checked, what those sources establish, what remains uncertain, and why this response format was chosen. A verifiable falsehood may call for a direct correction. An emerging manipulation pattern may be better addressed by explaining what to watch for without restating the claim. If a joke would give the claim another round of attention, skip the joke.

This approach has costs. Checking takes time. Publishing uncertainty can feel less satisfying than delivering a sharp verdict. Keeping a decision record is extra work, especially when a story changes. We think those costs are worth accepting: they make it possible to correct the response itself when new evidence appears.

The practical test is whether a reader can follow the evidence without having to trust the person posting. That is the standard we would want for our own work, and the one we would ask of any public counter-narrative. In our view, an auditable path is worth more than a larger pile of rebuttals.

# A Disinformation Cluster Is an Incident, Not a Dashboard Spike

Marek Sowa — Wed, 07 Oct 2026 00:00:01 +0000

A Disinformation Cluster Is an Incident, Not a Dashboard Spike

Organized disinformation works by making coordinated falsehoods feel normal. The engineering challenge is to make the coordination visible without presenting suspicion as proof, and to make the evidence understandable without repeating the falsehood more loudly than the correction.

If I were building a cluster-review workflow, I would borrow more from incident response than from a trending-topics dashboard. A spike tells you where to look. It does not tell you what happened.

Start with a reviewable record

For each suspected cluster, I would keep a record with fields like these:

Core claim: Neutral description, not a headline repeating the claim
Affected audience: Who is likely to encounter or act on it
Sources: Saved items and their publication times
Evidence: What each source supports or contradicts
Signals: Observable similarities in wording, timing, or distribution
Alternatives: Plausible explanations for those similarities
Risk: Potential harm and urgency if the claim spreads
Status: Unreviewed, under review, supported, inconclusive, or retired

The distinction between evidence and signals matters. Similar wording is a reason to inspect two posts together. A shared document, an attributable instruction, or another independently checkable record would be a different kind of evidence. The record should say which is which.

Build an evidence chain, not a cluster label

Consider a hypothetical case: several posts in different languages make the same factual assertion within a short period. A useful review would proceed in stages:

Save the posts and publication times so the observation can be checked later.
Write a neutral version of the assertion, then identify the primary source that could verify it.
Compare wording, sequence, and cited material across the posts.
Record what those comparisons actually show, and what else might explain them, such as a shared news source.
Have a reviewer decide whether the public needs a correction, an early explanation of the emerging narrative, or no post yet.

That chain might support a conclusion that the posts carry the same unsupported assertion. It would not, without further evidence, justify calling their publishers a coordinated group. The conclusion should never outrun the weakest link in the chain.

Make uncertainty an output

I would require every review to answer three questions before publishing:

What can a reader verify from the evidence we have?
What remains an inference?
What new evidence would change our assessment?

Those answers belong in the public explanation, not just an internal note. “These posts use similar wording” is clearer and more defensible than “we caught a network” when authorship and coordination remain unresolved.

A six-hour review cadence could help catch changes in an active cluster, but cadence is a trade-off, not a credibility guarantee. Each pass should check whether the claim, evidence, audience, or risk has changed. Stale messaging should be retired; high-risk claims should go to a human reviewer rather than being promoted by an automatic threshold.

Publish the factual frame first

A correction should open with what is established, then show how to check it. A prebunk can explain a recognizable manipulation pattern before an emerging claim takes hold. Satire is a poor substitute for either: if it obscures the evidence or makes the affected audience the joke, it works against the goal.

Volunteers can help review evidence, translate context, monitor changes, and verify sources. Give them bounded questions and a way to report uncertainty. Do not ask them to turn a resemblance into an accusation.

The point is not to produce a more confident dashboard. It is to leave a trail another person can inspect, challenge, and correct. That is how we make coordination visible, evidence understandable, and the public harder to manipulate.

# A six-hour review loop only matters if the evidence survives publication

Marek Sowa — Tue, 06 Oct 2026 00:00:15 +0000

A six-hour review loop only matters if the evidence survives publication

Lustro's rapid-response plan uses a disinformation-cluster feed reviewed every six hours. High-risk cases are recalibrated right away. The engineering problem is what happens between that review and a social post.

A correction can arrive on time and still fail. Source links can disappear. Its reasoning can become impossible to check. Or the draft can repeat the unverified claim it was meant to address. A character limit does not excuse any of that.

I found Lustro through research published by ProjektLustro.eu. Jakub Sikora's whitepaper, "Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets", provides the research context. The rapid-response process described here is a program plan, not a claim that results have already been measured.

Treat drafts as evidence handoffs

For each cluster, the plan calls for a documented choice based on harm, audience, evidence quality, and spread potential. The response may be a correction, a prebunk, or restrained satire. The decision log should include that choice and preserved source links.

Different readers need this for the same basic reason. Researchers need to inspect the evidence and the decision. Journalists need an attributable correction they can verify before using it. People who see the post need a clear explanation that does not make them read the unverified claim again.

The line is clear. Lustro is not an automated verdict engine or a political persuasion campaign. It should not publish a claim-specific item if it cannot preserve the sources and decision log.

A reproducible pre-publication checklist

For a channel-native draft, I would check these points before publishing:

Trace the input. Does the draft refer to a cluster from the Lustro feed rather than an unsourced social post?
Record the decision. Are harm, intended audience, evidence quality, spread potential, and the selected response type documented?
Keep the evidence reachable. Are source links preserved, and can readers find the matching decision log?
Check for amplification. Does the draft repeat or materially amplify an unverified claim? If so, pause it. A prebunk can describe observable manipulation patterns without naming a live rumor.
Validate the channel version. Does the draft meet the platform's length and other publication requirements without dropping the evidence trail or changing its meaning?
Check the format's history. If removals, locks, or rule conflicts keep happening and moderator-approved adaptation cannot fix them, stop using that format.

This is a draft-review method, not a claim about an existing software pipeline. It makes failure states visible. "We had a source somewhere" is not source preservation. "We discussed it" is not a decision log.

What would count as evidence that it works?

The plan calls for counting approved responses with complete source links and decision logs. It calls for tracking high-risk review and recalibration against the six-hour cadence, and assessing documented changes in the reach and credibility of organized disinformation. It also counts verified volunteer signups, not incomplete submissions.

Those are evaluation targets, not reported results. The open methodological questions matter: how are reach and credibility assessed? How are decisions audited when a draft is paused? Public-interest responses need to be inspectable, not merely fast.

The project site and volunteer pathway are at https://projektlustro.eu.

# A disinformation feed needs a decision log, not just a fast response

Marek Sowa — Mon, 05 Oct 2026 00:00:18 +0000

A disinformation feed needs a decision log, not just a fast response

I came across Lustro while looking for ways to make disinformation-cluster research checkable. Posting quickly is the easy part. The harder work is deciding what the evidence supports, keeping that evidence attached to the response, and knowing when to say nothing yet.

The operator brief describes a permanent program centered on the Projekt Lustro feed. It calls for clusters to be reassessed every six hours, with immediate recalibration in high-risk cases. Before choosing a correction, a prebunk, or restrained satire, the feed is meant to weigh harm, audience, evidence quality, and potential spread.

That is more than a posting schedule.

The six-hour cycle only helps if the evidence survives the handoff. Each response needs its source links and a decision log showing what was documented, why that response was chosen, and what remains uncertain. Without those, a quick correction risks becoming another unsupported claim in the feed. The brief sets two clear limits: do not repeat unverified claims, and do not target political persuasion.

Speed matters. So does confidence. Some clusters may need an immediate response; others may not support a public claim yet. I would rather see that distinction stated plainly than read a polished counter-narrative that has outrun its sources.

For the research context, start with Jakub Sikora's whitepaper, "Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets", published under the ProjektLustro.eu Open Research Initiative. The project site is the landing page and includes volunteer signups.

When I read a response from the feed, I want to know whether I can follow its sources, tell a documented claim from an interpretation, and see why that intervention was chosen. If I can't, it needs more work, no matter how fast it arrived.

# Lustro: a fast disinformation feed still needs an evidence trail

Marek Sowa — Sun, 04 Oct 2026 00:00:15 +0000

Lustro: a fast disinformation feed still needs an evidence trail

Refreshing a feed every six hours sounds like an engineering task. For a feed tracking disinformation clusters, it also means deciding what the evidence supports. Which clusters warrant a public response? Which need more review?

That question is what interests me about Lustro. The ProjektLustro.eu site describes a public-interest effort to turn documented disinformation clusters into clear social posts backed by evidence. Its research context is Jakub Sikora’s whitepaper, “Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets”, published under ProjektLustro.eu.

Decide before posting

The stated approach starts with the Lustro feed as the source of truth. Each cluster is then classified by harm, audience, evidence quality and spread potential. After that comes the choice of response: a correction, a prebunk or restrained satire.

The order matters. Repeat an unverified claim too quickly and you may give it another route to readers. Leave out source links or a decision log, and the response becomes harder to audit if the evidence changes.

The program calls for rolling analysis and messaging updates every six hours, plus immediate recalibration for high-risk clusters. That is an operating plan, not proof that every cluster can be assessed well in six hours. Anyone who has run an incident process knows the tension: speed helps, but you still need a record of what was known when the decision was made.

Lustro aims to reduce the reach and credibility of organized disinformation and invite aligned readers to become verified volunteers. Neither goal is a measured outcome. I would look at the linked sources, the decisions made from them and whether the team can correct a post when the evidence shifts.

# Lustro: a disinformation feed needs an evidence trail

Marek Sowa — Sat, 03 Oct 2026 00:00:43 +0000

Lustro: a disinformation feed needs an evidence trail

A cluster of similar posts is a lead. It isn't proof of a coordinated campaign.

That distinction drew me to Lustro. ProjektLustro.eu describes a disinformation-cluster feed intended to support public responses backed by evidence. Finding related material is one task. Deciding what the evidence lets you say about it is harder.

Before treating any cluster as a story, I'd read Jakub Sikora's whitepaper, "Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets". It's published under the ProjektLustro.eu Open Research Initiative and is also available as a PDF.

Where the line is

The stated response plan calls for classifying clusters by harm, audience, evidence quality, and spread potential. From there, the choice is a correction, a prebunk, or restrained satire. Every response should have source links and a decision log.

Without that trail, a quick correction risks becoming another unattributed claim in the feed. Similarity is a reason to investigate. It isn't a basis for asserting intent or coordination.

The plan sets a rolling six-hour review cadence and immediate recalibration for high-risk clusters. That's an operating target, not a performance result. The evidence check still has to fit inside the loop.

I haven't seen enough to say the feed reduces disinformation reach or credibility. I'd first look at individual responses: can you inspect their sources, uncertainty, and decisions? For engineers, journalists, and researchers, that's more useful than a confident dashboard number.

The Lustro project site is the entry point and has a volunteer signup.