v1 · public proof layer

Candidate Record v1

How TWOG converts internal research artifacts into stable public candidate pages with rationale, evidence, risks, decision history, and reproducibility metadata.

activeapplies to · candidate pagesclaims · research artifact
What this governs

A candidate page is a frozen public argument. It should show what TWOG currently believes, what supports it, what is still weak, and what would change the record.

LLMs argue and synthesize. Operator approval is the write gate.

01 · Internal evidence

The source material starts as TWOG research artifacts: briefs, therapy ideas, validation packets, citation refs, decision events, and reproducibility metadata.

02 · Public snapshot

The exporter creates a bounded public payload with the hypothesis, status, rationale, evidence refs, risk notes, known blockers, and linked records.

03 · Citation expansion

Internal labels such as C1, C20, or C22 are expanded into a reference dossier with title, DOI, PMID, PMCID, source, evidence kind, supported claim, and provenance counts.

04 · Decision trail

Status changes and snapshot events are preserved as dated decision entries. A candidate should never silently move from proposed to investigating to advanced.

05 · Hash and publish

The public snapshot receives a content hash. The page can be cited, compared, challenged, and regenerated without pretending the record is more final than it is.

What the record is

A candidate record is a public snapshot of a research idea at a specific moment. It preserves the hypothesis, current status, source evidence, known risks, decision history, and reproducibility metadata without treating the idea as clinically settled.

How evidence labels work

Short labels such as C1 or C20 are local citation identifiers from a source brief. The public page must expand them into article titles, identifiers, links, evidence type, source provenance, duplicate handling, and the exact claim each source supports.

What hashes mean

The content hash is computed from the public snapshot payload. It lets a reader cite or compare a specific version of the candidate page when later evidence changes the record.

How decision logs work

Decision entries record when a candidate is proposed, updated, advanced, parked, or regenerated. Each meaningful transition should carry a short rationale and a link back to the related agent, evidence packet, validation decision, or compute run when available.

What the page does not claim

A candidate page is not a diagnosis, prescription, treatment recommendation, or proof of efficacy. It is a research artifact that makes the reasoning chain easier to inspect, challenge, reproduce, and improve.

What a reader can verify
What is being proposed
The candidate ID, status, target family, therapy family, and current priority score.
What evidence supports it
Short citation labels expanded into readable source compartments and supported claims.
What is still weak
Known limitations, missing data, citation gaps, and reasons the record has not advanced.
Why the status changed
Timestamped rationale for snapshot generation, evidence updates, status changes, and reviewer actions.
How this version was made
Pipeline version, source brief/evaluation IDs, committee run IDs, content hash, and method reference.
Where it's inspectable — public routes
Checkout / one candidate
/api/public-candidates/{candidate_id}

Returns one public candidate record: metadata, latest snapshot, rationale, literature, decision events, and reproducibility fields.

Browse / all candidatesopen route →
/api/public-candidates

Returns the exported public candidate dataset so readers can find available records and compare snapshot metadata.

Example checkoutopen route →
/api/public-candidates/rly2608-pik3ca

A live candidate payload using the stable candidate ID. Display IDs resolve on the page; the API uses durable IDs.

Evidence bundleopen route →
/api/public-candidates/rly2608-pik3ca/evidence-bundle

Returns the actionable checkout packet: source-document dossier, chunk manifest, artifact manifest, compute/MD reproducibility contract, and check-in endpoints.

Contribution templateopen route →
/api/public-candidates/rly2608-pik3ca/contribution-template

Returns a fillable contribution packet for evidence, critique, replication notes, artifacts, or validation proposals tied to this snapshot.

How to interpret this method
  • A record is an inspectable research artifact, not a clinical recommendation.
  • Evidence labels are local to the source brief; the reference dossier is the public decoding layer.
  • A candidate can be promising and still not validation-ready.
  • Human analog evidence is treated as context unless canine-specific evidence closes the bridge.
  • A content hash identifies the public snapshot, not permanent scientific truth.
What this method does not certify

Candidate Record v1 does not certify efficacy, safety, dosing, clinical readiness, regulatory fitness, or veterinary use. It only makes the research reasoning chain easier to inspect.