DEV Community: Marek Sowa

# A research link is not an evidence pipeline

Marek Sowa — Sun, 25 Oct 2026 01:38:20 +0000

A research link is not an evidence pipeline

If you work on a platform that surfaces research, the easy part is posting a title and a URL. The harder part is deciding what a reader can safely conclude from them.

Lustro points to a whitepaper titled “Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets.” It is authored by Jakub Sikora and published under the ProjektLustro.eu Open Research Initiative.

The title identifies a topic. It does not, by itself, establish the paper’s methods, findings, or the strength of its evidence. For an engineer sharing the work, that distinction matters: a polished summary can travel much farther than the qualifications behind it.

How I would evaluate it

I would start with the reading version and keep the PDF open for checking exact wording. Before repeating any conclusion, I would look for answers to four questions:

What is the unit of analysis? A document, a publication, a quoted passage, or something else? Similar-looking outputs can support very different claims.
How are cross-language comparisons justified? Translation, shared terms, and contextual similarity are not interchangeable. The paper’s definitions and examples matter more than the title.
What does temporal alignment mean in the analysis? A timing comparison needs a stated window and a reason for choosing it. Sequence alone should not be retold as causation.
What could the evidence miss? Source selection, incomplete archives, ambiguous matches, and editorial context can all affect interpretation. I would check which limitations the paper actually discusses rather than assume they were handled.

That is a reading checklist, not a description of methods or results claimed by the whitepaper. The links are the place to verify those details.

The trade-off in sharing early

A short post gets the work in front of people who may have useful technical objections. It also leaves too little room to substantiate a methodological claim. I would rather make the boundary visible than fill that space with an invented explanation of how Lustro works or a metric I cannot verify.

If you read the paper, a useful comment is specific: identify a definition, evidence choice, or limitation you think deserves scrutiny, and point to the passage that prompted it. That gives others something they can check rather than another summary to trust.

The ProjektLustro.eu site also has information about the initiative and volunteer signups.

# A research link is not an evidence pipeline

Marek Sowa — Sun, 25 Oct 2026 00:00:53 +0000

A research link is not an evidence pipeline

If you work on a platform that surfaces research, the easy part is posting a title and a URL. The harder part is deciding what a reader can safely conclude from them.

How I would evaluate it

I would start with the reading version and keep the PDF open for checking exact wording. Before repeating any conclusion, I would look for answers to four questions:

What is the unit of analysis? A document, a publication, a quoted passage, or something else? Similar-looking outputs can support very different claims.
How are cross-language comparisons justified? Translation, shared terms, and contextual similarity are not interchangeable. The paper’s definitions and examples matter more than the title.
What does temporal alignment mean in the analysis? A timing comparison needs a stated window and a reason for choosing it. Sequence alone should not be retold as causation.
What could the evidence miss? Source selection, incomplete archives, ambiguous matches, and editorial context can all affect interpretation. I would check which limitations the paper actually discusses rather than assume they were handled.

That is a reading checklist, not a description of methods or results claimed by the whitepaper. The links are the place to verify those details.

The trade-off in sharing early

The ProjektLustro.eu site also has information about the initiative and volunteer signups.

# From a research paper to an auditable response

Marek Sowa — Sat, 24 Oct 2026 00:00:28 +0000

From a research paper to an auditable response

The title of Jakub Sikora’s whitepaper, “Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets,” raises a question worth examining: how should researchers assess timing and information flow across languages and outlets without treating a temporal match as proof of coordination?

Sikora authored the paper, published under the ProjektLustro.eu Open Research Initiative. Read the paper or inspect the PDF. The title identifies the subject; it does not, by itself, establish a finding. Before citing a result, check what the paper defines as an observation, how it compares material across languages, what evidence supports each inference, and which limitations the author identifies. In particular, keep “appeared close in time” separate from any stronger claim about why it appeared.

That distinction matters for Lustro’s rapid-response program. Its response-selection workflow uses the disinformation-cluster feed as its sole source of truth, reviews clusters every six hours, and calls for immediate recalibration of high-risk cases. A cluster entering that workflow is a reason to inspect evidence, not permission to publish a conclusion.

A publishable response needs an evidence trail:

Preserve the source links used to assess the cluster.
Record the publication decision against four criteria: documented harm, audience, evidence quality, and spread potential.
Mark what is verified and what remains unknown. Choose a source-linked correction, a method-led prebunk, restrained satire where justified, or a documented decision not to publish.
Validate the channel-native draft before release. If its links or decision log cannot be retained, the format is not suitable.

A prebunk can explain a manipulation pattern and show readers how to verify material without reproducing an unverified claim. A correction should let readers follow its sources back to the evidence. Neither is a vehicle for political persuasion. If a draft repeats an unverified claim, makes an unsupported inference, or lacks a complete source record, the response should pause.

For researchers and journalists, the useful test is not whether a response sounds certain. It is whether its source path, unknowns, and publication decision remain inspectable as the cluster changes. Lustro’s program measures that discipline through preserved links and logs, documented response and non-publication decisions, use of source-linked responses, and observed changes in the reach and credibility of addressed disinformation.

People who want to support that documented public-interest work can use the ProjektLustro.eu site for the verified volunteer signup pathway, not to amplify a claim before it has been checked.

# From a research paper to an auditable response

Marek Sowa — Fri, 23 Oct 2026 00:00:21 +0000

From a research paper to an auditable response

A publishable response needs an evidence trail:

Preserve the source links used to assess the cluster.
Record the publication decision against four criteria: documented harm, audience, evidence quality, and spread potential.
Mark what is verified and what remains unknown. Choose a source-linked correction, a method-led prebunk, restrained satire where justified, or a documented decision not to publish.
Validate the channel-native draft before release. If its links or decision log cannot be retained, the format is not suitable.

People who want to support that documented public-interest work can use the ProjektLustro.eu site for the verified volunteer signup pathway, not to amplify a claim before it has been checked.

# A rapid-response loop needs an audit trail

Marek Sowa — Thu, 22 Oct 2026 00:00:04 +0000

A rapid-response loop needs an audit trail

A disinformation cluster can change faster than a team can review its last response. For platform and SRE engineers, that creates a familiar problem: how do you act quickly without losing the evidence and decisions behind each action?

Lustro’s campaign brief calls for a six-hour review cycle, with immediate reassessment of high-risk clusters. Each cluster is assessed for harm, audience, evidence quality, and spread potential. An intervention may be an evidence-backed correction, a prebunk, or restrained satire; an unverified claim should not be repeated to fill a gap.

The engineering trade-off is speed versus traceability. A six-hour cadence gives a team a regular point to reconsider priorities, but it cannot be the only trigger for a high-risk case. And a response that ships quickly is hard to evaluate later if its source links and decision log are missing. The brief calls for preserving both for every intervention.

That also sets a limit on what can be claimed about results. The campaign aims to reduce the reach and credibility of organized disinformation and track verified volunteer signups. Those are goals to measure, not outcomes established by this post.

For the research context, read “Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets” by Jakub Sikora, published under the ProjektLustro.eu Open Research Initiative. The PDF is also available. For the project and volunteer signups, visit ProjektLustro.eu.

The useful question for builders is not just how fast a response can go out. It is whether someone reviewing it later can tell what was known, what remained uncertain, and why that response was chosen.

# Treat disinformation like an incident, not a quote to debunk

Marek Sowa — Wed, 21 Oct 2026 00:00:12 +0000

Treat disinformation like an incident, not a quote to debunk

Anyone who has handled an incident knows the failure mode. A confident summary travels faster than the evidence behind it.

Disinformation makes that worse, because repeating the claim gives it another place to live. Even a correction does. So I would rather document the transmission path: where the material showed up, what changed as it moved, which sources back the assessment, and which apparent connections nobody has verified yet.

What the review would look like

Say a cluster shifted between review cycles. I wouldn't lead with the most alarming reading. Check the source trail first. Keep direct observations apart from things that look alike or happened at the same time. Write down why the cluster is worth answering at all. Then pick the smallest useful response: a correction with evidence behind it, a warning about the tactic, or nothing public yet.

That last option matters. Similar wording isn't proof of coordination, and a fast run of posts isn't proof of intent. An audit trail should put those limits in plain view instead of a footnote.

The trade-off

It's slower than posting a screenshot with a rebuttal, and the one-liners are worse. What it gives journalists, researchers and the public is something they can inspect without having to take in the original claim again.

My test is simple. Can someone follow the evidence trail and see the manipulation tactic without learning how to repeat the disinformation? If not, the documentation still needs work.

# Disinformation Needs an Incident Log, Not Just a Rebuttal

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

Disinformation Needs an Incident Log, Not Just a Rebuttal

A rebuttal answers a claim. An incident log answers a different question: why did we decide this was the right response, with the evidence available at the time?

That distinction matters when several posts carry similar wording, cite the same fragment of evidence, or appear close together. Those signals may justify a closer look. They do not, by themselves, prove coordination or make the underlying claim false.

For platform and SRE engineers, the useful analogy is alert correlation. A dedup key helps group events for review; it is not a root-cause finding. A correlation window helps decide what to inspect together; it is not evidence that the events share an operator. The same discipline should apply here.

What the log needs to record

A compact record could look like this:

Cluster ID: Stable identifier for related posts
Review window: When the posts were observed and next review is due
Claim summary: Neutral description, without republishing the claim
Source provenance: Originals inspected; copies, crops, and gaps noted
Assessment: Harm, evidence quality, audience, coordination
indicators, and spread potential
Decision: Correct, prebunk, or use restrained satire
Rationale: Why this mode; why the alternatives were rejected
Owner and status: Reviewer responsible; open, revisiting, or closed
Revisit trigger: New primary evidence, wider spread, or changed risk

The record should distinguish observed from inferred. “Two posts use similar wording” is an observation. “They were centrally directed” is an inference that needs more evidence. Preserve that distinction in the rationale, not just in a footnote.

An owner should revisit the record when its trigger fires and close it only with a documented reason. Retention should be set by an explicit policy that balances later audit against unnecessary storage of people’s posts; “keep everything forever” is not an incident-management strategy.

Work through a cluster

Suppose a reviewer sees several public posts making the same assertion about a public-service rule. They use similar phrasing within one review window and point to copies of a cropped image. This is a hypothetical exercise, not a reported incident.

The first pass is not a numerical score that pretends to know more than it does:

Dimension	Assessment	Reason
Harm	Potentially high	A reader could act on the assertion
Evidence quality	Low	The image’s original context is not yet available
Intended audience	Unclear	Public posts do not establish who was meant to see them
Coordination indicators	Present, unconfirmed	Shared phrasing and timing warrant review, not attribution
Spread potential	Unknown	The sample does not establish reach

The log should record which originals were inspected, where the cropped image first appeared if that can be established, and what remains missing. Similarity can act as a dedup key for investigation. It must not become a shortcut to “coordinated campaign.”

What should be published? Not a correction yet: without the original context or another reliable source, the reviewer cannot responsibly declare the assertion false. A restrained prebunk is possible if it stays at the level of method: explain why a cropped image is insufficient to establish a rule, and tell readers what kind of primary document would resolve the question. Do not repeat the unverified assertion to make the warning punchier.

If reliable primary evidence later resolves the factual claim, update the record and consider an evidence-backed correction that cites it. If the apparent cluster turns out to be unrelated copying, record that too. The log is there to make a changed judgment legible, not to defend the first one.

Budget for false positives

Fast review creates pressure to treat weak signals as conclusions. An incident process needs an explicit false-positive budget: what harm would a premature label cause, and what evidence threshold justifies publishing one?

That is also where the SRE analogy should stop short. Posts involve people, not failing services. A blameless review asks whether the evidence and decision process held up; it does not turn uncertainty into an accusation about authors or audiences. Satire has an even narrower role: use it only when it clarifies a tactic without repeating the claim or making an identifiable person the punchline.

A rebuttal may be the eventual output. The log is the work that makes it possible to explain why that output was warranted, and to change course when it was not.

# A correction needs a provenance trail

Marek Sowa — Mon, 19 Oct 2026 00:00:22 +0000

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.

# Making a disinformation cluster legible without spreading it

Marek Sowa — Sun, 18 Oct 2026 00:00:32 +0000

Making a disinformation cluster legible without spreading it

A correction can become another distribution channel for the claim it corrects.

That is the engineering problem I keep circling. If an organized narrative is moving across accounts, the useful output is not a louder copy of the falsehood with "false" stapled to it. It is a clear account of the mechanism: where the claim appeared, what evidence is missing, how it spread, what is still unknown.

I would treat this like incident triage, with one difference that breaks the analogy. Publishing the incident report can change the incident.

For each emerging cluster, the first pass should ask:

What harm could this cause, and who is likely to encounter it?
Which parts are supported by checkable sources?
Is there evidence of coordinated spread, or just similar wording?
Would quoting the claim help readers understand it, or hand it another audience?

A six-hour review cadence could keep that assessment current, with earlier reassessment when the risk changes. The decision log matters as much as the public explanation. Write down why a cluster got a correction, a prebunk, a lighter response, or nothing yet. Otherwise "we acted quickly" and "we guessed quickly" look identical from the outside.

The trade-off is speed against evidential restraint. Wait for perfect attribution and a claim goes unchallenged while it spreads. Publish a confident story about coordination on thin evidence and you have a different failure on your hands. Similar posts are a lead to investigate. They are not proof of shared control.

So the public version should be narrower than the internal analysis. Show the source trail and the evidence gap. Explain the tactic in plain language. Skip reproducing an unverified claim when a description will do.

None of this makes organized disinformation disappear. It can make the distribution path easier to inspect without volunteering to be part of it.

# Disinformation response is an incident workflow, not a posting contest

Marek Sowa — Sat, 17 Oct 2026 00:00:35 +0000

Disinformation response is an incident workflow, not a posting contest

A false claim can travel faster than a careful correction. That doesn't mean the correction should be louder. It means the work before you hit publish matters more.

When a suspicious claim lands in a community channel I help moderate, I'd start with three questions. What exactly is being claimed? What evidence would confirm it, or kill it? And would repeating it in a response just hand it more reach?

Platform engineers already know this shape. An alert is not an incident report. A cluster of similar messages is not proof of coordination. A confident dashboard label is not evidence.

Show the decision path

For each claim worth addressing, I'd want a small, reviewable record:

The original claim and where it appeared.
The sources checked, including anything that contradicts the proposed correction.
What is verified, what remains uncertain, and why a public response is warranted.
The response chosen: a factual correction, an explanation of the manipulation pattern, or no response yet.

That last option matters. Publishing on a fixed cadence keeps a team attentive, and it also turns weak evidence into a deadline-driven post. High-risk claims deserve faster review. Low-confidence ones may deserve silence until the record improves.

The response should make the evidence easier to inspect than the claim is to repeat. Quote only what you need. Name the tactic early when you can identify it. If a factual assertion is false, show the check plainly instead of piling on more rhetoric.

The trade-off I would accept

This is slower than firing back at every post. It will miss conversations, and a visible correction won't convince everyone who saw the original claim.

But the alternative, more volume with less provenance, makes its own noise. The useful engineering question isn't "Did we publish enough?" It's "Could someone outside the response team reproduce the reasoning and spot where we got it wrong?"

Organized disinformation loses some of its advantage when its tactics get named early and its claims meet a visible evidence trail. Not because a clever reply wins the internet. Because the next person has something solid to check.

# A viral claim is not an incident report

Marek Sowa — Fri, 16 Oct 2026 00:00:25 +0000

A viral claim is not an incident report

When the same claim appears in several communities over one afternoon, people often fold two questions into one:

Is the claim supported?
How is it being distributed?

The second matters, but it cannot answer the first. Repetition can make an assertion seem documented even when every post leads back to one screenshot.

For developers, this is less a debate to win than an incident to triage. Preserve the artifacts. Separate observations from inferences. Write down what would change the assessment.

Start with an evidence ledger

Before drafting a correction, reduce the case to five fields:

Assertion: What, exactly, is being claimed?
Provenance: Where did the cited evidence originate?
Confidence: Which parts can be checked, and which remain uncertain?
Distribution: Where and when did the wording appear?
Disconfirmation: What evidence would contradict or resolve the claim?

“Many accounts posted this” belongs under Distribution, not Confidence. A screenshot with no accessible source belongs under Provenance, with the gap marked. Neither is proof.

The last entry is often the most useful. If no one can name the evidence that would settle the matter, the response may become one more assertion competing for attention.

Treat the source chain like a dependency graph

A post cites an article. The article cites an unnamed source. Ten other posts cite the article. That can look like eleven pieces of support. It is actually one unverified attribution and ten references to it.

Follow each citation toward the primary material. Note where the chain ends. If a screenshot is cropped, ask what the full document shows. If a quote is translated, keep the original separate from the translation. If the primary source is unavailable, say so.

That does not prove the claim false. It tells readers why it is still unverified.

Analyze spread without inventing a coordinator

Timestamps, repeated wording, and reposts across communities are worth checking. They can show how a claim traveled and whether posts that look separate depend on the same source.

They cannot, on their own, establish who directed the activity or why anyone shared it. People copy phrasing for mundane reasons. Keep observed distribution and attributed intent in separate columns.

Choose the smallest response the evidence supports

A factual correction should identify the unsupported assertion and name the evidence needed to resolve it. “Be critical of what you read” gives readers no test to run.

If repeating the claim is unsafe, explain the reusable pattern instead: an anonymous attribution, a selectively cropped image, or citations that all end at one unsupported source. That is a prebunk without giving the original assertion another clean distribution channel.

Satire has a narrower job. It may expose a contradiction, but it fails if readers remember the false claim better than the evidence gap.

Reassess before repeating

Fast-moving cases need short review cycles. At each pass, check the potential harm, who is likely to encounter the claim, the available evidence, and whether its spread has changed. A six-hour reassessment is a reasonable discipline for a live response. It is not a license to publish every six hours.

Stop conditions matter more than a posting schedule. If the claim cannot be described without amplifying a harmful falsehood, stop. If the planned wording has no reliable documentation behind it, stop. If a moderator flags the approach, revise or stop instead of pushing harder.

The goal is not a louder counter-narrative. Make the claim’s evidence, gaps, and route through the network clear while readers can still pause before passing it on.

# When does a cross-language pattern become evidence?

Marek Sowa — Thu, 15 Oct 2026 00:00:35 +0000

When does a cross-language pattern become evidence?

A Polish outlet and Russian state media may cover the same event. Similar wording or close publication times could be worth investigating, but neither alone establishes that information moved from one to the other. For developers used to inspecting pipelines, the useful question is not “does this look coordinated?” It is “what observations, transformations, and assumptions would support that interpretation?”

That is why I’m pointing to Lustro’s whitepaper, “Cross-Lingual Information Diffusion and Temporal Alignment: Russian State Media and Polish Outlets.” It is authored by Jakub Sikora and published under the ProjektLustro.eu Open Research Initiative. I’m sharing the work as a community advocate, not as its author.

The title identifies a concrete research problem: comparing material across languages and time. It also gives technically minded readers several ways to scrutinize a proposed method:

Scope: Which outlets, documents, and periods are included? What would change if the selection changed?
Cross-language comparison: How are related items identified when wording differs? How are translation ambiguity and shared source material handled?
Time: Which timestamp is being compared, and how are updates or republications treated?
Interpretation: What distinguishes an observed sequence from a claim about influence? Which alternative explanations remain plausible?

These are questions to bring to the paper, not claims that it answers each one in a particular way. That distinction matters. A temporal match can motivate closer examination without proving a direction of diffusion; a cross-language match can identify material to inspect without becoming a fact-checking verdict. The value of an inspectable method is that readers can argue about its choices and limits rather than trade confident conclusions.

Read the whitepaper and bring a specific methodological question to the discussion: https://jakub.team/whitepapers/lustro-cross-lingual-diffusion/

The PDF is here: https://jakub.team/papers/lustro-cross-lingual-diffusion.pdf

If the research interests you and you’re considering volunteering, the project site is https://projektlustro.eu.

Publication note: An English Dev.to post is already queued. Check that queued copy before publishing this replacement; do not publish it as a second post.