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 and contract v1.2. 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:

The exact Jotform form ID and Builder field label.
The exact, case-sensitive Advanced → Field Details → Unique Name value (do not guess).
Allowed fixed, non-identifying URL-prefill values and the value for missing/invalid context.
Required/hidden/default/PHI behavior and effects of Clear Hidden Field Values.
Show/hide/require conditions, their precedence, and no accidental hiding of required contact fields.
Browser proof for each intended context and EN/ES locale, both direct hosted and iframe.
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.

7.5 KiB Raw Permalink Blame History Unescape Escape