A structural read is a kind of vulnerability report on a trial design. Encounter handles those reads the way the security industry handles vulnerability reports: privately first, then publicly.
In the early years of commercial software, security researchers who found flaws had no structured channel to disclose them. They published publicly and companies sued them; both sides behaved badly; the industry took a decade to build the infrastructure that now makes this routine. Bug bounty programmes — HackerOne, Bugcrowd, Project Zero — solved the coordination problem by formalising a sequence: private disclosure first, a window for the vendor to engage, public publication after. That sequence is now the professional norm in software security. Everyone benefits — researchers get paid, vendors get warned before the public does, users get safer products.
Clinical trial design has the same coordination problem and no equivalent infrastructure. Structural problems in trial designs are visible to outside readers who aren't inside the sponsor's assumptions. But no channel exists to report them, and no convention governs how sponsors should respond. Encounter is one attempt at that infrastructure.
Step 1 — Private letter. If Encounter finds a structural observation on an ongoing trial, the sponsor receives a dated private letter describing the observation, what it implies for the pivotal, and a specific verification task they can run on their own data to confirm or rule out the question. No ask is attached. The letter is private; we do not share it with anyone else.
Step 2 — Engagement, if the sponsor wants it. Sponsors who want to work with Encounter on the question reply to the letter. Engagement is a fixed-fee proposal, scoped to the specific observation. The service page describes what a full engagement includes.
Step 3 — Scorecard entry. Whether or not the sponsor engages, the structural call becomes a scorecard entry in due course — dated, falsifiable, pre-registered on Zenodo before the trial reads out. The scorecard is the public ledger. It does not publish the private conversation; it publishes the call.
Three properties follow from the sequence. First, sponsors are not surprised — the letter precedes the scorecard entry, always. Second, the dated private disclosure is the artifact regardless of what happens next; if Encounter's call holds at readout, the record shows the sponsor was informed before the trial enrolled. Third, the scorecard is only useful if the calls on it are dated before the readouts — so publication is part of the mechanism, not a threat.
This is what makes the programme legitimate rather than adversarial. The work is structural. The sequence is predictable. The calls are falsifiable. Misses stay on the record alongside hits.
We do not predict effect sizes or magnitudes — only direction. We do not make subgroup claims without a derivation we can defend against the already-public data in the same class. We do not name sponsors in terms of how they responded to a private letter. We do not write reads on trials whose mechanism the framework cannot decompose.
Reply to the sender. The first conversation is about whether the question in the letter is worth pursuing — if your team runs the verification task and it comes back clean, the call is wrong and we say so. If the question holds, the next conversation is about scope.
The service page describes the scoping flow. The disclosure sequence above applies when Encounter initiates the read; the service flow applies when a sponsor does.
