# BindingDB–AlphaFold cohort-feasibility audit

This audit tests whether the public data can support the predeclared study:

> Did AlphaFold shorten the path from a protein target to an experimentally measured potent ligand?

It does **not** estimate an AlphaFold effect.

## Frozen scope

The audit uses the latest available BindingDB article-curated TSV release rather than combining journal articles, patents, ChEMBL imports, and other source types. The exact release, URL, byte count, and SHA-256 are recorded in `feasibility.json`:

```text
feasibility.json → sources.bindingdb
```

The strict primary measurement rule is:

- single-chain or chain-count-unknown targets;
- exactly one base UniProt accession;
- exact numeric **Ki or Kd** values in nM;
- publication date from BindingDB's `Date of publication` field;
- IC50, EC50, inequalities, ranges, and approximate values excluded from the primary threshold-crossing audit.

Experimental-structure history comes from the public SIFTS UniProt–PDB mapping and official wwPDB release dates. AlphaFold exposure currently means that a target has no experimental structure released before 22 July 2021 but does have an AlphaFold DB model.

That last rule is provisional. Model availability alone does not establish that the relevant binding site or domain is accurate enough for a ligand-discovery workflow.

## Feasibility result

The current row, mapping, target-group, risk-set, post-treatment-event, source-coverage, and API-query counts are generated in `feasibility.json`. The post-treatment event count remains a feasibility result rather than an effect estimate.

## Evidence gates

The current evidence-gate statuses and evidence are generated in `feasibility.json` and copied into `data/studies.json`:

The order and meaning of the eight predeclared gates are stable; the status and evidence cells must be read from the machine-readable report after each refresh.

Pre-treatment event counts and calendar coverage must be modelled directly; a simple before-and-after comparison is not sufficient.

## Rebuild

Run:

```sh
python3 audits/bindingdb-alphafold/audit.py --check-upstream
python3 audits/bindingdb-alphafold/audit.py
python3 audits/bindingdb-alphafold/apply.py
python3 audits/bindingdb-alphafold/check.py
```

The audit writes:

- `feasibility.json` — source hashes, schema counts, target counts, gate assessment, and non-causal conclusion;
- `target-cohort.csv` — one row per core UniProt target with threshold dates, structure history, AlphaFold availability, group, and primary-outcome risk-set status.

The large BindingDB source archive is not copied into this repository. Its exact release URL, byte count, member name, and SHA-256 hash are committed so the audit can be reproduced from the primary public source.

## Interpretation

The audit establishes that a target-level panel can be built from public data. It does not establish that the identifying assumptions are credible, that the primary outcome has adequate power, or that AlphaFold caused faster ligand discovery.

**No causal effect is estimated.** The study remains `not_estimated` and moves only from design specification to data build.

## Next step

Freeze a binding-site or domain usability rule, audit target-class and pre-treatment-activity overlap, and estimate pre-treatment event-study leads. Only after those steps should the project decide whether the study can move to analysis or whether its primary outcome must be revised prospectively.

## Methodological inspiration

The separation between a stable outcome series, an exposure design, and a causal claim is inspired in part by METR's [“LLMs' Contribution to Discoveries”](https://metr.org/notes/2026-08-14-llm-contribution-to-discoveries/) and Thomas Cunningham's public [`ai-discovery-data`](https://github.com/tecunningham/ai-discovery-data) repository. This audit uses its own code, decision rules, and primary-source rebuild.