Hmm…? It looks like quite a few different things may have gotten mixed together here, so I hope this helps organize them as clearly as possible:
Short answer
If you are asking where to share an AI/science tool on Hugging Face, I would separate the question into several different layers:
| What you want to share or ask for |
Best first place |
Why |
| Code / source implementation |
GitHub |
Best for code review, issues, PRs, releases, licenses, contributor workflow |
| A runnable demo |
Hugging Face Spaces |
Best for letting people try the tool directly |
| Data, examples, benchmark cases, annotations |
Hugging Face Dataset repo |
Best for reusable examples, evaluation sets, and dataset documentation |
| A model, adapter, reranker, embedding model, or fine-tuned checkpoint |
Hugging Face Model repo |
Best only if there is an actual model artifact to publish |
| A public announcement of something already built |
Show and Tell |
Best for showing Spaces, Models, Datasets, tools, and getting feedback |
| A call for collaborators or contributors |
Community Calls |
Best for asking the community for help on a specific project |
| Science / biology / neuroscience / biomedical-oriented discussion |
Hugging Science |
Likely relevant for AI-for-science or biomed-facing work; check the Discord channel norms before posting |
| A research hypothesis, evaluation design, or methodology question |
Research |
Best for the research question itself, not for a general product announcement |
| Anything potentially patent-sensitive |
Do not disclose technical details publicly yet |
First clarify what can be disclosed with a patent professional |
So the practical route would probably be:
- If patent filing is still pending, do not post technical details publicly yet.
- Put the code on GitHub, if it can be disclosed.
- Make a small Hugging Face Space if there is a runnable demo.
- Put examples, evaluation cases, or benchmark-like data in a Dataset repo, if relevant.
- Use Show and Tell to present the built thing.
- Use Community Calls if you are looking for collaborators.
- Use Research only for the research question / evaluation method / hypothesis.
- Consider Hugging Science if the work is genuinely science/biomed-oriented.
The main thing is: this probably should not be one single post containing everything. It is easier to understand if the tool, the research claim, the personal motivation, the patent/disclosure status, and the collaboration request are separated.
First: separate the different questions
Your post seems to combine several different questions at once:
| Layer |
Example question |
Where it belongs |
| Product/tool layer |
“I built a tool; where do I show it?” |
GitHub, HF Space, Show and Tell |
| Research layer |
“I have a scientific hypothesis or evaluation idea; where do I discuss it?” |
Research forum, Hugging Science |
| Data/evaluation layer |
“I have examples, evidence, claims, annotations, or benchmark cases.” |
HF Dataset repo |
| Collaboration layer |
“I need engineers, scientists, reviewers, or testers.” |
Community Calls, GitHub Issues/Discussions, Hugging Science |
| Legal/disclosure layer |
“Some of this may be patent-sensitive.” |
Pause public disclosure; get professional advice |
| Personal background layer |
“Here is why this matters to me.” |
Useful context, but should not overwhelm the technical post |
A good first move is not “pick one forum category.”
A better first move is:
What exactly am I sharing?
That question determines the right place.
A simple decision tree
Is patent filing still pending?
yes:
Do not disclose technical details publicly yet.
First clarify what can be safely shared.
no / disclosure cleared:
Continue.
Do you have source code?
yes:
Put it on GitHub or another code-hosting repo.
no:
Explain that it is currently only a concept or private prototype.
Do you have a runnable demo?
yes:
Put it on Hugging Face Spaces.
no:
Consider making a minimal demo before asking for broad feedback.
Do you have data, examples, claims, annotations, or evaluation cases?
yes:
Put them in a Hugging Face Dataset repo if they can be shared.
no:
At least provide a few non-sensitive examples in the README or post.
Are you announcing something already built?
yes:
Use Show and Tell.
Are you looking for collaborators?
yes:
Use Community Calls, GitHub Issues/Discussions, and possibly Hugging Science.
Are you asking a research-method question?
yes:
Use Research.
Why GitHub may be useful here
Hugging Face repositories are Git-based too. Models, Spaces, and Datasets are hosted on the Hugging Face Hub as Git repositories, so HF can absolutely store real project artifacts.
However, if this is mainly a software tool, GitHub is still often the clearest place for:
- source code
- issue tracking
- pull requests
- release notes
- contributor workflow
- licensing
- citation files
- security policy
- documentation
- tests
- roadmap
A good GitHub README could answer the questions people will naturally ask first:
# <project-name>
## What this is
<one-sentence description>
## What problem it addresses
<scientific claim checking / literature verification / evidence review / other>
## Current status
<prototype / private prototype / patent-pending / public release / research demo>
## What is public
- Code: <GitHub URL>
- Demo: <Hugging Face Space URL>
- Dataset/examples: <Hugging Face Dataset URL>
- Paper/preprint: <paper URL if any>
## How to run it
<installation and minimal example>
## Example
Input:
<example input>
Output:
<example output>
## Limitations
- Not medical advice.
- Not clinical decision support.
- Requires human review.
- May miss relevant evidence.
- May produce false positives or false negatives.
- Not a substitute for domain expert review.
## How to contribute
<what kind of help you want>
## License
<license>
If you do not yet have code that can be public, say that clearly. A vague “I built something but cannot show details” post is much harder for others to help with.
Why a Hugging Face Space may be useful
A Hugging Face Space is useful if people need to try the tool, not just read about it.
For this kind of project, a minimal Space could be enough:
Input:
- scientific claim
- abstract
- citation
- source passage
- optional paper metadata
Output:
- supported / unsupported / needs review
- evidence passages
- explanation
- failure mode
- confidence caveat
A minimal demo might be more effective than a long post because it answers:
- What does the tool actually do?
- What does the input look like?
- What does the output look like?
- What kind of mistakes does it make?
- What feedback do you want?
Important caution: public Spaces are public. The HF docs explain that public Spaces make the source code visible, the running app accessible, and the repo cloneable. Protected/private options exist, but the visibility choice matters. So if there is patent-sensitive material, private logic, secret methods, or API keys, do not accidentally publish them in a public Space.
Also, if the Space uses API keys or tokens, use Space secrets/environment variables rather than hard-coding secrets in the repo.
Why a Dataset repo may be more important than a Model repo
If this is a literature-verification or scientific-claim-checking tool, a Dataset repo may be more important than a Model repo.
A model repo is appropriate if you have an actual model artifact:
| Situation |
Model repo needed? |
| You only use existing LLM APIs |
Usually no |
| You built a RAG or claim-checking app around existing models |
Usually no |
| You fine-tuned a biomedical model |
Yes |
| You created a LoRA/adaptor |
Yes |
| You trained a reranker or embedding model |
Yes |
| You released model weights |
Yes |
For a claim-checking / literature-verification tool, the reusable asset may instead be:
claims.jsonl
source_passages.jsonl
paper_metadata.jsonl
expected_outputs.jsonl
failure_cases.jsonl
annotation_guidelines.md
README.md
A Dataset Card is where you explain:
- what the examples are
- where the evidence came from
- how annotations were produced
- what the license is
- what the limitations are
- what biases or risks exist
- what the data should and should not be used for
For science or biomedical work, provenance and limitations are not decorative. They are central.
Where to post what
1. Show and Tell
Use Show and Tell when you have something concrete to show:
- a Space
- a GitHub repo
- a Dataset repo
- a Model repo
- a working prototype
- a demo video
- a reproducible example
The category description says it is for sharing and discussing projects such as Spaces, Models, Datasets, and getting feedback. It also encourages technical/open-source detail rather than promotional content.
A good Show and Tell post could look like this:
Title:
<project-name>: a small demo for scientific claim checking against source material
Body:
I built a small research demo for checking scientific claims against source material.
Demo:
<HF Space URL>
Code:
<GitHub URL>
Dataset/examples:
<HF Dataset URL>
What it does:
- accepts a claim or citation
- retrieves or compares source evidence
- marks the result as supported / unsupported / needs review
- shows evidence passages
- highlights failure cases
I am looking for feedback on:
- whether the output format is useful
- how to evaluate it
- what failure cases are important
- what datasets or benchmarks may be relevant
- whether the demo is understandable
Limitations:
This is a research / literature-review support prototype.
It is not medical advice.
It is not clinical decision support.
Human review is required.
Use Show and Tell when the main message is:
Here is what I built. Please try it and give feedback.
2. Community Calls
Use Community Calls when the main message is:
I need help from the community on a specific project.
This is where a collaborator request is likely more natural than in a general announcement post.
A good Community Calls post should be specific:
Title:
Looking for collaborators for a scientific claim-checking / literature-verification tool
Project:
I am building <short description>.
Current status:
- Code: <GitHub URL or "not public yet">
- Demo: <HF Space URL or "not available yet">
- Dataset/examples: <HF Dataset URL or "in preparation">
- Disclosure status: <public / partial / patent-sensitive / to be clarified>
Help needed:
- ML engineering
- biomedical or scientific literature review
- dataset annotation
- evaluation design
- UX testing
- safety / limitations review
Who would be a good fit:
- ML engineers
- scientific or biomedical domain experts
- people experienced in retrieval / RAG / evidence verification
- dataset builders / annotators
- people interested in evaluation design
Terms:
<volunteer / paid / open to discuss / grant-seeking / not sure yet>
Contact:
<GitHub Issues / forum reply / email / Discord after checking channel rules>
Try to avoid a generic “I need collaborators” request. Instead, break the work into roles.
For example:
| Need |
Better wording |
| “I need help” |
“I need help testing retrieval failures on 20 example claims.” |
| “I need scientists” |
“I need domain experts to review whether the evidence labels are reasonable.” |
| “I need engineers” |
“I need help turning the prototype into a minimal Gradio Space.” |
| “I need feedback” |
“I need feedback on whether the output schema is useful.” |
3. Research
Use Research if the core topic is the research question itself:
- hypothesis
- methodology
- evaluation
- benchmark design
- related work
- failure modes
- scientific validity
- safety/limitations
A Research post should not be mainly a product announcement. It should be framed as a research problem.
Example:
Title:
How should we evaluate LLM-assisted scientific claim checking against source literature?
Research question:
Can an LLM-assisted pipeline help detect unsupported scientific claims by checking them against source passages?
Hypothesis:
A retrieval + evidence-checking workflow may reduce unsupported claims compared with a plain LLM answer, but only if retrieval quality and human review are part of the evaluation.
Possible setup:
- collect a small set of scientific claims
- attach source passages or paper metadata
- label claims as supported / unsupported / ambiguous / needs expert review
- compare baseline LLM answers against a retrieval-grounded workflow
- inspect failure modes manually
Evaluation questions:
- What counts as enough evidence?
- How should ambiguous claims be labeled?
- How should missing evidence be handled?
- What failure cases are most important?
- How much human review is required?
- Which existing datasets or benchmarks are relevant?
Limitations:
This is not a clinical system.
This is not medical advice.
The goal is literature-review support and evaluation design.
For biomedical or medical-adjacent work, keep the language conservative.
Avoid:
This diagnoses disease.
This proves the hypothesis.
This is ready for doctors.
This automatically verifies medical truth.
This can be used for treatment decisions.
Prefer:
research prototype
literature-review support
scientific claim-checking demo
evidence retrieval aid
annotation support
human review required
not medical advice
not clinical decision support
4. Hugging Science
Hugging Science looks relevant if the project is really in the AI-for-science direction. Its public page explicitly points people toward Discord for real-time collaboration, discussion, and community coordination, and toward GitHub for open-source project contribution.
I would treat it as a strong candidate for:
- AI for science
- biology
- neuroscience
- biomedical literature workflows
- scientific discovery tooling
- scientific evaluation and datasets
However, I would not assume the exact Discord channel or posting norm from outside. Discord rules and channel structure can change. The safe approach is:
Join the Discord.
Read the channel descriptions and rules.
Ask where a biomedical / literature-review / claim-checking tool discussion should go.
Post a short, non-sensitive summary first.
Move technical details to GitHub / Space / Dataset repo only when disclosure is cleared.
So the public recommendation would be:
Hugging Science may be a good place for science-focused feedback, especially if the project is biology, neuroscience, biomedical literature, or AI-for-science oriented. But check the current Discord channel rules and moderator guidance before posting details.
Patent / disclosure caution
This is important enough to put before the sharing plan.
If a patent filing is still pending, be careful with public disclosure. Patent rules differ by jurisdiction, but in many systems public disclosure before filing can matter for novelty or prior art. The European Patent Office guidance on novelty focuses on what has been made available to the public as prior art, while the US has its own grace-period rules and exceptions.
That means a public forum post, GitHub repo, public Space, dataset, demo, screenshots, or detailed explanation may be legally relevant.
This is not legal advice, but the practical rule is:
If patent filing is still pending, do not publicly disclose the technical core.
First ask a patent professional what can be safely shared.
A safe high-level statement could be:
Some technical details are not public yet because disclosure status is still being clarified. I can discuss the high-level goal and the kind of feedback/collaboration I am looking for, but I cannot share implementation details until the disclosure situation is clear.
For a patent-sensitive project, it may be better to ask only for broad guidance first:
I am working on a research-oriented tool related to scientific literature verification. Some implementation details are not public yet. I am trying to understand which HF community channels are most appropriate for future sharing once disclosure is cleared.
Recommended order
If this were my project, I would not start by writing a long forum post. I would do this instead:
| Step |
Action |
Why |
| 0 |
Clarify patent/disclosure status |
Prevent accidental public disclosure |
| 1 |
Write a short private project summary |
Forces the idea into clear terms |
| 2 |
Decide what can be public |
Separates shareable from non-shareable |
| 3 |
Create a GitHub README |
Organizes the project better than a forum post |
| 4 |
Build a minimal HF Space if possible |
Lets people understand the tool quickly |
| 5 |
Prepare examples or a Dataset repo |
Makes evaluation and feedback concrete |
| 6 |
Post in Show and Tell |
Announce the thing that exists |
| 7 |
Post in Community Calls |
Ask for specific collaborators |
| 8 |
Post in Research |
Discuss the hypothesis/evaluation separately |
| 9 |
Ask in Hugging Science if science/biomed-focused |
Find domain-focused feedback |
The reason for this order is simple: forum posts become much clearer when there is already a README, demo, or example set to point to.
A compact “routing map”
| If the sentence starts with… |
It probably belongs in… |
| “I built…” |
Show and Tell |
| “Try the demo…” |
HF Space + Show and Tell |
| “The code is…” |
GitHub |
| “The dataset/examples are…” |
Dataset repo |
| “The model weights are…” |
Model repo |
| “I need collaborators…” |
Community Calls |
| “I need engineers…” |
GitHub Issues / Community Calls |
| “I need biomedical/scientific review…” |
Hugging Science / Research |
| “My hypothesis is…” |
Research |
| “How should this be evaluated?” |
Research |
| “Some details are patent-sensitive…” |
Do not disclose technical details yet |
Suggested minimal public package
Before posting widely, try to prepare this:
1. One-sentence description
2. One paragraph explaining the problem
3. One screenshot or demo
4. One GitHub README
5. One minimal example input/output
6. One limitations section
7. One clear request for help
8. One disclosure/patent note if needed
Example structure:
Project:
<one-sentence description>
Status:
<prototype / demo / private / patent-sensitive / public>
Public links:
- Demo: <HF Space URL>
- Code: <GitHub URL>
- Examples/data: <HF Dataset URL>
What I need:
- <specific help request 1>
- <specific help request 2>
- <specific help request 3>
Limitations:
- research demo only
- not medical advice
- not clinical decision support
- human review required
Three separate post drafts
Instead of one large post, I would split it into three posts only if each one has a clear purpose.
A. Show and Tell version
Title:
<project-name>: a small research demo for checking scientific claims against source material
Hi everyone,
I built a small research demo for checking scientific claims against source material.
Demo:
<HF Space URL>
Code:
<GitHub URL>
Examples / dataset:
<HF Dataset URL>
The tool currently:
- accepts <claim / abstract / citation / source text>
- compares the claim against source material
- returns <supported / unsupported / needs review>
- shows evidence passages where possible
- highlights uncertainty and failure cases
I would appreciate feedback on:
- whether the output format is useful
- whether the demo is understandable
- what failure cases should be tested
- how this should be evaluated
- whether there are relevant datasets or benchmarks I should look at
Limitations:
This is a research / literature-review support prototype.
It is not medical advice.
It is not clinical decision support.
Human review is required.
B. Community Calls version
Title:
Looking for collaborators for a scientific claim-checking / literature-verification tool
Hi everyone,
I am looking for collaborators for a project related to scientific claim checking and literature verification.
Current status:
- Demo: <HF Space URL or "not public yet">
- Code: <GitHub URL or "not public yet">
- Dataset/examples: <HF Dataset URL or "in preparation">
- Disclosure status: <public / partial / patent-sensitive / still being clarified>
I am especially looking for help with:
- ML / retrieval / RAG engineering
- biomedical or scientific literature review
- evaluation design
- dataset annotation
- UX testing
- failure-case analysis
Good fit:
- ML engineers
- researchers
- biomedical/scientific domain experts
- people familiar with evidence retrieval or citation checking
- people interested in evaluation and benchmark design
Terms:
<volunteer / paid / open to discuss / grant-seeking / undecided>
Important note:
Some technical details may be limited if disclosure or patent filing is still being clarified.
Contact:
<GitHub Issues / forum reply / email / other>
C. Research version
Title:
How should we evaluate LLM-assisted scientific claim checking against source literature?
Hi everyone,
I am interested in the evaluation problem behind scientific claim checking.
Research question:
How should we evaluate whether an LLM-assisted workflow can check scientific claims against source literature?
Possible setup:
- collect a small set of claims
- attach source passages or paper metadata
- label each claim as supported / unsupported / ambiguous / needs expert review
- compare plain LLM answers against a retrieval-grounded workflow
- analyze false positives, false negatives, missing evidence, and ambiguous cases
Questions:
- What should count as sufficient evidence?
- How should ambiguous or partially supported claims be labeled?
- What existing datasets or benchmarks might be relevant?
- How should human review be incorporated?
- What failure modes matter most in scientific or biomedical settings?
Limitations:
This is not a clinical system.
This is not medical advice.
The goal is literature-review support and evaluation design.
Final recommendation
I would not try to solve this by choosing one perfect place.
The cleaner approach is:
- Do not disclose patent-sensitive technical details until cleared.
- Use GitHub for code and project structure.
- Use Hugging Face Spaces for a runnable demo.
- Use a Dataset repo for examples, annotations, and evaluation cases.
- Use Show and Tell to show the built artifact.
- Use Community Calls to ask for collaborators.
- Use Research to discuss the research question and evaluation.
- Use Hugging Science for science/biomed-focused community feedback, after checking current Discord norms.
In other words:
The key question is not only “where should I share this?”
The key question is “what exactly am I sharing: code, demo, data, model, research question, or collaboration request?”
Once those are separated, the right place becomes much easier to choose.
tool I needed and it works.
. i sold my everquest2 account for cheap so I could have $65.for patent. Between economic vacuum potential and megacorporation likely would try to steal it, i decided to do a demo free public and gate the workbench for use on site and do gumroad for subs with 75% affiliate commissions. I can scale infinitely because it is bring your own ai key, multi model including localhost, ip, google, chatgpt, openrouter, and maybe add more…ot is open language, the ai translates core prompts and interface if not english, air gapable (with local library and local llm) and no drm, no pii call home… i dont want to block medical or academic advancement but must limit sales saas and keep it available to the hands of people like me with no f-ing money, banned from almost all social media, and just want to use AI to learn or research and get better results.
