Scan a paper application

A guardian hands in a completed paper membership form. Quick Scan photographs it, reads the fields with a language model, puts them in front of a person, and, once that person presses Confirm & Create Member, writes a child, a guardian and an emergency contact all in one save.

It is the fastest route from paper to a usable record, and the only place anywhere in PTRS where a photographed document is actually read into individual fields. The AI Assistant's own regulation library, the only other feature in the product that reads a document at all, only accepts plain text and reads it exactly as typed. See index a regulation document.

This is also the flow with the sharpest gap between what the review screen seems to promise and what confirming actually writes, so this page traces both sides of it.

The flow at a glance

#	Step	Documented in
1	Upload one form, or a batch of up to 20	Review a scanned application
2	The file is stored and a scan record is created	The pipeline, step by step
3	A language model reads the fields	It is a real model call
4	A person reviews the reading against the paper	What to check before confirming
5	Confirm, the child, guardian and contact are written	What is written when the reviewer presses Confirm
6	Or reject, and enter the form by hand instead	Add a child to PTRS

After step 5, the child exists as a real record. Everything in enrol a child from step 3 onward still has to be done separately; a scan does not enrol anybody in anything.

Steps 1 to 3: upload and reading

The screens are on review a scanned application; what happens behind them is on what Quick Scan extracts.

This is a genuine model call, not a simple keyword match: the file is encoded and sent to an outside AI service with a fixed brief and a fixed, 57-field structure to fill in, kept as close to the facts as possible. Two other features elsewhere in PTRS that are presented as AI, the incident-writing assistant and incident pattern detection, are both simple keyword matches run in your own browser, and Quick Scan is not one of those.

Whether reading runs at all depends on one setting

The access key for the outside AI service is blank both in the checked-in default configuration and in the production environment template. A blank value is treated as present rather than missing, so the connection is still set up either way, and every request goes out with an empty key.

With no working key, every upload is still accepted, saved, given a scan record, marked as processing, retried twice, and finally stored as failed, with that outside service's own response as the reason. At least the failure is visible: a red message and a red "Failed" badge in the queue. See whether it runs at all.

Upload in single files, not batches

A batch runs up to three files at once through a single, shared connection that was never built to be shared this way. A batch of two or more files can fail unpredictably with a message about a second operation starting on the same connection. A single upload is not affected. See batch.

Step 4: the review, and what it can actually change

This is the step this whole flow page exists for, because the screen and the actual outcome disagree with each other.

The review screen shows the fields it read with a confidence dot beside each one. What that dot actually is, and what it is not, is at the confidence figure. Read that before treating a high number as a reason to skip checking a field yourself.

The review fields cannot be edited, and a correction would not actually be sent even if one could be made

Two separate facts, either one of which alone would already be enough.

Typing produces no visible change at all. The review screen's own boxes are locked to their original value and quietly ignore anything typed into them. There is no error message and nothing looks disabled; the field simply looks editable and refuses everything you type into it. See fields cannot be edited.

The corrected information is never actually sent, even if you could change it. Confirming a scan can optionally carry a corrected version of the reading, and PTRS would prefer it over the raw reading if it were ever sent. Both places that confirm a scan send only the scan's own id and the reviewer's own notes, so that corrected version is always left empty, and the child's record is always created straight from the model's own original reading. See corrections not sent.

The one thing a reviewer can genuinely contribute is a note, behind the Add Notes option. It is stored on the scan's own record and appears nowhere else at all.

So the review is really a simple accept-or-reject decision, not an editing step at all. Confirm accepts the reading exactly as the model produced it; Reject throws it away entirely. There is no third choice, and no way to accept eleven fields while fixing a twelfth.

Step 5: what Confirm actually writes

Confirming requires the scan to already be in a read state, matches the reading to real records, and saves everything in one single save, so a confirmation either all happens or none of it does.

Written	Detail
The child's own record	34 fields, plus a status of new, active, with today as the enrolment date
The guardian's own record	16 fields, contact method set to email, language set to English, marked willing to receive communication
The link between them	Marked primary, authorised for pickup, with the relationship taken from the form
An emergency contact	Only if a first or last name was actually read, given the top priority
The scan's own record	Marked confirmed, with the new child's own id, who reviewed it and when
The audit trail	One entry naming the child that was created

Two things follow from this that no other single page in this whole site is positioned to actually say.

Quick Scan is a path that genuinely creates guardian records. The bulk data-import wizard is not: it offers every guardian and emergency-contact column and writes none of them, so a child brought in through an import has no guardian recorded at all. See what an import writes and step 4 of open a new organisation. For a club holding paper forms on file, scanning them actually produces a more complete record than importing a spreadsheet ever would.

A name that could not be read becomes the literal word "Unknown". A guardian whose name did not come through is stored with both first and last name reading "Unknown" rather than left empty, and a missing phone number or email is stored as an empty value rather than left out. A record reading "Unknown Unknown" is a child whose primary guardian nobody can actually contact, and it will not look like an error on any screen you open. The full table of these defaults is at the defaults.

There is no duplicate check of any kind

Confirming a scan for a child already in PTRS creates a second, separate record for them. Search the child directory for the name before confirming. See work the member directory.

What to check against the paper, every single time

The full list is on what to check before confirming and the reasoning behind each item on what a person must still check. The four that matter most:

Date of birth. It drives nothing automatically anywhere in PTRS, and everything a person decides about where to place that child.

The guardian's first and last name. Reading "Unknown" here means an uncontactable primary guardian.

The guardian's phone number and email. A missing one is stored silently as empty, with nothing to flag it.

Allergies and medical facts. These are safety-critical, and this review is the only moment anyone actually compares them against the paper form.

Keep the paper itself. It is the only way to correct anything: a field the model read wrong can be fixed afterward, directly on the child's own record. See work a child's record. The paper is what you fix it against.

What this flow does and does not do

Reads a photographed form and extracts 57 fields	Yes, with a real model call
Creates a child, a guardian and an emergency contact together	Yes
Lets a reviewer correct a misread field before creating the record	No. The fields refuse input, and corrections are never actually sent
Detects that the child is already in PTRS	No
Enrols the child in anything	No. See enrol a child
Notifies the guardian	No. Nothing in PTRS ever creates a notification

Related

• Members overview, Members troubleshooting
• Member and guardian fields
• Who can do what with members and guardians
• How PII is protected in the AI pipeline, the AI Assistant's own boundary, a completely different pipeline from this one