Revert "Update T1OO text to reflect new reality"

This reverts commit 7bc93d1.

docs/type-one-opt-outs.md

@@ -25,18 +25,12 @@ Instead they describe the data they require using [ehrQL](https://docs.opensafel
 At the point where ehrQL needs to fetch the data, it is told (by the system described above) whether it should include data from opted-out patients or not.
 
 Every ehrQL query contains a "population definition" which specifies exactly which criteria a patient must meet to be included in the result e.g. "patients between the ages of 18 and 65 who have not recently changed GP practice".
-Unless a project is named in the project permissions file, ehrQL will automatically add an extra condition to this population definition: the patient's pseudonymous ID number must appear in the list of allowed ID numbers.
+Unless a project is named in the project permissions file, ehrQL will automatically add an extra condition to this population definition: the patient's pseudonymous ID number must not appear in the list of ID numbers with a registered type 1 opt-out.
 
 This list is provided by the system suppliers and stored in the secure database along with the rest of the patient data.
-It contains all patients known to the system supplier with two classes of patient _removed_:
+It consists of a single bespoke type 1 opt-out table, with a single list of pseudonymous IDs and no other information.
 
- * patients which are known to have registered a type 1 opt-out; and
- * patients which _might_ have registered a type 1 opt-out elsewhere, which would not be recorded by the system supplier.
-
-That is, the list contains just those patients which the system supplier can be confident have _not_ registered a type 1 opt-out.
-It consists of a single bespoke table, with a single list of pseudonymous IDs and no other information.
-
-Again, the [code which enforces this](https://github.com/opensafely-core/ehrql/blob/f5b0d5f56b53039062cf1f95ea76dda584f485de/ehrql/backends/tpp.py#L97-L136) is publicly available on Github.
+Again, the [code which enforces this](https://github.com/opensafely-core/ehrql/blob/8494b943be0d73d02413ad41272a612a5fddbff3/ehrql/backends/tpp.py#L75-L100) is publicly available on Github.
 
 ### Data access which does _not_ go via ehrQL
 
@@ -45,7 +39,7 @@ There are three sorts of circumstances under which data access in OpenSAFELY doe
 #### 1. Cohort Extractor
 
 ehrQL's predecessor was a tool called "Cohort Extractor" and studies which began before the launch of ehrQL continue to use this tool; these all had permission to process data from patients with a type 1 opt-out.
-Cohort Extractor applies exactly the [same rules](https://github.com/opensafely-core/cohort-extractor/blob/f07867c1b277115c28859bcf356e7379953ca43b/cohortextractor/tpp_backend.py#L420-L441) as does ehrQL with respect to opt-outs.
+Cohort Extractor applies exactly the [same rules](https://github.com/opensafely-core/cohort-extractor/blob/18c954499ec0a8fbcf5f83e0a4d1bbe2a469b0c1/cohortextractor/tpp_backend.py#L417-L435) as does ehrQL with respect to opt-outs.
 However, as a tool, it was not originally intended to enforce data access controls and its design makes it difficult to implement the same security boundaries as ehrQL.
 As a result, we have limited access to Cohort Extractor to just those projects which _already_ have access to opted-out data.
 This is enforced by the same mechanism as access to opted-out data i.e. an auditable file of [permitted projects](https://github.com/opensafely-core/job-server/blob/main/jobserver/permissions/cohortextractor.py), and enforced [code protection rules](https://github.com/opensafely-core/job-server/blob/main/.github/CODEOWNERS).