iCIMS real-tenant validation

Companion to the Workday and Greenhouse validations. Validated the iCIMS engine against a live iCIMS candidate form — Cotiviti's "Senior Software Engineer (AI), US-Remote" (careers-cotiviti.icims.com/jobs/19357/...). Andrew created the iCIMS candidate account himself (new-site register + apply are one combined step); I never handled his credentials, filled a field, or submitted — pure read-only DOM inspection inside the content iframe.

What matched — the two HARDEST things validate ✅

iCIMS is the app's hardest base (nested iframes, ASP.NET-generated ids, table soup). Both risky parts hold up against the real tenant:

Concern	Real Cotiviti tenant	Our selector	Match
Content iframe	iframe#icims_content_iframe	ContentIframe[0] = "#icims_content_iframe"	✅
First name	input#PersonProfileFields.FirstName	input[id$='FirstName']	✅
Last name	input#PersonProfileFields.LastName	input[id$='LastName']	✅
Email	input#PersonProfileFields.Email (type=email)	input[id*='email' i] / input[type='email']	✅
Phone	input#-1_PersonProfileFields.PhoneNumber	input[id*='phone' i]	✅
Address (street)	input#-1_PersonProfileFields.AddressStreet1	input[id*='address' i] (DOM-first)	✅

The ends-with / substring philosophy the ScraperLab loop chose for iCIMS is vindicated — the real ids carry the FirstName/LastName/Email/Phone suffix tokens exactly as assumed.

Findings (coverage gaps, not broken selectors)

Unlike Workday (whose existing contact selectors were genuinely broken), iCIMS's existing fills work. The gaps are fields the engine doesn't yet reach:

1. Structured address is only half-filled. The engine fills AddressStreet1 but the real form also has separate -1_PersonProfileFields.AddressCity, AddressZip, AddressState (select), AddressCountry (select) — none of which the engine fills or has selectors for. The app has this data (intake city/state/zip/country); it just doesn't push it into iCIMS's structured address.
2. "How did you hear about us?" fails on iCIMS custom-field ids. The real control is <select id="rcf3048"> whose meaning lives ONLY in its <label for="rcf3048"> ("How did you hear about us?"). Our HowHeardSelect chain looks for id/name tokens (source/hearaboutus/howheard) or an aria-label — none present — so WW-38 how-heard won't resolve here. iCIMS's tenant-configurable questions all use opaque rcf<number> ids; matching them needs LABEL-driven resolution (find the control whose associated <label for> text matches), which the current CSS-selector chains can't express. Same applies to other custom questions (work-auth, consent, etc.).

Both gaps need new engine capability (more fills; a label→for→control resolver) AND can't be validated autonomously without typing into / submitting a real application (which the build never does), so they're filed as a follow-up rather than auto-implemented here.

Verdict

The scary parts of iCIMS — the nested content iframe and the generated contact ids — are correct against a real tenant. The gaps are additive coverage (structured address, label-driven custom questions), tracked as a follow-up.