aia-website/www/reports/phase-9-form-a-jotform-runtime-verification-2026-10-25.md

# P9-03 Form A — Jotform field-key and multilingual runtime verification

**Recorded:** 2026-10-25 · **Scope:** Form A only · **Evidence:** owner-reported Builder screenshots and manual browser checks, with form identity corroborated by the connected Jotform form metadata.  
**Status:** partial configuration/runtime verification; **not approved for production embedding, submissions, or analytics**.

This report adds implementation evidence to [P9-03 integration plan](phase-9-jotform-implementation-plan-2026-10-18.md) and [contract v1.2](phase-9-jotform-integration-contract-2026-10-18.md). It does not change the approved three-form architecture, close any JF/OA gate, or amend historical inventory evidence. No submitted answers or PHI were inspected.

## Form identity and availability

- New blank-built form: **AIA | Website | General Enquiries**; Jotform form ID `262946078314059`.
- Builder: `https://hipaa.jotform.com/build/262946078314059`.
- Hosted form: `https://form.jotform.com/262946078314059`.
- Form was **enabled temporarily for browser inspection**. This is not approval to collect public leads; its availability should be restricted/disabled outside authorized testing until notification, privacy, and acceptance gates are cleared. Do not infer current status from this dated report.
- The legacy `250727122848156` form remains historical reference only. **Forms B and C have no approved form IDs or embed destinations yet.**
- The four campaign landing pages remain **permanently assigned to Form B**. Any Form A compact rendition there is a temporary, non-submitting Astro review mock, not an authorized live Form A integration.

## Critical discovery: visible label is not the URL-prefill key

Jotform's **Build → select field → Advanced → Field Details → Unique Name** value governs URL prepopulation. The visible question label `formContext` did **not** imply its underlying unique name was `formContext`. Initially the field retained its generated default unique name, so `?formContext=contact` failed to override the `landing` default and did not show the contact message.

The owner set **Unique Name** explicitly to the case-sensitive value **`formContext`**. Subsequent browser inspection confirmed the contact-specific message became visible. This property must be independently inspected for every future context field; do not derive URL keys from question labels, numbers, internal HTML IDs, or semantic TypeScript names.

| Configuration | Current Form A specification |
|---|---|
| Label | `formContext` (not visible to visitors) |
| **Unique Name** | **`formContext` (case-sensitive, owner verified)** |
| Default value | `landing` |
| Required | No |
| Visibility | Hidden from visitors |
| PHI marking | Owner reports all Form A fields PHI-protected; verify any fields subsequently added before activation |
| Approved presentation keys | `contact`, `landing` only in initial Astro placement contract |
| Optional future conditional state | `inquiry`, existing Builder rule; not approved for an actual published placement |
| Security significance | Presentation hint only, not authorization or trusted attribution |

Use only controlled non-identifying literal contexts selected by Astro. Do **not** forward arbitrary page query parameters, UTM values, visitor details, clinical data, or raw referrers into Jotform. Values are client-modifiable; never authorize sensitive behavior based on them.

## Owner-verified browser behavior

| Check | Result reported on 2026-10-25 |
|---|---|
| Hosted `?formContext=landing` | Compact fields displayed; no message text area |
| Hosted `?formContext=contact` | Contact message **How Can We Help?** and its privacy sublabel displayed; enquiry category absent |
| Preferred Contact Method | Phone and Email radio choices present after correcting an unintentionally enabled *Hide Field* toggle |
| Preferred Contact Method = Email | Email Address becomes required; selecting Phone leaves Email Address optional; phone remains required |
| Español | Spanish language added to Form A; owner reports language presentation verified |

These are owner-reported interactive checks, **not verified accepted submissions**, delivered email tests, or comprehensive translation/accessibility certification. In particular, the complete validation-message/confirmation translations and iframe-specific locale behavior still require acceptance testing.

The **How Can We Help?** label was shortened to that exact question, while its field sublabel now reads: “Please do not include medical details, diagnoses, insurance member identifiers, or other sensitive information.” The sublabel travels with the conditionally displayed message field. The condition is **SHOW** the message when `formContext = contact` **OR** the optional enquiry-category selection is `General Question`. Enquiry-category visibility is restricted to the unapproved `inquiry` context. Keep both independently verified during future condition edits.

## Honeypot, style and nonproduction notes

- Separate field `websiteCheck` was created for a basic, hidden, optional, empty honeypot. Builder conditions visibly show **IF websiteCheck IS FILLED → DISABLE Submit**. This is not proof of server-side spam rejection, nor a replacement for vendor anti-abuse protections. Confirm the field's precise unique name, hidden status and PHI classification before live acceptance.
- The owner installed form-specific Jotform Custom CSS and visually confirmed cream-colored inputs and AIA orange Submit button. Exact live selectors and style equivalence to Astro still need comparison; CSS cannot style a cross-origin iframe from Astro's parent document.
- A locally generated `www/integrations/jotform/README.md` and `aia-form-a.css` were **not present on the pushed `faithful-astro-migration` branch at the time this report was authored**. Do not recreate or overwrite those Codex-owned uncommitted files through this PR. When they are committed, reconcile this verified `formContext` unique-name requirement and the actual installed CSS with that README.

## Future Forms B and C — explicit prefill contract required

For any page/placement/service-context field added to Forms B or C, record and manually verify **all** of the following before authorizing live embedding:

1. The exact Jotform form ID and Builder field label.
2. The exact, **case-sensitive** `Advanced → Field Details → Unique Name` value (do not guess).
3. Allowed fixed, non-identifying URL-prefill values and the value for missing/invalid context.
4. Required/hidden/default/PHI behavior and effects of **Clear Hidden Field Values**.
5. Show/hide/require conditions, their precedence, and no accidental hiding of required contact fields.
6. Browser proof for each intended context and EN/ES locale, both direct hosted and iframe.
7. Compatibility with honeypot and Submit-button behavior; no untrusted UTM/source forwarding.

The values for B and C are **TBD**, not automatically `formContext`. The URL parameter for Form A is verified; applying that convention to another form requires its own Builder unique-name inspection.

## Still pending

JF-01–JF-09 and owner-approval gates remain open until their **full scopes** are verified, including the actual notification recipients/content/attachments/reply-to, bilingual autoresponders and confirmations, third-party integrations/webhooks, security and retention settings, accepted synthetic submissions, honeypot behavior, iframe height/focus/mobile behavior, and clinical/privacy/release approval.

**No real PHI, live production embed, production tracking, or Jotform submission is authorized by this documentation update.**