Compliance N161
Validation Checks by Instafill.ai
1
Validates core case identifiers are present and correctly formatted (Claim/Case No., Appeal Court Ref No., Date Filed)
Checks that the Claim or case number is provided and matches an allowed pattern (letters/numbers plus permitted separators such as dashes or slashes) and is not just whitespace. If an Appeal Court Reference Number is provided (often court-use), it must also match the same character constraints and length limits to prevent invalid references. Validates Date Filed is a real calendar date in an accepted format and is not in the future. If any of these fail, the submission should be rejected or routed to manual review because the court cannot reliably match the notice to the correct case.
2
Ensures exactly one party-role group is selected for the Claimant/Applicant/Petitioner section and names are supplied accordingly
Validates that at least one of Claimant(s), Applicant(s), or Petitioner(s) is selected, and prevents contradictory or ambiguous selections if the business rule requires a single role (or, if multiple are allowed, ensures the names field clearly covers all selected roles). If any of these role checkboxes are selected, the Claimant/Applicant/Petitioner name(s) field must be populated with at least one full name and must not contain placeholder text (e.g., 'N/A'). This is important because the appeal record must reflect the correct procedural role(s) from the originating proceedings. If validation fails, the form should not be accepted because the parties cannot be correctly identified.
3
Ensures exactly one party-role group is selected for the Defendant/Respondent section and names are supplied accordingly
Checks that at least one of Defendant(s) or Respondent(s) is selected and that the Name(s) of Defendant(s)/Respondent(s) is completed when a role is selected. Validates the names field supports multiple parties (e.g., comma-separated) and enforces reasonable length and character rules (no control characters, no purely numeric values). This matters because the appeal must be served on the correct respondent(s) and the court must know who is on the other side. If it fails, the submission should be blocked or flagged for correction before filing/serving.
4
Validates Appellant and Respondent contact blocks are complete and usable (name, address, postcode, email/phone)
Ensures Appellant name and address (including postcode) are present, and Respondent name and address (including postcode) are present, because these are essential for correspondence and service. Validates UK postcode format (allowing standard spacing variations) and rejects clearly invalid postcodes (e.g., too short/long or illegal character sequences). Also validates that at least one reliable contact method is provided for each party (e.g., phone or email), if required by the implementation, and that fields are not filled with placeholders. If validation fails, the system should prevent submission because the court and parties may be unable to contact or serve documents.
5
Validates telephone and fax number formats (UK/international) and prevents invalid characters
Checks that telephone and fax numbers contain only permitted characters (digits, spaces, parentheses, leading '+') and meet minimum/maximum length constraints to avoid unusable numbers. Where a fax number is provided, it must pass the same formatting rules; where it is blank, it should be accepted. This is important to ensure contact details can be used without manual correction and to reduce failed service/communication attempts. If validation fails, the user should be prompted to correct the number format before submission.
6
Validates email address format for all provided email fields (Appellant, Respondent, representatives)
Ensures any entered email address matches a practical email pattern (local@domain) and rejects common invalid inputs (missing '@', spaces, trailing punctuation). Also enforces length limits and normalizes case/whitespace to reduce bounce risk. This matters because courts and representatives may rely on email for correspondence and service where permitted. If validation fails, the system should block submission or require correction for any email field that is populated.
7
Validates 'From which court is the appeal being brought?' selection is consistent and location/specification fields are completed
Checks that exactly one origin court pathway is selected among County Court, Family Court, High Court, or Other (unless the form design explicitly allows multiple, in which case it must still be logically consistent). If County Court is selected, County Court location must be provided; if Family Court is selected, Family Court location must be provided; if Other is selected, the 'Other court (please specify)' text must be provided. If High Court is selected, at least one division (King’s Bench, Chancery, Family) should be selected where required by process. If this validation fails, the appeal may be routed to the wrong jurisdiction, so submission should be stopped until corrected.
8
Ensures exactly one Judge status is selected and Judge name is present
Validates that one (and only one) Judge status checkbox is selected (e.g., District Judge, Circuit Judge, Master, etc.) to avoid ambiguity about the decision-maker. Also requires the Judge name field to be completed with a plausible name (not empty, not purely numeric, within length limits). This is important because appeal routes and permission requirements can depend on the judge level and the court needs to identify the decision under appeal. If validation fails, the system should require correction before accepting the notice.
9
Validates decision date is a real date and logically consistent with filing date
Checks that the Date of decision is present and is a valid calendar date in an accepted format. Validates that the decision date is not after the Date Filed (if Date Filed is provided) and is not unreasonably far in the future/past based on system rules. This matters because appeal time limits are calculated from the decision date and incorrect dates can invalidate the filing. If validation fails, the submission should be blocked or flagged for urgent manual review.
10
Validates 'Previous appeal decision' Yes/No is answered and triggers additional document expectations where applicable
Ensures exactly one of 'Previous appeal decision - Yes' or 'No' is selected. If 'Yes' is selected, the system should require (or at least strongly prompt for) the supporting documents indicated in Section 13 for prior-appeal situations (copy of first order, reasons, and prior appellant’s notice) or require an entry in the 'document not supplied' table explaining absence. This is important because second appeals have additional procedural requirements and missing context can prevent listing or determination. If validation fails, the submission should be halted or routed to a deficiency workflow.
11
Validates legal representation branching logic for Appellant and Respondent representative details
If the Appellant is marked as legally represented, the representative’s name, address (with postcode), and at least one contact method (phone or email) must be provided; if not represented, those fields should be empty or ignored to prevent conflicting data. If the Respondent is marked as legally represented, the respondent representative details must be provided under the same completeness rules. This matters because service and correspondence may need to go to representatives and incorrect branching causes mis-service. If validation fails, the system should prompt the user to either complete the representative block or change the representation selection.
12
Validates representative type selection is consistent with 'legally represented' and is not contradictory
When 'Are you legally represented?' is Yes, validates that exactly one representative type is selected (solicitor vs direct access counsel conducting litigation vs direct access counsel hearings-only), unless the business rules allow multiple (in which case it must still be consistent). When 'legally represented' is No, these type checkboxes must not be selected. This is important because different representative types have different service and conduct-of-litigation implications. If validation fails, the system should block submission until the representation type is clarified.
13
Validates permission-to-appeal logic (need permission, granted/not granted, and Box A/Box B completion)
Checks that the user answers whether permission is needed, and if permission has been granted. If permission has been granted, Box A must be completed with the date of the order granting permission (valid date) and the name of the judge granting permission; if permission has not been granted, Box B must include the name of the person seeking permission. Also validates that the 'granted in part' follow-up (seek permission for refused grounds Yes/No) is only answered when permission is granted in part and is not contradictory. If validation fails, the appeal may be procedurally defective, so the system should prevent filing until corrected.
14
Validates timeliness and extension-of-time dependency (Section 5 vs Section 10 Part B and Section 11 evidence)
Ensures exactly one of 'lodged in time' Yes/No is selected. If 'not lodged in time' is selected, then Section 10 Part B (extension of time) must be selected and Section 11 must contain reasons for delay and steps taken, with a minimum content threshold to avoid blank/meaningless entries. This is important because late appeals generally require an extension application supported by evidence, and missing this can lead to immediate refusal. If validation fails, the system should block submission and direct the user to complete the required sections.
15
Validates Grounds of Appeal attachment confirmation and minimum content expectations
Requires the 'grounds of appeal are attached' confirmation to be checked and enforces that an attachment record exists (or, in systems without file upload, that the user has indicated the grounds are provided as a separate sheet). Optionally validates that the grounds are structured in numbered paragraphs (basic pattern check) if text is captured, or at least that the attachment is not empty/zero bytes. This matters because the appeal cannot proceed without grounds and the court needs them to assess permission and case management. If validation fails, the submission should be rejected as incomplete.
16
Validates Section 9 relief sought is selected and 'vary/substitute order' text is provided when required
Checks that at least one outcome is selected in Section 9 (set aside, vary/substitute, or new trial). If 'vary the order and substitute' is selected, the substitute order text must be provided and must meet a minimum length/clarity threshold (not just 'see attached' unless attachments are explicitly supported for that field). This is important because the appeal court must know what order is being requested to manage the appeal and draft directions. If validation fails, the system should require the user to specify the relief sought before submission.