docs(forms): record P9-03 Jotform integration contract and inventory

2026-10-18 13:30:46 -07:00
1 parent 59911eb929
commit 537f9864a0
@@ -0,0 +1,369 @@
 # Phase 9 — P9-03 form entry-point inventory and Jotform integration plan
 Execution date: **2026-10-17 UTC** (the execution clock had crossed UTC midnight after the October 16 kickoff). Planning and source inventory only. No implementation, form creation, account configuration, submissions, tracking, hosting changes or deployment authorized or performed.
 **P9-03 INVENTORY COMPLETE — READY FOR OWNER MAPPING**
 This means the repository inventory is complete against the selected signed source and its matching generated output. It does not mean the 27 account forms have been inspected or that their mappings, notifications, fields, accessibility or release are approved.
 ## 1. Baseline, method and evidence boundaries
 - Branch: `faithful-astro-migration`.
 - HEAD: `59911eb929579af7bcd6c42de6476128dab62289`; signed Phase 8 checkpoint, parent `8e64d322092b1fa6e0f648ddf26a665c80588198`, message `fix(a11y): reconcile responsive layouts and multilingual UI`.
 - Initial tracked tree and index clean. Six pre-existing untracked paths: the five protected exclusions and `.phase8-stage-paths.nul`. None was read, modified, removed or checksummed.
 - Read AGENTS.md, MIGRATION_BRIEF.md, AUTONOMOUS-CODEX.md, SESSION_HANDOFF, relevant migration-summary sections, Phase 9 register, nonproduction plan and Phase 8 browser/consolidated records. Their historical findings and decision statuses are unchanged.
 - Searched `www/src` for native forms, actions, named/required controls, submit handlers, fetch calls, Jotform/CentralReach destinations, CTAs, contact helpers, navigation and campaign references. Inspected actual components, content and routing utilities.
 - Recreated the manifest using the existing `createPublicationManifest`, `createLibraryCatalog`, `createLibraryPaginationPublications`, `createAuthorArchivePublications` and search-publication utilities with current frontmatter. Matched **122 eligible routes** to existing generated HTML. This reused the publication policy rather than introducing a second eligibility rule.
 - Explicit read-only verification passed: `node tools/audit-routes.mjs --check --evidence reports/route-reconciliation-2026-10-15-offline-18-21-22-820Z.json`, from `www`. No network or writes. Source fingerprint: `8453ffad597e2f2414343b634997bf204cbdd59fc00c3d8d122babef8a632cb5`; 133 dispositions, 122 generated routes, nine redirects. Its historical production sitemap count is not the indexing-enabled Astro sitemap count.
 - No build, browser submission, account login, API token retrieval, live form opening, Sign invitation opening or production crawl was performed. Public vendor documentation alone was retrieved. No patient records, notifications or answers were accessed.
 - Application counts remain the signed baseline: 122 routes/canonicals, 108 indexing sitemap URLs, 180 hreflang links/55 routes, 25 translation sets, 74 Library records, search 55/12/7, nine archives/nine redirects. No new claim of browser or human acceptance is made.
 Companion artifacts:
 - [Complete route-level inventory CSV](phase-9-form-entry-points-2026-10-17.csv): 2,140 rows: 20 native-form instances and 2,120 grouped navigation/contact records representing 2,705 rendered link occurrences. Header/mobile copies with identical route, region, target and label are grouped using `occurrences`. These are not 2,120 independent lead forms. Search and adjacent non-lead workflows are explicitly classified.
 - [Owner account worksheet](phase-9-jotform-owner-worksheet-2026-10-17.csv): 27 empty metadata rows; row numbers are worksheet positions, not invented form IDs.
 CSV scope includes links to enquiry/service/intake/Tour/insurance/referral routes, external intake, financing/payment/donation/recruitment/event/program destinations and script-generated public phone/email links. Ordinary research citations, unrelated article links and social-profile navigation are not counted as lead forms. Component/source columns identify the content or shared rendering owner; generated archives are identified by their publication utility. The tables below add precise references for the primary implementations.
 ## 2. Organizational decisions supplied by the user
 These facts are **user-confirmed, not independently account-inspected**:
 | Item | Confirmed direction | Still unresolved |
 |---|---|---|
 | Account | Existing Jotform Gold; HIPAA functionality enabled; BAA signed; 27/100 form slots used | Actual definitions, per-form protections, integrations, settings and other usage limits |
 | Lead processing | All lead-generating forms use Jotform directly | Exact existing-form IDs, schemas and operational routing |
 | Contabo boundary | No sensitive submission proxy and no PHI-bearing webhook | Enforcement and testing of the future integration/configuration |
 | Presentation | Iframe preferred; hosted fallback acceptable | Actual embed, language, accessibility and privacy acceptance |
 | Notifications | Generic new-lead email; date/time/source only where supported and approved | Actual HIPAA template capabilities, timezone, source safety and recipient controls |
 | Advertising | GA4/Ads remain disabled; future event must represent accepted submission | P9-05/P9-07 approval and reliable success signaling |
 | Hosting preference | Contabo for static Astro and approved non-PHI APIs; Raspberry Pi fallback | Topology, TLS, operator, failover and deployment verification under P9-09 |
 These decisions narrow the earlier provider-selection question; they do not approve implementation or close P9-03. Existing decision-register statuses and the living handoff are deliberately not edited.
 ## 3. Count definitions and visitor journeys
 | Population | Count and interpretation |
 |---|---|
 | Lead-form implementations | **3**: FormShell, ContactForm, ServiceInquiryDrawer |
 | Published native enquiry instances | **9**: seven EN, two ES, zero AR |
 | Other HTML form implementations | **2**: LibrarySearch and FaqPage search |
 | Other published HTML form instances | **11 GET search forms**; not lead collection |
 | All HTML forms | 5 implementations, 20 rendered instances |
 | Primary health/service lead intents | **6**: general contact, general consultation, ABA, evaluation, Social Club, professional referral |
 | Additional organizational enquiry intents | **3**: Tour request, fundraising contact, historical community-event/booth enquiry |
 | Total identified AIA enquiry intents | **9**, counting the historical event intent separately; current event availability unverified |
 | Clinical intake tracks | **3**, separate from initial leads: ABA, psychological, Social Club |
 | Existing Jotform destinations | **6 unique URLs across 7 link occurrences**: five form URLs and one Sign invitation |
 | CentralReach | **1 unique URL across 3 link occurrences** |
 | Proposed lead-form architecture | **3 logical forms**, preferably three physical forms using approved multilingual support; five physical forms if separate EN/ES copies are necessary |
 Commercial insurance, AHCCCS and private pay are current payment-interest branches, not independently implemented forms. They do not justify separate forms without different approved operational requirements. Recruitment, bill payment, financing and donation transactions are additional conversion boundaries, not health-service lead forms. Historical event registration is separately flagged, not declared active.
 ## 4. Primary route/component/field matrix
 Proposed categories are **JF-G** general enquiries, **JF-S** service consultation and **JF-R** professional referral. These are planning labels, not account form names or IDs. Every mapping requires owner inspection; iframe preferred with a hosted fallback.
 | ID | Published route / locale | Implementation and source | Purpose | Current fields / required | Mapping |
 |---|---|---|---|---|---|
 | F-001 | `/contact` EN | `src/components/ContactForm.astro:17–28`; `components/pages/ContactPage.astro:19`; `content/pages/en/contact.mdx` | General contact | G; none required | JF-G |
 | F-002 | `/es/contact` ES | Same component with explicit ES locale; `content/pages/es/contact.mdx` | General contact | G localized; none required | JF-G ES |
 | F-003 | `/client-consultation` EN | `src/components/FormShell.astro:12–21`; `layouts/PageLayout.astro:15,82` | Consultation | G; none required | JF-S |
 | F-004 | `/es/client-consultation` ES | Same layout/component, explicit ES locale | Consultation | G localized; none required | JF-S ES |
 | F-005 | `/schedule-consultation` EN | Same FormShell; `content/pages/en/schedule-consultation.mdx` | Alternate consultation entry | G; none required | JF-S |
 | F-006 | `/referrals` EN | Same FormShell; `content/pages/en/referrals.mdx:29` links to `#form-title` | Professional referral | G; none required; no professional-specific fields yet | JF-R |
 | F-007 | `/aba-therapy` EN | `src/components/ServiceInquiryDrawer.astro:71–168`; `layouts/PageLayout.astro:81` | ABA enquiry | D; first_name, last_name, phone, email required | JF-S / ABA |
 | F-008 | `/autism-evaluations` EN | Same drawer, service-specific copy | Evaluation enquiry | D; same four required | JF-S / evaluation, subject to availability approval |
 | F-009 | `/learner-social-club` EN | Same drawer, service-specific copy | Social Club enquiry | D; same four required | JF-S / Social Club |
 Paths above are relative to `www`. All nine have `method="post" action=""` and disabled submit controls. No destination or API is configured for their submissions. All have a phone fallback. The CSV contains actual field types, options and required flags, not an inferred schema.
 **G schema** (`FormShell:15–19`, `ContactForm:22–26`): `name` text; `email` email; `phone` tel; `service` select; `message` textarea. Service options: ABA Therapy, Autism Evaluation, Learner Social Club, Other, with localized ES labels. Options omit explicit values, so their labels become submitted values; a future integration must not rely on translated labels as stable routing codes. The first service option is ABA by default, rather than an explicit blank choice. All five are optional in the present HTML; a nonempty email receives browser type validation on ordinary submission.
 **D schema** (`ServiceInquiryDrawer:77–161`): `first_name` text, `last_name` text, `phone` tel and `email` email required; optional `child_first_name` text, `child_last_name` text, `child_birth_date` text with numeric input hint (not a validated date input), `location_interest` select, `service_interest` select, `payment_options` select, `referred_by` select and `comment` textarea.
 - Location: Scottsdale, Glendale, Other/None, initially blank.
 - Service: behavioral/ABA, psychological/evaluation, sociological/Social Club, Other/None, initially blank even in a service-specific drawer.
 - Payment: United Healthcare AHCCCS, BCBS AZ, United Healthcare, Optum, Tricare, Care Credit, Private Pay, Other; initially blank. These labels do not independently establish accepted/in-network coverage.
 - Referral source: Facebook, Google, Primary Doctor, Specialist, Client Referral, Community Event, Other; initially blank. It is self-reported information, not verified campaign attribution.
 There is no Arabic enquiry form implementation. Arabic articles/archives offer navigation to existing English destinations; `/ar` remains unpublished. Spanish service pages link to `/es/client-consultation` but do not instantiate the English-only drawer. No new localized route is proposed.
 ## 5. CTA, intake and external-flow mapping
 The CSV is the exhaustive route/target/region mapping. This compact table groups repeated implementations without counting a navigation link as another form.
 | Entry group / source | Current path or behavior | Proposed mapping / open issue |
 |---|---|---|
 | EN/ES home hero, commitments and financial help; `content/pages/{en,es}/index.md:15–17,41–43,120–123`; HomeHero/HomeServicesIntro/HomeFinancialHelp | Three consultation links per homepage | JF-S in the existing locale; claims about appointments/assessment are not confirmed booking |
 | HomeProcess and intake-process content | Six section links per homepage; intake page CTA leads to locale consultation | JF-S first enquiry; later clinical steps remain distinct |
 | Services/program pages EN/ES | Consultation CTAs; EN additionally has three drawer instances | JF-S with approved service context; no separate payment form by default |
 | Tour/header Tour button/contact Schedule Tour | `/tour` then `/client-consultation`; no scheduling calendar or Tour form | JF-G tour request proposed; preserve existing visitor journey until explicitly approved |
 | Referrals CTA | `#form-title` on `/referrals` | JF-R; current generic field labels are not a professional referral contract |
 | Library body links, all locales | Existing contact/consultation/service links and phone/email alternatives | JF-S/JF-G destination; source page ID may be recorded only through approved mapping, never full article URL in email |
 | Hours-of-ABA article | Local `/client-consultation`; observed public `/lp/early-intervention` | JF-S candidate, but P9-01 owns exact campaign destination; no equivalence assumed |
 | Header/MainNav/Footer and visitor-navigation resolver | Contact, services, referrals, client forms, insurance, Tour; locale fallbacks | Preserve valid targets and language notices; shared links are not separate implementations |
 | `/client-forms`, `ClientFormSteps.astro` | Three intake tracks; seven Jotform links, three CentralReach links, two psychological handbook PDFs | Preserve pending operational mapping; no initial-lead reuse approved |
 | `/donate-autism-giveback` | Fundraiser enquiry by public general email; Amazon wishlist/Giving Fountain donation links | JF-G fundraising request if approved; do not replace payment/donation providers |
 | Community Day article | Historical Eventbrite registration and staff event-contact email | JF-G event/booth enquiry candidate; registration replacement/status requires event owner, not an automatic migration |
 | `/careers`, `/team` | Indeed jobs links and public HR email | Separate recruitment workflow; do not assume current all-lead direction authorizes HR replacement |
 | Shared header | CareCredit provider search and PatientNotebook payment | Financing/billing transactions, not lead forms; preserve separate review boundary |
 | ABA pages EN/ES | `https://aiaprep.org/` curriculum reference | Separate Academy project; linked page is not evidence of an inspected lead form |
 | `/employee-portal` | Metadata-only route, no native form/authentication | P9-02 protected-workflow decision; no lead mapping |
 | Search (S-001–S-011 CSV) | LibrarySearch on ten routes plus FAQ search | Leave GET search separate; user-entered query text can still be sensitive |
 Privacy-policy telephone/email links are included as rights/contact boundaries, not automatically mapped to a lead form. Shared social-profile links are outbound navigation, not inspected lead submissions. Educational screener references (e.g. M-CHAT) are informational links, not AIA intake. No downstream external page was opened to infer additional fields or active availability.
 ### Existing Jotform and CentralReach destinations
 All discovered in `www/src/content/pages/en/client-forms.mdx`. The exact public URLs are in source/CSV except the Sign invitation token, deliberately not duplicated. None was requested.
 | ID | Source line(s) / occurrences | Destination | Evidence status / reuse |
 |---|---|---|---|
 | X-01 | 40 / 1 | `https://form.jotform.com/Arizona_Institute/aba-intake-agreement-form` | Repository-linked ABA agreement; inspect schema, ownership and live workflow |
 | X-02 | 45,108 / 2 | `https://form.jotform.com/Arizona_Institute/aba-learner-pre-assessment-form` | Shared ABA/LSC pre-assessment URL; confirm reuse is intentional |
 | X-03 | 50 / 1 | Jotform Sign document `232958430113048`; invitation segment retained only in original source | Handbook signature, not an assumed reusable lead form; owner must determine invitation scope/expiry |
 | X-04 | 71 / 1 | `https://form.jotform.com/Arizona_Institute/psy-intake-agreement-form` | Psychological agreement; metadata inspection required |
 | X-05 | 76 / 1 | `https://form.jotform.com/Arizona_Institute/aia-psychological-pre-assessment-fo` | Psychological pre-assessment; metadata inspection required |
 | X-06 | 103 / 1 | `https://form.jotform.com/Arizona_Institute/aia-learner-social-club-intake-agre` | LSC agreement; metadata inspection required |
 | X-07 | 35,66,98 / 3 | `https://members.centralreach.com/?public=true#forms/form?id=DF3D21C5-3A33-4906-9803-3E4580D32277` | Same client-intake target in all three programs; identify whether this is initial lead collection or post-contact intake |
 | X-08/09 | 82–83 | Two local psychological handbook PDFs (ages 2–5 and 6+) | Download/print/sign, no Astro submission; approval of later return channel required |
 Six destination URLs do not prove six of the account's 27 form slots: Sign inventory and vanity URLs must be reconciled by the owner. **Zero existing forms are confirmed suitable as initial-lead forms.** Five conventional form URLs and one Sign destination are inspection candidates, primarily for preserving clinical intake. The other account definitions remain unknown. No new numeric form ID is invented.
 ### Contact/legacy discrepancies requiring owner mapping
 `ContactObfuscation.astro:30–59` constructs phone/mailto links in the browser; without JavaScript its original fallback strings remain. Public contact targets discovered include general `(480) 687-7099`, billing `(602) 708-0429`, an older `(480) 707-2195`, general `info@azinstitute4autism.com`, `info@abaclinicaz.com` on schedule-consultation, `hello@azinstitute4autism.com`, and the apparent spelling variant `hello@azinsitute4autism.com` in three Library records. HR and the historical event staff email are separate contacts. The CSV identifies their routes.
 The apparent spelling error is source-observed, not live mailbox verification. `managing-aggressive-behavior-outbursts.mdx:40` also displays a literal `www.azinstitute4autism.com/contactus` rather than a working link. Other Library consultation wording links to the homepage first. These are owner-confirmation/possible later correction items; nothing was silently normalized. Contact alternatives must not invite emailing clinical details merely because a form is unavailable.
 ## 6. Submission and isolation findings
 | Finding | Evidence classification | Consequence / later safeguard |
 |---|---|---|
 | All nine enquiry forms have empty POST actions and disabled submits | Confirmed source and matching generated HTML | An empty action resolves to the current document; it is not an approved receiver or isolation mechanism |
 | Helper `src/scripts/forms.ts:1–3` prevents submit events but has no discovered invocation | Confirmed source | Do not claim a wired guard; merely wiring it would still not cover native scripted submission |
 | Native `form.submit()` attempted an intercepted POST from a synthetic Spanish fixture | Previously browser-verified, `phase-8-browser-verification-2026-10-15.md:81–85` | The guard prevented transmission; real forms were not submitted. No new mutation test performed |
 | Ordinary Enter-key submission on every current form/browser | Requires later controlled testing | Disabled default submit usually inhibits implicit submission; do not generalize this to all controls, browsers or scripting paths |
 | Native scripted submission bypasses submit events and constraint checks | Platform behavior; [MDN](https://developer.mozilla.org/en-US/docs/Web/API/HTMLFormElement/submit) | Later tests need intercepted native-submit and requestSubmit paths; no live endpoint probes |
 | Drawers open after 10 seconds and store dismissal in sessionStorage | Confirmed source, drawer script:173–246 | Closed native dialogs remain unavailable without JS; this storage is not attribution consent or campaign tracking |
 | Raw form data could be sent to Astro origin through scripted POST | Confirmed potential; observed only in synthetic fixture | Host behavior/logging unverified; future integration removes obsolete native submission path and denies unintended requests |
 | Free-text and child identifiers exist | Confirmed source | Assume sensitive input is possible even when labels are general; minimize initial fields with owner approval |
 | Public tel/mailto and external intake links are usable navigation | Confirmed source; external reception unverified | They are not disabled by local form controls; review recipients, legacy targets and clinical-data notices |
 | Search uses GET | Confirmed source | Sensitive typed queries may enter URLs/history/access logs. Not a Jotform workflow or a reason to add remote search |
 | Production counter fallback and automatic map resources exist | Confirmed source / prior controlled browser evidence | Jotform selection does not resolve P9-04 or external-resource isolation; noindex is not a network boundary |
 Future form integration must keep all entered values inside the cross-origin Jotform document, avoid parent-page field mirrors and URL prefills of contact/health information, and retain a clear hosted-form/telephone fallback. Replacing visual markup does not establish complete privacy compliance. A parent submit guard alone is insufficient, and the Jotform frame's own scripts/network require separate review.
 ## 7. Proposed form architecture and minimum fields
 | Option | Benefit | Cost / risk |
 |---|---|---|
 | A: one shared form | Least schema maintenance | Confuses administrative/professional/service paths; conditional logic can become hard to review |
 | B: dedicated forms for every service/payment/locale | Tailored wording and routing | Duplicated fields, translation drift, notification sprawl; nine categories alone do not justify nine forms |
 | **C: hybrid — recommended** | Three distinct schemas with service/payment branches where appropriate | Requires approved mapping, conditional rules and language testing |
 | Proposed category | Routes/intent | Minimum proposed fields | Owner-dependent additions |
 |---|---|---|---|
 | **JF-G General enquiry** | Contact EN/ES; Tour, fundraiser and event enquiries where approved | Adult contact name; preferred contact method; one corresponding contact channel; broad enquiry reason | Organization/role for fundraiser/event only if needed; optional message only with justification and protected handling |
 | **JF-S Service consultation** | Consultation variants; ABA/evaluation/LSC; campaign entry when approved | Adult contact name; preferred contact method; corresponding phone/email; service selection | Broad service area and payment category if routing needs them; preferred language; no booking guarantee |
 | **JF-R Professional referral initiation** | `/referrals` | Referring professional name, organization/role, work contact method/channel, requested service | Authorization/consent statement approved by privacy; patient identification and clinical documents belong in a separately approved secure referral/intake stage |
 Propose JF-G and JF-S with reviewed EN/ES versions, JF-R EN matching current publication. Three physical multilingual-capable forms would use at most three additional slots if nothing can be reused (27→30). Separate EN/ES copies for G/S plus EN R would use five (27→32). These are capacity illustrations, not account creation instructions; storage/submission quotas and Sign limits remain unverified. Do not create duplicates or alter active workflows before inspection.
 Initial prototype recommendation: **JF-G on a local-only copy of `/contact`**, followed by the ES version. It exercises the shared integration without child fields, a service drawer or a professional clinical handoff. Use an owner-approved test form, isolated recipient roles and synthetic data only after explicit testing authorization.
 ### Field disposition proposal — no existing field removed
 | Existing/proposed data | Classification | Reason / proposed treatment |
 |---|---|---|
 | Adult contact name and one reachable channel | Required and supported by contact purpose, subject to exact owner approval | Do not require both phone and email by default; current drawers require both, so changing that needs approval |
 | First/last name split versus one name | Potentially necessary — owner confirmation | Avoid duplicating both schemas without operational need |
 | Preferred method/language | Potentially necessary — owner confirmation | Supports respectful follow-up; translated labels and options need review |
 | Service and broad location | Potentially necessary — owner confirmation; privacy review | Useful routing but can disclose health-service interest; never email raw values by default |
 | Commercial/AHCCCS/private-pay/unsure category | Potentially necessary — owner confirmation; privacy review | Do not collect policy/member IDs or guarantee benefits; separate forms only for materially different approved requirements |
 | Child name and exact DOB | Better deferred to clinical intake | For eligibility triage, consider an approved age band only if necessary; not an automatic replacement |
 | Diagnosis, history, treatment detail, attachments | Better deferred to clinical intake | No new initial-lead collection; secure later Jotform workflow requires clinical/privacy approval |
 | `message` / `comment` | Privacy review required | Free text is potentially sensitive regardless of prompt; consider omission or constrained reasons, only with owner approval |
 | `referred_by` plus campaign fields | Potentially duplicative | Distinguish self-report from acquisition context; retain only needed, separately approved concepts |
 | Arbitrary UTM/query/referrer/IP/browser details | Unnecessary for minimum lead purpose; privacy review | No default copying into fields, notifications or event payloads |
 | Agreements, signatures, handbook acknowledgement | Separate clinical/operational intake | Existing linked workflows remain intact; not automatically merged into JF-S |
 The CentralReach boundary needs an explicit answer: if its current step is itself initial lead collection, it must be remapped to satisfy the user-selected Jotform direction; if it is clinical onboarding, its continued role needs separate operational/privacy approval. This report authorizes neither replacement nor new forwarding.
 ## 8. EN/ES and fallback presentation contract
 Jotform documents multilingual forms and translation of confirmation/thank-you content [V4]. Prefer reviewed multilingual G/S forms if the actual HIPAA form supports deterministic initial locale and accessible validation. Separate EN/ES copies are the fallback if this cannot be verified. No automatic translations are accepted as fluent review.
 - Pass an explicit page locale to a future component; map only approved form IDs/URLs and language values. Verify the vendor's actual locale parameter before using it; no guessed URL syntax.
 - EN Contact→JF-G EN; ES Contact→JF-G ES; EN consultation variants→JF-S EN; ES consultation→JF-S ES; EN service drawers→JF-S EN branch. ES service CTA stays ES. Referrals remain EN unless a separately approved translation is supplied.
 - Arabic article visitors currently follow English contact/consultation links, including the Arabic first/then article. Retain clear English-destination notices; do not invent an Arabic form or route.
 - Review heading/button/error/help/CAPTCHA/thank-you language, not only labels. Use localized descriptive iframe titles. Ensure language changes do not discard entries without warning.
 - Test 320/390/768/1440 widths, 200% zoom, keyboard entry/exit, validation focus, screen-reader announcements, long Spanish strings, conditional height changes and mobile keyboard behavior. Parent CSS cannot fix iframe-internal accessibility.
 - Start with a plain iframe plus visible hosted fallback. Jotform's documented iframe publishing option [V3] does not prove its exported helper script is necessary or acceptable. Inspect resize helpers and message handlers before adding them; validate message origin, source window and payload.
 - A frame `load` event is neither submission success nor proof that the form is usable. Account for blocked resources, empty/failed frames and network loss. Hosted fallback must remain available without parent JavaScript; actual Jotform no-JS functionality remains unverified.
 - Preserve service-drawer focus/close behavior if later embedding there. Cross-origin Escape behavior, nested scrolling and tab boundaries need actual testing; use the full-page/hosted fallback if a drawer fails accessibility.
 ## 9. Owner inventory checklist for the 27 existing forms
 Complete the companion worksheet using **metadata or sanitized configuration only**. No credentials, API tokens, submission exports, real answers, notification messages, private invitation links or clinical records.
 For each form provide title, public ID/URL, active/disabled/archive status, purpose, owner role, operational use, field names/labels/types/required flags and protected flags (including hidden fields), language/error-message coverage, conditional logic, notification template structure/tags, recipient roles, subject/reply-to configuration, attachments, timezone, thank-you/redirect settings, integrations/webhooks/widgets/tracking, sensitive-field categories and embedding support/testing. Record whether an approved test copy may be created later and which workflow must not be disrupted.
 Public Sign invitations are not automatically safe metadata exports; supply a document ID and explain invitation scope without private access tokens. No patient data is needed to establish whether a field exists.
 Review account metadata for remaining submission/storage limits, retention/deletion policy, staff access roles/MFA, monitoring responsibility and available test isolation. User-confirmed Gold/HIPAA/BAA facts need not be re-proved through patient submissions. Account owner then maps each candidate to JF-G/S/R or retained clinical intake; zero matches are assumed now.
 ## 10. Proposed attribution contract
 This is a proposed allowlist, not implemented code or approved notification content.
 | Proposed internal value | Meaning | Notification display candidate |
 |---|---|---|
 | `E-CONTACT-EN`, `E-CONTACT-ES` | Known contact entry | Website |
 | `E-CONSULT-EN`, `E-CONSULT-ES`, `E-SCHEDULE-EN` | Consultation destination | Website |
 | `E-SERVICE-ABA`, `E-SERVICE-EVAL`, `E-SERVICE-LSC` | Approved service entry | Website (no service label) |
 | `E-REFERRAL-EN` | Professional route | Website (no patient/referrer details) |
 | `E-TOUR`, `E-GENERAL` | Tour/general organizational request | Website |
 | `C001` | Reserved first approved paid-search campaign; not yet assigned | Search campaign, only after privacy approval |
 | `C002` | Reserved approved partner campaign; not yet assigned | Partner campaign, only after privacy approval |
 | `UNSPECIFIED` | No trustworthy allowed source | Website / source unavailable |
 Entry context and service/payment intent can be sensitive even when represented by a code. Keep the detailed internal entry/service fields protected; proposed notification labels deliberately collapse them. Opaque codes are not automatically anonymous or safe.
 Recommended first release uses fixed entry context only, with no persistence. A CTA click may carry an approved fixed entry code to the form destination later; absent such an approved mechanism, only the destination route is known. Do not pretend a visit to consultation establishes that it originated on a particular article or homepage.
 If campaign mapping is later approved: accept one recognized code from a versioned allowlist or an exact approved UTM tuple, never arbitrary UTM text. Reject repeated/conflicting/malformed/oversized values to `UNSPECIFIED`; do not concatenate them. Discard `utm_term`, click IDs, full referrers and arbitrary URLs by default. Known page context remains independent from campaign classification. Client-supplied attribution is spoofable and must never control authorization or privileged data routing.
 - No campaign parameters: **unspecified**, not confidently “direct.” Organic search and referral traffic cannot be inferred reliably without additional approved evidence. Do not inspect or transmit a full referrer merely to fill the label.
 - Paid search: only a deliberately assigned allowlisted campaign value; no GA4/Ads activation, click-ID capture or conversion implied.
 - Invalid/competing values: generic source; never echo raw input to a template, URL or log.
 - Hidden fields remain editable by clients. For email inclusion, require vendor-side constrained values and a fixed validated label mapping. If Jotform cannot enforce that safely, use static generic email wording rather than raw hidden-field interpolation.
 - No cookies/sessionStorage for attribution proposed initially. Existing drawer-dismissal storage is unrelated. Any later persistence requires a purpose, duration, consent/privacy review and deletion behavior.
 - Review iframe/hosted-link referrer policy and the actual exported embed helper for automatic parent query forwarding. Prefer no-referrer at this boundary, subject to compatibility tests; it does not suppress all vendor-side browser metadata. Never prefill names, health information or free text through URLs.
 ## 11. Notification capability and approval matrix
 Vendor documentation was reviewed on October 17 using public official help pages, without opening any AIA form. Documentation capability is not proof of AIA's current settings.
 | Requirement | Public evidence / limitation | Proposed acceptance |
 |---|---|---|
 | HIPAA notification body | Jotform supports notifications with PHI-marked fields excluded [V1]. Its field guide says fields are protected by default on HIPAA enablement and warns about turning protection off [V2]. Existing settings still need inspection. | Keep contact/child/health/free-text fields protected; explicitly minimalist template plus full synthetic delivered-email review |
 | Submission date/time | Generic email guide documents `{DATE}`, `{DATE:Date-US}`, `{DATE:Time-US}` and formatting tags [V5]. | Confirm supported metadata in this HIPAA form and actual received message, not only preview |
 | Arizona time | Account timezone and table display are configurable [V6]. That guide alone does not prove the timezone used by every notification tag. | Owner verifies America/Phoenix/Arizona-equivalent setting and actual submission timestamps across midnight and DST-season dates; do not use visitor-supplied date or a DST-observing Mountain timezone |
 | Campaign/source label | No verified account-specific safe notification contract | Approved coarse label only after protected-field and tampering tests; do not disable PHI protection merely to make a field appear |
 | Recipients | Notification setup supports recipient configuration [V9]; account roles unknown | Approved staff recipient roles, no visitor-controlled recipient/reply-to, no unreviewed forwarding; addresses supplied privately during authorized setup |
 | Subject/sender | Current template uninspected | Fixed generic subject/sender; no person, service, campaign detail, answer, form-title interpolation or submission ID |
 | Hidden fields/defaults | Hidden does not mean protected; templates may include answer placeholders | Inspect all-field tokens, hidden inputs, IP/browser widgets, reply-to, PDFs, filenames, footers, edit/view links and autoresponders |
 | Submission identifiers/links | Unnecessary for the proposed notification | No ID, tokenized edit link, public receipt, attachment or answer-bearing URL; generic authenticated account sign-in instruction |
 | Failures/monitoring | Official delivery guide describes troubleshooting [V10]; exact account monitoring capabilities unverified | Staff-owned reconciliation inside Jotform, controlled test failure/bounce handling and coverage when alerts stop; no PHI-bearing monitoring export |
 Proposed **generic fallback**, still subject to actual template and privacy approval:
 ```text
 Subject: New AIA website inquiry
 A new inquiry has been received.
 Sign in to AIA's authorized Jotform account to review the submission.
 ```
 Only after support and privacy are verified, add:
 ```text
 Date: [verified Arizona-local submission date]
 Time: [verified Arizona-local submission time]
 Source: [approved coarse source label]
 ```
 A precise timestamp plus a campaign category may enable correlation with an individual; neither is automatically non-PHI. If that combination is unsafe or unsupported, omit it. A submission timestamp, email-send time and email-client display time are different concepts and must not be conflated.
 AIA's restriction is stricter than optional vendor PDF features: **no submission attachments, even encrypted PDFs**, no answer dumps and no PHI-bearing webhook to Contabo. No separate email-building service should receive the full submission merely to produce a generic notification. Respondent autoresponders need separate approval; do not infer them from staff notification approval. The fallback is generic Jotform-originated notification, or owner review of notification feasibility—not disabling safeguards.
 ## 12. Successful submission and future conversion signaling
 The existing [Ads handoff](google-ads-consultation-conversion.md) remains authoritative: conversion means an accepted inquiry, not a CTA click, iframe load, form open, validation attempt or failure. GA4/Ads stay disabled.
 | Approach | Feasibility/evidence | Limitation and disposition |
 |---|---|---|
 | Jotform internal thank-you/confirmation | Documented [V7]; can keep visitor inside vendor workflow | Recommended initial UX, no advertising event. Do not echo answers or expose edit/download actions by default |
 | Static external thank-you redirect | Documented [V8] | A direct visit/refresh/forged URL is not authenticated acceptance. Avoid query identifiers and data forwarding; not sufficient alone for conversion |
 | Embedded completion message/event | Requires current vendor-supported contract and actual HIPAA test-form evidence | No stable supported acceptance-event API verified in this assessment. Do not infer success from resize/navigation or invent a postMessage payload |
 | Server verification/webhook | Would require new data flow/authorization | PHI-bearing webhooks and submission polling/proxying through Contabo contradict the chosen boundary; not proposed |
 | Vendor analytics integration | Technical availability is not approval | Remains P9-05/P9-07; do not turn it on as an embedding shortcut |
 If a supported message is approved later, validate exact origin, source window, schema and form identity; reject unexpected values without logging answer-bearing payloads. No visitor identifier/submission ID should reach ads, URLs or Astro logs. An origin-checked message is not automatically server-authenticated acceptance; document its actual guarantees and replay/duplicate behavior before approving measurement.
 Jotform documents unique-field duplicate controls [V11], but using contact identifiers to block repeat enquiries can exclude siblings or legitimate later requests. Owner must define duplicate rules separately from ad-event deduplication. Test double click, retry after timeout, Back/refresh, incomplete/cancelled forms, validation failures, blocked resources, offline state, quotas and closed forms on an authorized test form. Do not label failed or uncertain requests accepted; give truthful next steps without clinical information in error logs.
 **Critical setting:** Jotform offers redirect-with-HTTP-POST of submission data [V12]. It must remain OFF for any Astro/Contabo return URL. A harmless-looking thank-you redirect can otherwise defeat the direct-to-Jotform boundary. Also exclude field interpolation in redirect query strings and automatic data-bearing action buttons.
 ## 13. Hosting and privacy dependencies
 Proposed path: visitor loads static Astro from approved Contabo host → visitor opens/loads approved Jotform iframe or hosted form → submission goes directly to Jotform → authorized staff review inside Jotform; staff receive only approved generic notifications. Raspberry Pi is an unverified fallback preference, not configured failover.
 - P9-09 must approve exact HTTPS form/CDN origins and CSP `frame-src`; do not use a broad wildcard from guessed vendor domains. Inspect the owner-supplied embed for any required parent `script-src`/`connect-src` additions. The account may use different HIPAA endpoints; do not infer them from public vanity links.
 - Ordinary cross-origin iframe navigation does not require a Contabo CORS proxy. Parent code cannot read the child DOM; parent CSP does not govern every resource inside the cross-origin form. Test the frame's requests/cookies separately. Do not relax CORS to extract submitted answers.
 - Consider parent `form-action 'none'` once obsolete native enquiry forms are replaced, with careful scope so approved search is preserved; review server denial of unexpected POSTs. These are future policy choices, not current settings. A blanket directive would also affect GET forms.
 - Review Referrer-Policy on frame/fallback, HTTPS-only resources, iframe permissions and any sandbox restrictions against actual vendor behavior. Do not grant broad top navigation or disable protections simply to make a redirect work.
 - Embeds may initiate vendor/CDN/cookie requests before submission or user interaction. Decide automatic loading versus an accessible click-to-load placeholder with privacy owner. Lazy loading alone is not consent.
 - Contabo, Cloudflare and fallback-host access logs can contain client IP and inbound query strings even without submission bodies. Approve log minimization, retention and redaction; sanitizing browser attribution after navigation does not erase earlier server logs.
 - Hosted previews must not load production form IDs by default. Use an approved test form with controlled notifications/integrations, explicit endpoint allowlist and synthetic data; stop unexpected production API or advertising attempts. Existing likes/views isolation remains P9-04.
 - Do not put form answers in parent state, session storage, app telemetry, exception reports, URLs, referrers, conversion payloads or webhooks. Keep APIs non-PHI; namespaced “non-PHI” code labels alone do not establish that classification.
 - Rollback includes both the static artifact and approved Jotform configuration/version; rolling back Astro alone does not undo vendor edits. Preserve operational form ownership and avoid reactivating obsolete empty-action forms as a fallback. Agree a safe telephone/hosted workflow.
 - Phase 10 must test Contabo and any proposed Raspberry Pi fallback for TLS, CSP/referrer behavior, routes, real errors, asset delivery, logs, external outages and rollback. No DNS/TLS/nginx/Cloudflare changes are included here.
 ## 14. Bounded future implementation batches
 Every batch requires separate authorization; this plan authorizes none.
 | Batch | Prerequisites / owners | Proposed files or systems | Tests and stopping point |
 |---|---|---|---|
 | 1. Mapping and approval | Owner completes 27-form metadata worksheet; intake/privacy approve schemas, languages, source handling, recipient roles; P9-01 campaign boundary | Jotform metadata and proposed form contract/report only initially | Map F/X IDs to approved account forms, flag active workflows and unknowns; stop before creating/editing forms |
 | 2. Local-only prototype | Explicit test-form creation/use and synthetic submission authorization; privacy/security endpoint approval | Future reusable Astro embed wrapper, `/contact` prototype, guarded browser tests; approved test Jotform | EN/ES, responsive/zoom, keyboard/screen reader, frame/fallback, blocked vendor/error state, observed egress and no Contabo payload; stop before production form use |
 | 3. Remaining integrations | Prototype accepted; each form/locale/service availability approved | FormShell, ContactForm, ServiceInquiryDrawer, PageLayout, locale content and targeted tests as necessary | Nine route instances, no old empty-action path, no duplicate IDs/forms, page design, referral flow, JS-disabled alternatives, publication invariants; stop with reviewable nonproduction changes |
 | 4. Source and notifications | Allowlist and notification privacy approval; actual HIPAA capability verified | Approved Jotform templates/settings and narrowly scoped source mapping | Synthetic delivered email inspection for all fields/headers/links/attachments, Arizona clock, tampered/unknown codes, failure monitoring; stop before live recipient/workflow activation |
 | 5. Measurement | Separate P9-05/P9-07 approval and supported acceptance-signal contract | Only approved event adapter/vendor configuration | Local mocks first; success-only, consent, duplicate/replay/failure checks, no identifiers/health context; no automatic tag installation or production events |
 | 6. Production acceptance | P9-09 verified hosting/rollback; all release owners and pending human reviews | Phase 10 release checklist and separately authorized systems | Approved synthetic operational tests, outage/rollback and go/no-go; explicit activation authorization remains required |
 ## 15. Owner decisions still needed
 | Priority | Question / evidence | Responsible role |
 |---|---|---|
 | 1 | Map the 27 definitions; identify existing lead forms versus clinical intake/Sign and protect active workflows | Jotform account and intake owner |
 | 1 | Approve G/S/R minimum fields, required contact channel, payment routing and initial referral boundary | Intake/clinical and privacy owners |
 | 1 | Confirm evaluation availability, service locations, waitlist/admission wording and payer categories before forms promise service | AIA operations/clinical leadership |
 | 1 | Supply sanitized HIPAA notification configuration, PHI flags and account timezone; determine whether generic-only is necessary | Jotform owner/privacy reviewer |
 | 2 | Confirm CentralReach's role and repeated ABA/LSC pre-assessment use; identify Sign invitation safety | Intake owner/security reviewer |
 | 2 | Verify EN/ES definitions/error states and preferred-contact routing; Arabic remains explicit English fallback | Fluent reviewers/intake |
 | 2 | Approve coarse source labels, fixed mapping, persistence policy and whether timestamps are appropriate in email | Privacy/marketing owners |
 | 2 | Confirm public email/phone aliases and historical event status; correct only with approved evidence later | Organizational/content owner |
 | 2 | Approve campaign `/lp/early-intervention` journey and ownership | P9-01 campaign/site owner |
 | 2 | Approve test form, test recipients, expected vendor domains, log policy and rollback responsibilities | Account owner/security/P9-09 operator |
 | Deferred | Define supported accepted-submission event and measurement approval | P9-05 marketing/privacy; no tracking now |
 Do not ask for already-confirmed Gold/HIPAA/BAA/capacity facts again. Do not request submissions to resolve any of these questions. Form quotas alone do not establish throughput/storage/operational capacity.
 ## 16. Remaining gates and documentation validation
 P9-01 campaign ownership; P9-04 counters/isolation; P9-05 measurement; P9-06 clinical, financial and organizational claims; P9-07 policies, actual data practices and trusted Spanish policy source; P9-09 hosting; P9-10 launch remain open. P9-02 portal and P9-08 author policy are unchanged. The selected Jotform direction is recorded here without declaring P9-03 fully resolved or changing register statuses.
 Fluent EN/ES form wording, Arabic fallback clarity, clinical referral/intake review, HIPAA configuration/privacy/legal acceptance, real screen-reader and authorized desktop/mobile/non-Chromium review remain required. Account HIPAA enablement/BAA and successful technical tests do not supply these approvals. Phase 10 retains production integration acceptance, rollback and cutover authority.
 Validation for this documentation-only task: current source manifest and 122 generated routes inspected; nine POST and eleven GET form instances accounted for; all native enquiry schemas matched; sanitized CSV unique IDs and required columns checked; 27-row blank account worksheet checked; explicit offline consistency check passed; `git diff --check` and final index/status inspection performed. No implementation tests/build were rerun because application bytes were unchanged. Only this report and two CSVs are newly created. No historical report, living handoff or decision register is edited.
 ## Vendor references and limits
 Official documentation consulted on **2026-10-17 UTC**, not account inspection. No public help example or support response is treated as proof of AIA configuration, compliance or a guaranteed acceptance-event API. Summaries below support the bounded proposals above.
 - **V1:** [HIPAA notification/autoresponder behavior](https://www.jotform.com/help/504-how-to-use-notification-and-autoresponder-emails-in-hipaa-accounts/) — protected fields excluded from email; no blanket claim that every email is safe.
 - **V2:** [PHI field settings](https://www.jotform.com/help/518-how-to-set-phi-fields-on-your-forms/) — protection defaults and per-field review.
 - **V3:** [Iframe publishing](https://www.jotform.com/help/148-getting-the-form-iframe-code/) — supported publishing method, not AIA accessibility certification.
 - **V4:** [Multilingual forms](https://www.jotform.com/help/298-how-to-make-your-forms-multilingual/) — language capability; actual translations and locale selection still unverified.
 - **V5:** [Email submission-date tags](https://www.jotform.com/help/68-how-to-add-a-date-to-an-email-notification/) — generic date/time formatting capability.
 - **V6:** [Submission date format and account timezone](https://www.jotform.com/help/346-how-to-change-submission-date-to-a-different-format-and-timezone/) — table/account setting; does not independently establish delivered-email timezone.
 - **V7:** [Thank-you options](https://www.jotform.com/help/211-setting-up-the-thank-you-page/) — confirmation, optional actions and data presentation need explicit configuration review.
 - **V8:** [External redirect after submission](https://www.jotform.com/help/38-redirecting-users-to-a-different-page/) — user navigation capability, not an authenticated conversion receipt.
 - **V9:** [Notification configuration](https://www.jotform.com/help/25-setting-up-email-notifications/) — owner must inspect actual recipients and template settings.
 - **V10:** [Notification delivery troubleshooting](https://www.jotform.com/help/364-why-am-i-not-receiving-email-notifications/) — no inferred operational monitoring SLA.
 - **V11:** [Unique-field limits](https://www.jotform.com/help/223-how-to-set-form-limits-based-on-a-unique-field/) — duplicate controls require a workflow-specific policy.
 - **V12:** [Redirecting submission data with HTTP POST](https://www.jotform.com/help/213-send-submission-data-via-post-method-and-thank-you-settings/) — capability explicitly excluded from the proposed Contabo boundary.
@@ -0,0 +1,222 @@
 # P9-03 source-specific implementation plan
 Date: **2026-10-18** · Plan version **1.1** · Governing contract: [P9-03-JF-2026-10-18 v1.1](phase-9-jotform-integration-contract-2026-10-18.md).
 **Planning only. Do not execute any batch from this document without separate authorization.** Phase 9 establishes decisions and bounded implementation authority. Phase 10 retains final production integration acceptance, rollback and cutover. The user stages, signs and pushes.
 ## 1. Actual baseline and reconciliation
 Verified `faithful-astro-migration`, HEAD `59911eb929579af7bcd6c42de6476128dab62289`, clean tracked tree and empty index. Three October 17 untracked inventory artifacts exist, alongside the five exclusions and `.phase8-stage-paths.nul`. No unexpected implementation change was found. The prior 27-row owner worksheet remains blank; the current supplied connector summary is not silently written into it.
 Current source-manifest construction confirmed nine eligible enquiry routes and corresponding existing generated HTML forms. Source files still match Git. No build/browser/submission test was run for this documentation-only task. Counts below are verified route mapping plus the signed checkpoint's accepted publication baseline, not new full-suite results.
 | Inventory ID | Route | Source content under `www/src/content/pages` | Owning component under `www/src/components` | Target |
 |---|---|---|---|---|
 | F-001 | `/contact` | `en/contact.mdx` | `pages/ContactPage.astro` → `ContactForm.astro` | A EN |
 | F-002 | `/es/contact` | `es/contact.mdx` | Same | A ES |
 | F-003 | `/client-consultation` | `en/client-consultation.md` | `FormShell.astro` via PageLayout | B EN |
 | F-004 | `/es/client-consultation` | `es/client-consultation.md` | Same | B ES |
 | F-005 | `/schedule-consultation` | `en/schedule-consultation.mdx` | Same | B EN |
 | F-006 | `/referrals` | `en/referrals.mdx` | Same; preserve `#form-title` | C EN |
 | F-007 | `/aba-therapy` | `en/aba-therapy.mdx` | `ServiceInquiryDrawer.astro` | B EN / ABA |
 | F-008 | `/autism-evaluations` | `en/autism-evaluations.mdx` | Same | B EN, availability gate |
 | F-009 | `/learner-social-club` | `en/learner-social-club.mdx` | Same | B EN / Social Club |
 Nine instances = 7 EN + 2 ES, three implementations. Eleven GET search instances remain separate. No Arabic enquiry form or Spanish referral route is created. EN/ES-capable logical forms do not imply new published routes.
 ### Discrepancies and supersession notes
 1. October 17 proposed possible event/fundraising consolidation into general enquiries. October 18 explicitly preserves the Event Submission Form separately; fundraising still needs approval. Tour currently points to consultation/B; A is provisional and requires a deliberate approved CTA disposition.
 2. October 17 proposed one chosen contact channel. Current owner field proposal requires adult email for A/B, with B phone undecided. Operations must approve final requirements and contact-preference validation; do not implement the old alternative.
 3. The older report allowed date/time/source notification extensions after review. Initial contract now explicitly defers them; use only the exact generic template after notification approval.
 4. The older inventory knew no confirmed lead source. The supplied October 18 evidence now selects `250727122848156` as a **structural source for a future copy**, not a validated schema or active embed destination.
 5. Three multilingual forms are the new preference, including C capability. Earlier fallback five physical forms assumed C EN-only; a complete EN/ES physical fallback for all three would be six. No new Spanish route is implied or authorized.
 6. The follow-up owner-supplied roster now lists all 27 unique IDs in contract section 3. IDs/titles are reported connector metadata; classifications are supplied planning categories, not verified settings or usage. Preserve the historical 27/27 ENABLED report. The October 17 worksheet remains unchanged; field/configuration and usage approvals remain pending.
 7. Connector element totals are not field counts; the prompt's plain-form title contains a literal vertical bar. Record the title correctly rather than treating it as an extra table column.
 8. Current “Schedule”/“Make an Appointment” headings/CTAs are not functioning booking. No calendar should be inherited. Obtain approved explanatory copy; do not silently change metadata, clinical text or publication identity.
 9. Zero *new lead* production IDs/traffic in off/mock is compatible with preserving existing clinical links. A blanket assertion of no Jotform IDs anywhere would be false because `/client-forms` already links to them. Test scoped new integration isolation and preserve existing click-only workflows.
 ## 2. Source findings and future edit surface
 All paths below are relative to repository root. Proposed additions do not exist as part of this task.
 | Existing file | Current behavior | Eventual bounded treatment |
 |---|---|---|
 | `www/src/components/ContactForm.astro` | Lines 17–28: empty POST, disabled submit, five optional contact/service/message controls | Keep card/layout styling; delegate mode-dependent lead UI to reusable integration; remove inactive native submission surface in off mode |
 | `www/src/components/FormShell.astro` | Lines 12–21: same POST pattern; outer section and `form-title` | Preserve section/background and referral fragment; pass logical form/locale explicitly |
 | `www/src/components/ServiceInquiryDrawer.astro` | Empty POST, child fields, stale options/copy; ten-second modal; dismissal sessionStorage | Preserve verified native dialog unless approved otherwise; replace lead content only after copy/UX decisions; no timed vendor request |
 | `www/src/layouts/PageLayout.astro` | `showForm` routes at line 15; EN-only drawers at line 81; FormShell at 82 | Explicit route→A/B/C configuration; retain publication architecture and locale guards |
 | `www/src/components/pages/ContactPage.astro` | ContactForm with lang, address and Leaflet/map resources | Pass integration props if needed, preserve map provider/layout; map traffic separately blocked in controlled tests |
 | `www/src/utils/form-messages.ts` | EN/ES text only; other locales rejected | Add approved mode/fallback/accessibility copy only; do not invent Arabic messages or remote-form translations |
 | `www/src/scripts/forms.ts` | Unused submit-event prevention helper | Do not treat as adequate isolation; future removal/wiring only if justified by selected architecture |
 | `www/src/styles/forms.css` | Existing source-faithful form styling | Narrow iframe/fallback styling only where necessary; preserve visual tokens |
 | `www/.env.example`; proposed `www/src/env.d.ts` only if needed | Existing environment example; no current `src/env.d.ts` | Document optional mode default-off and type semantics if needed; no actual live IDs or credentials |
 | `www/src/content/pages/en/tour.mdx` | CTA to `/client-consultation` | No route edit until Tour A/B decision approved |
 | `www/src/content/pages/en/client-forms.mdx` | Clinical, Sign, CentralReach and PDF links | Preserve; not part of lead-form replacement |
 | `www/reports/google-ads-consultation-conversion.md` | Accepted-API-success premise | Do not edit in this batch; future separate P9-05 contract must reconcile direct Jotform semantics |
 **Proposed additions for authorized Batch C:**
 - `www/src/utils/form-integration.ts`: typed logical form (`A/B/C`), locale, mode and deployment-role validation; pure functions suitable for existing Node tests.
 - `www/src/data/form-integrations.ts`: explicit route mapping and build-time descriptors; no production descriptor until later approval; semantic service hints are not Jotform field keys.
 - `www/src/components/FormIntegration.astro`: mode orchestration, localized off fallback and local mock selection.
 - `www/src/components/JotformEmbed.astro`: reviewed iframe/fallback presentation, inactive until approved live descriptor; defer its live behavior to authorized test work if unnecessary for C.
 - `www/tools/form-integration.test.mjs`: focused configuration/output tests, not full-copy snapshots.
 - `www/tools/phase9-forms-browser.mjs`: guarded local runner using the established Playwright approach; test fixture served from the loopback harness or browser route interception, **not a new public production route**.
 Names are proposed and may be refined in an authorized batch. No dependency, database, backend, CMS, hosting configuration or Jotform SDK is needed to prototype off/mock. Do not add API tokens to PUBLIC variables or retrieve secrets. The iframe URL itself is not a substitute for an approved contract.
 ## 3. Typed configuration and fail-closed behavior
 Suggested mode name `PUBLIC_AIA_FORMS_MODE`; exact enum `off | mock | live`, default off. A second build/deployment-role gate must identify approved isolated-test versus approved production context. Its implementation/name needs hosting review; do not infer approval from `PUBLIC_ALLOW_INDEXING`, localhost detection or the presence of a URL.
 Logical descriptor semantics: logical form key; supported locale set; reviewed accessible title; approved hosted and frame URLs; approved origin; environment role; evidence/version reference. These are application semantics, not guessed Jotform uniqueName/field identifiers. Keep original source IDs in evidence only; never use them as default URLs. Fail an explicit invalid live build rather than rendering a broken or fallback original form.
 | Case | Required result |
 |---|---|
 | Missing, empty or unknown mode | Off/no active lead submission; report invalid config safely where appropriate |
 | Off with a stray live URL | Ignore/reject without emitting URL/ID, frame, helper, preload, cookie or vendor request |
 | Mock | Harness-served synthetic document only; no live configuration required or included; no external submission traffic |
 | Live without approved deployment role, logical mapping, locale, exact HTTPS origin/URL or evidence | Build rejection; never silently substitute another form/locale |
 | Live B configured with source `250727122848156` | Reject; a separately created approved working-copy ID is required |
 | Unsupported locale | No invented translation; localized approved route fallback where available, otherwise fail configuration safely |
 | Approved isolated-test live configuration | Explicit test-only mapping and recipient controls; no production fallback; separate D authorization |
 | Approved production live configuration | E/F authorization, correct reviewed artifact and mapping; no inference from indexing-enabled build |
 For off mode prefer non-form fallback markup without editable lead controls or an enclosing native form. Removing the form surface prevents the specific `form.submit()` bypass; disabling a button or catching `submit` alone does not. Test the actual resulting DOM, not just a handler string. Do not claim protection against arbitrary malicious script execution.
 Mock fixtures must be synthetic and inert to external requests, including Enter and native submission paths; Playwright aborts unapproved requests before transmission. Fixture URLs/assets must not appear in the production route manifest. Live descriptors must not leak into off/mock emitted bundles through shared imports—scan generated HTML, scripts and preload hints.
 Parent component preserves approved page design, explanatory text, iframe title, hosted fallback and responsive width/height. Cross-origin child labels/errors must be verified in Jotform; Astro locale and CSS do not localize/fix them. No guessed `?language=es`, hidden-field mapping, completion event or helper script. Loading/error UI must not claim it can inspect the child DOM. A frame load is not proof of availability or accepted submission.
 Drawer decision is a prerequisite for replacing its live content: retain timer only if approved and incapable of loading vendor resources without the approved trigger; otherwise use an explicitly approved open/load interaction or full-page fallback. Preserve Escape/initial focus/restoration and test cross-origin focus boundaries. No wholesale dialog replacement.
 ## 4. Builder review and copy procedure prerequisites
 Use [JF-01–09 and owner gates](phase-9-jotform-verification-checklist-2026-10-18.csv). All start Pending/Unverified. Verify source settings read-only in A; reverify actual working-copy settings in B. Successful source review is not approval of inherited copy settings. Runtime portions of JF-03/08 remain open until D.
 Before any copy, approve a safe account process that prevents unexpected public submissions, production recipients and automations. The [official clone guide](https://www.jotform.com/help/27-how-to-clone-an-existing-form-from-your-account/) notes that notification settings and several workflow settings can be copied. Do not assume integrations, payments or encryption/protection behave safely in this account. Record exact new ID only after authorized creation; preserve original completely; no copying/importing submissions. If safe immediate isolation cannot be established, stop before copying.
 Review all default/hidden fields, protected flags, conditional routing, reply-to, subjects, attachments, staff recipients, autoresponders, integrations, webhooks, exports, save/continue, limits, duplicates and access/retention. Inspect actual thank-you behavior and ensure answer echo and HTTP POST forwarding to Astro/Contabo are off. Generic notification setup itself requires authorized Jotform mutation; no “test email” to inherited recipients before review.
 ## 5. Independently authorizable batches
 ### Batch A — Builder settings verification and final field approval
 - **Objective:** close configuration knowledge gaps and secure owner decisions, not change forms.
 - **Authorization:** explicit read-only Builder/metadata review scope. No credentials or submissions requested; owner may provide sanitized screenshots/exports. Use the complete roster in contract section 3; verify uncertain generic titles and relevant configuration without retrieving answers or assuming operational usage.
 - **Owners/dependencies:** account owner, operations, clinical, privacy, EN/ES reviewers; JF-01–08 configuration portions, OA-01–05; P9-01 Tour/campaign boundaries where relevant.
 - **Outputs:** versioned source-ID field map, approved semantic schema/options/requirements, notification contract, eligibility/copy decision, clone-safety process, language/embed uncertainties. Update only separately authorized evidence/ledger files.
 - **Acceptance:** distinguish static elements from fields; every proposed field mapped or explicitly pending; no guessed internal IDs or locale behavior. Required callback/contact expectations approved.
 - **Stop:** before any form creation/editing, tests generating notifications, or production mapping.
 ### Batch B — Safe working-copy creation and notification/redirect review
 - **Objective:** create an isolated B copy from the selected original and separately authorized A/C assets; not repurpose operational originals.
 - **Authorization:** explicit Jotform mutation permission identifying source, action, proposed copy names, isolation steps and whether A/C creation is included. A's source remains undecided; C is a new dedicated form. Capacity is not authorization.
 - **Prerequisites:** A's field decisions and safe isolation procedure; account/privacy owner available; approved test recipient roles; no live notification inheritance accepted.
 - **Systems:** Jotform copies/configuration only, plus sanitized provenance documents. Never edit original B or Event Submission Form.
 - **Acceptance:** record actual new IDs, before/after metadata, copied setting audit, protected fields, generic notification, no booking/child identifiers, no PHI forwarding, no Google integration; JF-01–08 repeated for copy. No submitted data imported.
 - **Stop:** isolated copies reviewed, no synthetic submissions unless D separately authorized; no site embed or live activation.
 ### Batch C — Local-only Astro off/mock integration
 - **Objective:** implement typed mode boundary and source-faithful inactive/mock presentation on existing routes.
 - **Authorization:** explicit repository implementation scope; **no Jotform account mutation or external form requests**. Can begin independently of B after minimal fallback/copy/UX decisions; no fabricated schema may substitute for A.
 - **Files:** proposed files in section 2; bounded edits to ContactForm/FormShell/PageLayout/drawer, form-messages and styles; environment example/types only if needed. Preserve ContactObfuscation, search, map provider, content metadata and publication policies.
 - **Suggested first code slice:** configuration + `/contact` and `/es/contact` off/mock with inert fallback, then remaining seven instances in a separately reviewed continuation. Report partial coverage honestly until all nine are protected. First slice must not claim a whole-site form-isolation guarantee.
 - **Acceptance:** off no POST surface or vendor hints; local mock; EN/ES fallback; invalid configuration tests; guarded Chromium checks and existing regression suites. No live IDs in emitted new lead integration.
 - **Stop:** reviewable unstaged local changes and evidence; no hosted preview, live descriptors or account use.
 ### Batch D — Isolated synthetic Jotform integration and accessibility
 - **Objective:** verify JF-09 and runtime JF-03/08 with actual approved isolated form(s).
 - **Authorization:** separately approve test form IDs, origins, environment, synthetic input set, notification recipient roles, permitted methods/network destinations and test window. This is not covered by GET-only prior browser authorization.
 - **Prerequisites:** B isolation reviewed; C mode guards; operations/privacy/language settings approved. Use loopback preview, exact test-only allowlist; production counters/maps/Google/unrelated resources blocked.
 - **Acceptance:** actual EN/ES submit/error/cancel/retry behavior; delivered generic emails and headers inspected in a controlled workflow; no answers/identifiers/attachments; no Contabo forwarding; iframe/fallback, keyboard, real screen reader where available, 200%/400% zoom, slow/offline/block scenarios. Use no real patient data; retain only sanitized results.
 - **Stop:** test-form evidence and remaining gates; no production IDs or deployment.
 ### Batch E — Approved production mapping and staged-site integration
 - **Objective:** prepare reviewed production lead descriptors and page integration without activating them.
 - **Authorization:** separate approval of exact IDs, origins, locales, recipients, privacy/security/operations decisions and static artifact scope. “Staged-site” means a proposed release artifact unless a hosted preview is separately authorized; it never means permission to use Git staging.
 - **Prerequisites:** A–D evidence, OA-01–05 and OA-07, JF settings stable, Tour/evaluation/payment decisions resolved. P9-04 preview isolation remains separate.
 - **Files/systems:** approved typed mapping, reviewed components/messages, tests and configuration documentation; no nginx/DNS/API changes. Working-copy and production IDs must be explicitly distinguished.
 - **Acceptance:** all nine instances mapped, controlled comparison with approved forms, production-mode artifact inspected without browser egress, normal staging still off; no original-form fallback or publication changes.
 - **Stop:** release-candidate review. No live submissions, notification activation, deployment or indexing activation.
 ### Batch F — Phase 10 production acceptance, release and rollback
 - **Authorization:** explicit Phase 10 go/no-go, operator, environment, form activation, approved synthetic operational test and rollback window. Not authorized by this plan.
 - **Prerequisites:** pending human accessibility/visual/language/clinical/privacy reviews, P9-01/03/04/07/09/10 dispositions, hosting validation and release authority. Measurement can remain off.
 - **Acceptance:** correct HTTPS/CSP/referrer/log boundaries, actual approved integrations, failure monitoring, reproducible artifact, route/SEO policies, safe rollback of both Astro and Jotform configuration, named responder. Raspberry Pi fallback requires its own verified parity/security plan.
 - **Stop:** only the explicitly approved operational scope; no automatic ads activation or campaign changes.
 ### Batch G — Separate conversion measurement under P9-05
 - **Authorization:** explicit P9-05/P9-07 approval of vendor data flows, consent, event semantics and tests. Independent of form planning; not required to launch an approved untracked enquiry flow.
 - **Prerequisites:** supported evidence of accepted Jotform submission and duplicate handling; no invented cross-origin event. Existing Ads IDs are documentation only.
 - **Acceptance:** local mocks first, no CTA/open/load/failed-submit conversions, no answer/identifier leakage; any vendor-network test separately authorized.
 - **Stop:** measurement review before tag installation/activation. No GA4/GTM/Ads/remarketing/enhanced-conversion code in Batches A–F by implication.
 ## 7. Future test matrix and validation procedure
 These are specifications for later tests, not test results or executable code added now.
 | Test ID | Required assertion | Where / authorization |
 |---|---|---|
 | FT-01 | Missing/empty/invalid mode defaults safely; explicit invalid live config rejected | Pure config tests, C |
 | FT-02 | No native lead form or active POST in off; Enter/native submit/requestSubmit cannot use an inactive lead surface | Rendered DOM + guarded browser, C; do not merely assert disabled button |
 | FT-03 | Off/mock new integration emits no source/live ID, iframe URL, helper/preconnect or external request | HTML/bundle scan + network ledger, C; existing clinical links scoped separately |
 | FT-04 | Exact nine route mappings and EN/ES behavior, no invented AR/C-ES publication | Existing manifest/content tests, C/E |
 | FT-05 | Mock local-only, no external endpoints, realistic synthetic errors and completion without tracking | Loopback harness, C |
 | FT-06 | 320/390/768/1440, actual 200%/400% zoom, text/reflow, named iframe/fallback, long labels | Guarded Chromium; record browser/device/zoom method, C/D |
 | FT-07 | Keyboard, focus entry/restoration, Escape, scrolling, drawer timer does not load vendor resources | C/D; UX decision required |
 | FT-08 | Missing/invalid ID/locale, iframe blocked/unavailable/slow, offline, JS-disabled fallback | C/D; no guessed language parameter |
 | FT-09 | Screen-reader names/errors/confirmation and EN/ES review | D + human reviewers; remains Pending if unavailable |
 | FT-10 | Actual approved synthetic success/failure, email privacy/headers, no identifiers/attachments/POST forwarding | D only, JF-09; protected data never used |
 | FT-11 | No production Jotform, Contabo form POST, Google/GA4 or counter traffic outside explicitly approved test endpoints | C/D guarded request ledger; attempted versus transmitted distinguished |
 | FT-12 | No booking, child identifiers, unapproved service/payment/location/claim inheritance in approved copy | A/B schema/copy review; D rendered confirmation |
 | FT-13 | No conversion on click/load/start/failure/thank-you replay/untrusted message | G only; supported success contract required |
 | FT-14 | Clinical/Sign/CentralReach paths, search and publication invariants unchanged | Existing link/publication suites, C/E |
 Existing test/tooling hooks: `www/tools/publication.test.mjs`, `seo.test.mjs`, `library.test.mjs`, `phase8.test.mjs`, `playwright-smoke.mjs` and Phase 8 guarded runners. Extend focused tests; do not duplicate 122 complete page snapshots. Do not put a mock fixture in the published collection or add a production route just to test it.
 After an authorized source batch, run sequentially from `www`:
 ```sh
 npm run check
 npm run test:markdown
 npm run test:publication
 npm run test:seo
 npm run test:library
 npm run test:routes
 node --test tools/phase8.test.mjs
 # Run the approved new form tests and guarded browser runner once implemented.
 npm run build
 PUBLIC_ALLOW_INDEXING=true npm run build
 npm run audit:links
 npm run audit:images
 npm run audit:blog
 npm run build
 ```
 Use `TMPDIR=/tmp` for affected fixtures where needed. No network submissions during normal builds/tests. Keep mode off except explicit mock tests; indexing-enabled build is not live-mode approval. Expected unchanged: 122 routes/canonicals, 108 indexing sitemap URLs, 180 hreflang links/55 routes, 25 translation sets, 74 Library articles, search 55/12/7, nine archives/nine redirects, 182 FAQs across 30 articles. Final staging 122 `noindex,nofollow`, empty sitemap/no hreflang. Existing Phase 8 counts (156 tests) are history, not future totals to force.
 Source changes require a newly named offline reconciliation using explicit final Phase 8 evidence `reports/route-reconciliation-2026-10-15-offline-18-21-22-820Z.json`, preserving all history and excluded files. Verify the actual new artifact explicitly with `--check --evidence`; no unrestricted crawl. Documentation alone does not require a new reconciliation. Finish `git diff --check`, source/status/index review; no staging/commit by Codex.
 ## 8. Remaining approvals, evidence and next action
 First recommended authorized batch: **Batch A**, read-only Builder settings verification and final field approval, using the now-complete owner-supplied 27-asset roster. First safe **code** batch is C's off/mock contact slice after its explicit authorization; it can avoid external account changes while B is pending, but cannot invent Jotform settings.
 Owner ledger OA-01–08 and JF-01–09 are all Pending/Unverified in the companion CSV. Pending facts include actual form question IDs/types/defaults/options, PHI flags, conditional routing, real translations/locale URLs, email recipients/templates, integrations/webhooks/exports, thank-you/POST behavior, security/retention/access, safe clone state and supported success signaling. No new production embed ID is known. A's source/reuse decision and final C creation are pending. Tour/event/fundraising separation must be retained.
 Any approval record must identify approver role, date, exact form/environment/version, sanitized evidence and scope. An account label ENABLED, a BAA, a successful static build or a generic vendor help article cannot close these gates. Keep the real screen-reader, authorized visual/non-Chromium, fluent-language, clinical, financial and policy/source-provenance requirements from SESSION_HANDOFF.
 ## 9. Documentation-only validation record
 Preflight branch/HEAD/index checked; three October 17 artifacts present; their contents preserved. Reconciled nine F IDs against current source manifest and generated form instances; seven EN/two ES, no AR, eleven search forms excluded. All 27 reported assets are now individually listed in contract section 3 with 27 unique IDs; metadata provenance and supplied planning classifications are distinguished from unverified Builder settings and operational usage. All reference IDs labeled source-only; no production mapping created. No Builder gate marked verified.
 Validation passed: local Markdown links, balanced code fences and whitespace; 18 unique checklist gates all Pending/Unverified (INV-01 retains configuration/usage verification, while roster receipt is recorded in its evidence) with blank approval dates; unchanged hashes for the three permitted October 17 inventory artifacts; unchanged tracked files; empty index; and `git diff --check`. Protected exclusions were not hashed or read. This task creates only the two October 18 Markdown documents and sanitized checklist CSV. No account mutation, form creation, submission/network POST, tracking, hosting change, build or deployment is performed. No historical document or living handoff is advanced. Protected exclusions and prior staging aid are neither read nor changed.
 Roster reconciliation, version 1.1: only the October 18 contract, plan and checklist were updated. The individual inventory gap is closed by owner-supplied metadata; no JF or owner approval is closed and no implementation batch is executed.
@@ -0,0 +1,256 @@
 # P9-03 Jotform integration contract
 **Contract ID:** P9-03-JF-2026-10-18 · **Version:** 1.1 · **Date:** 2026-10-18
 **Status: documented planning architecture; implementation and activation NOT authorized.**
 This is the authoritative P9-03 planning contract for the owner decisions supplied on October 18. It supersedes conflicting *proposals* in the [October 17 inventory](phase-9-form-entry-point-inventory-2026-10-17.md), without rewriting that historical record. It does not supersede project policy, approve clinical/legal content, close the Phase 9 register, or authorize production changes. Future changes require an explicit owner decision, a version/change record and evidence links. Version 1.0 records the original planning instruction; version 1.1 adds the owner-supplied complete roster without changing decisions or approvals; no future commit SHA is invented.
 Companions: [source-specific implementation plan](phase-9-jotform-implementation-plan-2026-10-18.md), [verification and approval ledger](phase-9-jotform-verification-checklist-2026-10-18.csv).
 ## 1. Verified repository and evidence provenance
 Branch `faithful-astro-migration`; actual HEAD `59911eb929579af7bcd6c42de6476128dab62289`, matching the reference signed Phase 8 checkpoint. Tracked tree and index clean at start. Nine pre-existing untracked files: the three October 17 inventory artifacts, the five protected exclusions and `.phase8-stage-paths.nul`.
 The three local artifacts exist: [inventory report](phase-9-form-entry-point-inventory-2026-10-17.md), [entry CSV](phase-9-form-entry-points-2026-10-17.csv), [account worksheet](phase-9-jotform-owner-worksheet-2026-10-17.csv). The CSV has 2,140 rows including nine enquiry instances and eleven non-lead search instances; the account worksheet has 27 blank metadata rows, not a completed account audit. These files were not part of the inspected checkpoint and remain unchanged.
 Current component inspection and the existing publication-manifest utilities confirm the nine published enquiry routes below. Existing generated HTML agrees with their native empty-action POST forms. This is not a new browser or submission test. No account tools, production forms, submissions, patient records, credentials or private configuration were accessed in this documentation task. Official public help documentation was retrieved read-only; that is not account verification.
 Evidence classes must remain distinct:
 | Class | Source | Permitted conclusion |
 |---|---|---|
 | Owner decision | October 18 user instruction | Approved planning direction, not implementation authority |
 | Owner-confirmed account fact | Same instruction | Gold, HIPAA enablement, signed BAA, 27/100 slots; not independently audited |
 | Reported connector observation | User-supplied summary of read-only ChatGPT Jotform inspection on 2026-10-18 | Reported asset IDs/titles/status/labels/counts; no Builder configuration guarantees |
 | Repository observation | Current source, local inventory, publication manifest and existing HTML | Actual local route/component behavior |
 | Vendor documentation | Official links in section 12 | General capability and cautions, not proof of AIA settings |
 | Pending verification | JF and owner gates | No approval or successful test may be inferred |
 ## 2. Established owner decisions
 - AIA uses Jotform Gold with HIPAA enabled and a signed Jotform BAA; 27 of 100 form slots are occupied. Existing clinical/operational workflows must remain intact.
 - **All public lead submissions go directly to Jotform.** No Contabo submission proxy, PHI-bearing webhook, completed form-data forwarding or clinical-document transfer to Contabo.
 - Prefer iframe presentation, preserving Astro design and locale behavior; use a hosted form fallback where embedding is unsuitable.
 - Use three logical forms: **A General Enquiries, B Service Consultations, C Professional Referral Initiation**. Prefer one EN/ES multilingual physical form for each where verified; separate EN/ES copies are a fallback requiring approval.
 - Form B uses a future separately authorized working copy of **AIA Lead Generator | plain**, source ID `250727122848156`. The original is reference-only and must not be modified, cloned, disabled, deleted or repurposed during this task. No working copy exists or is authorized by this contract.
 - No appointment booking in initial consultation forms. Staff contact the family to arrange follow-up.
 - Begin with the generic Jotform notification in section 8, subject to actual settings/recipient/privacy review. Timestamps and campaign labels are deferred.
 - GA4, Google Ads, GTM, remarketing, enhanced conversions and user-data collection remain disabled/unapproved.
 - Contabo static hosting and approved non-PHI API functions, with Raspberry Pi fallback, remain planning preferences—not verified topology or deployment instructions.
 ## 3. Account assets and accounting for all 27
 The user reports that all 27 assets were classified and ENABLED during the October 18 connector inspection, without retrieving submitted answers. Enabled is an observed status at that time, not approval to use the asset.
 | Asset | Reference-only form ID | Connector elements | Disposition |
 |---|---|---:|---|
 | AIA Lead Generator | `250207157108146` | 22 | Promotional/structural comparison only; legacy service/waitlist/age claims not approved |
 | AIA Lead Generator &#124; plain | `250727122848156` | 16 | Selected structural source for a future authorized **copy**, never the original live embed |
 | AIA Client Consultation Form | `231638510219149` | 16 | Operational reference; not selected source; booking/address/child fields not inherited |
 | AIA Event Submission Form | `242248780044153` | 12 | Separate event-calendar request/approval workflow; preserve, do not merge into A |
 | Other clinical/operational assets, combined | 23 additional IDs listed below | Not supplied | Preserve all; no proposed initial-lead reuse |
 | **Total** | **27 individually listed below** | Not summed as input fields | All reported ENABLED; full configuration unverified |
 ### Complete owner-supplied asset roster
 The owner supplied this complete list as a follow-up to the October 18 read-only connector inspection. IDs and titles are **reported account metadata from that inspection**, not independently re-queried in this reconciliation. The prior report that all 27 were ENABLED is preserved as historical metadata, not current availability or use authorization.
 Classifications are the **owner-supplied planning categories**, not verified Jotform administrative fields or proof of operational usage. They may reflect title-based interpretation; no additional usage is inferred here. Parenthetical descriptions in the two generic “Form” entries are preserved exactly as supplied and may be descriptive annotations rather than literal Builder titles. Their exact Builder titles remain subject to verification. In particular, “Unclassified” and “placeholder candidate” do not establish that an asset is unused or safe to delete.
 | Reference-only form ID | Supplied classification | Supplied form title |
 |---|---|---|
 | `232985535203155` | Agreement | AIA Visitor Confidentiality Agreement Form |
 | `240620332314138` | Clinical operations | AIA Clinical Manager Daily Line-Up AM Report - Scottsdale |
 | `240936470111146` | Billing | AIA Client Late Billing Form |
 | `240619052715150` | Clinical operations | AIA Clinical Manager Daily Line-Up PM Report - Scottsdale |
 | `231638510219149` | Lead candidate | AIA Client Consultation Form |
 | `232905007988161` | Agreement | ABA Intake Agreement Form |
 | `232841161148048` | Clinical assessment | AIA Learner Pre-Assessment Form |
 | `250727122848156` | Lead candidate | AIA Lead Generator &#124; plain |
 | `232908888347170` | Agreement | AIA Learner Social Club Intake Agreement Form |
 | `240620858181153` | Administration | AIA Monthly Clinical Administrator Supply Order Report |
 | `242248780044153` | Event workflow | AIA Event Submission Form |
 | `240620359815153` | Clinical operations | AIA Daily Clinical Administrator Line-Up Report - Scottsdale |
 | `253627035160047` | Training | Form (RBT Training Documentation) |
 | `241344474497161` | Billing | AIA Claims Billing Daily Line-Up PM Report |
 | `250207157108146` | Lead candidate | AIA Lead Generator |
 | `250215235488052` | Unclassified | Form (two-element placeholder candidate) |
 | `241348621585157` | Billing | AIA Accounts Billing Daily Line-Up PM Report |
 | `241088352323149` | Clinical operations | AIA Clinical Client Advocate Supervisor Daily Line-Up PM Report |
 | `233248580388162` | Agreement | PSY Intake Agreement Form |
 | `233298119061153` | Clinical assessment | AIA Psychological Pre-Assessment Form |
 | `241336917832157` | HR operations | AIA Recruiting Daily Line-Up PM Report - Scottsdale |
 | `240778894757176` | HR operations | AIA Job Requisition Form |
 | `241336553202144` | HR operations | AIA Human Resources Daily Line-Up PM Report |
 | `241468586261161` | Administration | AIA Operations Monthly Line-Up PM Report |
 | `242029552135148` | Marketing operations | AIA Marketing Monthly Line-Up PM Report |
 | `242236946264158` | Administration | AIA Technology Request Form - Scottsdale |
 | `240728578023156` | Administration | AIA Maintenance Request Form - Scottsdale |
 Validation: **27 rows, 27 unique IDs**. The four previously identified assets are included; the other 23 are now individually listed. The individual roster is no longer outstanding. This fills the metadata inventory gap only: JF-01 through JF-09 and all owner approvals remain pending. The October 17 worksheet and source evidence are preserved unchanged.
 `250727122848156` is the selected **source-template ID only**, never an approved production embed ID. Preserve every listed clinical, agreement, billing, event, HR, administrative and other operational workflow; no classification permits modification, repurposing or deletion. This roster contains no submitted answers, patient data, submission metadata or inferred field-level configuration.
 The plain form's reported update timestamp is `2026-05-07 22:27:30`, timezone unknown. Element counts include headings/static content/buttons and are **not input-field counts**. Its reported input labels are Full Name, Phone Number, E-mail, Service Interest, Location Interest, Insurance & Payment Options, How Did You Hear About Us?, Child's Name, Child's Date of Birth, Child's Age, Additional Information/Comments. These labels do not establish types, IDs, required flags, defaults, PHI settings or option values.
 The operational consultation form includes adult contact/service/payment, child name/age, appointment date/time, address, area, source and comments. None is adopted merely because present. The richer Lead Generator's broad children/teens and service/waitlist claims require current organizational review.
 **No production embed ID is assigned for A, B or C.** All four existing IDs above are evidence references only. The source B ID must be rejected as the future B working-copy/live mapping. Account slot availability is not creation permission; three new forms would provisionally mean 30/100, while six separate EN/ES forms would mean 33/100, subject to actual reuse and account-limit verification.
 ## 4. Proposed semantic field contracts
 Names below are domain semantics only, **not Jotform question IDs, uniqueName values, URL-prefill keys or actual schemas**. Operations, clinical and privacy approval remain pending.
 | Form | Semantic field | Proposed requirement |
 |---|---|---|
 | A | adult_name | Required |
 | A | adult_email | Required |
 | A | adult_phone | Optional |
 | A | inquiry_type | Required controlled selection: general; tour only after workflow approval |
 | A | preferred_contact | Optional; define valid choices and phone/email consistency |
 | A | message | Omit by default; add only with explicit approval |
 | A | source_code | Deferred; absent initially |
 | B | adult_name | Required |
 | B | adult_email | Required |
 | B | adult_phone | Operations decision pending; no implied default requirement |
 | B | service_interest | Required, approved controlled selection |
 | B | payment_category | Optional, approved categories only |
 | B | service_area | Optional city/area; not full address |
 | B | preferred_contact | Optional; define consistency with available contact fields |
 | B | message | Prefer omitted; owner review |
 | B | source_code | Deferred; absent initially |
 | C | professional_name | Required |
 | C | organization | Required |
 | C | work_email | Required |
 | C | work_phone | Optional |
 | C | referral_service | Required, approved controlled selection |
 | C | referral_notes | Omit by default |
 | C | source_code | Deferred; absent initially |
 **A:** General website/contact enquiries; Tour only if approved. Fundraising and other organizational types require explicit additions. Existing event workflow is not included. No child name/DOB, diagnosis, records, address, calendar or unnecessary free text.
 **B:** Consultation for ABA, Learner Social Club, approved evaluation availability, and approved commercial/AHCCCS/private-pay branches. Proposed service semantics: `aba`, `learner_social_club`; `autism_evaluation` only after availability review; `other` only if approved. General ABA baseline: **18 months through eight years**. Learner Social Club: separate **private-pay program ages 8–17** per owner direction. Academy-specific ages/ratios are not generalized to either form. No automatic carryover of Tricare, CareCredit, Glendale, waitlist, enrollment or guaranteed-admission claims. Payment/service-area options need current operational approval.
 B excludes child name, exact DOB, diagnosis, clinical history, records/uploads and appointment calendar unless separately approved within an appropriate protected workflow. Staff arrange follow-up; no promise of a booked appointment. Existing booking-oriented site headings are an editorial approval item, not permission to silently rewrite metadata or body content.
 **C:** New dedicated form only after creation authorization. Initial professional contact, not patient-record transfer. No patient name/DOB, diagnosis narrative, medical document or protected case detail. Detailed referral belongs in a separately approved protected workflow. Existing clinical/CentralReach paths remain unchanged.
 Treat submitted contact information and any approved free text as protected unless the privacy owner explicitly determines otherwise. Required-field proposals do not justify exposing values in email. If a visitor chooses phone contact without supplying a phone number, define an approved conditional validation or fallback rather than inventing behavior.
 ## 5. Reconciled Astro route mapping
 Cross-checked against F-001–F-009 in the local CSV, current source and eligible publications. Paths below are relative to `www`.
 | ID | Published route | Locale | Current owner | Target |
 |---|---|---|---|---|
 | F-001 | `/contact` | EN | `src/components/ContactForm.astro:17`, via `components/pages/ContactPage.astro:19` | A |
 | F-002 | `/es/contact` | ES | Same, explicit locale | A ES |
 | F-003 | `/client-consultation` | EN | `src/components/FormShell.astro:12`, `layouts/PageLayout.astro:15,82` | B |
 | F-004 | `/es/client-consultation` | ES | Same, explicit locale | B ES |
 | F-005 | `/schedule-consultation` | EN | Same FormShell | B |
 | F-006 | `/referrals` | EN | Same FormShell; CTA `#form-title` | C |
 | F-007 | `/aba-therapy` | EN | `src/components/ServiceInquiryDrawer.astro:71`, `layouts/PageLayout.astro:81` | B / approved ABA context |
 | F-008 | `/autism-evaluations` | EN | Same drawer | B only after availability/copy approval |
 | F-009 | `/learner-social-club` | EN | Same drawer | B / approved Social Club context |
 Three implementations, nine instances: seven EN, two ES, zero AR. Eleven GET search instances are not lead forms and must not be disabled or routed to Jotform. No new Arabic form or translated publication is authorized. Spanish service pages currently use Spanish consultation CTAs, not drawers. Arabic visitors retain established English fallbacks and clear language notices. All three logical forms prefer EN/ES capability, but no Spanish referral page or new route is implied.
 Tour's actual CTA currently goes to `/client-consultation` (B destination). A is the provisional proposed Tour mapping, **not a completed route change**. Fundraising awaits owner confirmation. Historical event requests remain separate; do not reinterpret the historical Eventbrite link as the account's Event Submission Form without evidence. `/client-forms` retains existing clinical, agreement, Sign and CentralReach links. The six repository-linked Jotform destinations are not automatically matched to the four named account assets.
 `/lp/early-intervention` and the provisional local `/client-consultation` substitution remain P9-01 decisions. Campaign landing pages outside this repository are out of scope. Phone/email legacy-target issues in the inventory remain unresolved; no target is silently replaced.
 ## 6. Verification gates — all Pending / Unverified
 The connector supplied titles, IDs, enabled status, timestamps, labels and limited summaries—not a full Builder audit. Each gate must record the exact source/working-copy ID, reviewer, date, sanitized evidence and disposition. A source-form finding does not automatically pass the corresponding working-copy gate.
 | Gate | Required verification | Owner / evidence |
 |---|---|---|
 | JF-01 | Types, required flags, defaults, exact options, visibility, internal identifiers, field-level PHI | Account owner + operations/privacy; Builder properties, no answers |
 | JF-02 | Show/hide, skip, calculations, update-field logic, conditional recipients and submission routing | Account owner; sanitized Conditions settings |
 | JF-03 | EN/ES support, complete translation, default/selector, errors, conditional logic, confirmation and embed locale behavior | Account owner + fluent reviewers; Builder plus later authorized runtime tests; never assume `?language=es` |
 | JF-04 | Notifications/autoresponders, recipient roles, subject/body/dynamic tags, attachments, reply-to, conditional routes, default IDs/links, cloned production recipients | Account/privacy owner; sanitized settings, no recipient addresses in public reports |
 | JF-05 | Native confirmation, redirects, answer echo, all targets, HTTP POST forwarding | Account/privacy owner; Builder; **submission-data POST to Astro/Contabo OFF** |
 | JF-06 | Integrations, webhooks, exports, destinations, Google/analytics, protected-data flows | Account/security/privacy owner; actual integration inventory, not cloning assumptions |
 | JF-07 | HIPAA/form/field protection, spam, availability, prefill, save/continue, access, retention, limits and duplicates | Account/privacy/security owner; settings and approved operational policy |
 | JF-08 | Approved HTTPS origin, hosted/iframe URLs, dimensions/mobile, scripts, referrer, locale and fallback | Account/hosting/accessibility owners; exported code and later authorized runtime evidence |
 | JF-09 | Actual EN/ES synthetic submission, notifications, success/failure, redirects and privacy boundary | **Later separately authorized** isolated form/environment; never real patient data |
 No JF gate has passed. Read-only Builder review may complete configuration portions of JF-01–08; runtime portions remain pending until explicitly authorized. Generic vendor documentation does not close a gate. The [CSV ledger](phase-9-jotform-verification-checklist-2026-10-18.csv) also tracks owner approvals and the supplied complete roster and its pending configuration/usage verification.
 ## 7. Future integration-mode contract
 Suggested semantic setting: `PUBLIC_AIA_FORMS_MODE`, exact values `off`, `mock`, `live`; typed build-time configuration, default **off**. Missing/invalid values must fail closed; explicit invalid live configuration should fail the build with a non-sensitive error. Do not infer mode from a URL, hostname, indexing setting or original source ID.
 | Mode | Required behavior |
 |---|---|
 | off | No active lead form/empty POST action, live iframe, Jotform preconnect/helper/network request, or analytics. Render approved localized contact fallback; no native-submit bypass on inactive lead UI |
 | mock | Synthetic local-only fixture, no external endpoint or real data; safe guarded Playwright use; no Jotform ID required |
 | live | Separate owner/deployment approval; exact approved IDs/HTTPS origins/URLs and build/deploy gate; no automatic original-form fallback. Distinguish authorized isolated test form from authorized production form |
 Off/mock output must not contain **new lead embed IDs/URLs or the B source-template ID** in HTML, scripts, preload hints or client bundles. Existing clinical/Sign links intentionally remain in the site; they already contain production destinations. Preserving them conflicts with a blanket “no production ID anywhere” assertion, so this contract's new-embed restriction is scoped to the new lead integration. Existing user-initiated clinical navigation is not permission for automatic loading or test submissions. Do not claim the whole site has zero vendor destinations.
 A separately approved isolated test can exercise live integration capability with **test-only mappings** and controlled notifications. Normal staging defaults off and cannot inherit production mappings. `PUBLIC_ALLOW_INDEXING` is independent and provides no privacy isolation. Forms modes do not change the separate likes/views API policy or existing map resource behavior; guarded tests still block those endpoints.
 Reusable iframe requirements: exact approved HTTPS origin and URL, localized accessible title, responsive width and tested height, visible hosted fallback, loading/error explanation, mobile scroll, keyboard/focus support and minimal permissions. No arbitrary queries, unreviewed helper scripts, guessed language keys or untrusted cross-origin events. Frame `load` is not success. CSP/referrer policy require review; a parent policy does not control all resources inside the cross-origin document. Do not introduce a Contabo CORS proxy.
 The existing ten-second drawer timer must not cause Jotform loading without explicit UX/privacy approval. Retention of auto-opening, explicit open and click-to-load are pending options. No wholesale dialog redesign is authorized. If embedding cannot satisfy usability/accessibility/privacy, use the approved hosted fallback.
 Answers must not enter Astro handlers, Contabo endpoints, unreviewed webhooks, redirect URLs, analytics, Google tags or application/server logs. No arbitrary UTM/referrer/query/visitor text forwarding. Source codes, persistence and campaign mappings are deferred. Static-host access logs still require review for inbound query strings even when answers stay in Jotform.
 ## 8. Initial notification contract
 Proposed exact initial template (activation still pending JF-04 and privacy approval):
 ```text
 Subject: New AIA form submission
 A new form submission has been received.
 Sign in to AIA's authorized Jotform account to review it.
 ```
 No dynamic answer tags, PDFs or other submission attachments, respondent reply-to, patient/family names, submitted email/phone, clinical data, submission ID, individual submission/edit link, unreviewed CC/BCC or automatic forwarding of responses. Do not disable PHI protection to expose a field. Check sender, headers, footer, hidden/default fields and all-field tokens as well as visible body. Arizona-local date/time and source/campaign labels are **deferred**, not optional additions for the implementer. No respondent autoresponder is authorized by this generic staff notification.
 Jotform's [HIPAA email guidance](https://www.jotform.com/help/504-how-to-use-notification-and-autoresponder-emails-in-hipaa-accounts/) describes excluding protected fields; its [field-protection guidance](https://www.jotform.com/help/518-How-to-set-PHI-fields-on-your-forms/) requires proper field classification. These do not prove a current template is safe. Inspect the actual copy, approved recipient roles and delivered synthetic message later. Never create a Contabo webhook receiving full answers to generate a generic email.
 ## 9. Working-copy safety and success measurement
 No working-copy creation or original mutation is authorized now. A later permitted copy must first be isolated from public access and live notifications/automations using an account-owner-approved process. If immediate isolation cannot be established safely, stop rather than creating an exposed copy. Verify settings before opening/filling it; do not test inherited recipients to discover where mail goes.
 The official [cloning guide](https://www.jotform.com/help/27-how-to-clone-an-existing-form-from-your-account/) warns that email settings, including recipients, and several workflow/thank-you settings are copied. It also describes encryption-related changes and differing treatment of integrations/payment connections. This is a reason to audit the actual copy, not a guarantee of AIA's exact copy behavior or HIPAA configuration. Never copy submissions. Capacity and “Clone of” naming do not establish a safe development environment.
 The [Ads handoff](google-ads-consultation-conversion.md) documents account `515-940-4739` and tag `AW-18494479353`, reference-only. Its prior approved-API response premise needs a separate P9-05 redesign for direct Jotform submission. The accepted-submission principle remains; no counting CTA clicks, frame loads, opens, starts, failed attempts, arbitrary thank-you visits or untrusted postMessage events. Cross-origin iframe visibility is not a verified acceptance signal. No success-event name or payload is invented.
 No Google Ads/GA4/GTM, enhanced conversions, remarketing, tracking scripts, customer data or real-network measurement tests. P9-05/P9-07 remain open. [Thank-you settings](https://www.jotform.com/help/211-setting-up-the-thank-you-page/) and [POST forwarding](https://www.jotform.com/help/213-send-submission-data-via-post-method-and-thank-you-settings/) must be reviewed: a redirect must not export answers to Astro/Contabo. Production remains Phase 10.
 ## 10. Owner approval ledger
 All implementation approvals below are **Pending**. Organizational selection of Jotform/three forms is already recorded; it does not resolve these gates.
 | ID | Owner role | Approval/evidence required |
 |---|---|---|
 | OA-01 | Intake/operations | Minimum fields, required flags/contact preference consistency, follow-up/callback expectations, Tour/fundraising scope |
 | OA-02 | Clinical leadership | Eligibility, service/evaluation availability, private-pay Social Club distinction, referral boundary and approved claims |
 | OA-03 | Jotform account owner | JF-01–08, safe copy process and actual new IDs/configuration; original preservation |
 | OA-04 | English/Spanish reviewer | Labels, errors, instructions, confirmations and locale switching; no automatic translation approval |
 | OA-05 | Privacy/legal/security | Protected fields, generic email/headers/recipients, embeds/referrers, vendor flows, access/retention and tracking boundaries |
 | OA-06 | Marketing | Deferred attribution categories and redesigned successful-submission semantics |
 | OA-07 | Hosting owner | Static/API separation, compile/deploy gates, CSP/referrer/log policy, preview isolation and fallback topology |
 | OA-08 | Release owner | Phase 10 integration activation, go/no-go, artifact/vendor rollback and deployment |
 Preserve real screen-reader, authorized visual, non-Chromium, fluent Arabic/Spanish, clinical and privacy-policy acceptance, including trusted Spanish-policy source comparison. No signed technical checkpoint closes these gates. P9-01 campaign ownership, P9-02 portal, P9-04 counters, P9-08 author SEO and other Phase 9 decisions remain outside form implementation authority.
 ## 11. Acceptance and restrictions
 Future tests must cover off-mode native/Enter/scripted submission safety and zero integration traffic; local mock behavior at 320/390/768/1440px, actual 200%/400% zoom, keyboard/focus, errors/offline/slow iframe, invalid locale/configuration, EN/ES consistency, drawer Escape and real screen-reader review where available. JF-09 synthetic submissions need a separately approved isolated form and notification recipients. Test failure, success, redirects, field protection and no Contabo/Google answer flow. No real patient data.
 This task created documents only. No forms created/copied/edited, no connector account access, no submissions or network mutation, no integrations/notifications/analytics configured, no production systems changed, and no staging/commit/deployment. Protected files and old staging aid are untouched. Historical inventories, acceptance records, SESSION_HANDOFF and decision register remain unchanged.
 ## 12. Supporting documentation and change record
 In addition to the specific references above, official guidance reviewed on October 18: [email settings](https://www.jotform.com/help/30-explanation-of-email-notification-and-autoresponder-settings/), [multilingual forms](https://www.jotform.com/help/298-How-to-Make-Your-Forms-Multilingual/) and [embed choices](https://www.jotform.com/help/67-Which-Form-Embed-Code-Should-I-Use/). Capabilities do not verify account-specific language URLs, callback behavior or approval.
 Version 1.0, 2026-10-18: records the owner's three-form/direct-Jotform/no-booking/generic-notification direction and supplied connector evidence; reconciles nine local instances; adds pending verification and authorization gates. Any successor must identify changed decisions, approver/date/evidence and affected implementation batches. Until separately authorized, stop at documentation.
 Version 1.1, 2026-10-18: adds the complete owner-supplied 27-ID roster and distinguishes reported metadata from planning classifications. Removes superseded missing-roster statements. Architecture, source-template restrictions, implementation authority and pending approval statuses are unchanged. No Jotform access or mutation occurred during this reconciliation.
@@ -0,0 +1,28 @@
 inventory_row,form_title,form_id_or_public_url,status,business_purpose,owner_role,active_workflow,field_schema_names_labels_types_required,phi_flags_including_hidden_fields,languages_and_errors,conditional_logic,notification_template_metadata_only,recipient_roles_no_addresses_needed,subject_reply_to_attachments,account_timezone,thank_you_redirect_and_post_data_setting,integrations_webhooks_trackers,sensitive_clinical_fields,embed_code_sanitized_or_availability,capacity_limits,candidate_category,reviewer_date_evidence
 1,,,,,,,,,,,,,,,,,,,,,
 2,,,,,,,,,,,,,,,,,,,,,
 3,,,,,,,,,,,,,,,,,,,,,
 4,,,,,,,,,,,,,,,,,,,,,
 5,,,,,,,,,,,,,,,,,,,,,
 6,,,,,,,,,,,,,,,,,,,,,
 7,,,,,,,,,,,,,,,,,,,,,
 8,,,,,,,,,,,,,,,,,,,,,
 9,,,,,,,,,,,,,,,,,,,,,
 10,,,,,,,,,,,,,,,,,,,,,
 11,,,,,,,,,,,,,,,,,,,,,
 12,,,,,,,,,,,,,,,,,,,,,
 13,,,,,,,,,,,,,,,,,,,,,
 14,,,,,,,,,,,,,,,,,,,,,
 15,,,,,,,,,,,,,,,,,,,,,
 16,,,,,,,,,,,,,,,,,,,,,
 17,,,,,,,,,,,,,,,,,,,,,
 18,,,,,,,,,,,,,,,,,,,,,
 19,,,,,,,,,,,,,,,,,,,,,
 20,,,,,,,,,,,,,,,,,,,,,
 21,,,,,,,,,,,,,,,,,,,,,
 22,,,,,,,,,,,,,,,,,,,,,
 23,,,,,,,,,,,,,,,,,,,,,
 24,,,,,,,,,,,,,,,,,,,,,
 25,,,,,,,,,,,,,,,,,,,,,
 26,,,,,,,,,,,,,,,,,,,,,
 27,,,,,,,,,,,,,,,,,,,,,
@@ -0,0 +1,19 @@
 gate_id,subject,verification_required,owner_role,evidence_source,status,approval_date,authorization_required
 JF-01,Question properties,"Types, required flags, defaults, exact options, visibility, internal identifiers, field-level PHI","Account owner + operations/privacy; Builder properties, no answers",Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 JF-02,Conditions,"Show/hide, skip, calculations, update-field logic, conditional recipients and submission routing",Account owner; sanitized Conditions settings,Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 JF-03,Languages,"EN/ES support, complete translation, default/selector, errors, conditional logic, confirmation and embed locale behavior",Account owner + fluent reviewers; Builder plus later authorized runtime tests; never assume `?language=es`,Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 JF-04,Emails,"Notifications/autoresponders, recipient roles, subject/body/dynamic tags, attachments, reply-to, conditional routes, default IDs/links, cloned production recipients","Account/privacy owner; sanitized settings, no recipient addresses in public reports",Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 JF-05,Thank-you behavior,"Native confirmation, redirects, answer echo, all targets, HTTP POST forwarding",Account/privacy owner; Builder; submission-data POST to Astro/Contabo OFF,Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 JF-06,Integrations,"Integrations, webhooks, exports, destinations, Google/analytics, protected-data flows","Account/security/privacy owner; actual integration inventory, not cloning assumptions",Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 JF-07,Security and availability,"HIPAA/form/field protection, spam, availability, prefill, save/continue, access, retention, limits and duplicates",Account/privacy/security owner; settings and approved operational policy,Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 JF-08,Embedding,"Approved HTTPS origin, hosted/iframe URLs, dimensions/mobile, scripts, referrer, locale and fallback",Account/hosting/accessibility owners; exported code and later authorized runtime evidence,Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 JF-09,Controlled synthetic acceptance,"Actual EN/ES synthetic submission, notifications, success/failure, redirects and privacy boundary",Later separately authorized isolated form/environment; never real patient data,Sanitized Builder configuration and owner approval; authorized runtime evidence where required,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 OA-01,Intake/operations,"Minimum fields, required flags/contact preference consistency, follow-up/callback expectations, Tour/fundraising scope",Intake/operations,Dated owner approval with scope and sanitized supporting evidence,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 OA-02,Clinical leadership,"Eligibility, service/evaluation availability, private-pay Social Club distinction, referral boundary and approved claims",Clinical leadership,Dated owner approval with scope and sanitized supporting evidence,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 OA-03,Jotform account owner,"JF-01–08, safe copy process and actual new IDs/configuration; original preservation",Jotform account owner,Dated owner approval with scope and sanitized supporting evidence,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 OA-04,English/Spanish reviewer,"Labels, errors, instructions, confirmations and locale switching; no automatic translation approval",English/Spanish reviewer,Dated owner approval with scope and sanitized supporting evidence,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 OA-05,Privacy/legal/security,"Protected fields, generic email/headers/recipients, embeds/referrers, vendor flows, access/retention and tracking boundaries",Privacy/legal/security,Dated owner approval with scope and sanitized supporting evidence,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 OA-06,Marketing,Deferred attribution categories and redesigned successful-submission semantics,Marketing,Dated owner approval with scope and sanitized supporting evidence,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 OA-07,Hosting owner,"Static/API separation, compile/deploy gates, CSP/referrer/log policy, preview isolation and fallback topology",Hosting owner,Dated owner approval with scope and sanitized supporting evidence,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 OA-08,Release owner,"Phase 10 integration activation, go/no-go, artifact/vendor rollback and deployment",Release owner,Dated owner approval with scope and sanitized supporting evidence,Pending/Unverified,,Separate batch authorization; no action authorized by this checklist
 INV-01,Supplied roster provenance and remaining verification,Complete 27-ID roster received and uniqueness checked; verify uncertain generic titles and relevant operational classification with account owner without inferring usage or retrieving submissions,Jotform account owner,Owner-supplied read-only connector roster; contract v1.1 section 3 lists all 27 unique IDs; individual roster no longer outstanding; configuration and usage verification pending,Pending/Unverified,,Read-only metadata review authorization; no account mutation