# P9-03 Jotform integration contract ## Current decision — 2026-10-30: default-live Form A The owner intentionally supersedes the earlier isolated-test and seven-route production-gate architecture. `npm run dev` and `npm run build` now enable Form A on exactly **16 approved placements**, including the publicly reachable `aia.web3app.dev` environment. No additional approval flags or access restriction are required. `PUBLIC_AIA_FORMS_MODE` is optional: absent/empty means `live`; explicit `off` and `mock` remain available. Invalid/obsolete `isolated-test` settings produce an actionable configuration error. The former approval flags and form environment role are retired, not renamed. Indexing and forms are independent. Both publication modes emit ten immediate frames (two contact, five landing, three consultation) and six deferred bilingual service-drawer frames. The bounded registry fixes ID `262946078314059`, HTTPS origin, context and language. Forms B/C are not activated; physical B is retired. Live drawers retain four-second/50%-scroll opening, shared 30-day suppression, manual CTA override, deferred loading, verified completion acknowledgment for five seconds, animated dismissal and fresh-form reopening. Off mode does not automatically show inactive drawers. All iframe security/fallback behavior is preserved. Employee-portal preview remains independently gated by explicit local approval, valid private ciphertext input and non-indexing output; Form A cannot authorize private content. No portal private resources enter normal artifacts. This owner authorization does not modify Jotform, authorize site cutover or complete pending consultation-language, provider-event, accessibility, runtime telemetry/privacy, recipient-routing or hosting acceptance. See the [current operating guide](../integrations/jotform/README.md) and [implementation and validation report](phase-9-form-a-default-live-2026-10-30.md). Earlier dated decisions and test results below are historical evidence, not current environment setup instructions. **Contract ID:** P9-03-JF-2026-10-18 · **Version:** 1.9 · **Decision revision:** 2026-10-30 **Current status: default-live Form A approved on 16 placements; site deployment/cutover not authorized. Historical contract follows.** This is the authoritative P9-03 planning contract for the owner decisions supplied on October 18 and revised through October 29. 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 beyond the Form A configuration scope recorded below, 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; version 1.2 supersedes the copy-based Form B proposal with three new blank forms; version 1.3 records limited owner-confirmed Form A configuration evidence; version 1.4 reconciles completed direct-Jotform testing and the seven-route isolated iframe adapter; version 1.5 records owner-reported embedded synthetic acceptance for sampled routes; version 1.6 adds the independent production-build gate without deploying it; version 1.7 retires physical Form B and specifies Form A consultation plus Form C referral planning; version 1.8 records the owner-reported consultation configuration and a separate nine-route isolated-test adapter. No future commit SHA is invented. Companions: [source-specific implementation plan](phase-9-jotform-implementation-plan-2026-10-18.md), [two-form integration specification](phase-9-two-form-integration-specification-2026-10-28.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 two physical forms: **A General Enquiries, landing enquiries and family service consultations**, and **C Professional Referral Initiation**. Form A retains its existing `contact` and `landing` contexts; owner-reported Builder configuration now includes `consultation`, which Astro may render only through its separate non-indexing isolated-test gate. `service` may remain a logical visitor-intent classification, not a separate physical form. - **Physical Form B is retired.** Do not create, clone or repurpose a separate service-consultation form. Form C alone remains a future blank-form creation task; the former proposal to use a working copy of **AIA Lead Generator | plain** remains superseded. - The historical source ID `250727122848156` remains reference evidence only. It must not be modified, cloned, disabled, deleted, repurposed or used as an embed destination under this decision. Existing clinical, agreement, billing, event, HR, administrative and CentralReach workflows remain independent. - 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. ### 2.1 Form A owner-confirmed configuration evidence — 2026-10-27 The owner supplied the following **Form A-specific configuration evidence** after a ChatGPT WebUI/Jotform review. The repository did not access the Jotform account, inspect submissions, or independently audit the Builder. Treat this as owner-confirmed evidence, not a blanket HIPAA certification and not proof of equivalent settings on Forms B, C, or any legacy form. - **Form A — General Enquiries** has form ID `262946078314059`. The ID is approved only for the gated Form A integration described in the current implementation and is **not production-activation authority**. - Form A's submitted fields are confirmed PHI-protected. - Form A's staff notification uses the approved generic, no-PHI template. It does not include submitted answers or a submission PDF attachment. - Form A has no webhooks or third-party integrations configured. - The owner reports privacy approval for these Form A controls and the direct-to-Jotform boundary. This confirmation includes owner-verified notification-recipient access and Form A submission-retention controls. The exact authorized roles and retention period remain account-policy information and are intentionally not copied into the repository. The later owner-confirmed direct-Jotform runtime evidence is recorded in section 2.2. It does not enable Form A, approve an iframe in a production artifact, or close P9-03, P9-05, P9-07, or Phase 10 release approval. Forms B and C remain separately planned and unverified. ### 2.2 Form A direct runtime evidence and isolated iframe status — 2026-10-28 The owner reports the following **direct-Jotform synthetic test evidence** for Form A. These tests were performed through Jotform itself; the repository did not submit data, inspect submissions, or access the Jotform account. - English and Spanish synthetic submissions completed successfully. - Native Jotform thank-you behavior was verified. - Staff-notification and family-autoresponder delivery were verified. The generic staff notification contained no submitted answers or PDF attachment. - Staff Reply-To was corrected with a fixed hidden email field and verified in Thunderbird. - No webhooks or third-party integrations are configured. - The conditional email requirement and language handling were verified. The owner additionally reports successful synthetic submission and native confirmation through the isolated Astro iframe on `/contact`, `/es/contact`, and one ABA landing placement. The owner report identifies the third placement only as an ABA landing page; record its exact route in the release test log rather than inferring it from the allowlist. These tests establish Form A's **functional submission acceptance** for the reported direct and embedded samples. The repository did not reproduce the submissions or inspect their answers. The remaining four or five landing placements, depending on the exact sampled ABA route, have automated rendering and fixed-URL coverage only. The current adapter is restricted to the seven placements listed in section 5 and to a separately gated, non-indexing `isolated-test` build. Its frame `load` event is only a transport signal; it is never treated as Jotform initialization, an accepted submission, or a conversion. The production-gated adapter is now prepared in the repository, but no deployment environment is configured by this record. Open Form A gates are therefore: final responsive, keyboard, screen-reader and fluent-language acceptance across all seven placements; Jotform runtime/network and telemetry privacy review; marketing-recipient operational review; deployment/hosting acceptance; and final site-release authorization. ## 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 | plain | `250727122848156` | 16 | Historical structural reference only; not a source for cloning and never an embed destination | | 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 | 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. Form A's limited 2026-10-27 configuration evidence is recorded in section 2.1 and the ledger; all other JF and owner approval scope remains pending. The October 17 worksheet and source evidence are preserved unchanged. `250727122848156` is a **historical reference ID only**, never an approved production embed ID or blank-form source. 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. **Form A alone has an approved ID for its existing fixed contexts.** Form C has no ID; physical Form B is retired and has none. All legacy IDs above remain evidence references only. The former source B ID must be rejected as a clone, working-copy or live mapping. Account capacity does not establish creation or configuration permission. ### Revised blank-form decision and legacy review The owner now selects **two physical Jotform forms**. Existing Form A is extended only after acceptance of its planned `consultation` context; Form C is the sole new blank form. This avoids a separate legacy-derived service form and preserves all existing operational workflows. One EN/ES multilingual configuration per form remains preferred where Builder and runtime verification support it; separate language forms remain a fallback requiring approval. The new Form C and any unapproved Form A consultation configuration are to use minimum-necessary fields with PHI protection, built-in confirmation, and no unapproved integrations, webhooks, answer-forwarding, PDFs or dynamic notification fields. A short English/Spanish family acknowledgment may be considered later, but it requires language, privacy and account-owner approval and must not echo submitted information. The owner also reports remediation of the existing `AIA Lead Generator | plain` form: all fields marked PHI-protected, automatic email-template updates disabled, autoresponder content revised to exclude submitted PHI, Spanish autoresponder behavior checked, email delivery tested by the owner and the generated submission PDF attachment removed. These are owner-reported actions, not an independent audit or HIPAA certification. Historical notification recipients, access, retention, delivery, other legacy forms and actual account settings remain separate privacy/operational review items. No submissions or historical emails were accessed. ## 4. Semantic field contracts Names below are domain semantics only, **not Jotform question IDs, uniqueName values, URL-prefill keys or actual schemas**. The v1.7 two-form contract supersedes former physical Form B planning; the historical B rows below remain only as dated decision evidence. Current future specifications are in [the two-form integration specification](phase-9-two-form-integration-specification-2026-10-28.md). 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 | | A / consultation | service_interest | Owner-reported configured required controlled choice; Builder properties, translations, conditions and runtime acceptance remain pending; no ID or option value inferred | | B (retired) | adult_name | Historical proposal only; not a physical-form requirement | | B (retired) | adult_email | Historical proposal only | | B (retired) | adult_phone | Historical proposal only | | B (retired) | service_interest | Historical proposal only | | B (retired) | payment_category | Historical proposal only | | B (retired) | service_area | Historical proposal only | | B (retired) | preferred_contact | Historical proposal only | | B (retired) | message | Historical proposal only | | B (retired) | source_code | Historical proposal only | | 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 (retired as a physical form):** The following was the former consultation proposal and is retained only as history. Form A `consultation` now carries the approved service choices described in the two-form specification. 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. The planned Form A consultation context 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` | Form A / `consultation`, isolated-test only | | F-004 | `/es/client-consultation` | ES | Same, explicit locale | Form A / `consultation`, isolated-test only | | F-005 | `/schedule-consultation` | EN | Same FormShell | Form A / `consultation`, isolated-test only | | F-006 | `/referrals` | EN | Same FormShell; CTA `#form-title` | C | | F-007 | `/aba-therapy` | EN | `src/components/ServiceInquiryDrawer.astro`, `layouts/PageLayout.astro` | Form A / `consultation`, isolated-test-only explicit drawer | | F-008 | `/autism-evaluations` | EN | Same drawer | Form A / `consultation`, isolated-test-only explicit drawer | | F-009 | `/learner-social-club` | EN | Same drawer | Form A / `consultation`, isolated-test-only explicit drawer | The October 17 inventory remains three implementations and nine original instances: seven EN, two ES, zero AR. The October 29 isolated-test extension adds three explicitly opened Spanish service drawers, without creating a Spanish referral route or changing Arabic fallbacks. Eleven GET search instances are not lead forms and must not be disabled or routed to Jotform. The five imported landing-page journeys—`/lp/aba-therapy`, `/lp/aba-insurance`, `/lp/aba-ahcccs`, `/lp/aba-private-pay` and `/lp/early-intervention`—are owner-approved **Form A** isolated-test placements, each using fixed `formContext=landing&language=en`. This supersedes their earlier Form B mapping. Physical Form B is retired. The nine documented consultation routes are Form A isolated-test placements only; no production consultation placement is authorized. The five panels do not add five native form implementations, and Form A remains unavailable in normal, indexing-enabled and production-shaped artifacts. Tour's actual CTA currently goes to `/client-consultation`, a future Form A `consultation` destination. Its service list has no tour choice, so the Tour disposition remains an intake/operations decision, **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 — current disposition The connector supplied titles, IDs, enabled status, timestamps, labels and limited summaries—not a full Builder audit. Each gate must record the exact form ID when one exists, reviewer, date, sanitized evidence and disposition. A historical-form finding does not automatically pass a newly created blank form's gate. The Form A owner-confirmed portions are recorded below and in the CSV ledger; every unlisted portion remains pending. | 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 and inherited production recipients or defaults | 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 | For Form A only, JF-01 (field PHI protection), JF-04 (generic no-PHI notification, corrected fixed Reply-To, tested notification/autoresponder delivery, recipient access and no PDF attachment), JF-06 (no webhooks/integrations), and the corresponding privacy/access/retention portions of JF-07/OA-05 are owner-verified. JF-03 is partially verified for direct English/Spanish language handling and the conditional email requirement. JF-05 is partially verified for direct native thank-you behavior. JF-09 functional submission acceptance is owner-reported as complete for direct EN/ES and embedded English contact, Spanish contact and one ABA landing sample. The exact third embedded route remains to be recorded; that prevents treating the evidence as seven-route acceptance. JF-02 and the remaining portions of JF-03, JF-05, JF-07, JF-08 and JF-09—including seven-route accessibility, runtime/network privacy and release scope—remain pending. Read-only Builder review may complete other configuration portions; generic vendor documentation does not close a gate. The [CSV ledger](phase-9-jotform-verification-checklist-2026-10-18.csv) tracks the exact scope, remaining work and supplied complete roster. ## 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 | | isolated-test | Form A only: requires `PUBLIC_AIA_FORMS_MODE=isolated-test`, `PUBLIC_AIA_FORMS_ENVIRONMENT=isolated-test`, `PUBLIC_AIA_FORMS_ISOLATED_TEST_APPROVED=true`, `PUBLIC_AIA_FORMS_LIVE_APPROVED=false`, and `PUBLIC_ALLOW_INDEXING=false`. The frozen seven-route Form A allowlist is eligible under those gates. The separate nine-route consultation allowlist additionally requires `PUBLIC_AIA_FORMS_CONSULTATION_TEST_APPROVED=true`; it is never production-eligible. | | live | Form A only: `PUBLIC_AIA_FORMS_MODE=live`, `PUBLIC_AIA_FORMS_LIVE_APPROVED=true`, `PUBLIC_AIA_FORMS_ENVIRONMENT=production`, and `PUBLIC_AIA_FORM_A_PRODUCTION_APPROVED=true` are all required. The fixed seven-route allowlist, fixed origin/URLs, locale and context still apply. Missing/invalid values fail closed. `PUBLIC_ALLOW_INDEXING` is independent: it must be `true` for an indexing-enabled release but cannot enable Form A alone. Form C and all other lead surfaces remain off. | Off/mock output must not contain **new lead embed IDs/URLs or the historical `250727122848156` reference 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, keyboard/focus support and minimal permissions. The Form A adapter keeps a direct hosted-form fallback hidden without layout space, reveals it after a 15-second missing-load timeout, cancels that timeout on `load`/disposal, and exposes a localized `