# Vercy AI instruction - YAML 1.2 (JSON-compatible) { "vercy": "1.0-draft", "publication": { "status": "published", "adjudicationStatus": "reviewable-draft", "publishableCanonical": false, "generatedAt": "2026-08-23T22:48:15Z", "synthesisSha256": "8e6a9b3302f0ca4f0b1c3f826bd5bd38361ed8f4b026cb02859f58d5dac99589", "providerMode": "dual-provider", "providers": [ "Claude", "Grok" ], "waivedProviders": [] }, "metaModel": { "id": "WM-ORG-010", "registryId": "vr.wm-org-010", "name": "Legal Entity Registration", "version": "0.3.0-research.1", "previousVersions": [], "entryKind": "entity", "family": "World Models", "category": "Society, people and institutions", "industry": [ "Cross-industry" ], "domain": [ "SOC.ORG.REG" ], "tags": [ "legal", "entity", "registration", "soc.org.reg" ], "status": "published" }, "canonicalUrl": "https://ver.cy/models/wm-org-010-legal-entity-registration/", "sourceUrl": "https://github.com/ver-cy/world-models/tree/feat/mega-model-registry/research/runs/wm-org-010", "model": { "registry_id": "vr.wm-org-010", "model_id": "WM-ORG-010", "name": "Legal Entity Registration", "entry_kind": "entity", "purpose": "Model the legal identity of an organization as constituted and recorded by an authoritative register or registration authority in a jurisdiction, so that an agent can identify, verify, monitor and operate on registered legal persons without conflating them with the organizations, groups or statistical units they relate to.", "scope_statement": "In scope is the registration record of a legal person (and of branches that carry their own register entries): the authoritative register and its assigned identifier, legal name and name history, legal form and jurisdiction of formation, registered addresses, registration and entity status, dated legal entity events including succession and dissolution, structural relationships as reported to registers, evidence and validation of those facts, cross-scheme identifier alignment, and the governance of the record (provenance, access tiers, retention, interoperability). Out of scope is anything that is a fact about the organization's operation, ownership content, finances or authorizations rather than about its registered legal existence.", "in_scope": [ "Authoritative register identity: registration authority, register-assigned entity identifier, and qualified alternate identifiers such as LEI, EUID and ISO/IEC 6523-scoped scheme identifiers", "Legal name, transliterations, trading and previous names with dated validity", "Entity legal form (ISO 20275 ELF) and jurisdiction of formation at country and subdivision level", "Registered/legal address, headquarters address and other addresses recorded by the register", "Registration status, entity status, status detail and compliance standing signals such as strike-off proposals and overdue filings", "Dated legal entity events: name change, legal form conversion, merger, division, spin-off, seat transfer, dissolution, liquidation, restoration, with effective and recorded dates", "Branch and establishment registration records and their head-office linkage", "Structural relationships as reported to registers: consolidating parents, branch/head-office, fund and feeder relationships, with validation level and reporting exceptions", "Evidence artifacts: certificates, dated register extracts, gazette notices, filings and their authentication", "Validation sources, corroboration levels, discrepancy detection and register correction processes", "Access tiers, licence conditions, personal-data handling, retention and deletion constraints on register records", "Interoperability mappings to external organization vocabularies and register-to-register exchange" ], "out_of_scope": [ "Internal organizational structure, units, posts, headcount and reporting lines (parent organization model)", "Beneficial ownership and control content, including natural-person particulars; only the linkage and access classification are in scope", "Financial statement content, accounting figures and audit opinions, even when filed with a register", "Sector authorizations, licences, permits and regulatory registrations that do not constitute legal existence", "Tax assessment, returns and fiscal compliance; only the fiscal identifier as an alternate identifier is in scope", "Statistical units (enterprise, enterprise group, local unit, kind-of-activity unit) and business demography", "Trademarks, brands and domain names", "Contracts, credit ratings, sanctions listings and adverse media", "Natural-person identity records and employment relationships", "Physical premises management, geocoding and facility operations" ], "boundary_notes": [ { "neighbor": "WM-ORG-001 Organization (parent model)", "distinction": "The parent models any organization, including informal, unregistered and purely internal ones. WM-ORG-010 models only the subset that has acquired or claims registered legal status, and only the facts that the register constitutes or records. W3C ORG makes the same cut with org:FormalOrganization, which RegOrg further narrows to rov:RegisteredOrganization for entities that gained legal entity status through formal registration.", "source_refs": [ "SRC-006", "SRC-007" ] }, { "neighbor": "Statistical business register unit model (enterprise, legal unit, enterprise group)", "distinction": "A legal unit is not an enterprise. Statistical frameworks define the enterprise as the smallest set of legal units with autonomy in financial and investment decisions, so a single enterprise may span several registered legal persons and a registered legal person may be only part of an enterprise. WM-ORG-010 stops at the registered legal unit and delegates statistical unit construction, demography and continuity rules elsewhere.", "source_refs": [ "SRC-016" ] }, { "neighbor": "Beneficial ownership register model", "distinction": "Beneficial ownership is held in a separate mechanism with a different legal basis and a materially different access regime; unrestricted public access to beneficial ownership data was struck down in the EU, whereas core company particulars remain publicly disclosable. Only the pointer, holding mechanism and access tier belong here.", "source_refs": [ "SRC-015", "SRC-018" ] }, { "neighbor": "Global LEI System (GLEIF/LEI issuers)", "distinction": "An LEI is a governed global identifier layered on top of a register record; GLEIF and its issuers are not registers of formation. LEI reference data explicitly cross-references the local business register through a registration-authority code and a local entity identifier, which confirms that the register, not the LEI, is the master identity source.", "source_refs": [ "SRC-002", "SRC-003" ] }, { "neighbor": "Tax registration and fiscal identifier model", "distinction": "Tax numbers, VAT numbers and employer identification numbers are usually assigned by a different authority under a different act; being on a business register does not imply tax registration and vice versa. They are carried here only as qualified alternate identifiers, scheme-tagged so they cannot be mistaken for the register identity.", "source_refs": [ "SRC-013", "SRC-012" ] }, { "neighbor": "Branch / establishment as an organization site", "distinction": "A branch is not a separate legal person, but in many jurisdictions it holds its own register entry, identifier and disclosure duties, and LEI relationship data recognises IS_INTERNATIONAL_BRANCH_OF as a distinct relationship. Branch registration records are therefore in scope, while branch premises and operations are not.", "source_refs": [ "SRC-005", "SRC-008" ] }, { "neighbor": "Regulatory licence and authorization model", "distinction": "Authorization to carry on a regulated activity is granted by a supervisor and can be withdrawn without ending legal existence. Registration constitutes or records existence; licensing conditions conduct. Conflating them makes an entity appear dissolved when it has merely lost a permission.", "source_refs": [ "SRC-009", "SRC-008" ] }, { "neighbor": "Document and evidence model", "distinction": "Certificates, extracts and filings are modelled here only as evidence bound to registration facts, with issuer, as-of date and authentication. Generic document lifecycle, storage and rendering belong to a composable document model.", "source_refs": [ "SRC-010", "SRC-002" ] } ] }, "sources": [ { "id": "SRC-001", "title": "Level 1 Data: LEI-CDF Format — Common Data File Formats", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/en/about-lei/common-data-file-format/lei-cdf-format", "version_or_date": "LEI-CDF version 3.1 (May 2021); page accessed August 2026", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:05:00Z", "relevance": "Defines the operational field set for legal entity reference data: legal name, addresses, legal jurisdiction, legal form, entity category, registration authority, entity status, legal entity events, registration status and validation fields." }, { "id": "SRC-002", "title": "LEI-CDF Version 3.1 — Documentation", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/content/4_lei-data/1_access-and-use-lei-data/2_level-1-data-lei-cdf-3-1-format/lei-cdf_version_3.1-documentation.html", "version_or_date": "Version 3.1, May 2021", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:07:00Z", "relevance": "Field-level definitions and cardinalities used to ground data elements: RegistrationAuthorityID/RegistrationAuthorityEntityID, LegalJurisdiction, EntityCreationDate, EntityExpirationDate/Reason, SuccessorEntity, LegalEntityEvents with effective and recorded dates, InitialRegistrationDate, LastUpdateDate, ValidationSources." }, { "id": "SRC-003", "title": "GLEIF Registration Authorities List", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/en/lei-data/code-lists/gleif-registration-authorities-list", "version_or_date": "Version 1.8.1, November 2024", "source_type": "registry", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:09:00Z", "relevance": "Governed list of over 1,050 business registers and validation authorities across 232 jurisdictions, each with a code; establishes that the register plus local entity identifier is the authoritative cross-reference for legal entity identity." }, { "id": "SRC-004", "title": "ISO 20275 Entity Legal Forms (ELF) Code List", "organization": "Global Legal Entity Identifier Foundation (GLEIF), Maintenance Agency Secretariat for ISO/TC 68", "url": "https://www.gleif.org/en/lei-data/code-lists/iso-20275-entity-legal-forms-code-list", "version_or_date": "Version 1.6, February 2026", "source_type": "classifier", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:11:00Z", "relevance": "Four-character ELF codes for over 3,600 legal forms in more than 200 jurisdictions, in local language only, with reserved codes 8888 and 9999; grounds the interdependence of legal form and jurisdiction." }, { "id": "SRC-005", "title": "Level 2 Data: Relationship Record (RR) CDF Format", "organization": "Global Legal Entity Identifier Foundation (GLEIF)", "url": "https://www.gleif.org/en/about-lei/common-data-file-format/relationship-record-cdf-format", "version_or_date": "RR-CDF version 2.1, May 2021", "source_type": "schema", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:13:00Z", "relevance": "Relationship types (IS_DIRECTLY_CONSOLIDATED_BY, IS_ULTIMATELY_CONSOLIDATED_BY, IS_INTERNATIONAL_BRANCH_OF, fund relationships), relationship/accounting/document-filing periods, qualifiers and quantifiers, corroboration levels and reporting exceptions." }, { "id": "SRC-006", "title": "The Organization Ontology", "organization": "World Wide Web Consortium (W3C)", "url": "https://www.w3.org/TR/vocab-org/", "version_or_date": "W3C Recommendation, 16 January 2014", "source_type": "ontology", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:16:00Z", "relevance": "Distinguishes FormalOrganization (recognised in a legal jurisdiction) from OrganizationalUnit and OrganizationalCollaboration; supplies identifier, classification, sub-organization, site and ChangeEvent (originalOrganization/resultingOrganization) patterns for succession." }, { "id": "SRC-007", "title": "Registered Organization Vocabulary", "organization": "World Wide Web Consortium (W3C), from the European Commission ISA Core Business Vocabulary", "url": "https://www.w3.org/TR/vocab-regorg/", "version_or_date": "W3C Working Group Note, 1 August 2013", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:18:00Z", "relevance": "rov:RegisteredOrganization as a subclass of org:FormalOrganization, with legalName, orgType, orgStatus, orgActivity and a structured registration identifier; confirms that the registration identifier carries its own metadata rather than being a bare string." }, { "id": "SRC-008", "title": "Companies House Public Data API — company profile resource", "organization": "Companies House (United Kingdom)", "url": "https://developer-specs.company-information.service.gov.uk/companies-house-public-data-api/resources/companyprofile?v=latest", "version_or_date": "Latest published specification, accessed 24 August 2026", "source_type": "first-party-doc", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:22:00Z", "relevance": "A working national register's field set and code lists: company_status and company_status_detail, type and subtype, jurisdiction, date_of_creation and date_of_cessation, previous_company_names, registered_office_is_in_dispute, branch_company_details and foreign_company_details, confirmation_statement." }, { "id": "SRC-009", "title": "UNCITRAL Legislative Guide on Key Principles of a Business Registry", "organization": "United Nations Commission on International Trade Law (UNCITRAL)", "url": "https://uncitral.un.org/en/texts/msmes/legislativeguides/business_registry", "version_or_date": "Adopted 2018; published 2019", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:26:00Z", "relevance": "Normative guidance on registry objectives, unique business identifiers used across public authorities, non-discriminatory public access with limited confidentiality exceptions, low or zero fees, and interoperability with tax and social security registration." }, { "id": "SRC-010", "title": "Company law and corporate governance", "organization": "European Commission", "url": "https://commission.europa.eu/business-economy-euro/doing-business-eu/company-law-and-corporate-governance_en", "version_or_date": "Accessed 24 August 2026; covers Directive (EU) 2017/1132, Directive (EU) 2019/1151 and Directive (EU) 2025/25 (in force 30 January 2025)", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:30:00Z", "relevance": "Establishes compulsory disclosure through national registers, BRIS interconnection since June 2017, the EU Company Certificate as a cross-border corporate passport, digital-by-default and once-only principles for company law procedures." }, { "id": "SRC-011", "title": "ROC Policy on Level 1 Data — Legal Entity Events and Data History in the Global LEI System", "organization": "Legal Entity Identifier Regulatory Oversight Committee (LEI ROC), published via GLEIF", "url": "https://www.gleif.org/en/lei-data/access-and-use-lei-data/level-1-data-who-is-who/roc-policy-on-level-1-data", "version_or_date": "Policy issued 28 March 2018, final 30 October 2018; General Government Entities guidance December 2020", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:33:00Z", "relevance": "Public-authority policy defining legal entity events (formerly corporate actions) that alter entity or relationship data or retire and create identifiers, prioritising name changes, mergers and acquisitions, and adding RESIDENT GOVERNMENT ENTITY and INTERNATIONAL ORGANIZATION categories alongside FUND, BRANCH and SOLE_PROPRIETOR." }, { "id": "SRC-012", "title": "Organization — schema.org type", "organization": "Schema.org Community Group (W3C)", "url": "https://schema.org/Organization", "version_or_date": "Version 30.0, 2026-03-19", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:36:00Z", "relevance": "Widely deployed interoperability target with legalName, leiCode (ISO 17442), iso6523Code in XXXX:YYYYYY:ZZZ form, taxID, vatID, duns, globalLocationNumber, naics, foundingDate, dissolutionDate, parentOrganization and subOrganization." }, { "id": "SRC-013", "title": "ISO 6523 ICD code list — Peppol BIS Billing 3.0", "organization": "OpenPeppol", "url": "https://docs.peppol.eu/poacc/billing/3.0/codelist/ICD/", "version_or_date": "Peppol BIS Billing 3.0, May 2026 release", "source_type": "registry", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T09:39:00Z", "relevance": "Operational list of over 240 ISO/IEC 6523 International Code Designators used to qualify organization identifiers in electronic documents (0060 D-U-N-S, 0088 GLN, 0199 LEI, 0208 Belgian enterprise number, national register and tax schemes); demonstrates that an organization identifier is meaningless without its scheme." }, { "id": "SRC-014", "title": "Commission Implementing Regulation (EU) 2021/1042 laying down rules for the application of Directive (EU) 2017/1132 as regards technical specifications and procedures for the system of interconnection of registers", "organization": "European Union (Official Journal, via EUR-Lex)", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32021R1042", "version_or_date": "18 June 2021, OJ L 225", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:42:00Z", "relevance": "Names the EUID as the unique identifier for communication between registers and prescribes service-based electronic communication, HTTPS transport and standard protocols for structured data and metadata exchange across BRIS. Full text could not be retrieved by automated fetch; grounding rests on the published title and quoted provisions, and this is recorded as an evidence gap." }, { "id": "SRC-015", "title": "Press release No 188/22 — Judgment of the Court in Joined Cases C-37/20 and C-601/20, WM and Sovim SA v Luxembourg Business Registers", "organization": "Court of Justice of the European Union", "url": "https://curia.europa.eu/site/upload/docs/application/pdf/2022-11/cp220188en.pdf", "version_or_date": "22 November 2022", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:45:00Z", "relevance": "Invalidates general public access to beneficial ownership information as neither limited to what is strictly necessary nor proportionate; the decisive counterexample against treating all register-adjacent data as uniformly public." }, { "id": "SRC-016", "title": "Guidelines on Statistical Business Registers", "organization": "United Nations Economic Commission for Europe (UNECE), Conference of European Statisticians", "url": "https://www.unece.org/fileadmin/DAM/stats/publications/2015/ECE_CES_39_WEB.pdf", "version_or_date": "Endorsed June 2015, published August 2015 (ECE/CES/39)", "source_type": "scientific", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:48:00Z", "relevance": "Defines the enterprise as a legal unit or smallest set of legal units with autonomy in financial and investment decisions, and the enterprise group as legal units under common control; supplies the boundary between registered legal units and statistical units." }, { "id": "SRC-017", "title": "Beneficial Ownership Information Reporting", "organization": "Financial Crimes Enforcement Network (FinCEN), U.S. Department of the Treasury", "url": "https://www.fincen.gov/boi", "version_or_date": "Accessed 24 August 2026; reflects the interim final rule effective 26 March 2025", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:51:00Z", "relevance": "Current scope of U.S. beneficial ownership reporting after the definition of reporting company was narrowed to entities formed under foreign law and registered to do business in a U.S. state or Tribal jurisdiction; evidence that register-adjacent obligations are volatile and must be version-dated." }, { "id": "SRC-018", "title": "Guidance on Beneficial Ownership of Legal Persons (Recommendation 24)", "organization": "Financial Action Task Force (FATF)", "url": "https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Guidance-Beneficial-Ownership-Legal-Persons.html", "version_or_date": "March 2023, following the March 2022 revision of Recommendation 24", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T09:54:00Z", "relevance": "International standard requiring adequate, accurate and up-to-date basic and beneficial ownership information, held by a registry or an alternative mechanism, with a multi-pronged approach. Direct fetch returned HTTP 403; grounding rests on the published title and FATF summaries, recorded as an evidence gap." }, { "id": "SRC-019", "title": "CJEU — C-398/15 — Manni (case analysis)", "organization": "GDPRhub (noyb-supported case-law wiki)", "url": "https://gdprhub.eu/index.php?title=CJEU_-_C-398/15_-_Manni", "version_or_date": "Judgment of 9 March 2017; analysis accessed 24 August 2026", "source_type": "secondary", "primary_source": false, "authority_tier": 3, "accessed_at": "2026-08-24T09:57:00Z", "relevance": "Secondary summary used only to surface the retention counterexample: no general right to erasure from a companies register even after the company ceases to exist, because no suitable maximum retention period can be identified, but a case-by-case right to object may apply." }, { "id": "SRC-020", "title": "ISO 17442-1:2020 Financial services — Legal entity identifier (LEI) — Part 1: Assignment", "organization": "International Organization for Standardization", "url": "https://www.iso.org/standard/78829.html", "version_or_date": "2020-08; confirmed 2026-01-21 (stage 90.93)", "source_type": "standard", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "Defines the eligible legal-entity population, the 20-character LEI, and the minimum identification scheme for parties that can enter contracts or bear financial responsibility, including governmental bodies, supranationals, international branches and individuals acting in a business capacity, excluding natural persons in a private capacity." }, { "id": "SRC-021", "title": "LEI-CDF Version 3.1 documentation and Level 1 Data: LEI-CDF Format 3.1", "organization": "Global Legal Entity Identifier Foundation", "url": "https://www.gleif.org/en/lei-data/access-and-use-lei-data/level-1-data-lei-cdf-3-1-format", "version_or_date": "LEI-CDF 3.1 (May 2021); documentation last updated 2021-03-04; business rules referenced 2025-07-03 v2.8.5", "source_type": "schema", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "Operationalises ISO 17442 attributes as Level 1 reference data: legal name, registration authority and entity ID, legal form, legal jurisdiction, legal and headquarters addresses, entity status, creation and expiration, legal-entity event effective dates, and LEI registration status, validation and update metadata." }, { "id": "SRC-022", "title": "Directive (EU) 2017/1132 relating to certain aspects of company law (codified, consolidated)", "organization": "European Parliament and Council of the European Union", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:02017L1132-20220812", "version_or_date": "Consolidated 2022-08-12; ELI http://data.europa.eu/eli/dir/2017/1132/2022-08-12", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "Normative EU rules on incorporation disclosure, the companies register file, European unique identifier (EUID), registered office, constituting instruments, persons authorised to bind, winding-up, nullity, liquidators, branches, online procedures and the Business Registers Interconnection System (BRIS)." }, { "id": "SRC-023", "title": "The FATF Recommendations — Recommendation 24 and Interpretive Note (Transparency and beneficial ownership of legal persons)", "organization": "Financial Action Task Force", "url": "https://www.fatf-gafi.org/en/publications/Fatfrecommendations/Fatf-recommendations.html", "version_or_date": "Adopted February 2012; updated June 2026", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "Requires company registration, a published basic-information set, a multi-pronged beneficial-ownership mechanism, controls on bearer shares and nominees, competent-authority access, and at least five-year retention after dissolution." }, { "id": "SRC-024", "title": "UNCITRAL Legislative Guide on Limited Liability Enterprises", "organization": "United Nations Commission on International Trade Law", "url": "https://uncitral.un.org/sites/uncitral.un.org/files/media-documents/uncitral/en/22-01230_final_ebook-corr.pdf", "version_or_date": "Adopted 2021; United Nations publication 2022, Sales No. E.22.V.21", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "Recommends distinct legal personality, limited liability, constitutive registration (the LLE is formed once registered), minimum formation particulars, identity and visibility through a business registry, conversion/restructuring and dissolution, and points to the 2018 UNCITRAL Guide on Key Principles of a Business Registry." }, { "id": "SRC-025", "title": "Global LEI System", "organization": "Legal Entity Identifier Regulatory Oversight Committee", "url": "https://www.leiroc.org/lei.htm", "version_or_date": "Page describing GLEIS governance; ISO 17442 originally 30 May 2012; accessed 2026-08-24", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "Defines GLEIS governance (ROC, GLEIF, Local Operating Units), the 20-character LEI structure, uniqueness, and the right to port an LEI between operators without changing the code." }, { "id": "SRC-026", "title": "UNCITRAL Legislative Guide on Insolvency Law", "organization": "United Nations Commission on International Trade Law", "url": "https://uncitral.un.org/en/node/823", "version_or_date": "Parts one and two 25 June 2004; subsequent parts 2010–2021", "source_type": "public-authority", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "States that a corporation obtains legal personality by a legal process, enjoys perpetuity independent of members, and that liquidation of a commercial legal entity usually results in its dissolution." }, { "id": "SRC-027", "title": "Commission Implementing Regulation (EU) 2020/2244 laying down technical specifications and procedures for the system of interconnection of registers", "organization": "European Commission", "url": "https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L:2020:439:FULL", "version_or_date": "OJ L 439, 29.12.2020", "source_type": "legislation", "primary_source": true, "authority_tier": 1, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "Specifies BRIS message exchange, EUID as the unique identifier of the company, and Alternate ID including Legal Entity Identifier for cross-register notifications such as branch disclosure." }, { "id": "SRC-028", "title": "GLEIF Base Ontology", "organization": "Global Legal Entity Identifier Foundation", "url": "https://www.gleif.org/ontology/Base/", "version_or_date": "Ontology IRI https://www.gleif.org/ontology/Base/; page dated 2022-04-20", "source_type": "ontology", "primary_source": true, "authority_tier": 2, "accessed_at": "2026-08-24T16:00:00Z", "relevance": "Formalises EntityStatus, EntityExpirationReason (corporate action, dissolved, other) and RegistrationAuthority as first-party semantics for legal-entity registration records." } ], "structure": { "bundles": [ { "id": "legal-identity-and-designation", "name": "Legal identity and designation", "description": "What the registered legal person is called, how it is identified across schemes, and how it is classified by legal form and activity.", "rationale": "Every other bundle attaches to a resolved identity. Reference-data standards converge on the same minimum: official name as recorded in official registers, legal form, and country of formation, cross-referenced to the local register identifier. Getting this layer wrong makes all downstream assertions unattributable.", "source_refs": [ "SRC-001", "SRC-002", "SRC-004", "SRC-006", "SRC-007", "SRC-012" ], "layers": [ { "id": "identity-and-identifiers", "name": "Identity and identifiers", "description": "The authoritative register-assigned identity and the qualified alternate identifiers that denote the same legal person.", "source_refs": [ "SRC-002", "SRC-003", "SRC-012", "SRC-013" ], "findings": [ { "id": "register-anchored-legal-entity-identity", "name": "Register-anchored legal entity identity", "description": "The master identity of the registered legal person is the pair (registration authority, identifier assigned by that authority). Locally assigned surrogate keys are subordinate and must be flagged as such. LEI reference data models this explicitly as RegistrationAuthorityID plus RegistrationAuthorityEntityID, and the governed authority list exists precisely because a bare registration number is ambiguous across 232 jurisdictions.", "source_refs": [ "SRC-002", "SRC-003", "SRC-007", "SRC-009" ], "questions": [ { "id": "which-register-and-identifier", "text": "Which register or registration authority holds the authoritative record for this entity, and what identifier does it assign?", "kind": "identity", "answer_data": [ "Registration authority code from a governed authority list, with list version", "Register-assigned entity identifier as recorded, byte-exact", "Register name in local and international form", "Jurisdiction of the register" ] }, { "id": "identifier-stability-and-reuse", "text": "Is the register-assigned identifier stable, reused after dissolution, or changed on conversion or migration?", "kind": "identity", "answer_data": [ "Identifier stability and reuse policy of the register", "Prior identifiers with validity intervals", "Trigger events that cause reassignment" ] }, { "id": "fallback-identity-strategy", "text": "When no register-assigned identifier exists, which fallback identity is used and how is it qualified?", "kind": "identity", "answer_data": [ "Fallback scheme: governed global identifier or IRI, else UUID or ULID assigned by the adopting Dimension", "Assigning Dimension and assignment timestamp", "Explicit locally-assigned flag and justification note" ] }, { "id": "identifier-syntactic-validation", "text": "How is the identifier syntactically validated before acceptance?", "kind": "validation", "answer_data": [ "Format pattern for the scheme", "Check-digit or checksum algorithm where defined", "Normalization rule for casing, padding and separators" ] } ], "data_elements": [ { "id": "registration-authority-code", "name": "Registration authority code", "description": "Governed code identifying the register or registration authority that holds the authoritative record.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "register-entity-identifier", "name": "Register entity identifier", "description": "Identifier assigned to the entity by the registration authority, stored exactly as recorded.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "locally-assigned-identifier", "name": "Locally assigned identifier", "description": "UUID or ULID minted by the adopting Dimension when no authoritative identifier is available; always flagged as non-authoritative.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] }, { "id": "identifier-validity-interval", "name": "Identifier validity interval", "description": "Start and end of the period during which a given identifier denoted this entity.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] } ], "artifacts": [], "inline_only_rationale": "Identity values are inline scalar reference data. The documentary proof of an identifier is a register extract or certificate, modelled once in registration-evidence-documents-and-extracts rather than duplicated here." }, { "id": "cross-scheme-identifier-alignment", "name": "Cross-scheme identifier alignment", "description": "Additional identifier schemes attached to the same legal person (LEI, EUID, VAT or tax number, D-U-N-S, GLN, national scheme numbers) together with the scheme qualification that keeps them unambiguous, and the precedence rules when they disagree. ISO/IEC 6523 exists because an organization identifier without its issuing scheme cannot be interpreted.", "source_refs": [ "SRC-013", "SRC-012", "SRC-003", "SRC-001" ], "questions": [ { "id": "which-alternate-schemes", "text": "Which additional identifier schemes are recorded for this entity and which authority issues each?", "kind": "interoperability", "answer_data": [ "Scheme code, for example an ISO/IEC 6523 International Code Designator", "Issuing authority name and reference", "Identifier value and scheme code-list version" ] }, { "id": "same-legal-person-or-not", "text": "Does each alternate identifier denote the same legal person, or a different unit such as an establishment, VAT group or branch?", "kind": "relationship", "answer_data": [ "Type of unit actually denoted by the identifier", "Strength of the equivalence assertion: asserted, corroborated, or authoritative", "Evidence reference supporting the equivalence" ] }, { "id": "identifier-precedence", "text": "What is the precedence order when alternate identifiers disagree with the authoritative register record?", "kind": "decision", "answer_data": [ "Precedence rule applied", "Conflict record with the divergent values", "Resolution decision and timestamp" ] }, { "id": "lei-status-reconciliation", "text": "How is a global identifier's own registration status reconciled with the underlying register record?", "kind": "state", "answer_data": [ "Registration status of the global identifier record", "Next renewal date and last update date", "Managing issuer reference" ] } ], "data_elements": [ { "id": "identifier-scheme-code", "name": "Identifier scheme code", "description": "Code qualifying which scheme an alternate identifier belongs to.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-013", "SRC-012" ] }, { "id": "alternate-identifier-value", "name": "Alternate identifier value", "description": "Value of an identifier issued under a scheme other than the authoritative register.", "value_kind": "identifier", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-012", "SRC-013" ] }, { "id": "identifier-equivalence-assertion", "name": "Identifier equivalence assertion", "description": "Typed assertion that an alternate identifier denotes the same legal person, with strength and evidence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005", "SRC-002" ] }, { "id": "global-identifier-record-status", "name": "Global identifier record status", "description": "Lifecycle status of the alternate global identifier record itself, distinct from the entity's legal status.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "identifier-crosswalk-table", "name": "Identifier scheme crosswalk table", "description": "Versioned mapping of scheme codes to issuing authorities, format rules and applicable jurisdictions, used to validate and interpret alternate identifiers.", "media_or_form": [ "tabular code list", "machine-readable mapping file", "published reference list" ], "serial": true, "identity_strategy": "Publisher plus code-list version and publication date, for example a registration authorities list version or a Peppol ICD code-list release; never identified by download date alone.", "source_refs": [ "SRC-003", "SRC-013" ] } ], "inline_only_rationale": null } ] }, { "id": "names-and-designations", "name": "Names and designations", "description": "The registered legal name, its variants across scripts and uses, and its dated history.", "source_refs": [ "SRC-002", "SRC-007", "SRC-008" ], "findings": [ { "id": "legal-name-variants-and-name-history", "name": "Legal name, variants and name history", "description": "The legal name exactly as recorded by the authoritative register, plus typed variants (transliterations, trading names, abbreviations, previous legal names) each with dated validity and an evidencing filing. Reference-data formats keep other names and transliterated names in separate typed containers because collapsing them destroys the distinction between the legally operative name and a convenience label.", "source_refs": [ "SRC-002", "SRC-007", "SRC-008", "SRC-011" ], "questions": [ { "id": "exact-legal-name", "text": "What is the legal name exactly as recorded by the authoritative register, including script, diacritics and legal-form suffix?", "kind": "definition", "answer_data": [ "Legal name string preserved byte-exact", "Language and script codes", "Whether the legal-form suffix is part of the recorded name" ] }, { "id": "typed-name-variants", "text": "Which other names are recorded and how is each typed?", "kind": "classification", "answer_data": [ "Name type code: trading name, previous legal name, transliteration, abbreviation, alias", "Name value and language code", "Source field the variant was taken from" ] }, { "id": "name-change-dating", "text": "When did each name become effective, when did it cease, and what filing evidences the change?", "kind": "temporal", "answer_data": [ "Name effective date and cessation date", "Legal entity event linking the change", "Filing or gazette reference evidencing it" ] }, { "id": "name-uniqueness-and-dispute", "text": "Does the register enforce name uniqueness, and is the name reserved or in dispute?", "kind": "constraint", "answer_data": [ "Uniqueness rule and scope of the rule", "Reservation status and expiry", "Dispute or direction-to-change flag" ] } ], "data_elements": [ { "id": "legal-name", "name": "Legal name", "description": "The official name of the legal entity as recorded in the official register or its constituting documents.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-007" ] }, { "id": "name-variant", "name": "Name variant", "description": "A typed alternative name with language, script and validity interval.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "name-change-effective-date", "name": "Name change effective date", "description": "Date on which a recorded name became or ceased to be operative.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-011" ] } ], "artifacts": [ { "id": "name-change-filing", "name": "Name change filing or notice", "description": "The filed instrument and register or gazette notice evidencing a change of legal name.", "media_or_form": [ "register filing document", "official gazette notice", "register extract page" ], "serial": true, "identity_strategy": "Register filing or transaction reference plus filing timestamp in RFC 3339; fallback is issuer reference plus content hash of the retrieved document.", "source_refs": [ "SRC-008", "SRC-011" ] } ], "inline_only_rationale": null } ] }, { "id": "legal-form-and-classification", "name": "Legal form and classification", "description": "The constitutive legal form and jurisdiction, and the categorical and activity classifications applied to the record.", "source_refs": [ "SRC-004", "SRC-002", "SRC-008", "SRC-011" ], "findings": [ { "id": "entity-legal-form-and-jurisdiction-of-formation", "name": "Entity legal form and jurisdiction of formation", "description": "The legal form under which the entity exists and the jurisdiction whose law constitutes it. These are interdependent: a legal form has meaning only under local legislation, which is why the governed code list carries local-language names and why a Dutch BV must not be normalised into a German GmbH. Sub-national formation jurisdictions are the norm in federal states.", "source_refs": [ "SRC-004", "SRC-002", "SRC-008" ], "questions": [ { "id": "formation-jurisdiction", "text": "Under which jurisdiction's law was the entity formed, at what sub-national level, and how is that coded?", "kind": "spatial", "answer_data": [ "Country code and, where applicable, subdivision code with the code-list version", "Jurisdiction label as used by the register", "Whether the register operates at national or sub-national level" ] }, { "id": "legal-form-coding", "text": "What is the entity's legal form, expressed both as a local-language name and as a governed code?", "kind": "classification", "answer_data": [ "Entity legal form code and code-list version", "Local-language legal form name and its language code", "Mapping note where the register's own vocabulary differs" ] }, { "id": "legal-form-change", "text": "Has the legal form changed over time, and what conversion event caused the change?", "kind": "lifecycle", "answer_data": [ "Previous legal form code with validity interval", "Conversion event type and effective date", "Whether legal personality was continuous through the conversion" ] }, { "id": "no-elf-code-available", "text": "If no governed code exists for the form, which placeholder and free-text value are used?", "kind": "exception", "answer_data": [ "Reserved placeholder code used, and why", "Free-text legal form value as recorded", "Reference to any pending request for a new code" ] } ], "data_elements": [ { "id": "legal-jurisdiction-code", "name": "Legal jurisdiction code", "description": "Coded jurisdiction whose law constitutes the entity, at country and where relevant subdivision level.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "entity-legal-form-code", "name": "Entity legal form code", "description": "Governed four-character code for the entity's legal form under the applicable jurisdiction.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-002" ] }, { "id": "other-legal-form-text", "name": "Other legal form text", "description": "Local-language legal form name used when no governed code applies.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-004", "SRC-002" ] } ], "artifacts": [ { "id": "elf-code-list-snapshot", "name": "Entity legal forms code list snapshot", "description": "The versioned legal-forms code list used to validate and interpret the recorded form at a point in time.", "media_or_form": [ "CSV code list", "spreadsheet code list", "published PDF list" ], "serial": true, "identity_strategy": "Publisher plus code-list version number and publication date, for example version 1.6 of February 2026; the version is mandatory because codes are added and jurisdictions revised between releases.", "source_refs": [ "SRC-004" ] } ], "inline_only_rationale": null }, { "id": "entity-category-and-economic-activity-classification", "name": "Entity category and economic activity classification", "description": "The structural category of the registration record (general entity, branch, fund, sole proprietor, resident government entity, international organization) and the declared economic activity codes. Category is not cosmetic: it changes which registration rules apply and how other fields must be read, and public-authority policy has repeatedly added categories rather than treating them as free text.", "source_refs": [ "SRC-011", "SRC-002", "SRC-007", "SRC-008" ], "questions": [ { "id": "record-category", "text": "What category and sub-category does this registration record fall into?", "kind": "classification", "answer_data": [ "Entity category code and sub-category code", "Governing policy reference and its date", "Effective date of the category assignment" ] }, { "id": "activity-codes", "text": "Which economic activity classification codes are recorded, under which scheme and version?", "kind": "classification", "answer_data": [ "Activity code values", "Scheme name and revision", "Primary versus secondary designation" ] }, { "id": "activity-verification", "text": "Is the declared activity self-reported or verified, and how often is it refreshed?", "kind": "evidence", "answer_data": [ "Assertion source and role", "Verification status", "Date the activity was last confirmed" ] }, { "id": "category-conditional-rules", "text": "Does the category change the applicable registration rules or the meaning of other fields?", "kind": "constraint", "answer_data": [ "Category-conditional rule set", "List of fields whose interpretation changes", "Fields that become mandatory or inapplicable" ] } ], "data_elements": [ { "id": "entity-category-code", "name": "Entity category code", "description": "Structural category of the registration record.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-011", "SRC-002" ] }, { "id": "entity-sub-category-code", "name": "Entity sub-category code", "description": "Finer classification within the entity category.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-011" ] }, { "id": "activity-classification-code", "name": "Activity classification code", "description": "Declared economic activity code with its scheme and revision.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-008" ] } ], "artifacts": [ { "id": "activity-classification-code-list", "name": "Activity classification code list", "description": "The versioned economic activity classification scheme against which recorded activity codes are validated.", "media_or_form": [ "published classification scheme", "machine-readable code list" ], "serial": true, "identity_strategy": "Scheme name plus revision identifier and publication date; revisions renumber classes, so an activity code without its revision is not interpretable.", "source_refs": [ "SRC-007", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "legal-personality-and-capacity", "name": "Legal personality and capacity", "description": "A registered legal person is a juristic person distinct from its members, able to acquire rights and assume obligations in its own name. UNCITRAL treats this as affirmative asset partitioning and recommends that members are not personally liable solely by reason of membership. UNCITRAL insolvency guidance adds that a corporation obtains personality by a legal process and enjoys perpetuity independent of changing members. ISO 17442 requires the party to have the legal right in its jurisdiction to enter independently into legal contracts.", "source_refs": [ "SRC-024", "SRC-026", "SRC-020" ], "questions": [ { "id": "legal-personality-and-capacity-q01", "text": "Does this subject have legal personality distinct from its members or controllers under the law of the formation jurisdiction?", "kind": "definition", "answer_data": [ "boolean has_legal_personality", "code personality_basis (registered-company, statutory-body, contractual-legal-person, other)", "text legal_basis_citation" ] }, { "id": "legal-personality-and-capacity-q02", "text": "Which capacities does the law confer on this legal person, and are any of them restricted by statute, objects or duration?", "kind": "constraint", "answer_data": [ "collection capacities (contract, hold-property, sue-and-be-sued, perpetual-succession)", "boolean objects_restrict_capacity", "text objects_clause", "date or duration stated_duration", "boolean indefinite_duration" ] }, { "id": "legal-personality-and-capacity-q03", "text": "Are members or shareholders shielded from the entity's debts solely by reason of membership, and under which legal form rule?", "kind": "classification", "answer_data": [ "code member_liability (limited, unlimited, mixed, not-applicable)", "text liability_rule_citation", "boolean veil_piercing_or_abuse_carveout_exists" ] }, { "id": "legal-personality-and-capacity-q04", "text": "At what event time did legal personality attach, and is registration constitutive or merely declaratory in this jurisdiction?", "kind": "lifecycle", "answer_data": [ "timestamp personality_effective_at", "code formation_theory (constitutive-registration, declaratory-registration, statutory-creation, charter)", "identifier constituting_instrument_id" ] } ], "data_elements": [ { "id": "legal-personality-and-capacity-data01", "name": "Has legal personality", "description": "Whether the subject is a juristic person distinct from natural-person members.", "value_kind": "boolean", "cardinality": "1", "required": true, "source_refs": [ "SRC-024" ] }, { "id": "legal-personality-and-capacity-data02", "name": "Personality effective at", "description": "Event time at which legal personality attached under the formation law, recorded separately from observation or ingestion time.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-024", "SRC-021" ] }, { "id": "legal-personality-and-capacity-data03", "name": "Formation theory", "description": "Whether registration creates the person (UNCITRAL LLE Recommendation 8: formed once registered) or records a person already constituted.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-024" ] }, { "id": "legal-personality-and-capacity-data04", "name": "Member liability regime", "description": "Limited, unlimited or mixed liability of members solely by reason of membership.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-024" ] } ], "artifacts": [ { "id": "legal-personality-and-capacity-artifact01", "name": "Proof of incorporation or constitution", "description": "Certificate, extract or statutory instrument that proves the entity exists as a legal person. FATF INR 24 lists proof of incorporation in the company-registry basic set.", "media_or_form": [ "register-extract", "certificate", "official-gazette", "public-legal-document" ], "serial": true, "identity_strategy": "Authoritative register document number in the formation jurisdiction; Dimension UUID only if the register issues no document identifier.", "source_refs": [ "SRC-023", "SRC-022", "SRC-024" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "register-and-registration-authority", "name": "Register and registration authority", "description": "The authority that keeps the register, what the register legally accomplishes, and the dated act of registration with its ongoing filing obligations.", "rationale": "Registration facts are only as strong as the authority behind them. Guidance for business registries treats the registry's mandate, publicity and accuracy duties as first-order design questions, and reference-data formats separate the authority that constitutes registration from sources consulted only for validation. Without this bundle an agent cannot tell a constitutive record from a scraped directory.", "source_refs": [ "SRC-003", "SRC-009", "SRC-010", "SRC-014", "SRC-008" ], "layers": [ { "id": "registration-authority-and-register-scope", "name": "Registration authority and register scope", "description": "Identification of the authority and register instance, and the legal effect of entry.", "source_refs": [ "SRC-003", "SRC-009", "SRC-010", "SRC-002" ], "findings": [ { "id": "registration-authority-identification", "name": "Registration authority identification", "description": "Identification of the organization operating the register, the specific register instance, its statutory mandate and its territorial or sectoral coverage, distinguishing a constitutive registration authority from a validation-only source. The existence of a governed list of more than a thousand registers across 232 jurisdictions shows that 'the register' is never inferable from the country alone.", "source_refs": [ "SRC-003", "SRC-009", "SRC-002", "SRC-010" ], "questions": [ { "id": "who-operates-the-register", "text": "Which organization operates the register, and under what statutory mandate?", "kind": "authority", "answer_data": [ "Authority legal name and its own entity identifier", "Enabling legislation reference", "Supervising ministry or oversight body" ] }, { "id": "coded-register-entry", "text": "Which coded entry from a governed registration-authority list applies, and at what list version?", "kind": "identity", "answer_data": [ "Registration authority code", "Authority list version and publication date", "Register name in local and international form" ] }, { "id": "register-coverage", "text": "Does the register cover the whole jurisdiction, or only a sub-national or sectoral segment?", "kind": "spatial", "answer_data": [ "Territorial coverage statement", "Sectoral or legal-form coverage", "Explicit exclusions and the registers that cover them instead" ] }, { "id": "constitutive-or-validation-source", "text": "Is this source constitutive for registration, or is it consulted only to validate?", "kind": "authority", "answer_data": [ "Source role code: registration authority, validation authority, or other validation source", "Corroboration level the source can support", "Whether the source is fee-gated or public" ] } ], "data_elements": [ { "id": "registration-authority-name", "name": "Registration authority name", "description": "Legal name of the organization operating the register.", "value_kind": "text", "cardinality": "1", "required": true, "source_refs": [ "SRC-003", "SRC-009" ] }, { "id": "authority-mandate-reference", "name": "Authority mandate reference", "description": "Citation of the legislation or instrument conferring the register's mandate.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "register-coverage-statement", "name": "Register coverage statement", "description": "Declared territorial and sectoral scope of the register, with exclusions.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-003", "SRC-009" ] } ], "artifacts": [ { "id": "registration-authorities-list-snapshot", "name": "Registration authorities list snapshot", "description": "The versioned governed list of registers and validation authorities used to resolve and validate authority codes.", "media_or_form": [ "versioned register list file", "spreadsheet or CSV list", "published PDF reference list" ], "serial": true, "identity_strategy": "List publisher plus version and publication date, for example version 1.8.1 of November 2024; implementers must record which version a stored code was validated against.", "source_refs": [ "SRC-003" ] } ], "inline_only_rationale": null }, { "id": "register-legal-effect", "name": "Register legal effect: constitutive versus declaratory", "description": "What entry on the register legally accomplishes: whether legal personality arises from registration or is merely recorded, from when disclosed particulars are opposable to third parties, what liability or warranty the register accepts, and whether parallel registers can conflict. This distinction determines whether absence from a register is evidence of non-existence or merely of non-disclosure.", "source_refs": [ "SRC-009", "SRC-010", "SRC-007" ], "questions": [ { "id": "does-registration-create-personality", "text": "Does registration create legal personality, or record an entity that already exists?", "kind": "definition", "answer_data": [ "Legal effect classification: constitutive or declaratory", "Statutory basis for that effect", "The precise moment legal existence begins" ] }, { "id": "opposability-to-third-parties", "text": "Which particulars are opposable to third parties once disclosed, and from when?", "kind": "authority", "answer_data": [ "Opposability rule and its statutory source", "Publication date and any grace period", "Consequences of non-disclosure for third-party reliance" ] }, { "id": "register-liability-regime", "text": "What is the register's liability regime for inaccurate entries, and is the data warranted?", "kind": "constraint", "answer_data": [ "Liability or immunity statement", "Warranty or disclaimer text as published", "Whether entries are verified or filed on self-declaration" ] }, { "id": "parallel-registers", "text": "Are there parallel registers in the same jurisdiction whose entries could conflict?", "kind": "exception", "answer_data": [ "List of parallel or sectoral registers", "Precedence rule between them", "Known divergence cases" ] } ], "data_elements": [ { "id": "register-legal-effect-code", "name": "Register legal effect code", "description": "Whether entry is constitutive of legal personality or declaratory only.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009", "SRC-010" ] }, { "id": "opposability-start-date", "name": "Opposability start date", "description": "Date from which a disclosed particular may be relied on against third parties.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010" ] }, { "id": "register-warranty-statement", "name": "Register warranty or disclaimer statement", "description": "The register's published position on accuracy, verification and liability.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "This finding records a legal characterisation derived from statute and published register terms. The statutory instruments are referenced by citation and belong to a legislation model; copying them here would duplicate a sibling model and create a second, drifting copy of the law." } ] }, { "id": "registration-act-and-filings", "name": "Registration act and filings", "description": "The dated act of registration, the currency of the record, and the recurring disclosure obligations that maintain it.", "source_refs": [ "SRC-002", "SRC-008", "SRC-010", "SRC-009" ], "findings": [ { "id": "registration-act-dates-and-record-currency", "name": "Registration act dates and record currency", "description": "The dated act of registration and how current the record is: entity creation date, the register's own initial registration date, last update, next renewal or confirmation date, and — critically — the separation of event time, register-recorded time and our observation time. Reference-data formats keep creation date and initial registration date as distinct fields precisely because they routinely differ.", "source_refs": [ "SRC-002", "SRC-008", "SRC-001" ], "questions": [ { "id": "creation-versus-registration-date", "text": "What is the entity creation date, and how does it differ from the register's initial registration date?", "kind": "temporal", "answer_data": [ "Entity creation date as recorded by the register", "Initial registration date in the register or identifier system", "Explicit mapping of each value to its source field" ] }, { "id": "record-currency", "text": "When was the register record last updated, and when did we last observe or retrieve it?", "kind": "provenance", "answer_data": [ "Last update timestamp in RFC 3339", "Observation or ingestion timestamp in RFC 3339", "Source system and endpoint or file" ] }, { "id": "renewal-obligation", "text": "What periodic confirmation or renewal obligation applies, and when is it next due?", "kind": "process", "answer_data": [ "Obligation type: annual confirmation, renewal, re-registration", "Cadence and next due date", "Consequence of missing the deadline" ] }, { "id": "date-precision-reconciliation", "text": "How are date-only register values reconciled with timestamped ingestion records?", "kind": "temporal", "answer_data": [ "Precision marker for each temporal value", "Time-zone assumption applied and its justification", "Normalisation rule preventing silent promotion of a date to a timestamp" ] } ], "data_elements": [ { "id": "entity-creation-date", "name": "Entity creation date", "description": "Date the entity was first established or came into legal existence.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "initial-registration-date", "name": "Initial registration date", "description": "Date the record was first created in the register or identifier system.", "value_kind": "date", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "last-update-timestamp", "name": "Last update timestamp", "description": "Time the source record was last modified, in RFC 3339.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "observation-timestamp", "name": "Observation timestamp", "description": "Time at which the adopting Dimension retrieved or observed the record, in RFC 3339.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-009" ] }, { "id": "next-renewal-date", "name": "Next renewal or confirmation date", "description": "Next date on which the record must be confirmed or renewed.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "These are inline scalar attributes of the registration record. The documents evidencing them are register extracts and filings already modelled in registration-evidence-documents-and-extracts and mandatory-disclosure-particulars-and-filing-obligations." }, { "id": "mandatory-disclosure-particulars-and-filing-obligations", "name": "Mandatory disclosure particulars and filing obligations", "description": "The particulars and documents the entity must disclose to the register at formation and on a recurring basis, the consequence of default, and the disclosure level applied to each. EU company law makes disclosure through national registers compulsory and interconnects it cross-border, while registry guidance treats the minimum registration dataset as a deliberate policy choice rather than a technical accident.", "source_refs": [ "SRC-010", "SRC-009", "SRC-008", "SRC-014" ], "questions": [ { "id": "required-particulars", "text": "Which particulars must be disclosed at registration under the applicable law?", "kind": "requirement", "answer_data": [ "Enumerated list of required particulars", "Statutory reference for each", "Mandatory versus optional designation" ] }, { "id": "recurring-filings", "text": "Which documents must be filed and how frequently?", "kind": "process", "answer_data": [ "Document type: constitution, annual accounts, confirmation statement, officer changes", "Filing cadence and due-date rule", "Filing channel and accepted formats" ] }, { "id": "late-or-missing-filings", "text": "What happens when a filing is late or missing, and how is that reflected in the record?", "kind": "exception", "answer_data": [ "Overdue indicator on the record", "Sanction type: penalty, disqualification, strike-off", "Escalation sequence and timings" ] }, { "id": "filing-disclosure-level", "text": "Which filings are publicly disclosed in full and which only as metadata?", "kind": "access", "answer_data": [ "Disclosure level per document type", "Redaction or suppression rules applied", "Fee or gating condition for full content" ] } ], "data_elements": [ { "id": "required-particular", "name": "Required particular", "description": "A specific fact the entity must disclose to the register.", "value_kind": "text", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-010", "SRC-009" ] }, { "id": "filing-obligation", "name": "Filing obligation", "description": "A recurring document-filing duty with cadence, due-date rule and default consequence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-010" ] }, { "id": "filing-due-date", "name": "Filing due date", "description": "Next date by which a required filing must be made.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "statutory-filing-document", "name": "Statutory filing document", "description": "A filed instrument or return held by the register: constitutional documents, annual accounts, confirmation statements, officer change notices.", "media_or_form": [ "filed PDF or scanned document", "structured electronic filing submission", "register-held paper document" ], "serial": true, "identity_strategy": "Register filing or transaction reference plus filing timestamp in RFC 3339 and a sequence number where several filings share a timestamp; fallback is issuer reference plus content hash.", "source_refs": [ "SRC-008", "SRC-010" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "lifecycle-status-and-events", "name": "Lifecycle, status and events", "description": "The state of the entity and of its record, the dated events that change them, and the end and possible restoration of registered existence.", "rationale": "Public-authority policy for the global identifier system defines legal entity events as those that alter entity or relationship data or cause identifiers to be retired and created, and requires data history. National registers publish separate status and status-detail vocabularies plus strike-off and restoration procedures. Status without dated events is unusable for reasoning about the past.", "source_refs": [ "SRC-011", "SRC-002", "SRC-008", "SRC-010" ], "layers": [ { "id": "status-and-standing", "name": "Status and standing", "description": "The two independent status axes and the softer signals of standing that precede a formal status change.", "source_refs": [ "SRC-002", "SRC-008", "SRC-001" ], "findings": [ { "id": "registration-status-and-entity-status", "name": "Registration status and entity status", "description": "Two distinct axes that must not be conflated: the legal state of the entity in the register (active, dissolved, in liquidation, converted), and the state of the registration record as a data object (published, pending, lapsed, retired, duplicate). An entity can be perfectly alive while its identifier record has lapsed, and a record can remain published after the entity is dissolved.", "source_refs": [ "SRC-002", "SRC-008", "SRC-001" ], "questions": [ { "id": "entity-status-in-register", "text": "What is the entity's status in the authoritative register and which code list defines it?", "kind": "state", "answer_data": [ "Entity status code and defining code list with version", "Effective date of the status", "Register field the value was taken from" ] }, { "id": "record-status-as-data-object", "text": "What is the status of the registration record as a data object, independent of the entity's legal state?", "kind": "state", "answer_data": [ "Record or registration status code", "Published or withheld flag", "Lapse, retirement or duplicate reason" ] }, { "id": "allowed-status-transitions", "text": "Which status transitions are legally possible, and which are terminal?", "kind": "lifecycle", "answer_data": [ "Allowed transition set for the jurisdiction and legal form", "Terminal states and any reversibility window", "Guard conditions on each transition" ] }, { "id": "status-detail-qualification", "text": "What supplementary status detail qualifies the headline status?", "kind": "state", "answer_data": [ "Status detail code, for example an active proposal to strike off or a transfer out of the jurisdiction", "Narrative note as published", "Source field and observation timestamp" ] } ], "data_elements": [ { "id": "entity-status-code", "name": "Entity status code", "description": "Legal status of the entity as recorded by the register.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "registration-record-status-code", "name": "Registration record status code", "description": "Status of the registration record as a data object, independent of the entity's legal state.", "value_kind": "code", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "status-detail-code", "name": "Status detail code", "description": "Qualifier refining the headline status.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "status-effective-date", "name": "Status effective date", "description": "Date from which the current status applies.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-002" ] } ], "artifacts": [], "inline_only_rationale": "Statuses are coded inline values. Their governing code lists are captured as versioned artifacts under classification and authority findings, and status-changing documents are captured as event and dissolution artifacts; a separate artifact here would duplicate both." }, { "id": "compliance-standing-and-removal-risk", "name": "Compliance standing and involuntary removal risk", "description": "Signals of standing short of a formal status change: overdue filings, published proposals to strike off or dissolve, disputed registered office, insolvency-history and charges flags, and administrative penalties. These are leading indicators an operating agent must act on before the status field changes.", "source_refs": [ "SRC-008", "SRC-010", "SRC-009" ], "questions": [ { "id": "active-removal-proposals", "text": "Are there active proposals to strike off, dissolve or suspend the entity, and when were they published?", "kind": "state", "answer_data": [ "Proposal type and issuing authority", "Publication date and objection deadline", "Outcome or withdrawal, if known" ] }, { "id": "overdue-filings", "text": "Which filings are currently overdue and by how long?", "kind": "measurement", "answer_data": [ "Overdue filing type", "Original due date and days overdue", "Accrued penalty amount where published" ] }, { "id": "standing-flags", "text": "Does the record carry flags for insolvency history, registered charges, or a disputed registered office?", "kind": "quality", "answer_data": [ "Flag name and value", "Source field and whether the flag is deprecated in favour of a sub-resource", "Observation timestamp" ] }, { "id": "remediation-path", "text": "What remediation restores good standing, and by when?", "kind": "process", "answer_data": [ "Required remediation action", "Party responsible for performing it", "Deadline and consequence of missing it" ] } ], "data_elements": [ { "id": "removal-proposal", "name": "Removal or strike-off proposal", "description": "A published proposal to strike off, dissolve or suspend the entity, with dates and objection window.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "overdue-filing-indicator", "name": "Overdue filing indicator", "description": "Whether any required filing is currently past its due date.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "standing-flag", "name": "Standing flag", "description": "Coded flag such as insolvency history, charges present or registered office in dispute.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "gazette-or-strike-off-notice", "name": "Official gazette or strike-off notice", "description": "The published notice evidencing a proposal to strike off, dissolve or suspend, or an administrative penalty.", "media_or_form": [ "official gazette notice", "register notice document", "published register alert feed item" ], "serial": true, "identity_strategy": "Gazette issue reference plus notice number and publication date in RFC 3339; fallback is the register's notice identifier plus issuing authority.", "source_refs": [ "SRC-008", "SRC-010" ] } ], "inline_only_rationale": null } ] }, { "id": "legal-entity-events-and-succession", "name": "Legal entity events and succession", "description": "Dated typed events that change registered facts, including those that create, absorb, transform or end legal persons.", "source_refs": [ "SRC-011", "SRC-002", "SRC-010", "SRC-008" ], "findings": [ { "id": "legal-entity-event-record-and-effective-dating", "name": "Legal entity event record and effective dating", "description": "Discrete typed events recorded with an effective date in the legal jurisdiction, a date recorded by the register, a completion status and supporting validation documents. Public-authority policy explicitly separates events that alter reference data from those that retire or create identifiers, and prioritises frequent events such as name changes and mergers over rare ones such as reverse takeovers.", "source_refs": [ "SRC-011", "SRC-002" ], "questions": [ { "id": "event-type", "text": "What type of legal entity event occurred, per a governed event type list?", "kind": "event", "answer_data": [ "Event type code and code-list version", "Narrative description as published", "Whether the event retires or creates an identifier" ] }, { "id": "event-three-times", "text": "What is the event's effective date in the jurisdiction, the date the register recorded it, and the time we ingested it?", "kind": "temporal", "answer_data": [ "Event effective date", "Event recorded date", "Ingestion timestamp in RFC 3339 with explicit offset" ] }, { "id": "event-completion-status", "text": "What is the event's completion status?", "kind": "state", "answer_data": [ "Event status: pending, in progress, completed, withdrawn", "History of status changes with dates", "Expected completion date for pending events" ] }, { "id": "event-effect-and-evidence", "text": "Which documents validate the event and which fields does it change?", "kind": "evidence", "answer_data": [ "Validation document references", "List of changed fields with before and after values", "Corroboration level achieved" ] } ], "data_elements": [ { "id": "legal-entity-event-type", "name": "Legal entity event type", "description": "Governed code for the kind of event that altered the registered facts.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011", "SRC-002" ] }, { "id": "event-effective-date", "name": "Event effective date", "description": "Date on which the event took legal effect in the jurisdiction.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-011" ] }, { "id": "event-recorded-date", "name": "Event recorded date", "description": "Date on which the register or identifier system recorded the event.", "value_kind": "date", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "event-status-code", "name": "Event status code", "description": "Completion state of the event.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-011" ] } ], "artifacts": [ { "id": "legal-entity-event-validation-document", "name": "Legal entity event validation document", "description": "The instrument evidencing that the event occurred and took effect.", "media_or_form": [ "court or registry order", "shareholder or board resolution", "regulatory filing or notice" ], "serial": true, "identity_strategy": "Issuing body reference plus document number and issue date in RFC 3339; fallback is issuer plus content hash.", "source_refs": [ "SRC-011", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "succession-merger-division-and-conversion", "name": "Succession: merger, division and conversion", "description": "Events that create, absorb or transform legal persons and the predecessor/successor links they generate, including cross-border operations where two registers must notify each other. Organization vocabularies model this as change events with original and resulting organizations rather than as an in-place update, which is the only representation that survives later audit.", "source_refs": [ "SRC-010", "SRC-006", "SRC-002", "SRC-011", "SRC-014" ], "questions": [ { "id": "predecessor-successor-links", "text": "Which predecessor and successor entities are linked by this event, and by which identifiers?", "kind": "relationship", "answer_data": [ "Predecessor entity identifiers with scheme", "Successor entity identifiers with scheme", "Link type and direction" ] }, { "id": "operation-type", "text": "Is the operation a merger by absorption, a merger by formation, a division, a spin-off or a conversion?", "kind": "classification", "answer_data": [ "Operation type code", "Statutory basis and jurisdiction", "Whether legal personality is continuous" ] }, { "id": "cross-border-notification", "text": "Does the operation cross jurisdictions, and which registers must notify each other?", "kind": "interoperability", "answer_data": [ "Origin and destination register codes", "Notification message type and channel", "Date the notification was sent and acknowledged" ] }, { "id": "identifier-survival", "text": "Does the entity's identifier survive the operation, or is a new one assigned and the old one retired?", "kind": "identity", "answer_data": [ "Identifier continuity decision and its basis", "Retired identifier and retirement date", "Newly assigned identifier and assignment date" ] } ], "data_elements": [ { "id": "successor-entity-reference", "name": "Successor entity reference", "description": "Reference to an entity that succeeds this one following the operation.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "predecessor-entity-reference", "name": "Predecessor entity reference", "description": "Reference to an entity this one succeeds.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-002" ] }, { "id": "operation-type-code", "name": "Operation type code", "description": "Coded kind of merger, division, spin-off or conversion.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-011" ] } ], "artifacts": [ { "id": "cross-border-operation-instrument", "name": "Cross-border operation instrument", "description": "Documents governing and evidencing a merger, division, conversion or seat transfer between registers.", "media_or_form": [ "common draft terms or merger plan", "pre-operation certificate issued by a register", "court or authority approval order" ], "serial": true, "identity_strategy": "Issuing register plus certificate or order number and issue date in RFC 3339.", "source_refs": [ "SRC-010", "SRC-014" ] } ], "inline_only_rationale": null }, { "id": "dissolution-liquidation-and-restoration", "name": "Dissolution, liquidation and restoration", "description": "The end and possible reinstatement of registered existence: voluntary and compulsory dissolution, liquidation and insolvency proceedings with appointed office-holders, deregistration, and restoration to the register. Restoration is a genuine counterexample to naive terminal-state modelling: a dissolved entity can be brought back, so 'dissolved' is not always absorbing.", "source_refs": [ "SRC-002", "SRC-008", "SRC-009", "SRC-011" ], "questions": [ { "id": "end-date-and-ground", "text": "On what date and on what ground did registered existence end?", "kind": "lifecycle", "answer_data": [ "Expiration or dissolution date", "Expiration reason code: dissolved, merged into another entity, transferred out, ceased to be eligible", "Ground description as published" ] }, { "id": "insolvency-proceeding", "text": "Which insolvency or liquidation proceeding is open, who is the appointed office-holder, and what are its dates?", "kind": "process", "answer_data": [ "Proceeding type and opening date", "Office-holder reference and appointment date", "Closure date and outcome" ] }, { "id": "restoration-availability", "text": "Can the entity be restored or reinstated, under what conditions and within what period?", "kind": "exception", "answer_data": [ "Restoration mechanism: administrative or court-ordered", "Eligibility window and conditions", "Restoring authority and effect on the intervening period" ] }, { "id": "post-dissolution-record", "text": "What happens to the record and its identifiers after dissolution?", "kind": "retention", "answer_data": [ "Record disposition rule", "Identifier retirement and reuse policy", "Minimum retention period and its statutory basis" ] } ], "data_elements": [ { "id": "entity-expiration-date", "name": "Entity expiration date", "description": "Date on which registered legal existence ended.", "value_kind": "date", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "entity-expiration-reason", "name": "Entity expiration reason", "description": "Coded ground on which registered existence ended.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002", "SRC-011" ] }, { "id": "data-insolvency-proceeding", "name": "Insolvency or liquidation proceeding", "description": "An open or closed proceeding with type, dates and appointed office-holder.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-010" ] }, { "id": "restoration-event", "name": "Restoration event", "description": "An event reinstating the entity to the register, with authority, date and effect.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] } ], "artifacts": [ { "id": "dissolution-or-restoration-order", "name": "Dissolution or restoration order", "description": "The registrar notice or court order ending or reinstating registered existence.", "media_or_form": [ "registrar dissolution notice", "court order or decision", "restoration decision document" ], "serial": true, "identity_strategy": "Issuing authority plus order or notice number and date of issue in RFC 3339.", "source_refs": [ "SRC-008", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "jurisdiction-place-and-cross-border-presence", "name": "Jurisdiction, place and cross-border presence", "description": "Addresses recorded by the register, and the entity's registered footprint beyond its jurisdiction of formation.", "rationale": "Reference-data formats keep legal address and headquarters address as distinct containers because only one of them has legal effect for service. Company law interconnects registers specifically so that branch registration and seat transfer are visible across borders, and national registers publish separate branch and foreign-company sub-structures. Place is therefore a registration fact, not merely a contact detail.", "source_refs": [ "SRC-002", "SRC-008", "SRC-010", "SRC-014", "SRC-006" ], "layers": [ { "id": "registered-addresses", "name": "Registered addresses", "description": "Addresses of record and their legal roles.", "source_refs": [ "SRC-002", "SRC-008", "SRC-006" ], "findings": [ { "id": "registered-office-and-address-set", "name": "Registered office and address set", "description": "The addresses attached to the registration record: the legal or registered address that has legal effect for service of documents, the headquarters address, and other recorded addresses — all distinguished from operating sites. Registers publish an explicit flag when a registered office is in dispute, which shows the address is a contested legal fact rather than descriptive metadata.", "source_refs": [ "SRC-002", "SRC-008", "SRC-006" ], "questions": [ { "id": "legal-address-components", "text": "What is the legal or registered address of record and which components does the register mandate?", "kind": "spatial", "answer_data": [ "Address lines, city, region, postal code", "Country code and code-list version", "Components the register treats as mandatory" ] }, { "id": "address-role-distinction", "text": "How does the registered address differ from the headquarters address and from operating sites?", "kind": "composition", "answer_data": [ "Address role code for each recorded address", "Purpose and legal effect of each role", "References to site records held in a separate location model" ] }, { "id": "service-of-process", "text": "Is the address usable for legal service, and is it a third-party or agent address?", "kind": "authority", "answer_data": [ "Service-of-process validity flag", "Registered agent or service provider reference", "Evidence of the agent's authority and its validity period" ] }, { "id": "address-verification-state", "text": "Is the recorded address disputed, unverified or subject to change proceedings?", "kind": "quality", "answer_data": [ "Dispute or default-address flag", "Verification method and last verified date", "Pending change proceeding reference" ] } ], "data_elements": [ { "id": "legal-address", "name": "Legal or registered address", "description": "The address of record with legal effect in the jurisdiction of registration.", "value_kind": "object", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-008" ] }, { "id": "headquarters-address", "name": "Headquarters address", "description": "Address of the entity's principal administration, where recorded and distinct from the legal address.", "value_kind": "object", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "address-role-code", "name": "Address role code", "description": "Role a recorded address plays: legal, headquarters, service, or other.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "registered-agent-reference", "name": "Registered agent reference", "description": "Reference to a third party providing the registered address or accepting service.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [], "inline_only_rationale": "Addresses are structured inline values on the registration record. Geocoding, premises identity and site management belong to a composable address and location model linked by composition; producing address artifacts here would duplicate that sibling." } ] }, { "id": "cross-border-presence", "name": "Cross-border presence", "description": "Branch registration, seat transfer and authorization to operate outside the jurisdiction of formation.", "source_refs": [ "SRC-008", "SRC-010", "SRC-005", "SRC-014" ], "findings": [ { "id": "branch-and-establishment-registration", "name": "Branch and establishment registration", "description": "Registration records for branches and establishments that are not separate legal persons but carry their own register entries, identifiers and disclosure duties in a host jurisdiction. Relationship data recognises an international branch relationship as a distinct type, and national registers hold explicit branch and foreign-company sub-structures pointing back to the home register.", "source_refs": [ "SRC-008", "SRC-005", "SRC-010", "SRC-011" ], "questions": [ { "id": "is-branch-not-legal-person", "text": "Is this record a branch or establishment rather than an autonomous legal person, and which head office does it belong to?", "kind": "classification", "answer_data": [ "Branch indicator and entity category", "Head office identifier and its register", "Head office jurisdiction" ] }, { "id": "host-register-identity", "text": "Which host-jurisdiction register holds the branch record and what identifier does it assign?", "kind": "identity", "answer_data": [ "Host registration authority code", "Branch registration identifier", "Branch registration date" ] }, { "id": "branch-disclosure-split", "text": "Which particulars must the branch disclose locally versus rely on from the head office register?", "kind": "requirement", "answer_data": [ "Locally required particulars", "Particulars referenced from the home register", "Mechanism by which home-register changes are notified" ] }, { "id": "head-office-closure-propagation", "text": "How is closure or dissolution of the head office propagated to the branch record?", "kind": "event", "answer_data": [ "Propagation rule and responsible register", "Notification message type", "Branch closure or removal date" ] } ], "data_elements": [ { "id": "branch-indicator", "name": "Branch indicator", "description": "Whether the record describes a branch or establishment rather than an autonomous legal person.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-011" ] }, { "id": "head-office-reference", "name": "Head office reference", "description": "Reference to the legal person of which this record is a branch.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-008" ] }, { "id": "branch-registration-identifier", "name": "Branch registration identifier", "description": "Identifier assigned to the branch by the host register.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] } ], "artifacts": [ { "id": "branch-registration-filing", "name": "Branch registration filing", "description": "Documents lodged to register a branch or establishment in a host jurisdiction.", "media_or_form": [ "branch registration form", "home-register extract lodged abroad", "certified translation of constitutional documents" ], "serial": true, "identity_strategy": "Host register filing reference plus filing date in RFC 3339; fallback is issuer plus content hash.", "source_refs": [ "SRC-008", "SRC-010" ] } ], "inline_only_rationale": null }, { "id": "redomiciliation-and-foreign-qualification", "name": "Redomiciliation and foreign qualification", "description": "Transfer of the registered seat between jurisdictions, and authorization to do business in jurisdictions other than that of formation, with or without continuity of legal personality. Register status vocabularies carry values for transfer out of the jurisdiction, confirming that jurisdiction of formation is a dated fact rather than a constant.", "source_refs": [ "SRC-008", "SRC-010", "SRC-002", "SRC-017" ], "questions": [ { "id": "seat-transfer", "text": "Has the entity transferred its registered seat, from which jurisdiction to which, and on what date?", "kind": "lifecycle", "answer_data": [ "Origin and destination jurisdictions", "Transfer effective date and register-recorded date", "Register status values reflecting transfer in and out" ] }, { "id": "personality-continuity", "text": "Is legal personality continuous across the transfer, or was the entity re-formed?", "kind": "definition", "answer_data": [ "Continuity assertion and its statutory basis", "Evidence reference supporting continuity", "Consequences for contracts and identifiers" ] }, { "id": "foreign-qualification", "text": "In which additional jurisdictions is the entity qualified or authorized to do business, and under what identifier?", "kind": "spatial", "answer_data": [ "Host jurisdiction and authorizing body", "Foreign qualification identifier", "Authorization start and end dates" ] }, { "id": "identifier-effects-of-move", "text": "Which identifiers are retired, retained or newly assigned as a result?", "kind": "identity", "answer_data": [ "Retained identifiers", "Retired identifiers with retirement dates", "Newly assigned identifiers with assignment dates" ] } ], "data_elements": [ { "id": "seat-transfer-event", "name": "Seat transfer event", "description": "A transfer of registered seat between jurisdictions with dates and continuity assertion.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-010" ] }, { "id": "foreign-qualification-record", "name": "Foreign qualification record", "description": "Authorization to do business in a jurisdiction other than that of formation.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-017", "SRC-008" ] }, { "id": "jurisdiction-of-formation-history", "name": "Jurisdiction of formation history", "description": "Ordered history of jurisdictions under whose law the entity has been constituted.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-010" ] } ], "artifacts": [ { "id": "seat-transfer-or-qualification-certificate", "name": "Seat transfer or foreign qualification certificate", "description": "Register-issued evidence of a seat transfer, a foreign qualification or a de-registration on transfer out.", "media_or_form": [ "registry certificate of transfer", "foreign qualification certificate", "de-registration confirmation" ], "serial": true, "identity_strategy": "Issuing register plus certificate number and issue date in RFC 3339.", "source_refs": [ "SRC-010", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "relationships-control-and-representation", "name": "Relationships, control and representation", "description": "Structural links between registered entities, the linkage to control and ownership mechanisms, and who may bind the entity.", "rationale": "Relationship reference data is standardised separately from entity reference data because it has its own periods, corroboration levels and reporting exceptions. Control information sits in a distinct mechanism with a distinct access regime. Representation authority is a registration fact that transactional systems depend on but that is routinely and wrongly inferred from officer titles.", "source_refs": [ "SRC-005", "SRC-011", "SRC-018", "SRC-015", "SRC-008" ], "layers": [ { "id": "group-and-parent-relationships", "name": "Group and parent relationships", "description": "Reported structural links between registered entities, with periods, evidence and exceptions.", "source_refs": [ "SRC-005", "SRC-011", "SRC-016" ], "findings": [ { "id": "parent-group-and-structural-relationships", "name": "Parent, group and structural relationships", "description": "Links between registered entities as reported to registers and identifier systems: direct and ultimate accounting-consolidating parents, international branch to head office, and fund, sub-fund and feeder-to-master links. Each carries a validity period, an accounting or document-filing period, a corroboration level and, where no parent is reported, a coded reporting exception. Consolidation-based parenthood is not the same as legal ownership and must not be presented as such.", "source_refs": [ "SRC-005", "SRC-011", "SRC-016", "SRC-006" ], "questions": [ { "id": "which-parents-reported", "text": "Which direct and ultimate consolidating parents are reported, and by which identifiers?", "kind": "relationship", "answer_data": [ "Parent identifiers with scheme", "Relationship type code and direction", "Accounting standard used for consolidation" ] }, { "id": "relationship-periods", "text": "Over what period is each relationship valid, and which accounting or filing period does the evidence cover?", "kind": "temporal", "answer_data": [ "Relationship start and end dates", "Accounting period covered by the evidence", "Validity period of the supporting filing" ] }, { "id": "relationship-corroboration", "text": "What corroboration level supports the relationship and which documents validate it?", "kind": "evidence", "answer_data": [ "Validation level: pending, entity-supplied only, partially corroborated, fully corroborated", "Validation document type and reference", "Ownership percentage or other quantifier where reported" ] }, { "id": "no-parent-exception", "text": "If no parent is reported, which reporting exception applies?", "kind": "exception", "answer_data": [ "Exception reason code, for example no legal obligation to consolidate or legal obstacles to disclosure", "Narrative justification", "Date the exception should be reviewed" ] }, { "id": "relationship-versus-statistical-group", "text": "How does this reported relationship differ from a statistical enterprise group?", "kind": "interoperability", "answer_data": [ "Statistical unit definition applied", "Divergence between reported parenthood and statistical control", "Which model owns which assertion" ] } ], "data_elements": [ { "id": "parent-relationship", "name": "Parent or structural relationship", "description": "A typed link to another registered entity with period, qualifier and evidence.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "relationship-type-code", "name": "Relationship type code", "description": "Governed code for the kind of structural relationship.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "relationship-validation-level", "name": "Relationship validation level", "description": "Corroboration strength of the reported relationship.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] }, { "id": "reporting-exception-reason", "name": "Reporting exception reason", "description": "Coded reason why no relationship is reported.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-005" ] } ], "artifacts": [ { "id": "relationship-validation-document", "name": "Relationship validation document", "description": "Evidence supporting a reported structural relationship.", "media_or_form": [ "consolidated financial statements", "regulatory filing", "ownership contract or official document" ], "serial": true, "identity_strategy": "Filer identifier plus document type, period covered and publication date in RFC 3339.", "source_refs": [ "SRC-005" ] } ], "inline_only_rationale": null } ] }, { "id": "control-representation-and-ownership-linkage", "name": "Control, representation and ownership linkage", "description": "The pointer to control information and the registration facts about who may act for the entity.", "source_refs": [ "SRC-018", "SRC-015", "SRC-017", "SRC-008" ], "findings": [ { "id": "beneficial-ownership-register-linkage", "name": "Beneficial ownership register linkage", "description": "The pointer from the registration record to the mechanism holding beneficial ownership or persons-with-significant-control information, its holding mechanism type and its access regime — the linkage only, never the ownership content. International standards allow a registry or an alternative mechanism, and the access regime is materially narrower than for core company particulars and has been changed by litigation and by national rule changes.", "source_refs": [ "SRC-018", "SRC-015", "SRC-017" ], "questions": [ { "id": "bo-holding-mechanism", "text": "Which mechanism holds beneficial ownership information for this entity?", "kind": "composition", "answer_data": [ "Mechanism type: central register, company-held register, or alternative mechanism", "Holder organization and jurisdiction", "Statutory basis and its current version date" ] }, { "id": "bo-link-identifier", "text": "What identifier links the registration record to the beneficial ownership record?", "kind": "identity", "answer_data": [ "Beneficial ownership record identifier", "Linking identifier and scheme", "Date the link was asserted and by whom" ] }, { "id": "bo-access-regime", "text": "Who may access the beneficial ownership record, and on what legal basis?", "kind": "access", "answer_data": [ "Access tier: competent authority, obliged entity, legitimate interest, public", "Legitimate-interest test applied", "Whether public access has been suspended or invalidated in this jurisdiction" ] }, { "id": "bo-currency", "text": "How current must the linked information be, and when was it last confirmed?", "kind": "quality", "answer_data": [ "Update obligation and deadline after a change", "Date of last confirmation", "Whether a discrepancy has been reported against it" ] } ], "data_elements": [ { "id": "beneficial-ownership-record-reference", "name": "Beneficial ownership record reference", "description": "Pointer to the record or mechanism holding beneficial ownership information.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "bo-holding-mechanism-code", "name": "Beneficial ownership holding mechanism code", "description": "Type of mechanism holding the information.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018" ] }, { "id": "bo-access-tier-code", "name": "Beneficial ownership access tier code", "description": "Access classification applicable to the linked record.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-015", "SRC-018" ] } ], "artifacts": [], "inline_only_rationale": "Only the linkage and its access classification are in scope. The ownership and control content, including natural-person particulars, belongs to a separate beneficial ownership model referenced by composition; holding copies here would replicate restricted personal data outside its access regime." }, { "id": "officers-and-authority-to-represent", "name": "Officers and authority to represent", "description": "Registered officers and representatives and the derived question of who may validly bind the entity, recorded as dated registration facts plus evidence of authority for a specific act. Registers publish suppression regimes for officer details, so the presence of a role does not guarantee the presence of the person's particulars.", "source_refs": [ "SRC-008", "SRC-010", "SRC-006", "SRC-009" ], "questions": [ { "id": "registered-officer-roles", "text": "Which officer or representative roles are recorded in the register, with what appointment and cessation dates?", "kind": "ownership", "answer_data": [ "Role type code", "Appointment date and cessation date", "Reference to the person or corporate officer record" ] }, { "id": "representation-rule", "text": "What representation rule applies — sole, joint, or limited by class of act — and where is it stated?", "kind": "authority", "answer_data": [ "Representation rule text as recorded", "Source document and article reference", "Scope and monetary or subject-matter restrictions" ] }, { "id": "authority-verification", "text": "How is authority to act evidenced for a specific transaction, and when was it verified?", "kind": "evidence", "answer_data": [ "Authority instrument reference", "Verification method and verifier", "Verification timestamp in RFC 3339 and validity window" ] }, { "id": "officer-detail-suppression", "text": "Are any officer details suppressed or protected, and under what regime?", "kind": "privacy", "answer_data": [ "Suppression flag and scheme", "Eligibility ground", "Which fields remain visible to which requester categories" ] } ], "data_elements": [ { "id": "registered-officer-role", "name": "Registered officer role", "description": "A recorded office or representative role with dates and person reference.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-008", "SRC-006" ] }, { "id": "data-representation-rule", "name": "Representation rule", "description": "Rule determining how the entity is validly bound.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-010", "SRC-009" ] }, { "id": "authority-verification-record", "name": "Authority verification record", "description": "A dated verification that a named representative could bind the entity for a stated act.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "proof-of-authority-instrument", "name": "Proof of authority instrument", "description": "Instrument evidencing that a person may act for the entity.", "media_or_form": [ "board or shareholder resolution", "power of attorney, including digital forms", "register extract naming representatives" ], "serial": true, "identity_strategy": "Issuing body plus instrument reference and execution date in RFC 3339; fallback is issuer plus content hash bound to the signing key.", "source_refs": [ "SRC-010", "SRC-008" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "evidence-verification-and-quality", "name": "Evidence, verification and quality", "description": "What proves each registration fact, how strongly it was corroborated, and how discrepancies are detected and resolved.", "rationale": "Reference-data formats make validation sources, validation authorities and corroboration levels first-class fields rather than metadata, and registry guidance treats accuracy and liability as core registry design. An agent that cannot state how strongly a fact is evidenced cannot safely act on it.", "source_refs": [ "SRC-002", "SRC-001", "SRC-005", "SRC-009", "SRC-010" ], "layers": [ { "id": "evidence-and-validation", "name": "Evidence and validation", "description": "Documentary evidence for registration facts and the strength of their corroboration.", "source_refs": [ "SRC-002", "SRC-010", "SRC-001", "SRC-005" ], "findings": [ { "id": "registration-evidence-documents-and-extracts", "name": "Registration evidence documents and extracts", "description": "Documents that evidence registration facts — certificates of incorporation or good standing, dated register extracts, gazette publications and cross-border company certificates — each speaking as of a point in time and each requiring authentication before reliance. Extracts age: an extract is a dated snapshot, not a standing truth, which is why an as-of timestamp and a freshness window are mandatory.", "source_refs": [ "SRC-010", "SRC-008", "SRC-002", "SRC-009" ], "questions": [ { "id": "which-document-evidences-what", "text": "Which document evidences each registration fact, and who issued it?", "kind": "evidence", "answer_data": [ "Document type and the facts it evidences", "Issuing authority and its identifier", "Issue date in RFC 3339" ] }, { "id": "extract-as-of-and-freshness", "text": "As of what date do the extract's contents speak, and how long is it treated as current?", "kind": "temporal", "answer_data": [ "Extract as-of date and time", "Freshness window applied by the relying process", "Expiry or re-request policy" ] }, { "id": "document-authentication", "text": "Is the document authenticated, and how is authenticity checked?", "kind": "validation", "answer_data": [ "Authentication method: seal, qualified signature, verifiable credential, apostille", "Verification result and verifier", "Verification timestamp" ] }, { "id": "cross-border-usability", "text": "Is a translation or legalization required for cross-border use?", "kind": "interoperability", "answer_data": [ "Translation requirement and certifying body", "Legalization or apostille type", "Whether a cross-border certificate removes the requirement" ] } ], "data_elements": [ { "id": "evidence-document-reference", "name": "Evidence document reference", "description": "Reference to a document evidencing one or more registration facts.", "value_kind": "reference", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-010", "SRC-008" ] }, { "id": "extract-as-of-date", "name": "Extract as-of timestamp", "description": "Point in time as of which an extract's contents are stated to be accurate.", "value_kind": "timestamp", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010", "SRC-002" ] }, { "id": "authentication-method-code", "name": "Authentication method code", "description": "How the document's authenticity is established.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-010" ] } ], "artifacts": [ { "id": "register-extract-or-certificate", "name": "Register extract or certificate", "description": "An issued, dated statement of registration facts drawn from the authoritative register.", "media_or_form": [ "certificate of incorporation or good standing", "dated register extract", "cross-border company certificate", "signed digital document or verifiable credential" ], "serial": true, "identity_strategy": "Issuing register plus extract or certificate reference and as-of timestamp in RFC 3339; fallback is a content hash bound to the issuer. A date alone is never the identifier because multiple extracts may be issued the same day.", "source_refs": [ "SRC-010", "SRC-008", "SRC-009" ] } ], "inline_only_rationale": null }, { "id": "validation-sources-and-corroboration-level", "name": "Validation sources and corroboration level", "description": "How each recorded fact was validated: which source was consulted, what role it plays, which validation authority and local identifier were used, and what corroboration level was achieved. Corroboration is graded, not binary, and the grade must travel with the data.", "source_refs": [ "SRC-002", "SRC-001", "SRC-005", "SRC-003" ], "questions": [ { "id": "which-source-per-field", "text": "Which source was consulted to validate each field, and is it the authoritative register or a secondary source?", "kind": "provenance", "answer_data": [ "Validation source code and reference", "Source role: registration authority, validation authority, other validation source", "Per-field attribution" ] }, { "id": "corroboration-grade", "text": "What corroboration level does the record achieve?", "kind": "quality", "answer_data": [ "Corroboration level code", "Per-field breakdown where levels differ", "Assessment date and assessor" ] }, { "id": "validation-authority-identity", "text": "Which validation authority and which local identifier were used for corroboration?", "kind": "authority", "answer_data": [ "Validation authority code from a governed list", "Entity identifier at that validation authority", "Other validation authorities consulted" ] }, { "id": "revalidation-cadence", "text": "How often must validation be repeated and what triggers re-validation?", "kind": "process", "answer_data": [ "Revalidation cadence", "Trigger events: legal entity event, renewal date, discrepancy report", "Timestamp of last validation" ] } ], "data_elements": [ { "id": "validation-source-code", "name": "Validation source code", "description": "Coded indication of the source and method used to validate the recorded facts.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-002", "SRC-001" ] }, { "id": "validation-authority-code", "name": "Validation authority code", "description": "Governed code of the authority used to corroborate the record.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-003" ] }, { "id": "corroboration-level", "name": "Corroboration level", "description": "Graded strength of corroboration achieved for the record or a field.", "value_kind": "code", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-005", "SRC-002" ] }, { "id": "last-validation-timestamp", "name": "Last validation timestamp", "description": "Time at which validation was last performed, in RFC 3339.", "value_kind": "timestamp", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] } ], "artifacts": [ { "id": "validation-evidence-package", "name": "Validation evidence package", "description": "The captured material proving that validation was performed against a named source at a named time.", "media_or_form": [ "captured source response or file", "rendered page capture", "signed API response" ], "serial": true, "identity_strategy": "Source system identifier plus retrieval timestamp in RFC 3339 and content hash; the hash establishes integrity only, never business identity.", "source_refs": [ "SRC-002", "SRC-001" ] } ], "inline_only_rationale": null } ] }, { "id": "quality-and-conflict-management", "name": "Quality and conflict management", "description": "Detecting, reporting and resolving divergence between the register record and other sources.", "source_refs": [ "SRC-009", "SRC-018", "SRC-008", "SRC-005" ], "findings": [ { "id": "data-quality-discrepancies-and-challenge-process", "name": "Data quality, discrepancies and challenge process", "description": "Detection, reporting and resolution of divergence between the register record and other authoritative or self-reported sources, including statutory discrepancy-reporting duties on obliged entities and the register's own correction or challenge procedure. Unresolved conflicts must be represented explicitly rather than silently resolved by picking a value.", "source_refs": [ "SRC-009", "SRC-018", "SRC-008", "SRC-002" ], "questions": [ { "id": "what-discrepancies-exist", "text": "Which discrepancies exist between the register record and other sources?", "kind": "quality", "answer_data": [ "Discrepancy type and affected fields", "Conflicting values with their sources", "Detection timestamp and detection method" ] }, { "id": "discrepancy-reporting-duty", "text": "Is there a duty to report the discrepancy, to whom, and within what deadline?", "kind": "requirement", "answer_data": [ "Reporting duty flag and legal basis", "Recipient authority", "Deadline and evidence of submission" ] }, { "id": "correction-process", "text": "What process corrects an erroneous register entry, and who may initiate it?", "kind": "process", "answer_data": [ "Correction or challenge procedure", "Eligible initiators", "Expected duration and interim status of the record" ] }, { "id": "automated-quality-checks", "text": "Which quality checks run automatically and at what thresholds?", "kind": "validation", "answer_data": [ "Check identifier and rule expression", "Severity and threshold", "Pass or fail result with run timestamp" ] }, { "id": "representing-unresolved-conflict", "text": "How is an unresolved conflict represented so downstream consumers are not misled?", "kind": "decision", "answer_data": [ "Conflict marker attached to the affected fields", "Confidence annotation and rationale", "Preferred-value rule and the fact that it is provisional" ] } ], "data_elements": [ { "id": "discrepancy-record", "name": "Discrepancy record", "description": "A recorded divergence between sources with values, detection metadata and status.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-018", "SRC-009" ] }, { "id": "quality-check-result", "name": "Quality check result", "description": "Outcome of an automated validation rule against the record.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-002", "SRC-005" ] }, { "id": "correction-request", "name": "Correction or challenge request", "description": "A submitted request to correct the register entry, with initiator, date and outcome.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-009", "SRC-008" ] } ], "artifacts": [ { "id": "discrepancy-report", "name": "Discrepancy report", "description": "The notice submitted to a register or authority recording a divergence, or the internal report documenting it.", "media_or_form": [ "structured discrepancy notice", "regulator submission receipt", "internal data quality report" ], "serial": true, "identity_strategy": "Reporting party plus report reference and submission timestamp in RFC 3339.", "source_refs": [ "SRC-018", "SRC-009" ] } ], "inline_only_rationale": null } ] } ] }, { "id": "governance-access-provenance-and-retention", "name": "Governance, access, provenance and retention", "description": "Who may see what, how personal data in register records is handled, how every assertion is attributed, and how long records must survive.", "rationale": "Register data is publicly disclosable by design yet contains personal data, and the two pull in opposite directions. Courts have held both that no general erasure right exists against a companies register and that unrestricted public access to beneficial ownership data is disproportionate. A model that treats register data as uniformly open or uniformly restricted will be wrong in one direction or the other.", "source_refs": [ "SRC-009", "SRC-015", "SRC-019", "SRC-010", "SRC-002", "SRC-006" ], "layers": [ { "id": "access-publicity-and-privacy", "name": "Access, publicity and privacy", "description": "Disclosure tiers and the handling of personal data within registration records.", "source_refs": [ "SRC-009", "SRC-015", "SRC-019", "SRC-008" ], "findings": [ { "id": "public-disclosure-tiers-and-access-conditions", "name": "Public disclosure tiers and access conditions", "description": "Who may see what: the free-to-all core that registry guidance says should be available to everyone without discrimination and at low or zero cost, versus fee-bearing, registration-gated, legitimate-interest and competent-authority-only tiers. Reuse licence conditions attach to disclosed data and constrain redistribution.", "source_refs": [ "SRC-009", "SRC-015", "SRC-010", "SRC-008" ], "questions": [ { "id": "which-fields-public", "text": "Which fields and documents are public without restriction, and which require registration, fee or a legitimate-interest test?", "kind": "access", "answer_data": [ "Access tier per field and per document type", "Gating condition and how it is evaluated", "Fee schedule and its effective date" ] }, { "id": "requester-categories", "text": "Which categories of requester are recognised and how are they authenticated?", "kind": "security", "answer_data": [ "Requester category definitions", "Authentication method per category", "Evidence retained of authorization" ] }, { "id": "reuse-licence", "text": "What licence or reuse conditions attach to the disclosed data?", "kind": "ownership", "answer_data": [ "Licence identifier and version", "Attribution requirement text", "Redistribution and caching limits" ] }, { "id": "restricted-access-logging", "text": "What must be logged when restricted content is accessed?", "kind": "evidence", "answer_data": [ "Audit event fields required", "Retention period for access logs", "Any duty to notify the data subject" ] } ], "data_elements": [ { "id": "access-tier-code", "name": "Access tier code", "description": "Classification determining who may read a field, document or record.", "value_kind": "code", "cardinality": "1..n", "required": true, "source_refs": [ "SRC-009", "SRC-015" ] }, { "id": "reuse-licence-identifier", "name": "Reuse licence identifier", "description": "Identifier of the licence governing reuse and redistribution of the disclosed data.", "value_kind": "identifier", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008", "SRC-009" ] }, { "id": "gating-condition", "name": "Gating condition", "description": "Condition that must be satisfied before restricted content is released.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-015", "SRC-009" ] } ], "artifacts": [], "inline_only_rationale": "Access rules are policy statements evaluated at request time, not stored documents. The governing terms are cited to the operating register and enforced through the Vercy access service layer; materialising them as artifacts would create a stale second copy of a live policy." }, { "id": "personal-data-in-registration-records", "name": "Personal data in registration records", "description": "Personal data unavoidably present in registration records — officers, agents, and registered addresses that are also private residences — and the constraints that follow. Settled case law holds there is no general right to erasure from a companies register even after the company ceases to exist, because no suitable maximum retention period can be identified, while a case-by-case right to object may exist; suppression regimes operate as the practical remedy.", "source_refs": [ "SRC-019", "SRC-015", "SRC-008", "SRC-009" ], "questions": [ { "id": "personal-data-inventory", "text": "Which fields in the registration record contain personal data, and whose?", "kind": "privacy", "answer_data": [ "Field inventory with data subject category", "Lawful basis for processing each", "Whether the field is public, gated or suppressed" ] }, { "id": "suppression-regimes", "text": "Which suppression, protection or redaction regimes are available, and how are they flagged?", "kind": "exception", "answer_data": [ "Suppression scheme name and eligibility criteria", "Applied flag and its effective date", "Fields affected and residual visibility" ] }, { "id": "erasure-and-objection", "text": "Can a data subject obtain erasure or restriction, and what is the settled position?", "kind": "retention", "answer_data": [ "Availability of erasure and its limits", "Scope of any right to object and the balancing test", "Authority competent to decide" ] }, { "id": "downstream-personal-data", "text": "How is personal data handled when the record is redistributed or cached downstream?", "kind": "security", "answer_data": [ "Redistribution rule inherited from the source register", "Minimisation profile applied on export", "Obligations imposed on downstream recipients" ] } ], "data_elements": [ { "id": "personal-data-field-inventory", "name": "Personal data field inventory", "description": "Enumerated fields carrying personal data, with data subject category and lawful basis.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-008" ] }, { "id": "suppression-flag", "name": "Suppression flag", "description": "Whether a protection or suppression regime has been applied to any field.", "value_kind": "boolean", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-008" ] }, { "id": "lawful-basis-reference", "name": "Lawful basis reference", "description": "Citation of the legal basis relied on for processing register-sourced personal data.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-019", "SRC-015" ] } ], "artifacts": [], "inline_only_rationale": "This finding governs the handling of fields already modelled elsewhere and produces policy annotations rather than standalone documents. Suppression applications are themselves register filings, already covered by mandatory-disclosure-particulars-and-filing-obligations." } ] }, { "id": "provenance-retention-and-interoperability", "name": "Provenance, retention and interoperability", "description": "Attribution of every fact to its source and time, survival of the record over time, and alignment to external vocabularies and exchange protocols.", "source_refs": [ "SRC-002", "SRC-006", "SRC-012", "SRC-014", "SRC-019" ], "findings": [ { "id": "provenance-source-attribution-and-observation-time", "name": "Provenance, source attribution and observation time", "description": "Full attribution of every recorded fact to its source, retrieval method, retrieving agent and time, keeping three clocks separate: when the event took legal effect, when the register recorded it, and when we observed it. Collapsing these makes it impossible to reconstruct what was knowable at a past decision point.", "source_refs": [ "SRC-002", "SRC-006", "SRC-001" ], "questions": [ { "id": "source-of-each-fact", "text": "From which source system, endpoint or file was each fact obtained, and at which version?", "kind": "provenance", "answer_data": [ "Source system identifier", "Endpoint, file or bulk-export reference", "Source format version and code-list versions in force" ] }, { "id": "three-clocks", "text": "What are the event time, the register's recorded time and our observation time for each fact?", "kind": "temporal", "answer_data": [ "Event timestamp or date with precision marker", "Register recorded date", "Observation timestamp in RFC 3339 with explicit offset or Z" ] }, { "id": "retrieving-agent", "text": "Which agent performed the retrieval and under what authorization?", "kind": "authority", "answer_data": [ "Agent identifier and software version", "Credential or scope used", "Run identifier for the retrieval job" ] }, { "id": "payload-preservation", "text": "How is the retrieved payload preserved so the assertion can be re-checked later?", "kind": "evidence", "answer_data": [ "Snapshot artifact reference", "Content hash and named hash algorithm", "Storage location and its retention class" ] } ], "data_elements": [ { "id": "source-system-identifier", "name": "Source system identifier", "description": "Identifier of the system, endpoint or publication from which a fact was obtained.", "value_kind": "identifier", "cardinality": "1", "required": true, "source_refs": [ "SRC-002", "SRC-006" ] }, { "id": "provenance-observation-timestamp", "name": "Provenance observation timestamp", "description": "RFC 3339 timestamp at which the fact was observed or ingested.", "value_kind": "timestamp", "cardinality": "1", "required": true, "source_refs": [ "SRC-002" ] }, { "id": "payload-content-hash", "name": "Payload content hash", "description": "Hash of the retrieved payload with its algorithm, used for integrity only.", "value_kind": "text", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-002" ] }, { "id": "retrieval-agent-reference", "name": "Retrieval agent reference", "description": "Reference to the agent or job that performed the retrieval.", "value_kind": "reference", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-006" ] } ], "artifacts": [ { "id": "source-snapshot-file", "name": "Source snapshot file", "description": "The preserved bulk export, API response or archived document from which facts were derived.", "media_or_form": [ "bulk register export or golden-copy file", "captured API response", "archived source document" ], "serial": true, "identity_strategy": "Publisher plus publication or retrieval timestamp in RFC 3339 and file sequence number; content hash records integrity but is never the primary business identity.", "source_refs": [ "SRC-001", "SRC-002" ] } ], "inline_only_rationale": null }, { "id": "record-history-retention-and-deletion-constraints", "name": "Record history, retention and deletion constraints", "description": "How prior states are kept, how long records survive dissolution, and where deletion is constrained. Public-authority policy for the global identifier system requires data history alongside events, and case law establishes that no single maximum retention period can be identified for register data, so retention must be declared per jurisdiction rather than assumed.", "source_refs": [ "SRC-011", "SRC-019", "SRC-009", "SRC-018" ], "questions": [ { "id": "history-granularity", "text": "Which historical versions of the record are retained and at what granularity?", "kind": "retention", "answer_data": [ "Version granularity: field-level, record-level, or snapshot", "History depth retained", "Where superseded values are stored" ] }, { "id": "post-dissolution-retention", "text": "For how long after dissolution must the record be retained, and by whom?", "kind": "retention", "answer_data": [ "Retention period and its statutory basis", "Party bearing the retention duty", "Whether the duty differs for the register and for downstream holders" ] }, { "id": "deletion-and-tombstone", "text": "Under what circumstances may data be deleted or de-published, and what tombstone remains?", "kind": "exception", "answer_data": [ "Deletion or de-publication trigger", "Tombstone content retained: identifier, jurisdiction, closure reason", "Approving authority and approval record" ] }, { "id": "retention-conflict-resolution", "text": "How are retention conflicts between register duties and privacy demands resolved?", "kind": "decision", "answer_data": [ "Conflict description and competing bases", "Balancing test outcome and reasoning", "Decision record with decider and timestamp" ] } ], "data_elements": [ { "id": "retention-period", "name": "Retention period", "description": "Declared minimum period for which the record must be retained, expressed as a duration.", "value_kind": "duration", "cardinality": "0..1", "required": false, "source_refs": [ "SRC-018", "SRC-009" ] }, { "id": "record-version-history", "name": "Record version history", "description": "Ordered set of superseded record versions with validity intervals.", "value_kind": "collection", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-011" ] }, { "id": "deletion-constraint", "name": "Deletion constraint", "description": "A stated legal or policy constraint preventing deletion of specified data.", "value_kind": "text", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-019", "SRC-009" ] } ], "artifacts": [ { "id": "record-history-archive", "name": "Record history archive", "description": "The retained history of the registration record across its versions.", "media_or_form": [ "append-only change log", "archived record versions", "register-issued history extract" ], "serial": true, "identity_strategy": "Record identifier plus version number and version timestamp in RFC 3339; versions are ordered by timestamp with the version number breaking ties.", "source_refs": [ "SRC-011", "SRC-008" ] } ], "inline_only_rationale": null }, { "id": "interoperability-mappings-and-exchange-projections", "name": "Interoperability mappings and exchange projections", "description": "Alignment of this model to external vocabularies and exchange protocols, recorded as version-pinned mappings with explicit conflicts rather than conformance claims. Register-to-register exchange uses service-based electronic communication with standard protocols and defined message types, which the model must be able to feed without becoming coupled to any one of them.", "source_refs": [ "SRC-006", "SRC-007", "SRC-012", "SRC-014", "SRC-013", "SRC-010" ], "questions": [ { "id": "aligned-vocabularies", "text": "Which external vocabularies and schemas is this model aligned to, and at which versions?", "kind": "interoperability", "answer_data": [ "Target vocabulary identifier and version", "Mapping direction: export, import, or bidirectional", "Date the mapping was last revalidated" ] }, { "id": "mapping-fidelity", "text": "Which fields map cleanly, which map with loss, and which have no counterpart?", "kind": "validation", "answer_data": [ "Per-field mapping status", "Description of information lost on projection", "List of unmapped fields in each direction" ] }, { "id": "exchange-protocols", "text": "Which register-to-register or downstream exchange protocols must be supported, and what message types do they define?", "kind": "process", "answer_data": [ "Protocol name and transport requirements", "Message types and their mandatory data sets", "Identifier scheme required by the protocol" ] }, { "id": "semantic-conflicts", "text": "Where do external models conflict semantically, and how is the conflict recorded rather than hidden?", "kind": "decision", "answer_data": [ "Conflict statement and affected concepts", "Which model's definition is authoritative for which use", "Recorded stance and review date" ] } ], "data_elements": [ { "id": "vocabulary-alignment", "name": "Vocabulary alignment", "description": "A version-pinned mapping between this model and an external vocabulary.", "value_kind": "object", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-006", "SRC-007", "SRC-012" ] }, { "id": "field-mapping-status", "name": "Field mapping status", "description": "Per-field fidelity of a mapping: exact, lossy, or unmapped.", "value_kind": "code", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-007", "SRC-012" ] }, { "id": "exchange-protocol-reference", "name": "Exchange protocol reference", "description": "Reference to a protocol and message type this model must feed.", "value_kind": "reference", "cardinality": "0..n", "required": false, "source_refs": [ "SRC-014", "SRC-013" ] } ], "artifacts": [ { "id": "interoperability-mapping-profile", "name": "Interoperability mapping profile", "description": "The published crosswalk between this model and a named external vocabulary or exchange format.", "media_or_form": [ "mapping table", "machine-readable crosswalk", "published alignment profile document" ], "serial": true, "identity_strategy": "This model identifier and version plus target vocabulary identifier and version, with the profile publication date in RFC 3339.", "source_refs": [ "SRC-006", "SRC-012", "SRC-014" ] } ], "inline_only_rationale": null } ] } ] } ] }, "functions": [ { "id": "resolve-registration-identity", "name": "Resolve registration identity", "description": "Resolve a candidate organization description to a single authoritative register record, or report that no confident resolution exists.", "inputs": [ "Candidate legal name and any known variants", "Jurisdiction hint at country and subdivision level", "Any candidate identifiers with their scheme codes", "Address hint" ], "outputs": [ "Resolved registration authority code and register entity identifier", "Match confidence with the evidence used", "Ranked alternatives when resolution is ambiguous", "Explicit no-match result with reason" ], "preconditions": [ "A version-pinned registration authority list is loaded", "The jurisdiction is within the declared coverage of the owner package" ], "effects": [ "Creates or reuses an identity assertion with an observation timestamp", "Records the resolution evidence and any rejected candidates", "Never silently mints a local identifier when an authoritative one is discoverable" ], "source_refs": [ "SRC-003", "SRC-002", "SRC-009" ] }, { "id": "validate-identifier-syntax", "name": "Validate identifier syntax and scheme", "description": "Check that an identifier conforms to the format and any checksum defined by its scheme, and that the scheme code itself is known.", "inputs": [ "Identifier value", "Scheme code", "Scheme code-list version" ], "outputs": [ "Pass or fail result with the failing rule", "Normalised identifier form", "Scheme metadata: issuing authority and applicable jurisdictions" ], "preconditions": [ "The scheme code list is loaded at a pinned version" ], "effects": [ "Rejects identifiers whose scheme is unknown rather than storing them unqualified", "Records the code-list version used for the check" ], "source_refs": [ "SRC-013", "SRC-012", "SRC-002" ] }, { "id": "ingest-register-record", "name": "Ingest register record with provenance", "description": "Retrieve a register record or bulk export and store it as timestamped assertions with full source attribution.", "inputs": [ "Source system reference and endpoint or file", "Retrieval credentials and scope", "Target registration record identity" ], "outputs": [ "Set of typed field assertions with source and observation time", "Snapshot artifact reference and content hash", "Change set relative to the previously held state" ], "preconditions": [ "Access to the source is authorized and within its licence terms", "Retrieval agent identity is established" ], "effects": [ "Appends assertions without overwriting prior values", "Preserves the retrieved payload as a serial snapshot artifact", "Records event time, register recorded time and observation time separately" ], "source_refs": [ "SRC-002", "SRC-001", "SRC-006" ] }, { "id": "apply-legal-entity-event", "name": "Apply legal entity event", "description": "Record a typed legal entity event and derive the field changes, identifier retirements and successor links it implies.", "inputs": [ "Event type code and code-list version", "Effective date and register recorded date", "Validation document references", "Affected registration record" ], "outputs": [ "Closed prior field assertions with end dates", "New field assertions with effective dates", "Successor and predecessor links where applicable", "Identifier retirement or assignment records" ], "preconditions": [ "The event type exists in the pinned event code list", "At least one validation document is supplied for identity-affecting events" ], "effects": [ "Extends the record history rather than mutating it in place", "Triggers re-validation where the event affects identity, status or jurisdiction" ], "source_refs": [ "SRC-011", "SRC-002", "SRC-010" ] }, { "id": "compute-current-status", "name": "Compute current status as of a time", "description": "Return the entity status, record status and standing signals that were true as of a given instant, using the stored assertion history.", "inputs": [ "Registration record identity", "As-of timestamp in RFC 3339" ], "outputs": [ "Entity status and record status as of that instant", "Active standing signals such as removal proposals and overdue filings", "The assertions and sources the answer rests on" ], "preconditions": [ "Assertion history is retained at least back to the requested instant" ], "effects": [ "Returns a knowledge-limited answer flagged as such when history does not reach the requested instant", "Does not extrapolate a status forward past its last observation without marking it stale" ], "source_refs": [ "SRC-002", "SRC-008", "SRC-011" ] }, { "id": "request-and-verify-evidence", "name": "Request and verify registration evidence", "description": "Obtain a dated extract or certificate and verify its authenticity and freshness before it is relied on.", "inputs": [ "Registration record identity", "Required evidence type and freshness window", "Intended use, including cross-border use" ], "outputs": [ "Evidence artifact with as-of timestamp", "Authentication verification result", "Translation or legalization requirement determination" ], "preconditions": [ "The issuing register is reachable and the requester meets its access tier" ], "effects": [ "Stores the evidence artifact with issuer, reference and as-of timestamp", "Marks previously relied-on evidence as superseded rather than deleting it" ], "source_refs": [ "SRC-010", "SRC-008", "SRC-009" ] }, { "id": "link-alternate-identifier", "name": "Link alternate identifier", "description": "Attach an identifier from another scheme to the registration record with an explicit equivalence assertion and evidence.", "inputs": [ "Alternate identifier value and scheme code", "Evidence supporting equivalence", "Unit type the identifier actually denotes" ], "outputs": [ "Equivalence assertion with strength and evidence", "Conflict record where the alternate identifier contradicts the register", "Updated identifier set for the record" ], "preconditions": [ "Scheme code validated against a pinned code list", "Authoritative register identity already resolved" ], "effects": [ "Never promotes an alternate identifier above the register-assigned identity", "Raises a conflict rather than overwriting when values disagree" ], "source_refs": [ "SRC-013", "SRC-012", "SRC-002" ] }, { "id": "detect-and-report-discrepancy", "name": "Detect and report discrepancy", "description": "Compare the register record with other held sources, classify divergence and discharge any statutory reporting duty.", "inputs": [ "Registration record and its assertions", "Comparison sources and their observation times", "Applicable reporting duty configuration" ], "outputs": [ "Discrepancy records with conflicting values and sources", "Reporting submission where a duty applies", "Conflict markers attached to affected fields" ], "preconditions": [ "Both sides of the comparison carry observation timestamps", "Reporting duty configuration is current for the jurisdiction" ], "effects": [ "Marks affected fields as contested until resolved", "Creates an auditable report artifact when a duty is discharged" ], "source_refs": [ "SRC-018", "SRC-009", "SRC-008" ] }, { "id": "evaluate-access-request", "name": "Evaluate access request against tier", "description": "Decide whether a requester may read specified fields, documents or artifacts, and produce the audit record.", "inputs": [ "Requester identity and category", "Requested scope: bundle, layer, finding or artifact", "Stated purpose and legal basis" ], "outputs": [ "Allow or deny decision per requested field", "Minimised payload where partial access applies", "Audit event with legal basis and RFC 3339 timestamp" ], "preconditions": [ "Access tiers are classified for every requested field", "Requester category is authenticated" ], "effects": [ "Denies by default for restricted tiers", "Withholds suppressed personal data regardless of tier absent an evidenced statutory override", "Writes an audit event for every restricted-tier access" ], "source_refs": [ "SRC-015", "SRC-009", "SRC-019" ] }, { "id": "project-to-exchange-format", "name": "Project record to an exchange format", "description": "Render the format-neutral record into a named external vocabulary or exchange message, declaring what is lost.", "inputs": [ "Registration record identity", "Target vocabulary or protocol and version", "Access tier of the recipient" ], "outputs": [ "Projected payload in the target format", "Loss report listing lossy and unmapped fields", "Applied minimisation profile for personal data" ], "preconditions": [ "A version-pinned mapping profile exists for the target", "Recipient access tier is established" ], "effects": [ "Emits a projection without altering the canonical record", "Attaches the mapping profile version to the output so the projection is reproducible", "Makes no conformance claim beyond the cited mapping" ], "source_refs": [ "SRC-006", "SRC-012", "SRC-014", "SRC-013" ] }, { "id": "close-or-supersede-record", "name": "Close or supersede a registration record", "description": "Close a record on dissolution, transfer out or supersession, retaining a tombstone and honouring retention duties.", "inputs": [ "Registration record identity", "Closure reason and effective date", "Successor record reference where applicable" ], "outputs": [ "Closed record with tombstone: identifier, jurisdiction, closure reason and date", "Retention classification and earliest permissible disposal date", "Successor link where the entity continues elsewhere" ], "preconditions": [ "Closure evidence is supplied", "No unmet retention duty blocks the requested disposition" ], "effects": [ "Never hard-deletes while a retention duty applies", "Preserves the identifier as retired rather than releasing it for reuse", "Keeps the record resolvable so historical references do not dangle" ], "source_refs": [ "SRC-019", "SRC-009", "SRC-011", "SRC-002" ] }, { "id": "submit-register-filing", "name": "Update register particulars", "description": "File and publish changes to name, registered office, representatives, capital, objects, legal form or other disclosed particulars, with event-effective time distinct from filing time.", "inputs": [ "authorised filing", "changed particulars", "event effective time", "evidence documents" ], "outputs": [ "updated register file", "serial artefact version", "last-update timestamp and reason" ], "preconditions": [ "Filer is a person authorised to bind the entity or a competent authority or liquidator.", "Entity has not been finally dissolved unless the update is a quality or winding-up amendment." ], "effects": [ "Disclosed record matches the new legal facts from the event effective time.", "Third-party reliance follows the disclosure rules of the jurisdiction." ], "source_refs": [ "SRC-022", "SRC-021" ] } ], "composition": [ { "target": "WM-ORG-001 Organization (registered parent model)", "relation": "CHILD", "purpose": "WM-ORG-010 specialises the parent organization concept to the subset that has registered legal status, mirroring the org:Organization to org:FormalOrganization to rov:RegisteredOrganization narrowing. The parent owns organization identity in general; this model owns the registration facts.", "required": true, "source_refs": [ "SRC-006", "SRC-007" ] }, { "target": "Beneficial ownership and control model (sibling)", "relation": "REFERENCE", "purpose": "Hold ownership and control content, including natural-person particulars, under its own access regime. This model carries only the pointer, holding-mechanism type and access tier.", "required": true, "source_refs": [ "SRC-018", "SRC-015" ] }, { "target": "Postal address and location model (sibling)", "relation": "COMPOSE", "purpose": "Supply the structured address type used for legal, headquarters and other recorded addresses, and own geocoding and premises identity, which are outside registration scope.", "required": true, "source_refs": [ "SRC-002", "SRC-006" ] }, { "target": "Jurisdiction and geopolitical unit model (sibling)", "relation": "REFERENCE", "purpose": "Resolve country and subdivision codes, jurisdictional hierarchy and the legal systems that give legal forms their meaning; legal form and jurisdiction are interdependent and must resolve against a governed jurisdiction set.", "required": true, "source_refs": [ "SRC-004", "SRC-002" ] }, { "target": "Document and evidence model (sibling)", "relation": "COMPOSE", "purpose": "Own generic document lifecycle, storage, rendering and signature verification, so that certificates, extracts, filings and gazette notices are typed evidence here rather than duplicated document machinery.", "required": true, "source_refs": [ "SRC-010", "SRC-008" ] }, { "target": "Natural person and party identity model (sibling)", "relation": "REFERENCE", "purpose": "Resolve officers, representatives and registered agents to person records without importing person identity or employment semantics into the registration record.", "required": false, "source_refs": [ "SRC-006", "SRC-008" ] }, { "target": "Provenance and observation mixin", "relation": "MIX-IN", "purpose": "Apply uniform source attribution, retrieving-agent identity, and the separation of event time, source-recorded time and observation time to every assertion in this model.", "required": true, "source_refs": [ "SRC-002", "SRC-006" ] }, { "target": "Bitemporal versioning and history mixin", "relation": "MIX-IN", "purpose": "Provide append-only assertion history with validity and transaction intervals, which the legal entity events and data history requirement depends on.", "required": true, "source_refs": [ "SRC-011", "SRC-002" ] }, { "target": "Tax registration and fiscal identifier model (sibling)", "relation": "REFERENCE", "purpose": "Own fiscal registration, assessment and compliance. This model carries tax and VAT numbers only as scheme-qualified alternate identifiers and makes no inference about tax status from business-register presence.", "required": false, "source_refs": [ "SRC-013", "SRC-012" ] }, { "target": "Regulatory licence and authorization model (sibling)", "relation": "REFERENCE", "purpose": "Own sector authorizations that condition conduct rather than constitute existence, preventing licence withdrawal from being read as loss of legal personality.", "required": false, "source_refs": [ "SRC-009", "SRC-008" ] }, { "target": "Statistical business register unit model (sibling)", "relation": "ALIGN", "purpose": "Declared boundary alignment: the enterprise, enterprise group, local unit and kind-of-activity unit are constructed from legal units but are not legal units. Mapping is one-to-many in both directions and must be recorded, not assumed.", "required": false, "source_refs": [ "SRC-016" ] }, { "target": "ISO 20275 Entity Legal Forms code list", "relation": "ALIGN", "purpose": "External governed classifier for legal form, referenced with an explicit version because codes and jurisdictions are added between releases.", "required": true, "source_refs": [ "SRC-004" ] }, { "target": "W3C Registered Organization Vocabulary and Organization Ontology", "relation": "ALIGN", "purpose": "Declared alignment for export and linked-data projection. Mapping is partial: RegOrg lacks the register-authority qualification and event history this model requires, and its status remains a Working Group Note.", "required": false, "source_refs": [ "SRC-007", "SRC-006" ] }, { "target": "GLEIF LEI-CDF and RR-CDF reference data formats", "relation": "ALIGN", "purpose": "Declared alignment for entity and relationship reference data exchange, version-pinned to LEI-CDF 3.1 and RR-CDF 2.1; alignment is not a conformance claim and holds only for entities within the identifier system's eligibility scope.", "required": false, "source_refs": [ "SRC-001", "SRC-002", "SRC-005" ] }, { "target": "ISO/IEC 6523 identifier scheme registry", "relation": "REFERENCE", "purpose": "Supply the scheme codes that qualify alternate organization identifiers, without which an identifier value cannot be interpreted or compared.", "required": true, "source_refs": [ "SRC-013", "SRC-012" ] } ], "serviceLayers": { "dimension": { "owner_package_requirements": [ "Name a single accountable owner package for WM-ORG-010 and declare, per jurisdiction, which register it treats as authoritative and whether that register is constitutive or declaratory.", "Pin the version of every external code list the package depends on — registration authorities, entity legal forms, activity classification, identifier schemes, event types — and store the pinned version alongside every code value, so a stored code remains interpretable after the list changes.", "Publish a jurisdiction coverage statement classifying each jurisdiction as production, best-effort or unsupported, and refuse to present best-effort data as authoritative.", "Publish an access-tier classification for every field and artifact type before any data is served, defaulting to deny for anything unclassified.", "Expose an AGENTS.md bootstrap at the package root and keep its URLs resolvable." ], "namespace_guidance": "Namespace instances as :org-reg::, keeping the authority code as the discriminator so identically formatted registration numbers from different registers can never collide. Reserve a distinct segment, :org-reg:local:, for identities minted by the adopting Dimension; entries in that segment must carry a non-authoritative flag and may never be published as if register-assigned. Alternate identifiers live in a scheme-qualified sub-namespace :org-reg:alt:: so that scheme is never stripped in transit.", "registry_links": [ "vr.wm-org-010 is the canonical registry entry; navigation path NAV.SOC.ORG.REG, domain tags SOC.ORG.REG.", "Parent registry entry WM-ORG-001 must resolve before this model is instantiated; a broken parent link blocks instantiation rather than degrading silently.", "External governed lists are referenced by registry link plus version and never silently copied; a local mirror must record the upstream URL, version and retrieval timestamp.", "Sibling models named in the composition block must be registered before any required composition link is marked satisfied." ] }, "canon_and_patch": { "canonicalization_rules": [ "The canonical form is format-neutral: an ordered set of typed assertions, each carrying subject, predicate, value, source and observation time. JSON, YAML, Markdown, HTML, Git, MCP and MongoDB are projections and must be reconstructible from the canonical assertions, never the reverse.", "Legal names are stored byte-exact as recorded by the register, preserving script, diacritics, casing and punctuation; normalisation for search and matching produces a derived index value that never replaces the stored value.", "All timestamps canonicalize to RFC 3339 with seconds and an explicit UTC offset or Z. Date-only register values retain an explicit precision marker and are never promoted to timestamps by assuming a time or a zone.", "Every code value canonicalizes to the pair (code, code-list version); a bare code is not a valid canonical value.", "Addresses canonicalize to component fields plus the register's own unparsed rendering, so that a lossy parse never destroys the authoritative string." ], "patch_rules": [ "Patches are append-only assertions. A superseded value is closed with an end timestamp and a superseding reference; it is never overwritten or deleted.", "Any patch touching identity, status, jurisdiction or legal form must cite a validation source and an observation timestamp, and is rejected without them.", "Patches derived from a legal entity event carry the event type, the event effective date and the event recorded date as separate fields, plus at least one validation document reference.", "Bulk patches from a source export must reference the snapshot artifact they were derived from, so any later correction can be scoped to the affected batch.", "A patch that would resolve a recorded conflict must carry the resolution rationale and decider; conflicts are not closed by overwriting one side." ], "compatibility_rules": [ "Adding an optional field, adding a code value, or relaxing a cardinality from 1 to 0..1 is compatible. Removing a field, narrowing cardinality, tightening a required flag, or reusing a retired code is breaking.", "Changing the authoritative register for an existing instance is breaking: it requires a new identity assertion with an explicit predecessor link, not an in-place edit of the authority code.", "External code-list version upgrades are recorded as migrations with an explicit mapping table. Values that cannot be mapped are retained under their original list version and flagged, never coerced.", "Projections may be added or retired without affecting canonical compatibility, provided the canonical assertions remain sufficient to regenerate every retained projection." ] }, "artifact_rules": { "identity_priority": [ "Identifier assigned by the authoritative master system — the registration authority code paired with the register-assigned entity identifier, both stored with the authority-list version used to validate them.", "Governed global identifier or IRI where one exists, such as a legal entity identifier, a cross-border register identifier, or an ISO/IEC 6523 scheme-qualified organization identifier; recorded as an alternate identity with an explicit equivalence assertion, never substituted for the register identity.", "UUID or ULID assigned by the adopting Dimension, used only when neither of the above is obtainable, flagged as locally assigned, and replaced by an authoritative identifier as soon as one is resolved, with the local identifier retained as a historical alias." ], "timestamp_rule": "All recorded times use RFC 3339 with seconds and an explicit UTC offset or Z. Event time, source-recorded time and observation or ingestion time are stored as separate fields and never collapsed into one. Date-only values from registers keep a precision marker and are compared only at date granularity. A date is never used as an identifier.", "serial_naming_rule": "Serial artifacts — extracts, certificates, snapshots, filings, gazette notices, history archives — are named ------, where sequence disambiguates artifacts sharing a timestamp. The issuer segment is mandatory because the same document type from two registers is not the same series, and a bare date is never sufficient.", "integrity_rule": "Every stored artifact carries a content hash with a named algorithm plus the issuer reference and retrieval timestamp. The hash establishes integrity and enables re-verification only; it must never be used as the business identity of the entity, of the registration record, or of the artifact series, because re-issued extracts of identical content are distinct artifacts and re-rendered documents of identical meaning hash differently." }, "policies": [ "No conformance claim is made to any external standard without a cited, version-pinned mapping and a published conflict list. Alignments are declared; conformance is proven or not asserted.", "A registration fact without a validation source and an observation timestamp is stored as unverified and must not be surfaced as authoritative, exported as corroborated, or used to satisfy a compliance check.", "Register-sourced personal data is redistributed only under the access tier, licence and minimisation profile recorded for its source register; a downstream copy never widens access beyond its origin.", "Dissolution, strike-off or transfer out never triggers silent deletion. Records are closed with a tombstone and retained per the declared retention period for the jurisdiction.", "Entity status and record status are always presented as two distinct values; any interface that exposes only one must label which one it shows.", "Where two registers or sources conflict, the conflict is stored and surfaced. A preferred value may be computed but must be marked provisional and carry its rule.", "One legally distinct entity receives at most one live LEI; porting changes the managing LOU, not the code.", "National register identifiers remain authoritative in the formation jurisdiction even when an LEI or EUID exists.", "EntityStatus and identifier RegistrationStatus must never be collapsed into a single status field.", "New bearer shares or bearer share warrants must not be issued; existing instruments and nominee arrangements require recorded mitigations.", "Minimum retention of basic and beneficial-ownership information is five years after dissolution or cessation; legal-identity history should not be hard-deleted while third-party reliance or restoration remains possible.", "Public access applies to the FATF basic set and to EU free BRIS particulars; beneficial-ownership access follows the jurisdiction's documented multi-pronged choice and privacy exceptions." ], "crud": { "read": [ "Reads of fields classified as public require no authorization but are rate-limited and logged in aggregate.", "Reads of restricted-tier fields require an authenticated requester category, a stated purpose and a recorded legal basis; the access decision and basis are written to the audit log.", "Every read returns, for each field, its source, observation timestamp and corroboration level, so a consumer can never receive a bare value without its provenance.", "Point-in-time reads are supported through the assertion history and must state explicitly when history does not reach the requested instant rather than returning the current value." ], "create": [ "Creation requires either a resolved authoritative register record or an explicitly justified fallback identity flagged as locally assigned.", "Creation records at minimum the registration authority code, register entity identifier, legal name, legal jurisdiction, entity status, record status and observation timestamp.", "Duplicate detection runs against the authority-qualified identifier and, secondarily, against name plus jurisdiction plus formation date before an instance is created; a suspected duplicate blocks creation pending review.", "Creation from a bulk export references the snapshot artifact and inherits its retrieval provenance." ], "update": [ "Updates are append-only assertions with source and observation time; prior values are closed with end timestamps, never overwritten.", "Updates to identity, jurisdiction, legal form or status require a cited validation source and, where the change results from a legal entity event, a linked event with effective and recorded dates.", "Changing an access-tier classification is itself an update requiring an approver, a rationale and an effective time.", "An update that contradicts a higher-corroboration assertion without new evidence is rejected and raised as a discrepancy." ], "delete": [ "Hard deletion of a registration record is prohibited while any legal retention duty applies, and the applicable duty must be evaluated per jurisdiction rather than assumed.", "De-publication is a status change plus a tombstone retaining the identifier, jurisdiction, closure reason and closure date, so historical references remain resolvable.", "Deletion or redaction of personal-data fields follows the suppression regime of the source register, is recorded as a redaction event with approver, basis and RFC 3339 timestamp, and leaves a redaction marker in place of the value.", "Retired identifiers are never released for reuse by the adopting Dimension, regardless of the source register's own reuse policy." ] }, "roles": [ { "name": "Registration Data Steward", "responsibilities": [ "Own the correctness of registration records within assigned jurisdictions and adjudicate discrepancies raised against them.", "Approve identity resolutions, duplicate merges and identifier retirements.", "Maintain the jurisdiction coverage statement and its production or best-effort classification." ] }, { "name": "Register and Jurisdiction Liaison", "responsibilities": [ "Track changes to register law, fee schedules, access regimes and published code lists in covered jurisdictions.", "Pin and roll forward external code-list versions, producing migration mapping tables.", "Record the constitutive versus declaratory characterisation and liability regime for each register." ] }, { "name": "Evidence and Verification Officer", "responsibilities": [ "Define required evidence types, freshness windows and authentication methods per use case.", "Verify authenticity of certificates and extracts and record verification results with timestamps.", "Set and review corroboration-level thresholds for downstream reliance." ] }, { "name": "Access and Privacy Controller", "responsibilities": [ "Classify every field and artifact type into an access tier and keep classifications current with legal change.", "Approve exceptions, evaluate legitimate-interest tests and enforce suppression regimes.", "Review access audit logs and investigate bulk-extraction alerts." ] }, { "name": "Interoperability Mapping Maintainer", "responsibilities": [ "Maintain version-pinned mappings to external vocabularies and exchange protocols, with per-field fidelity and loss reports.", "Publish and review the semantic conflict list rather than silently resolving conflicts in mappings.", "Validate that projections remain regenerable from canonical assertions." ] }, { "name": "Automated Ingestion Agent", "responsibilities": [ "Retrieve register records and exports under authorized credentials and within licence terms.", "Write assertions with full provenance and preserve snapshot artifacts with content hashes.", "Halt and escalate rather than guess when a source schema, code list or access regime changes unexpectedly." ] } ], "access": { "default_rule": "Deny by default. A field, document or artifact is readable only if it has been explicitly classified as public by the owner package on the basis of the source register's own disclosure regime; anything unclassified is treated as restricted. Every permitted read returns source, observation time and corroboration level with the value.", "scopes": [ "bundle", "layer", "finding", "artifact" ], "exceptions": [ "Competent authorities and obliged entities may access legitimate-interest and restricted tiers where the source register's regime permits, with the requester category, purpose and legal basis recorded on each access.", "Suppressed or protected officer and address details remain withheld regardless of requester tier unless a statutory override is evidenced and recorded by the Access and Privacy Controller.", "Evidence artifacts containing unredacted personal data are served only to authenticated principals with a recorded purpose, and only in the minimised form sufficient for that purpose.", "Pending cross-border operations and other embargoed events are withheld until their register publication date, even where the underlying record is public.", "Beneficial ownership linkage may resolve to a record the requester cannot read; the linkage itself is disclosed only where the source jurisdiction permits, following the invalidation of unrestricted public access in the EU.", "Bulk export of the public tier is permitted only under the source register's reuse licence, with attribution and redistribution limits propagated to the recipient.", "Competent-authority and FIU access overrides public-access limitations on beneficial-ownership and legal-owner data.", "Privacy and data-protection rules may restrict public BO access even where basic information remains public; record the legal basis rather than deleting the duty.", "Sealed court files, sanctions-related redactions and identity-protection orders may withhold representative particulars while preserving the fact of an order.", "RA777777 public-legal-document sources may be public as law yet lack a queryable register API." ], "audit_requirements": [ "Log requester identity, requester category, scope, fields returned, stated purpose, legal basis and an RFC 3339 timestamp for every restricted-tier access.", "Retain access logs for at least the retention period applicable to the most sensitive record class accessed, and protect them under the same or stricter access rules.", "Alert on bulk extraction of personal-data fields exceeding a configured threshold, and on repeated resolution attempts against suppressed records.", "Record every access-tier reclassification with approver, rationale and effective time, and retain the prior classification.", "Record every override of a suppression regime with the statutory basis relied on and the approving role.", "Log every create, update, status transition, disclosure, certified-copy issuance and access to non-public layers with actor, scope, purpose, event time and ingestion time.", "Retain audit logs at least as long as the underlying legal-entity artefacts.", "Record LEI challenge, port, lapse and retirement events with the managing LOU identifier." ] }, "agents_bootstrap": { "filename": "AGENTS.md", "required_fields": [ "Name", "Type", "Specification URL", "Storage type URL", "Interface URL", "Processes URL", "Owner", "Jurisdiction coverage statement URL", "Pinned external code list versions", "Access tier classification URL" ], "read_order": [ "AGENTS.md at the package root, which must be present regardless of whether the storage projection is a file tree, Git, MongoDB or an MCP resource server.", "Specification URL, for model scope, boundaries, the bundle-layer-finding-question structure and the question set.", "Storage type URL, for the projection actually in use and how canonical assertions are materialised in it.", "Interface URL, for the access contract, tier evaluation and audit obligations.", "Processes URL, for ingestion, identity resolution, event application, validation, discrepancy handling and retention procedures.", "Jurisdiction coverage statement, before treating any jurisdiction's data as production quality.", "Pinned external code list versions, before interpreting any code value in the record." ] } }, "coverage": { "claim": "Synthesis covers register-anchored legal-person identity and identifiers, register authority and legal effect, registration act and filing obligations, two-axis status plus standing signals, typed legal-entity events with succession and restoration, jurisdiction/addresses/branches/redomiciliation, register-reported structural relationships and officer representation, evidence and graded corroboration, and governance of access, personal data, provenance, retention and interoperability — with Grok contributing the legal-personality, capacity and member-liability axis that the base lacked. Coverage is strongest for EU, UK and global identifier-system (LEI/ELF/RA-list) profiles; it is unverified for US state-level formation, non-EU civil-law registers, and legal forms that arise without registration. No claim of universal, jurisdiction-complete or standard-conformant coverage is made.", "confidence": "medium", "checklist": [ { "dimension": "identity", "status": "covered", "notes": "Register-anchored identity as (authority code, register entity identifier) with a governed authority list, plus scheme-qualified alternate identifiers and an explicit three-step fallback priority. Grounded in LEI-CDF registration-authority fields, the registration authorities list and ISO/IEC 6523 scheme qualification." }, { "dimension": "lifecycle", "status": "covered", "notes": "Two status axes, typed legal entity events with effective and recorded dates, succession through merger, division and conversion, and dissolution with restoration modelled as a non-absorbing terminal state. Grounded in public-authority legal-entity-events policy and a national register's status and status-detail vocabularies." }, { "dimension": "relationships", "status": "covered", "notes": "Consolidating parent, international branch and fund relationships with periods, qualifiers, corroboration levels and coded reporting exceptions, plus explicit separation from statistical enterprise groups. Grounded in RR-CDF 2.1 and UNECE statistical unit definitions." }, { "dimension": "temporal", "status": "covered", "notes": "Three clocks kept separate throughout — event effective time, source-recorded time, observation time — with RFC 3339 required and date-only precision preserved rather than promoted. Point-in-time status computation is an explicit function." }, { "dimension": "provenance", "status": "covered", "notes": "Per-field source attribution, retrieving agent and authorization, preserved snapshots with content hashes, and a rule that hashes prove integrity but never carry business identity." }, { "dimension": "ownership", "status": "covered", "notes": "Covered at the boundary by design: registered officers and representation authority are in scope as registration facts, while beneficial ownership content is delegated to a sibling model and only its linkage, mechanism type and access tier are held here." }, { "dimension": "validation", "status": "covered", "notes": "Validation sources, validation authorities, graded corroboration levels, automated quality checks with thresholds, discrepancy reporting duties and register correction or challenge processes." }, { "dimension": "access", "status": "covered", "notes": "Deny-by-default with tiered classification across bundle, layer, finding and artifact scopes, requester categories, reuse licences and audit obligations, informed by the invalidation of unrestricted public access to beneficial ownership data." }, { "dimension": "retention and deletion", "status": "covered", "notes": "Append-only history, per-jurisdiction retention declaration rather than a global default, tombstones on closure, no identifier reuse, and redaction events for suppression. Grounded in the finding that no single suitable maximum retention period can be identified for register data." }, { "dimension": "interoperability", "status": "covered", "notes": "Version-pinned alignments to W3C ORG and RegOrg, schema.org, LEI-CDF and RR-CDF, ISO/IEC 6523 scheme codes and register-to-register exchange, with per-field fidelity reporting and an explicit conflict list instead of conformance claims." }, { "dimension": "classification", "status": "covered", "notes": "Legal form as a governed code tied to jurisdiction and kept in local language, entity category and sub-category as rule-bearing structural classifications, and activity codes carried with scheme revision." }, { "dimension": "jurisdiction and place", "status": "covered", "notes": "Jurisdiction of formation at country and subdivision level as a dated fact with history, registered versus headquarters addresses distinguished by legal effect, and branch, seat transfer and foreign qualification treated as registration facts." }, { "dimension": "evidence and authentication", "status": "covered", "notes": "Certificates and extracts as dated, ageing snapshots with as-of timestamps, freshness windows, authentication methods including verifiable credentials, and translation or legalization determination for cross-border use." }, { "dimension": "authority and legal effect", "status": "covered", "notes": "Register mandate, coverage, constitutive versus declaratory effect, opposability to third parties, liability or warranty regime, and the separation of registration authority from validation-only source." }, { "dimension": "privacy and personal data", "status": "covered", "notes": "Field-level personal data inventory, suppression regimes, the limited erasure position and case-by-case objection right, and inheritance of minimisation obligations by downstream copies." }, { "dimension": "process and events", "status": "covered", "notes": "Filing obligations with cadence and default consequences, strike-off and restoration procedures, cross-border notification between registers, and eleven operating functions with preconditions and effects." }, { "dimension": "measurement", "status": "covered", "notes": "Present but thin by design: days overdue, accrued penalties and relationship ownership quantifiers are the only genuine measurements a registration record carries. No further measurement surface was asserted, because inventing one would not be falsifiable against the cited sources." }, { "dimension": "security", "status": "covered", "notes": "Authentication of requester categories, credential scope for retrieval agents, audit logging with retention, bulk-extraction alerting and protection of audit logs at the sensitivity of the data accessed." }, { "dimension": "conflict and discrepancy handling", "status": "covered", "notes": "Conflicts stored and surfaced rather than resolved by overwriting, provisional preferred-value rules, statutory discrepancy reporting, and rejection of low-corroboration updates that contradict better-evidenced assertions." }, { "dimension": "fees and cost of access", "status": "gap", "notes": "Registry guidance recommends free or very low-cost services, and fee schedules are modelled as part of access gating, but no primary source in this set enumerates fee structures across jurisdictions. Treated as a declared gap rather than presented as covered structure." } ], "known_omissions": [ "Sole traders, partnerships without legal personality and unincorporated associations are only partially addressed. They appear as an entity category and are within registry-guidance scope, but the model is built around registered legal persons, and jurisdictions differ on whether such entities register at all.", "Trusts and other legal arrangements are deliberately excluded. They are governed by a distinct international recommendation with different transparency mechanics and would need a sibling model rather than an extension of this one.", "Charity, cooperative, religious-body and public-body registers are acknowledged as parallel registers but their specific particulars are not enumerated; only the parallel-register conflict question captures them.", "Fee schedules, filing costs and cost-of-access economics are not modelled beyond gating conditions, as noted in the checklist gap.", "Registered capital, share structure and share classes are not modelled. They are register-disclosed in many jurisdictions but belong to a capital and securities model.", "Sanctions listing, export-control designation and politically exposed status are excluded as screening concerns rather than registration facts.", "Historical registers, pre-digitisation records and jurisdictions where the register is paper-only are not addressed; the ingestion functions assume a retrievable electronic source.", "Verifiable-credential issuance of registration facts is referenced as an authentication method but its issuance, revocation and trust-chain semantics are not modelled.", "UNCITRAL Guide on Key Principles of a Business Registry (2018) is cited by the LLE Guide as the dedicated registry-operations instrument but was not independently fetched; operational registry-service design may be thinner than that Guide.", "Administrative strike-off, restoration to the register, dormancy and administrative revival are nationally common and not specified in the fetched global instruments.", "United States state secretaries of state, registered-agent statutes, China's Unified Social Credit Code, India's CIN and similar national identifier schemes are not modelled beyond the RA-list binding.", "Full FATF INR 24 footnotes, verification methods and foreign-person 'sufficient links' tests are only partially extracted.", "Digital-asset organisations, DAOs and other emerging personality experiments have no primary support in ISO 17442 eligibility as fetched.", "Islamic waqf, cooperatives, unincorporated associations and mixed public-law bodies are covered only insofar as an ELF code or RA source exists.", "EU proposal for an 'EU Inc.' 28th-regime corporate form (2026) is not in force and is excluded.", "ISO 5009 official organisational roles and vLEI role credentials are alignment pointers, not a modelled officer ontology." ], "conflicts": [ "Legal-form classification versus register-native type vocabularies. A national register's own company type and subtype values do not map cleanly onto the international legal-form code list; both are retained with an explicit mapping status rather than one being normalised into the other.", "Entity status semantics diverge between systems. A register's dissolved or converted-closed value and an identifier system's lapsed or retired registration status describe different things, and treating either as the entity's legal state produces false conclusions. The model keeps two independent status axes for this reason.", "Publicity versus privacy. Registry guidance and EU company law push toward broad public disclosure, while the Court of Justice invalidated unrestricted public access to beneficial ownership data as disproportionate, and the settled position on companies registers denies general erasure while allowing case-by-case objection. These are not reconcilable into a single access rule and are modelled as jurisdiction-specific tiers.", "Parenthood definitions conflict. Accounting-consolidation parenthood, legal ownership and statistical control produce different parents for the same entity. The model records the reported relationship type and refuses to present consolidation-based parenthood as ownership.", "Legal unit versus enterprise. Statistical frameworks construct enterprises from one or more legal units, so any one-to-one assumption between a registration record and a business is wrong in both directions.", "Standard maturity is uneven. The Registered Organization Vocabulary remains a Working Group Note while the Organization Ontology is a Recommendation, so alignment strength differs between the two and is recorded per mapping.", "Regulatory volatility around register-adjacent obligations. The narrowing of US beneficial ownership reporting to foreign-formed entities in 2025 shows that obligations attached to registration can invert within a single rulemaking, so every such obligation is stored version-dated rather than as a standing fact.", "The incorporating-register identifier is legally master in the formation jurisdiction; the LEI is a globally unique identifier for the same person but is not constitutive of personality.", "EUID is mandatory for EU inter-register communication yet companies must continue to use domestic numbers in their own correspondence.", "ISO 17442 includes individuals acting in a business capacity and international branches; many company registers and FATF 'legal persons' treatments do not treat those objects as companies.", "ELF codes with similar English labels are not equivalent across jurisdictions; any crosswalk is heuristic and non-conformant to ISO 20275.", "EntityStatus (legal existence/operation) and LEI RegistrationStatus (issued, lapsed, retired) can diverge and must not be fused.", "FATF requires competent-authority access to beneficial-ownership information and only invites countries to consider public access; some regional regimes have made BO registers public and later restricted them. This model records the duty and the chosen access posture rather than claiming one global publicity rule.", "UNCITRAL LLE is formed once registered (constitutive); some company-law systems treat registration as declaratory of a prior notarial constitution." ], "regional_assumptions": [ "The model assumes a jurisdiction has at least one identifiable registration authority. This fails where a legal form arises without registration, and the fallback identity path exists specifically for that case.", "EU-specific structure — cross-border register interconnection, a European unique identifier, and a cross-border company certificate — is treated as one regional realisation of register interoperability, not as the universal pattern.", "The United States has no single national company register; formation is state-level and there is no federal equivalent to a national commercial register. The registration authority code must therefore resolve to a state office, and any model assuming one register per country will break here.", "Sub-national jurisdiction coding is assumed necessary, not optional, because federal and devolved systems routinely register at that level; a national register's jurisdiction field with devolved values illustrates this.", "Local-language legal form names are assumed authoritative and untranslatable; translation is a convenience layer, never a substitute for the local name and its code.", "Restoration or reinstatement after dissolution is assumed to exist in some jurisdictions and not others; the model does not treat dissolution as universally absorbing.", "Register access regimes are assumed to differ by jurisdiction and to change; a single global access classification is not assumed anywhere in the model.", "Non-Latin script and transliteration handling is assumed necessary, following reference-data formats that carry separate transliterated name and address containers.", "EU Directive 2017/1132, EUID and BRIS are a regional profile applied when the entity is an EU/EEA registered company or branch, not a global default.", "GLEIF RA and ELF lists are globally broad (232 jurisdictions / 200+ jurisdictions) but still incomplete; absence from a list is a gap, not proof that no register or form exists.", "Common-law registered-office-plus-registered-agent patterns and civil-law notarial constitutive deeds both map to the same address and instrument findings with different formation_theory codes.", "FATF 'company registry' language is applied mutatis mutandis to other legal persons as INR 24 footnote 68 requires, without pretending every foundation or cooperative uses a companies house." ], "adversarial_checks": [ "Tested whether the register-assigned identifier is genuinely the master identity, against the counterexample that some entities have a global identifier but no retrievable register entry, and some jurisdictions reuse registration numbers. Result: identity priority is retained but the fallback path and identifier validity intervals were added, and identifier reuse is an explicit question rather than an assumption.", "Tested whether 'dissolved' can be modelled as a terminal state. Restoration and reinstatement procedures falsify this, so the lifecycle keeps dissolution reversible within a jurisdiction-specific window and asks explicitly which states are terminal.", "Tested whether register data can be treated as uniformly public. The invalidation of unrestricted public access to beneficial ownership data, combined with officer suppression regimes, falsifies it; access is modelled as tiered with deny-by-default rather than as open data with exceptions.", "Tested whether a right to erasure resolves the personal-data tension. The settled position that no general erasure right exists against a companies register, because no suitable maximum retention period can be identified, falsifies the simple deletion model; retention is declared per jurisdiction and deletion is constrained rather than defaulted.", "Tested whether one registration record equals one business. Statistical unit definitions falsify this in both directions, so the statistical business register model is a declared boundary alignment and enterprise-level concepts were kept out.", "Tested whether a country code plus registration number is sufficient to identify an entity. The existence of over a thousand distinct registers across 232 jurisdictions, and the fact that the US has no national register, falsifies it; the registration authority code is mandatory and is the namespace discriminator.", "Tested whether an alternate identifier such as a VAT or tax number can substitute for the register identity. It cannot: such identifiers frequently denote a VAT group, an establishment or a branch rather than the legal person, so equivalence is an evidenced assertion with a denoted-unit type, not an implicit join key.", "Tested whether a certificate or extract can be treated as a standing fact. It cannot: an extract speaks only as of its issue date, so as-of timestamps and freshness windows are mandatory and evidence is superseded rather than updated.", "Tested the durability of register-adjacent obligations by checking a live example, finding that US beneficial ownership reporting was narrowed to foreign-formed entities by an interim final rule effective 26 March 2025. Any structure asserting a standing obligation was therefore version-dated.", "Tested source availability honestly: EUR-Lex full texts, the FATF guidance page, the ISO catalogue and the UNECE publication page all refused automated retrieval during this research. Those sources are cited with their titles and dates, their contribution is limited to provisions confirmed by title and published summaries, and this is recorded as an evidence gap rather than presented as verified full-text grounding.", "If a partnership or MSME has no legal personality, this model must refuse to mint a legal-person record even if a tax or licence number exists.", "If two ELF codes share a name (LLC, SA) they must not be merged; doing so would violate ISO 20275's no-embedded-intelligence and no-cross-country-alignment rules.", "If an LEI is lapsed or retired, identity resolution must still use the LEI as a name for the person while EntityStatus and legal existence are taken from the register.", "If a branch has an LEI, the agent must not infer a separate incorporating-register legal person without a parent-company link and a legal_nature code.", "If asked to delete a dissolved company, the agent must convert the request to status transition plus retention, not erasure.", "If beneficial-ownership percentages are requested, the agent must switch to the sibling model and only answer holding-body, access and quality from this model.", "If a trust is presented, the agent must test Recommendation 25 versus legal-person registration before accepting the record." ] }, "researchAdjudication": { "providerMode": "dual-provider", "activeProviders": [ "claude", "grok" ], "waivedProviders": [], "providerPolicy": {}, "boundaryDecision": { "entry_kind": "entity", "status": "accepted", "rationale": "Both providers independently returned entry_kind 'entity' and the same registry_id and name, and both draw the same primary cut against WM-ORG-001: the subject is a legal person whose identity is anchored in an authoritative register, not the social/operational organisation. The subject has a stable identity anchor (registration authority + register-assigned identifier), a lifecycle with typed events, and states that persist independently of any single observation, which is the entity test rather than an event, relation or process test. The base scope is accepted as drawn by Claude: registration facts only, with ownership content, capital and share structure, statistical units, tax assessment and sector licensing delegated to siblings." }, "decisions": [ { "concept": "Base provider selection", "disposition": "Claude as base", "rationale": "Claude's boundaries are the clearest and most complete: eight boundary notes with distinct neighbours, a ten-item out-of-scope list, and inline_only_rationale on nine findings that explicitly refuse to duplicate sibling models. It makes three cuts Grok does not make at all — legal unit versus statistical enterprise, registration versus sector licensing, and evidence versus a generic document model. Size is corroborating, not decisive." }, { "concept": "Grok legal personality and capacity", "disposition": "Accepted into legal-form-and-classification", "rationale": "The one axis where Grok is materially stronger than the base. Personality, capacity, asset partitioning and the member liability shield are the substance of what registration confers, and the base models only the register's act, not the legal status it produces." }, { "concept": "Grok eligible-party-types", "disposition": "Rejected as duplicative", "rationale": "Its category content (general entity, fund, sole proprietor, branch, international organisation) is already the base's entity-category-and-economic-activity-classification finding, and its admission-gate question is carried by the accepted legal-personality finding. Adding it would create two competing category findings in the same layer." }, { "concept": "Grok authoritative-and-global-identifiers", "disposition": "Rejected as duplicative", "rationale": "The base already splits this across register-anchored-legal-entity-identity and cross-scheme-identifier-alignment, including syntactic validation, precedence on disagreement and global-identifier status reconciliation. LEI check-digit structure, one-LEI-per-entity uniqueness and LOU portability are question-level detail, not a third identifier finding." }, { "concept": "Grok authoritative-register-binding", "disposition": "Rejected as duplicative", "rationale": "Fully covered by registration-authority-identification, which already carries the governed RA list, coverage scope and the constitutive-versus-validation-source distinction. The reserved RA codes for entities with no ordinary register are subsumed by the base's fallback-identity-strategy question." }, { "concept": "Grok euid-and-bris-interconnection", "disposition": "Deferred as an EU regional profile", "rationale": "Evidence-backed but region-specific. The base deliberately generalises register-to-register exchange into interoperability-mappings-and-exchange-projections and states in its regional assumptions that EU interconnection is one realisation, not the universal pattern. Promoting it to a core finding would structurally privilege one jurisdiction and undermine multi-profile validation." }, { "concept": "Grok constituting-instruments", "disposition": "Rejected, with parts deferred", "rationale": "The instrument-and-particulars content duplicates mandatory-disclosure-particulars-and-filing-obligations, and the disclosed-representatives content duplicates officers-and-authority-to-represent. Its remaining content — authorised and subscribed capital, stated objects, entity duration and the location of the shareholder or member register — sits outside the base boundary, which delegates capital and share structure to a capital and securities sibling." }, { "concept": "Bearer shares and nominee arrangements", "disposition": "Rejected, routed to siblings", "rationale": "Grok's FATF-grounded transparency-obstacle content is real but is a share-structure and beneficial-ownership fact, both of which the base explicitly delegates. Recording it here would replicate restricted ownership content outside its access regime, which is the specific failure the base's beneficial-ownership-register-linkage finding was written to prevent." }, { "concept": "Judicial declaration of nullity", "disposition": "Folded into existing vocabularies, grounding deferred", "rationale": "Grok is right that EU law requires disclosure of judicially declared nullity and the base names only dissolution, liquidation, strike-off and restoration. Nullity is a value in the governed event-type list and a ground under end-date-and-ground, not a new finding; its retroactive effect on third-party reliance needs primary-text grounding first." }, { "concept": "Authoritative identity priority", "disposition": "Retain base ordering unchanged", "rationale": "Both providers independently land on the same priority — register authority plus register-assigned identifier first, governed global identifier (LEI, EUID) second, locally minted surrogate last and flagged as such. No adjudication needed; the agreement raises confidence in the base wording rather than requiring a merge." }, { "concept": "Legal unit versus statistical enterprise boundary", "disposition": "Retain from base; absent in Grok", "rationale": "Claude's UNECE-grounded boundary note that one registration record is neither one enterprise nor one business, in either direction, is a load-bearing cut that Grok does not make anywhere. It is preserved verbatim as a boundary note and as the relationship-versus-statistical-group question." }, { "concept": "Registrar-side formation function", "disposition": "Rejected", "rationale": "Grok's form-and-register-legal-entity brings a legal person into existence, which presumes the operator is the registration authority. The base is an observer-and-operator model over an external authoritative register; accepting it would silently change the model's role rather than fill a gap." }, { "concept": "Grok corroborate-reference-data function", "disposition": "Rejected as duplicative", "rationale": "The base's request-and-verify-evidence and detect-and-report-discrepancy jointly produce and update the corroboration grade held by validation-sources-and-corroboration-level. A third overlapping verification function would blur the boundary between fetching evidence, comparing sources and grading corroboration." }, { "concept": "Service-layer merge", "disposition": "Merge", "rationale": "Both providers place validation, access, retention and interoperability concerns in cross-cutting layers with substantially the same content; keeping them separate would fragment provenance and access enforcement across two vocabularies. Base layer identifiers govern." } ], "publicationHolds": [ "Source retrieval is not verified. Claude's own adversarial checks record that EUR-Lex full texts, the FATF guidance page, the ISO catalogue and the UNECE publication all refused automated retrieval, so those citations rest on titles and published summaries rather than confirmed full text. Every accepted source must be re-fetched and its contribution re-confirmed before publication.", "SRC-019 (GDPRhub, authority tier 3, non-primary) carries the load-bearing claim that no general right to erasure exists against a companies register. Replace it with the primary CJEU judgment in C-398/15 (Manni) or downgrade every finding that depends on it, including personal-data-in-registration-records and record-history-retention-and-deletion-constraints.", "Version pins must be reconciled and re-verified as-of a single date: ELF list v1.6 (Feb 2026), GLEIF RA list v1.8.1 (Nov 2024), LEI-CDF 3.1, Peppol ICD (May 2026), schema.org 30.0, and the FATF Recommendations edition (Claude cites March 2023 guidance, Grok cites an update dated June 2026).", "The two providers cite different EU implementing regulations for the system of interconnection of registers — Commission Implementing Regulation (EU) 2021/1042 (Claude) and (EU) 2020/2244 (Grok). Determine which is in force, whether one repeals the other, and pin the surviving instrument before publishing any interconnection or exchange-protocol structure.", "Claude cites Directive (EU) 2025/25 as in force from 30 January 2025 via a Commission overview page rather than the Official Journal text. Confirm against EUR-Lex before any disclosure or interconnection claim relies on it.", "Domain-profile validation is incomplete. The model has been reasoned against EU, UK and global identifier-system profiles only. Before publication it must be exercised against at least: US state-level formation with no national register, a non-EU civil-law register (for example Japan or Brazil), a national identifier scheme outside the RA-list framing (China USCC, India CIN), and a jurisdiction where a legal form arises without registration, which is the case the fallback identity path exists to serve.", "Legal-effect characterisations — constitutive versus declaratory registration, opposability of disclosed particulars to third parties, register liability or warranty for inaccurate entries, and third-party reliance on translated versions — are stated as general rules but grounded partly in secondary summaries. Hold until each is confirmed against primary statutory text for at least two contrasting jurisdictions." ], "deferredResearch": [ "EUID and BRIS as an explicit EU regional profile overlay (Grok SRC-003, SRC-010): EUID composition, the no-centralised-database constraint on the central platform, and the branch-disclosure and cross-border-merger notification message types — to be modelled as a jurisdiction profile bound to the base's interoperability layer, not as core structure.", "Registered capital, subscribed versus authorised capital, share classes, bearer shares and nominee shareholder or director arrangements: confirm the split between the capital and securities sibling model and the beneficial-ownership sibling, and decide where the FATF transparency-obstacle mitigations attach.", "Stated objects, entity duration and the notified location of the shareholder or member register: these are register-disclosed in many jurisdictions and are currently unowned by any model in the set; decide whether they belong here as registration facts or to the capital and governance siblings.", "Administrative strike-off, restoration, reinstatement and dormancy: both providers record that global instruments do not specify these and that they are nationally common. Needs national-profile research (UK, US states, Australia) to ground the base's claim that dissolution is non-absorbing within a jurisdiction-specific window.", "Judicial declaration of nullity of a company: primary-text grounding for its disclosure requirement, its retroactive effect on acts already performed, and whether it belongs in the event-type vocabulary as a distinct type or as a ground under termination of registered existence.", "FATF 'sufficient links' test for foreign-created legal persons, and how it interacts with the base's foreign-qualification and redomiciliation structure — currently only partially extracted by Grok and absent from the base.", "Register fee schedules and cost-of-access economics, declared a gap by the base: determine whether any primary source enumerates them across jurisdictions or whether the gap must remain declared.", "Whether Vercy models the registrar role at all: the rejected formation and disclosure functions imply a second actor perspective. Decide explicitly, because accepting it later would change the model's purpose statement rather than extend it." ] }, "statistics": { "sources": 28, "bundles": 7, "layers": 15, "findings": 29, "questions": 118, "artifacts": 21, "functions": 12 } }