An age-estimation score becomes consequential when it opens or closes a door. Evaluating that door requires more than an average error or a privacy slogan.
A small question with a long chain behind it
A website may want a single answer: does this person meet the relevant age requirement? Obtaining that answer can involve a photograph, an identity document, an account history, an external provider or a credential stored on a device. The answer displayed at the end conceals a chain of choices about evidence, uncertainty, data access and consequences.
That chain deserves attention because a narrowly phrased question can produce a surprisingly broad intervention. A person who is wrongly refused access experiences the refusal, not the model's average performance. A child wrongly classified as eligible experiences whatever the service allows next. Someone asked to upload more information experiences the collection whether the final result is accurate or not.
The evidence is still developing. NIST's ongoing facial age-estimation evaluation displayed results updated September 29, 2026 when inspected for this article. Its headline mean-absolute-error presentation averages specified age and sex groups, including ages 18 through 30; the page also distinguishes several photographic conditions. Those details limit what a reader should infer about a different population or capture environment. NIST FATE age-estimation evaluation
A better public discussion begins by separating four questions. What evidence supports an age claim? How accurately does the method interpret that evidence? What information moves between organizations? What happens to the person after the system decides? None of the four can safely stand in for all the others.
This is an analysis of evaluation and design, not legal advice or a recommendation that every service should require age checks. Jurisdictions, purposes and obligations differ. The examples below are invented to clarify the reasoning; they do not report a particular platform's users, error rates or outcomes.
Estimation, verification and a service's decision
The European Data Protection Board's age-assurance statement treats the term as an umbrella for methods that determine age or age range with varying confidence. It distinguishes categories including estimation, verification and self-declaration, and frames age assurance as a data-protection issue with implications for other rights. The statement was adopted February 11, 2025, with minor changes recorded in the document through April 1. EDPB Statement 1/2025
A reader can understand the practical difference without assuming any one method is always best. An estimate predicts an age-related property from observed signals. A verification process checks evidence for a claim, although its dependability still rests on the evidence and the checking process. Self-declaration records what someone says. A service then applies a rule to the resulting information.
Those steps should not collapse into a single label. A system might correctly estimate that a person is probably within an age band but apply an inappropriate rule to that uncertainty. Another might correctly validate a credential yet fail to establish that the current user is entitled to use it. A third might obtain a sound answer while collecting more information than the task requires.
The distinction also changes what an appeal should address. A user could dispute the source record, the interpretation of an image, the applicability of a threshold or a technical failure. Telling every unsuccessful user to try the same camera step again assumes that all failures have the same cause. They do not, even in a purely hypothetical system.
A useful service explanation should therefore identify the decision being made and the kind of evidence being used. It need not expose security-sensitive implementation details to be clear about whether the service is reading a verified age claim, making a prediction or asking for a declaration.
A birthday boundary is not an average-error problem
NIST's 2024 report evaluates the technical performance of submitted age-analysis algorithms and distinguishes age estimation from age verification. A numeric age estimate can be compared with a threshold, but the threshold decision has its own errors. The report describes the image sources and evaluation conditions and explicitly avoids endorsing identified products. Its results concern tested algorithms and data, not a universal certification of any live age-checking service. NIST IR 8525
Consider an original arithmetic example. A service uses an eligibility threshold of 18. One fictional system estimates a 40-year-old as 43 and a 17-year-old as 18. Its absolute errors are three years and one year. The smaller numerical error is the one that crosses the eligibility boundary. The larger error leaves the decision unchanged.
Now consider a 19-year-old estimated as 17. The error goes in the other consequential direction: an eligible person is refused. Calling both mistakes age error does not explain their effects. A public report should say which side of the boundary was misclassified and which people formed the denominator.
This is why a low overall average can coexist with an unsuitable gate for a particular use. The relevant users may cluster close to the cutoff, or the tested population may contain many people far from it. A performance summary dominated by easy cases can be poorly matched to the decision that matters most.
The example does not establish the failure rate of any real product. It establishes a mathematical reason to ask for threshold-specific evidence. The service should explain the threshold, any buffer it applies, the population tested and how uncertainty is handled. A number without that context is incomplete, even when calculated correctly.
Four outcomes, two very different mistakes
Hypothetical arithmetic example, not measured performance. Overall accuracy can conceal different false-acceptance and false-refusal rates. Original calculation, 1 November 2026.
A simple decision table makes the structure visible. People who meet the requirement can be accepted correctly or refused incorrectly. People who do not meet it can be refused correctly or accepted incorrectly. The two mistakes need separate names and separate measurement.
Here is a deliberately hypothetical test with round numbers. Of 100 people below the threshold, suppose 10 are accepted. Of 100 people at or above the threshold, suppose 20 are refused. The overall accuracy is 85 percent: 170 correct decisions among 200 people. The false-accept rate among ineligible people is 10 percent, while the false-refusal rate among eligible people is 20 percent.
Change the mix of people without changing those two conditional rates and overall accuracy changes. If the evaluation includes 900 ineligible people and 100 eligible people, the same illustrative rates produce 810 correct refusals and 80 correct acceptances, or 89 percent accuracy. The system has not improved at either task. The population weighting changed.
These calculations are an original teaching example, not measured age-assurance performance. They explain why a chart headed accuracy should identify what was counted. A platform's actual user mix, the mix in a research dataset and the mix in a vendor demonstration may differ substantially.
A clear evaluation would report the underlying counts as well as the rates. It would describe inconclusive cases rather than quietly excluding them. It would also distinguish people from attempts: one person trying repeatedly is not equivalent to several independent people. Those choices determine what the numbers mean.
For a public-interest assessment, the practical question is which errors remain acceptable for this service and how their consequences will be limited. That is a policy and design judgment informed by evidence, not something a single score can decide automatically.
A buffer moves the burden
A service can choose to accept only estimates comfortably above a required age. Such a buffer may reduce one kind of mistake while increasing another. It may also send more people to a secondary method. Evaluating the initial estimator alone would then miss part of the actual user experience.
Imagine a fictional service that requires eligibility at 18 but sends people with uncertain results to another route. The important question is not simply whether the first step rejects more people. Some of those people may complete an alternative check easily; others may lack the requested evidence or abandon the process. The total effect depends on the whole pathway.
A buffer should therefore be described as an operating choice rather than an invisible correction that makes uncertainty disappear. The service can explain that the first method cannot establish eligibility confidently enough and offer a distinct next step. It should avoid telling an adult that the system has definitively discovered they are a child when the actual result is uncertainty.
The alternative route also needs evaluation. Does it collect more information? Is it usable on an older device? Does it require a document that some eligible users do not possess? Is there a human review process, and how long does it take? An apparently cautious threshold can transfer a substantial burden to people near the boundary.
No universal buffer is recommended here. Choosing one requires relevant evidence, a defined purpose and an assessment of the consequences. The analytical point is that the buffer belongs in the published description of the process. It should not be left out while the provider advertises only the easiest cases.
Read the trial's exclusions before repeating its headline
Australia's government-hosted Age Assurance Technology Trial includes a detailed age-estimation volume. Its 16-plus gate figure states that two providers were excluded for consistently poor performance and that small provider samples were excluded. The nearby narrative and table also report different false-rejection values for some ages. Those features require clarification before treating a single extracted number as a population-wide estimate. The government's 2026 corrigendum concerns bibliography references; it is not evidence that this numerical discrepancy was resolved. Trial Part D, corrigendum
This is a reason to read carefully, not an allegation about the authors' motives. Excluding a system can be justified for a particular analytical question, but the remaining result answers that narrower question. Readers need to know whether a statistic covers every tested provider, selected providers, a specific configuration or only participants with successful captures.
The distinction becomes especially important when a report is used for procurement. A trial of a technology class is not automatically a ranking of all commercial products. A platform still needs evidence about its selected provider, operating point and implementation. A broad statement about technical feasibility cannot supply all those missing details.
For this article, the unresolved inconsistency is not converted into a polished performance chart. That would give uncertain interpretation the visual authority of settled data. A conceptual diagram and an explicitly hypothetical arithmetic example are more honest than choosing whichever published number makes the cleanest story.
The general reading habit is valuable beyond age assurance: follow a reported result to its population, exclusions and definitions. If those differ between a summary and a table, record the discrepancy and seek clarification. Do not silently reconcile it through guesswork.
Laboratory accuracy and deployed effectiveness are different evidence
Ofcom's guidance distinguishes technical accuracy, robustness in actual deployment, reliability and fairness. It also identifies accessibility and interoperability as relevant principles. These are the regulator's stated evaluation dimensions, not a claim that every method listed on its page has been independently proved effective in every configuration. Ofcom age-assurance guidance
An original way to make that distinction concrete is to imagine two test rooms. In one, a researcher has clear instructions, suitable equipment and a carefully prepared sample. In the other, people use their own devices, misunderstand some instructions, encounter interruptions and vary in what evidence they can provide. A method can perform differently without either room being fraudulent.
A deployment assessment needs to describe the second environment rather than assume the first represents it. That includes ordinary failures such as a camera that will not start, a page that does not load, a document image that cannot be read or a user who cannot complete a requested motion. These events belong in the service outcome even when the age model never returns a prediction.
Robustness testing can also examine misuse, but a public explanation does not need to publish instructions for defeating a safeguard. It can report the classes of tests, the independent review process and the unresolved limitations at an appropriate level. Security testing and public transparency can coexist without turning an article into an evasion manual.
The crucial editorial distinction is between a claim that a component performs a task under specified conditions and a claim that a service achieves its broader purpose. The latter requires evidence about implementation and outcomes, not merely a successful component demonstration.
What a new research model does and does not establish
The research landscape is changing quickly. An October 23, 2026 preprint called A-GE explores age-related evidence from fine-grained motion measured by ordinary device sensors. Its authors, affiliated with Aerendir Mobile, report separate development and final-evaluation cohorts and more than 600 participants. The paper describes privacy benefits and residual risks. It is a company-affiliated preprint and should be read as reported research, not independent certification or proof of universal suitability. Gharib, Cascone and Zizi, A-GE
A new signal can make an interesting contribution without resolving the entire age-assurance problem. The reader should ask who was represented, what devices were used, how the reference ages were established and what happened when the signal could not be collected. A different measurement method can move the uncertainty rather than eliminate it.
It is particularly important to examine the relationship between the claimed age property and other characteristics. If a method relies on behavior or movement, an evaluator should consider whether variation unrelated to age could affect the outcome. The existence or size of such an effect must be measured; it should not be invented from intuition. Equally, an absence of measurement should not be presented as evidence that no issue exists.
A responsible research summary can preserve both curiosity and caution. It can explain why the approach is worth investigating while keeping the reported population and experimental status visible. It can also distinguish the authors' explanation of a mechanism from an independently established physiological fact.
For a public service, the next useful evidence would be evaluation suited to its intended population and conditions, along with a meaningful fallback. Novelty is a reason to investigate a method, not a reason to skip those steps.
General-purpose AI is not a shortcut around evaluation
A separate preprint, first submitted in February 2026 and revised October 24, compares specialized age-estimation architectures with general-purpose vision-language models across selected image datasets. Its authors report differences in estimation and threshold performance. The comparison is bounded by its sampled images, model versions and procedures; it is not a finding that any conversational AI can safely operate an age gate. Ren and colleagues, version 3
A system that produces a confident sentence can be especially misleading if the interface hides the distinction between an estimate and a verified record. A human reader may interpret fluent wording as evidence that the system knows more than it does. For an eligibility decision, the relevant evidence remains the measured behavior of the actual configured process.
Model changes create another practical issue. A provider may update a hosted model without preserving the exact behavior of a previous evaluation. A service relying on it needs a way to identify the version in use and determine when reevaluation is necessary. This is a proposed governance requirement, not a claim about any named provider's update practices.
The question should also remain appropriately narrow. A service that needs an age-related claim should not casually ask a general model to infer unrelated personal attributes from the same input. More capable software does not make every possible inference necessary or legitimate.
A procurement team can request a reproducible evaluation record, explicit handling of inconclusive responses and a clear statement of what the model is permitted to output. If those cannot be supplied, a compelling demonstration should not be confused with an operationally accountable service.
Proving a property need not reveal a whole identity
The European Commission describes an age-verification solution intended to let a user prove an age threshold without sharing other personal information with the relying service. Its official page dates the original blueprint to July 14, 2025 and feature readiness to April 15, 2026. It describes further rollout and governance work. Those statements should not be rewritten as proof that all member states had completed deployment by this article's preparation date. European Commission age-verification approach
The architectural idea matters even when implementation questions remain. A service may need a claim such as meets this threshold rather than a name, full birth date, address and document number. An evidence provider and the service receiving the claim need not automatically receive the same information.
That does not make the system information-free. Someone or something must establish the underlying claim. The device, issuer, verifier and service may each observe different events. A privacy assessment needs to map those observations and ask which can be linked, retained or repurposed. The phrase anonymous proof is not a substitute for examining the actual data flows.
An original comparison helps. A venue that only needs to know whether a ticket is valid does not normally need the buyer's entire transaction history. Similarly, a threshold claim can be narrower than an identity dossier. The analogy explains a design objective; it does not prove that any particular age credential achieves it.
The best public explanation separates the objective from the verified implementation. It states what the relying service receives, what the issuing process requires and which assumptions remain. Where independent security or privacy review is incomplete, that fact should be visible rather than hidden behind a blueprint's intended properties.
Privacy begins before retention
The Australian privacy regulator's March 17, 2026 guidance asks organizations to consider whether age assurance is necessary, assess privacy impacts and use proportionate methods. It also addresses vendors, escalation, notices, support and retention. This is jurisdiction-specific regulatory guidance, not a global legal rule; organizations need advice appropriate to their circumstances. OAIC age-assurance guidance
A common discussion focuses on whether an uploaded image is deleted. That matters, but it is not the only moment at which privacy is at stake. The process may collect information, send it to another entity, derive a result, associate that result with an account and retain an audit record. Each step has a purpose that should be examined.
An original review exercise is to follow one imaginary user's information through the workflow. At every handoff, list what the receiving party sees and what it can do next. Do not write only the name of the organization; describe the data fields and the event. A statement that a provider processes age checks is less useful than a concrete map of what reaches it.
Then ask which information is necessary for which function. A support team may need an error category without needing the original image. A service may need an eligibility result without needing a full birth date. An audit may need evidence that a procedure was followed without retaining every source item indefinitely. The right answer depends on the system, but the distinction is worth making explicitly.
Deletion claims also need careful wording. Removing one stored input does not necessarily remove derived records or information already shared elsewhere. A trustworthy explanation identifies the categories and recipients rather than using deletion as a blanket promise about the entire ecosystem.
An appeal is part of accuracy in practice
A mistaken initial result does not have to become a permanent exclusion. Whether it can be corrected depends on the route offered to the person who receives it.
The UK's Information Commissioner's Office explains age assurance as part of a risk-based, proportionate approach to the Children's code. Its page currently warns that the guidance is under review following legislative changes. That warning is relevant: an old opinion should not be presented as an unchanging statement of every current obligation. ICO age-assurance opinion
For a hypothetical service, an appeal should begin with an intelligible message. Unable to establish eligibility is different from confirmed ineligible. A technical capture failure is different from an age estimate below the threshold. The interface should not tell people more than the system actually knows.
The next step should also be realistic. A button labeled contact support is not a complete remedy if nobody responds or if the response merely repeats the failed step. An alternative method may help some users but exclude others. Evaluation should include completion rates, waiting times and the eventual disposition of disputed decisions, with appropriate privacy protections for those records.
A human reviewer is not automatically a perfect solution. Reviewers need a defined task, suitable evidence, training and limits on what they can access. Their decisions also need a way to be checked. Introducing a person changes the process; it does not remove the need to evaluate it.
A sensible public report would distinguish initial errors from unresolved errors after review. Both matter. A system that frequently burdens eligible users but eventually corrects itself is different from one that rarely makes mistakes, and different again from one that leaves affected people without a workable route back.
Who disappears from the denominator?
A service may report excellent results among people who successfully completed a check. That does not describe everyone who started it.
Imagine an invented evaluation with 1,000 invited participants. Only 700 finish the required steps. A report describing accuracy among those 700 leaves an important question about the other 300. They might have encountered technical failures, lacked evidence, declined the privacy terms or simply lost interest. The reasons cannot be inferred from the completion count alone.
The honest report would show the pathway: invited, started, completed, received a conclusive result and resolved any dispute. It would avoid treating every departure as a failed age prediction or every departure as harmless. Different explanations have different implications for accessibility, privacy and the service's purpose.
Representation also matters within the completed group. A sample may be too small to support confident conclusions about a particular age band, disability, device condition or demographic group. Publishing a rate with several decimal places does not create evidence that the sample lacks. The uncertainty should be stated in terms a reader can understand.
This is an editorial recommendation for evaluation, not a claim that all existing reports omit these issues. Some research is necessarily limited to a component or a laboratory population. The problem arises when those limits disappear as results move from a technical paper into a sales pitch or policy argument.
A useful dashboard should therefore distinguish missing information from favorable information. No observed failure in an untested group is not proof of success. An unavailable result should look unavailable, rather than being colored green or silently removed from the chart.
Effectiveness requires an outcome beyond the gate
Ofcom's report published July 16, 2026 is presented as an early assessment of how regulated services used age assurance. The government publication page explicitly says it does not provide final conclusions about effectiveness. That qualification should travel with any summary of the report. Ofcom report on the use of age assurance
A gate can be measured at several levels. Did the component return the correct classification? Did the service apply the intended access rule? Did the broader intervention reduce the harm it was meant to address? Those questions require different evidence, and improvement at one level does not automatically establish improvement at all three.
For an original evaluation design, begin by stating the intended outcome. If the goal concerns exposure to a particular risk, a count of completed checks is an implementation measure rather than the final outcome. If the goal concerns age-appropriate settings, refusal rates alone may not describe whether the settings actually work.
A change over time also needs interpretation. Other platform changes, seasonal patterns or shifts in the user population could affect observed outcomes. An evaluation should describe those possibilities and its comparison method rather than assigning every favorable change to the new check. This is a basic causal reasoning requirement, not an assertion that any specific study has made that mistake.
The costs belong in the same account. Extra collection, mistaken exclusion, support burden and abandonment may matter even when the intended outcome improves. A serious assessment does not need to pretend that all benefits and costs can be reduced to one universal score. It needs to show the evidence clearly enough for a reasoned decision.
A useful disagreement is about assumptions
Researchers do not all frame the problem in the same way. A March 2026 analysis by Lueks and colleagues compares age-assurance approaches and architectures in terms of effectiveness, side effects and acceptance. It is an analytical research report, not a new population-wide experiment. Its distinctions are useful because the place where a check occurs can matter alongside the method used to make it. Assessing Age Assurance Technologies
A September 2026 preprint by Ma and colleagues examines the literature and proposes a sociotechnical process framework. It emphasizes the connections between evidence, age claims, decisions and institutional responsibility. That is a research framing and literature analysis, not proof that a particular commercial service succeeds or fails. Reconceptualizing Age Assurance as a Sociotechnical Problem
These perspectives help clarify disagreements that otherwise sound irreconcilable. One person may be discussing an estimator's performance on a fixed image set. Another may be concerned about the data collected by the entire service. A third may be asking whether the intervention changes children's experiences. They can disagree strongly while answering different questions.
A productive discussion names the question and the evidence that could change the answer. If a claim concerns technical error, specify the relevant test. If it concerns privacy, map the information flows. If it concerns exclusion, examine who cannot complete the process. If it concerns safety outcomes, define the outcome and the comparison.
That discipline does not remove political or ethical disagreement. It makes the disagreement more legible. People can then contest the acceptable tradeoff instead of arguing over a single word such as effective whose meaning shifts between speakers.
Designing the explanation around the person at the door
A well-designed age-check interface should explain the immediate task before demanding evidence. The person should understand what the service is trying to establish and what kinds of information the available methods require. This is an original design recommendation, not a finding that one specific layout guarantees compliance or acceptance.
The first screen can use a short purpose statement and clearly distinguish the available routes. Each route should describe what it asks for, who processes it and where to learn about retention and review. Important information should not be hidden behind a generic trust badge or a large button that implies there is no choice when alternatives exist.
The uncertainty state deserves its own design. Avoid a red verdict that falsely implies certainty when the real problem is insufficient evidence. Explain whether the user can try another method, correct a record or request review. Preserve accessibility for people who use assistive technologies, have limited bandwidth or cannot complete a particular physical interaction.
The result screen should show the consequence without exposing unnecessary personal details. An eligibility claim need not become a public badge containing a birth date. A refusal should not reveal sensitive evidence to someone else using the same device. These are design scenarios to test, not assertions that all current systems behave this way.
For editorial coverage, the same principles apply. A useful article graphic should show the chain from evidence to evaluation to claim to service decision, including an appeal branch. It should not depict a face scan as a magical measurement of an exact birthday. Nor should it use an image of a real child to imply that an actual age inference was performed.
A review sheet for a concrete proposal
Before evaluating a named service, ask for a short description of the requirement it is trying to enforce. The threshold, jurisdiction and purpose should be explicit. A statement that the product keeps children safe is too broad to define the test by itself.
Next, identify the evidence pathway. Does the service rely on a document, a credential, an estimate or another signal? Which organizations handle the evidence? What reaches the final service? An answer should describe the deployed configuration, not merely the maximum privacy features a technology could theoretically support.
Then request threshold-specific evaluation with relevant populations and conditions. Ask how inconclusive cases, failed captures and repeat attempts are counted. Ask for false acceptance and false refusal separately. Where a published report uses exclusions, the proposal should explain whether those exclusions resemble the intended deployment.
Review the secondary route with the same seriousness as the primary one. An alternative that exists only on a diagram is not meaningful evidence of accessibility. Test whether a person can find it, understand it and complete it without disclosing information unrelated to the task. Record delays and unresolved cases rather than treating appeals as an administrative footnote.
Finally, separate the evidence currently available from the evidence still needed. A vendor demonstration, a laboratory benchmark, a regulatory description and an independent operational study are different kinds of support. They can all be useful, but they should not be counted as interchangeable endorsements.
The resulting review sheet may be less exciting than a headline accuracy figure. It is also far more useful for deciding whether the particular proposal is proportionate, understandable and accountable. Where the evidence is inadequate, the honest result is a request for more evidence or a narrower proposal, not a decorative seal of approval.
The reference age needs a provenance trail
An evaluation compares a system's answer with a reference. Before treating that reference as ground truth, the evaluator should document how it was obtained and what uncertainty it contains. This is a methodological recommendation, not an allegation that any source cited here used unreliable ages.
For an invented image test, a date of birth and an image-capture date would support a different reference than a broad age label attached years later. If the picture was taken before a birthday but the label reflects the upload date after it, the distinction could matter near the eligibility threshold. A reviewer needs enough provenance to understand which date the reference represents.
Approximate labels require their own interpretation. A category such as teenager cannot support a precise claim about which side of a particular birthday the person occupied when the image was captured. An evaluation can still use coarse categories for an appropriate question, but it should not silently convert them into exact ages.
The same care applies to duplicate people and repeated captures. Several images of one person may be useful for studying variation, yet they should not be presented as several independent participants. If development and evaluation sets share people, the report should explain that relationship and its implications rather than allowing readers to assume complete separation.
A public summary does not need to disclose identities to describe these methodological choices. It can state how references were established, whether dates were available, how repeated subjects were handled and where uncertainty remained. That information helps readers judge the result without creating a new privacy problem merely to demonstrate that an evaluation occurred.
The right conclusion remains conditional
Age assurance can be discussed seriously without pretending that all checks are equivalent or that every concern invalidates every possible design. A narrow age claim can expose less information than a complete identity record. A carefully evaluated process can perform differently from a casual guess. A functioning appeal can reduce the lasting consequences of an initial mistake.
Those possibilities do not establish a universal answer. The appropriate method depends on the purpose, the population, the evidence available, the consequences of error and the information the process collects. A technically impressive system can still be poorly suited to a particular service. A privacy-conscious architecture can still require stronger evidence about accessibility or performance.
The most useful public question is therefore not whether age checking works in the abstract. It is whether this process establishes this claim, for these people, under these conditions, with acceptable consequences and a credible way to correct mistakes.
That question is harder than asking a model for a number. It is also the question that matters to the person waiting on the other side of the screen.
Sources, scope and access notes
Prepared November 1,2026. No legal compliance advice, bypass instructions or actual user analytics. Numerical teaching examples are explicitly hypothetical. No chart of the Australian trial's disputed values is presented. The main-report PDF exceeded the web tool size limit; the112-page estimation volume and2026corrigendum were opened directly, so no claim of reading the entire multi-volume trial is made.
Primary institutional or original-research sources opened:
- NIST live evaluation, updated September29,2026.
- NIST IR8525, May2024,79-page report.
- EDPB Statement1/2025,11-page version withApril2025minor changes.
- Australian trial PartD,112pages; figureD.10.3 and adjacent narrative require numerical clarification; 2026bibliography corrigendum.
- Ofcom operational guidance, current page accessed preparation date.
- A-GE preprint, October23,2026,15-page PDF opened; company-affiliated authors, no independent certification inferred.
- Ren et al. preprint, version3 October24,2026,10-page PDF opened; benchmark not deployment proof.
- European Commission architecture and rollout account, current official page, intended properties distinguished from completed implementation.
- OAIC guidance, March17,2026.
- ICO opinion, explicitly under review on opened page.
- Ofcom July16,2026 report landing page, early-results limitation verified; full92-page report not relied on.
- Lueks et al., March2026,53-page analytical research report opened.
- Ma et al., September2026,26-page literature-analysis preprint opened, not a new user experiment.