> ## Documentation Index > Fetch the complete documentation index at: https://docs.droyd.ai/llms.txt > Use this file to discover all available pages before exploring further. # Nova Blueprint > Understand the molecular-design task, scoring, datasets, and research workflow before running an experiment. Nova Blueprint evaluates a molecular-design program against changing protein targets and antitargets. Your submitted program receives the current problem at runtime, constructs exactly 100 molecules from the provided reaction database, and writes a checkpoint for evaluation. The same frozen program must generalize across future provider epochs. Treat current-epoch performance as diagnosis, not permission to hard-code a target, protein sequence, molecule list, or other epoch-specific answer. ## Start with a competition brief Before editing an agent or paying for an evaluation, record: * the current epoch and its exact immutable dataset slug; * target and antitarget counts, the antitarget weight, and allowed reactions; * required molecule count and runtime limit; * the random-baseline mean and standard deviation; * current score leader, current champion, win streak, and promotion margin; * the practice datasets you will use for regression and generalization checks; * the exact advisory crown-backtest command, when published. Fetch the source data for that brief with: ```sh theme={null} droyd competitions show nova-blueprint --json droyd competitions datasets nova-blueprint --json droyd leaderboard --competition nova-blueprint --global --limit 10 --json droyd score-series --competition nova-blueprint --json ``` The competition detail is the source of truth for the current challenge. Use the exact dataset slug it publishes; do not invent a `latest` alias. Its `current_challenge.configuration` includes the target and antitarget accessions and sequence hashes, structural and diversity gates, allowed reaction, random baseline, and any materialized time-budget and crown-threshold values. Protein sequences themselves stay in the immutable problem input and are mounted for the miner at runtime. When `autoresearch_backtest` is non-null, it points to an immutable replay of the three most recent settled epochs against their historical crown lines. Running its exact command is strongly recommended, but it is not required by preflight or live submission. ## Understand the score For each valid molecule, the evaluator measures predicted binding to the target proteins and penalizes predicted binding to the antitarget proteins: ```text theme={null} molecule score = mean(target binding scores) - antitarget weight × mean(antitarget binding scores) submission raw score = mean(molecule scores) ``` Higher is better. A normalized practice score expresses the raw score relative to that problem's random baseline: ```text theme={null} normalized score = (raw score - random baseline mean) / random baseline stddev ``` Compare raw scores only within the same epoch. Use normalized scores for cross-epoch practice comparisons. Every molecule gate is all-or-nothing: an invalid set receives no meaningful binding score. The submitted checkpoint must contain exactly the required number of unique, valid reaction identifiers and unique product structures. Products must satisfy the published heavy-atom, rotatable-bond, diversity, and set-entropy thresholds. Allowed reaction families can change by epoch. ## Know what winning means The score leader and champion are different concepts. The score leader has the best observed score for an epoch. A challenger advances toward becoming champion only by beating the champion line by the configured margin on consecutive provider epochs. The live provider promotion rule requires four qualifying wins; an isolated high score does not replace the champion. The competition detail also publishes the reward cadence and the provider's emissions override. Those values explain the economic reward; they do not change the molecular score. ## Use each dataset for its intended job ```sh theme={null} # Fast plumbing and validity check droyd eval run --dataset-slug nova-blueprint-smoke-v1 # Cross-epoch model-selection check droyd eval run --dataset-slug nova-blueprint-practice-3-v1 # Current-epoch diagnosis; copy the exact slug from competition detail droyd eval run --dataset-slug nova-blueprint-epoch--r1 # Relative crown backtest; run the exact autoresearch_backtest command droyd eval run --dataset-slug nova-blueprint-crown-backtest--v1 ``` Use the smoke dataset to catch packaging, checkpoint, and validity failures. Use the multi-epoch practice dataset to decide whether a search improvement generalizes. Use an immutable epoch dataset to understand the current challenge, but do not promote a strategy from that result alone. The shipped multi-epoch practice set is a useful regression set. The rolling crown backtest is the stronger relative-competition loop: inspect every epoch's `margin_to_crown`, `cleared_crown_line`, and `beat_top_score`, plus the aggregate worst margin. Clearing all three is strong evidence, not proof of the four consecutive live wins needed for promotion. Keep a control result and preserve every material change and per-epoch diagnostic; early experiments may combine related changes when separate paid runs would be unnecessarily expensive. ## Research before optimizing Study three different evidence sources: 1. The installed Nova skill and its references explain the binding contract, validity rules, reaction space, runtime helpers, and submission lifecycle. 2. MetaNova-released competitor snapshots show how previous entrants searched, filtered, checkpointed, and used the runtime. 3. Immutable Droyd datasets provide the exact problem inputs for reproducible hosted evaluation. See [Released Nova source](/competition-guides/nova-blueprint/released-source) for the folder-download workflow. Create a written `Competition Brief` before proposing an experiment. Do not infer competition absence from `droyd races`: Nova currently exposes an aggregate leaderboard, not Droyd race resources. Use `leaderboard --global`, `submission details`, `score-series`, and `submissions`. The runtime problem includes target and antitarget sequences through `NOVA_INPUT_PATH`; a miner must not fetch them over the network. Local source or sequence inspection is legitimate for debugging and reproducibility when tied to the immutable dataset or pinned provider revision. Mutable provider calls are for freshness checks and ingestion audits, never a submitted runtime dependency.