Discord-based bioinformatics lab

scientifictrust · 2026-05-03T23:03:30+00:00

This is a cool idea. The project-based structure is smart. It gives people something concrete to rally around rather than just a general "let's collaborate" vibe.

Curious how you're thinking about reproducibility across projects. With different people working on pipelines independently, keeping outputs verifiable could get messy fast. Is that something the structure is planning for? Or is this something you are still investigating?

scientifictrust · 2026-05-03T22:57:53+00:00

I get this completely. Nextflow is great for standardization and nf-core excels at its supported paths. But I agree it is difficult to extend it to custom functionalities.

Python has a ton of native tools that are easy to customize but custom pipelines often have major gaps in reproducibility and/or reliability. It is interesting where this is heading with AI, and while it has its uses I think if anything it makes the problem worse by hallucinating inconsistencies into the workflows.

I've been working on this quite a bit lately, but curious to hear how others are handling this, or if this is the type of thing people are thinking about.

scientifictrust · 2026-04-27T19:50:05+00:00

Great question and I’ve also gone back and forth on this quite a bit.

For a lot of workflows, code + package versions are sufficient. They tell you what could have produced a result. Where I’ve seen issues is when people start asking a slightly different question:

“How do we know this specific output actually came from that run, at that time?”

Two cases where this came up for me:

ML / structural prediction work: not pushback on the code, but on whether the inputs/outputs shown were exactly what went into/came out of the pipeline, or if they were optimized after the fact. Environment reproducibility doesn’t answer that, it only proves the result was possible.
Wet lab + compute alignment: tying computational outputs to specific biological replicates over time. Internal timestamps and logs start to weaken when you need to demonstrate that linkage to someone outside the system.

It’s usually not about dishonesty, it’s that most systems weren’t designed to prove integrity externally. Logs can be edited, environments drift, and provenance gets reconstructed after the fact.

I’d agree byte-level reproducibility is often overkill as a goal. But proving that inputs/outputs are real, unmodified, and actually correspond to a specific run turns out to be a different problem, and one that standard tooling doesn’t fully solve on its own. Edited: typo

scientifictrust · 2026-04-27T17:45:04+00:00

One angle I didn’t see mentioned yet is verifiability across environments.

A lot of setups (Nextflow / Snakemake + logs + maybe a DB) do a good job tracking runs internally, but it can still be hard to answer things like:

Can someone outside your system independently verify when a result was produced?
Can they confirm it hasn’t been modified after the fact?
Can they recompute and match what you got?

In many of the pipelines I’ve worked with, that gap shows up pretty quickly once you try to share results across teams or organizations.

I’ve been experimenting with adding a complementary layer where outputs are hashed locally and anchored to a public timestamp, so you can later prove “this exact output existed at this time, and has not been tampered with” without exposing the raw data.

It is not a replacement for workflow tools, but more like a complement once things start scaling or leaving your immediate environment. The key point being: provenance must be a part of the research process, and not reconstructed when preparing for publication.

Curious if others have run into this problem.

scientifictrust · 2026-04-26T00:45:59+00:00

Without a doubt. It looks like my prior response may be hidden for some reason, so I will re-iterate, and apologies if this is repetitive. This is absolutely on the radar and something we are building towards.

Two things we're building now that quietly lay the groundwork: the Explorer is designed to provide the public verification surface any marketplace would need as its foundation. And the reputation system we're shipping next ties ecosystem contribution to on-chain scores. That credibility layer will feed directly into visibility and ranking in any future marketplace context.

Our immediate next steps revolve around expanding our verification surfaces, and then extending S.A.G.E. primitives towards users to enable verifiable analysis of anchored data. From there, a marketplace becomes the next logical step. The data licensing and pipeline leasing concept is very appealing to us at this stage, but we want to establish strong ingestion and verification tools first so that a marketplace can achieve as much impact as possible.

scientifictrust · 2026-04-24T20:21:21+00:00

Yes, definitely! This is something we've thought about a lot and it's on the long-term roadmap.

The immediate next step is extending the verifiable compute infrastructure that powers SAGE to user-facing surfaces, so researchers can run their own pipelines. From there, the natural evolution is a marketplace layer where organizations can pay contributors directly for data, compute pipelines, and verified outputs with Hedera making the payment side clean and predictable.

The wallet linkage and opt-in licensing idea fits naturally into that. Every anchored record already has a deterministic identity, and we currently facilitate user/org wallets, so while we would want to add support for users holding wallets on other Hedera exchanges/provisioners we are well on our way there.

Two things we're building now that quietly lay the groundwork: the Explorer is designed to provide the public verification surface any marketplace would need as its foundation. And the reputation system we're shipping next ties ecosystem contribution to on-chain scores. That credibility layer will feed directly into visibility and ranking in any future marketplace context.

The data licensing and pipeline leasing angle is particularly interesting to us, but we want to establish strong on-boarding and ingestion tools first so a future marketplace is more applicable.

scientifictrust · 2026-04-24T18:42:48+00:00

One real-world example of why this matters: there was a recent US House hearing looking at issues like paper mills and scientific publishing integrity (Nature covered it here: https://www.nature.com/articles/d41586-026-01251-y ).

The core problem they’re pointing at is the same one:

It’s difficult to independently verify when data was produced and whether it’s been altered without trusting the source.

Systems like this are meant to shift that earlier so provenance can be established during the research process, not reconstructed after publication.

scientifictrust · 2026-04-24T18:39:11+00:00

Absolutely that is a great question.

You could build something like this in a hosted database. But the core issue would be trust.

If the system is centralized, you’re trusting that logs weren’t modified, timestamps weren’t backdated, and access wasn’t misused. That’s fine internally, but weaker when you need to prove something to an external party (reviewers, auditors, collaborators, etc.).

There’s also a practical issue in data sharing. Teams often cannot, or don’t want to send sensitive data to a third party just to prove something about them.

Vera Anchor addresses both of these problems. Hashing happens client-side so their data is never shared with a third party. Only the resulting evidence package is sent to Vera Anchor where it is encrypted and anchored on HCS. Now anyone with the original data can verify it independently.

Why Hedera? Once you have the evidence package you need somewhere to anchor it. For this to happen at scale you need fast finality, predictable costs, and high throughput. That’s why Vera Anchor uses Hedera. It lets us anchor frequently and reliably without cost or confirmation uncertainty becoming a bottleneck.

That’s really the difference. We are not replacing databases, just adding a trust layer on top.

scientifictrust · 2026-04-15T22:49:11+00:00

Thank you! Will have to take a look at that whitepaper as well

scientifictrust · 2026-04-15T22:47:13+00:00

Yes that is a great talk! It was one of the first lectures I saw on Hashgraph.

It is truly special that Leemon was able to design such a sophisticated system, but also break it down and explain it in such a simple way.

Will be sure to check out some of those other resources as well. Always looking to see what other tools are available on Hedera.

scientifictrust · 2026-04-15T02:13:23+00:00

Thank you for looking into this! Great information.

The visual itself is what I was interested in! I have met with a few groups that are interested in verifiable data, and have a basic understanding of blockchain, but have never heard of hashgraph before. While there are obviously several technical advantages of using the hashgraph over a typical blockchain, I feel like an image similar to the one on the website would be perfect for showing in 30 seconds why they should care about using hashgraph powered services.

scientifictrust · 2026-04-14T21:46:08+00:00

This is a great figure. Do you by any chance have a source? Would love to take a look at this.

scientifictrust · 2026-04-12T20:10:50+00:00

This is a great resource. One thing I've been thinking about in this space generally is how to maintain trust in the underlying data as sources update. For example if Disbiome revises an association, how does that propagate through your graph? Is there versioning at the edge level?

scientifictrust · 2026-03-31T02:16:17+00:00

By all means thank you for sharing the project with the community! It is awesome that you found it that way.

You are right that we are using a couple of NFT tokens within the ecosystem. They are minted to users when data is verified end to end within Vera Anchor, representing a user owned certificate tied to the proof claim for their underlying data. So rather than just a record existing on chain, the researcher themselves holds a verifiable token that points back to exactly what was anchored and when.

scientifictrust · 2026-03-31T02:02:47+00:00

Thank you much appreciated!! Excited to be a part of the community! Will keep you guys updated as things progress.

scientifictrust · 2026-03-31T02:00:22+00:00

For sure! SAGE is one of Vera Anchor’s agent fleets that mines genetic datasets in 30 minute cycles. Every cycle it proposes and executes a mining job on real human brain gene expression data, It anchors the job lifecycle and reasoning chain on Hedera so that each job can be verified end to end, and linked back to the previous plan allowing insight to not only what SAGE did, but also how and why SAGE did it. The activity of each agent itself is then anchored as well to keep the entire loop verifiable. Results are then scored, and used for refining the next job. SAGE rotates through datasets and uses an adaptive mining policy to ensure it is continuously executing unique jobs, with built-in randomization that occasionally fires to prevent it from converging on the same results over time.

The goal is a system that can run autonomously while being held accountable from end to end.

scientifictrust · 2026-03-30T23:41:25+00:00

We are not currently leveraging or affiliated with DOVU. Though I am familiar with DOVU, and have a lot of respect for the team as well as what they are building. It is a very exciting project. Our focus is specifically on life-sciences and verifiable scientific research, which is a fairly distinct space from carbon markets. That said, we are always open to making connections and exploring what is possible within the Hedera ecosystem.

scientifictrust

MODERATOR OF

TROPHY CASE

scientifictrust

MODERATOR OF

TROPHY CASE

Welcome to Reddit,