Mauritius Notice of Change in Registered Particulars of a Limited Partnership (Form S22/F LP7)

Candidate selection

GOV-4932 ("GovSchema Standard Research"). The prior six CBRD Mauritius Business Formation cycles (GOV-4897/4904/4911/4918/4925) authored LLP1, the Foundation registration form, LLP2 Consent of Partner, LP Consent of General Partner, and LP5 (Notice of Change of Name), disclosing a shrinking backlog of confirmed-live companion/notice forms on each cycle's own VERIFICATION.md. The most recent disclosure (GOV-4925) left four items open — LLP4 (Notice of Change in Registered Office), LLP5 (Notice of Change of Name of a Limited Liability Partnership), LLP8 (Application for removal of Limited Liability Partnership from Register), and LP7 (Notice of Change in Registered Particulars) — plus a further unscreened batch surfaced that same cycle but not yet independently re-verified by any prior cycle (an LLP7 "Registered Particulars" notice distinct from this LP7, change-of-general-partner, change-of-manager/partner (LLP6), name-reservation (LP1, LLP3), annual return (LP3), and a Foundation change-of-name form).

This cycle re-fetched CBRD's own downloadable-forms listing (https://companies.govmu.org/cbrd/downloadable-forms/, HTTP 200) fresh via a live WebFetch rather than trusting the banked list, and confirmed LP7, LP4 (removal), LLP4, LLP7, and LLP8 are all still linked. LP7 was picked over its siblings because it is the most thoroughly re-verified item in the backlog (independently byte-confirmed on three separate cycles now: GOV-4911, GOV-4918, and this one, all returning the identical 47,636-byte document) and, as the direct Limited Partnerships Act 2011 analogue already flagged alongside LP5 in the GOV-4925 disclosure, is a natural next pick after last cycle's LP5.

Reaching the live source

https://companies.govmu.org/cbrd/wp-content/uploads/2025/08/NOTICE-OF-CHANGE-IN-REGISTERED-PARTICULARS_LP7.pdf

• Plain unauthenticated curl, no session/cookie state, no CAPTCHA/WAF challenge — same unauthenticated hosting pattern as every other CBRD form this registry has already modelled.
• HTTP 200, 47,636 bytes retrieved — byte-identical to the size disclosed on both prior cycles (GOV-4911, GOV-4918), and now also independently re-confirmed via a fresh curl -I HEAD request (content-length: 47636) and a full download.
• sha256 of the retrieved bytes: 2ce4d1b518009bf5d6541f7bcb894b79714f99487d557b7f9ca11af90ddfc578.
• 1 page, confirmed via pdfjs-dist's numPages.
• getAnnotations() returned 0 form-field annotations — not an interactive AcroForm, same as every sibling CBRD schema.
• getTextContent() returned 78 positioned text items — a genuine text layer, with every printed label and blank-line dot-leader run recovered cleanly. Items were sorted by descending y-coordinate (then x) and grouped into rows using a 1-point y-tolerance to reconstruct the form's exact top-to-bottom, left-to-right layout, disambiguating the two-column "Signatures" / "Full names" grid by each item's own x-position (signature column at x≈72, full-name column at x≈360).
• A supplementary canvas render (node-canvas, 2.5x scale) confirmed the box layout: a single wide box with one ruled line ("Name of Limited Partnership"), two small bordered boxes beneath it ("Registered No.", "Category"), then unboxed free-text ruled lines and the signature grid — no checkbox or undivided-box ambiguity anywhere on the page. The render dropped every glyph via a Helvetica path-resolution warning (a more severe instance of the known node-canvas font-substitution gap already documented in this registry's own gov-form-pdf-extraction practice note, distinct from the clean text-layer extraction that supplied every field label and position without ambiguity), so the render was used for layout/box confirmation only, not text confirmation.

Authority attribution

The form's own header ("THE LIMITED PARTNERSHIPS ACT 2011", "(Section 22)") and its hosting directly on the Corporate and Business Registration Department's own domain (companies.govmu.org/cbrd/, the same authority already attributed on every other CBRD schema in this registry) attribute authority to the Corporate and Business Registration Department (abbreviation CBRD) directly.

Extraction method

A single positional text-layer dump (sorted by descending y-coordinate, then x, grouped into rows using a y-tolerance) reconstructed the form's row structure — the same method used on every prior CBRD sibling. A supplementary canvas render (see above) confirmed the box/line layout where the text layer alone left ambiguity about box boundaries.

Document structure

Page 1 (single page):

• Header: "FOR OFFICE USE" (shaded label) | "S22." / "F LP7" (printed form reference codes, not fillable) | "Document Folio" (officer-only small box beneath it) — none modelled, same officer-only header pattern as every sibling CBRD schema.
• Title block: "THE LIMITED PARTNERSHIPS ACT 2011" / "NOTICE OF CHANGE IN REGISTERED PARTICULARS" / "(Section 22)" — static, not modelled.
• Existing-partnership identification block: "Name of Limited Partnership" (single-ruled-line box), followed by two small bordered boxes stacked vertically — "Registered No.", "Category". A genuine structural difference from the LP5 sibling: LP5 prints a third box, "Date of Registration", which this form does not print at all — confirmed both by the clean text-layer extraction (no "Date of Registration" string anywhere in the 78 extracted items) and the canvas render (only two small boxes visible beneath the name entry, not three). Both remaining boxes are modelled required, since the notice cannot be processed without identifying which registered Limited Partnership's particulars are changing.
• Change(s)-filed block: "The following change (s) in information stated in the declaration referred to in Section 11(1) or 19(2) (d) is/are filed with the Registrar:" followed by four blank ruled lines with no further structure (no per-item labels, no repeatable table) — modelled as a single free-text field (changesFiled) matching the form's own single logical entry spanning multiple ruled lines, the same convention used for other multi-line free-text blocks in this registry.
• Declaration block: "Date: ______", then "General Partner (s)" / "Signatures:" / "Full names:" column headers followed by a four-row grid of blank ruled-line pairs. A genuine structural difference from the LP5 sibling: LP5 prints only a single "Signature of general partner(s): ______" / "Name of general partner(s): ______" line pair with no "attach a separate sheet" boilerplate, whereas this form prints an explicit four-row grid for up to four general partners to sign directly on the page. Modelled using this registry's established bounded-slot convention (slot 1 required, slots 2-4 optional, no requiredWhen gate, since the source prints no count/checkbox field to gate on) — the same pattern already used for the LP1/LLP1 partner and manager grids.
• No "Presented By" block and no "(For office use)" fee/officer column — confirmed absent by a substring search across all 78 extracted text items (no occurrence of "presented" anywhere on the page), a further genuine structural difference from the LP5 sibling and every other CBRD Business Formation schema in this registry, all of which print a "Presented by:" section. This form ends immediately after the four-row signature grid.
• No footer "Sheet ___ of ___" line or checkboxes were found on this form (unlike the LP5 sibling's footer) — confirmed by the same substring search and by visual inspection of the canvas render, which shows blank margin below the signature grid.

Conformance

No requiredWhen gates are used — every field on this form is either unconditionally required (slot 1 of the identification and signature blocks) or unconditionally optional (slots 2-4 of the signature grid), unlike the either/or BRN/ID No. pattern on the Consent-family siblings, which this form does not print. An ephemeral, uncommitted Node script exercised:

• 1 valid scenario: all required fields supplied (nameOfLimitedPartnership, registeredNo, category, changesFiled, declarationDate, generalPartner1Signature, generalPartner1FullName), all four optional slot-2/3/4 fields omitted.
• 1 valid scenario: all 13 fields supplied (slots 2-4 filled in).
• 7 required-field-omission mutations (one per required field, each independently rejected as expected).
• 1 unknown-field-rejection mutation, rejected as expected.

Both node tools/validate.mjs and node tools/validate-ajv.mjs pass against the full registry with this schema included.

Scope and disclosed backlog

This schema does not model any of the other companion/notice forms on the same downloadable-forms listing:

• Their Limited Liability Partnership Act 2016 analogues, previously disclosed and re-confirmed still linked this cycle but not independently re-byte-verified: Notice of Change of Name of a Limited Liability Partnership (LLP5), Notice of Change in Registered Office (LLP4), Application for removal of Limited Liability Partnership from Register (LLP8). Left open, disclosed backlog.
• Consent of Manager (LLP2 sibling form) and Application for Removal of Limited Partnership from Register (LP4) remain the two genuine dead links (HTTP 404) on the Department's own hosting first disclosed on the GOV-4911 cycle, not re-tested this cycle.
• Surfaced on the GOV-4925 cycle, not yet independently re-verified by any cycle since: NOTICE-OF-CHANGE-IN-REGISTERED-PARTICULARS_LLP7.pdf (an LLP-family "Registered Particulars" notice distinct from this LP7 — the listing page reuses "LP7" and "LLP7" as separate form codes, easy to conflate), NOTICE-OF-CHANGE-OF-GENERAL-PARTNER_LP.pdf, NOTICE-OF-CHANGE-OF-MANAGER_LLP6.pdf, NOTICE-OF-CHANGE-OF-PARTNER_LLP6.pdf, APPLICATION-FOR-RESERVATION-OF-LIMITED-PARTNERSHIP-NAME_LP1.pdf, RESERVATION-OF-NAME-LLP_LLP3.pdf, Annual-Return_LP3.pdf, and APPLICATION-TO-CHANGE-NAME-OF-A-FOUNDATION.pdf. None of these have been fetched or byte-verified since first surfaced; flagged here so a future cycle re-scans the listing page directly rather than relying on this write-up alone.

Full company incorporation itself remains out of scope (login-gated CBRIS portal, no static equivalent, per every prior CBRD schema's own disclosed scope).