L-Series: Machine-Readable Legislation & Policy-as-Code

DNP-L.400 PRF

Standards and Regulatory Publications

Pakistan AKN Application Profile (PAKN-AP)

Summary

This Profile establishes the national technical and operational rules under which Akoma Ntoso is used for machine-readable legislation in Pakistan. It constrains the OASIS Akoma Ntoso base standard for national drafting, identification, metadata, validation, exchange, publication and preservation, and defines the conformance classes and compliance levels against which institutions and tools are assessed.

Foreword

This Profile responds to an interoperability and trust problem rather than a formatting problem alone. Pakistan’s legal-information ecosystem is undergoing progressive digitization, yet legal texts continue to be published and exchanged largely through fragmented, institution-specific and predominantly document-centric channels — limiting reliable machine processing, durable citation, amendment tracking, bilingual alignment, cross-institution exchange and downstream reuse across government, the legal profession, research and public-facing digital services. Akoma Ntoso (AKN), maintained within the OASIS LegalDocML ecosystem, provides a structured XML-based legal-document standard, but public implementation experience shows that jurisdictions operationalize AKN safely only by publishing a governed application profile that constrains the base standard for local drafting, publication, exchange, validation and preservation. This Profile is that governed national constraint: it specifies how Akoma Ntoso shall be used for Pakistan’s machine-readable legislative standard, and is issued for expert and institutional review at Committee Draft (CD) v0.1 prior to advancement toward Final Draft and Publication. upon Final Draft (FD) approval]

Document Control

Restructured to the DNP-X.001 mandatory clause sequence and Annex A publication template. Pending review by the PDA Standards Board.

Contact:Pakistan Digital AuthorityStandards Board Secretariat4th Floor, 5-A Constitution Avenue,Sector F-5/1,Islamabad 44000, PakistanE-Mail: standards@pda.gov.pkhttps://standards.dnp.gov.pk(planned landing page: standards.dnp.gov.pk/DNP-L-400.html)

1 Scope

1.1 Background

The background to this Profile should be understood as an interoperability and trust problem rather than a formatting problem alone. A national machine-readable legislative baseline is justified because fragmented publication practices, PDF-centric circulation, and unstable cross-reference habits make authoritative maintenance, bilingual synchronization, amendment traceability, and future structured reuse materially harder than they need to be. Pakistan’s legal-information ecosystem is undergoing progressive digitization; however, legal texts continue to be published and exchanged largely through fragmented, institution- specific, and predominantly document-centric channels. In practice, this limits reliable machine processing, durable citation, amendment tracking, automated consolidation, bilingual alignment, cross-institution exchange, and downstream reuse across government, the legal profession, research, and public-facing digital services. Akoma Ntoso (AKN) is a structured XML-based legal-document standard maintained within the OASIS LegalDocML ecosystem. Its architecture extends beyond a schema vocabulary alone and includes a technical document model, a naming-convention layer, and an interoperable media-type model for exchange and processing. Public implementation experience demonstrates that jurisdictions do not operationalize AKN safely by merely “using some AKN XML.” They publish a governed application profile that constrains the base standard for local drafting, publication, exchange, validation, and preservation. Pakistan already possesses a practical foundation for such a transition. The legal and administrative environment contains obligations relating to publication, maintenance, updating, and translation of laws in soft form. At the same time, the current environment remains multi-source and heavily PDF-centric, creating persistent difficulties for authoritative consolidation, stable cross-referencing, structured bilingual management, and future AI- ready legal corpora. Accordingly, this Pakistan AKN Application Profile is established as the national technical profile through which Pakistan’s machine-readable legislative standard based on Akoma Ntoso shall be specified, governed, validated, published, exchanged, and preserved.

1.2 Purpose

The purpose of this Profile is to define the national technical and operational rules by which Akoma Ntoso shall be used for machine-readable legal and legislative documents in Pakistan. More particularly, this Profile is intended to:

• (a) establish a constrained and governable Pakistan-specific implementation of the Akoma Ntoso standard;
• (b) define the document classes, metadata, identifiers, language rules, structural requirements, conformance expectations, packaging rules, publication rules, and preservation requirements applicable within Pakistan;
• (c) provide a common basis for legal drafting systems, publication platforms, legal- information repositories, exchange interfaces, resolver services, APIs, and validation tools used by competent institutions;
• (d) support authoritative publication, durable citation, amendment tracking, consolidation, bilingual governance, structured reuse, and future linked-data alignment;
• (e) reduce fragmentation, non-persistent citation practices, inconsistent markup implementations, and vendor-specific lock-in across institutions; and
• (f) define the minimum implementation package, including normative annexes, controlled vocabularies, identifier grammar, metadata dictionary, validation baseline, and packaging and distribution profile, required for safe operational rollout.

1.3 Objectives

The objectives of this Profile are to: 1. establish Akoma Ntoso as the canonical machine-readable representation for documents within scope under this Profile; 2. define a Pakistan-specific application profile that remains interoperable with the base Akoma Ntoso standard while reflecting Pakistan’s legal, institutional, and bilingual realities; 3. institute a persistent identifier framework combining long-term legal identifiers and resolvable publication identifiers; 4. standardize the minimum metadata necessary to support legal authenticity, provenance, versioning, jurisdictional identification, language management, and structured reuse; 5. provide common structural and editorial rules for the markup of legal texts, including Acts, Ordinances, Bills, Rules, Regulations, and other instruments included within scope; 6. establish conformance classes and validation requirements to support predictable exchange, publication, and quality assurance; 7. define publication and reuse expectations, including machine-readable distribution, human-readable renderings, API access, bulk distribution, and long-term preservation; and 8. provide a governed path for institutional rollout, maintenance, update, and controlled profile evolution.

1.4 Coverage Statement

This Profile applies to the machine-readable representation, exchange, publication, validation, distribution, and preservation of legal and legislative documents that are expressly brought within scope by the issuing authority. Unless otherwise provided in a later update, the initial scope of this Profile shall cover, at minimum:

• (a) the Constitution of Pakistan;
• (b) Federal Acts;
• (c) Ordinances;
• (d) Bills;
• (e) Rules;
• (f) Regulations; and
• (g) such Notifications, Statutory Regulatory Orders, Gazette notices, commencement instruments, corrigenda, or other subordinate legal instruments as may be designated by the Profile Owner or issuing authority. This Profile applies to both:

I. born-digital documents, being documents created natively within a structured drafting, exchange, or publication environment; and II. ii. legacy documents, being documents converted from pre-existing sources such as PDF, word-processing files, HTML pages, scanned archives, or other non-native legal publishing formats. Version 1 of this Profile is publication-capable and workflow-ready. It is intended first to stabilize machine-readable publication, controlled exchange, and preservation. It may also be integrated into drafting and pre-publication workflows, provided the implementing institution meets the applicable authoring and exchange conformance requirements. This Profile is intended for use across federal institutions in the first instance and shall be capable of adoption, adaptation, or extension for provincial implementation through a governed national interoperability framework. This Profile does not, by itself, determine the legal validity of any instrument, nor does it replace the legal requirements governing enactment, publication, authentication, or evidentiary status. It defines the technical and operational profile by which such documents may be represented and managed in machine-readable form.

1.5 Intended Audience

This Profile is intended for use by:

• (a) institutions responsible for legal drafting, legal publication, consolidation, maintenance, translation, or archival management of laws;
• (b) legislative secretariats, parliamentary offices, and publication authorities;
• (c) ministries, departments, divisions, and agencies that create, maintain, or publish instruments within scope;
• (d) information-technology teams and solution providers responsible for drafting systems, publication systems, repositories, resolvers, APIs, and validation services;
• (e) implementers of transformation, rendering, indexing, exchange, and archival workflows;
• (f) conformance assessors, validators, auditors, or quality-assurance teams;
• (g) institutions participating in federal–provincial interoperability efforts; and
• (h) downstream users of machine-readable law, including public-sector service providers, legal-information services, researchers, civic-technology communities, and other reuse communities, to the extent relevant.

1.6 Relationship to Akoma Ntoso

This Profile is based on the Akoma Ntoso standard and shall be interpreted as a national application profile of that standard, not as a replacement for it and not as a separate markup language detached from it. For the avoidance of doubt:

• (a) the base international standard remains Akoma Ntoso as maintained within the OASIS LegalDocML ecosystem;
• (b) this Profile defines the constrained national implementation of that standard for Pakistan;
• (c) this Profile is intended to operate as a true constrained subset plus governed national rules, not as a competing dialect detached from the base standard;
• (d) where this Profile imposes additional constraints, naming rules, metadata requirements, structural limitations, packaging rules, or conformance obligations, those constraints shall apply within the Pakistan implementation domain;
• (e) where this Profile is silent, the relevant provisions of the base Akoma Ntoso standard and associated normative artifacts shall continue to apply, subject to the issuing authority’s implementation guidance; and
• (f) any Pakistan-specific extension shall be controlled through the governance mechanisms defined in this Profile and shall not be used in a manner that unnecessarily breaks base interoperability.

1.7 Profile Design Principles

1.7.1 Authoritativeness

Authoritativeness under this principle requires explicit signaling of status at metadata, publication, and resolver levels. A system shall not rely on visual prominence, portal placement, or file naming alone to communicate whether a text is authoritative, officially derived, consolidated, translated, or informational. The Profile shall support authoritative representation and controlled publication of legal texts by enabling clear distinction between authoritative, official derivative, consolidated, translated, and informational manifestations.

1.7.2 Interoperability

Interoperability here means more than parsable XML. It requires compatible identifiers, shared code lists, predictable structural patterns, stable package semantics, and consistent endpoint behavior so that legal resources can move between institutions without semantic re-interpretation. The Profile shall be designed to facilitate interoperability across institutions, jurisdictions, systems, and time, and shall avoid unnecessary divergence from the base Akoma Ntoso model.

1.7.3 Persistence of Citation

Persistence shall be engineered across both identifier policy and repository behavior. Citations must survive platform redesign, supplier change, URL refactoring, consolidation cycles, and publication refreshes without forcing users to relearn how the same legal resource is identified. Identifiers, references, and structural anchors shall be designed for persistence, resolvability, and stability across system changes, publication channel changes, and document updates.

1.7.4 Reuse by Design

Reuse shall include programmatic retrieval, legal search, analytics, semantic enrichment, controlled downstream republising, and preservation-driven migration. For that reason, canonical XML, metadata, package manifests, and derivative relationships should all be designed to support lawful re-use from the outset.

The Profile shall support not only human-readable publication but also machine-readable reuse through structured metadata, consistent identifiers, predictable packaging, publication interfaces, and bulk distribution profiles.

1.7.5 Bilingual Integrity

Bilingual integrity requires that language handling preserve both semantic correspondence and asymmetry where asymmetry is real. The Profile shall therefore support aligned provisions where feasible while allowing controlled recording of divergence, non- equivalence, and authority differences between language expressions. The Profile shall support Urdu and English legal expressions in a manner that preserves legal meaning, translation provenance, and stable structural alignment.

1.7.6 Validation Before Release

Validation before release shall be treated as a publication gate, not a best-efforts aspiration. Where deadlines or operational pressure arise, the correct control response is documented exception handling or delayed release, not silent weakening of the validation stack. Publication and exchange under this Profile shall be subject to formal validation and quality controls sufficient to reduce structural inconsistency, metadata drift, packaging drift, and downstream interoperability failure.

1.7.7 Controlled Extensibility

Controlled extensibility under this principle means that innovation is permitted only where it remains externally intelligible, documented, and reversible. Extensions that cannot be validated, explained, or migrated should not be allowed to become part of the production baseline. The Profile may permit controlled extensions where necessary for Pakistan-specific legal, editorial, or technical requirements; however, such extensions shall be explicitly governed and shall not be permitted to create avoidable incompatibility.

1.7.8 Vendor Neutrality

Vendor neutrality shall be tested by exit scenarios. If an institution could not export its corpus, validation evidence, identifiers, and publication logic from a supplier-controlled environment without semantic loss, the implementation should not be regarded as fully aligned with this principle. The Profile shall be technology-neutral and vendor-neutral. It shall not be written or governed in a manner that privileges a proprietary implementation or restricts conformance to a single tool, supplier, or platform.

1.7.9 Annex-Backed Implementability

This principle recognizes that a national profile becomes reliable only when prose obligations are backed by annexes, schemas, code lists, fixtures, and rule catalogues. The Profile shall therefore be maintained as an implementable package, not as a narrative text alone. The Profile shall be accompanied by normative annexes sufficient to make the national implementation testable, portable, and repeatable, including annexes for conformance statements, identifier grammar, metadata dictionary, structural templates, validation baseline, package and endpoint profile, and controlled vocabularies.

2 Normative Basis and References

For implementation safety, this clause shall be read as an explicit dependency-control mechanism. Institutions shall avoid relying on unnamed, drifting, or locally substituted standards references, and shall maintain an internal record of the exact reference versions, schemas, code lists, and update notices used in production at any given time.

2.1 Normative Standards

The standards listed here shall be treated as named dependencies whose versions are part of the national control surface. Implementing institutions should record which exact schema, naming-convention reference, language-tagging practice, and identifier standard version they are applying in production. The following standards and technical artifacts SHALL constitute the normative basis of this Profile, to the extent applicable:

• (a) OASIS Akoma Ntoso Version 1.0 Part 1: XML Vocabulary, approved 29 August 2018;
• (b) OASIS Akoma Ntoso Version 1.0 Part 2: Specifications, approved 29 August 2018;
• (c) OASIS Akoma Ntoso Naming Convention Version 1.0;
• (d) OASIS Akoma Ntoso media-type specification for application/akn+xml;
• (e) RFC 9676, LEX: A Uniform Resource Name (URN) Namespace for Sources of Law;
• (f) RFC 2119 and RFC 8174 for requirement keywords used in normative text;
• (g) BCP 47 language-tagging practice, as adopted by the Profile Owner for language and script tagging;
• (h) the XML, namespace, Unicode, character-encoding, URI, and IRI standards expressly adopted by the Profile Owner for production use under this Profile; and
• (i) the validation-related standards and rule-expression mechanisms formally adopted for conformance under this Profile. Where any inconsistency appears between local implementation practice and the normative basis listed above, the base standard and this Profile shall prevail over ad hoc local implementation preferences.

2.2 Normative National Instruments

National instruments referenced here shall anchor the technical profile to Pakistan’s legal and administrative reality. Where a future workflow or repository design would otherwise abstract away official publication, maintenance, translation, or archival obligations, these national instruments shall pull the implementation back into domestic legal alignment. Implementation of this Profile SHALL additionally operate consistently with the applicable national legal and institutional instruments governing, inter alia:

• (a) publication of laws;
• (b) maintenance and updating of legal texts in soft form;
• (c) preparation and publication of translations where applicable;
• (d) drafting, approval, and publication workflows for legal and legislative instruments;
• (e) institutional responsibilities of ministries, divisions, departments, secretariats, publication authorities, and other competent bodies; and
• (f) digital-governance or public-information mandates relevant to the establishment of a national machine-readable law framework. Without prejudice to the generality of the foregoing, this includes the national legal and administrative framework under which Pakistan’s laws are maintained, published, authenticated, made accessible, and, where applicable, translated or consolidated.

2.3 Related AKN and LegalDocML Artifacts

Related artifacts shall be used comparatively and carefully. They are useful for interpreting mature implementation practice, but they shall become binding only through explicit adoption, annex incorporation, or controlled implementation notice under this Profile. This Profile shall be interpreted in the context of the wider LegalDocML ecosystem. In applying or extending this Profile, due regard shall be had to relevant related artifacts, including but not limited to:

• (a) public application-profile approaches used in national or institutional implementations based on Akoma Ntoso;
• (b) conventions and examples concerning identifiers, conformance packaging, validation assets, resolver design, and bulk publication;
• (c) public implementation patterns relevant to drafting, publication, exchange, API exposure, and archival preservation; and
• (d) comparative material relevant to bilingual handling, FRBR-style modelling, and linkage to legal-identifier frameworks. The purpose of referencing such related artifacts is interpretive and comparative. Unless expressly adopted by the issuing authority or by a normative annex to this Profile, such artifacts shall not themselves become binding under this Profile.

2.4 Version Pinning and Reference Governance

Version pinning shall be explicit enough that two institutions can later determine whether they were applying the same normative baseline at the same time. Silent substitution of a newer schema, namespace practice, or rule set shall be treated as unmanaged change rather than harmless technical maintenance. Normative references under this Profile shall be version-pinned unless the reference is, by its nature, intended to track a governed evolving register or code list maintained under this Profile. Where the Profile Owner determines that a later version of a referenced standard or artifact should apply, that determination shall be made through a controlled update notice or profile version. Implementing institutions shall not silently substitute later versions of normative dependencies merely because a later version exists.

2.5 Informative References

Informative references should be curated to support implementation, migration, QA, and comparative understanding, but they shall not be allowed to dilute the binding hierarchy between the Profile, its annexes, and its adopted normative references. The Profile Owner may maintain an informative reference list to support implementation, interpretation, comparison, training, migration planning, and controlled future version. Such informative references may include:

• (a) comparative country studies;
• (b) institutional implementation guides;
• (c) API documentation and packaging examples;
• (d) sample corpora and example instances;
• (e) migration and validation guidance notes; and
• (f) rendering and publication guidance. Informative references shall not have normative force unless expressly incorporated into this Profile or an annex designated as normative.

3 Definitions

The terms in this clause are not editorial conveniences. They shall be used consistently across schemas, metadata, validation artifacts, repository behavior, resolver services, package manifests, and institutional guidance so that the same concept is not described differently by different systems or authorities.

3.1 Terms and Definitions

Definitions under this section shall be aligned across legal, technical, and operational usage so that the same concept is not interpreted differently by drafters, publishers, repository managers, validators, and downstream API consumers. For the purposes of this Profile, the following terms shall have the meanings assigned below.

3.1.1 Akoma Ntoso (AKN)

“Akoma Ntoso” means the base international LegalDocML standard used for the structured representation of legislative, parliamentary, judicial, and related legal documents.

3.1.2 Application Profile

“Application Profile” means a constrained, governed implementation of the base standard for a specific jurisdiction, institution, or operational context, including locally binding rules relating to structure, identifiers, metadata, validation, publication, exchange, and preservation.

3.1.3 Authoritative Text

“Authoritative Text” means the version or manifestation of a legal document that is recognized by the competent authority as the official source for publication, reference, or evidentiary reliance, subject to applicable law.

3.1.4 Official Derivative

“Official Derivative” means a published rendering, transformation, or manifestation derived from an authoritative source and issued under institutional control, including, where applicable, HTML, PDF, or translated outputs.

3.1.5 Informational Version

“Informational Version” means a version, rendering, or output made available for convenience, access, or reuse that does not itself alter the legal status of the authoritative text.

3.1.6 Work

“Work” means the abstract legal or legislative act, instrument, or document as a conceptual legal entity independent of language, file, or manifestation.

3.1.7 Expression

“Expression” means a realization of a Work in a particular language, version, or legally relevant textual state.

3.1.8 Manifestation

“Manifestation” means a concrete file, serialization, or output instance of an Expression, including machine-readable XML, HTML, PDF, or packaged distributions.

3.1.9 Consolidated Text

“Consolidated Text” means a version of a legal instrument showing the text as modified by subsequent amendments, repeals, commencements, corrections, or related legal events up to a stated point in time.

3.1.10 Point-in-Time Version

“Point-in-Time Version” means the version of a legal text representing its content as legally effective or textually constituted on a specified date.

3.1.11 Resolver

“Resolver” means a service or mechanism that maps a persistent identifier or canonical URI to a current location, representation, manifestation, or explanatory landing page of the referenced legal resource.

3.1.12 Conformance

“Conformance” means the state of meeting all applicable mandatory and conditional requirements of this Profile for a given class of implementation, document, package, or service.

3.1.13 Validation

“Validation” means the technical and editorial process by which a document, package, identifier set, metadata set, service output, or release candidate is checked for compliance with this Profile.

3.1.14 Profile Owner

“Profile Owner” means the institution formally designated to maintain, publish, revise, and govern this Profile.

3.1.15 Issuing Authority

“Issuing Authority” means the institution or authority under whose approval or endorsement this Profile is formally issued.

3.1.16 Canonical Representation

“Canonical Representation” means the primary machine-readable representation designated under this Profile as the controlling structured form for purposes of publication, validation, reuse, exchange, or preservation.

3.1.17 Bilingual Alignment

“Bilingual Alignment” means the maintained relationship between corresponding Urdu and English expressions, segments, or structural units of the same Work.

3.1.18 Source Manifestation

“Source Manifestation” means the file, publication copy, scan, facsimile, or other recorded source from which a structured or derivative manifestation is created or against which it is verified.

3.1.19 Controlled Vocabulary

“Controlled Vocabulary” means a governed set of allowed values, tokens, or codes designated by the Profile Owner for use in identifiers, metadata, lifecycle states, authority roles, or other profile-controlled fields.

3.1.20 eId “eId” means the expression-local structural identifier used to anchor a provision or component within a given expression.

3.1.21 wId “wId” means the continuity identifier used, where implemented, to maintain cross-version or cross-expression lineage of a provision or structural unit.

4 Abbreviations

This Clause sets out the abbreviations, naming conventions, and normative requirement keywords used throughout this Profile.

4.1 Abbreviations

Acronym use in later annexes, schemas, and implementation notices should remain consistent with this section. Where a new acronym becomes operationally important, it should be defined centrally rather than left to tool-specific or institution-specific interpretation. For the purposes of this Profile, the following acronyms apply:

Additional acronyms may be introduced in later clauses or annexes and shall, where first used, be defined.

4.2 Document Naming and Typographic Conventions

Naming and typographic conventions should also support tooling consistency. The same clause title, annex label, and requirement keyword practice should be reproducible across documentation, schemas, validation reports, and publication notices. Unless otherwise specified:

• (a) the term “Profile” means this Pakistan AKN Application Profile;
• (b) the term “base standard” means the underlying Akoma Ntoso standard and associated normative artifacts;
• (c) references to “shall”, “shall not”, “should”, “should not”, and “may” shall be interpreted in accordance with Clause 4.3;
• (d) clause numbering, annex references, and defined terms shall be interpreted according to their explicit usage within this document; and
• (e) where examples are provided, they are illustrative unless expressly designated as normative.

4.3 Keywords for Requirement Levels

Requirement words shall be interpreted strictly and consistently across the entire profile package. Implementations shall not weaken a SHALL through narrative qualification elsewhere unless the Profile or a controlled annex expressly creates an exception path. The keywords SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, and RECOMMENDED in this Profile indicate requirement levels.

• (a) SHALL and SHALL NOT indicate mandatory requirements;
• (b) SHOULD and SHOULD NOT indicate recommended requirements whose departure should be justified and documented where applicable;
• (c) MAY indicates a permissive option;
• (d) RECOMMENDED indicates a preferred implementation practice. Where a requirement applies only to a defined conformance class, that limitation shall be explicitly stated.

5 Governance, Ownership, and Maintenance

5.1 Profile Owner

The Pakistan Digital Authority shall serve as the Profile Owner unless another institution is formally designated by competent authority.

The Profile Owner shall be responsible for the stewardship, publication, maintenance, version control, and coordinated evolution of this Profile, including the maintenance of normative annexes, code lists, namespace policy, conformance artifacts, implementation guidance, and public notices relevant to profile use.

5.2 Issuing Authority

The issuing authority for this Profile shall be the authority designated in the approval and endorsement section of the formal instrument by which this Profile is adopted. Where the Profile is issued through an inter-institutional or government-approved mechanism, the issuing authority may act jointly or through a formally authorized lead institution. Where publication of the Profile occurs within a broader national standards framework, the document shall also comply with the applicable national issuance and publication rules for such instruments.

5.3 Governance Model

The governance model shall keep standards governance, authoritative publication governance, and institutional workflow governance distinct but interoperable. Pakistan’s implementation will be strongest if these layers share identifiers, code lists, validation assets, and issue-management discipline without collapsing their legal mandates. Implementation of this Profile shall be governed through a multi-layer model comprising standards governance, authoritative-publication governance, institutional workflow governance, and nationally shared technical services.

5.3.1 Standards Governance

Standards governance shall include stewardship of annexes, code lists, schemas, namespace policy, and publication notices, so that profile meaning remains stable across time and across toolchains. Standards governance shall include:

• (a) publication and maintenance of this Profile;
• (b) maintenance of identifier policy, code lists, metadata rules, namespace rules, and conformance artifacts;
• (c) operation or coordination of national conformance testing arrangements;
• (d) maintenance of reference examples, guidance notes, public registers, and implementation notices; and
• (e) coordination of national interoperability discussions relevant to machine-readable legal information.

5.3.2 Authoritative Publication Governance

Authoritative publication governance shall determine which manifestation or manifestation pair carries official status for public reliance, how corrections are announced, and how resolver and publication services communicate those status distinctions externally. Authoritative publication governance shall be exercised by the competent legal and publication authorities responsible for the release, maintenance, correction, consolidation, or official derivative publication of legal texts. That governance shall include:

• (a) determination of which manifestations are authoritative, official derivative, consolidated, translated, informational, or otherwise controlled under this Profile;
• (b) approval of release workflows for enactment-stage, publication-stage, and correction- stage resources;
• (c) control of publication notices, status notices, and authenticity statements; and
• (d) preservation of the legal and evidentiary distinction between official source text, controlled derivative, and convenience presentation.

5.3.3 Institutional Workflow Governance

Institutional workflow governance shall ensure that drafting, review, consolidation, translation, validation, and release actions remain attributable and reproducible. Local efficiency improvements are permitted only where they do not erode the externally visible national baseline. Institutional workflow governance shall include:

• (a) integration of the Profile into drafting, review, publication, translation, consolidation, and archival workflows;
• (b) editorial control over legal texts and transformations derived from them;
• (c) validation, release authorization, and provenance control within operational pipelines; and
• (d) alignment of publication practices with legal authenticity and institutional mandates.

5.3.4 National Shared Technical Services

Shared services should, at minimum, be considered for the resolver layer, namespace registry, conformance fixtures, code lists, package-validation baseline, and public issue register. Shared services reduce duplication and make federal-provincial alignment easier to sustain. The national governance model should, to the greatest extent reasonably practicable, include shared or coordinated services for matters that benefit from national consistency. Such services may include, inter alia:

• (a) a national resolver policy and, where designated, a resolver service;
• (b) a controlled identifier registry or publication of identifier grammar and examples;
• (c) a namespace and authority-list registry;
• (d) a national validator or a nationally coordinated validator baseline;
• (e) conformance test fixtures and public implementation notices;
• (f) a code-list service for jurisdictions, document families, language-status values, lifecycle states, and authority roles; and
• (g) a public issue-management mechanism for profile defects, clarifications, and controlled change requests.

5.3.5 Federal–Provincial Coordination

Federal–provincial coordination should prioritize common identifier grammar, controlled vocabulary reuse, validation equivalence, and publication-behavior consistency. Jurisdictional autonomy should be preserved in law and corpus governance, but not allowed to fragment the common technical baseline.

The governance model shall include an inter-institutional coordination mechanism through which federal and provincial bodies may:

• (a) align on identifiers and citation practices;
• (b) coordinate profile adoption and adaptation;
• (c) agree on document-type expansion and interoperability rules;
• (d) share implementation experience, conformance issues, and change requests; and
• (e) coordinate rollout windows where profile evolution affects cross-jurisdiction publication or exchange.

5.4 Technical Working Group

The Technical Working Group should be empowered to translate policy decisions into executable artifacts such as annex updates, rule clarifications, fixture updates, namespace proposals, and migration notes. Its value lies in shortening the path from issue discovery to governed technical remedy. A Technical Working Group shall be established or designated to support the Profile Owner and participating institutions in the implementation and maintenance of this Profile. The Technical Working Group shall include representation, at minimum, from:

• (a) the Profile Owner;
• (b) competent legal drafting and publication institutions;
• (c) parliamentary secretariats where applicable;
• (d) technical implementers responsible for drafting, validation, repository, resolver, archival, or publication systems; and
• (e) such other institutions as are designated by the governance mechanism. The Technical Working Group shall advise on technical issues, prepare proposed changes, review conformance questions, support profile evolution, maintain implementation artifacts, and recommend when recurring local practices should be elevated into nationally governed annexes or code lists.

5.5 Change Control Process

Change control shall preserve traceability from issue to decision to implementation artifact. The record should make clear whether a change is editorial, clarificatory, backward- compatible, or breaking, and what downstream actions institutions are expected to take. All substantive modifications to this Profile shall be managed through a formal change- control process. The change-control process shall include:

• (a) submission of a change request;
• (b) classification of the issue as editorial, clarificatory, backward-compatible, or breaking;
• (c) technical and institutional review;
• (d) impact assessment on identifiers, metadata, validation, packaging, publication, archival continuity, and existing conformant content;
• (e) decision by the Profile Owner or issuing authority, as applicable; and
• (f) publication of the approved change in accordance with the versioning policy.

No institution or implementer shall unilaterally alter the meaning of this Profile by local convention while continuing to claim conformance to it.

5.6 Review and Update Cycle

Review should be scheduled but also event-driven. Material base-standard changes, large- scale onboarding of new document classes, systemic implementation defects, or repeated ambiguity across institutions should all be capable of triggering an earlier governed review. This Profile shall be reviewed periodically on a schedule determined by the Profile Owner, or earlier where required by:

• (a) changes in the base standard or relevant normative artifacts;
• (b) implementation experience;
• (c) legal or institutional reform;
• (d) profile expansion to new document classes or jurisdictions;
• (e) material conformance or interoperability issues; or
• (f) accumulated evidence that a recurring implementation practice now requires controlled national standardization. A regular review cycle of not more than twenty-four months is recommended for the first three years of implementation, after which the cycle may be updated based on maturity and operational stability.

5.7 Versioning and Deprecation Policy

Versioning shall serve both legal-information stability and technical operability. Institutions should be able to tell, from release notices and version labels, whether a update affects only interpretation, also affects tooling, or requires managed migration of content and services. This Profile shall be versioned in a manner that clearly distinguishes between:

• (a) editorial updates;
• (b) clarificatory updates;
• (c) backward-compatible substantive updates; and
• (d) breaking updates requiring managed transition. Where an element, rule, annex, code list, endpoint behavior, identifier pattern, or practice is to be withdrawn from active use, the Profile Owner shall declare it deprecated, specify the date or version from which deprecation applies, and indicate the replacement approach where applicable.

5.8 Backward Compatibility Policy

Backward compatibility shall prioritize persistent identifiers, public fragment anchors, published package semantics, and external service contracts. Compatibility loss should be permitted only where compensating controls and transition support are clearly provided. Backward compatibility shall be preserved wherever reasonably possible, especially in relation to persistent identifiers, public citation anchors, published manifestations, resolver behavior, and machine-consumable metadata relied upon by downstream users. Where backward compatibility cannot be preserved, the Profile Owner shall publish transition guidance, migration requirements, and any relevant conformance implications before the breaking change takes effect.

5.9 Issue Tracking and Resolution

Issue tracking should distinguish between problems of wording, model design, validator behavior, code-list governance, implementation practice, and publication operations. That distinction makes it easier to resolve recurring defects without over-amending the core profile. The Profile Owner shall maintain an issue-management process sufficient to record, classify, monitor, and resolve technical, editorial, structural, governance, and conformance issues relating to this Profile. Issue records should distinguish between:

• (a) specification issues;
• (b) implementation issues;
• (c) conformance issues;
• (d) documentation issues;
• (e) requests for future enhancement; and
• (f) matters that should properly be resolved through controlled annex, code-list, or implementation-notice publication rather than through ad hoc local workaround.

6 Conformance Framework

Conformance under this clause shall be bounded, evidence-based, and specific to the object assessed. Institutions shall avoid generic claims of “AKN compliance” where the actual implementation is limited to a smaller document set, a narrower lifecycle stage, or a restricted publication capability. This Clause defines the conformance framework for implementations, documents, packages, services, and publication outputs operating under this Profile. The purpose of the conformance framework is to ensure that claims of compliance are specific, testable, repeatable, and supportable by evidence. Conformance under this Profile shall be determined against the applicable requirements of the Profile version identified in the conformance claim, together with any normative annexes, code lists, validation artifacts, and implementation notices expressly designated as binding by the Profile Owner. Unless expressly stated otherwise, conformance shall be assessed separately for each relevant object of assessment, including a document instance, a publication package, a repository service, a resolver service, an API, a bulk distribution service, or an archival package.

6.1 Scope of Conformance

The scope of conformance shall be explicit enough that implementers cannot hide weak practice behind broad labels. A document, service, package, resolver, API, or archive may each be conformant in different ways, and the Profile shall preserve that specificity. A document, package, service, system, or implementation may claim conformance to this Profile only if it satisfies all mandatory requirements applicable to the relevant conformance class under this Clause and the associated normative annexes.

No claim of conformance shall be made solely on the basis of partial structural similarity, isolated use of XML, or use of selected Akoma Ntoso elements without adherence to this Profile’s identifier, metadata, validation, packaging, and publication rules where applicable.

6.2 Conformance Statement

Conformance statements should function as controlled declarations, not marketing language. They shall identify version, classes, levels, limitations, and evidence pathways so that other institutions can understand exactly what has been implemented and what has not. Any institution, system, or service asserting conformance to this Profile shall maintain and, where appropriate, publish a conformance statement. A conformance statement shall, at minimum, identify:

• (a) the exact version of this Profile to which conformance is claimed;
• (b) the document classes or instrument families for which conformance is claimed;
• (c) the conformance class or classes claimed under Clause 6.3;
• (d) the compliance level claimed under Clause 6.5;
• (e) the validation mechanisms used, including schema validation, rule validation, business- rule validation, and editorial checks applied;
• (f) the package, resolver, API, or archival behaviors claimed where applicable;
• (g) any declared limitations, exclusions, transitional arrangements, or approved deviations; and
• (h) the institution responsible for the conformance claim and the date from which that claim takes effect. No claim of full or profile-wide conformance shall be made where conformance is limited to a subset of document classes, lifecycle stages, languages, services, or publication channels, unless that limitation is expressly declared.

6.3 Conformance Classes

The class structure here shall prevent all-or-nothing thinking. Pakistan’s rollout can mature progressively, but only if each institution says clearly whether it has achieved authoring, exchange, publication, resolver, API, or archival conformance and at what level. Conformance under this Profile shall be organized into the following classes. A single implementation may claim one or more conformance classes, provided that each claim is independently supportable by evidence and validation results.

6.3.1 Authoring Conformance

Authoring conformance shall include prevention of structurally plausible but semantically weak output. Systems should therefore constrain document type, language, metadata, identifier assignment, and validation preconditions during authoring rather than fixing everything only at the publication stage. Authoring conformance applies to systems or workflows used to create, edit, or transform legal texts into the canonical machine-readable representation defined by this Profile. An authoring-conformant implementation shall ensure, at minimum, that:

• (a) documents created or transformed under the implementation conform to the structural and metadata rules applicable to their document class;
• (b) required identifiers, lifecycle markers, language declarations, and authority references are created and maintained in accordance with this Profile;
• (c) editorial or workflow metadata do not displace or corrupt the canonical legal markup; and
• (d) documents cannot proceed to profile-conformant exchange or publication status without the required validation controls.

6.3.2 Exchange Conformance

Exchange conformance shall preserve not only XML bytes but also meaning-bearing relationships, package completeness, and the distinction between canonical content and auxiliary workflow material. Exchange conformance applies to systems, packages, or services that transfer machine- readable legal content between institutions, environments, or workflow stages. An exchange-conformant implementation shall ensure that:

• (a) the exchanged package preserves the canonical AKN representation without lossy alteration;
• (b) required metadata, identifiers, package manifests, integrity artifacts, and validation evidence accompany the exchange where prescribed;
• (c) the receiving system can determine the profile version, document type, language, lifecycle status, and package status of the transferred material; and
• (d) any proprietary or workflow-specific content included in the exchange remains controlled, documented, and separable from the canonical legal content.

6.3.3 Publication Conformance

Publication conformance requires that the released manifestation, its metadata, and any derivatives form one coherent publication record. It is not enough merely to expose a file if resolver behavior, status signaling, or traceability remain unclear. Publication conformance applies to systems or processes that release documents to public or restricted publication channels. A publication-conformant implementation shall ensure that:

• (a) the published XML manifestation corresponds to the validated canonical representation;
• (b) human-readable renderings are derived from, and traceable to, the canonical representation or other approved authoritative source;
• (c) publication metadata clearly distinguish authoritative, official derivative, consolidated, translated, and informational manifestations; and
• (d) published content remains stably identifiable, citable, and retrievable in accordance with Clause 10 and Annex F.

6.3.4 Resolver Conformance

Resolver conformance shall be measured by stability, clarity, and non-deceptive behavior. A conformant resolver shall help users and systems understand whether they are reaching a work, expression, manifestation, or explanatory landing page, and under what current status. Resolver conformance applies to services that map persistent identifiers or canonical publication identifiers to representations, manifests, or resources. A resolver-conformant service shall ensure that:

• (a) persistent identifiers remain actionable or otherwise resolvable through the mechanisms designated by the Profile Owner;
• (b) redirections preserve referential integrity and do not silently redirect to a legally different work or expression;
• (c) where multiple manifestations exist, the resolver distinguishes them clearly by media type, language, date, or status; and
• (d) resolver behavior is stable enough to support citation, cross-reference maintenance, and automated reuse.

6.3.5 API and Distribution Conformance

API and distribution conformance shall include predictable content types, parameter behavior, paging where needed, and clear relationship between metadata resources and full-document resources. Convenience serializations shall not dilute the canonical legal- information model. API and distribution conformance applies to interfaces or mechanisms that expose documents, packages, metadata, or related resources for machine consumption, download, or reuse. A conformant implementation shall provide outputs that are consistent with the declared machine-readable publication format, metadata profile, and access rules under this Profile and Annex F.

6.3.6 Archival Conformance

Archival conformance shall ensure that preserved resources remain interpretable even after production systems change. Preserved packages should therefore include enough identifier, metadata, provenance, and validation context to reconstruct why the resource had the status it did. Archival conformance applies to repositories or preservation workflows that store, retain, or reproduce machine-readable legal materials under this Profile. A conformant archival implementation shall preserve integrity, provenance, package intelligibility, and retrievability in accordance with the archival and preservation requirements of this Profile and the relevant annexes.

6.4 Requirement Categories

Requirement categories shall be interpreted through the conformance class and lifecycle context in which they operate. An optional feature never becomes permission to bypass a mandatory baseline, and a conditional requirement becomes binding whenever its condition is present. Requirements in this Profile shall be interpreted as follows:

• (a) mandatory requirements apply in all cases within the relevant conformance class;
• (b) conditional requirements become mandatory where the stated condition or document type is present;
• (c) optional requirements may be implemented at institutional discretion, provided that their implementation does not create inconsistency with mandatory or conditional requirements.

An implementation that fails a mandatory requirement for a claimed conformance class shall not be considered conformant for that class.

6.5 Levels of Compliance

The compliance levels here should be used to stage national adoption realistically without weakening the long-term target. Early capability can be recognized, but only if institutions remain explicit about what interoperability outcomes are not yet achieved. For operational clarity, implementations under this Profile shall be assessed against the following graduated levels of compliance. These levels do not replace the conformance classes in Clause 6.3; rather, they describe increasing degrees of implementation completeness and interoperability maturity.

6.5.1 Minimum Compliant

Minimum Compliant status is appropriate only where the implementation can already produce and preserve structurally valid, identifier-disciplined, metadata-bearing resources for the declared scope. It shall not be used to describe raw XML experiments or ungoverned one-off conversions. Minimum Compliant status shall apply where an implementation can produce or manage profile-conformant AKN instances for defined document types, with valid core structure, required identifiers, and minimum mandatory metadata, but does not yet provide complete publication, distribution, resolver, or archival capabilities.

6.5.2 Publication-Ready

Publication-Ready status shall mean that release controls, canonical manifestation handling, derivative traceability, and public status signaling are sufficiently mature for controlled dissemination under real institutional responsibility. Publication-Ready status shall apply where an implementation satisfies Minimum Compliant requirements and additionally supports validated public or controlled release of canonical XML together with at least one controlled human-readable manifestation and the metadata needed for official repository use.

6.5.3 Full Interoperable

Full Interoperable status should be treated as the main national target for production ecosystems. At this level, independent institutions should be able to consume, cite, validate, and preserve released resources without bespoke bilateral remediation. Full Interoperable status shall apply where an implementation satisfies Publication-Ready requirements and also supports stable exchange, persistent identification, resolver behavior, and machine-oriented access sufficient for interoperable reuse across institutional boundaries.

6.5.4 Advanced Semantic-Ready

Advanced Semantic-Ready capability shall remain additive and subordinate to the canonical legal representation. Semantic enrichment is useful only where it remains anchored to controlled identifiers, stable structures, and preserved publication meaning. Advanced Semantic-Ready status shall apply where an implementation satisfies Full Interoperable requirements and further supports enriched metadata, controlled vocabularies,

structured cross-references, and semantic interoperability features adequate for linked-data alignment, advanced analytics, or AI-ready corpora.

6.6 Evidence of Conformance

Evidence should be retained in a form suitable for later audit, migration, procurement assurance, and inter-institution trust. A conformance claim that cannot be re-examined after the fact should not be treated as robust. Evidence of conformance shall include, as applicable:

• (a) schema-validation results;
• (b) rule-validation results;
• (c) editorial QA records;
• (d) conformance declarations in the form prescribed by Annex A;
• (e) package inspection records;
• (f) resolver or API behavior tests;
• (g) archival integrity and package-completeness checks; and
• (h) such additional evidence as the Profile Owner prescribes through annex, code list, or implementation notice.

6.7 Conformance Assessment Approach

Assessment may be staged and multi-sourced, but the underlying tests and evidentiary standards should remain nationally comparable. Otherwise, different institutions may claim the same level while having been measured against materially different baselines. Conformance may be assessed through:

• (a) self-assessment by an implementing institution;
• (b) coordinated assessment under a national conformance program;
• (c) third-party technical assessment where designated; and
• (d) automated conformance testing supported by reference fixtures and validation assets. The conformance framework shall be supported over time by a published set of schemas, rules, fixtures, and example packages consistent with mature profile-governed implementations.

6.8 Non-Conformance Severity and Handling

Severity handling shall encourage transparent remediation rather than silent downgrading of defects. If a release proceeds under exception, the record should show who approved it, what risk was accepted, and how correction will be completed. Where an implementation, document, package, or service fails to meet one or more applicable requirements of this Profile, the non-conformance shall be recorded, classified, and handled through a controlled remediation process. Non-conformance handling shall, at minimum, distinguish between:

• (a) blocking defects, being defects that prevent publication, exchange, or compliance assertion;
• (b) material defects, being defects that do not necessarily block internal handling but materially affect interoperability, authenticity, citation, legal clarity, or preservation quality;
• (c) minor defects, being editorial or technical defects that do not materially alter legal meaning or core interoperability but nonetheless require correction; and
• (d) advisory findings, being non-binding improvement observations. No document shall be released as profile-conformant where blocking defects remain unresolved.

6.9 Exceptions and Transitional Claims

Exceptions shall be time-bounded, explicit, and narrow. Transitional claims are useful during rollout, but they shall never be worded in a way that lets a partial implementation impersonate a fully conformant national service. Where a document, package, or service is released under an approved transitional arrangement despite identified limitations, the limitation shall be expressly declared and shall not be represented as full conformance. No institution shall reclassify a blocking or material requirement as optional by local practice without an approved national profile change or a formally recorded national exception.

7 Pakistan Legislative Domain Model

The domain model in this clause shall function as the common legal-information vocabulary for Pakistan’s machine-readable law environment. Local workflow labels may be richer, but they shall map cleanly to the controlled public model so that cross-institution exchange does not collapse under incompatible local semantics. This Clause defines the conceptual legislative domain model to be used for machine- readable representation under this Profile. The purpose of the domain model is to ensure that legal works, institutional roles, lifecycle states, and legal events are represented consistently across drafting, exchange, publication, consolidation, and archival workflows. Unless expressly stated otherwise, the domain model in this Clause is normative for all document types within scope.

7.1 Jurisdiction Model

Jurisdiction shall be modelled as a controlled legal-information attribute affecting identifiers, metadata, scope, and publication behavior. The same work shall not drift between jurisdictions because of portal labeling, administrative hosting, or user-interface convenience. The jurisdiction model under this Profile shall distinguish, at minimum, the jurisdiction in which a legal work is made, the jurisdiction in which it applies where different, and the jurisdictional label by which it is published and cited.

7.1.1 Federal Jurisdiction

Federal works should remain identifiable as federal even where their application, implementation, or retrieval is mediated through multiple institutional channels. Territorial extent and operational responsibility may vary, but conceptual legal identity should remain stable.

Federal jurisdiction shall be used for the Constitution of Pakistan, Acts of Majlis-e-Shoora (Parliament), Ordinances promulgated at the federal level, and subordinate or executive legal instruments issued under federal legal authority. Where an instrument is made by or under the authority of a federal institution but has differentiated territorial application, the work shall remain identified as a federal work while the territorial extent or application shall be recorded in metadata. A federal work shall not be reclassified as a provincial work merely because it is implemented, administered, or invoked by a provincial authority.

7.1.2 Provincial Jurisdictions

Provincial onboarding shall preserve equivalence of technical discipline without collapsing the distinct identity of provincial works. Similar titles or subjects across provinces shall not justify identifier or metadata conflation. Provincial jurisdictions shall, at minimum, support Punjab, Sindh, Khyber Pakhtunkhwa, and Balochistan as distinct legal jurisdictions for purposes of identification, publication, interoperability, and controlled expansion of this Profile. A provincial work shall be identified as a distinct work of the relevant province even where it corresponds in subject matter, short title, or numbering pattern to a federal or another provincial instrument. Where a provincial corpus is onboarded under this Profile, the province shall be recorded through the controlled jurisdiction vocabulary prescribed by the Profile Owner and shall be reflected consistently in identifiers, metadata, and publication services.

7.1.3 Other Constitutionally Relevant Jurisdictions

Where additional jurisdictions are onboarded, their inclusion should be backed by controlled tokens, authority records, and onboarding guidance so that later scale-out does not depend on ad hoc naming practices. This Profile may additionally represent other constitutionally or administratively distinct jurisdictions, territories, or publication domains that are lawfully brought within scope by the competent authority, including the Islamabad Capital Territory and any other jurisdiction explicitly designated by the Profile Owner for technical interoperability purposes. Where such jurisdictions are included, they shall be governed through explicit code lists and shall not be represented through uncontrolled local naming practices.

7.2 Institutional Actors

Institutional actor modelling should support both legal provenance and workflow accountability. Distinguishing who drafted, approved, promulgated, published, consolidated, translated, or preserved a resource materially improves later audit and interpretive clarity. The legislative domain model shall distinguish the institutional roles relevant to creation, approval, publication, maintenance, translation, consolidation, and preservation of legal documents. Depending on the document type and institutional workflow, these roles may include, inter alia:

• (a) the drafting authority;
• (b) the introducing or sponsoring authority;
• (c) the deliberative authority;
• (d) the passing or adopting authority;
• (e) the assenting, promulgating, or issuing authority;
• (f) the publication authority;
• (g) the consolidation authority;
• (h) the translation authority; and
• (i) the archival or preservation authority. A single institution may perform more than one role; however, the role performed shall be distinguishable in metadata and provenance where relevant to authenticity, accountability, or lifecycle interpretation.

7.3 Instrument Families

Instrument-family classification should drive template selection, identifier formation, metadata expectations, and validation rules. Families that differ legally should not be collapsed just because they look similar in a PDF. For modelling purposes, legal documents within scope shall be grouped into instrument families reflecting their constitutional or legal character. The instrument families under this Profile shall include, at minimum:

• (a) constitutional instruments;
• (b) primary legislation;
• (c) ordinance-type instruments;
• (d) parliamentary bill documents;
• (e) delegated legislation, including rules and regulations;
• (f) executive statutory instruments, including notifications and statutory regulatory orders where included within scope; and
• (g) publication-control instruments, including commencement notices, corrigenda, or related Gazette publications where designated. Document-type specific structural and metadata requirements may vary by instrument family; however, such specialization shall remain consistent with the core modelling principles of this Profile.

7.4 Legislative Lifecycle States

Lifecycle states under this Profile should remain externally understandable and nationally controlled. Internal workflow micro-states may exist, but they should map cleanly to the controlled public lifecycle vocabulary used for publication and exchange. The lifecycle of a legal document under this Profile shall be represented through controlled lifecycle states. These states support drafting, repository management, publication interpretation, and legal-history reconstruction. The lifecycle states described below are minimum nationally governed states and may be supplemented by more detailed sub-states in workflow systems, provided that such sub- states do not displace the controlled public state model of this Profile.

7.4.1 Draft

Draft state handling shall preserve confidentiality and non-authoritative status while still allowing structured authoring, validation, and inter-office exchange. Draft material should not be discoverable through the same public patterns used for released law unless intentionally published as draft. The Draft state shall apply to a text under preparation, review, or internal circulation prior to formal introduction, passage, issuance, or authorized publication. Draft state documents shall not be represented as enacted or authoritative legal texts unless the competent authority has expressly designated them as authoritative in that drafting context.

7.4.2 Bill

Bill-state representation should preserve parliamentary stage, chamber context, and text- version history so that the pre-enactment record remains usable without misleading users into treating the bill as enacted law. The Bill state shall apply to a text introduced into the legislative process as a bill or amendment bill but not yet enacted. Where multiple stages of a bill exist, including as introduced, as reported, or as passed by one House, the bill shall remain within the bill family unless and until it attains the enacted state under applicable law.

7.4.3 Passed

Passed status should be carefully separated from enactment and commencement, especially in interfaces, APIs, and derivative renderings where users may otherwise infer legal force too early. The Passed state shall apply where a text has completed the relevant legislative vote or approval stage but has not yet attained full enactment, assent, promulgation, or publication status required for legal effect. The Passed state shall be used with care so as not to imply commencement or in-force status prematurely.

7.4.4 Assented / Enacted

Enactment handling shall identify the legally relevant act, date, and authority that moves the instrument out of the parliamentary or drafting stage and into enacted status, without assuming that commencement is identical. The Assented or Enacted state shall apply where the competent constitutional or legal act of assent, enactment, or promulgation has occurred and the work has attained enacted status, whether or not it has yet commenced. Enactment and commencement shall be treated as distinct events unless the legal instrument makes them coincide.

7.4.5 In Force

In-force status shall support full, partial, staged, and conditional force. Simplified document- wide assertions should be avoided where only some provisions have commenced or where territorial application differs.

The In Force state shall apply where the legal provisions represented are operative as law for the relevant time and territorial scope. Where commencement is partial, staged, or conditional, the in-force position shall be represented through appropriate temporal or component-level modelling, rather than by oversimplified document-wide assertions where such simplification would mislead users.

7.4.6 Amended

The Amended state shall apply where a work has been altered by one or more subsequent legal events affecting text, structure, effect, scope, or operation. The existence of amendment does not by itself determine whether the published text is as enacted, as amended, or consolidated; that distinction shall be made explicitly elsewhere in the model.

7.4.7 Consolidated

The Consolidated state shall apply to a non-original expression that incorporates amendments, repeals, substitutions, insertions, omissions, or related legal changes into an integrated text as at a stated point in time. A consolidated expression shall be clearly distinguished from the as-enacted expression and shall record its consolidation basis and effective date.

7.4.8 Repealed

Repeal handling should distinguish total repeal, partial repeal, expiry, sunset, spent status, and comparable end-state mechanisms where those distinctions matter for legal research or point-in-time reconstruction. The Repealed state shall apply where a work, or the relevant legal effect of it, has ceased by reason of repeal, expiry, sunset, or other terminating legal mechanism recognized in law. Where repeal is partial, the model should record the extent of repeal and avoid treating the whole work as fully repealed unless that is legally accurate.

7.4.9 Corrected / Corrigendum

The Corrected or Corrigendum state shall apply where an official correction, rectification, or publication-level amendment has been issued to address error without re-enacting the whole work. Corrections shall be represented in a manner that preserves the prior publication history and allows users to determine what was corrected, when, by whom, and with what status.

7.5 Event Model

The event model shall be sufficiently explicit that later automated consolidation, citation history, and knowledge-graph enrichment can rely on event records rather than on narrative notes buried in prose or PDFs. The legislative domain model under this Profile shall represent legally or editorially significant events as distinct, traceable events associated with the relevant work, expression, or manifestation. The event model shall support, at minimum, enactment events, amendment events, repeal events, commencement events, and correction events. Additional event types may be

introduced under controlled extension rules where justified by Pakistan-specific legal or publication requirements.

7.5.1 Enactment Events

Enactment events should identify date, authority, related publication trigger, and any linked instrument or approval facts required to understand how the work attained enacted status. An enactment event shall record the legally relevant act by which a bill, ordinance, regulation, rule, or other instrument attains its enacted or issued status. Where applicable, enactment metadata should identify the competent authority, the enactment date, the publication trigger where distinct, and any related authority instrument.

7.5.2 Amendment Events

Amendment events should support both whole-work and fine-grained provision targeting so that later users can reconstruct not just that a change happened, but which text was inserted, omitted, substituted, or otherwise affected. An amendment event shall record the legal event by which a prior work or part of a work is altered, substituted, inserted into, omitted from, or otherwise textually or legally modified by a later instrument. Amendment events shall be modelled so that the relationship between the amending instrument and the amended target remains explicit and machine-processable.

7.5.3 Repeal Events

Repeal events should preserve their scope and basis, including whether the repeal is direct, partial, implied through replacement, or tied to a broader legislative reform instrument. A repeal event shall record the legal event by which a work, a provision, or a legal effect is repealed, revoked, spent, superseded, or otherwise brought to an end. Where the repeal is not total, the event representation shall distinguish partial repeal from full repeal.

7.5.4 Commencement Events

Commencement events should support multiple dates, conditions, territories, and provision ranges, because legal effect often begins in layers rather than all at once. A commencement event shall record the date or condition by which an enacted or issued instrument, or part of it, comes into force. Commencement events shall support immediate, deferred, staggered, conditional, and partial commencement patterns where these occur in Pakistani legal practice.

7.5.5 Correction Events

Correction events should make the basis and effect of the correction explicit so that repositories and users can tell whether the correction changes legal meaning, publication accuracy, or only a technical manifestation defect. A correction event shall record an official textual or publication correction, including corrigenda and rectifications, that affects the intelligibility or accuracy of a previously released text. Correction modelling shall preserve publication history and shall not silently overwrite the record of the earlier manifestation.

8 Scope of Documents Covered

This Clause identifies the categories of documents covered by this Profile in its initial implementation phase, distinguishes documents currently outside scope, and sets the basis for future expansion. Document classes brought within scope shall be interpreted narrowly and governed through controlled inclusion, so that institutions do not apply the Profile inconsistently to materials for which the required structure, identifiers, and publication rules have not yet been defined.

8.1 Documents in Scope for Version 1

Version 1 of this Profile shall apply, at minimum, to the document classes set out in this Clause.

8.1.1 Constitution

The Constitution of Pakistan, including its authoritative text, amendments, and controlled consolidated expressions, shall be within scope. Given its foundational status, the Constitution should be treated as a priority class for canonical structuring, persistent identification, and point-in-time consolidation under this Profile.

8.1.2 Federal Acts

Acts of Majlis-e-Shoora (Parliament), whether principal or amending, shall be within scope. Both as-enacted expressions and controlled consolidated expressions of Acts shall be supported under this Profile.

8.1.3 Ordinances

Ordinances promulgated under competent constitutional authority at the federal level shall be within scope, together with relevant lifecycle and status information. Where an Ordinance subsequently lapses, is repealed, or is replaced by Act, those relationships should be represented explicitly.

8.1.4 Bills

Bills, including amendment bills and other bill-form parliamentary texts designated by the competent authority, shall be within scope for structured representation. Bill versions should be capable of representing the legislative stages designated by the relevant parliamentary workflow, subject to the controlled lifecycle model in Clause 7.

8.1.5 Rules

Rules made under statutory authority shall be within scope where they are formally designated for inclusion by the issuing or publication authority and where the required structural and publication controls can be applied.

8.1.6 Regulations

Regulations made under statutory or other lawful authority shall be within scope on the same basis as Rules, subject to the document-type-specific structural requirements of this Profile.

8.1.7 Notifications and Statutory Regulatory Orders (SROs)

Notifications, Statutory Regulatory Orders, and comparable statutory or executive instruments shall be within scope where they create, modify, implement, or communicate legal effect in a manner requiring machine-readable treatment under the national machine- readable legislative framework. Because publication practice for these instruments is often heterogeneous, their inclusion shall be governed by controlled onboarding and validation rules rather than assumed wholesale.

8.1.8 Gazette Notices and Related Publication Instruments

Gazette notices, commencement instruments, corrigenda, and other publication-linked legal notices may be included within scope where they are necessary to represent lifecycle, legal effect, or publication authenticity accurately. Where included, such instruments shall be modelled in a way that preserves their relationship to the primary work or event they affect.

8.2 Documents Out of Scope for Version 1

Unless expressly designated otherwise by the Profile Owner or issuing authority, the following classes of materials shall be treated as out of scope for Version 1:

• (a) judicial decisions and court judgments;
• (b) parliamentary debates, questions, committee proceedings, and related parliamentary records not constituting legislative instruments within scope;
• (c) treaties, agreements, contracts, or policy papers not designated as machine-readable legislative instruments under this Profile;
• (d) administrative forms, manuals, circulars, office memoranda, or internal guidance documents lacking legislative or normative status within the intended scope of this Profile; and
• (e) local-government or sector-specific legal corpora for which no approved document-type profile has yet been issued. The exclusion of a document class from Version 1 does not prevent future onboarding; it means only that a national profile-conformant representation has not yet been formally defined for that class.

8.3 Future Expansion Scope

This Profile is intended to be extensible. Future updates may bring additional classes of legal, parliamentary, regulatory, or policy instruments within scope where there is a justified business, legal, or interoperability need. Future expansion may include, inter alia, provincial primary legislation, local legislative instruments, parliamentary records, selected judicial materials, explanatory memoranda, or other related corpora, provided that the governing authority publishes the necessary structural, metadata, and conformance rules for those classes.

8.4 Legacy Documents and Born-Digital Documents

This Profile shall apply to both born-digital and legacy documents within scope.

Born-digital documents are those created natively within systems or workflows designed to produce profile-conformant structured output. Legacy documents are those converted from pre-existing non-native sources, including PDF, Word-processing files, HTML pages, scanned images, or other historical publication formats. Legacy conversion under this Profile shall be subject to stricter provenance, validation, and editorial review controls because historical sources may contain OCR defects, formatting inconsistencies, missing metadata, or publication ambiguities. A legacy-converted document shall not be treated as equivalent to a born-digital authoritative source unless the competent authority has performed the validation and release steps required to authorize it as such.

9 Core Modelling Approach

This Clause defines the core modelling approach by which legal resources shall be represented under this Profile. The modelling approach is intended to preserve legal meaning, publication integrity, version distinction, and machine-processable interoperability while remaining aligned with the conceptual architecture of Akoma Ntoso. The rules in this Clause shall guide how Pakistan-specific legal resources are identified as works, realized as expressions, embodied as manifestations, and distinguished according to legal status, time, language, and publication channel.

9.1 Canonical Representation

The canonical machine-readable representation under this Profile shall be the profile- conformant Akoma Ntoso XML instance designated by the competent workflow or publication authority. The canonical representation shall serve as the controlling structured representation for validation, exchange, publication derivation, machine reuse, and preservation, unless the issuing authority expressly designates another equivalent representation for a defined purpose. Human-readable outputs such as HTML, PDF, or print-oriented renderings may be derived from the canonical representation or from another authorized source under controlled workflow, but such outputs shall not displace the canonical representation for machine- oriented interoperability.

9.2 Work, Expression, and Manifestation Model

This model shall be implemented consistently in identifiers, metadata, packaging, resolver behavior, API responses, and preservation sets. Treating it as theory only would reintroduce ambiguity at the precise places where production systems need deterministic distinctions. This Profile shall apply a Work–Expression–Manifestation model for conceptual and operational clarity. The Work shall represent the abstract legal entity, independent of file, language, or particular serialized output. The Expression shall represent a realization of that Work in a particular language, version, or legally relevant textual state.

The Manifestation shall represent a concrete file, serialization, or distributed instance of an Expression, including XML, HTML, PDF, packaged distributions, or preservation copies. Where bilingual publication is undertaken, Urdu and English realizations of the same legal work should, where legally and institutionally appropriate, be modelled as distinct expressions of the same work rather than as separate unrelated works. This model shall be used to distinguish original enactment from later consolidated expressions, and canonical XML from derivative renderings, without collapsing them into a single undifferentiated publication object.

9.3 Official, Authoritative, and Informational Texts

The status taxonomy here should be visible to both humans and machines. Portal labels, API fields, and package manifests should all communicate the same status semantics rather than requiring users to infer them from context. This Profile shall distinguish among authoritative texts, official derivatives, and informational versions. An authoritative text is the manifestation or expression formally recognized by the competent authority as the official source for publication, citation, or evidentiary reliance, subject to applicable law. An official derivative is a rendering or representation generated or issued under institutional control from an authoritative or otherwise approved source, including HTML presentations, PDFs, translated outputs, or editorially enhanced views. An informational version is a non-authoritative convenience representation made available for access, indexing, analytics, or other downstream purposes without altering the legal status of the authoritative source. Where doubt may arise, metadata and publication notices shall make this distinction explicit.

9.4 Point-in-Time and Versioning Model

Versioning should be capable of reconstructing both textual history and effective legal state. The profile should therefore preserve not only current expressions but also historically significant prior expressions and the dates or events that link them. The modelling approach under this Profile shall support point-in-time representation and explicit version distinction. A point-in-time expression shall represent the text of the work as legally effective, or textually constituted, at a stated date. Versioning shall be explicit and shall not rely solely on file timestamps, repository order, or informal publication practice. Where a text changes because of enactment, amendment, repeal, correction, re-publication, translation update, or editorial consolidation, the model shall distinguish the new expression or manifestation from its predecessor in a manner that preserves traceability.

9.5 As-Enacted, As-Amended, and Consolidated Forms

This Profile shall distinguish among as-enacted, as-amended, and consolidated forms of legal text. An as-enacted expression represents the text in the form in which it was enacted, assented to, promulgated, or otherwise issued at the time of original legal effect.

An as-amended expression may represent a legally later state that incorporates one or more amendments or legal changes but is not necessarily a formally issued consolidation product. A consolidated expression represents an integrated text prepared to show the state of the law after relevant legal changes up to a stated point in time. The distinction among these forms shall be explicit in metadata, publication services, and citation handling so that users and systems do not confuse historical original texts with later integrated views.

9.6 Amendment and Repeal Modelling Philosophy

The philosophy here should favor explicit legal relationships over display-only hints. Human- readable notes may assist interpretation, but downstream quality depends on structured machine-processable relations among amending, amended, repealing, and repealed resources. Amendment and repeal shall be modelled as relationships and events, not merely as informal explanatory notes. Where an amending instrument changes a target work, the relationship between the source instrument and the affected target components shall be represented in a way that supports both human interpretation and machine processing. Repeal shall likewise be represented explicitly, with sufficient precision to distinguish full repeal, partial repeal, substitution, omission, expiry, or other legally terminating or superseding effects. The modelling philosophy of this Profile is to preserve the separateness of the amending or repealing instrument while also enabling downstream consolidation and point-in-time reconstruction.

9.7 Corrigenda and Errata

Corrigenda, errata, and comparable corrections shall be modelled as controlled corrections rather than as silent overwrites. Where the correction is itself a separate legal or publication instrument, it should be represented as such and linked to the affected work, expression, or manifestation. Where the correction is applied within a later manifestation of the same expression, the correction basis, responsible authority, and date shall be retained in provenance or publication metadata. Correction handling shall preserve the ability to understand what the earlier publication contained and how the later corrected state differs from it.

9.8 Consolidation Status and Evidentiary Notes

Consolidation notes should state not only the as-at date but also the basis and known limitations of the consolidation. This is especially important for legacy corpora and partially updated collections where not all legal effects may yet have been integrated. A consolidated text shall include clear consolidation status information sufficient to identify the basis, date, scope, and evidentiary character of the consolidation. Where a consolidated text is not itself legally authoritative, it shall be labelled accordingly and shall not be represented as the original enacted source.

Where a consolidated text is officially maintained, the responsible consolidation authority and the date through which legal changes have been incorporated shall be recorded. Where known limitations exist, including pending amendments not yet incorporated, uncertain historical source quality, or unresolved publication questions, those limitations shall be disclosed through appropriate evidentiary or explanatory notes.

10 Identifier and Citation Policy

This Clause defines the identifier and citation policy for legal resources represented under this Profile. The policy is intended to ensure persistence, resolvability, legal clarity, bilingual interoperability, stable cross-referencing, and long-term machine reuse. Identifiers under this Profile shall distinguish conceptual legal identity from publication location, and shall support both persistent legal citation and network-based retrieval.

10.1 General Identifier Principles

Identifier governance should favor long-lived legal identity over incidental publication paths. Internal convenience keys may exist, but they shall remain subordinate to the nationally governed public identifier system established by this clause and its annexes. Identifiers used under this Profile shall be stable, unambiguous, minimally dependent on mutable technical infrastructure, and capable of controlled long-term maintenance. An identifier shall not be changed merely because a platform, repository, software supplier, host name, or URL path changes. Identifiers shall be assigned consistently across document classes, jurisdictions, languages, and lifecycle states, and shall not be generated through uncontrolled local conventions. Where multiple identifiers exist for operational reasons, their roles shall be distinguished clearly so that users and systems can determine which identifier is persistent, which is resolvable, which is internal, and which is fragment-specific.

10.2 Identifier Architecture

This Profile adopts a layered identifier architecture comprising:

• (a) a persistent legal-identifier layer for the Work and, where required, for expression-level legal identity;
• (b) a resolver and publication-URI layer for network retrieval and service behavior;
• (c) stable component identifiers for citation-relevant structural parts; and
• (d) workflow-continuity identifiers for cross-version processing and editorial traceability. The definitive Pakistan identifier grammar SHALL be the grammar set out in Annex B.

10.2.1 Persistent Legal Identifier Layer

The persistent legal-identifier layer SHALL be based on URN:LEX, profiled nationally for Pakistan in accordance with Annex B and governed in a manner consistent with RFC 9676. The purpose of the persistent layer is to identify the legal resource in a durable, citation- oriented manner independent of particular web-hosting arrangements, supplier choices, or current publication endpoints.

No institution shall introduce a competing public persistent-identifier syntax for in-scope national production use unless such syntax is formally adopted through national change control.

10.2.2 Resolver and Publication Layer

The resolvable publication layer SHALL use canonical HTTP or HTTPS URIs designated by the publication authority or resolver service. Canonical publication URIs shall be structured predictably enough to support publication, API reuse, content negotiation, and automated linking. They may resolve directly to a manifestation or indirectly through a resolver mechanism; however, they shall not undermine the persistence function of the legal-identifier layer.

10.3 Work-Level Identifier Rules

Each work within scope SHALL be assigned a stable work-level persistent identifier. The work-level identifier shall identify the abstract legal instrument independently of language, manifestation format, or derivative rendering. As a general rule, the Pakistan work-level URN SHALL encode only such attributes as are sufficiently stable for long-term legal identity, including jurisdiction, document family, year or date of making where appropriate, and the official number or other nationally governed designation. A work-level identifier SHALL NOT be made language-specific unless the Profile Owner expressly determines that the legal reality of the corpus requires separate work treatment rather than expression-level distinction.

10.4 Expression-Level Identifier Rules

Each expression SHALL be identifiable in a manner that distinguishes it from other realizations of the same work. Expression-level distinction may be required because of language, point-in-time state, official consolidation, corrected state, or other legally or publication-relevant variation. Where bilingual publication is undertaken, Urdu and English expressions of the same work SHALL be explicitly distinguishable. Where point-in-time or consolidated states are represented, the expression-level identifier or expression metadata SHALL make the relevant temporal or status distinction machine- processable.

10.5 Manifestation-Level Identifier Rules

Each distributed manifestation SHALL be identifiable in a manner that distinguishes file or serialization instances from the work and expression levels. Manifestation-level identification may be realized through a canonical publication URI, a package path, a media-specific suffix, a checksum-linked descriptor, or another controlled mechanism, provided that the manifestation remains traceable to the governing work and expression. Manifestation identifiers SHALL support, where applicable, XML, HTML, PDF, preservation packages, and other authorized outputs.

10.6 Fragment Identifier Rules

This Profile SHALL support stable fragment identification for structural components of a legal document, including Parts, Chapters, Articles, Sections, subsections, clauses, paragraphs, Schedules, tables, and forms where applicable. Fragment identifiers shall be designed so that internal linking, citation, amendment targeting, bilingual correspondence, and machine processing remain stable over time to the greatest extent reasonably possible. Where renumbering, restructuring, or editorial normalization affects a component, the identifier policy SHALL preserve traceability rather than silently replacing all historical anchors.

10.6.1 Part and Chapter Identifiers

Parts, Chapters, and equivalent higher-level divisions shall receive stable fragment identifiers generated according to the grammar in Annex B. Where the source text uses Roman numerals, Urdu labels, mixed captions, or jurisdiction- specific drafting conventions, the public fragment identifier shall nonetheless follow a predictable machine-friendly pattern while preserving the human label separately in content or metadata.

10.6.2 Article and Section Identifiers

Articles, Sections, and other primary numbered provisions shall receive stable fragment identifiers suitable for durable citation and cross-reference handling. Where the source text includes inserted or substituted provisions such as section 5A, 5AA, or comparable patterns, the identifier policy shall preserve legal intelligibility without forcing unstable renumbering across the corpus.

10.6.3 Schedule and Annex Identifiers

Schedules, Annexes, and comparable attached components shall receive distinct fragment identifiers because they frequently operate as legally significant components rather than mere appendices. Where a Schedule or annex contains its own internal divisions, those subordinate components shall likewise be fragment-identifiable under controlled rules.

10.6.4 Table and Form Identifiers

Tables and forms that are legally integral to the document shall receive stable identifiers where citation, amendment, machine processing, or bilingual alignment requires such distinction. Purely presentational tables introduced only for human-rendering convenience need not receive public citation identifiers unless they are treated as legally meaningful components.

10.7 eId and wId Policy This Profile distinguishes between expression-local structural identifiers and cross-version continuity identifiers. The eId SHALL identify the structural component within a given expression and SHALL function as the public structural anchor ordinarily used for manifestation-level rendering, hyperlinking, and expression-specific citation.

The wId SHALL identify the continuity of a provision or structural unit across versions, transformations, corrections, and consolidations and SHALL therefore be used, where implemented, as the stable workflow and cross-version linkage identifier. Where a structural position changes between expressions, the eId may change in accordance with the expression-local structure; however, the wId should remain stable unless the underlying provision continuity itself has ceased or been deliberately reconstituted. No implementation shall invert these roles in a manner that treats eId as the primary cross- version continuity mechanism and wId as a merely transient local label.

10.8 Versioned URI Rules

Where canonical HTTP URIs express version, language, or date distinctions, those distinctions SHALL be governed through the nationally controlled patterns in Annex B and Annex F. A versioned URI shall not imply a different work where the difference is only at expression or manifestation level. Where a current resolver URI and a version-specific URI both exist, their relationship shall be explicit and machine-processable.

10.9 Citation and Cross-Reference Rules

Citation under this Profile shall support both human legal citation practice and machine- resolvable cross-reference. A citation shall, where practicable, identify the work, the relevant component, and, where necessary, the expression or point-in-time state relied upon. Internal references within documents shall target stable structural anchors rather than brittle page-number or layout-dependent references. External references should, where the target corpus supports it, resolve to persistent identifiers or canonical URIs rather than to transient download links or unmanaged file names.

10.10 Resolver, Redirect, and Content Negotiation Rules

Resolver and redirection behavior under this Profile shall preserve citation integrity and distinguish clearly among work-level, expression-level, and manifestation-level access. Where content negotiation is offered, the negotiation service shall not obscure the identity of the requested resource or silently substitute a legally different resource. Redirects shall be controlled and should be permanent only where the redirection target is intended to remain the canonical location for the same identified resource. Publication services SHALL support deterministic retrieval of at least the canonical XML manifestation and, where offered, controlled human-readable manifestations and metadata responses.

10.11 Language Tokens in Identifiers

Language tokens should distinguish expression language only, not work identity or interface language. Token policy should therefore remain simple, controlled, and consistent across identifiers, URIs, metadata, and APIs.

Where language distinction is reflected in identifiers or URIs, the language tokens shall be controlled nationally and applied consistently. Language tokens shall distinguish, at minimum, Urdu and English where both are represented. Language tokens shall indicate expression-level language realization and shall not be misused to imply different works where the underlying legal resource is the same work in different language expressions.

10.12 Normative Grammar and Examples

The definitive Pakistan identifier grammar, component-naming rules, URI patterns, and worked examples are set out in Annex B. No production implementation shall invent incompatible jurisdictional, document-type, language, or fragment patterns outside Annex B, except under an expressly approved national exception or subsequent profile version.

11 Metadata Profile

This Clause defines the metadata profile applicable to works, expressions, manifestations, legal events, and related publication or exchange packages represented under this Profile. Metadata under this Clause shall be recorded at the appropriate level of abstraction and shall not be collapsed into a single undifferentiated block where that would obscure legal meaning, provenance, authenticity, versioning, or publication status. The definitive field list, field names, value constraints, and cardinality rules for production use SHALL be those set out in Annex C.

11.1 Metadata Principles

Metadata under this Profile shall be governed by the principles of legality, provenance, persistence, interoperability, proportionality, machine-readability, and authority control. Metadata shall describe the legal resource in a manner sufficient to enable users and systems to determine, at minimum, what the resource is, which work and expression it belongs to, who is responsible for it, what status it holds, what language it is in, when it took effect or was published, how it relates to other legal resources, and on what authority it is being released. Metadata shall be treated as governed legal-information infrastructure and shall not rely on uncontrolled local labels, undocumented abbreviations, or ad hoc free-text practices where controlled values or authority lists have been prescribed.

11.2 Metadata Model

The metadata model under this Profile shall distinguish, at minimum, metadata relating to the Work, the Expression, the Manifestation, and the relevant legal or editorial events affecting them. Work-level metadata shall describe the abstract legal resource, including its identity, jurisdiction, document class, legal family, and persistent relations.

Expression-level metadata shall describe a particular textual realization of the work, including language, temporal state, consolidation status, translation status, and relationship to other expressions of the same work. Manifestation-level metadata shall describe a concrete file, serialization, or distribution object, including media type, publication endpoint, package membership, integrity-related attributes, and release status where required. Event metadata shall describe legally or editorially significant events such as enactment, promulgation, commencement, amendment, repeal, correction, consolidation, translation, republication, and withdrawal. Where a single metadata field is insufficient to represent a legally meaningful distinction, the distinction shall be represented explicitly rather than inferred from filenames, portal labels, or interface behavior.

11.3 Mandatory Work-Level Metadata

Every in-scope work SHALL carry, at minimum, the following mandatory work-level metadata as defined in Annex C:

• (a) persistent work identifier;
• (b) document class and instrument family;
• (c) jurisdiction;
• (d) official title and, where applicable, short title or citation title;
• (e) official number or designation where one exists;
• (f) responsible or originating authority;
• (g) core legal-status category;
• (h) citation-relevant designation; and
• (i) links to related works where such links are legally material.

11.4 Mandatory Expression-Level Metadata

Every in-scope expression SHALL carry, at minimum:

• (a) expression identifier or controlled expression designation;
• (b) parent work identifier;
• (c) expression language;
• (d) expression status, including whether the expression is as-enacted, translated, corrected, consolidated, point-in-time, draft, or otherwise controlled;
• (e) date or temporal basis sufficient to determine the textual state represented;
• (f) provenance sufficient to identify how the expression came into being; and
• (g) language-status and authority-status information under Clause 12.

11.5 Mandatory Manifestation-Level Metadata

Every publication-ready or exchange-ready manifestation SHALL carry, at minimum:

• (a) manifestation identifier or canonical publication URI;
• (b) parent work and parent expression identifiers;
• (c) media type and encoding;
• (d) publication or exchange status;
• (e) release or package date;
• (f) package or checksum reference where applicable;
• (g) authority statement or publication-basis statement where required; and
• (h) access or distribution status, including public or restricted designation where relevant. A manifestation shall not be treated as publication-ready where the mandatory metadata required for its class are absent, internally contradictory, or materially incomplete.

11.6 Mandatory Event Metadata

Where a legal or editorial event is represented, the event record SHALL identify:

• (a) event type;
• (b) affected work, expression, manifestation, or component;
• (c) responsible authority where applicable;
• (d) relevant date or date range;
• (e) source instrument or basis where applicable; and
• (f) the direction of effect, including amended-by, repealed-by, commenced-by, corrected- by, consolidated-as-of, translated-from, or equivalent relation.

11.7 Conditional Metadata

Conditional metadata become mandatory where the circumstances of the relevant work, expression, manifestation, or event require them. At minimum, conditional metadata shall include:

• (a) Bill number, House, session, or parliamentary-stage metadata for Bills and pre- enactment materials;
• (b) parent or enabling-instrument references for Rules, Regulations, Notifications, SROs, commencement instruments, and related subordinate instruments;
• (c) Gazette, issue, part, volume, notice, or publication-series references where official publication practice requires them;
• (d) commencement details where legal effect depends on staged, territorial, partial, or deferred commencement;
• (e) amendment, repeal, substitution, insertion, omission, renumbering, or correction relations where the resource changes another legal text or is itself changed by another text;
• (f) consolidation metadata where the expression is consolidated, point-in-time, editorially compiled, or otherwise not the bare as-enacted expression;
• (g) translation provenance and alignment metadata where the resource is represented in more than one language;
• (h) schedule, annex, form, or appendix descriptors where such components have independent numbering, citation significance, or operational importance; and
• (i) authenticity, seal, attestation, or certification metadata where required by the issuing or publication authority. Conditional metadata shall not be omitted merely because a portal or downstream system does not currently display them.

11.8 Optional Metadata

Optional metadata may be used where they improve discoverability, interoperability, editorial control, or downstream reuse without altering legal meaning. Optional metadata may include subject keywords, alternate titles, legacy references, explanatory labels, collection memberships, implementation notes, corpus tags, or other descriptive enrichments approved by the Profile Owner. Optional metadata shall remain subordinate to the mandatory and conditional metadata model and shall not be used to mask gaps in required metadata.

11.9 Provenance Metadata

Every profile-conformant resource shall carry provenance metadata sufficient to identify how the represented text was created, transformed, reviewed, approved, and published. For born-digital resources, provenance metadata shall identify the authoritative drafting or publication workflow, the responsible institution, and the relevant release or approval context. For legacy conversions, provenance metadata shall additionally identify the source manifestation or manifestations used for conversion, the conversion method, the date of conversion, the responsible institution or operator, and any declared limitations or unresolved uncertainties. Where a resource is derived from OCR, manual transcription, reconstruction from poor- quality sources, or mixed evidentiary sources, that fact shall be explicitly recorded.

11.10 Legal Status and Authenticity Metadata

Metadata under this Profile shall clearly distinguish the legal and publication status of a resource. At minimum, resources shall be distinguishable as authoritative text, official derivative, consolidated expression, translated expression, informational version, draft material, or other controlled status prescribed by Annex G. Authenticity-related metadata shall identify, where applicable, the authority responsible for publication, the basis on which the text is treated as authoritative or officially derived, and the date from which that status applies. A consolidated expression shall not be presented in metadata as though it were identical in status to the original as-enacted expression unless the competent authority has expressly so provided.

11.11 Versioning and Temporal Metadata

Versioning and temporal metadata shall support accurate distinction among as-enacted, amended, corrected, repealed, consolidated, and point-in-time expressions. Where an expression reflects the law as at a stated date, that as-at date shall be explicitly recorded. Where a work or expression comes into force on a date different from its enactment, promulgation, or publication date, the effective date or commencement metadata shall be recorded separately.

Where only parts of a work are commenced, amended, repealed, or corrected, the metadata model shall be capable of identifying the affected scope with sufficient precision for later resolution. A publication service shall not silently overwrite historically significant expression or manifestation metadata when a new version is issued.

11.12 Jurisdiction and Authority Metadata

Jurisdiction metadata shall be drawn from the controlled jurisdiction model established under Clause 7 and Annex G and shall not rely on uncontrolled portal labels or abbreviated textual descriptions. Authority metadata shall distinguish, where relevant, among the drafting authority, deliberative authority, adopting authority, promulgating authority, publishing authority, consolidation authority, translation authority, archival authority, and technical release authority. Where more than one authority participates in the lifecycle of the same work or expression, metadata shall preserve that distinction rather than flattening all responsibility into a single undifferentiated publisher field.

11.13 Subject Classification and Controlled Vocabularies

This Profile shall support controlled subject and domain metadata sufficient to classify legal resources by topic, sector, legal function, responsible institution, or other nationally governed taxonomy. Controlled vocabularies shall be used for document class, jurisdiction, lifecycle state, language status, authenticity status, authority role, and such additional domains as the Profile Owner designates through Annex G or controlled update. Free-text keywords may supplement controlled vocabularies for search or descriptive convenience, but they shall not replace required controlled values.

11.14 Translation and Alignment Metadata

Where a work is represented in more than one language, the metadata shall identify the source expression, the target expression, the translation status, and the provenance of the translation. Translation metadata shall record, where applicable, whether the translation is official, authoritative, certified, working, editorial, or informational. Where bilingual alignment is maintained at structural level, the metadata shall support linkage among corresponding titles, provisions, schedules, or other units across expressions.

11.15 External Metadata Mappings

The metadata profile defined by this Clause may be mapped to external discovery or interoperability models where such mapping supports lawful reuse, cataloguing, cross- jurisdictional exchange, or linked-data publication. Such mappings shall remain subordinate to the canonical legal-information model of this Profile and shall not simplify away distinctions that are legally or operationally material.

At minimum, the Profile Owner may publish controlled mappings to general descriptive vocabularies and to legal-identifier or linked-data models where useful, but no external mapping shall override or weaken the mandatory metadata requirements under this Profile.

12 Language, Script, and Bilingual Policy

This Clause defines the language, script, and bilingual-governance rules applicable to documents represented under this Profile. Language handling under this Profile shall preserve legal meaning, support authoritative publication and translation workflows, and enable stable machine processing across Urdu and English expressions.

12.1 Supported Languages

The Profile shall support, at minimum, Urdu and English for works and expressions within scope. Additional languages may be represented where lawfully required, historically necessary, or institutionally approved; however, such support shall be governed through controlled codes and shall not displace the minimum Urdu-English policy of this Profile. The mere technical ability to store multilingual text shall not be treated as compliance with this Clause unless the represented language status, provenance, and expression relations are also governed.

12.2 Official Language Policy within the Profile

This Profile does not itself determine which language expression is legally authoritative in any given case; that question shall be determined by applicable law, competent authority, and publication practice. The function of this Clause is to ensure that, whatever the legal status of a language expression, that status can be represented explicitly and managed predictably within the machine-readable environment. Where both Urdu and English expressions are maintained for the same work, their respective authority, officiality, and publication status shall be explicitly declared and shall not be left to implication.

12.3 Urdu and English as Expressions of the Same Work

Where a legal resource exists in Urdu and English as two language realizations of the same underlying instrument, the two realizations shall be modeled as distinct expressions of the same work. A difference of language alone shall not result in the creation of a different work identifier. Where one language expression is a translation of another, the relationship between source expression and target expression shall be explicitly recorded. Where the competent authority issues parallel language expressions that are both official, that parity shall be expressed in metadata and provenance rather than inferred from portal presentation.

12.4 Bilingual Titles, Headings, and Short Titles

The metadata model under this Profile shall support title, short-title, and citation-title information in Urdu and English where such information exists or is officially supplied. Within the canonical text of a given expression, headings and titles shall ordinarily appear in the language of that expression rather than as uncontrolled bilingual composites. A bilingual display label generated for user-interface convenience shall not be mistaken for the canonical text of either expression. Where a short title is legally defined in one language and rendered editorially in another, the distinction shall be made explicit in metadata or provenance.

12.5 Translation Provenance

Every translated expression represented under this Profile shall carry translation provenance sufficient to identify the translation authority, translator or responsible workflow where appropriate, source expression, translation date, and translation status. Where a translation is provisional, unofficial, machine-assisted, or otherwise not approved as an official expression, that limitation shall be explicitly declared. A publication service shall not present a translated expression in a manner likely to mislead users as to its authority or source.

12.6 Alignment Rules for Parallel Expressions

Where Urdu and English expressions of the same work are both maintained, alignment shall be preserved to the greatest extent reasonably possible at legally meaningful structural levels. At minimum, alignment should ordinarily be maintained across titles, major divisions, and citation-relevant provisions such as Articles, Sections, Rules, Regulations, and Schedules where corresponding structures exist. Stable identifiers and anchors shall be used so that equivalent or corresponding provisions can be linked across language expressions. Where a precise one-to-one alignment is not possible because of drafting divergence, translation compression, structural expansion, or historical irregularity, the divergence shall be documented rather than hidden.

12.7 Right-to-Left and Left-to-Right Rendering Requirements

Urdu expressions shall be stored and processed in logical character order and shall not rely on visual-order storage or presentation-layer workarounds. Rendering environments shall support right-to-left script behavior, Unicode shaping, bidirectional text handling, punctuation positioning, and mixed-script display sufficient for legally intelligible publication. English expressions shall be rendered left-to-right in accordance with ordinary standards for English legal text publication. Where a single publication interface presents Urdu and English side by side or within the same navigational view, the interface shall preserve the integrity of each expression and shall not introduce false character-ordering or citation ambiguity. Renderer or portal limitations shall not justify alteration of the canonical underlying text.

12.8 Language Tags and Representation Rules

Language and script values SHALL be represented using controlled tags designated by the Profile Owner and aligned, to the greatest extent reasonably practicable, with BCP 47 language-tagging practice. The same language SHALL NOT be represented through multiple inconsistent codes or labels across manifestations or services. Where script distinction is relevant, such distinction shall be represented explicitly through the controlled tagging approach adopted by the Profile Owner. Language metadata shall identify the language of the expression itself, and shall not be misused to describe the interface language of a portal, API, or rendering template.

12.9 Friendly URL Aliases and Canonical Language Tokens

Publication services may expose language-friendly URL aliases or path tokens for user convenience, including short language tokens for Urdu and English. Such friendly aliases shall remain subordinate to the canonical identifier policy established under Clause 10 and Annex B. Language tokens in resolvable URLs shall indicate expression language and shall not create the false appearance of separate works where the underlying work is the same. Where both canonical and friendly URLs are supported, resolver behavior shall preserve stable citation and predictable redirection.

13 Common Structural Rules

This Clause establishes the common structural rules applicable across document classes under this Profile. The purpose of these rules is to ensure that legal texts are represented through explicit, semantically meaningful structure rather than through formatting conventions alone. Where a document class requires specialized rules beyond the common structure defined here, those specialized rules shall be applied in conjunction with this Clause and not in substitution for it.

13.1 Front Matter

Front matter shall contain the identifying and introductory matter that precedes the operative provisions of the legal text. Front matter may include, as applicable, titles, short titles, citation labels, numbers, year designations, promulgation or enactment formulas, authority statements, prefaces, publication notices, and other institutionally required introductory material. Front matter shall be structurally distinguished from the operative body of the legal instrument and shall not be flattened into undifferentiated text blocks.

13.2 Preamble / Recitals

Where a legal instrument contains a preamble, recital sequence, statement of objects, or comparable prefatory legal text, that material shall be represented as a distinct structural component.

Preambles and recitals shall not be merged into the main body merely because they appear on the same page in print or PDF manifestation. Where a document class does not use preambles or recitals as a standard feature, the absence of such a component shall not be artificially simulated.

13.3 Main Body

The operative provisions of the legal text shall be represented within the main body of the document. The main body shall preserve the authoritative hierarchy of provisions and shall not rely solely on typography, indentation, or line breaks to express legal structure. Where the source text contains an irregular or shallow hierarchy, the markup shall remain faithful to the source and shall not invent additional levels merely for symmetry.

13.4 Divisions of Text

Divisions of text shall be represented according to the legally meaningful hierarchy used in the source instrument. Where the source instrument employs Parts, Chapters, Articles, Sections, Rules, Regulations, Subsections, Clauses, Provisos, Explanations, Schedules, or similar components, the markup shall preserve those distinctions through explicit structural representation. Numbering styles, including Arabic numerals, Roman numerals, alphabetical labels, bracketed forms, or mixed patterns, shall be preserved as authoritative textual features unless a controlled editorial rule provides otherwise.

13.4.1 Parts

Parts shall be used where the source instrument organizes major thematic or legal divisions at that level. A Part identifier shall remain stable for citation and amendment purposes even where later provisions are inserted, omitted, or renumbered around it.

13.4.2 Chapters

Chapters shall be represented where the source instrument uses them as an intermediate or major structural division. A Chapter shall not be downgraded to mere heading text where it has citation, amendment, or organizational significance.

13.4.3 Articles

Articles shall be represented explicitly where the source instrument uses article-based drafting, including the Constitution and any other relevant instruments. Article identifiers shall support stable fragment citation and cross-reference handling.

13.4.4 Sections

Sections shall be represented explicitly where the source instrument uses section-based drafting. Inserted or substituted Sections shall preserve citation continuity and relation to prior numbering through the identifier policy established under Clause 10.

13.4.5 Subsections and Clauses

Subsections, Clauses, sub-clauses, paragraphs, subparagraphs, and similar nested units shall be represented at the depth required to preserve legal meaning, citation integrity, and amendment granularity. Where the source uses mixed drafting patterns, including bracketed letters, nested numerals, provisos, or explanations, the structural representation shall preserve their legal role and hierarchical position.

13.5 Definitions

Definitions shall be represented within the structural context in which they operate. Where a document contains a dedicated definitions or interpretation unit, that unit shall be represented as such. Where defined terms occur in multiple decentralized provisions rather than in a single definitions clause, the markup shall preserve the source structure while enabling later indexing or semantic treatment through controlled metadata or annotation layers.

13.6 Schedules and Annexes

Schedules, annexes, appendices, attachments, or similarly structured supplementary materials shall be represented as distinct structural components of the legal resource where they form part of the instrument. Where a Schedule or annex has independent numbering, headings, tables, forms, or internal divisions, that internal structure shall be preserved. A Schedule shall not be reduced to an opaque attachment image or unstructured text block where structured representation is reasonably achievable. Where supplementary material is merely associated publication matter and not part of the legal instrument, that distinction shall be made explicit.

13.7 Forms and Tables

Forms, prescribed templates, rate tables, fee schedules, lists, and comparable structured content shall be represented in a manner sufficient to preserve their legal and operational meaning. Tables shall, where reasonably possible, be represented as structured tables rather than flattened lines of text or raster images. Where a prescribed form depends materially on layout, the canonical representation shall preserve the legal content and structure of the form, while rendering guidance or controlled presentation rules may supplement it for faithful human-readable output. A manifestation may include a print-optimized form rendition, but the presence of such a rendition shall not excuse failure to preserve the underlying machine-readable structure.

13.8 Footnotes, Marginal Notes, and Headnotes

Footnotes, marginal notes, headnotes, notes added by the publication authority, and similar auxiliary text shall be represented in a way that preserves their provenance and legal status. Where such material is part of the authoritative source, that status shall be reflected accordingly.

Where such material is editorial or publication-added, it shall be distinguishable from operative legal text. Marginal notes and headnotes shall not be silently promoted to operative provisions, nor shall operative provisions be demoted to notes because of typographic placement in legacy sources.

13.9 Signatures, Authentication Blocks, and End Matter

Signature lines, attestation blocks, seals, certification text, ministerial endorsements, publication notes, and comparable end matter shall be represented where relevant to authenticity, provenance, or documentary completeness. The absence of a handwritten or image-based signature within a machine-readable manifestation shall not by itself imply lack of authenticity where the competent publication process provides another lawful authenticity mechanism. Where end matter includes Gazette references, issuing-office certifications, or other authority cues, those cues should be represented in structured form to the greatest extent reasonably possible.

14 Document-Type Specific Structural Rules

This Clause establishes the additional structural rules applicable to specific document classes within scope. These rules shall be read together with the common structural rules in Clause 13, the domain model in Clause 7, the identifier rules in Clause 10, the metadata rules in Clause 11, and the minimum structural templates in Annex D. Where a particular document instance presents a structural anomaly not expressly addressed in this Clause or Annex D, the implementation shall preserve the source faithfully and record the anomaly through controlled editorial or provenance mechanisms rather than inventing non-source structure.

14.1 Constitution

The Constitution of Pakistan shall be represented with particular care to preserve its Article- based hierarchy, Parts, Chapters, and Schedules, together with amendment-sensitive citation anchors. A profile-conformant constitutional expression SHALL, at minimum, preserve:

• (a) the title matter and citation matter;
• (b) Parts, Chapters, Articles, clauses, provisos, explanations, and Schedules where present;
• (c) the distinction between the constitutional work and each amending Act affecting it; and
• (d) the basis and date of any controlled consolidated constitutional expression. Constitutional Articles, clauses, provisos, explanations, and Schedules shall carry stable identifiers sufficient to support durable citation, amendment modeling, and bilingual alignment where applicable.

14.2 Acts

Federal Acts and other Acts within scope shall ordinarily include, where applicable, title matter, long title, short title, enacting formula, commencement provisions, definitions, operative provisions, and schedules or appendices. A profile-conformant Act SHALL preserve, at minimum:

• (a) Act number and year where applicable;
• (b) title and citation elements;
• (c) section-based hierarchy and nested subordinate provisions;
• (d) amendment language where the Act is amending in nature; and
• (e) schedules, appendices, forms, or tables where they form part of the instrument. Where an Act amends another Act, the amending Act shall be represented as a distinct work linked by explicit legal relations to the affected work or provisions.

14.3 Ordinances

Ordinances shall be represented as distinct works with explicit promulgation and status metadata appropriate to their constitutional and temporal nature. A profile-conformant Ordinance SHALL preserve, at minimum:

• (a) title matter and issuing-authority matter;
• (b) promulgation metadata;
• (c) operative provisions structured to the depth used in the source;
• (d) lapse, repeal, replacement, or conversion relationships where they arise; and
• (e) schedules, appendices, or attached forms where present. An Ordinance shall not be modeled merely as a transient publication notice if it contains operative provisions of continuing legal significance.

14.4 Bills

Bills shall be represented as pre-enactment legislative works or work states with stage- sensitive metadata and structure. Bill metadata SHALL include, where available and applicable:

• (a) Bill number;
• (b) House;
• (c) legislative session;
• (d) introduction date;
• (e) stage;
• (f) sponsor or introducing authority; and
• (g) passage status. The structure of a Bill shall preserve clause-based or section-based drafting as used in the source, together with schedules, statements of objects and reasons, financial memoranda, or explanatory materials where these form part of the official legislative package. A Bill shall not be represented as though it were an enacted Act merely because its text resembles the eventual enacted form.

14.5 Rules

Rules shall be represented as subordinate legal instruments linked explicitly to the enabling Act, Ordinance, constitutional authority, or other parent legal basis under which they are made. A profile-conformant Rules expression SHALL preserve:

• (a) the enabling-instrument relation;
• (b) rule number and year where applicable;
• (c) the rule-making authority;
• (d) rule-based hierarchy, including sub-rules, clauses, provisos, forms, and schedules; and
• (e) commencement and publication metadata where relevant.

14.6 Regulations

Regulations shall be represented as subordinate legal instruments linked to their enabling legal basis and issuing authority. Where the legal system distinguishes Regulations from Rules in authority, scope, or drafting form, that distinction shall be preserved in document class and metadata, even where the structural pattern is similar. Regulations may contain internal Parts, Chapters, Regulations, clauses, schedules, forms, tariffs, or technical appendices, and such structure shall be represented explicitly.

14.7 Notifications and Statutory Regulatory Orders (SROs)

Notifications and SROs within scope shall be represented through a constrained but structured instrument model appropriate to executive or subordinate legal publication. Such instruments SHALL, at minimum, preserve:

• (a) the issuing authority;
• (b) the instrument number or designation;
• (c) the date;
• (d) the legal basis;
• (e) the subject line or title where present;
• (f) the operative text; and
• (g) any schedules, tables, forms, or annexes they contain. Where a Notification or SRO amends rates, inserts schedules, grants exemptions, appoints dates, designates authorities, or alters the operation of another legal text, those legal relations should be represented explicitly.

14.8 Gazette Notices and Commencement Orders

Gazette notices and comparable publication instruments shall be represented in a manner that preserves their publication identity and their legal relation to the underlying work or event they announce. Where a Gazette notice is itself the legally operative instrument, it shall be represented as a work or expression in its own right. Where a Gazette notice merely publishes, republishes, commences, corrects, or gives notice concerning another instrument, the relation to that underlying instrument shall be explicit.

Commencement orders or notifications shall identify the commenced work, and, where applicable, the specific provisions or territorial scope to which commencement applies, together with the effective date or dates.

14.9 Corrigenda and Amendment Instruments

Corrigenda, errata, correction notices, and comparable instruments shall be represented in a manner that makes the target of correction explicit. A correction instrument SHALL identify, to the greatest extent reasonably possible, the affected work, expression, manifestation, and structural location or locations to which the correction applies. Where a correction is merely editorial to a published manifestation, that distinction shall be preserved. Where a correction has legal effect because it is issued through a competent legal process, that legal status shall be represented explicitly in metadata and event relations. Amendment instruments shall preserve the amending text as its own work or expression and shall, where possible, support structural linkage to the affected provisions of the target text.

14.10 Annex D as Operational Baseline

The minimum structural templates, component requirements, and admissible mandatory element patterns for each in-scope document class SHALL be those set out in Annex D. No implementation shall claim document-type conformance while materially departing from Annex D, except under a formally approved national exception or subsequent profile version.

15 Editorial and Textual Policy

This Clause defines the editorial and textual-discipline rules applicable to the creation, conversion, maintenance, and publication of resources under this Profile. The aim of this Clause is to preserve fidelity to authoritative legal text while permitting the controlled editorial handling necessary for structured publication, conversion from legacy sources, bilingual management, and consolidation.

15.1 Authoritative Text vs Editorial Enhancement

The authoritative legal text shall remain primary under this Profile. Editorial enhancement may be applied only to the extent necessary to support structure, metadata, discoverability, rendering, validation, accessibility, or controlled user comprehension, and shall not silently alter legal meaning. Editorial additions, including explanatory notes, editorial headings, convenience labels, parallel citations, legacy-source caveats, or consolidation notes, shall be distinguishable from the authoritative text. No editorial process shall present a corrected, normalized, translated, or consolidated expression as though it were the original authoritative enacted expression unless that status has been lawfully established.

15.2 Text Normalization Rules

Text normalization under this Profile shall be conservative and governed.

Permissible normalization may include correction of encoding defects, normalization of line- break artifacts arising from page-based sources, regularization of whitespace where it carries no legal significance, and repair of purely technical corruption introduced during digitization or transformation. Normalization shall not silently alter wording, numbering, punctuation carrying possible legal significance, defined terms, dates, monetary values, cross-references, citations, or the hierarchical structure of provisions. Where uncertainty exists as to whether a normalization would affect legal meaning, the source reading shall be preserved unless and until a competent editorial or legal decision authorizes correction.

15.3 OCR and Source-Cleanup Policy

Where legacy text is derived from OCR, scanned images, or poor-quality source files, the resulting text shall not be treated as authoritative merely because it has been converted into structured form. OCR-derived content shall be subject to controlled review, verification, and correction before profile-conformant publication as authoritative or official derivative text. Unresolved OCR uncertainty shall be explicitly flagged through provenance or editorial mechanisms rather than guessed or silently cleaned up. For high-value or high-risk legal texts, the implementing institution should preserve the source image or source manifestation as evidence supporting later review. Automated cleanup tools may assist conversion, but responsibility for the released text remains with the competent institution.

15.4 Punctuation, Typography, and Formatting Normalization

Typography and formatting features that are purely presentational may be regularized for machine-readable consistency or rendering quality, provided that legal meaning is not altered. Examples of such regularization may include removal of artificial line wrapping, harmonization of duplicate spaces, normalization of non-substantive indentation artifacts, or standardization of technically inconsistent quotation marks or dash characters introduced by conversion tools. Presentational normalization shall not be used to erase meaningful source distinctions such as numbered paragraphs, provisos, formulaic punctuation, quoted amendment language, tabular relationships, or bilingual script integrity. Where the source uses unusual formatting with possible interpretive significance, that formatting or its significance shall be preserved or explicitly documented.

15.5 Error Handling and Correction Policy

Apparent errors in a source manifestation shall be handled according to their nature. Where the issue is a technical conversion defect, it may be corrected within the controlled editorial workflow, provided the correction is traceable and does not pretend to be a legal amendment.

Where the issue appears to originate in the source publication itself, the implementing institution shall not silently fix the legal text unless a competent correction, corrigendum, republication, or other lawful basis exists. Where an error is suspected but not resolved, the text should be preserved as found and accompanied by an editorial or provenance note where appropriate. Error handling shall distinguish clearly among legal correction, editorial clarification, technical remediation, and unresolved uncertainty.

15.6 Change Logs

Profile-conformant publication and maintenance workflows shall maintain change logs sufficient to distinguish:

• (a) legal changes to the work or expression;
• (b) editorial changes arising from conversion, cleanup, or normalization;
• (c) metadata changes;
• (d) packaging or manifestation changes; and
• (e) corrections arising from validation or QA. Change logs shall identify, to the extent appropriate, what was changed, when, by whom or by which responsible workflow, and on what basis. A mere replacement file without retained change history shall not be treated as adequate lifecycle governance for authoritative legal publication.

15.7 Consolidation Editorial Rules

Consolidation under this Profile shall be governed as a distinct editorial and legal-information process. A consolidated expression may incorporate amendments, repeals, substitutions, insertions, omissions, commencement effects, renumberings, and corrigenda only through a controlled workflow capable of explaining the resulting state of the text. The consolidated expression shall state, through metadata and where appropriate through human-readable notes, the as-at date and the basis on which consolidation has been performed. Where ambiguity exists in the amendment history, commencement history, or source evidence, the consolidation workflow shall record that ambiguity explicitly. A consolidated expression shall not erase the independent identity or historical accessibility of the underlying as-enacted and amending instruments.

15.8 Historical Version Handling

Historical expressions and manifestations of legal texts shall be preserved in a manner that supports later citation, audit, legal research, and authenticity review. Superseded, repealed, corrected, withdrawn, or otherwise outdated expressions shall remain distinguishable and, where appropriate, retrievable. No historical version of a work or expression shall be destructively overwritten merely because a more recent consolidated or corrected expression becomes available. Where legacy manifestations are retained for evidentiary or archival reasons, their relationship to later structured manifestations shall be explicit in metadata or provenance.

16 Extensibility and Proprietary Content

This Clause defines the conditions under which profile-conformant documents, packages, repositories, and services may carry locally specific data beyond the common national baseline. The purpose of this Clause is to permit strictly governed extensibility without allowing uncontrolled divergence from Akoma Ntoso, from this Profile, or from national interoperability requirements. In Pakistan's implementation context, extensions may be necessary for workflow continuity, bilingual management, repository integration, auditability, and publication operations. Such need, however, shall not be used as a justification for creating institution-specific dialects that frustrate exchange, validation, portability, or future national consolidation.

16.1 General Extension Principles

Extensions under this Profile shall be exceptional, explicit, minimal, and documented. No implementing institution shall introduce local markup, metadata, attributes, namespaces, or packaging conventions merely for convenience where the required meaning can be represented through the base standard or through this Profile. An extension shall be permitted only where the business need is real and documentable, the need is not already adequately addressed by the base standard or this Profile, the extension does not undermine core interoperability or validation, and the extension can be governed through stable documentation, version control, and controlled deprecation if required. For the avoidance of doubt, extensions shall supplement, and shall not replace, mandatory profile semantics. A local extension shall not be used to avoid work, expression, manifestation, metadata, identifier, language, structural, or publication obligations established elsewhere in this Profile.

16.2 Use of Proprietary Containers

Where Akoma Ntoso proprietary containers or equivalent extension mechanisms are used, they shall be used in a disciplined manner and only for content that is truly outside the common national semantic core. Proprietary containers shall not be used to store text that ought properly to be represented as normative legal content, structural components, or prescribed profile metadata. They shall be used only for controlled ancillary data whose omission would not alter the legal meaning of the represented instrument. Any use of proprietary containers in a publicly released manifestation shall be declared in metadata, tied to a governed namespace or schema where applicable, and accompanied by documentation sufficient to permit informed processing, validation, or safe ignoring by downstream systems.

16.3 Permitted Extension Categories

Extensions under this Profile may be permitted in the following controlled categories, subject to governance and validation: editorial metadata; workflow metadata; system integration keys; audit and processing metadata; controlled semantic links to external authority lists; and such additional categories as may later be approved by the Profile Owner. No institution shall invent new extension categories in an uncontrolled manner while continuing to claim profile conformance. Where a recurring local extension category proves

necessary across more than one implementing institution, that category should be considered for elevation into a future normative annex, code list, or profile version.

16.4 Editorial Metadata

Editorial metadata may be carried as an extension where it records information relevant to editorial preparation, source tracing, normalization decisions, unresolved issues, internal preparation notes, or consolidation reasoning that is not intended to form part of the public legal text. Editorial metadata shall be clearly separable from authoritative legal content. It shall not be rendered as if it were part of the enacted or official text unless the rendering context expressly identifies it as editorial commentary, notice, or provenance information. Where editorial metadata materially influences consolidation, correction, publication, or bilingual alignment, that metadata shall be preserved in a traceable manner and shall not be left only in transient authoring environments or staff-specific notes.

16.5 Workflow Metadata

Workflow metadata may be used to support drafting, review, validation, approval, publication, translation, and archival operations. Typical examples include workflow state, task assignment references, release tickets, internal routing marks, validation batch identifiers, or production-stage timestamps. Workflow metadata shall not leak uncontrolled into public manifestations where it would expose internal administrative information, create interpretive confusion, or undermine trust in the published resource. Public release pipelines shall distinguish between workflow metadata that is operationally internal and metadata that is intentionally releasable as provenance or publication information. Where workflow metadata is required to survive transfer between institutions, it should be expressed through a stable exchange profile rather than through undocumented private conventions.

16.6 System Integration Keys

System integration keys may be used to link a profile-conformant resource to external repositories, case-management systems, drafting environments, gazette systems, archives, catalogue services, resolver registries, or other operational platforms. Integration keys shall be treated as auxiliary technical identifiers and shall not displace the persistent legal identifiers established under Clause 10. They shall not be exposed to users as if they were stable legal citations unless they have separately been adopted as governed public identifiers. Where system integration keys are exchanged outside the originating institution, their semantics, cardinality, mutability, and lifecycle shall be documented. Keys that are unstable, environment-specific, or vendor-specific should not be relied upon as long-term inter- institution references.

16.7 Audit and Processing Metadata

Audit and processing metadata may be used to record transformation lineage, validation outcomes, processing timestamps, operator roles, import events, export events, checksum calculations, packaging actions, publication runs, or other machine-process evidence.

Such metadata shall be trustworthy, tamper-evident where required, and attributable to the system or role that produced it. It shall be sufficiently precise to support later technical review, accountability, and preservation of the publication or exchange chain. Where audit and processing metadata is retained outside the AKN document itself, the relationship between the external audit record and the affected manifestation or package shall remain explicit and resolvable.

16.8 Namespace Governance

Every extension that uses namespaced content shall be bound to a controlled namespace policy. The namespace used shall be stable, documented, and attributable to a responsible governance authority. An implementing institution shall not use transient, ambiguous, or unpublished namespaces for production content. Namespace documentation shall state the owner, intended scope, validation expectations, compatibility assumptions, and deprecation approach. Where national reuse is anticipated, the Profile Owner may reserve or designate namespaces for Pakistan-wide use so that extensions with recurring public value can be governed consistently across institutions.

16.9 Validation of Extensions

Any extension used in production shall be subject to validation proportionate to its operational importance. At minimum, the extension shall be syntactically valid, namespace- consistent, and non-conflicting with mandatory base or profile elements. Where an extension affects publication, exchange, resolver behavior, archival treatment, validation outcomes, or public rendering, rule-based validation should be applied in addition to structural validation. No institution shall rely on manual interpretation alone for extensions that materially affect interoperability or release readiness. The absence of a full validator for an extension shall not excuse non-governed production use. In such cases, the extension should either be constrained to non-public internal use or delayed until proper validation support is established.

16.10 Restrictions on Over-Customization

Over-customization is prohibited under this Profile. A document, package, or service shall be treated as non-conformant where local extensions alter the common meaning of core structures, replace prescribed identifiers or metadata, redefine citation anchors, change mandatory publication behavior, or otherwise create a materially incompatible local dialect. Institutions shall prefer common national solutions over bespoke customizations. Where a local requirement appears genuine but potentially generalizable, the correct path is to raise a governed change request rather than to embed a unilateral long-term customization in production workflows. In Pakistan's implementation context, this prohibition is especially important because the Profile is intended to support eventual federal and provincial interoperability, repository portability, and supplier neutrality. Avoidable customization today becomes fragmentation tomorrow.

17 Validation and Quality Assurance

This Clause establishes the minimum validation and quality-assurance regime for documents, packages, services, and publication workflows operating under this Profile. Validation under this Profile shall not be understood as schema checking alone. A resource may be structurally valid yet still be unfit for publication, exchange, citation, consolidation, or preservation. Accordingly, validation and quality assurance under this Clause shall combine structural, rule-based, editorial, packaging, resolver, API, and release controls.

17.1 Validation Architecture

The national validation architecture SHALL be layered. At minimum, it shall distinguish:

• (a) structural validation against the relevant schema;
• (b) rule validation against profile-specific and document-class-specific constraints;
• (c) business-rule validation for identifiers, metadata, packaging, and publication behavior;
• (d) package and integrity validation where applicable;
• (e) resolver or API behavior validation where the relevant services are claimed; and
• (f) editorial review for text quality, source fidelity, and release readiness. Validation architecture may be implemented centrally, institutionally, or through a hybrid model, but the resulting control evidence shall be sufficiently comparable to support national conformance assessment.

17.2 Schema Validation

Every machine-readable manifestation claiming profile conformance shall pass schema validation against the adopted Akoma Ntoso schema set and any profile-governed schema constraints formally designated for the relevant document class. Schema validation shall confirm that the document is structurally admissible, namespace- consistent, properly encoded, and free from syntax-level defects that would make exchange or downstream processing unreliable. Schema validity shall be treated as a necessary but not sufficient condition for release.

17.3 Rule Validation

Rule-based validation SHALL be used to test profile constraints that cannot reliably be captured through base schema mechanisms alone. Such rules shall include, at minimum:

• (a) identifier grammar and uniqueness checks;
• (b) mandatory metadata presence and cardinality checks;
• (c) language-policy and bilingual-alignment checks where applicable;
• (d) structural restrictions by document class;
• (e) title, citation, status, and authority requirements;
• (f) package and manifest consistency checks where applicable; and
• (g) publication, resolver, or API behavior checks where applicable. The baseline national rule set shall be the rule set defined in Annex E.

17.4 Business Rules

Business rules under this Profile shall cover matters such as identifier uniqueness, expression-to-work linkage, manifestation naming, resolver readiness, package completeness, checksum presence where required, release labeling, and consistency between metadata and rendered outputs. Business rules may also govern Pakistan-specific matters such as bilingual alignment completeness, issuing-authority code consistency, jurisdiction labeling, gazette linkage, commencement-note presence, consolidation basis statements, or the relationship between authoritative and derivative outputs. Business rules shall be maintainable, auditable, and appropriately testable. They shall be expressed in a form that can be applied consistently across institutions rather than relying on undocumented portal-specific assumptions.

17.5 Editorial QA Checklist

Every publication or exchange workflow shall include an editorial quality-assurance checklist proportionate to the document class and publication significance. At minimum, editorial QA shall address fidelity to the source; correct representation of titles, headings, numbers, dates, provisos, schedules, forms, tables, footnotes, and signatures where relevant; consistency of cross-references; correctness of language labels; adequacy of corrigenda handling; and the clarity of any editorial, consolidation, or translation notices. For legacy conversion, editorial QA shall additionally address OCR defects, line-break normalization, omitted characters, merged paragraphs, table reconstruction, page-header contamination, and other source-cleanup risks that are common when converting PDF- centric legal materials into structured form.

17.6 Regression Testing

Where automated transformation, rendering, packaging, or publication pipelines are used, regression testing SHALL be performed before major release changes enter production. Regression testing shall include representative fixtures across document classes, language forms, amendment patterns, schedules, tables, and packaging scenarios so that previously correct behavior is not broken by new code, rule, stylesheet, resolver configuration, or API change.

17.7 Release Gates

Production release under this Profile shall be controlled through defined release gates. At minimum, release gates SHALL verify that:

• (a) structural validation has passed;
• (b) applicable rule validation has passed or been formally excepted;
• (c) editorial QA has been completed;
• (d) publication metadata is complete;
• (e) package or endpoint behavior has been confirmed where applicable; and
• (f) release authorization has been recorded. Higher-impact releases, including first publication of a major corpus, publication of the Constitution, wide-scale consolidation updates, or cross-institution exchange bundles, should be subject to enhanced release approval and retained evidence of the decision basis.

17.8 Conformance Test Fixtures

The Profile Owner shall maintain, or coordinate, conformance test fixtures sufficient to support repeatable implementation and testing. Such fixtures shall cover positive and negative examples, document-class variations, language variants, identifier examples, package examples, and edge cases relevant to Pakistan's legal corpus. Fixtures shall be treated as implementation aids and conformance evidence instruments. They shall be versioned and aligned to the relevant profile version so that institutions and vendors can test against a common reference set.

17.9 Non-Conformance Reporting

Non-conformance shall be recorded and classified in a controlled manner. Reports shall distinguish, at minimum, structural defects, rule failures, editorial defects, packaging defects, resolver defects, API defects, and release-process defects. Each non-conformance record shall identify the affected resource, the failed requirement or test, the severity, the proposed remediation, and the final disposition. Suppressed, waived, or deferred issues shall be visible rather than hidden. Persistent or recurring non-conformities across institutions should be treated not merely as local defects but as signals for possible profile clarification, guidance enhancement, fixture improvement, or controlled update.

18 Packaging and Exchange Rules

This Clause establishes the minimum requirements for packaging profile-conformant resources for transfer, publication, validation, archival deposit, and inter-institution exchange. A package under this Profile shall be more than an arbitrary collection of files: it shall be a governed unit whose internal structure, naming, metadata, and integrity artifacts permit reliable consumption by another compliant party. The definitive national packaging and exchange baseline SHALL be the baseline set out in Annex F.

18.1 Canonical File and Package Structure

The Profile Owner shall prescribe, through Annex F and controlled implementation notices, the canonical file and package structure for profile-conformant exchange and bulk distribution. At minimum, a compliant package structure SHALL distinguish:

• (a) the principal AKN manifestation;
• (b) associated derivative outputs where included;
• (c) metadata files;
• (d) package manifests;
• (e) integrity artifacts; and
• (f) ancillary media or referenced components. Internal paths and file naming shall be stable enough to support automated import, validation, and archival preservation.

18.2 Component and Media Handling

Where a work or manifestation includes schedules, appendices, tables, forms, images, seals, or other associated media, the package shall preserve the relationship between the principal XML manifestation and those additional components. Associated media shall be named and linked in a predictable manner. Media references shall not be left dependent on workstation-specific absolute paths, broken relative paths, or externally mutable transient URLs. Where an image, scan, facsimile page, or evidentiary attachment forms part of the release basis, its role shall be explicit so that downstream systems can distinguish between authoritative text, source evidence, and convenience media.

18.3 Manifestation Packaging Rules

A package may carry one manifestation or multiple related manifestations of the same expression, provided their relationship is explicit. Where multiple manifestations are bundled, the package shall identify which manifestation is canonical for machine-readable purposes and which are official derivatives, informational derivatives, or supplementary materials. No package shall imply that all contained files have equal authority merely because they are co-distributed. Authority status shall be expressed explicitly through metadata and package documentation.

18.4 Checksums and Integrity Artifacts

Where integrity assurance is required, packages shall include checksum artifacts sufficient to verify that the contained files have not changed since package creation. SHA-256 or a stronger nationally approved hash algorithm should be used unless superseded by later guidance. Checksum manifests shall be machine-readable, attributable to the package-generation event, and stored in a manner that permits later validation without ambiguity over file paths or algorithm choice. For high-value exchanges, checksum artifacts should be accompanied by package identifiers, generation timestamps, and operator or system provenance so that integrity verification is linked to a traceable release event.

18.5 Digital Signature and Seal Options

This Profile permits the use of digital signatures, electronic seals, or equivalent trust controls where required by law, governance policy, or operational assurance needs. Where such assurance is required, the signing or sealing method, coverage scope, and verification expectations shall be explicit and interoperable with the applicable national trust framework. An institution shall not rely on proprietary signing behaviors that make later verification unduly tool-dependent.

18.6 Exchange Bundles for Inter-Institution Transfer

Where resources are transferred between drafting offices, publication authorities, repositories, archives, or other competent institutions, exchange bundles shall follow the controlled national profile in Annex F rather than local email-style attachment practices.

An exchange bundle should include, as applicable, the principal XML manifestation, required metadata, integrity artifacts, validation results, release notes or transfer notes, dependency references, and any controlled supplementary materials required by the receiving institution. Receiving institutions shall not be expected to infer hidden workflow assumptions from the package. Exchange bundles shall therefore be self-describing to the extent necessary for safe ingestion and validation.

18.7 Import and Export Rules

Import and export under this Profile shall be governed operations. Systems claiming conformance shall be capable of exporting profile-conformant resources without silent data loss and of importing such resources without uncontrolled mutation of identifiers, structure, metadata, or language state. Where an import process necessarily enriches, maps, or normalizes incoming material, the result shall preserve traceability to the received package and shall record any material transformation or rejection. Export functions should support reproducible output so that repeated export of the same approved manifestation under the same profile version does not produce unexplained semantic drift.

19 Publication and Distribution Rules

This Clause establishes the rules governing public and restricted publication of profile- conformant legal resources. The central principle of this Clause is that Pakistan’s machine-readable law ecosystem shall treat the structured AKN manifestation as the canonical machine-readable publication object, while also permitting controlled derivative outputs and access channels suitable for human use, API reuse, bulk distribution, and archival preservation. The definitive national baseline for endpoints, package behavior, and distribution profiles SHALL be the baseline set out in Annex F.

19.1 Canonical Machine-Readable Publication Format

The canonical machine-readable publication format under this Profile SHALL be Akoma Ntoso XML conformant to the adopted base standard and to this Pakistan Application Profile. A resource shall not be treated as machine-readably published merely because a human- readable PDF, image scan, or web page exists. Profile-conformant machine-readable publication requires a controlled XML manifestation with stable identifiers, governed metadata, and publication behavior consistent with this Clause. Where a human-facing service offers multiple formats, the XML manifestation shall remain the canonical source for downstream machine processing, citation anchoring, structured reuse, and future transformation.

19.2 Human-Readable Publication Outputs

Human-readable publication outputs are permitted and, in practice, will often be necessary for legal access, accessibility, printability, and public communication. Such outputs may include HTML, PDF, and print-ready variants.

Human-readable outputs shall, however, be generated and governed as derivative manifestations of a controlled source rather than being independently edited in ways that sever their traceability to the canonical resource. Where human-readable outputs display editorial notices, authenticity notices, bilingual notices, or consolidation notices, such notices shall be consistent with the underlying metadata and release status of the source manifestation.

19.3 HTML

HTML publication is strongly recommended as the principal human-readable online presentation format for profile-conformant resources. HTML renderings should preserve citation anchors, stable fragment addressing, language directionality, structural hierarchy, schedules, tables, notes, and cross-references in a manner that is both human-usable and machine-linkable. Where HTML is generated from the canonical XML manifestation, the rendering pipeline shall be sufficiently controlled to avoid loss of legally significant distinctions such as amendment notes, commencement notices, bilingual correspondence, or schedule boundaries.

19.4 PDF

PDF publication may be used as an official derivative or convenience format, including for download, printing, archival access, or compatibility with existing administrative practices. A PDF derivative shall not displace the canonical XML manifestation for machine-readable purposes. It shall be clearly associated with the relevant work, expression, and manifestation identifiers, and it should carry visible citation, version, date, and status information sufficient to reduce ambiguity in offline circulation. Where a PDF is derived from legacy source evidence rather than from the canonical XML manifestation, that fact shall be recorded so that users do not assume a structured-origin derivative where none exists.

19.5 Print-Ready Variants

Print-ready variants may be published where required for gazette workflows, court bundles, parliamentary proceedings, certified extracts, or archival print reproduction. Such variants shall be governed as manifestations with explicit production status. They should preserve page-level integrity and display conventions appropriate to their official purpose, but they shall not introduce hidden textual divergence from the approved source. Where print pagination has citation significance in a legacy context, the relationship between print-ready pagination and canonical structural citation shall be documented and, where feasible, machine-linked.

19.6 API Publication Profile

The publication ecosystem under this Profile SHOULD include a governed API profile for retrieval, listing, filtering, resolver-assisted access, and metadata access for profile- conformant resources. The national API baseline SHALL support, at minimum:

• (a) retrieval by work identifier, expression identifier, or canonical publication URI;
• (b) retrieval of canonical XML manifestations;
• (c) retrieval of manifestation metadata independent of full document payload where useful;
• (d) filtering by document class, jurisdiction, language, date, and status where the corpus supports it; and
• (e) controlled versioning and deprecation behavior. API responses shall not invent alternative identity or status semantics inconsistent with the canonical publication record. Where JSON or other convenience serializations are provided, their relationship to the canonical XML resource shall be explicit and stable.

19.7 Bulk Distribution Profile

Bulk distribution SHALL be supported for corpora, collections, updates, or institutional transfer scenarios where one-by-one retrieval is impractical or insufficient. Bulk distributions should be versioned, documented, and partitioned in a way that permits controlled refresh, integrity verification, and selective re-ingestion. They should also preserve sufficient metadata and package structure so that the distributed corpus remains usable outside the originating platform. Where daily, weekly, periodic, or event-based bulk updates are provided, the update policy shall be transparent so that downstream users can distinguish between full refreshes, incremental deltas, and point-in-time corpus snapshots.

19.8 Media Types and Serialization Rules

Published resources shall use correct media types and serialization behavior. Akoma Ntoso XML manifestations should be served using the applicable AKN media type or another nationally approved interoperable media-type profile consistent with the base standard. Character encoding shall be explicit and interoperable. UTF-8 should be used unless a later nationally approved profile provides otherwise. No publication system shall silently serve structurally governed XML as an opaque binary download without appropriate type declaration.

19.9 Licensing and Reuse Conditions

Reuse conditions for published resources shall be explicit. Publicly releasable machine- readable law should, to the maximum extent consistent with law and policy, be distributed under clear terms that support citation, reuse, indexing, and responsible downstream processing. The publication service shall distinguish between restrictions arising from legal confidentiality or institutional policy and restrictions that arise merely from absent or ambiguous licensing language. Where restricted distributions are necessary, the applicable terms, access conditions, and prohibitions shall be machine-discernible or at least clearly declared in associated metadata and service documentation.

19.10 Public vs Restricted Distribution Rules

This Profile supports both public distribution and restricted distribution, provided the distinction is explicit and governed.

Public distributions may include authoritative texts, official derivatives, metadata, API endpoints, and bulk packages intended for broad reuse. Restricted distributions may include pre-publication bundles, internal exchange sets, embargoed texts, or legally controlled materials whose release conditions differ. A resource shall not move from restricted to public distribution through informal copying or path exposure alone. The transition shall occur through a controlled release act with traceable metadata and applicable publication notices.

19.11 Content Negotiation and Endpoint Behaviour

Where publication endpoints support content negotiation, resolver redirection, or format- specific retrieval, endpoint behavior shall be predictable, documented, and stable. Clients shall be able to determine, with reasonable certainty, how to retrieve the canonical XML manifestation, how to obtain derivative formats, how to access metadata, and how persistent identifiers resolve over time. Where content negotiation is not implemented, the platform may expose stable format- specific endpoints instead, provided the relationship between those endpoints and the underlying persistent resource remains explicit.

19.12 Resolver and Redirection Behaviour

Resolvers operating under this Profile shall map persistent identifiers or canonical URIs to current publication endpoints, manifestations, or explanatory landing pages in a manner consistent with Clause 10 and Annex F. Resolver behavior shall preserve persistence, avoid deceptive or circular redirects, and make it reasonably clear when the user has reached a work-level landing point, an expression-level view, or a manifestation-level file. Where a resource has moved, been superseded, been withdrawn from public access, or is available only in restricted form, the resolver should return a meaningful response rather than a silent failure. At minimum, it should preserve citation continuity and explain the current publication state to the extent permitted.

20 Security, Integrity, and Trust Controls

This Clause establishes the minimum security, integrity, and trust controls applicable to the authoring, validation, publication, exchange, and preservation of profile-conformant resources. Because machine-readable law is intended to function as national legal-information infrastructure, security under this Profile shall be understood not merely as server hardening but as a broader discipline of content integrity, provenance assurance, controlled release, and trustworthy traceability across the legal publication lifecycle.

20.1 Integrity Controls

Implementing institutions shall apply integrity controls sufficient to detect unauthorized change, corruption, or unexplained divergence in authoritative manifestations and exchange packages. Integrity controls may include checksums, controlled repository workflows, immutable release artifacts, versioned storage, tamper-evident logging, or other nationally approved

measures. The exact technical implementation may vary, but the integrity objective shall remain common across institutions. Where a manifestation has been altered after release, the fact of alteration shall be visible through controlled versioning or correction handling rather than hidden through silent replacement.

20.2 Provenance Assurance

Every authoritative or officially released resource shall be traceable to a governed provenance chain. At minimum, it shall be possible to identify the responsible institution, the release event, the applicable workflow stage, and the relationship between the published manifestation and its approved source basis. Provenance assurance shall be especially strong for consolidations, corrections, translations, and derived public renderings because these are the contexts in which misunderstandings about status and authorship most readily arise. Where provenance is distributed across more than one system, the linkage between those systems shall remain reviewable so that no critical provenance fact depends exclusively on inaccessible local memory or undocumented staff practice.

20.3 Role Separation

Role separation shall be applied in workflows where a single person or system action could otherwise introduce unreviewed legal-text changes, unauthorized publication, or concealed metadata manipulation. At minimum, institutions should separate, where operationally feasible, the roles responsible for source preparation, structured conversion or markup, validation management, editorial approval, and production publication. Smaller institutions may implement proportional controls, but they shall not collapse all critical control points into an unreviewable single- action workflow. Where automated pipelines perform multiple steps, equivalent control evidence shall be retained so that the functional separation of duties remains demonstrable even if some actions are system-executed.

20.4 Access Control for Pre-Publication Workflows

Pre-publication materials shall be protected by access controls proportionate to their sensitivity, legal status, and operational risk. Draft texts, embargoed instruments, unpublished amendments, and internal correction workflows shall not be exposed through the same uncontrolled channels used for public corpus access. Access permissions should follow role, need, and workflow state. Temporary publication candidates should not be reachable through public resolvers, guessable URLs, or unaudited shared drives before formal release. Where external vendors or technical service providers participate in pre-publication workflows, contractual and technical controls shall ensure that content confidentiality, integrity, and deletion or return obligations are clearly enforceable.

20.5 Authenticity and Certification Rules

Where authenticity assurance is required, the institution shall define how authenticity is evidenced for the relevant class of resource. Such evidence may consist of controlled

publication status, competent authority approval, digital signature or seal, certified derivative production, or other lawful mechanisms. Authenticity claims shall be precise. A platform shall not describe a manifestation as authoritative, official, certified, or authenticated unless the relevant basis for that claim is institutionally and legally supportable. Where multiple manifestations of the same expression are distributed, the authenticity rules shall identify whether authenticity attaches to the structured XML manifestation, to a visible derivative such as PDF, to both, or to a designated official pair of manifestations.

20.6 Audit Trail Requirements

Institutions operating under this Profile shall maintain audit trails sufficient to support accountability, incident review, release verification, and preservation of trust in the publication chain. At minimum, audit trails should record significant events such as ingest, normalization, structural conversion, validation runs, editorial approval, publication, correction, withdrawal, resolver changes, package generation, and archival deposit, together with responsible role or system attribution and timestamping. Audit trails shall be protected against uncontrolled alteration and retained for a period appropriate to the legal and operational significance of the relevant publication activities.

21 Archival and Preservation Requirements

This Clause establishes the preservation requirements applicable to profile-conformant legal resources and related evidence. Preservation under this Profile shall be understood as the sustained ability to maintain access to, interpret, verify, and where necessary reproduce the authoritative and evidentiary record of legal publications over time. Preservation therefore concerns not only the text of the law but also the identifiers, metadata, provenance, validation context, and derivative relationships that make the law trustworthy and usable in the future.

21.1 Preservation Principles

Preservation shall be guided by the principles of authenticity, integrity, persistence, intelligibility, traceability, and controlled accessibility. Institutions shall preserve profile-conformant resources in a manner that permits future determination of what the resource was, when it was issued or produced, what status it held, how it related to other expressions or manifestations, and whether it has remained intact. Preservation actions shall not destroy the distinction between work, expression, manifestation, or event state. Historical legal-information meaning depends on those distinctions remaining recoverable over time.

21.2 Preservation Manifestations

At minimum, the preservation set for a significant published resource should include the canonical XML manifestation and such additional manifestations or evidence as are necessary to preserve the publication record and future intelligibility of the resource.

Depending on the document class and workflow, preservation manifestations may include official derivative PDFs, source evidence files, package manifests, validation reports, checksum records, release notes, stylesheet or transformation references, and controlled metadata exports. No institution should preserve only a human-readable derivative where the structured canonical manifestation exists and forms the basis of future machine readability, citation, or reuse.

21.3 Long-Term Access Requirements

Preserved resources shall remain discoverable and retrievable over time through stable identifiers, maintained catalogue records, or equivalent archival access mechanisms. Long-term access shall account for the needs of legal research, governmental continuity, public evidence, inter-institution reference, and future migration. A preserved resource that exists physically but cannot be found, interpreted, or linked to its identity and status does not meet the preservation objective of this Profile. Where access restrictions apply, the preservation regime shall still preserve existence, provenance, and internal retrievability even if public retrieval is limited.

21.4 Evidence Preservation and Recordkeeping

Preservation shall include, where proportionate, the evidence needed to explain how the preserved manifestation came into existence and how it was validated and released. Evidence preservation may include approval records, transformation lineage, source references, publication notices, checksum manifests, correction notices, and archival deposit logs. Such records are especially important for constitutional texts, primary legislation, consolidations, and legally sensitive corrigenda. Institutions shall not rely solely on ephemeral operational logs where the publication event has long-term evidentiary significance. Key evidence shall be retained through a governed recordkeeping approach.

21.5 Format Sustainability Considerations

The preservation strategy under this Profile shall favor open, documented, and sustainably processable formats. The canonical XML manifestation is therefore a preservation-strength asset as well as a publication asset. Where ancillary formats are used, institutions shall avoid unnecessary dependence on proprietary binaries, opaque embedded objects, or undocumented transformation assumptions that would make later migration or verification difficult. Preservation planning should also include retention of the profile version, relevant schema and rule references, namespace documentation, and other contextual artifacts required to understand the preserved resource in future technical environments.

22 Implementation Guidance

This Clause provides implementation guidance for institutions adopting this Profile. It is intended to support pragmatic rollout while preserving the normative expectations established elsewhere in this document.

Implementation guidance under this Clause shall not be interpreted as weakening mandatory profile requirements. Rather, it identifies the minimum capabilities, workflow steps, and staged adoption practices necessary to operationalize those requirements within Pakistan's legal and institutional environment.

22.1 Minimum Institutional Capabilities

An institution implementing this Profile should, at minimum, possess or obtain the capability to identify and manage in-scope legal resources; create or receive structured source material; apply or verify identifiers and metadata; run validation; manage controlled publication; preserve released manifestations; and support issue correction and later migration. No institution shall assume that machine-readable law can be sustained as a one-time conversion exercise without governed ownership, editorial capability, technical validation support, and repository continuity. Where full in-house capability is not immediately available, institutions may use shared national services, centrally provided tooling, or coordinated service arrangements, provided responsibility and control remain clear.

22.2 Reference Workflow

A reference workflow under this Profile should proceed through controlled stages from source acquisition to long-term preservation. The exact platform implementation may vary, but the logical sequence shall remain clear, auditable, and repeatable.

22.2.1 Ingest

Ingest is the controlled receipt of born-digital or legacy legal material into the structured workflow. Ingest should capture source provenance, source type, receipt date, responsible institution, and initial classification of the resource. At ingest, institutions should also determine whether the source is authoritative, derivative, legacy evidence, draft input, correction input, or another controlled category, because later processing depends on that distinction.

22.2.2 Normalize

Normalization is the stage in which source material is cleaned, regularized, and prepared for reliable mapping into the structured model. This may include encoding cleanup, heading repair, whitespace normalization, OCR correction, table normalization, language tagging, and removal of page-furniture contamination from scanned or PDF-derived materials. Normalization shall be documented to the extent necessary to preserve trust in the transformation chain, especially where legacy material is affected.

22.2.3 Map to AKN

This stage includes document-class selection, structural segmentation, identifier assignment, metadata population, linkage of schedules and media, and controlled handling of notes, corrections, translations, and lifecycle events. Mapping shall not rely on undocumented per- operator improvisation for recurring document patterns.

22.2.4 Validate

Validation shall test the mapped resource against schema, profile rules, business rules, and such packaging or service checks as are relevant to the intended release path. Validation outcomes shall be retained in a reviewable manner. A failed validation shall trigger correction, exception handling, or rejection, and shall not be silently ignored.

22.2.5 Editorial Review

Editorial review is the human assurance step through which source fidelity, legal-text completeness, structural intelligibility, and publication readiness are confirmed. Editorial review is especially important in legacy conversion, bilingual handling, amendment modeling, and consolidation, because these are the areas where technically plausible markup can still be substantively wrong.

22.2.6 Publish

Publish is the controlled act by which the approved manifestation and associated metadata enter the governed publication environment. Publication should assign or activate the relevant resolver behavior, endpoint exposure, status labeling, and public or restricted access mode. Publication shall be attributable, timestamped, and capable of later verification.

22.2.7 Distribute

Distribution includes API exposure, portal presentation, bulk packaging, inter-institution transfer, and derivative dissemination. Distribution should preserve consistency with the released source and should not generate format-specific contradictions in identity, status, or language state.

22.2.8 Archive

Archive is the preservation deposit stage in which the approved publication record and supporting evidence are secured for long-term retention and later use. Archival deposit should occur as part of the release workflow rather than as an uncertain later activity dependent on manual recollection.

22.3 Migration from Legacy Sources

Legacy migration shall be treated as a controlled program rather than an informal batch conversion exercise. Institutions should prioritize legal significance, demand, corpus readiness, and source quality when determining migration order. Where the source corpus is predominantly PDF-based or scanned, migration planning shall explicitly account for OCR quality, manual review effort, structural ambiguity, missing amendment context, and the distinction between source evidence and reconstructed structured text. Legacy migration should produce a transparent status model so that users can distinguish between fully validated structured texts, provisional conversions, and items still dependent on legacy source evidence.

22.4 Pilot Implementation Guidance

Initial national implementation should proceed through a bounded pilot rather than immediate uncontrolled corpus-wide rollout.

A Pakistan pilot should prioritize high-value, comparatively stable corpora such as the Constitution, federal Acts, and a selected set of amendments, together with a small number of document classes that exercise key profile features such as bilingual handling, schedules, and point-in-time publication. Pilot scope should be sufficient to test identifiers, metadata, validation, resolver behavior, HTML and PDF derivatives, packaging, and archival deposit before wider expansion.

22.5 Federal-Provincial Rollout Guidance

Federal-provincial rollout should follow a coordinated but adaptable approach. The common national profile should remain stable, while implementation sequencing, local corpus readiness, and supporting service arrangements may differ across jurisdictions. Provincial adoption should not result in incompatible identifier grammars, divergent structural assumptions for common document classes, or inconsistent language and metadata rules where national interoperability is intended. A coordinated governance mechanism should therefore support shared code lists, resolver policy, validation fixtures, and corpus onboarding guidance across the Federation.

22.6 Tooling and Repository Guidance

This Profile is tool-neutral and vendor-neutral. Institutions may use proprietary, open-source, or hybrid tooling provided the resulting resources remain conformant, portable, and governable. Tooling choices should favor standards-based storage, exportability, validation support, repeatable rendering, and long-term maintainability. Repositories should support identifier persistence, metadata queryability, version control, derivative generation, and preservation- ready export. No implementation should become dependent on a single supplier or opaque system behavior such that the institution cannot later migrate, audit, or independently verify its own legal-information assets.

23 Profile Evolution and Transition Management

This Clause governs how this Profile shall evolve over time and how implementing institutions shall manage transition from one profile state to another. Because legal-information infrastructure must remain persistent across institutional, technical, and supplier change, profile evolution under this Clause shall emphasize controlled change, backward compatibility where feasible, transparent deprecation, and managed institutional transition rather than disruptive replacement.

23.1 Profile Versioning Policy

This Profile shall maintain a clear versioning policy distinguishing editorial updates, clarificatory updates, backward-compatible substantive updates, and breaking updates. Editorial updates may correct wording, references, typographic defects, or explanatory material without altering normative meaning. Clarificatory updates may sharpen interpretation while preserving intended behavior. Backward-compatible substantive updates may introduce additional controlled capabilities without invalidating prior conformant

resources. Breaking updates shall be reserved for changes that materially affect conformance, structure, identifiers, packaging, or publication behavior. Version labels and release notices shall make these distinctions visible so that institutions can plan transition proportionately.

23.2 Transition from Earlier Versions

Where a new update of this Profile is published, the Profile Owner shall specify the transition relationship between the outgoing and incoming versions. At minimum, transition notices should identify the effective date, conformance impact, migration requirements, validity of existing content, and whether previously released resources remain conformant, become conditionally conformant, or require controlled remediation. No institution shall be expected to infer migration policy from a version number alone. Transition must be governed explicitly.

23.3 Backward Compatibility Controls

Backward compatibility shall be preserved wherever reasonably possible, especially in relation to persistent identifiers, public citation anchors, existing published manifestations, and machine-consumable metadata relied upon by downstream users. Where backward compatibility cannot be preserved, the Profile Owner shall provide compensating controls such as redirects, mapping guidance, alias handling, schema migration rules, or dual-running arrangements during the transition period. Breaking change without migration support is contrary to the long-term public-value goals of this Profile and should be avoided except where a compelling national reason exists.

23.4 Deprecation Rules

Deprecation shall be explicit, documented, and time-bounded where appropriate. When a structure, attribute, namespace usage, packaging behavior, endpoint pattern, or validation rule is deprecated, the Profile Owner shall identify the deprecated item, the reason for deprecation, the replacement approach, and the effect on future conformance. Deprecated features may remain temporarily usable for compatibility purposes, but institutions shall not introduce new production dependencies on features that have formally entered deprecation unless expressly permitted. Where public resources depend on deprecated behavior, transition arrangements shall preserve user access and citation continuity during the managed withdrawal period.

23.5 Institutional Transition Planning

Each implementing institution shall maintain a practical transition plan sufficient to adopt relevant profile updates without uncontrolled disruption to drafting, publication, repository operations, or preservation responsibilities. Transition planning should address validator updates, stylesheet updates, repository mappings, API behavior, staff guidance, exception handling, and preservation of previously released manifestations. Where a profile version affects federal and provincial interoperability, coordinated transition windows should be preferred so that avoidable national fragmentation does not arise from staggered incompatible adoption.

24 Supporting Annexes, Publication Maintenance, and Controlled

Further Development

This Clause records the maintenance position of this Profile as a publication-ready national instrument supported by governed annexes, controlled code lists, validation artifacts, and implementation notices. The clauses preceding this one establish the core profile needed for authoritative structured publication, exchange, validation, and preservation. The annexes to this document convert that core into an operational national implementation package.

24.1 Annex Suite

The following annexes form part of the implementation package for this Profile:

• (a) Annex A (Normative) — Conformance Statement Template;
• (b) Annex B (Normative) — Pakistan Identifier Grammar and Examples;
• (c) Annex C (Normative) — Minimum Metadata Dictionary;
• (d) Annex D (Normative) — Document-Type Minimum Structural Templates;
• (e) Annex E (Normative) — Validation Rule Baseline;
• (f) Annex F (Normative) — Package, API, Resolver, and Distribution Baseline;
• (g) Annex G (Normative) — Controlled Vocabularies and Authority Lists; and
• (h) Annex H (Informative) — Implementation Phasing Note. Where a conflict appears between the main clauses and a normative annex, the main clauses shall prevail unless the issuing authority expressly states that the annex provision controls for the defined operational purpose.

24.2 Publication Maintenance

The Profile Owner shall maintain this Profile, its annexes, code lists, namespace rules, example packages, fixtures, and implementation notices as a coherent publication family. Maintenance shall include:

• (a) controlled publication of updated annexes or annex updates;
• (b) preservation of prior annex versions where historical conformance review requires them;
• (c) controlled notice of deprecated rules, identifiers, or package behaviors;
• (d) continued publication of implementation guidance sufficient to support repeatable national rollout; and
• (e) maintenance of a public clarification path for issues that do not yet require formal profile version.

24.3 Controlled Further Development

Further development under this Profile shall proceed through governed update, controlled annex publication, implementation notices, or approved code-list expansion. No institution shall treat recurring local practice as nationally approved merely because it has been used operationally in one environment. Future controlled development may include, inter alia:

• (a) additional document classes;
• (b) richer parliamentary workflow modelling;
• (c) more detailed subject-taxonomy support;
• (d) deeper linked-data alignment;
• (e) advanced bilingual alignment services;
• (f) expanded preservation profiles; and
• (g) additional distribution or exchange formats that remain subordinate to the canonical XML representation.

24.4 Informative Issue Register Outside the Normative Body

Implementation questions, ambiguous edge cases, recurring deployment issues, and candidate future enhancements should be recorded in an informative issue register maintained by the Profile Owner or designated governance mechanism. Such an issue register shall support controlled learning and profile improvement; however, it shall not itself modify the normative meaning of this Profile unless and until the relevant matter is incorporated through formal change control.

24.5 National Implementation Position

With the annex suite published and governed under this Clause, this Profile shall be treated as a complete national application-profile baseline for initial Pakistan implementation. Subsequent work should prioritize disciplined rollout, validator maturity, corpus onboarding, and repository quality rather than uncontrolled reinvention of the core profile model.

25 Conformity Assessment

This Clause defines the final, mandatory conformity-assessment baseline for this Profile. It consolidates, for assessment purposes, the conformance framework established in Clause 6, and states how conformity is to be verified, who may perform that verification, and how this Profile maps to its parent base standard.

25.1 Purpose

The purpose of this Clause is to ensure that any claim of conformity to this Profile can be independently verified against evidence, rather than asserted on the basis of narrative description alone. This Clause applies to every conformance class defined in Clause 6.3 and to every compliance level defined in Clause 6.5.

25.2 Conformity Mapping to the Base Standard

As a Profile (PRF) under the DNP series, this Profile constitutes a constrained, governed implementation of the Akoma Ntoso base standard identified in Clause 2.1. Accordingly, conformity assessment under this Profile shall include an explicit mapping between:

• (a) each normative requirement of this Profile; and
• (b) the corresponding element, attribute, naming-convention rule, or specification clause of the base Akoma Ntoso standard from which it is derived, constrained, or to which it adds a national rule.

This mapping shall be maintained by the Profile Owner as part of the Annex A conformance statement template and shall be made available to implementers and assessors so that conformity to this Profile can be distinguished from, and related to, conformity to the base standard.

25.3 Assessment Methods

Consistent with Clause 6.7, conformity under this Profile may be assessed through self- assessment, coordinated assessment under a national conformance program, third-party technical assessment where designated, or automated conformance testing supported by reference fixtures and validation assets. The Profile Owner shall determine which method or combination of methods applies to a given conformance class, document class, or institutional context, and shall publish that determination through implementation notice or annex update.

25.4 Assessment Evidence and Records

A conformity assessment shall be supported by the evidence described in Clause 6.6, recorded in the conformance statement format prescribed by Annex A, and, where validation tooling is used, by results referable to the validation rule catalogue in Annex E. Assessment records shall be retained by the assessed institution and, where applicable, by the Profile Owner, for the period prescribed by the Profile Owner’s recordkeeping policy.

25.5 Outcome Classification

The outcome of a conformity assessment shall be classified as fully conformant, conformant with declared limitations or transitional arrangements under Clause 6.9, or non-conformant. Non-conformant outcomes shall be handled in accordance with the severity classification and remediation process set out in Clause 6.8. No institution, system, or service shall represent an assessment outcome of “conformant with declared limitations” as full conformance.

25.6 Re-Assessment and Currency

A conformity assessment is current only as at the Profile version and evidence set against which it was performed. Where this Profile is revised in a manner affecting an applicable requirement, or where the implementation assessed is materially changed, the assessment shall be treated as lapsed until re-assessed. The Profile Owner shall specify, in implementation guidance, the maximum interval after which a conformity assessment must be renewed even absent a Profile revision.

Annex A (normative) — Conformance Statement Template

This Annex establishes the minimum national template for any conformance statement, implementation declaration, procurement response, onboarding submission, validator attestation, or publication-readiness claim made under this Profile. The template is intended to make claims specific, testable, comparable, and auditable.

A.1 Required Claim Header

A.2 Conformance Class Matrix

A.3 Corpus and Document-Scope Declaration

A.4 Required Evidence Set

A.5 Exceptions, Limitations, and Transitional Arrangements

A.6 Approval and Retention

Every conformance statement shall be retained as a governed record together with the validator versions, ruleset versions, test-fixture release, responsible sign-off, and the evidence pack relied upon. Where a public claim is withdrawn, superseded, or narrowed, the institution shall preserve the historical claim record and state the reason for change.

Annex B (normative) — Pakistan Identifier Grammar and Examples

This Annex supplies the national baseline for persistent legal identifiers, canonical HTTP publication identifiers, and fragment-level citation anchors. It is intended to translate Clause 10 from policy text into a formal enough grammar that different implementers do not produce mutually incompatible identifier sets while still claiming conformance.

B.1 General Rules

B.2 Controlled Token Sets

B.3 Persistent Work Identifier Pattern

The national persistent layer SHALL use a URN:LEX-governed strategy or a later nationally designated replacement with materially equivalent persistence properties. Until superseded, the Pakistan profile shall treat the following pattern as the baseline local-name discipline for work-level identifiers. Generic pattern: urn:lex:{jurisdiction}:{document-class}:{date-or-year};{official-number}

B.4 Work-Level Examples

B.5 Expression Identifier Pattern

Expressions SHALL be distinguishable by language, temporal/legal state, and controlled point-in-time or consolidation status where applicable. Expression identity SHALL remain linked to, and subordinate to, the work-level identifier. Illustrative pattern:

{work-id}!expression/{language}/{state}[/{as-at-date}]

B.6 Manifestation and Publication URI Pattern

Manifestations SHALL remain traceable to the governing work and expression. The canonical HTTP layer SHALL be nationally controlled, resolvable, and stable enough for citation support, API access, and derivative retrieval. Illustrative publication pattern: https://law.pakistan.gov.pk/akn/{jurisdiction}/{document-class}/{year-or-date}/{official- number}/{language}/{state}.{format}

B.7 Fragment Grammar and Continuity Rules

B.8 Validation Constraints

B.9 Pakistan-Specific Edge Cases

Annex C (normative) — Minimum Metadata Dictionary

This Annex turns the metadata policy of Clause 11 into a minimum field dictionary. It sets out the baseline fields that every conformant implementation shall support, together with their abstraction level, requirement status, type, and governance notes.

C.1 Work-Level Metadata

codes.

C.2 Expression-Level Metadata

C.3 Manifestation-Level Metadata

C.4 Event Metadata

C.5 Cardinality and Nullability Rules

C.6 Field Crosswalk Expectations

Implementers shall be able to map each mandatory field in this Annex to the concrete Akoma Ntoso structure or metadata location used in the national profile implementation. Where crosswalks to Dublin Core, ELI, or RDF are provided, they shall be treated as interoperable projections and not as substitutes for the richer legal-domain metadata required by this Annex.

Annex D (normative) — Document-Type Minimum Structural Templates

This Annex provides the minimum structural baseline for the document classes initially brought within scope. It does not attempt to exhaust every drafting variation found in the corpus; instead, it defines the minimum expected structural commitments that must be respected for profile-conformant representation.

D.1 Structure Matrix by Document Class

D.2 Minimum Mandatory Internal Components

D.3 Amendment-Formula Handling

D.4 Pakistan-Specific Source Irregularities

Implementers shall expect legacy and live-source irregularities including mixed numbering patterns, parenthetical designations in SROs, Gazette-derived line breaks, inconsistent heading capitalization, embedded tables as images, and corrigenda that target publication manifestations rather than the legal work directly. None of these source realities justify abandoning structured representation; instead, they require stronger provenance, controlled editorial handling, and specific validation rules.

Annex E (normative) — Validation Rule Catalogue Baseline

This Annex supplies the minimum validation catalogue. The rule IDs below are a national baseline. Additional institution-specific rules may be used, but they shall not weaken or contradict these baseline controls.

E.1 Severity Definitions

E.2 Rule Catalogue

E.3 Minimum Release Gate

Annex F (normative) — Package, API, Resolver, and Distribution

Baseline

This Annex provides the minimum operational baseline for packaging, programmatic access, resolver behavior, and bulk distribution. It is not a full OpenAPI specification, but it is sufficiently detailed to constrain procurement, onboarding, and interoperability.

F.1 Canonical Package Layout

F.2 API Endpoint Baseline

F.3 Query and Response Constraints

F.4 Resolver Behavior Matrix

F.5 Bulk Distribution Profiles

Annex G (normative) — Controlled Vocabularies and Authority Lists

This Annex provides the minimum nationally governed code sets required for interoperable profile operation. These lists are a baseline and may be expanded through controlled change governance.

G.1 Jurisdiction Codes

G.2 Document-Class Codes

G.3 Lifecycle and Publication Status Codes

G.4 Expression Authority / Authenticity Codes

G.5 Authority Role Codes

G.6 Language Tags Baseline

Annex I (informative) — Sample Instance Blueprints

This Annex provides informative blueprints illustrating how different classes of Pakistani legal materials should be conceptualized and packaged. It is not a substitute for the normative grammar or future fully worked XML instances, but it helps implementers understand the intended object model.

H.1 Federal Act Blueprint

Work: federal Act; Expression: English enacted expression; Manifestations: canonical AKN XML, HTML derivative, PDF derivative; Events: enactment, publication, later commencement if separate; Components: sections, schedules, forms, tables, correction history where applicable.

H.2 Bilingual Act Blueprint

One work; at least two expressions (enacted English and official Urdu translation, or vice versa as lawfully governed); alignment metadata linking corresponding sections / articles; shared work-level identifier; distinct expression identifiers and manifestation URIs.

H.3 Ordinance Blueprint

One ordinance work; promulgation event; publication manifestation(s); later lifecycle events for lapse, replacement, or conversion into Act; preservation of historical ordinance identity even if later superseded.

H.4 SRO / Notification Blueprint

One executive statutory instrument work; designation line and legal basis modeled explicitly; schedule and table handling preserved where legally operative; parent enabling work and publication reference carried in metadata.

H.5 Corrigendum Blueprint

One corrigendum work or correction event, depending on legal/publication practice; explicit target relation to the affected manifestation or work; preservation of pre-correction and post- correction publication history.

Annex II (informative) — Rendering and Bilingual Display Guidance

This Annex provides display-layer guidance so that public portals, internal dashboards, and archive interfaces do not accidentally destroy legal intelligibility while rendering structurally correct content.

Annex III (informative) — Migration and QA Checklist

Annex IV (informative) — Governance RACI and Change Register

Templates

K.1 Minimum RACI Matrix

K.2 Change Request Register Template

`{=openxml}

`

Bibliography

The following non-normative references are provided to support implementation, interpretation, comparison, training and migration planning. They do not carry normative force under this Profile unless expressly incorporated into the body or into an annex designated as normative (see clause 2.5).

[b-1]OASIS. Akoma Ntoso Version 1.0 Part 1: XML Vocabulary. OASIS Committee Specification, approved 29 August 2018.

[b-2]OASIS. Akoma Ntoso Version 1.0 Part 2: Specifications. OASIS Committee Specification, approved 29 August 2018.

[b-3]OASIS. Akoma Ntoso Naming Convention Version 1.0.

[b-4]OASIS. Media Type Specification for application/akn+xml.

[b-5]IETF. RFC 9676 — LEX: A Uniform Resource Name (URN) Namespace for Sources of Law.

[b-6]IETF. RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels.

[b-7]IETF. RFC 8174 — Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.

[b-8]IETF. BCP 47 — Tags for Identifying Languages.

[b-9]Pakistan Digital Authority. DNP-X.001 FWK — Nomenclature, Series Structure, and Issuance Framework (03/2026).

[b-10]Pakistan Digital Authority. DNP-X.400 FWK — Structured Standards Publication Framework.

Note — Clause 2.5 of this Profile additionally identifies categories of informative material that the Profile Owner may maintain as a living, non-exhaustive register rather than a fixed bibliographic list.

Machine-Readable Metadata Block (JSON-LD)

The following JSON-LD block is the structured metadata record for this publication, per DNP-X.001 clause 13 and DNP-X.400 clause 9. It is provided here as the final page of the publication; the equivalent machine-readable file accompanies the publication package as metadata.jsonld.

{
    "@context": "https://standards.dnp.gov.pk/schema/dnp",
    "@type": "DNPPublication",
    "identifier": "DNP-L.400 PRF",
    "urn": "urn:dnp:L.400",
    "persistentUrl": "https://standards.dnp.gov.pk/DNP-L-400.html",
    "title": "Pakistan AKN Application Profile (PAKN-AP)",
    "titleUrdu": null,
    "publishingAuthority": "Pakistan Digital Authority (PDA)",
    "series": "L",
    "documentType": "PRF",
    "lifecycleStage": "CD",
    "maturityLevel": "PILOT",
    "classification": "INTERNAL",
    "language": "en",
    "normativeReferences": [
       "OASIS Akoma Ntoso v1.0 Part 1: XML Vocabulary",
       "OASIS Akoma Ntoso v1.0 Part 2: Specifications",
       "OASIS Akoma Ntoso Naming Convention v1.0",
       "IETF RFC 9676 (LEX URN Namespace)",
       "IETF RFC 2119 / RFC 8174",
       "IETF BCP 47",
       "DNP-X.001 FWK",
       "DNP-X.400 FWK"
    ],
    "dateApproved": null,
    "dateEffective": null,
    "dateReview": null,
    "rightsBasis": "PDA-owned",
    "jurisdiction": "PK",
    "gazetteReference": null
}

Note — Fields recorded as null are not yet determinable at Committee Draft (CD) v0.1 (e.g. dateApproved, dateEffective, dateReview, titleUrdu, gazetteReference) and shall be populated by the Profile Owner as this Profile advances through the PRF issuance procedure (DNP-X.001 clause 11.7) toward Final Draft (FD) and Publication (PUB).