docs(forms): adopt new Jotform form architecture

www/reports/phase-9-jotform-implementation-plan-2026-10-18.md

@@ -1,6 +1,6 @@
 # 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).
+Date: **2026-10-18** · Plan version **1.2 revision 2026-10-21** · Governing contract: [P9-03-JF-2026-10-18 v1.2](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.
 
@@ -24,12 +24,14 @@ Current source-manifest construction confirmed nine eligible enquiry routes and
 
 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.
 
+The five imported landing-page journeys—`/lp/aba-therapy`, `/lp/aba-insurance`, `/lp/aba-ahcccs`, `/lp/aba-private-pay` and `/lp/early-intervention`—are accounted for as future Form B destinations. Their inactive consultation panels are not additional native form implementations and do not have Jotform IDs.
+
 ### 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.
+4. The older inventory knew no confirmed lead source. The supplied October 18 evidence preserves `250727122848156` as a **historical structural reference only**. The revised owner decision rejects cloning or repurposing it; it is 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.
@@ -78,7 +80,7 @@ Logical descriptor semantics: logical form key; supported locale set; reviewed a
 | 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 |
+| Live A, B or C configured with existing source `250727122848156` | Reject; an approved ID from a separately created blank form 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 |
@@ -91,38 +93,40 @@ Parent component preserves approved page design, explanatory text, iframe title,
 
 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
+## 4. Builder review and blank-form creation 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.
+Use [JF-01–09 and owner gates](phase-9-jotform-verification-checklist-2026-10-18.csv). All start Pending/Unverified. Verify the blank-form Builder settings in A/B before any synthetic test; no existing form is a source for inheritance. 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.
+Before any creation, approve an account process that creates exactly three disabled blank forms, prevents public access and live notifications, and records the new IDs only after the account owner confirms the forms are isolated. Configure minimum fields, PHI protection, generic notifications, confirmation behavior and no-forwarding settings explicitly. Do not copy/import fields, settings or submissions from existing forms. If safe isolation cannot be established, stop before creation.
 
 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.
 
+The owner separately reports that the existing `AIA Lead Generator | plain` form has had field PHI protection enabled, automatic email-template updates disabled, autoresponder content revised to exclude submitted PHI, Spanish autoresponder behavior checked, delivery tested and its generated PDF attachment removed. Treat this as owner-reported remediation only. It does not audit historical recipients, access, retention, other legacy forms or HIPAA compliance, and it does not make that form a source for A/B/C. No submissions or historical emails are to be retrieved in this planning document.
+
 ## 5. Independently authorizable batches
 
-### Batch A — Builder settings verification and final field approval
+### Batch A — Final form specifications
 
 - **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.
+- **Outputs:** versioned semantic field map, approved options/required flags, notification contract, eligibility/form decision, blank-form creation procedure, 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
+### Batch B — Create three blank Jotform forms
 
-- **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.
+- **Objective:** create exactly three purpose-built disabled forms from blank forms: A General Enquiries, B Service Consultations and C Professional Referral Initiation.
+- **Authorization:** explicit Jotform mutation permission naming the three forms, account owner, reviewers, environment, isolation steps, proposed settings and stopping conditions. The historical `250727122848156` form is not a source and must not be cloned or repurposed.
+- **Prerequisites:** Batch A field decisions; account/privacy owner available; approved test recipient roles; blank-form creation confirmed; no production form is edited.
+- **Systems:** new Jotform forms and sanitized provenance documents only. Preserve all 27 existing assets, including clinical, agreement, event and operational workflows.
+- **Acceptance:** record actual new IDs, blank-form provenance, protected fields, generic notification, no booking/child identifiers, no PHI forwarding, no Google integration, and no inherited recipients/conditions/attachments/redirects. JF-01–08 are verified for each new form.
+- **Stop:** new forms remain disabled and unembedded; no synthetic submissions unless Batch D is separately authorized.
 
 ### 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.
+- **Authorization:** explicit repository implementation scope; **no Jotform account mutation or external form requests**. Can begin independently of B after minimal fallback/form/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.
@@ -132,7 +136,7 @@ Review all default/hidden fields, protected flags, conditional routing, reply-to
 
 - **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.
+- **Prerequisites:** Three blank forms created and their configuration review recorded in B; 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.
 
@@ -141,7 +145,7 @@ Review all default/hidden fields, protected flags, conditional routing, reply-to
 - **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.
+- **Files/systems:** approved typed mapping, reviewed components/messages, tests and configuration documentation; no nginx/DNS/API changes. Isolated-test 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.
 
@@ -176,13 +180,13 @@ These are specifications for later tests, not test results or executable code ad
 | 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-12 | No booking, child identifiers, unapproved service/payment/location/claim inheritance in approved form 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`:
+After an authorized implementation batch, run sequentially from `www`:
 
 ```sh
 npm run check
@@ -207,9 +211,9 @@ Source changes require a newly named offline reconciliation using explicit final
 
 ## 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.
+First recommended authorized batch: **Batch A**, final blank-form specifications and owner field approval, using the now-complete owner-supplied 27-asset roster as historical context only. 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.
+Owner ledger OA-01–08 and JF-01–09 are all Pending/Unverified in the companion CSV. Pending facts include actual new-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, blank-form isolation and supported success signaling. No new production embed ID exists. Final field approval and creation of A/B/C 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.
 
@@ -220,3 +224,5 @@ Preflight branch/HEAD/index checked; three October 17 artifacts present; their c
 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.
+
+Decision revision, version 1.2, 2026-10-21: the owner superseded the working-copy proposal with three new blank Jotform forms. Batch A now finalizes specifications, Batch B creates the three disabled forms only after explicit mutation authorization, and later batches retain off/mock/live safeguards. The 27-form legacy roster and all existing workflows remain historical/operationally independent. No source components, tests, Jotform forms or production systems were changed.

www/reports/phase-9-jotform-integration-contract-2026-10-18.md

@@ -1,10 +1,10 @@
 # P9-03 Jotform integration contract
 
-**Contract ID:** P9-03-JF-2026-10-18 · **Version:** 1.1 · **Date:** 2026-10-18
+**Contract ID:** P9-03-JF-2026-10-18 · **Version:** 1.2 · **Decision revision:** 2026-10-21
 
 **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.
+This is the authoritative P9-03 planning contract for the owner decisions supplied on October 18 and revised on October 21. 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; version 1.2 supersedes the copy-based Form B proposal with three new blank forms without changing the three-form architecture or pending 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).
 
@@ -33,7 +33,8 @@ Evidence classes must remain distinct:
 - **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.
+- **Create three new forms from blank forms:** A General Enquiries, B Service Consultations and C Professional Referral Initiation. Do not clone or repurpose an existing operational form. The former proposal to use a working copy of **AIA Lead Generator | plain** is 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.
@@ -46,7 +47,7 @@ The user reports that all 27 assets were classified and ENABLED during the Octob
 | 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 | Selected structural source for a future authorized **copy**, never the original live embed |
+| 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 |
@@ -90,14 +91,22 @@ Classifications are the **owner-supplied planning categories**, not verified Jot
 
 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.
+`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.
 
-**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.
+**No production embed ID is assigned for A, B or C.** All four existing IDs above are evidence references only. The former source B ID must be rejected as a clone, working-copy or live mapping. Account slot availability is not creation permission; three new forms would provisionally mean 30/100, subject to actual account-limit verification.
+
+### Revised blank-form decision and legacy review
+
+The owner has selected **three purpose-built forms created from blank Jotform forms**. This avoids inheriting legacy fields, stale service/location/insurance language, conditional logic, recipients, attachments, redirects or other operational settings. The physical target is three forms, with one EN/ES multilingual configuration per form where Builder and runtime verification support it; separate language forms remain a fallback requiring approval.
+
+Each new form is to remain disabled during configuration, use minimum-necessary fields with PHI protection enabled by default, begin with built-in confirmation, and have 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. Proposed semantic field contracts
 
@@ -157,20 +166,22 @@ Cross-checked against F-001–F-009 in the local CSV, current source and eligibl
 
 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.
 
+The five imported landing-page journeys—`/lp/aba-therapy`, `/lp/aba-insurance`, `/lp/aba-ahcccs`, `/lp/aba-private-pay` and `/lp/early-intervention`—are all future Form B destinations. Their current consultation panels remain inactive; they do not add five native form implementations or new Jotform IDs.
+
 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.
+The connector supplied titles, IDs, enabled status, timestamps, labels and limited summaries—not a full Builder audit. Each gate must record the exact new-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.
 
 | 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-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 |
@@ -189,7 +200,7 @@ Suggested semantic setting: `PUBLIC_AIA_FORMS_MODE`, exact values `off`, `mock`,
 | 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.
+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.
 
@@ -214,11 +225,11 @@ No dynamic answer tags, PDFs or other submission attachments, respondent reply-t
 
 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
+## 9. Blank-form creation 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.
+No form creation or original mutation is authorized now. Batch B may create exactly three disabled blank forms only after explicit Jotform mutation authorization naming the forms, account, reviewers, environment and stopping conditions. The new forms must be configured from the approved minimum field contracts, with PHI protection and generic notification defaults reviewed before any synthetic submission. Do not clone, copy, import or repurpose an existing form, and never copy submissions.
 
-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 historical [cloning guide](https://www.jotform.com/help/27-how-to-clone-an-existing-form-from-your-account/) remains evidence for why the owner rejected inheritance: copied forms can carry email settings, recipients and workflow/thank-you behavior, with account-specific treatment of integrations and protection requiring verification. It is not an implementation path. The old source ID `250727122848156` remains reference-only and must be rejected by any future configuration validator. Account capacity does not establish creation permission.
 
 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.
 
@@ -232,7 +243,7 @@ All implementation approvals below are **Pending**. Organizational selection of
 |---|---|---|
 | 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-03 | Jotform account owner | JF-01–08, blank-form creation, actual new IDs/configuration and preservation of all existing forms |
 | 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 |
@@ -254,3 +265,5 @@ In addition to the specific references above, official guidance reviewed on Octo
 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.
+
+Version 1.2, 2026-10-21: records the owner's decision to create three new blank Jotform forms from scratch. Supersedes the earlier working-copy proposal for `250727122848156`; preserves that ID as historical reference evidence only. Adds the owner-reported legacy-form remediation summary, retains all existing workflows, changes Batch B and OA-03 to blank-form creation, and leaves JF-01–09 and all owner approvals Pending/Unverified. No Jotform access or mutation occurred during this documentation revision.

www/reports/phase-9-jotform-verification-checklist-2026-10-18.csv

@@ -2,7 +2,7 @@ gate_id,subject,verification_required,owner_role,evidence_source,status,approval
 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-04,Emails,"Notifications/autoresponders, recipient roles, subject/body/dynamic tags, attachments, reply-to, conditional routes, default IDs/links, inherited production recipients or defaults","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
@@ -10,10 +10,10 @@ JF-08,Embedding,"Approved HTTPS origin, hosted/iframe URLs, dimensions/mobile, s
 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-03,Jotform account owner,"JF-01–08, blank-form creation, actual new IDs/configuration and preservation of all existing forms",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
+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.2 section 3 lists all 27 unique IDs; individual roster no longer outstanding; new-form configuration and usage verification pending,Pending/Unverified,,Read-only metadata review authorization; no account mutation