Compliance Form 866 (Protection visa)
Validation Checks by Instafill.ai
1
Validates total number of people included is a positive integer and matches provided person sections
Checks that 'Number of people included in this application' is a whole number greater than or equal to 1 (must include the main applicant). It also verifies that the count aligns with the number of populated person records (e.g., Other person 1/2 and additional member blocks like m.* 3-6, dependants, newborns) and that no extra person blocks are filled beyond the declared total. This prevents missing applicants/dependants or accidental inclusion of unintended people. If the validation fails, the submission should be blocked and the user prompted to correct the count or complete/remove person entries.
2
Ensures main applicant name fields are complete and contain only valid characters
Validates that the main applicant 'Family name' and 'Given names' are not blank, are within reasonable length limits, and do not contain invalid characters (e.g., digits-only, control characters, or excessive punctuation). Names should allow common legal-name characters such as letters, spaces, hyphens, and apostrophes. This is important for identity matching against passports/birth certificates and downstream record creation. If invalid, the form should require correction before acceptance.
3
Enforces single selection for sex fields per person (mutual exclusivity)
Checks that exactly one sex option is selected for each person (Male/Female/Indeterminate-Intersex-Unspecified) and that multiple boxes are not checked simultaneously. It also flags cases where none are selected when the person record is otherwise populated. This ensures consistent demographic data and avoids contradictory entries. If the validation fails, the user must select one option or correct conflicting selections.
4
Validates date of birth format and plausibility for all persons
Ensures each date of birth is a valid calendar date in the expected format and is not in the future. It also applies plausibility bounds (e.g., not older than a configured maximum such as 120 years) and requires DOB when a person’s name is provided. This reduces data entry errors and supports eligibility/identity checks. If invalid, the system should reject the submission or require correction for the affected person.
5
Validates birthplace fields completeness and country normalization
Checks that place of birth town/city and country are provided for the main applicant and any other person records that are included, and that country values come from an approved list (or are normalized to standard country names/codes). It also flags placeholder values like 'Select' or empty strings. Accurate birthplace data is critical for identity verification and jurisdictional processing. If validation fails, the user must provide valid town/city and a recognized country.
6
Validates citizenship field presence and handles stateless rule
Ensures citizenship/nationality is provided for each included person and is not a placeholder (e.g., 'Select'). If the applicant indicates statelessness (by entering 'stateless' or equivalent), the system must require the previous country of citizenship as instructed. This is important for legal status assessment and document checks. If the rule fails, the submission should be blocked until citizenship information is corrected or completed.
7
Validates current country of residence and arrival date consistency
Checks that 'Current country of residence' is present and valid (not 'Select') and that 'Date you arrived in this country' is a valid date not in the future. It also verifies the arrival date is after the applicant’s date of birth and is logically consistent with residence history start dates if provided (e.g., ap.resi start date). This prevents impossible timelines and supports residency-based assessments. If inconsistent, the user must correct the country or date values.
8
Validates immigration/status code field is present and conforms to allowed pattern
Ensures 'Status in this country (code)' is provided and matches an allowed pattern (e.g., 1–10 characters, letters/numbers, no long free-text paragraphs). Optionally, it can validate against a configured set such as C/PR/TR/BRIDGING depending on program rules. This field drives eligibility and routing, so malformed values can break downstream logic. If validation fails, the system should prompt for a valid code/short status text.
9
Enforces relationship status selection rules and prevents contradictory statuses
Validates that at least one relationship status option is selected for the main applicant (and for each other person where relationship status is captured), and that mutually incompatible combinations are not selected together (e.g., 'Never married' with 'Married legally', or 'Widowed' with 'Engaged'). Where multiple selections are allowed by design, it should still flag logically conflicting pairs. This ensures consistent marital/relationship representation for legal and dependency determinations. If conflicts exist, the user must revise selections before submission.
10
Requires relationship event details when applicable (date/place/previous name)
If the relationship status is anything other than 'Never married or been in a de facto relationship', the system must require 'Date relationship status occurred' and 'Place relationship status occurred' and validate the date format. It should also require 'Previous name (if applicable)' to be either explicitly blank with a confirmation (e.g., checkbox) or provided when the status implies a likely name change (e.g., marriage), depending on business rules. These details support legal verification and identity history. If missing or invalid, the submission should be blocked and the missing fields highlighted.
11
Validates multiple current partners branching and required details
Ensures exactly one of 'Yes' or 'No' is selected for 'Do you currently have more than one partner?'. If 'Yes' is selected, 'Additional current partner — details' must be present and meet minimum content requirements (e.g., includes name and at least one identifying detail such as DOB or birthplace). If 'No' is selected, the additional partner details field must be empty to avoid contradictory data. If validation fails, the user must correct the selection or provide/remove the required details.
12
Validates 'other current relationship' branching for engaged/never-married scenarios
When relationship status is 'Engaged' or 'Never married or been in a de facto relationship', the form’s 'Other/current relationship details' Yes/No must be answered (mutually exclusive). If 'Yes' is selected, the narrative details field must be completed with sufficient information (e.g., other person’s name and relationship start timing). This prevents incomplete disclosures and ensures the correct follow-up processing. If the branching rules are not satisfied, the system should block submission until corrected.
13
Validates biological relationship Yes/No exclusivity and dependent explanation fields
For each 'Other person' record, checks that exactly one of 'biologically related: Yes' or 'No' is selected. If 'No' is selected, the 'Explain how they are related' field must be completed; if 'Yes' is selected, the 'Describe the precise biological relationship' field must be completed. This ensures relationship claims are supported and reduces ambiguity in dependency/eligibility decisions. If validation fails, the user must provide the required explanation or correct the selection.
14
Validates contact information formats (phone numbers and email) and conditional requirements
Validates phone components (country code, area code, number) and mobile number to contain only allowed characters and meet length constraints; it should also prevent impossible combinations (e.g., country code present but no number). For email, if 'ap.com email_yes' is selected, at least one email field (ap.email 1/2/3) must be present and match standard email format; if 'email_no' is selected, email fields should be empty. Correct contact data is essential for notifications and identity verification. If invalid, the system should require correction and may warn that processing could be delayed.
15
Validates document entries when document presence is marked 'Yes' (type/number/country/issue/expiry)
For each document block (ap1.doc through ap7.doc), if the corresponding doc_yes is selected, the system must require document type, document number, issuing country, date of issue, and (if applicable) date of expiry and place of issue. It must validate that issue/expiry dates are valid, that expiry is after issue, and that document numbers meet basic format/length rules (alphanumeric, no illegal characters). This prevents unusable identity documents and downstream verification failures. If validation fails, the submission should be blocked until document details are corrected.
16
Validates required declarations/consents checkboxes are all affirmed
Checks that mandatory declaration fields (e.g., ap.check1_yes through ap.check16_yes, and declaration name fields ap.dec name 1-7 where required) are completed according to the form’s rules. It should ensure no required declaration is left unchecked and that declaration names are not blank when a signature/name is required. These attestations are legally significant and often required to accept the application. If any required declaration is missing, the system must prevent submission and prompt the applicant to complete the declarations.