This policy defines how OpenAMP Foundry should communicate results in README text, releases, papers, posters, abstracts, talks, blog posts, social media, funder updates, and partner-facing material.
Public communication is part of the scientific system.
A careless claim can damage trust even when the code is safe.
Publish the evidence level, not the excitement level.
This policy applies to:
- public release notes;
- README and website text;
- candidate summaries;
- benchmark reports;
- external review packets;
- scientific manuscripts;
- posters and talks;
- grant or funder updates;
- press language;
- agent-generated summaries.
Before public claims, complete:
- Proof-ladder mapping.
- Claim review checklist.
- Safety review if sensitive artifacts are involved.
- Benchmark source-of-truth check.
- Release-status check.
- Negative-result and limitation review.
- Decision record for major claim upgrades.
Use:
Allowed for computational-only outputs:
- computationally nominated candidate;
- dry-lab candidate;
- selected by reproducible pipeline;
- selected for expert review;
- evidence package;
- benchmark-supported under stated assumptions;
- candidate-selection hypothesis;
- informational result;
- requires qualified review.
Use only when evidence supports it exactly:
- experimentally observed signal;
- independently reproduced result;
- candidate family;
- novelty-supported family;
- safety-adjusted early evidence;
- improved experiment selection.
Define context precisely.
Avoid or reject:
- drug candidate;
- safe;
- effective;
- clinically useful;
- therapy;
- cure;
- antibiotic;
- proven;
- breakthrough;
- world-first;
- AI discovered an antibiotic;
- validated by computation.
When communicating benchmark results, state:
- benchmark name;
- dataset or source-of-truth doc;
- metric;
- cheap baselines;
- known shortcuts;
- confidence or uncertainty where available;
- whether the benchmark is exploratory, informational, gate, or deprecated;
- what the benchmark does not prove.
Do not copy stale metrics across many docs.
Link to METRICS_CURRENT.md when possible.
When communicating a candidate or panel, state:
- proof-ladder level;
- whether evidence is dry-lab only;
- selection rule;
- novelty status;
- safety-risk status;
- release status;
- external review status;
- unsupported claims.
Do not present a top-ranked candidate as a hit.
Negative results should be reported where safe and interpretable.
A public report should not include only successes if failures materially affect interpretation.
Negative evidence may support:
- claim downgrade;
- benchmark revision;
- model deprecation;
- next-batch redesign;
- calibration rejection.
High-level communication may be ambitious, but it must remain grounded.
Good framing:
OpenAMP builds open infrastructure for reproducible, safety-aware antimicrobial peptide candidate selection.
Bad framing:
OpenAMP uses AI to discover antibiotics.
The first describes process.
The second implies evidence the project may not have.
Agent-generated public text requires human review before publication.
Agents should default to weaker claims and explicit caveats.
For major public claims, record:
claim_id: stable-id
date: YYYY-MM-DD
claim_text: text
proof_ladder_level: level
supporting_artifacts: list
benchmark_source: path-or-null
safety_review: required-or-not
release_status: open | staged | restricted | internal | do-not-release
limitations: list
approved_by: role-or-name
revisit_condition: textA public OpenAMP claim should make skeptical readers trust the project more, not because it is bold, but because it is bounded.