BayesARC connects scientific questions to accountable decisions.
It is not one AI model, one docking screen or one score. The programme is the persistent scientific context; tools are views and actions inside that context.
Define the therapeutic objective, target, modality, acceptance criteria and what would change the next action.
Keep COMPUTED, RETRIEVED, MEASURED and REVIEWED evidence distinct while allowing them to inform the same decision.
Record limitations, applicability, disagreement, missing evidence and sensitivity to assumptions instead of hiding them in a single confidence score.
Promote, hold, reject, run another computation, request an experiment or escalate to qualified human review.
Four failure modes the system is designed to prevent
Wrong target, species, variant, structure, chain, candidate or programme context.
A prediction or simulation silently becomes a “measured” value.
A result travels downstream without the method, version, assumptions or source that produced it.
A ranking, model score or retrieved record is presented as stronger biological proof than it actually provides.
The same programme_id, candidate identity and evidence history should remain connected across Discovery, Programme Command, experiments, Candidate OS, MIDD and later development work.
A good first run is bounded, inspectable and scientifically familiar.
Use a known target or benchmark programme. The goal is to understand the evidence chain before scaling compute.
- Define the programme and target.
Record programme name, disease/indication, discovery objective, target source, biological target and PDB/structure identifier. For custom targets, add species when it must be strict, optional UniProt, mutation and domain context before structure resolution.
- Resolve the target structure.
Find an experimental structure that actually corresponds to the requested biological target and context.
- Qualify the structure.
Review chain, biological assembly, pocket, ligand, cofactors/metals/waters, receptor preparation, protonation, docking box and controls.
- Run the intended design workflow.
Use small-molecule Discovery or Protein Engineering only after the required scientific inputs are qualified.
- Inspect evidence, not only rank.
Look at poses, property predictions, applicability, contradictions, provenance and failure reasons—not just a sorted list.
- Compare evidence and uncertainty.
Ask where evidence agrees, where it conflicts, what is missing and what next action would reduce the most important uncertainty.
- Use Programme Command to decide the next action.
Review blockers, candidate state, evidence gaps and human-review requirements in one programme context.
- Send bounded questions to experiments.
Define the assay question and acceptance criteria before CRO/lab execution; ingest returned data only after identity and QC checks.
- Nominate through gates.
Candidate OS can assemble the evidence contract and surface inconsistencies; final nomination remains an accountable human decision.
If receptor identity, chain, pocket, protonation, cofactor state or candidate identity is wrong, a perfectly completed docking run does not become valid evidence.
Define the exact biological and programme context that Discovery Mission Control will carry forward.
The current Discovery Campaign no longer treats a target name or PDB ID as enough context. Programme identity, biological identity and structure identity are separate fields, and each has a different scientific role.
| Current field / control | What the user enters or selects | How BayesARC uses it | Important boundary |
|---|---|---|---|
| Programme name | Name of the governed discovery effort. | Anchors the persistent programme, campaign, candidates and downstream evidence. | Changing pages should not create a new scientific identity. |
| Disease / indication | Therapeutic context. | Provides the disease frame for target and later evidence interpretation. | Indication context does not itself validate the target. |
| Discovery objective | Desired mechanism, target hypothesis and what a useful shortlist should support. | Defines the decision the campaign is trying to inform. | A ranking without an objective is not a decision framework. |
| Target source | Your target / PDB or Try a qualified example. | Chooses custom target onboarding versus the managed NDM-1 example profile. | Example readiness must not leak into a custom target. |
| Biological target | Protein/gene target label, optionally including a standard substitution such as KRAS G12C. | Seeds canonical identity resolution and structure matching. | Aliases are resolved canonically; ambiguous biology remains reviewable, not guessed. |
| PDB ID / structure identifier | Experimental structure selected for the programme. | Defines the exact deposited structure to validate and later qualify. | A real PDB is RETRIEVED evidence, not automatic docking readiness. |
| Species | Leave blank for deposited-PDB organism context, or enter a species explicitly. | Blank means no forced organism constraint; an entered species is a strict identity requirement. | BayesARC no longer silently assumes Homo sapiens for pathogen targets. |
| UniProt | Optional accession such as P01116. | When supplied, it becomes a strict accession/identity gate and helps canonical sequence mapping. | Do not enter a convenient accession unless it is the intended target identity. |
| Mutation | Optional standard substitution or other variant context. | Standard substitutions can be mapped to canonical/deposited sequence evidence. | Complex deletions, insertions, fusions, frameshifts or unresolved notation route to Target Qualification. |
| Domain | Optional functional region such as kinase domain. | Mapped against canonical UniProt features and deposited construct coverage when possible. | Domain words in a PDB title are not sufficient evidence by themselves. |
| Previously qualified core target | An existing qualified target profile when available. | Lets the programme reuse an existing governed qualification context instead of recreating it. | Reuse does not expand the approved scope beyond that qualification. |
programme_idPersists the scientific programme across Discovery, Programme Command, Candidate OS, experiments and later development.
funnel_idIdentifies the exact discovery campaign/funnel. Explicit URL context outranks stale browser state and is identity-checked before campaign state is trusted.
Biological target, PDB, species, UniProt, variant and domain must stay internally coherent before compute authority can be granted.
What does “Species: Auto from deposited PDB” mean?
If the Species field is blank, Discovery does not inject a human default. The structure resolver can use the organism deposited with the matching PDB entity as the identity context. If the user explicitly types a species, that value remains a strict fail-closed constraint. This is particularly important for pathogen targets such as HIV-1 protease, influenza neuraminidase, dengue proteins or bacterial enzymes.
Why is UniProt optional but strict?
A target can often be resolved from gene/protein identity plus deposited metadata. When a user supplies UniProt, BayesARC treats it as an explicit identity claim. A contradictory accession therefore blocks automatic acceptance rather than being ignored.
What happens with aliases such as ALK2 versus ACVR1?
Target Identity Passport v2 resolves canonical UniProt identity and recognized aliases before comparing deposited structure identity. Exact alias normalization prevents a common name from being rejected merely because the PDB uses the canonical gene name. The canonical identity is still recorded so downstream evidence does not drift between aliases.
Resolve the target to the correct deposited protein entity before asking whether the receptor is fit for docking.
Discovery now uses a formal Target Identity Passport (TIP-2) to separate identity evidence from receptor qualification. The passport is built from UniProt and RCSB/PDB evidence and remains fail-closed for biology it cannot safely resolve.
The programme states what biological object it intends to use.
Retrieved evidence with provenance; execution is still not authorized.
| Passport element | What is checked / recorded | Why it matters |
|---|---|---|
| Canonical target | Primary gene/protein identity plus recognized aliases from UniProt. | Prevents alias-only false mismatches and preserves one canonical identity. |
| Species / taxonomy | Requested organism versus deposited organism/taxonomy. | Prevents a valid PDB from being used under the wrong species context. |
| UniProt / isoform | Reference-sequence identifiers and strict requested accession when supplied. | Protects against a same-name but wrong sequence/isoform context. |
| Variant | Structured mutation annotation first, then mapped deposited sequence via UniProt alignment; title text is only a limited fallback. | A variant should not be accepted because its name merely appears in descriptive text. |
| Domain / construct | Canonical domain feature, residue interval, deposited construct coverage and requested-residue coverage. | Answers whether the structure actually contains the biology the user requested. |
| Polymer entity / chains | Actual deposited polymer entity IDs, auth/asym chains, sequence, sequence length and sequence hash. | Avoids assuming that the first protein-looking entity is the intended target. |
| Structure context | Experimental method, resolution, ligands, cofactors, metals and retained structural context. | Provides the facts needed for the later qualification review. |
| Provenance | RCSB/UniProt sources, retrieval time, passport fingerprint and algorithm version. | Makes identity evidence inspectable and reproducible. |
How to interpret Passport status
The target/PDB relationship is supported, but the passport still requires receptor/experiment-context review before production compute.
Complex variants, unresolved mappings, assembly questions or other target-specific biology must go to human Target Qualification.
Correct the target, PDB, species, UniProt, variant or domain. Do not bypass the mismatch.
TIP records retrieved canonical identity, aliases, sequence/construct mapping and structural context. It does not approve biological assembly, pocket choice, protonation, cofactor retention, receptor preparation, docking controls or mechanism. Those remain a separate qualified-human gate.
Which variants can be handled automatically?
Standard amino-acid substitutions such as G12C, T790M, L858R, V600E or R206H can be parsed and mapped when the canonical/deposited evidence supports them. Complex deletions, insertions, duplications, frameshifts, splice events, fusions or unresolved notation are intentionally routed to Target Qualification rather than guessed.
What if the mutation annotation conflicts with the mapped sequence?
The conflict stays visible and blocks automatic scientific eligibility. Structured deposited mutation annotation has higher authority than title text, while mapped deposited sequence provides an independent check. Conflicting evidence is a review problem, not something to average away.
Identity says “this is the intended structure”; qualification asks “is this structure fit for this computational question?”
Discovery keeps core docking readiness separate from optional advanced-physics qualification. Planning can continue while production compute remains fail-closed.
Confirm the exact target entity, chain/assembly, construct boundaries, sequence/isoform context and relevant variant/domain.
Confirm which subunits/partners are biologically relevant and whether the functional pocket depends on an interface.
Define the intended binding site and preserve the evidence used to locate it.
Retain or remove catalytic metals, cofactors and relevant waters with an explicit rationale.
Document protonation, missing residues/atoms, alternate conformations, cleanup and prepared-receptor provenance.
Define the search space, pose rules and appropriate redocking/reference controls.
A qualified reviewer approves the specific receptor/protocol context before production docking is authorized.
Discovery searches for an existing non-revoked request for the same target + PDB first and reopens it when present; it creates a new request only when needed. Opening the workspace does not itself approve the gate.
Advanced physics options shown in Discovery
Use optional MD/MM-GBSA only when the selected target has a qualified protocol for that context.
Complete the governed core discovery campaign without advanced physics.
Flag target-specific qualification work. Installed software does not make advanced physics scientifically valid by itself.
It does not mean every advanced method is qualified, the receptor is universally correct, or a docking result becomes measured binding evidence.
The current Discovery Campaign is a state-driven scientific workspace, not a static Plan/Run/Review form.
Mission Control uses one canonical campaign state for the workflow rail, current decision, blockers and next action. A later-stage programme should not be sent back to generic target readiness unless readiness has genuinely become invalid.
Current campaign presets
| Preset | Generated / intake | Fast real Vina | Accurate | Deep | Review intent |
|---|---|---|---|---|---|
| Verified 100 · client pilot | 100 | 100 | 30 | 10 | Up to 5 for integrated evidence + human review. |
| Pilot 1K | 1,000 | 1,000 | 100 | 30 | Broader pilot with progressively deeper compute. |
| Focused 20K | 20,000 | 2,000 | 500 | 50 | Large generation/intake with bounded docking expenditure. |
| Advanced 100K | 100,000 | 5,000 | 1,000 | 100 | Large-scale design with progressively concentrated compute. |
The displayed plan also reports estimated core compute, internal allocation basis, review-shortlist size and optional physics state before launch approval.
Launch review freezes target context, scientific plan and compute allocation before execution. Approval authorizes computational/database work only.
Fast, Accurate and Deep Vina stages preserve ligand-level checkpoint/progress state so recovery does not silently restart scientific history.
Inspect target-specific structural requirements separately from raw score ranking.
Keep ADMET, exact identity, novelty/external evidence, synthesis feasibility, safety and other evidence domains separate and traceable.
Shortlisted candidates must have persistent identity/evidence records before an authenticated scientific decision is recorded.
The computational leader can guide inspection, but promotion/nomination is a separate authenticated human decision.
How to read Vina and Vinardo correctly
| Evidence state | Meaning in Review | Blocker? |
|---|---|---|
| Vina available + Vinardo available | Docking evidence package: COMPLETE. Primary docking and orthogonal/alternative rescoring are both present. | Not for this evidence item. |
| Vina available + Vinardo missing, Vinardo optional | PARTIAL. Primary docking evidence exists; optional rescoring is absent. | No. Optional evidence must not be counted as a required blocker. |
| Vina available + Vinardo missing, Vinardo protocol-required | ACTION REQUIRED. The primary result exists but the selected protocol requires the orthogonal rescoring channel. | Yes, until the required rescoring is completed or the governed protocol changes. |
| Vina missing | ACTION REQUIRED. Primary docking evidence is absent. | Yes for a docking-dependent review path. |
They are separate computational channels. The UI now distinguishes primary Vina from protocol-dependent Vinardo instead of labelling all missing rescoring as “no docking evidence.” Neither score is a measured Kd, Ki or IC50.
Decision-domain readiness shown for each shortlisted candidate
Vina/Vinardo state and provenance.
Whether target-specific pose rules/validation are recorded.
Persistent candidate identity is required before authenticated decision authority.
Candidate identity and traceable external evidence remain separate from docking.
Predictions remain COMPUTED and carry applicability limits.
Generated or retrieved routes do not prove material has been made.
Required only when the programme/protocol qualifies an ensemble path.
Absent measurement should remain absent rather than being inferred from computation.
Authenticated reviewer rationale remains distinct from computational ranking.
At Review, the order is: resolve any genuine readiness invalidation → register shortlisted Candidate Passports → complete required integrated evidence → record qualified human review. The current-decision banner, workflow rail and Decision & Readiness panel should all derive from the same state.
The same evidence discipline applies when the design object is a sequence or biomolecule.
Binder, antibody, nanobody, peptide and sequence-variant workflows should preserve identity, model provenance, uncertainty and experimental boundaries.
| Stage | Scientific question | Typical work | How to interpret it |
|---|---|---|---|
| Target context | What protein/interface/epitope are we designing against? | Target, sequence, structure and interface definition. | Identity and biological context must be explicit. |
| Design | Which sequence/binder hypotheses should we test? | Binder, antibody, nanobody, peptide or sequence-variant proposal. | Generated sequences are hypotheses. |
| Structure / complex | Is the fold or interaction geometrically plausible? | Structure prediction or co-folding adapters where configured. | Predicted confidence/geometry is COMPUTED evidence. |
| Sequence engineering | Can affinity, selectivity, stability or liabilities improve? | Inverse folding, sequence redesign and mutation hypotheses. | Model-score changes require experimental confirmation. |
| Developability | Is the design practical as a therapeutic? | Stability, aggregation/liability, immunogenicity-risk and manufacturability review. | Predictions prioritize assays; they do not replace them. |
| Review | Which designs should move to experiments? | Pareto comparison, design passport and human review. | Promotion should preserve trade-offs and uncertainty. |
Use the Capabilities page to distinguish current runtime capability from external integration paths or roadmap items. Do not infer that every listed model family is executing in production merely because it is represented in the product architecture.
Do the results agree, conflict or remain inconclusive—and why?
Evidence comparison is not simply putting values in the same table. BayesARC should preserve what each result actually means, compare claims that are scientifically comparable, surface contradictions and show what uncertainty still matters to the decision.
Algorithm/model output
Docking, ADMET prediction, PBPK simulation, structure prediction or other calculation. Record method/model, version, inputs and applicability.
Traceable external source
RCSB PDB, ChEMBL, PubChem, UniProt, literature or another curated source. Record identifier, retrieval date and contextual relevance.
Observed assay/study result
CRO/internal assay, PK, solubility, safety or another controlled observation. Require identity, method, units, conditions, source and QC.
Human interpretation/decision
Target approval, candidate promotion, contradiction resolution or nomination. Records accountability; it is not itself a measurement.
A docking score, hERG prediction, literature statement and CRO IC50 answer different questions. They can inform the same decision, but they should not lose their evidence class, context or uncertainty just because they appear on the same candidate card.
8.1 A disciplined comparison workflow
Example: “Candidate BP-017 is likely to engage the intended EGFR pocket.” Be specific enough that evidence can actually support or contradict it.
Keep docking/ADMET as COMPUTED, databases/literature as RETRIEVED, assays as MEASURED and interpretations as REVIEWED.
Check units, endpoint definitions, assay conditions, species, receptor state, candidate identity and model context before interpreting agreement.
Ask whether independent methods or sources support the same qualitative conclusion—not whether their numbers look similar.
Do not let a favorable model prediction silently hide an unfavorable measured result or vice versa. Keep both and investigate the discrepancy.
Identify whether uncertainty comes from the model, structure, pose, experimental method, source relevance, missing evidence or the decision itself.
Prefer the smallest computation, review or experiment that can meaningfully reduce a decision-critical uncertainty.
8.2 Types of uncertainty BayesARC users should recognize
Training-domain limitations, calibration, model version, endpoint definition or out-of-distribution chemistry can weaken interpretation.
Missing residues, uncertain side chains, predicted low-confidence regions, ambiguous assembly or cofactor treatment can change the binding environment.
Several similarly scored poses, clashes or inconsistent interactions can indicate ambiguous pose hypotheses.
A compound ranked #2 in one qualified receptor and #34 in another may be conformation-sensitive rather than robust.
Replicate variability, controls, assay format, units, QC or batch effects can limit confidence even when the evidence class is MEASURED.
Different species, constructs, assay conditions, publications or older methods can make apparently supportive literature indirect.
A discovery prioritization can tolerate more uncertainty than candidate nomination, FIH dose rationale or a regulatory claim.
The same candidate can have low identity uncertainty, moderate pose uncertainty, high hERG-model uncertainty and strong confidence in a measured solubility result at the same time.
8.3 Illustrative candidate example
Candidate BP-017 · evidence comparison
Supports target-engagement hypothesis in the primary qualified receptor.
Suggests meaningful receptor-conformation sensitivity; robustness is not established.
Permeability signal is encouraging, but hERG confidence is limited by model context.
Measured potency is modest and experimental precision should be reviewed before strong claims.
Computational evidence supports possible target engagement, but cross-structure instability and modest/variable measured potency prevent a “confirmed strong hit” conclusion.
Next action: review assay QC and pose robustness; consider a focused confirmatory experiment rather than simply increasing the composite score.8.4 How BayesARC should record a scientific claim
Primary-receptor Vina pose; alternative rescoring; plausible hinge interaction.
Poor ranking in one qualified receptor conformation; measured potency only modest.
Mostly COMPUTED + one MEASURED potency result.
Moderate; driven by receptor-conformation sensitivity and assay variability.
Resolve the most decision-critical uncertainty with targeted review/measurement.
8.5 Minimum provenance questions
- What exactly is the claim?
“Predicted low hERG risk” is different from “measured hERG IC50 = X”.
- What produced it?
Model, database, paper, assay, study, reviewer or external partner.
- Which version and inputs?
Model version, receptor structure, candidate identity, source version and parameter set.
- Where does it apply?
Chemical space, species, assay condition, receptor state, population or model context.
- What decision can it support?
Hypothesis generation, prioritization, gate satisfaction or accountable final review.
QA fixtures should remain explicitly marked QA_ONLY / SIMULATED and should not silently enter production decision exports.
Send a defined uncertainty to the lab—not an unbounded request for “more data.”
BayesARC is software. Laboratory work is performed by qualified internal laboratories or external CRO/partners and returned as traceable evidence.
- Define the experimental question.
State what uncertainty the assay should resolve and which candidates and controls are included.
- Define method and acceptance criteria.
Record assay type, units, conditions, controls, replicates, QC requirements and interpretation boundary before execution.
- Create controlled partner handoff.
Send candidate identities, protocol context and required return fields without losing programme linkage.
- Ingest returned results.
Map every value back to the correct candidate, method and source file.
- QC before evidence promotion.
Check units, identity, controls, quality criteria and completeness. A returned spreadsheet is not automatically trusted MEASURED evidence.
- Human review.
Approve, reject or qualify the result for programme use while preserving the original record and limitations.
If an assay has not been performed or a scientific service is unavailable, the correct state is missing, pending or failed—not a model-generated substitute entered as MEASURED evidence.
SAR and Design–Make–Test–Learn turn isolated hits into an evidence-generating programme.
The objective is not to maximize one property. It is to learn which chemical changes improve the programme's multi-objective profile.
Propose a molecular change that tests a scientific hypothesis: potency, selectivity, exposure, solubility, safety or another objective.
Plan or execute synthesis. Keep route feasibility separate from actual material production and analytical confirmation.
Generate relevant measured evidence using controlled methods, authoritative candidate identity and appropriate QC.
Update the programme hypothesis from successes, failures and contradictions. Negative data should remain part of the learning record.
What is SAR?
Structure–activity relationship is the relationship between molecular changes and changes in biological activity or other properties. SAR is most meaningful when compounds belong to a coherent chemical series and the compared assays/conditions are comparable. Mixing unrelated scaffolds, different assay formats or predicted and measured endpoints without context can create misleading trends.
Why is optimization multi-objective?
A molecule with the strongest potency may have poor solubility, rapid clearance, safety liabilities, difficult synthesis or weak selectivity. BayesARC should therefore make trade-offs visible rather than hiding them behind one composite rank. Pareto-style review is useful when several candidates represent different acceptable trade-offs.
Computational rank prioritizes inspection; it does not nominate a development candidate.
The current decision path requires persistent candidate identity, the required evidence contract, explicit DCP state where applicable, and authenticated human authority.
Anchor the shortlisted candidate to persistent identity, provenance, evidence versions, limitations and review history.
Resolve required docking, target-aware validation, exact identity, ADMET/safety, synthesis and other programme-specific evidence while preserving optional versus required semantics.
A generated DCP starts as planning-only. Establishing it creates an immutable revision such as R1/R2 that can govern nomination criteria.
Conflicting predictions, retrieved evidence and measurements remain visible and must be bounded or explicitly accepted for the stage.
A qualified reviewer records rationale and authority. Computational leader and human nomination are deliberately separate fields.
DCP state in the current product
Useful for defining intended criteria and evidence needs. A draft does not silently become nomination authority.
Once explicitly established, the DCP becomes a versioned programme criterion set (R1, R2, …).
Final nomination cannot rely on an unestablished planning draft when authoritative DCP criteria are required.
Required gates are satisfied, evidence is current, material contradictions are bounded and accountable rationale is recorded.
Progress is allowed only under explicit conditions with named unresolved risks and follow-up work.
Important evidence, Candidate Passport registration, DCP authority or required review is missing/stale/contradictory.
The candidate no longer supports the programme hypothesis or has an unacceptable risk/benefit profile. Preserve the negative learning.
BayesARC can rank, compare and expose the evidence contract. Final promotion/nomination remains an authenticated, accountable human decision and must preserve the underlying evidence state.
Carry the evidence spine into development, MIDD, regulatory work and lifecycle decisions.
Nomination should not erase the assumptions and provenance generated during discovery. Later stages require stronger evidence and different context-of-use boundaries.
| Workspace | Main question | Examples | Important boundary |
|---|---|---|---|
| Preclinical Development | Can this become a viable development asset? | DMPK, safety, exposure, developability, CMC/FIH context. | Predictions do not replace validated studies. |
| Clinical Development + MIDD | What model-informed evidence supports dose/regimen and development decisions? | PBPK, PopPK, PK/PD, dose rationale, assumptions and diagnostics. | Models require qualification, appropriate data and pharmacometrics review. |
| Regulatory & Approval | Which claims are supported by which evidence? | Evidence mapping, claim context and submission readiness. | Regulatory accountability remains with qualified teams. |
| Lifecycle Management | How should the asset evolve? | New indications, formulations, evidence updates and lifecycle opportunities. | Version history should remain visible rather than rewriting past decisions. |
The acceptable uncertainty for early ranking is not the acceptable uncertainty for candidate nomination, clinical dose selection or a regulatory claim.
Open a workspace for a defined decision—not simply because it exists.
Runtime availability and maturity can vary by configured backend/service. Use the Capabilities page for current implementation status.
Programme fields, Target Identity Passport, target qualification, governed Vina funnel, integrated evidence, Candidate Passports and human review.
Define → Qualify → Plan → Run → Review DesignProtein EngineeringSequence/structure context, binder or variant design, evaluation and developability review.
Design passport CommandProgramme CommandProgramme state, blockers, candidate comparison, evidence gaps and next actions.
Next governed action ExperimentsStudy ExecutionAssay/study plan, protocol context, controls and acceptance criteria.
Execution-ready study PartnerCRO / Partner HandoffControlled experimental package and traceable returned data.
Partner evidence package QCExperimental ReviewReview returned results before promotion to trusted measured evidence.
Reviewed measurement EvidenceCandidate PassportIdentity, provenance, versions, limitations, contradictions and history.
Auditable record OptimizeLead OptimizationSAR, series comparison and Design–Make–Test–Learn prioritization.
Promotion rationale NominateCandidate OSDMPK, PK/TK, safety, developability, CMC and nomination gates.
Nominate / hold / kill MIDDMIDD Command CenterPBPK, PopPK, PK/PD context, dose rationale, assumptions and diagnostics.
Model-informed package RegulatoryRegulatory & ApprovalClaims, evidence mapping and submission-readiness context.
Traceable claim evidence LifecycleLifecycle ManagementEvidence evolution and post-nomination/approval opportunities.
Lifecycle decision historyResolve the identity, protocol or evidence reason for failure; do not bypass the gate.
Missing, partial, unavailable and review-required states are meaningful scientific states. The product should surface the exact blocker rather than forcing every card to green.
Pathogen target is being checked as Homo sapiens
This was a frontend context bug and has been removed. The Species field is blank by default for custom target resolution. Blank means no forced species and allows deposited-PDB organism context; an explicitly entered species remains strict. If an old browser session still displays a human default, reload the current Discovery bundle and re-enter the programme context rather than accepting the mismatch.
The PDB exists but target–structure identity validation fails
Inspect the Target Identity Passport checks: canonical protein/alias, species/taxonomy, UniProt, variant, domain and deposited construct. A valid PDB can still be wrong for the requested programme. Correct the context instead of weakening the validator.
ALK2, ACVR1 or another common alias produces a mismatch
Current TIP-2 performs canonical UniProt alias resolution. Check whether the requested alias resolves to the intended canonical gene/protein and whether any supplied UniProt accession agrees. Exact canonicalization is preferred over substring matching.
A mutation is in the title but Variant still requires review
This can be intentional. Structured deposited mutation annotation and mapped deposited sequence have higher evidentiary authority than descriptive title text. Complex variants and unresolved notation route to Target Qualification.
The domain is biologically present but domain validation fails
Current TIP uses canonical UniProt feature/residue mapping and deposited construct coverage when available. Check whether the requested feature name maps to a canonical region and whether the PDB construct covers enough of that interval. Text-only domain wording is insufficient for automatic confirmation.
Target readiness says “Qualification required”
Keep the Target Readiness step open and use Create / reopen Target Qualification. The product should reopen an existing matching target/PDB request before creating another. Planning may continue, but production compute remains blocked until the qualified review approves the required scope.
Vina has a score but Docking evidence says Vinardo/rescoring incomplete
Vina and Vinardo are separate computational evidence channels. Vina present + optional Vinardo missing should be PARTIAL, not “no docking evidence.” If the selected protocol explicitly requires Vinardo, its absence is correctly an action-required blocker.
Review shows 0 Candidate Passports registered
Register the shortlisted candidates before recording an authenticated human decision. Candidate Passport registration anchors identity and evidence history; it does not itself approve the candidate.
Next Best Action and workflow stage appear inconsistent
The current Mission Control design derives the stepper, current decision and Decision & Readiness guidance from canonical campaign state. If guidance still contradicts the persisted state after a current-bundle reload, treat it as a software state bug and preserve the underlying scientific evidence rather than manually forcing a stage.
Nominate is disabled
Check Candidate Passport registration, required evidence domains, contradictions, reviewer authority and DCP status. A generated DCP is planning-only until explicitly established; missing required authority should remain fail-closed.
A scientific service is unavailable
Preserve the unavailable/failed state and error provenance, then retry when appropriate. Never substitute a default or fabricated scientific value just to keep the workflow green.
Practical definitions for terms users see in BayesARC.
The important question is not only “what is this term?” but “what does it mean for the decision?”
| Term | Meaning in BayesARC | Why it matters |
|---|---|---|
| Target | Protein, gene product or biological entity the programme intends to modulate. | Wrong target identity invalidates downstream structure and evidence interpretation. |
| PDB structure | An experimentally deposited macromolecular structure retrieved from RCSB PDB. | Retrieved evidence; may still need qualification and preparation. |
| Structure resolution | Finding and verifying which 3D structure corresponds to the requested target/context. | Answers “Which structure should we use?” |
| Protein chain | One continuous polypeptide in a structural file, usually labelled A, B, C, etc. | Wrong chain can invalidate docking. |
| Biological assembly | Biologically relevant combination of protein chains/subunits. | Functional pockets can depend on oligomeric or partner context. |
| Structure qualification | Review of whether the selected structure is fit and prepared for the intended computation. | Answers “Can we scientifically use this structure here?” |
| Binding pocket | 3D region where the ligand is expected to bind. | Defines the structural hypothesis and docking search region. |
| Reference ligand | Known ligand used to understand the pocket and sometimes test redocking. | Anchors a binding context but does not guarantee the same mode for new chemistry. |
| Cofactor / metal | Non-protein component required for structure or catalysis, e.g. Zn, Mg, heme. | Incorrect treatment can change the binding environment. |
| Structural water | Resolved water that may participate in protein–ligand interactions. | Retention/removal should be scientifically justified. |
| Receptor preparation | Preparing the selected structure for a computational engine while recording changes. | Prevents hidden preprocessing assumptions. |
| Protonation | Assignment of hydrogen/charge states to ionizable groups. | Can materially change electrostatics and interactions. |
| Docking box | 3D volume the docking engine searches. | Wrong placement can make a successful run irrelevant. |
| Docking pose | Predicted orientation/conformation of a ligand in the receptor. | A hypothesis, not an experimentally observed structure. |
| Docking score | Computational ranking function for poses/molecules. | Not a measured Kd, Ki or IC50. |
| Redocking | Re-docking a known ligand to test whether the protocol recovers a plausible known pose. | Protocol-context check, not universal validation. |
| Ensemble docking | Docking against multiple qualified receptor conformations. | Reveals conformation sensitivity and ranking robustness. |
| Evidence comparison | Structured assessment of whether relevant evidence supports, contradicts or leaves a claim unresolved. | Prevents incompatible evidence from being collapsed into a misleading score. |
| Uncertainty | What is unknown, unstable, assumption-sensitive or insufficiently supported for a specific claim/context. | Determines whether more review, computation or measurement is needed. |
| Applicability domain | Region/context in which a model's output is considered interpretable. | Predictions outside domain should carry weaker decision weight. |
| ADMET | Absorption, Distribution, Metabolism, Excretion and Toxicity-related properties. | Helps identify development liabilities and prioritize experiments. |
| SAR | Structure–activity relationship. | Links molecular changes to changes in activity/properties. |
| DMTL | Design–Make–Test–Learn cycle. | Organizes optimization as iterative hypothesis testing. |
| Candidate Passport | Candidate identity, evidence, provenance, limitations and decision history. | Makes promotion/nomination rationale inspectable. |
| Gate | Declared condition that must be reviewed before progression. | Prevents missing or wrong-class evidence from silently passing. |
| COMPUTED | Output generated by an algorithm or model. | Useful for prediction/prioritization within stated applicability. |
| RETRIEVED | Evidence imported from a traceable external source. | Must be checked for relevance, version and context. |
| MEASURED | Observed assay/study result with traceable method and QC. | Can satisfy experimental gates when identity and quality are established. |
| REVIEWED | Human interpretation or governed decision. | Records accountability but is not a measurement. |
| Target Identity Passport (TIP) | Retrieved canonical target/structure identity record including aliases, species, UniProt, variant/domain, construct mapping and provenance. | Confirms what biological structure is being considered; does not qualify docking readiness. |
| Target Qualification | Human-reviewed target/receptor/protocol qualification for the intended computational context. | Controls production compute authority for chain/assembly, pocket, preparation, cofactors, box and controls. |
| Candidate Passport | Persistent candidate identity/evidence/provenance record. | Required registration anchors shortlisted evidence before authenticated decision recording. |
| DCP | Decision Criteria Profile; planning draft becomes authoritative only after explicit establishment as an immutable revision. | Prevents nomination criteria from silently changing after results are seen. |
| Vina | Primary AutoDock Vina docking evidence channel. | A computational ranking/pose signal, not measured affinity. |
| Vinardo | Alternative/orthogonal rescoring channel when included by the selected protocol. | Its absence is a blocker only when protocol-required; otherwise the docking package can remain partial. |
| MIDD | Model-Informed Drug Development. | Uses qualified quantitative models and data to support development decisions. |
| PBPK | Physiologically Based Pharmacokinetic modelling. | Mechanistically represents disposition using physiology and drug-specific parameters. |
| PopPK | Population Pharmacokinetic modelling. | Characterizes PK variability using observed data and covariates. |
| PK/PD | Pharmacokinetic / pharmacodynamic modelling. | Relates exposure to biological or clinical effect. |
Use the web manual for depth; keep the PDF for fast orientation.
The living web manual contains the detailed scientific explanations. The PDF remains a concise A4 reference for quick start, lifecycle, evidence classes, candidate decisions and troubleshooting.