Editorial Standard

This is the house style for HackCancer pages. The goal is not to make every page identical; it is to make scientific claims readable, sourced, cautious, and useful for builders.

TL;DR

Every technical page should answer six questions:

1. What is it?
2. What does it measure, change, or solve?
3. What does it not do?
4. How mature is the evidence?
5. How does it connect to data, computation, or implementation?
6. Which sources support the key claims?

If a page cannot answer those, it is probably still a stub.

---

Required page shape

Section	Purpose
# Title	Clear topic name, not a marketing slogan
Scope note	Educational boundary and clinical safety caveat when needed
## TL;DR	One dense paragraph with maturity and limits
## What it is	Mechanism, definition, or conceptual model
## What it measures / solves	Concrete use cases
## What it does not do	Failure boundaries and common misconceptions
## Evidence maturity	Approved, guideline-based, trial-stage, translational, preclinical, or speculative
## Data / pipeline interface	What files, measurements, metadata, or workflows it produces
## Failure modes	How readers can be misled
## What technologists can build	Practical software, data, QA, or infrastructure opportunities
## See also	Internal links
## References	Primary sources, guidelines, reviews, or official sources

Short pages may combine sections, but they should not hide evidence maturity or limitations.

---

Evidence maturity labels

Use plain text badges with the existing status style:

Label	Use when
standard of care	Routine in specific clinical settings
approved, limited use	Approved in some regions or indications
phase III	Pivotal trial evidence or active phase III
phase I/II	Human feasibility/safety or early efficacy
translational	Strong biology, limited clinical validation
preclinical	Cell, animal, organoid, or engineering work
speculative	Hypothesis, concept, or weakly supported claim

Do not let a speculative mechanism sit next to an approved therapy without a maturity label.

---

Citation style

Use this inline pattern after a paragraph or table that needs support:

<small class="hc-citations">Sources: <a href="#ref-1">[1]</a>, <a href="#ref-2">[2]</a></small>

Use this reference pattern:

1. <span id="ref-1" class="hc-ref-anchor"></span>Author A, Author B. **Title.** *Journal* Year;Volume:Pages. PMID 00000000. [https://doi.org/...](https://doi.org/...)

Rules:

• No raw footnote markers copied from another system.
• No citation numbers glued directly to words.
• Prefer PubMed-indexed papers, DOI links, official regulators, official guidelines, and official trial registries.
• Use reviews for orientation, but primary trials or official labels for claims about approval, efficacy, or safety.
• Link URLs with Markdown. Do not paste bare links into prose.

---

Language rules

• Use precise words: associated with is not causes.
• Avoid miracle framing: no cure, breakthrough, revolutionary, or game-changing unless the page explains why and cites evidence.
• Distinguish patient care, research, engineering, and speculation.
• Keep English pages in English and PT-BR pages in Portuguese.
• Preserve technical terms when translation would confuse readers, but explain them once.
• Avoid emoji in headings and body text. Status symbols are acceptable only when they carry a consistent signal.
• Do not use visible instructions like "click here" when a descriptive link works.

---

Link rules

Internal links should be descriptive:

[Clinical trials 101](./clinical-trials-101)

Avoid:

click here: https://example.com

Every new EN page should have a PT-BR counterpart when the section is mirrored. Every new PT-BR page should have the same core structure and links unless the content is intentionally local.

---

Diagram rules

• Prefer SVG or stable HTML/tables for durable diagrams.
• Avoid Mermaid for critical diagrams until rendering is proven stable across the site.
• Put diagram assets in docs/assets/images/diagrams/.
• Use alt text that describes the information, not just "image".
• Diagrams should clarify a decision, taxonomy, workflow, or mechanism; decoration alone is not enough.

---

Page template

# Topic Title

> Note: This page is educational. It does not provide medical advice.

## TL;DR

One dense paragraph: what it is, why it matters, maturity, and main limitation.
<small class="hc-citations">Sources: <a href="#ref-1">[1]</a></small>

---

## What it is

Define the topic plainly.

---

## What it measures / solves

| Use case | What it tells you | Caveat |
|---|---|---|
| Example | Example | Example |

---

## What it does not do

- Boundary 1
- Boundary 2
- Boundary 3

---

## Evidence maturity

<span class="hc-status">translational</span>

Explain why this label is fair.

---

## Data / pipeline interface

What files, measurements, metadata, assays, APIs, or workflows connect this topic to builders?

---

## Failure modes

- How people overinterpret it
- How artifacts enter
- What validation is needed

---

## What technologists can build

- Practical tool or dataset
- QA dashboard
- Reproducible workflow

---

## See also

- [Related page](./related-page)

---

## References

1. <span id="ref-1" class="hc-ref-anchor"></span>Reference with DOI or official URL.

---

Definition of done

Before a page is considered usable:

• It has EN and PT-BR versions if the section is mirrored.
• It states evidence maturity.
• It has at least one credible source for each major claim cluster.
• It has no raw footnotes.
• It has no bare URLs.
• It has internal links to adjacent concepts.
• It names at least one limitation or failure mode.
• It does not encourage self-directed clinical experimentation.
• It passes vitepress build docs.