Constraints
Exact properties, presets, structures, relationships, fidelity, units, and coverage.
Constraints determine eligibility. Registry IDs and typed operators replace ambiguous display names and free-form expressions.
{
"type": "property",
"property_id": "rdkit.mol_wt",
"operator": "gt",
"value": 250,
"units": "Da",
"required_fidelity": "exact_product",
"missing": "reject"
}Scalar operators are gt, gte, lt, lte, and range; range endpoints explicitly record
inclusivity. Units are validated against registry metadata and normalized before planning.
lipinski-ro5/v1 expands to MW ≤ 500 Da, Crippen cLogP ≤ 5, HBD ≤ 5, and HBA ≤ 10. It includes no
unannounced polarity, flexibility, alert, or “lead-like” rule. Explicit constraints intersect with
preset constraints; an empty intersection is a validation error.
Structure conditions use shallow all, thresholded any, and none groups with inline typed
queries or reviewed pattern_id values. Relationship constraints state reference-relative meaning,
such as a different Bemis–Murcko scaffold. Validation reports each condition as exact pushdown,
conservative approximate pushdown plus exact final verification, post-assembly only, or unsupported.
Approximation may broaden or accelerate candidate acquisition. Every normal hard constraint remains
authoritative on the assembled product, with missing: reject; there is no public switch that turns
off exact final verification.