Fast-Fail vs Standard vs Deep

Use this page to explain packaging clearly.

These tiers describe how much computational analysis is performed, how much evidence is generated, and how much technical depth is applied.

They are not interchangeable, and they are not just pricing labels.

• Fast-Fail is a rapid screening tier for early triage.
• Standard is the default full audit tier for most core diligence workflows.
• Deep is the advanced computational tier for cases where higher-resolution technical investigation is justified.

Important boundary

None of these tiers replaces broader real-world diligence.

They are computational audit packages designed to structure evidence, surface risk, and support judgment.
They do not eliminate the need for:

• scientific review
• domain-expert interpretation
• follow-up investigation
• experimental validation where appropriate
• legal, regulatory, clinical, operational, or investment diligence
• decision-owner accountability

The output should be used as a decision support artifact, not as a substitute for full downstream investigation.

What changes across tiers

The main differences are:

• Scope of analysis
• Turnaround expectations
• Evidence depth
• Computational intensity
• Technical resolution
• Ideal use cases

Compare

Dimension	Fast-Fail	Standard	Deep
Purpose	Rapid first-pass screening	Full core computational audit	Advanced computational investigation for technically harder or higher-stakes cases
Primary question	Is this worth further attention right now?	What does the core computational evidence and risk picture look like?	Do advanced methods materially improve technical understanding of unresolved questions?
Scope of analysis	Focused, limited-scope screen designed to surface major issues quickly	Full core audit package across the standard evidence stack	Standard package plus selected advanced deep-tool integrations and simulation-heavy modules
Evidence depth	Concise first-pass evidence	Full core evidence-linked audit artifact	Expanded, higher-resolution computational evidence for specific unresolved questions
Computational depth	Low to moderate	Moderate and comprehensive within the core stack	High, often including simulation, structural, thermodynamic, kinetic, or quantum-informed analysis
Turnaround	Fastest	Standard delivery window	Longest, depending on selected deep modules and compute demands
Output style	Screening-oriented summary and next-step guidance	Full sealed audit artifact with broader technical support	Expanded audit package with advanced module outputs and deeper technical interpretation
Best for	Early triage, target filtering, lower-cost first look	Core diligence support, internal review, partnership screening, portfolio support	Mechanistic ambiguity, structural uncertainty, simulation-sensitive cases, or programs where added computational depth is justified
What it does not do	Does not replace full expert review or downstream diligence	Does not replace full expert review or downstream diligence	Does not replace full expert review or downstream diligence
Decision implication	Helps guide whether more work is warranted	Helps structure a fuller computational diligence view	Helps resolve questions the core package cannot answer with enough technical resolution

Deep means advanced tool integrations

Deep is justified when the question cannot be answered well enough from the core audit stack alone.

This usually means adding one or more advanced computational modules, such as:

• molecular docking
• molecular dynamics
• binding kinetics
• interaction stability analysis
• solvation thermodynamics
• solvent mapping
• QM/MM analysis
• CUDA Quantum or other quantum-informed target audit methods
• cryptic pocket analysis
• dynamics / normal mode analysis
• physics-based binding analysis
• proteomics validation extensions
• y-scramble or advanced validation modules
• other specialized deep-tool workflows as supported by the package

Deep is not simply “more Standard.”
It is the tier used when the case requires different classes of computational evidence.

When Fast-Fail is sufficient

Fast-Fail is usually sufficient when:

• the target is still in early screening
• the goal is to eliminate weak candidates quickly
• a fast first-pass assessment is more important than broader analysis
• the decision is still internal and provisional
• the user wants an initial technical screen before committing to a larger workflow

Fast-Fail is not appropriate when the situation calls for broader review, more technical development, or deeper follow-up work.

When Standard is sufficient

Standard is the right default in most core audit cases.

It is usually sufficient when:

• a full core computational audit package is needed
• the decision needs to be documented, shared, or reviewed internally
• the standard evidence stack can adequately characterize the main technical risk picture
• the case does not require simulation-heavy or specialized advanced modules
• the user needs a serious computational diligence artifact as part of a larger diligence process

Standard is the baseline full package for core computational audit work.
It still does not replace broader expert investigation or downstream diligence.

When Deep is justified

Deep is justified when the core package leaves a meaningful unresolved technical question.

Typical triggers include:

• structural or mechanistic ambiguity that cannot be resolved well enough with the standard stack
• a need for simulation-based evidence rather than primarily static or literature-linked evidence
• higher-stakes situations where additional computational resolution is worth the extra time and cost
• cases involving binding behavior, conformational dynamics, solvent effects, kinetics, cryptic pockets, or quantum-relevant questions
• scientific review contexts where a stronger technical record is needed
• programs where unresolved uncertainty remains materially important after the standard package

Deep should be used deliberately.
It is warranted when added computational depth is likely to produce decision-relevant technical evidence, not when a user simply wants the largest package.

Keep category separate

Fast-Fail, Standard, and Deep describe execution profile and computational evidence depth.

They do not replace category-routing policy.

A package must still be routed through the correct scientific category before execution assumptions are made.

Before deciding that Deep is needed, also confirm which scientific category the staged package actually supports in Category Policy and Routing.

Decision rule

Use the following rule of thumb:

• Choose Fast-Fail when speed and early triage matter most.
• Choose Standard when a full core computational audit is needed.
• Choose Deep when advanced computational methods are required to investigate unresolved technical questions.

In all cases, users should still conduct the broader expert, experimental, operational, legal, and strategic diligence appropriate to the decision.

Practical guidance

If the user is unsure:

• start with Fast-Fail for early filtering and limited-scope screening
• start with Standard when a full core computational audit is needed
• escalate to Deep when advanced modules are necessary to investigate structural, kinetic, thermodynamic, mechanistic, or quantum-level uncertainty

Simple summary

• Fast-Fail = rapid screening computational audit
• Standard = full core computational audit
• Deep = advanced computational evidence tier

None of these tiers is a substitute for broader real-world diligence, expert review, or further investigation.