Closed 9 September 2026 after the actual GDI → DSA40 Collaboratory link and three substantive public records: the current aggregate tracker, the September 2025 policy paper, and the linked issue tracker. These reveal applicant-reported validity disputes and a current pending AliExpress entry. They do not publish an identifiable AliExpress application/response pair or establish whether a particular refusal was justified.
[Tracker Insights](http[local research file] displays “last updated: 8. September 2026”. It reports 70 complete applications registered through its voluntary tracker; 51 decided, comprising 24 accepted and 27 rejected. Those are recorded application statuses, not verified data deliveries. “Complete” concerns the tracker's recorded applications and does not independently establish that a platform received a legally sufficient submission.
The platform table lists one AliExpress public-data application as open. It discloses no submission date, applicant, requested fields, response, paragraph, cure or subsequent outcome. No GDI identity is established. Public-data labelling alone is insufficient to reconstruct the actual legal channel used. This current entry cannot be matched to the confidential population in the separate FTI audit ending June 2025 or treated as a contradiction of that audit's report of no approved applications.
A narrow arithmetic check of the original HTML table gives 68 listed applications: 17 open, 27 rejected and 24 accepted. The decided totals match the headline; the table leaves two of the headline 70 unaccounted for. The page does not explain the difference. Do not silently add cases, infer missing outcomes or calculate population-wide success rates. Its narrative initially names fewer platforms than the displayed table; the table itself contains the AliExpress row. Original applications-tracker.html; full substantive text applications-tracker.derived.txt; exact table extraction applications-tracker-table0.json.
The same page's Reasons for Rejection section provides an unattributed platform-style excerpt concerning systemic-risk purpose limitation, plus the following category counts. These are the organiser's presentation of submitted information, not a bundle of publicly inspectable original platform letters.
| Reported category | Count | Evidentiary limit |
|---|---|---|
| Failure to confine research to the statutory purpose | 5 | Most common reason within the reasons presented; not proof every proposal was outside scope. |
| Necessity and proportionality | 2 | The requested data, platform reasoning and balancing are absent. |
| Incompleteness | 1 | Missing fields and any cure request are not identified. |
| Access request differed from application | 1 | The application/request pair is not published. |
| Required university affiliation | 1 | The organiser labels this an invalid reason during early implementation; no individual decision or adjudication is supplied. |
| Required EU location | 2 | Likewise an organiser assessment, with no original correspondence or outcome of a challenge. |
These counts sum to 12, not all 27 reported refusals. The page does not identify which platforms or legal paragraphs produced each category, whether the categories overlap, or a complete coding frame. It separately says 27 entries provided application text and only 12 explicitly referred to Article 34. Those are different denominators and must not be equated with the 12 refusal-category counts. An explicit Article 34 citation is not by itself a demonstrated legal completeness test.
The tracker mixes public and non-public requests. Its categories cannot all be assigned automatically to Article 40(12), or its non-public rows to completed Article 40(4) DSC proceedings. It reports platform decisions; it does not publish the original channel and chronology needed to classify each one. The displayed average decision delays are sample summaries and were not treated as statutory clocks or evidence of the AliExpress entry's duration.
The actual [September 2025 policy paper](http[local research file] Data Access for Researchers under the Digital Services Act: From Policy to Practice, is Weizenbaum Policy Paper 14. The current publications index dates it 22 September 2025; the PDF cover and imprint give September 2025. It is not a fresh 2026 study of the tracker snapshot.
PDF 12–13 / printed 11–12 expressly discuss Article 40(12). Researchers apply through platform-specific forms or email, with provider or surrogate vetting. The authors report varying information requirements, refusals based on EU residence, and lengthy exchanges requiring progressively narrower purposes or data scope. Footnote 24 describes forms ranging from 8 questions for Snap to 55 for Meta, including requests for phone number or date of birth in some forms. These are the paper's dated accounts; this lane neither accessed those forms nor verified current requirements.
The account distinguishes receiving access from receiving reliable data, reporting quality problems even after approval. It cites an earlier 2024 policy paper for the application obstacles rather than reproducing original letters. It proposes Commission guidance and codes of conduct; those are authors' proposed remedies, not an acquired cure procedure or a successful appeal. PDF 14–15 separately discuss privileged Article 40(4) access and data specificity; those legal explanations must not be used to recategorise the preceding Article 40(12) examples.
PDF 35 / printed 34 expressly describes the Collaboratory tracker as researcher self-reporting and the project as offering application support. The entry page openly recruits researchers and non-profit organisations to share requests, with the stated aims of reporting success, helping applications and informing regulation. This is a self-selected sample from an advocacy/support network, not a random sample or a census of platform applications. The inspected sources give no response rate or independently sampled comparison population. Original application texts are apparently available for a subset of the submissions, but their submission to the organiser is not public release or independent verification here.
PDF 2 says the paper draws on the transnational network built by the Collaboratory, led by some of its authors, and calls it a joint project funded by “Mercator Stiftung” since early 2024. The retained homepage/publications HTML references a funder logo asset named Stiftung-Mercator-Weiss-RGB.png, with empty alt text. The logo image was not separately acquired or visually read. These observations identify the disclosed foundation name; no exact grantor legal suffix, amount, award agreement, payment or reserved approval right was acquired.
The same page describes institutional funding of the Weizenbaum Institute by the German Federal Ministry of Research, Technology and Space and the State of Berlin. That institutional credit is not proof those bodies funded this particular study or determined the tracker's categories. No funder approval, sampling instruction, editorial control or access to applicant records is disclosed in the inspected scopes. The authors' leadership, the project's open recruitment and application-support mission do establish a closer organiser/study relationship than an independent audit of platform decisions. The paper also argues for more resources for researcher intermediaries (PDF 35–36); that is a stated policy position, not an awarded new resource.
The linked [Issue Tracker](http[local research file] says submissions are checked by the organisers and may prompt follow-up. Its undated substantive body lists a past Meta application-submission interruption from December 2024 to April 2025 and a TikTok API data outage in January 2025. Its statement that it knows of no current critical issues is limited to the organisers' knowledge and this issue-list scope. It does not negate the separate application refusals or pending cases. No AliExpress refusal, cure, complaint, restored access or original response is published there. The linked external Meta page was not followed because it would expand beyond the selected three substantive records.
The home and tracker pages each timed out in the ordinary web reader, then succeeded through one ordinary public GET. The linked April 2024 paper landing failed in the reader; its one GET alternative returned HTTP 200 BunkerWeb Bot Detection content at a challenge URL, requiring JavaScript. That is challenge HTML, not the paper. The route was closed without challenge completion, alternate mirror or DOI retry. The exact response, URL and hash remain in custody. No account, survey, form, contact, application or live platform test was used.
The strongest rival to arbitrary obstruction is that at least some requests failed legitimate eligibility, specificity or proportionality requirements. Conversely, a platform's own label of incompleteness does not prove that its demands were necessary or its process offered a reasonable cure. The present aggregates cannot decide between those explanations for AliExpress or any other individual case.
The most useful next record is an applicant-consented, dated and appropriately redacted application plus platform response, follow-up/cure exchange and final outcome, with the exact Article 40 paragraph and dataset request. A link from that pair to the tracker's coding record would allow a real validity assessment. The Collaboratory/applicant would be expected holders for reported submissions and the platform for its decision record; no release or request is assumed. The root's separate audit evidence remains a different period and source population. This lane closes without a finding that GDI submitted the tracked AliExpress request, that access was delivered, or that a refusal violated the DSA.
Text reading: full substantive home and tracker bodies; current publications index entries/links; policy PDF 1–3, 12–15, 35–36 and 38 (plus the initial reader's introductory/context scope through PDF 12, not a full-PDF read); full substantive Issue Tracker body. Full policy extraction is retained for root review but is not a claim every page was read. No images/charts were visually inspected; the tracker table was read from actual HTML text. Primary original hashes, exact paths and transport/read scopes are in applications-captures.json.