Member and guardian fields

Every field a person can fill in, what limits it, and which screen can supply it.

PTRS checks almost nothing before a save leaves the browser. The rule run on PTRS's own side, after the save is sent, is the only rule there is, and a person finds out it was broken after pressing Save. Where PTRS's own check is looser than the space actually available to store the value, the result is a plain server error with no explanation, not a helpful message; those cases are marked.

Four write actions in this module have no check at all: adding a guardian, verifying a document (a check exists on the wrong action; the one that runs takes free text), moving a document's status, and deleting a document. Of the twenty checks that do exist, eleven set a maximum length, a better ratio than any module read so far, and still not a complete one.

Member

A child's own record carries 44 fields. The table gives the space actually available, the rule PTRS enforces, and which of the four creation and edit surfaces can supply it.

The surfaces column uses four letters: QA for Quick Actions → Quick Member Entry, W for the eight-step registration wizard, E for the edit sheet on a child's record, and S for Quick Scan's extraction.

Field	Limit	Rule	QA	W	E	S	Notes
First name	100, required	Required on create and update	●	●	●	●	Set to "Unknown" on a scan when unreadable
Middle name	100	None		●	●	●
Last name	100, required	Required	●	●	●	●
Nickname	100	None		●	●	●
Suffix	20	None				●	Collected by the wizard's step 1 and never sent
Date of birth	Required, fixed at creation	Required on create only	●	●	✗	●	Cannot be changed after creation. The edit sheet shows it as required and does not send it
Gender	A named choice, 50	Checked; an unrecognised value fails the save	●	●	●	●	Male, Female, Non-binary, Prefer not to say, Other
Ethnicity	A named choice, 50	Checked; an unrecognised value fails the save		●	●	●	9 choices
Member Status	A named choice, 50	Checked; an unrecognised value fails the save		●	●	✗	10 choices; a scan always sets "New"
Status reason, status changed date	500	No rule					No writer anywhere
Membership Type	A named choice, 50	No rule		✗			No writer anywhere. The wizard offers six choices and does not send them
Organisation member id	100	No rule					No writer anywhere. The badge falls back to the child's internal record id
Grade	20	None	●	●	●	●	Free text. Three vocabularies; see Age and grade
Photo	2000	No rule					No writer anywhere. Every avatar falls back to an outside image service
Primary guardian	A link to a guardian record	No rule	●	●		●	Set only when a guardian is created alongside the child
Language Preference	A named choice, 50	Checked; an unrecognised value fails the save		●	●	●	English, Spanish, Haitian Creole
Enrolment date	Required, fixed at creation	Required on create only	auto	auto	✗	auto	Always today's date; the edit sheet shows it and does not send it
Active flag	Yes or no	No rule					No writer after creation. Always "yes" on every row
Allergies	A short list	None		⚠	⚠	●	Must be a specifically formatted list. See The list fields
Medical Alerts	A short list	None		⚠	⚠	●	Same
Medications	A short list	None		⚠	⚠	●	Same
Hobbies, Other Programs	A short list	None			⚠		Same
Primary phone	20	None		✗		●	Collected by the wizard and never sent
Email	256	None, no format check		✗		●	Collected by the wizard and never sent
Home address	500	None		●	●	●
City	100	None		●	●	●
State	50	None		●	●	●	The wizard offers 51 two-letter codes; the field accepts anything
Postal code	20	None		●	●	●
County	100	None		✗		●	Collected by the wizard and never sent
Home phone	20	None		●	●	●
School name	200	None		●	●	●
School district	200	None		●	●	●
Referral source	A named choice, 50	Dropped without a message when unrecognised		⚠	●	●	See Referral source
Previous member, previous member years	Yes/no, a number	None; the years figure has no range rule		●	●	●	The wizard caps it at 0 to 20 on screen only
Can swim	Yes or no	None		●	●	●	Set to "no" on a scan when unreadable
Physician name	200	None		●	●	●
Physician phone	20	None		●	●	●
Preferred hospital	200	None		●	●	●
Hospital phone	20	None		●	●	●
Insurance company	200	None		●	●	●
Insurance policy number	100	None		●	●	●	Stored in plain, readable text
Pickup password	100	None		●	●	●	Stored in plain, readable text; returned whenever the record is read
Linked user account	A link	No rule					No writer in this module

Length limits stop at the two names

First name and last name are the only fields on a child's record with a length rule actually enforced. Every other field has a limit and no rule checking it, so an over-length address, school name, physician name, insurance number or pickup password fails with a plain server error, not a helpful message naming the field.

Email has no format rule either, on the child or on the guardian.

The list fields

Allergies, Medical Alerts, Medications, Hobbies and Other Programs each hold a short list, and PTRS stores whatever is sent, checked by nothing.

The edit sheet is explicit about the shape it expects, showing examples like a bracketed, quoted list of items, and what a person types is sent exactly as typed. Typing a plain sentence instead of that shape produces a server error.

The registration wizard is not consistent about it. It sends the medical conditions and current medications boxes, both ordinary paragraphs of text, into the same two fields that expect the structured list shape. Any child with a recorded medical condition or medication therefore fails at the very first step of the wizard's save sequence with a database error.

Only the allergies field is safe from the wizard, because it alone is built into the correct shape before sending.

The child's own record parses these fields back defensively: anything that is not a proper list renders as an empty list rather than breaking the page.

Age and grade

PTRS enforces no age eligibility anywhere. There is no minimum, no maximum, no future-date check and no relationship between age and grade, not on save, not on the record, not on any of the four input surfaces.

The only age arithmetic in the module is:

Where	What it does
Directory filter	Four fixed bands, 5 to 8, 9 to 11, 12 to 14, 15 to 18, converted to a date-of-birth range on PTRS's side. The arithmetic is correct
Registration wizard	Shows the calculated age, and shows a COPPA notice when the child is under 13 and an email address has been entered
Consents step	Shows the same COPPA notice under 13

The four bands and the age of 13 are fixed values written into the screens. The code cites no regulation for any of them. The COPPA notice names COPPA in its text and gives no section reference.

The age-range arithmetic itself is correct and uses the right boundary on both ends.

Grade is free text with three vocabularies, matched exactly in the filter:

Screen	Values
Registration wizard	Pre-K, K, 1st, 2nd, up to 12th
Directory filter	Pre-K, K, 1st, 2nd, up to 12th
Quick Member Entry	K, 1, 2, up to 12; no Pre-K
Edit sheet	Free text, placeholder "e.g., 5"

A child added through Quick Member Entry in third grade is stored as a bare "3", and the directory's Grade filter, which looks for "3rd", will never find them.

Referral source

PTRS recognises eleven referral sources: Newspaper, School, Radio, Mailer, Flyer or Poster, Friend or Family, Staff or Club Member, Club Event, Website, Social Media, Other.

The registration wizard offers seven, and only three of them are spelled in a way PTRS accepts:

Offered	Accepted
School, Website, Other	Yes
Friend/Family, Community Event, Social Media, Walk-in	No

An unrecognised value is dropped without a message; PTRS only assigns the field when the match succeeds, and returns no error either way. Four of the seven choices therefore leave the field blank with no indication.

Editing the field afterward behaves the same way.

Guardian

A guardian record belongs to the organisation, not to one child, and is joined to a child through a link record.

Field	Limit	Rule	Add Guardian	Edit guardian
First name	100, required	Enforced on edit only	●	●
Last name	100, required	Enforced on edit only	●	●
Email	256, required	No rule on either	●	●
Phone	20, required	Required, enforced on edit only	●	●
Relationship	100	Required, enforced when linking	●
Preferred contact method	A named choice, 50	Not applicable
Language preference	A named choice, 50	Not applicable
Work phone	20	None		●
Work phone extension	10	None		●
Employer	200	None		●
Occupation	200	None		●
Military status	A named choice, 50	Dropped without a message when unrecognised		●
Military branch	100	None		●
Military installation	200	Not applicable		No writer
Lives on base	Yes or no	None		●
Military start date, end date	A date	Dropped without a message when unrecognised		●
Home address, city, state, postal code	500/100/50/20	None		●
Maiden name	100	None		●
Cell phone	20	Not applicable		No writer
Lives with member, is emergency contact, can receive communication	Yes or no	Not applicable		No writer except Quick Scan
Sign-in account link, linked user account, notification preferences	Various	Not applicable		No writer in this module

Everything in the "Edit guardian" column is unreachable

Editing a guardian is built to accept eighteen fields, and no screen ever calls it. So the eighteen fields it accepts can be read back on the guardian's own record and can never be set.

Add Guardian collects five fields and has no check on it at all. Since email and phone are required fields and the request sends them as plain values with no rule, a blank value for either produces a plain server error rather than a field-level message.

Two guardians can share the same email address; nothing stops it, and the one action that would link an existing guardian to a second child is reachable from no screen, so a family with three children ends up with three guardian records.

The member-guardian link

Field	What it is	Set by
Relationship	100, required	Add Guardian; set to "Parent/Guardian" on a scan when the form gave none
Primary flag	Yes or no	Add Guardian; always "yes" on a scan
Authorised for pickup	Yes or no, defaults to yes	Add Guardian; always "yes" on a scan

Each child-guardian pair can exist only once, and linking checks for a duplicate and refuses it before it can happen. Neither the uniqueness rule nor the duplicate check can actually fire in practice, because the only reachable path creates a fresh guardian every time rather than reusing one.

Emergency contact

Field	Limit	Rule	On the form
First name	100, required	Required	●
Last name	100, required	Required	●
Phone	20, required	Required; no length rule, so over 20 characters fails with a plain server error	●
Phone extension	10	None; over 10 fails with a plain server error	●
Relationship	100	None	●
Priority	A number, defaults to 1	Must be 1 or more when adding; no rule on edit	●
Second phone	20	Not applicable	No writer
Primary phone type, secondary phone type	A named choice, 20	Not applicable	No writer
Authorised for pickup	Yes or no	Not applicable	No writer except Quick Scan

The list is ordered by priority, and shows an "Authorised for pickup" marker for a flag no input on the form can actually set.

Authorised pickup and restricted person

Field	Limit	Rule	On the form
Authorised pickup
First name, last name	100, required	Required	●
Phone	20	None; over 20 fails with a plain server error	●
Relationship	100	None	●
Active flag	Yes or no	Set to yes on add, no on remove	auto
Authorised date	A date	Set to today on add	auto
Revoked date	A date	Set on remove, and then hidden along with the record	auto
Photo ID on file, photo, court order on file, authorising guardian, notes	Various	Not applicable	No writer anywhere
Restricted person
First name, last name	100, required	Required	●
Reason	2000	None; over 2000 fails with a plain server error	●

An authorised pickup's own description in the code says it supports DELACARE release-of-child rules and tracks a photo ID, a court order and the authorising guardian. None of those three can actually be recorded.

Consent

PTRS recognises 21 consent types, in the four groups the registration wizard uses:

Group	Types
General	Membership, Photo Release, Field Trip, Technology Use, Data Collection, Background Check, Open Door Policy, School Data Release
Medical	Medical Treatment, Emergency Hospitalization, Emergency Transportation, Caregiver Support Meeting
Medication	Medication Admin Request, Medication Consent Caregiver, Medication Consent Physician, Non-Prescription Med Authorization, EpiPen/Inhaler Authorization, Non-Intravenous Injection Authorization, Injection Liability Waiver
Health-adjacent	Sunscreen Application, Insect Repellent Application

The wizard's own list offers 19 of the 21, leaving out Membership and School Data Release.

Field	Limit	Rule
Child, organisation, consent type, signing guardian	Required	All required; consent type checked, an unrecognised value fails the save
Signature	10,000 characters	No rule; a captured signature image longer than that fails with a plain server error
Expiry date	A date	Checked; an unrecognised value fails the save
Consent granted flag	Yes or no	Always "yes" on create
Revoked date, revoked by	A date, a link	Set by the revoke action
Medication consent type	A named choice, 50	Checked; an unrecognised value fails the save
Physician name, phone, signature, signed date	200/20/10,000/date	Accepted by PTRS and not sent by the screen; the request only carries five of the ten fields
Document version, submitting address, witness name, member's own signature	Various	No writer anywhere

Whether a consent is currently active is worked out on the spot each time, not stored: it is active when it has not been revoked, and either has no expiry or the expiry has not passed.

The link to the signing guardian is a real, enforced link, which is why the registration wizard's made-up guardian identifier cannot work here.

Document

Field	Limit	Rule
Document type	A named choice, required	Required; checked against 24 choices, an unrecognised value fails the save
Document name	200, required	Required; the on-screen check allows 250, so a name of 201 to 250 characters passes on screen and fails with a plain server error once it reaches PTRS
File location	2000	Set by PTRS; blank when no file was attached
Upload date	A date	Set to today
Expiry date	A date	Checked; dropped without a message when unrecognised
Verified flag	Yes or no	Set to yes by verify; never set back
Verified by	256	Required, up to 200 characters; free text sent by the screen, not the account that is actually signed in. The Documents section sends the fixed word "current-user" on every verification
Verified date	A date	Set to today by verify
Status	A named choice	Checked by the status action, which nothing calls
Required flag	Yes or no	From the upload form
Notes	2000	Up to 2000 characters

Upload limits: 25 MB; PDF, JPG, JPEG, PNG, GIF, DOC, DOCX. The file itself is optional.

Required documents

Three lists exist and no two of them agree.

Source	Count	Types
The Documents section's checklist, the one a person actually sees, noted "per DELACARE compliance"	9	Birth certificate, immunisation record, physical exam, enrolment application, emergency contact form, emergency medical authorisation, medical release, photo release, insurance card
The registration wizard	5	The first three, plus school enrolment verification and emergency medical authorisation
PTRS's own missing-documents check	3	Birth certificate, immunisation record, physical exam

All three are fixed lists written into the code. None cites a regulation. The Documents section's is the only one that names a rule at all, in a note reading "required per DELACARE compliance", with no regulation number, no section and no date.

Verify the list your licensing authority requires against your own current source. The checklist on screen is not a compliance statement.

Two further limits on PTRS's own check: it ignores whether a document is actually marked required for that child, and it does not look at the expiry date, so an immunisation record that expired last year still counts as present. Nothing on any screen calls that check anyway, so the Documents section works out its own checklist in the browser instead.

Three of the type names the interface offers are not names PTRS recognises, and PTRS refuses to save them:

Offered on	Value	PTRS recognises instead
Documents section, 20 options	IEP Document	IEP Plan
Registration wizard, required list	School Enrollment Verification	Nothing similar
Registration wizard, optional list	Medical Form, IEP/504 Plan	IEP Plan and Section 504 Plan, kept separately

Enrolment prerequisites

Adding an enrolment is the module's one enforced safety gate. All five figures below are fixed values written into that one check.

#	Rule	Figure	Reads	Message
1	Minimum emergency contacts	2	Her emergency contacts	"has N emergency contact(s); minimum 2 required"
2	An active Emergency Hospitalization consent, granted, not revoked, not expired	Not applicable	Her consents	"does not have an active signed Emergency Medical Authorization consent"
3	Immunisations marked exactly up to date	Not applicable	Her structured medical record	"does not have immunizations marked as up to date"
4	Physical exam within	1 year	Her structured medical record's last physical date	"physical exam is expired or missing"
5	Every emergency-type medication on site cleared to administer	Not applicable	Medications on site	"has emergency medication that is not ready for administration"

The code cites no regulation for the 2 or the 1 year. No federal reference, no DELACARE citation, no note explaining either figure. Verify both against your own current source.

A sixth rule is a warning only. If her medical conditions text contains any of six words, asthma, diabetes, seizure, allergy, anaphylaxis, epilepsy, in any case, and she has no active emergency action plan, the save still succeeds and PTRS quietly logs a warning to the audit trail. Nothing reads that warning and no screen shows it, so it reaches nobody.

The gate reads a record most creation paths never write

Checks 3 and 4 read her separate, structured medical record. Quick Scan and Quick Member Entry never create that record; Quick Scan writes the physician, hospital and insurance values onto her main record instead. So a scanned or quick-added child fails check 3 until somebody opens the Health tab and sets Immunizations Up to Date and a physical date.

A waiver setting exists that would skip all five checks and log who used it. No screen sets it, and PTRS applies no extra role check on it beyond the module's usual setting, which admits staff members.

The structured medical record

A child's structured medical record is a second, separate record, at most one per child. Six of its fields duplicate fields on her main record, and nothing reconciles the two.

Field	Limit	On PTRS's read	On PTRS's save	On the screen	Effect
Allergies	2000	●	●	✘	The screen omits it from both its own types, so it can never be set or shown from the interface
Medical conditions	2000	●	●	●	Works
Current medications	2000	●	●	●	Works
Medication administered at club	Yes or no	●	●	●	Works
Medication instructions	2000	●	●	●	Works
Dietary restrictions	2000	●	●	●	Works
Dietary restriction type	A named choice, 50	✘	✘	●	Always blank; the screen sends it and PTRS drops it
Special medical needs, in a person's own words	4000	✘	✘	●	Same
Behavioural health notes	4000	✘	✘	●	Same
Physician name, phone	200/20	●	●	●	Duplicates the main record
Preferred hospital, hospital phone	200/20	●	●	●	Duplicates the main record
Insurance provider, policy number, group number	200/100/100	●	●	●	The first two duplicate the main record
Can swim	Yes or no	●	●	●	Duplicates the main record
Physical limitations	2000	●	●	●	Works
Last physical date	A date	●	●	●	Read by enrolment check 4
Immunisations up to date	Yes/no/blank	●	●	●	Read by enrolment check 3
Blood type	10	●	●	●	Free text, no fixed vocabulary

Saving this record only actually requires the child's id. None of the eighteen fields has a length rule, so any of the six 2000-character fields overflows into a plain server error.

Four fields are marked for removal in the code in favour of newer, structured records: a structured allergy list, a structured chronic condition list, a structured current-medication list, a structured physical-limitation list. None of those four has a writer anywhere in the solution, and both actions that touch this record silence the warning that would normally flag using a field marked for removal.

Three parallel allergy models

Model	Written by	Read by
A short list on the main record	Quick Member Entry, the wizard, the edit sheet, Quick Scan	The member detail banner and the printed badge
Free text on the structured medical record, marked for removal	Nothing; the screen omits the field	The Health tab
The structured allergy record	Nothing anywhere in the solution	CACFP's allergy alerts, CACFP's meals-with-alerts list, CACFP's allergen cross-reference, Health and Safety's enrolment readiness check

The three do not see each other. An allergy typed into the interface is visible on the child's own record and to nothing else in the product.

Demographics, financial and enrolment history

Each has at most one record per child.

Her demographics record can hold household setting, family setting, sibling counts, household size, income range and government assistance programmes. A details field, a primary language field and a previous club name field exist on the record and have no writer. The three named- choice fields are dropped without a message when unrecognised. Saving this record only actually requires the child's id and the organisation, and nothing calls the action anyway.

Her financial record can hold annual household income, free/reduced lunch, receives childcare subsidy, subsidy case number, government assistance programmes, billing type and monthly fee; last payment date, balance due and the confidential flag are returned and have no writer. The only rule PTRS checks beyond the child's id is that the fee is zero or more. Both actions are narrowed; see Member financial information.

Her enrolment history can hold enrolment type, enrolment date, effective start date, expiry date, membership fee, fee-waived flag and reason, payment method, application received date, ID card issued date, orientation completed flag and date, and processed-by, all coming from the request; a data-entry date is stamped as today automatically. The processed-by field is free text, not the signed-in account's actual identity. Termination date and reason are set only by the terminate action, and there is no un-terminate.

What the audit trail records, and what it leaves out

Every save in the module logs to the audit trail, which records a snapshot of the record before and after.

A field marked for exclusion is left out of that snapshot entirely; it is not hidden, it is absent. The reasoning behind the exclusion, documented in the code, is that it protects sensitive fields such as tokens, personal detail and medical data that should not appear in an audit entry.

On the child's main record, twelve fields carry that exclusion:

Excluded from the audit snapshot
Allergies, medical alerts, medications
Physician name, phone, preferred hospital, hospital phone
Insurance company, insurance policy number
Pickup password
Primary phone, email, home address, city, state, postal code, home phone

The guardian record excludes email, phone, work phone and extension, address, maiden name and cell phone. A consent excludes all three signature fields and the submitting address. The structured medical record excludes almost everything it holds.

The audit row still records that the child's record was updated, by whom and when. It does not record what changed in any of those fields.

What this costs a reviewer

A state reviewer asking "who changed this child's allergy list, and when?" gets an entry saying the record was updated, with the changed fields absent from both the old and the new values.

Combined with the child's own audit history only showing changes to her main record, so guardian, contact, consent, document and note changes do not appear at all, the Audit panel inside the edit sheet shows changes to her name, school, grade, status and swimming ability, and nothing else.

This is a deliberate privacy trade-off in the code, not a defect. It is recorded here because the product's audit trail is presented as tamper- evident and complete, and on this module it is tamper-evident and partial.

Where to go next

• Who can do what with members and guardians, all 59 actions and whether anything reaches them
• Member financial information, the two narrowed screens
• What Quick Scan extracts, the eight silent defaults a scan applies to these fields
• Members troubleshooting