# Profile catalogue The six profiles in standard version `0`. Each one is an independently versioned file. A released profile is never rewritten; a meaningful correction becomes a new version. Each entry below gives what the profile carries, the representation a port has to declare to match it, the checker that runs against live values, and what passing the checker does *not* establish. Inspect whatever your installed runtime actually ships: ```bash biosimulant compatibility profiles biosimulant compatibility show protein.sequence/v1 ``` ## `protein.sequence/v1` One protein sequence represented as amino-acid residue symbols. | | | | --- | --- | | Representation | scalar `str`, format `sequence` | | Checker | `protein_sequence` | | Context fields | `species`, `identifier_namespace` | Passing does not establish that the sequence is biologically correct. Protein identity is not established unless an identifier namespace is declared. The profile does not translate nucleotide sequences. ## `chemical.smiles/v1` One molecule represented as a SMILES string. | | | | --- | --- | | Representation | scalar `str`, format `smiles` | | Checker | `molecular_smiles` | | Context fields | `identifier_namespace` | It does not establish tautomer, salt, protonation or canonicalization equivalence, and it does not establish that two valid strings identify the same molecule. It accepts one molecule and excludes reaction SMILES. A compatible string is not evidence that the intended molecule was supplied. ## `protein.multiple-sequence-alignment/v1` A protein multiple-sequence alignment in A3M form, supplied as a file. | | | | --- | --- | | Representation | scalar `str`, file value, format `a3m` | | Checker | `a3m_file` | | Context fields | `species`, `identifier_namespace` | Passing does not establish alignment quality or evolutionary appropriateness. Agreement between the alignment query and a separate protein input stays the model wrapper's responsibility. ## `protein-ligand.complex-structure-mmcif/v1` A predicted three-dimensional protein-ligand complex as an mmCIF file. | | | | --- | --- | | Representation | scalar `str`, file value, format `mmcif` | | Checker | `mmcif_file` | | Context fields | none | Passing does not establish structural accuracy or biological relevance. Predicted and experimentally determined structures are not interchangeable under this profile. ## `boltz.binding-probability/v1` The Boltz affinity model's `affinity_probability_binary` output: its reported probability that the specified ligand binds the specified protein target. | | | | --- | --- | | Representation | scalar `float32`/`float64`, unit `1` | | Checker | `probability` | | Context fields | none | This is a model prediction, not experimental evidence, and it must not be read as a clinical probability. Another model family must not claim this profile unless its output has the same reviewed meaning. ## `boltz.log10-ic50-micromolar/v1` The Boltz affinity model's `affinity_pred_value` output: log10(IC50) with IC50 in micromolar. Lower values imply stronger predicted affinity. | | | | --- | --- | | Representation | scalar `float32`/`float64`, unit `1` | | Checker | `finite_number` | | Context fields | none | This value is **not** pIC50, and it is a prediction rather than a measured IC50. It is not compatible with another concentration basis or logarithmic convention without an explicit adapter. ## Model-family profiles Two of the six name a model family. `affinity_pred_value` means what Boltz's documentation says it means, and a number from another model under another convention is a different quantity even when both are floats. Until someone reviews a cross-family meaning, naming the family is the honest option. ## Next steps - [Use it in a model](/standards/model-compatibility/model-yaml): map a port to a profile - [Propose a profile](/standards/model-compatibility/propose-profile): when none of these fit - [Boltz example](/standards/model-compatibility/boltz): all six in one lab