Every summer, the same pressure materialises. Passenger volumes surge. Flight schedules tighten. And somewhere in the background - less visible than the queues at security, but no less consequential - a Customer Care team is processing applications from passengers with hidden disabilities who need assistance for their journey.

These are not routine enquiries. Applications for services like accessibility scheme registration involve supporting documentation: diagnostic letters, specialist referrals, GP correspondence, professional assessments. They carry health data - GDPR Article 9 special category data - submitted by passengers who are often anxious, often flying with family members who depend on the outcome, and who applied weeks earlier and have heard nothing because the queue ran long.

The manual review model that most airports use for these applications has a structural problem that summer amplifies: the volume of incoming documents does not scale with the capacity of the team reviewing them. When review time is entirely a function of staff hours, peak-season queue load means delayed decisions, which means passengers travelling without the support they were entitled to.

The Document Intelligence triad - classifier, extractor, authenticator - is the architecture that changes this equation. Not by removing human reviewers from a process that requires them, but by doing the reading for them.

The Queue Problem, Precisely Stated

To design the right solution, it helps to be precise about where the bottleneck actually sits. In a typical manual document review workflow for an accessibility scheme, the process runs something like this:

A passenger submits an application with supporting documentation - usually via email or a web form - attaching a diagnostic letter, a GP note, or a specialist assessment.
The application joins a queue. At low volume, the wait is days. At peak summer, it can extend to weeks.
A Customer Care agent opens the application, reads the supporting document, checks it against the scheme's eligibility criteria, and makes a decision: approve, decline, or request further information.
If approved, the agent processes the outcome - in legacy systems, triggering a postal fulfilment process for a physical lanyard or card. In more modern deployments, issuing a digital entitlement.
The applicant receives confirmation.

The bottleneck is step three. Everything else in the process is largely administrative and scalable. Document reading - understanding what a clinical letter says, extracting the diagnosis, mapping it against the eligibility rules for this specific scheme - is cognitive work that currently requires a trained human being to perform it from scratch, on every document, in sequence.

At 50 applications per week in winter, this is manageable. At 400 applications per week in July, it is not - not without overtime, not without backlogs, and not without the periodic failure mode where a passenger turns up at the airport without their Fast Track authorisation because the approval email arrived the morning they flew.

The document reading step is where the queue forms. Everything upstream and downstream of it can be automated. The question is what it takes to automate the reading without automating the decision.

Why This Process Touches GDPR Article 9 - and Why That Matters for the Architecture

Before describing the technical solution, the data context is essential - because it determines what the architecture must be, not merely what it could be.

Supporting documentation for accessibility scheme applications almost always contains health data. A diagnostic letter confirming Autism Spectrum Disorder. A GP note referencing a sensory processing condition. A specialist assessment describing functional impairments that make certain aspects of airport navigation distressing or dangerous. Under both EU and UK GDPR, this is Article 9 special category data: the most tightly regulated category of personal information, subject to strict processing conditions and heightened accountability obligations.

The implications for an AI-assisted document review system are specific and non-negotiable:

‍‍Explicit consent or an applicable Article 9(2) condition is required. Processing health data in support of providing a disability-related service to the data subject falls under Article 9(2)(b) - obligations and rights in employment, social security, and social protection - and potentially Article 9(2)(a) if explicit consent is obtained at application. The legal basis must be identified, documented, and defensible. ‍
Automated decisions with significant effect require human review. Article 22 of the GDPR restricts solely automated decisions that produce legal or similarly significant effects. An accessibility entitlement - particularly one that affects whether a passenger can use Fast Track or receive proactive staff support - has significant practical effect on the individual. Human review of the AI recommendation is not optional: it is legally required and architecturally essential. ‍
The processing must be proportionate. The system should extract what it needs for the eligibility assessment and no more. Storing health data beyond what is necessary for the decision, or using it for any purpose other than the stated one, is a compliance failure regardless of the quality of the AI. ‍
The audit trail must be complete. Every decision - AI recommendation and human outcome - must be recorded with a timestamp, the basis for the decision, and the evidence on which it rested. If a decision is ever challenged, the organisation must be able to reconstruct exactly what the system did, what the reviewer saw, and why the outcome was reached.

These constraints are not obstacles to automation. They are the design specification. An architecture that satisfies all four of them is an architecture that can be deployed in production, withstand regulatory scrutiny, and be trusted by the passengers whose data it handles.

The Document Intelligence Triad

The classifier, extractor, and authenticator are three distinct AI capabilities that operate in sequence on each incoming document. Each has a specific function, a specific scope, and specific failure modes that the architecture must handle.

Step 1: The Classifier

The classifier's job is to identify what kind of document has been submitted and whether it is the right kind of document for this application type. Before a reviewer reads a single word, the classifier has already answered: is this a GP letter? A hospital consultant's report? A psychologist's assessment? A school EHCP document? Or is it something else entirely - a utility bill submitted by mistake, an image of the wrong document, a file that cannot be read?

This step catches the most common and most time-consuming queue pollutants. In a manual process, a reviewer opens an attachment only to find it is the wrong document, sends a chase email, and waits. In an IDP-assisted process, the classifier flags this immediately upon submission and triggers an automated acknowledgement to the applicant asking for the correct document - before the application has entered the human review queue at all.

The classifier also routes. A diagnostic letter from a psychiatrist confirming ASD follows a different extraction path than a GP referral letter that mentions sensory sensitivities in passing. The classifier determines which extraction model and which rules pack to apply to the document downstream.

Step 2: The Extractor

The extractor reads the classified document and pulls out the specific data fields that the eligibility assessment requires. For an autism or sensory processing disorder application, this typically means:

Confirmation that a formal diagnosis has been made
The specific condition or conditions identified
The date of diagnosis or assessment
The professional credentials and registration of the issuing clinician
Any functional descriptions relevant to the scheme's eligibility criteria

The extractor does not summarise. It does not interpret. It does not make an eligibility recommendation. It extracts specific, bounded data points against a defined schema - and it records a confidence score for each extraction. Fields where confidence is below a defined threshold are flagged for reviewer attention. Fields above threshold are presented to the reviewer pre-populated, ready for validation rather than first-pass reading.

This is the step that changes the economics of review. A reviewer who previously spent three to five minutes reading a letter to extract these data points now spends thirty seconds validating extractions they did not have to make themselves. The cognitive work is front-loaded onto the AI. The human work becomes verification - which is both faster and, because it is a checking task rather than a reading task, more reliable.

50–70% reduction in document processing time typically achieved by IDP implementations - with some deployments moving from 7+ minutes per document to under 30 seconds (Docsumo, 2025)

Step 3: The Authenticator

The authenticator is the most sensitive component - and the one most frequently underspecified in IDP deployments that are built for speed rather than compliance.

Its function is to assess whether the document is what it claims to be. For accessibility scheme applications, this means cross-checking the issuing clinician's details against professional registers where available, checking structural markers that distinguish legitimate clinical correspondence from fabricated or altered documents, and flagging documents that present specific risk indicators for manual review.

A critical design principle governs this step: the authenticator never rejects. It flags. The determination that a document is inauthentic - and the consequences that flow from that determination, including any referral - is a human decision. The AI surfaces the indicators. The reviewer makes the call. This is not caution for its own sake; it is the correct interpretation of Article 22 in a context where the decision has significant effect on the individual.

It is also practically important for accessibility applications specifically. The population applying for these schemes includes individuals whose documentation may be older, may originate from a different healthcare system, or may use non-standard formatting because it was issued by a specialist charity or educational institution rather than an NHS practice. Automatic rejection based on format anomalies alone would systematically disadvantage the very passengers the scheme exists to support.

What the Reviewer Sees

The output of the triad is not a decision. It is a pre-populated review screen that presents the extracted data, the confidence scores for each field, any authentication flags, a provisional eligibility indicator based on the rules pack, and the original document alongside - so the reviewer can validate each extraction directly against the source.

The reviewer's task is now structured, not open-ended. They are not reading a letter and constructing an eligibility assessment from scratch. They are checking that what the AI extracted is what the letter actually says, reviewing any flagged fields, and confirming or overriding the provisional eligibility indicator. If they override, they record a reason. That reason, along with their identity, timestamp, and the document state at the time of review, enters the audit log.

In this model, the AI handles document reading. The human handles the decision and holds accountability for it. GDPR Article 22 is satisfied not as a formal checkbox but as a genuine operational reality: the human reviewer has sufficient information, sufficient time, and sufficient authority to make a meaningful decision. The AI has not made the decision for them. It has made it possible for them to make a better decision, faster.

The goal is not to automate decisions out of the hands of Customer Care agents. It is to remove the reading from their queue, so that what remains is genuinely decision-shaped work that only a human should do.

The Peak Summer Queue: What Changes

With the triad in place, the relationship between application volume and review capacity changes fundamentally.

In the manual model, queue length is a direct function of staff hours. Double the applications: double the queue length, or double the overtime. There is no other lever. In the IDP-assisted model, a large proportion of the queue management work - document classification, data extraction, initial quality checks, routing of incomplete or incorrect submissions - is handled by the system at machine speed, regardless of volume. The human review queue contains structured, pre-processed applications rather than raw submissions.

The practical consequences at peak summer are significant. Consider a team of four Customer Care agents who can individually process thirty applications per day in the manual model - working through each letter from scratch. In the IDP-assisted model, the same four agents, working from pre-populated review screens, can validate and decide on applications significantly faster. Deployments applying IDP to high-volume document workflows consistently report 50–70% reductions in processing time per document. Even at the conservative end of that range, the same team handles materially higher volume without additional resource.

More importantly, the backlog does not accumulate in the same way. In the manual model, a spike in submissions on a Monday creates a backlog that does not clear until Friday - meaning passengers who applied that week may not hear before their flight. In the IDP-assisted model, the classifier and extractor run on submission. Incomplete or incorrect documents are flagged and chased immediately, not when a reviewer finally opens them three days later. Applications with straightforward documentation and high-confidence extractions can be surfaced to reviewers as a prioritised batch, reducing the time from submission to decision for the clearest cases.

Up to 80% reduction in end-to-end processing time for document-intensive applications - with one IDP deployment cutting claims processing from 20 days to under 4 (Netcall / Input For You, 2025)

The Audit Trail as Operational Asset

One benefit of the IDP architecture that is underappreciated until the first regulatory query or complaint arrives is the quality of the audit record it produces automatically.

In the manual process, the evidence trail for an eligibility decision is typically an email chain and a note in a CRM. What document was submitted, what it contained, what the reviewer concluded, and why - these may be partially reconstructable, but they are rarely complete, and the effort required to reconstruct them retrospectively is significant.

In the IDP-assisted process, the audit log is a by-product of normal operation. Every document that enters the system generates a record: document received, classifier output, extractor outputs with confidence scores, authenticator flags, reviewer actions, decision timestamp, and decision rationale if an override was recorded. This record is created at submission time and requires no retrospective effort.

For a process handling GDPR Article 9 data, this matters beyond the individual case. It is the foundation of demonstrable compliance: the ability to show, for any decision, exactly what data was processed, by whom, on what basis, and with what outcome. If a passenger challenges a declined application, or a regulatory authority asks for an audit of the scheme's decision-making, the organisation has a complete, structured, queryable record rather than a fragmented email trail.

The audit log also drives scheme improvement. Patterns in override rates - reviewers consistently correcting a specific extractor field, or overriding provisional eligibility in a specific document type - are signals that the rules pack or extraction model needs refinement. This feedback loop does not exist in the manual process; it is inherent in the IDP architecture.

Design Principles for Sensitive Document Processing

Building this system for accessibility scheme applications - rather than a less sensitive document type like invoice processing - requires a set of explicit design commitments that should be non-negotiable in the specification:

Minimum necessary extraction. The extractor schema should contain only the fields required to assess eligibility against the scheme's defined criteria. Extracting additional health data - even if it is present in the document - is a GDPR violation waiting to happen. The schema is owned by the scheme operator, not the technology team. ‍
Confidence thresholds that err toward human review. For Article 9 data, the threshold for flagging a field for reviewer attention should be set conservatively. A false flag that adds thirty seconds of reviewer time is a minor inefficiency. A confident extraction that is wrong, and that a reviewer does not catch because it looked convincing, is a compliance and reputational failure. ‍
No storage of health data beyond decision completion. Once the eligibility decision has been made and the entitlement issued or declined, the supporting health documentation should be retained only for the legally required minimum period and under defined access controls. The IDP system should not become an inadvertent repository of health data. ‍
Reviewer override as a first-class workflow. The system must make it easy - not merely possible - for reviewers to override the AI recommendation. If the override path is friction-heavy, reviewers will follow the AI recommendation even when their judgement disagrees. That is not human oversight; it is automation with a human rubber stamp. ‍
Plain-language explanation at every stage. Passengers must be able to understand, in accessible language, what the process involves, what data is being processed, and what rights they have. For an accessibility scheme specifically, this is not a legal nicety - it is a fundamental design requirement for a service that exists to support people who may find complexity or ambiguity particularly distressing.

The Chassis That Reuses Across the Organisation

The architecture described here - classifier, extractor, authenticator, pre-populated review screen, decision log - is not purpose-built for accessibility applications. It is a document processing chassis.

The same chassis, with a different document type and a different rules pack, handles sick certificate triage for HR. Special leave applications. Airport ID card processing. Supplier onboarding documentation for procurement. Inbound email attachments that currently sit in an unmanaged mailbox and surface only when someone has time to look.

This is the commercial argument that goes beyond the accessibility use case: the investment in the classifier-extractor-authenticator stack is not a single-use spend. It is infrastructure. Each additional document type that runs through it requires a new rules pack - which is owned by the relevant business team - and a new extraction schema. The AI model, the review workflow, the audit log, and the compliance architecture are already there.

For organisations evaluating the investment case, the calculation should be made across the full universe of document-intensive queues that currently consume skilled staff time: not just the most visible one at peak summer, but every queue where a human being is spending time reading a document that a machine could have read first.

Cutting Review Time Is Not the Point. Protecting What the Review Is For Is.

The framing of this solution as a queue management tool misses its more important quality. Yes, the Document Intelligence triad reduces review time. Yes, it absorbs volume spikes without proportional increases in staffing. Yes, it produces a better audit trail than the manual process.

But the reason these things matter in an accessibility context is not operational efficiency. It is that passengers with Autism Spectrum Disorder or sensory processing conditions who have applied for a scheme designed to make their journey less overwhelming deserve to know, before they travel, whether their application has been approved. A backlog that means they arrive at the airport without a Fast Track code - or that means their carer spent the morning trying to reach a Customer Care team that is under-resourced at peak summer - is not an abstract operational failure. It is a failure of the service promise.

The Document Intelligence triad does not change the commitment that Customer Care makes to these passengers. It gives the team the capacity to honour it - at volume, under pressure, with a compliance record that stands up to scrutiny - in the weeks when the commitment is hardest to keep. If you're interested to know how we can help, contact us.