aia-website/www/reports/phase-9-two-form-integration-specification-2026-10-28.md

Phase 9 — Two-form integration specification

Recorded: 2026-10-28 UTC

Scope: future Form A consultation configuration and future Form C referral initiation Status: owner direction documented; no Jotform or Astro route activation authorized

Decision revision

The owner has replaced the former three-physical-form plan with two physical Jotform forms:

• Form A — General Enquiries, landing enquiries and family service consultations. The existing Form A ID remains 262946078314059; its approved contact and landing contexts and seven current Astro placements are unchanged.
• Form C — Professional Referral Initiation. It remains a separate future blank form with no assigned Jotform ID.

Form B is retired as a physical form. Historical Form B decisions remain in the versioned contract and plan. The repository may keep service as a logical visitor-intent classification, but it will map to Form A's planned consultation context after the required Builder configuration and acceptance.

This revision does not enable a new route, add an iframe placement, modify Form A, create Form C, add a query parameter, alter a canonical URL, promise an appointment, or change the frozen seven-route Form A production allowlist.

Form A contexts and planned consultation contract

Context	Status	Intended audience	Required route state
contact	Existing, owner-tested	General contact enquiries	Current two-contact-route gate only
landing	Existing, owner-tested	Five named campaign landing journeys	Current five-landing-route gate only
consultation	Planned; not configured or emitted	Family service consultations	Builder configuration, synthetic acceptance and a separately approved Astro allowlist

The context value is presentation-only. It is not an authorization, attribution, security, analytics or visitor-controlled value. formContext remains the known case-sensitive hidden-field Unique Name; no other Jotform field ID or condition name is inferred here.

Planned consultation fields

The consultation context reuses the current Form A adult contact and preferred contact-method behavior, including its existing conditional email/phone validation. It adds one required controlled question:

Which service would you like to discuss?

Approved display option	Logical intent only
ABA Therapy	aba_therapy
AIA Preparatory Academy	aia_preparatory_academy
Learner Social Club	learner_social_club
Autism Diagnostic Evaluation	autism_diagnostic_evaluation
I'm Not Sure Yet	not_sure_yet

The values in the right column are planning labels, not Jotform option values or IDs. Operations and the Jotform owner must approve the exact Builder labels, translations, requiredness and conditions.

When Autism Diagnostic Evaluation is selected, show this owner-approved explanation:

AIA can help families connect with qualified providers who offer autism diagnostic evaluations. Diagnostic evaluations are not currently available at our clinic.

This is referral-assistance language. It does not state or imply that AIA currently provides an in-clinic diagnostic evaluation, offers a diagnosis, or has completed a diagnostic-professional hire.

Do not add child name, date of birth, age, diagnosis, medical history, records, insurance member ID, payment, location or booking questions to the initial consultation context. Do not make any additional consultation field required without a separately documented operations, clinical and privacy decision. Whether an existing optional free-text message remains visible requires the existing Form A privacy treatment; it is not an additional required consultation field under this specification.

Form C — Professional Referral Initiation

Form C remains a separate future physical Jotform created from a blank form. Its initial, minimum-necessary specification is:

Semantic field	Requirement
Professional name	Required
Organization	Required
Work email	Required
Work phone	Optional, pending operations confirmation
Service of interest	Required controlled selection

The visible form must instruct referrers not to submit patient names, dates of birth, diagnosis narratives, medical records or other patient-identifying information. Detailed referrals remain in the separately approved protected workflow. No Form C ID, hosted URL, iframe, language route or conditional logic is assigned by this document.

Future route and component matrix

The following is a future integration plan. Every listed consultation surface continues to use its current inactive/off/mock behavior until Form A's consultation configuration is approved, synthetically tested and added through a separately authorized code change.

Route or entry point	Locale	Current component / behavior	Future physical form and context	Dependencies
/client-consultation	EN	FormShell.astro through PageLayout.astro; inactive logical service form	Form A / consultation	Builder fields, EN copy, new allowlist and synthetic acceptance
/es/client-consultation	ES	Same component; inactive logical service form	Form A / consultation	Spanish Form A labels, errors, evaluation explanation and locale test
/schedule-consultation	EN	FormShell.astro through PageLayout.astro; inactive logical service form	Form A / consultation	Builder configuration, no-booking copy review and acceptance
/aba-therapy drawer	EN	ServiceInquiryDrawer.astro; inactive legacy child-data drawer	Form A / consultation	Separate drawer/copy redesign, clinical approval and dialog accessibility test
/autism-evaluations drawer	EN	Same drawer; inactive legacy evaluation variant	Form A / consultation	Required referral-assistance wording and clinical approval
/learner-social-club drawer	EN	Same drawer; inactive legacy Social Club variant	Form A / consultation	Program-eligibility/copy approval and dialog accessibility test
/referrals	EN	FormShell.astro, logicalForm=referral; inactive	Form C / future referral initiation	Create and verify Form C; no patient data in initial form

English and Spanish service-page CTAs already route visitors to the client consultation routes. They are navigation dependencies, not independent Form A iframe placements. The same is true of homepage, services, FAQ and library consultation CTAs that resolve to those pages.

The current Tour CTA in src/content/pages/en/tour.mdx points to /client-consultation. The planned consultation service list contains no tour choice. Intake/operations must decide whether Tour keeps that destination, moves to the existing general-contact/tour journey, or receives a separately approved context before any code or CTA change. This specification makes no Tour-route change.

Owner and Jotform actions before consultation activation

1. Confirm that extending the active Form A with a consultation context will not change the approved contact or landing journeys; record the rollback method for the Builder configuration.
2. Configure the exact hidden context value, service question, option labels, requiredness, conditional evaluation explanation, EN/ES translations, validation messages and confirmation language in Jotform. Do not invent fields or accept query-controlled context values.
3. Confirm that no child/clinical/payment/location/booking fields, webhooks, integrations, answer-bearing notifications, PDF attachments, analytics or forwarding are introduced for the consultation context.
4. Obtain intake/operations, clinical and privacy approval for the field set, the evaluation explanation and the approved service options. Obtain fluent English/Spanish review for all added presentation and error text.
5. Run separately authorized synthetic Jotform and Astro-iframe acceptance tests with no real patient data. Cover both locales, all service choices, validation/error states, no-JavaScript and keyboard behavior, confirmation, notifications, responsive sizes and direct hosted fallback.
6. Only then authorize a new fixed Astro allowlist and production-gate update. The current seven Form A routes remain the only permitted real iframes until that implementation is independently reviewed.
7. For Form C, separately authorize creation from a blank form, then verify its minimum fields, PHI protections, recipients, retention, hosted/iframe behavior and protected-workflow handoff before mapping /referrals.

Retained gates

This decision does not close P9-01, P9-03, P9-05, P9-06, P9-07, P9-09 or P9-10. Form A's existing owner-reported direct and sampled embedded acceptance does not prove the new consultation context. Final real screen-reader, all-route responsive, runtime telemetry/privacy, hosting, notification-recipient and release-owner acceptance remain open.