Mauritius Application for Removal of a Limited Partnership from Register for the Purpose of Transferring its Registration to Another Country (Form S65.F LP4)

Candidate selection

GOV-4974 ("GovSchema Standard Research"). The prior cycle (GOV-4967, authoring the LP6 "Notice of Change of General Partner") disclosed that the LP4 removal-from-register form — a confirmed dead link (HTTP 404) since GOV-4911 — has been resurrected to HTTP 200 (55,979 bytes), not yet authored. This is the direct Limited Partnerships Act 2011 analogue of the already-authored mu/cbrd/limited-liability-partnership-removal-from-register (LLP8) schema, and the strongest disclosed banked candidate carried forward into this cycle: it is a re-linked, previously-dead form now confirmed live, rather than an unscreened batch item never independently byte-verified.

Reaching the live source

This cycle re-fetched CBRD's own downloadable-forms listing fresh (https://companies.govmu.org/cbrd/downloadable-forms/, HTTP 200, 185,260 bytes) via a plain unauthenticated curl, and confirmed the exact LP4 filename directly from the page's own raw HTML rather than reusing a banked guess:

https://companies.govmu.org/cbrd/wp-content/uploads/2025/08/APPLICATION-FOR-REMOVAL-OF-LIMITED-PARTNERSHIP-FROM-REGISTER-FOR-THE-PURPOSE-OF-TRANFERRING-ITS-REGISTRATION-TO-ANOTHER-COUNTRY_-LP4.pdf

(note the source's own filename typo, "TRANFERRING", carried verbatim from the live URL — not a transcription error introduced by this schema).

• 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, 55,979 bytes retrieved — exactly matching the byte count disclosed by the GOV-4967 cycle's live re-check.
• sha256 of the retrieved bytes: 6ac6b206d31a9fea6175ff591f2baa950a620ede2042de861d57c2ac9cedd222.
• 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 74 positioned text items — a genuine text layer, with every printed label and blank-line dot-leader run recovered cleanly.

Authority attribution

The form's own header ("LIMITED PARTNERSHIPS ACT 2011", "(Section 65)", form code "S65.F LP4") 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 positional text-layer dump (each item's string plus x/y transform coordinates) reconstructed the form's row structure — the same method used on every prior CBRD sibling. Because the "Enclosed herewith:" block's exact widget type (checkbox vs. plain lettered list) was not determinable from text alone, a supplementary canvas render (node-canvas, 2.5x scale) was produced. The render dropped every glyph via the same Helvetica path-resolution warning documented in this registry's gov-form-pdf-extraction practice note (visible in this document's own render as a garbled "Iaa" artifact over the "FOR OFFICE USE" shaded header box), but the vector box/line graphics rendered cleanly. A programmatic zero-dark-pixel scan of the full interior region between the identification/transfer boxes (image y≈700) and the signature grid (image y≈1450) confirmed no checkbox squares or other fillable-widget graphics anywhere in the "Enclosed herewith" area — a genuine structural difference from the LLP8 sibling, whose own canvas render confirmed three visible checkbox squares in the equivalent region. See "Document structure" below for how this difference is modelled.

Document structure

Page 1 (single page):

• Header: "FOR OFFICE USE" (shaded label, rendered as a garbled glyph artifact per the extraction note above) over a "Document Folio" box (officer-only, not modelled) | "S65.F LP4" / "LIMITED PARTNERSHIPS ACT 2011" (printed form reference codes, not fillable).
• Title block: "TRANSFER OF REGISTRATION" (a kicker heading not present on the LLP8 sibling's own title block) / "APPLICATION FOR REMOVAL OF LIMITED PARTNERSHIP FROM REGISTER FOR THE PURPOSE OF TRANSFERRING ITS REGISTRATION TO ANOTHER COUNTRY" / "(Section 65)" — static, not modelled.
• Existing-LP identification block: "Name of Limited Partnership" (single-ruled-line box), followed by two small bordered boxes side by side — "Category" (left, x≈52) and "Registered No." (right, x≈274). The same side-by-side two-box pattern and label order already established by the LLP8 sibling, distinct from the LP7 sibling's own stacked layout and the LP6 sibling's own abbreviated "LP No." label.
• Transfer-details block: "Proposed jurisdiction of transfer" — a third, centered bordered box beneath the Category/Registered No. boxes, confirmed via the canvas render. Identical field to the LLP8 sibling's own transfer-details block.
• Enclosed-documents block: "Enclosed herewith:" followed by three lettered items — "(a) Documentary evidence as required under section 65 (a), (b) and (d) of the Act.", "(b) Written confirmation from MRA/Financial Services Commission that there is no objection to the Limited Partnership being removed from the register.", and "(c) Public Notice under Section 67". Two genuine structural differences from the LLP8 sibling's own equivalent block: (1) no checkbox graphics are printed anywhere in this section (confirmed by the zero-dark-pixel scan described above) — this form's three items are a plain lettered checklist, not tickable widgets, so they are modelled as documents[] entries (category supporting-evidence) rather than boolean fields[], following this registry's established non-fillable-checklist convention (e.g. the Thailand MFA visa schema's own page-1 checklist); and (2) item (b) merges what the LLP8 sibling models as two separate checkboxes (an unconditional MRA confirmation and a conditional FSC confirmation, gated on holding a Category One Global Business License) into a single unconditional "MRA/Financial Services Commission" confirmation, with item (c) — "Public Notice under Section 67" — a wholly new third item with no LLP8 equivalent at all. All three documents are modelled required: the form states all three as a flat "Enclosed herewith" list with no conditional-language qualifier on any item (unlike LLP8's own explicitly conditional FSC item), so no requiredWhen gate is used.
• Declaration block: "General Partner (s)" heading (the same LP-Act terminology already established by the LP6/LP7 siblings, not "Partner (s)", the LLP-Act terminology used by LLP4/LLP5/LLP8), then "Full Name(s):" / "Signature(s):" column headers, followed by a four-row grid of blank dot-leader pairs, and "Date:…………………………" beneath the grid. Column order: "Full Name(s):" at x≈58 (left) then "Signature(s):" at x≈346 (right) — matching the LLP8 sibling's own column order, the reverse of the LP7 sibling's own Signature-before-Full-Name order. Modelled with generalPartner{n}FullName preceding generalPartner{n}Signature in both the fields array and the declaration step's field list, matching this form's own left-to-right column order.
• No "Presented By" block — confirmed absent by a substring search across all 74 extracted text items (no occurrence of "presented" anywhere on the page), the same absence already established by the LP7/LLP8 siblings. This form ends immediately after the four-row signature grid and the Date: line.
• No footer "Sheet ___ of ___" line or officer-only checkboxes were found on this form (unlike the LLP4/LLP5/LP5 siblings' footers) — confirmed by the same substring search and by visual inspection of the canvas render, which shows blank margin below the Date: line.

Conformance

No requiredWhen gates are used on fields[] or documents[] — every field is either unconditionally required, unconditionally optional (the General Partner 2-4 slots), or optional by the registry's established bounded-slot convention, and all three documents[] entries are unconditionally required per the source's own flat, unqualified "Enclosed herewith" list. An ephemeral, uncommitted Node script exercised:

• 1 valid scenario: all required fields supplied (nameOfLimitedPartnership, registeredNo, category, proposedJurisdictionOfTransfer, declarationDate, generalPartner1FullName, generalPartner1Signature), all optional fields omitted (General Partner slots 2-4).
• 1 valid scenario: all 11 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:

• This closes the LP4 removal-from-register form, the last item disclosed as a confirmed dead link since GOV-4911 and resurrected to HTTP 200 per the GOV-4967 cycle's live re-check. Mauritius remains at 4 of 6 verticals (a thirteenth schema within the already-open Business Formation vertical, not a new vertical).
• The GOV-4925-surfaced unscreened batch — NOTICE-OF-CHANGE-OF-PARTNER_LLP6.pdf, name-reservation (LP1, LLP3), annual return (LP3), and a Foundation change-of-name form — remains unscreened and is now the sole remaining disclosed backlog. 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.
• Consent of Manager and Notice of Change of Manager (LLP6 half of the LLP6 pair) remain the two genuine dead links (HTTP 404) on the Department's own hosting, not re-tested this cycle.

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