The FORRT chain(s) reachable from a published nanopub URI, as a compact projection you can actually read.

Call this to see an existing chain — before starting a replication (what has already been done?), when extending someone else's chain, or to inspect your own after publishing.

The raw Science Live constellation is ~330 KB for one chain, of which ~95 % is a depth-5 neighbourhood of UNRELATED chains reachable through shared links (on the marine-heatwave chain, 64 of 98 nodes are other studies' AIDA statements). This returns the chains, the apex CiTO, any Research Synthesis, and the Quote/Question anchors attributable to this paper — and drops the rest, reporting how much it dropped under neighbourhood.

Read citedPaper rather than assuming: the API's own top-level paperDoi is a frequency vote across the whole walk and can name a neighbour's paper, so this derives the paper from the chain's CiTO citation and sets disagreesWithReported when the two differ.

stepsPresent legitimately omits steps: a CiTO at the apex of the constellation is hoisted out of its chain, and Quote/AIDA anchors are often not enumerated. Missing does not mean unpublished.

What has already been claimed about a paper — the starting point for new work, whether that work is a replication or a fresh study.

Given any published nanopub URI in a constellation, returns one entry per completed chain: the claim type, what was tested (scope), how (method), what was done differently (deviations), the verdict and confidence, and — the field to read most carefully — limitations, where the previous authors stated in their own signed words what their study did NOT cover.

Use it to avoid duplicating an existing replication, to choose a CiTO relation relative to prior work (extends / qualifies / disputes), and to find the part of a claim still open. Cite what you find; do not re-derive it — a published chain step is a record with a URI, not a result to recompute.

Prove that a candidate quotation is really in a source PDF, before it is published as verbatim.

Call this on EVERY quotation destined for a Quote-with-comment nanopub. You choose which sentence carries the paper's claim — that is judgement. This decides whether the sentence is admissible, and that is not: it is a string search, and anyone can re-run it and get the same answer.

Returns a graded verdict with the page, character offsets and the file's SHA-256 as evidence:

exact byte-identical to the extracted page text normalized matched after whitespace / ligature / typographic punctuation / line-break-hyphen repair extraction_tolerant additionally ignored hyphens and punctuation spacing not_found NOT in this PDF — do not publish it as a quotation

A tier below exact is normal and not a warning about your quotation: PDF extraction inserts line breaks and drops hyphens (a real published FORRT quotation matches only at extraction_tolerant, because pypdf reads "35-year" as "35year"). Every tier canonicalises formatting only — never words, digits or order — so an altered number still fails at every tier. Read matched_text before publishing.

On not_found, closest.text_in_pdf shows what the paper says where it nearly matched. A one-digit change scores ~0.91 similarity and is still not_found: high similarity is not a pass.

The unprojected /np/constellation response, including every node and edge.

For debugging the graph itself or investigating an upstream data problem. Prefer constellation for normal use: this is very large (~330 KB for a single chain) and most of it belongs to other studies. Lower depth to shrink the walk.

The exact form fields of one FORRT chain step, from the live template.

Call this BEFORE drafting any nanopub field. A nanopub template is the schema for its step, so this is what makes "never invent a field name" a lookup rather than a rule you have to remember: it returns the real field ids, prompts, whether each is required or repeatable, the length/format constraints (regex, prefix, datatype — where the Quote template's character cap actually lives), and, for choice fields, the allowed values.

step accepts 05_outcome, 05, or outcome. Known steps: 01_quote, 01_pico, 01_pcc, 02_aida, 03_claim, 04_study, 05_outcome, 06_citation, 07_research_software, 08_synthesis.

Check source: live means fetched from the nanopub network just now; bundled-snapshot means the network was unavailable and these are vendored values that may be stale. driftedFromSnapshot: true means the template was superseded upstream — the live values win, and this package needs re-vendoring.

The allowed values of a FORRT controlled vocabulary, from its template.

Use it whenever a draft needs a claim type, a study type, a validation status, a confidence level, or a CiTO relation. Every term comes from the real restricted-choice field on the real template (or the value-list nanopub it points at), so a value returned here is one the form will actually accept — and nothing else is.

Names: claim_type, study_type, validation_status, confidence_level, cito_relation, pico_question_type.

Three worth reading before you draft:

• study_type carries the Reproduction vs Replication distinction (same data + same methods, vs different data and/or methods, or both).

• validation_status is the Outcome verdict. Pick it from the evidence, not from what would be a nicer result; a contradicted replication is publishable and an overclaimed one is not.

• pico_question_type is PICO-only, deliberately. Step 01 has three alternative anchors and they are not variants of one form: a PCC question has NO type field, and a Quote-with-comment has neither a type nor a label. Call template_fields on the anchor you are actually using (01_quote, 01_pico or 01_pcc) rather than assuming they match.

Which chain steps and vocabularies this server can look up.

Cheap, offline, and no network. Call it first if you are unsure what to pass to template_fields or vocabulary.

Does this DOI resolve, and to what?

Call it on every DOI destined for a nanopub field, CITATION.cff, or a CiTO citation. resolves: false means the DOI is not registered — do not publish it, however well-formed it looks. A well-formed DOI is not a real one, and a fabricated one is indistinguishable from a genuine one until something asks the registry.

On success it returns the registered title, authors, year, container and type, so you can confirm it is the paper you mean rather than merely a paper that exists. Accepts bare (10.…), URL, or doi:-prefixed forms.

Find real Wikidata items for a term, and type-check them.

Call it for every Wikidata topic or keyword destined for a nanopub field. It returns candidates with their descriptions and real P31/P279 types; it deliberately does NOT choose one, because picking the right sense of an ambiguous label is a judgement. What it guarantees is that the QID you publish exists and is what you say it is.

Pass expected_type as a QID (e.g. Q16521 taxon, Q11862829 academic discipline) and each candidate is marked typeMatches from its actual statements. Candidates are annotated, never filtered — a near miss is often the informative result. Searching "Bombus" with Q16521, for instance, returns the insect genus as a match and the album of the same name as not.

A zero-candidate result means leave the field empty or try another label. Never fall back to a QID from memory.

Check one drafted nanopub against its template and the real world.

Run this on every draft before publishing. It is the pre-flight checklist in docs/forrt-form-fields.md, actually executed: field ids checked against the live template, choice values against the template's own enumeration, length caps against its regex, DOIs against the registry, Wikidata QIDs against Wikidata.

publishable is true only when there are no errors. Severities:

error would publish something false, or be rejected by the form warning a human should look, but it may be intentional info checked and fine, or deliberately not checked

Three placeholder conventions are distinguished, because only one is a problem: «URI of step 05 …» is a back-reference the chain wizard fills (info); {{ZENODO_VERSION_DOI}} is a release-time token the release workflow substitutes (warning — confirm the release ran); anything else still standing in for a value is an error.

step is inferred from the filename (05_outcome.md); pass it explicitly for a file named otherwise. A draft whose required fields are nearly all empty is reported once as an unfilled skeleton rather than field by field.

Check every draft in a nanopubs/drafts/ directory at once.

The whole-chain pre-flight: run it before starting Phase 5b, and again before announcing. Returns per-draft results plus totals, with publishable true only when no draft has an error.

Note what it cannot see: values a draft puts in prose or a markdown table rather than behind a <!-- field: … --> marker are reported as coverage warnings, not as missing. The CiTO step's citation list is the known case.

Verify a published FORRT chain. Run this before announcing it anywhere.

Point it at a nanopubs/PUBLISHED.md ledger (or the directory holding one). Read-only: it never edits, retracts or supersedes — a failing row is for a human to act on. green is true only when nothing failed.

What it checks:

• every required step (01-06) has a URI in the ledger;

• every URI is really published — present in the constellation, or, for the upstream anchors the walk does not reach, served as RDF by the w3id.org/np/ resolver;

• the Outcome's repository resolves (a Zenodo version DOI is the expected value — it pins the archived state, where a GitHub URL would be a moving target);

• every DOI the chain cites resolves;

• the CiTO relation agrees with the Outcome's verdict — Validated implies confirms, PartiallySupported implies qualifies, Contradicted implies disputes. A mismatch means the Outcome and the Citation disagree about what the replication found, which is the failure most worth catching before anyone reads the chain. Only the ledger's own Outcome and CiTO are judged: the relation→target pairs come from the step-06 TriG, and the relation that counts is the one on the paper the Quote quotes. Other chains the walk reached (several chains often cite the same paper) are listed as neighbours, never judged.

A step reported as "not enumerated by the walk but its TriG resolves" is fine, not a warning: the constellation legitimately stops short of Quote, AIDA and Claim.

mode — auto (default), replication, reproduction or new_research. It changes only what is REQUIRED. Research that starts from scratch has no existing work to cite, so no CiTO step and no cited DOI are expected, and auto infers that from the absence of a published step 06. Everything else is checked identically in all three. Reproduction and replication verify the same way; pass one explicitly only to make the wording match your study.

Check nanopubs/chain-draft.json before handing it to the chain wizard.

Run this at the end of Phase 5b, after pixi run build-chain-draft and BEFORE pushing the file and opening the wizard URL. readyForWizard is true only when nothing came back as an error.

This file — not the markdown drafts — is what the wizard pre-fills each step from, and therefore what a human reviews and signs. validate_draft checks the authoring input; this checks the artifact.

What it catches that reading the file cannot:

• a superseded template_uri, which is invisible in the JSON but makes the wizard pre-fill the old form. Re-run build-chain-draft to fix;

• a prefill key that is neither a template field nor a known platform form-field — the wizard silently drops it;

• a complex field in the wrong shape: 06_citation.st02 must be [{cites, cited}] with at least one entry, and 04_study.disciplineSelection is a single object, NOT an array;

• a required field that is neither prefilled nor carried forward;

• values violating the template's own regex (the Quote's 500-character cap lives there), an invalid vocabulary term, a malformed date, an unresolved {{TOKEN}}, or a DOI that does not resolve;

• a carry_forward edge that runs backwards through the chain.

Fields the wizard fills itself are exempt, not reported missing: 02_aida has no project, 03_claim no aida, 04_study no claim, because each is carried forward from the step published before it.

Mirror published CiTO citations into Wikidata — as a batch for a human to submit.

Run it after verify_chain is green, to make the chain's typed citation ("this replication confirms / qualifies / disputes that paper") visible in Wikidata and Scholia. Pass the CiTO nanopub URIs, or published_path (a nanopubs/PUBLISHED.md) to take every CiTO nanopub in the ledger.

It writes nothing to Wikidata. It returns quickstatements — a batch that adds, on the replication's item, "cites work" (P2860) → the original, with "has goal" (P3712) → the CiTO intent, referenced by "nanopublication identifier" (P12545) → the CiTO nanopub — plus a per-work report. Show the researcher the report; they submit the batch at https://quickstatements.toolforge.org with their own Wikidata account. Never submit it on their behalf.

Items are looked up by DOI and ORCID first and created only when missing; a replication is one item per Zenodo concept DOI, not one per version. Items are created from the Zenodo record's title, so a repository-slug title ("my-replication-repo") should be fixed on Zenodo first. pending lists citations to works this same batch creates: re-run after submitting.

Check an RO-Crate before it is released or deposited (e.g. in ROHub).

path is the crate's directory (usually the repository root) or its ro-crate-metadata.json. Run it after pixi run -e rocrate build-rocrate and before deposit-rohub; it is the same check the template's CI runs.

Two layers:

• passed/issues: rocrate-validator against profile (default ro-crate-1.2) at level (REQUIRED, RECOMMENDED or OPTIONAL). Each issue names the check, its message and the offending entity — relay them verbatim. metadata_only=True skips the checks that the listed files exist (for a crate whose data are not checked out). The first run fetches the RO-Crate JSON-LD context (then cached); offline=True needs that cache.

• fdo_checks/fdo_ready: what a replication crate needs beyond the specification to work as a FAIR Digital Object — a persistent identifier, a licence, the workflow as mainEntity, a community FAIR Implementation Profile in conformsTo, the FORRT chain in subjectOf, and no ro-crate-metadata.json among its parts (ROHub reserves that name). Advisory: they do not change passed; each failing check says how to fix it.

Never hand-edit ro-crate-metadata.json to make it pass: it is generated by scripts/build_rocrate.py — fix the source (CITATION.cff, the ledger, rocrate.json) and rebuild.