Clarification Queries

Ref

Topic / Reference

Question

Reason for Asking

Ignite's Response

Q-01

B8_User_Portal_and_Marketplace — Section A — AI Accelerators (60 marks)

Ref: Form: B8_User_Portal_and_Marketplace | Section: Section A — AI Accelerators (60 marks) | Item #: 2 | Marks: 6

Requirement: Key Features & catalogue management

Client's Wording: Searchable catalog, solution showcasing, program/hackathon management, demo days, investor matching, recommendation engine.

Clarification is requested on the definition of "investor matching" within the marketplace scope. Please confirm

• (a) what the platform is expected to deliver - a directory of registered investors with profile matching and introduction requests, or an end-to-end deal workflow including data room, term-sheet exchange and transaction tracking;
• (b) whether Ignite will supply the investor base and any accreditation or KYC screening, or whether the bidder is expected to onboard investors; and
• (c) whether any regulatory approval under SECP or other Pakistani financial-services rules is assumed to be handled by Ignite.

Substantiation: Detailed description, feature list, screenshots, wireframes

• (a) A core engine covering demand and supply side including discovery/introduction capability under Company governance -- not a full transactional deal workflow (data room, term-sheet exchange, transaction tracking).
• (b) Bidders should support both Company-supplied and bidder-onboarded investors, subject to Company governance/approval.
• (c) Marketplace should have provision of verification from relevant authorities through APIs etc. Ignite will provide all possible support through documentation but bidders remain responsible for general regulatory compliance.

Q-02

Form B6 — Sovereign AI Language Model Capability, Data Pipelines & Tiered Inference Services — Section A — Model Training & Fine-Tuning Platform (25 marks)

Ref: Form: Form B6 — Sovereign AI Language Model Capability, Data Pipelines & Tiered Inference Services | Section: Section A — Model Training & Fine-Tuning Platform (25 marks) | Item #: 4 | Marks: 6

Requirement: Platform handover & independence

Client's Wording: Platform fully operable by the in-country team without bidder dependency at contract end; no licensing or technical lock preventing continued independent fine-tuning

Clarification is requested on the scope of "no licensing or technical lock" and on what constitutes an acceptable handover.

• (a) Does this item require the bidder to grant the Government of Pakistan a perpetual, irrevocable, royalty-free and transferable licence to the training and fine-tuning platform software that survives contract end, or is a renewable subscription — which GoP is free to renew or discontinue — acceptable?
• (b) Are third-party and open-source components governed by their own upstream licences acceptable within the handed-over platform, provided that none of them restricts the Government's continued independent fine-tuning?

Substantiation: Handover plan; dependency/lock-in disclosure

• (a) Yes -- a perpetual, irrevocable, transferable licence to the platform, surviving contract end, at no cost/financial obligation to GoP.
• (b) Yes -- third-party/open-source components under their own upstream licences are acceptable, provided none restricts GoP's continued independent fine-tuning and no additional financial obligations are involved.

Q-03

Form B6 — Sovereign AI Language Model Capability, Data Pipelines & Tiered Inference Services — Section B — Governed Data Pipelines & Local-Context Datasets (25 marks)

Ref: Form: Form B6 — Sovereign AI Language Model Capability, Data Pipelines & Tiered Inference Services | Section: Section B — Governed Data Pipelines & Local-Context Datasets (25 marks) | Item #: 1 | Marks: 5

Requirement: Data-partnership framework

Client's Wording: A working framework and signed initial data-sharing arrangements with willing Pakistani organisations, operating under MoITT/Ignite governance and consent/legal compliance

Clarification is requested on the timing, form and counterparty of the required data-sharing arrangements.

• (a) Must the "signed initial data-sharing arrangements" be executed and submitted at bid-submission stage, or is a binding commitment together with a post-award signature milestone schedule acceptable? If signature is required at bid stage, please state the minimum number of arrangements expected and the acceptable instrument (MoU, letter of intent, or full data-sharing agreement).
• (b) Will MoITT/Ignite nominate, introduce or pre-approve candidate Pakistani data-holding organisations, and can Ignite issue a letter of support to facilitate access to government-held datasets? Access to public-sector data is materially outside a bidder's unilateral control.

Substantiation: Partnership engagement plan; governance/consent model

Ignite/MoITT will provide all possible support to facilitate access to data-holding organisations; the data-governance framework will be owned by Ignite/MoITT.

Q-04

Form B6 — Sovereign AI Language Model Capability, Data Pipelines & Tiered Inference Services — Section B — Governed Data Pipelines & Local-Context Datasets (25 marks)

Ref: Form: Form B6 — Sovereign AI Language Model Capability, Data Pipelines & Tiered Inference Services | Section: Section B — Governed Data Pipelines & Local-Context Datasets (25 marks) | Item #: 4 | Marks: 5

Requirement: Data sovereignty & governance

Client's Wording: All collected/curated data resident in-country, owned by GoP, with full provenance, audit trail, and consent/withdrawal handling under MoITT/Ignite governance

Clarification is requested on residency, ownership scope and the consent/withdrawal obligation.

• (a) Does "resident in-country" prohibit all cross-border access to the data, including read-only access by non-Pakistani specialist engineers during supported fault diagnosis? If controlled remote support is permitted, please confirm the acceptable mechanism — for example a GoP-supervised jump host, full session recording, and named-individual prior approval.
• (b) Does GoP ownership extend to derived artefacts — tokenised corpora, embeddings, vector indices, intermediate checkpoints and evaluation sets — in addition to the raw and curated datasets?
• (c) On "consent/withdrawal handling": where a data subject withdraws consent after a model has already been trained, is it sufficient to delete the record from the dataset and exclude it from the next training cycle, or does Ignite require the removal of its influence from already-trained weights (machine unlearning or retraining)? Please also state the required response time for a withdrawal request.
• (d) Is there an existing MoITT/Ignite data-governance policy, data-classification scheme or residency standard that the bidder's documentation must map to? If so, please issue it with the clarification response.

Substantiation: Data-governance and residency documentation

Data flow is to be governed as per the applicable policies, rules, and regulations, etc.

Q-05

Form B7 — Section B: Ecosystem Adoption & Software Maturity — Migration & interoperability tooling

Ref: Form: Form B7 — Section B: Ecosystem Adoption & Software Maturity | Section: Migration & interoperability tooling | Item #: 6 | Marks: 5

Requirement: Migration & interoperability tooling

Client's Wording: Little or no tooling to migrate from common ecosystems; high lock-in

The definition of "common ecosystems" is not clarified. clarification required ; if it refers to the CUDA / PyTorch ecosystem.

Substantiation: Migration tooling documentation; portability evidence

Not limited to CUDA/PyTorch -- migration/interoperability tooling should align with popular, widely-adopted AI/ML ecosystems generally.

Q-06

Form B6 — Sovereign AI Language Model Capability, Data Pipelines & Tiered Inference Services — Section C — Sovereign Fine-Tuned LLM (the national model)

Ref: Form: Form B6 — Sovereign AI Language Model Capability, Data Pipelines & Tiered Inference Services | Section: Section C — Sovereign Fine-Tuned LLM (the national model) | Item #: 2 | Marks: 8

Requirement: Fine-tuning for Urdu & local context

Client's Wording: Model fine-tuned/aligned on the Urdu corpora and local-context datasets of Section B, with demonstrated capability uplift on Urdu/local evaluation sets versus the untuned base

The definition of Benchmark need to define

Substantiation: Before/after evaluation results on Urdu/local benchmarks

Not a single named suite -- any recognised industry-standard/best-practice benchmark demonstrating capability uplift before vs. after fine-tuning on the Urdu corpora and local-context datasets.

Ref

Topic / Reference

Question

Reason for Asking

Ignite's Response

1

DR / Colocation Requirements; Draft SLA §11–12, pp. 234 onward

The RFP requires Primary and DR facilities with defined recovery targets. Kindly clarify the intended overall resilience architecture: should both sites provide equivalent AI compute, storage, network and platform capacity, or may bidders propose an appropriately sized DR environment capable of restoring the required critical services within the prescribed RPO/RTO?

Defines the complete Primary/DR architecture, capacity, replication model and major cost baseline. The SLA defines recovery targets but not equivalent infrastructure capacity.

Bidders may propose an appropriately sized DR environment based on industry best practices (baseline 75% primary 25% DR); The proposal should support the core platform, including orchestration platform and AI stack, to be deployed both in Primary and DR environment to meet the SLA requirement.

2

DR / Colocation Requirements; Technical Evaluation – DR, p. 81

As part of the end-to-end DR solution, should bidders determine whether the two sites operate Active/Active or Active/Passive, together with the required inter-site bandwidth, provided the committed availability, RPO and RTO are achieved? If not, kindly provide IGNITE's preferred operating model and minimum inter-site connectivity requirements.

Architecture, WAN capacity, replication technology and DR investment all depend on this decision.

Bidders shall declare their proposed design and demonstrate it meets the committed availability and RPO/RTO targets in the SLA.

3

Layer 1 – Accelerator / AI Fabric Requirements

The solution is expected to support future AI capacity growth in addition to the initial accelerator deployment. Kindly clarify whether the required 25% growth headroom means only that the architecture must be expandable, or whether Day-1 facility capacity—including rack space, power, cooling and network ports—must also be reserved for this expansion.

Ensures compute, network and colocation facilities are engineered as one scalable solution rather than independently sized components.

Treated differently by domain: facility power/cooling headroom (25%) must be an actual, physically guaranteed Day-1 capacity; network-fabric headroom is an architectural requirement (topology must accommodate 25% growth without re-architecting), not a Day-1 port-population mandate.

4

Layer 1 – Accelerator Requirements

Given the rapid evolution of AI accelerator technologies, kindly clarify at what project milestone the requirement for “latest-generation, in-production” accelerators will be assessed—bid submission, contract award, procurement or delivery. May the bidder upgrade to a newer equivalent/superior generation during execution, subject to compatibility and approval?

Prevents the overall solution becoming technologically outdated during a potentially long procurement and deployment cycle.

Assessed as declared at bid submission and re-confirmed at Delivery/Operational Acceptance; any change requires the Company's prior written approval and compliance with procurement rules.

5

Data-Pipeline / General-Purpose Compute Tier, p. 92

The RFP requires a dedicated data-pipeline compute tier with ≥1,500 physical CPU cores, ≥1 TB memory per node and ≥500 TB flash-class working storage. Kindly clarify whether IGNITE's objective is physical separation of compute and storage resources, or guaranteed dedicated performance and isolation. Accordingly, may bidders integrate the 500 TB scratch requirement with the high-performance parallel-storage architecture if the required ≥100 GB/s read/write performance and workload isolation are demonstrably achieved?

Allows the complete data path—ingestion → processing → storage → GPU training—to be optimized as one architecture rather than creating potentially duplicated storage islands.

Both physical separation of compute and storage resources, as well guaranteed dedicated performance and isolation.

6

Parallel Storage System, §26.1 / Technical Evaluation Section D, pp. 93 onward

For the parallel-storage solution, Kindly confirm whether the ≥1 PB hot-tier expansion requirement represents usable capacity after data protection. Further, will IGNITE prescribe a standard benchmark methodology for validating ≥380 GB/s read, ≥190 GB/s write and ≥6 GB/s concurrent delivery per accelerator node, or should bidders propose an OEM-validated test methodology for acceptance?

Capacity and performance must be evaluated together to correctly engineer the storage nodes, media, protection scheme and storage fabric.

≥ 200 TB usable (post-data-protection) for the active training working set, non-disruptively expandable to ≥1 PB. The bidders shall propose an OEM-validated methodology, for the Company's review as part of the Acceptance Test Plan.

7

Parallel Storage §26.1.4 – Direct Storage-to-Accelerator DMA

The RFP requires a direct data path from parallel storage to accelerator memory. Is the functional objective to achieve CPU-bypass/high-performance accelerator data movement, allowing any OEM-supported standards-based or equivalent implementation, rather than requiring a specific proprietary technology?

Maintains interoperability and allows the storage, accelerator and network ecosystem to be selected as an integrated solution rather than locking the architecture to one implementation.

Yes — the requirement is technology-neutral outcome, no specific proprietary technology is mandated. So, architecture will remain same as required.

8

AI Fabric / Networking Requirements; Scope Overview

For clarity of the complete network architecture, Kindly confirm whether bidder responsibility extends across all required connectivity domains—AI accelerator fabric, parallel-storage fabric, service/data network, management/OOB network, security perimeter, Internet/external connectivity and Primary-to-DR connectivity—or identify any connectivity that will be provided by IGNITE or another nominated party.

Establishes the end-to-end network boundary and prevents interface gaps between different partners/OEMs. The Prime Bidder otherwise carries end-to-end integration accountability.

Bidder responsibility extends across all listed connectivity domains.

9

§26.1.6 – Container Orchestration, pp. 151–152

The RFP intentionally permits a CNCF-conformant Kubernetes platform without mandating a vendor. To support long-term technology sovereignty and portability, Kindly confirm whether a production-grade open-source Kubernetes architecture with enterprise-grade 24×7 support is acceptable, or whether IGNITE expects commercial OEM subscriptions for the complete Managed Operations Term.

Determines the overall platform strategy, long-term licensing model, support responsibility and degree of vendor independence.

Yes — a production-grade open-source Kubernetes architecture is acceptable; no commercial OEM subscription is mandated, provided the RFP's 24×7×365 support and Anti-Lock-In obligations are met.

10

§26.1.8 – DR & Backup; Draft SLA §11

The RFP defines different RPO/RTO targets for critical, standard and bulk/archival services. Should bidders therefore design a policy-based data-protection architecture in which datasets, model artefacts, platform state and other data are protected according to their service criticality, or is the complete parallel-storage dataset expected to be replicated at the DR facility?

This is fundamental to DR storage capacity, backup sizing, replication bandwidth and overall solution economics.

A policy-based, criticality-driven architecture is intended, confirmed by the SLA's differentiated RPO/RTO targets by service tier; full replication of the entire dataset is not mandated. The protection of core platform, including orchestration platform and AI stack, should support the operation in both in Primary and DR environment to meet the SLA requirement.

11

§26.1.8 – Backup & DR; Draft SLA §11

To engineer the complete data-protection solution, Kindly confirm whether IGNITE will prescribe backup retention, backup frequency, immutability and archival requirements, or whether bidders should propose an appropriate policy aligned with the RFP-defined service tiers and RPO/RTO objectives.

Without the protection policy, backup capacity, technology and long-term storage requirements cannot be accurately sized.

Bidders shall propose a backup architecture with defined retention, aligned with the RFP's tiered RPO/RTO framework, for the Company's review and approval.

12

Cross-Cutting Security / IAM / Security Operations

Should NAIIH be designed with its own complete cybersecurity operations environment—including IAM, MFA/PAM, SIEM/SOC and associated security controls—or are any existing IGNITE/Government identity or SOC platforms expected to be integrated with the proposed ecosystem?

Determines whether we build a self-contained security ecosystem or an integrated security architecture and avoids duplicate technology investment.

A complete, self-contained security operations capability is required as part of scope.

13

§26.1.7 – Infrastructure Monitoring & Telemetry, p. 151; Cross-Cutting Monitoring/Logging

Does IGNITE expect a unified observability and operations platform covering compute, accelerators, network, storage, facilities, Kubernetes and platform services, or should the solution integrate with any existing NOC/SOC/ITSM platforms?

The ecosystem requires end-to-end operational visibility; this clarifies whether monitoring is a complete new solution or an integration requirement.

A unified, complete observability capability is required as part of scope for the solution to integrate with.

14

Colocation Requirements; Draft SLA §12, pp. 234 onward

Considering the high-density accelerator infrastructure, Kindly confirm whether bidders may propose liquid-cooled/high-density AI systems together with the necessary CDU, manifolds and facility integration. Additionally, must both proposed facilities already hold operational Tier III/TIA-942 Rated-3 certification at bid submission, or may certification be completed before deployment/Operational Acceptance?

AI system selection, colocation selection, rack density, power and cooling must be engineered together. The RFP requires operationally certified, concurrently maintainable facilities.

Kindly refer to form B3 and form B5.

15

Technical Evaluation B9-2 – Core Component Implementation & Testing

The RFP requires OEM involvement for implementation and testing of “Core Components.” Kindly clarify which technology domains are considered Core Components and whether implementation by OEM-authorized/certified partners under OEM supervision/support is acceptable, while the Prime Bidder retains end-to-end integration accountability.

Critical for defining the delivery model across GPU, compute, storage, networking and platform OEMs and avoiding overlapping implementation responsibilities.

Some of the core components include e.g. accelerators, storage, networking/ interconnects, cybersecurity, orchestration layer, AI stack etc. Implementation by OEM, with the Prime Bidder retaining end-to-end accountability, is consistent with the RFP's broader Proven Capability framework.

16

§31.1 Acceptance; Draft SLA §5, pp. 230 onward

Since Operational Acceptance depends on the integrated operation of compute, storage, network, orchestration, software and management layers, will IGNITE and the Successful Bidder jointly finalize an end-to-end Acceptance Test Plan during detailed design, defining workload profiles, benchmarks, test conditions and measurable pass/fail criteria before deployment?

Ensures the entire ecosystem is accepted based on agreed end-to-end outcomes rather than isolated component specifications.

Yes. The Successful Bidder must provide a phased acceptance plan for the Company's approval, mapping each acceptance milestone to measurable criteria, to be finalised jointly during detailed design.

17

End-to-End Capacity / Sizing

Are the capacities stated in the RFP intended as fixed minimum Day-1 capacities, or should bidders perform end-to-end sizing and may propose higher capacities where necessary to ensure that compute, GPU, storage, network and platform layers operate as a balanced solution?

Prevents us from treating individual minimum specifications as independently sized components.

The stated capacities are binding Day-1 minimums, not fixed specifications; bidders are expected to perform their own end-to-end sizing and may propose higher capacities for a balanced solution.

18

Technology / OEM Interoperability

Does IGNITE expect bidders to propose a best-of-breed multi-vendor architecture where appropriate, provided end-to-end interoperability and single-point accountability are demonstrated, or is preference given to a more tightly integrated OEM ecosystem?

Very important for deciding NVIDIA/compute/storage/network/platform vendor strategy and consortium structure. The RFP already emphasizes interoperability and support accountability in areas such as storage.

The RFP is vendor- and technology-neutral and permits a best-of-breed approach; no preference for a single, tightly integrated OEM ecosystem is stated.

19

Management & Control Infrastructure

Should management, control-plane and platform-support services be deployed on dedicated infrastructure independent of the AI/GPU workload clusters, and should equivalent management capability also be maintained at DR?

Defines the “brains” of the ecosystem and avoids using expensive GPU resources for management/platform services.

Yes to dedicated infrastructure — the RFP defines a distinct Management & Control-Plane Node Tier, physically separate from the accelerator host tier. the DR site must restore critical services within the stated RPO/RTO. However, the bidder may propose industry best practices with clear evidence.

20

Day-1 vs. Future Expansion

For requirements specifying future scalability or expansion, Kindly clarify which capacities must be physically delivered and licensed at Day-1 versus capabilities that only need to be architecturally supported for future expansion.

This has major implications for BOQ, licensing, facility reservation and commercial pricing.

The infrastructure needs to be interoperable and expandable based on future requirements and plans.

21

Phased Acceptance & Payment

Given the scale and multi-layer nature of the programme, can infrastructure, platform, DR and operational capabilities be commissioned through defined stage-gates with independent acceptance and corresponding commercial/payment milestones rather than making overall acceptance dependent upon completion of the entire ecosystem?

Probably one of the most important questions for partner risk. It limits accumulated delivery and cash-flow exposure.

Yes. The RFP expressly stages acceptance into defined milestones, each mapped to measurable criteria and corresponding payment milestones, which will be finalized in agreement with the successful bidder.

22

Dependency / Third-Party Risk

Where achievement of a project milestone depends upon facilities, connectivity, approvals, data, access, integrations or services to be provided by IGNITE or another nominated stakeholder, how will delays outside the Successful Bidder's control be treated for schedule, SLA and acceptance purposes?

Prevents the prime from absorbing delays it cannot control.

The end-to-end project delivery is the bidder's responsibility. However, where applicable, force majure rule may apply. Furthermore based on responsibility matrix Ignite/MoITT will provide all possible support to facilitate access to relevant data-holding organisations.

23

Technology Evolution / Obsolescence

Given the project duration and rapid evolution of AI technologies, will a formal technology-refresh/change-control mechanism allow equivalent or superior technologies to be introduced during Build and Operate phases without being treated as deviation from the originally accepted solution?

Protects the consortium against accelerator/platform obsolescence during a multi-year programme.

Introducing an equivalent or superior technology is treated as a change requiring Ignite's prior written approval.

24

BOT Risk Boundary

Please clarify the point at which operational responsibility and associated service risk transfer from Build/Implementation into the Managed Operations phase, and subsequently from the Successful Bidder to IGNITE at completion of BOT.

Establishes when each major category of delivery and operational liability begins and ends.

Please refer to section 40. PAYMENT / DISBURSEMENT PLAN of RFP for clarity.

25

A.1.a — Model Requirements: Licensing / Country of Origin

Beyond the Apache 2.0/permissive-license requirement, are there any country-of-origin restrictions on eligible base models (or a list of legally banned models)?

Determines the eligible model catalogue and shapes the model-sourcing strategy given potential geopolitical or export-control considerations.

No country-of-origin restriction is stated; only the licence type is mentioned i.e. Apache 2.0, or an equivalent OSI-approved permissive licence, with no ban list of specific models or origins in the RFP. However, it is advised that any open source model considered should comply with the applicable laws and regulations of Pakistan.

26

A.1.b — Model Requirements: Minimum Parameter Sizes

What are the minimum parameter sizes (e.g., 7B, 70B) required for final delivery?

Directly impacts compute sizing, infrastructure requirements and cost planning for training/inference.

For the sovereign model: minimum 30B parameters (dense or MoE active), with a 70B target. No RFP-wide minimum applies to the ≥20-model open-weight catalogue, which need only "span a range of sizes and capabilities."

27

A.1.c — Model Requirements: Catalogue Selection (≥20 Open-Weight Models)

For the ≥20 open-weight models, does Ignite mandate/pre-approve specific models or is selection fully at bidder discretion subject to license compliance?

Determines the model-selection and evaluation effort required from the bidder and whether a pre-approved shortlist exists.

Selection is at bidder discretion, subject to each model's licence permitting the intended hosted-inference service and the catalogue spanning general, coding, reasoning and multilingual capabilities; However, it is advised that any open source model that is considered should comply with the applicable laws and regulations of Pakistan.

28

A.2.a — Data Collection: Pre-Vetted Datasets

Will Ignite provide pre-vetted government departments and pre-cleared datasets, or is the consortium 100% responsible for data collection and cleaning from scratch including digitizing/OCRing physical government archives?

Fundamental to the scope, cost and schedule of the data-acquisition workstream.

Establishing partnerships and assembling/cleansing the corpora (including any digitisation) is the bidder's scope. Ignite/MoITT will provide all possible support to facilitate access to relevant data-holding organisations.

29

A.2.b — Data Collection: Existing MOUs / Data Partnerships (M7a)

Also please confirm if does Ignite already have MOUs or relationships in progress with entities like Federal and provisional government institute, or ministries that we'd inherit, or is establishing every data partnership from zero the bidder's sole responsibility? Government data-sharing agreements often take 6-12+ months how does that risk get reflected in the milestone schedule (M7a)?

Directly affects schedule risk and the feasibility of data-partnership-dependent milestones.

Data-partnership establishment is bidder-led under Ignite governance as per the applicable laws, regulations, policies etc. such as data governance policy.

30

A.2.c — Data Collection: Digitization/OCR Cost Responsibility (Section 14.2.1)

Who bears the direct cost of digitizing and OCRing physical government archives into machine-readable formats? As this itself a huge separate project (Section 14.2.1).

A major cost and scope driver that needs clear allocation between IGNITE and the bidder.

Ignite/MoITT will provide all possible support to facilitate access to data-holding organisations. However, the optimization of the datasets will be the responsibility of the bidder.

31

A.3.a — Safety/Alignment Authority

“Safety alignment... tuned to the Pakistani legal and cultural context” does Ignite provide a written content-policy/guardrail specification, or is the bidder expected to author it and get sign-off? Who owns liability if the model produces content that violates local law post-launch?

Determines authorship and approval process for the content-safety policy and clarifies post-launch liability allocation.

Safety alignment, content controls, and bias/appropriateness handling tuned to the Pakistani legal and cultural context is the bidders responsibility to ensure the compliance with the applicable guidelines, regulations and laws etc.

32

A.4.a — Language Scope

The ToR says “Urdu, other local and regional languages” which specific languages beyond Urdu are mandatory (Pashto, Punjabi, Sindhi, Balochi?), and is there a minimum performance bar per language, or is Urdu the only hard requirement with others as bonus scoring?

Defines the mandatory language coverage and evaluation criteria, which affects model training and localization effort.

Prime focus on Urdu with other local and regional languages to be proposed by the bidder.

33

B — Infrastructure & Data Centers: DR Site Zoning [Section 48.1]

What are the exact geographic or zone separation requirements for the Disaster Recovery (DR) site [Section 48.1]?

Affects DR site selection, inter-site connectivity design and compliance with the required resilience/zoning criteria.

DR site separated from Primary by sufficient distance to survive a regional event (flood/seismic/grid), while supporting the required replication - bidder states distance and justification in light of industry standards and global best practices.

34

B — Infrastructure & Data Centers: Temporary Hosting [Section 53.1 / 60.4]

Section 53.1: Can temporary third-party hosting (in Pakistan) be used in parallel for early-value public services while primary hardware is being imported (Section 60.4)?

Enables early-value service delivery planning while addressing hardware import lead-time risk.

No.

35

Procurement & Submission — ITB / Delivery

What support will the Government provide for end-user certificates and import licences required to import the AI accelerators and related equipment?

Import licensing and end-user certificate timelines directly affect procurement lead-time and the delivery schedule for AI accelerators. (Must-know)

All possible support will be provided by Ignite/Government for end-user certificates; however, the procurement and import compliance for the infrastructure, including accelerators, storage, networking/interconnects and related equipment etc. sits within the bidder's scope.

36

Consortium & Eligibility — ITB (JV ≤ 5)

The JV/Consortium is capped at 5 members. Please confirm the treatment of a technology / platform sub-contractor engaged by a JV member (permitted alongside the 5 members?).

Determines the permissible consortium structure and whether technology/platform partners count toward the 5-member cap. (Must-know)

Subcontractors engaged by the JV/Consortium would not be counted as part of the JV/Consortium members (capped at 5). It may be noted that a subcontractor or vendor not formally declared as a Consortium/JV partner does not qualify as a reference source — except where the subcontractor is an OEM formally engaged by the Lead Bidder under a formal OEM support/vendor agreement. Furthermore, clause 4.10 of the RFP may also be referred (page 6 of 254)

37

Facility / Colocation — Form B3 · CTX-2

Will IGNITE nominate the Tier-III colocation facility, or is it to be arranged within the bidder's scope?

Affects facility selection, cost baseline and delivery timeline for the colocation workstream. (Must-know)

Arranging the colocation facility (Primary and DR) is within the bidder's scope; Form B3 requires the bidder to substantiate its own facility with certificates and SLAs.

38

Cross-Cutting – Technology Neutrality, Equivalence & Performance Evaluation

Where the RFP specifies functional/performance requirements rather than a named technology, will solutions based on different accelerator ecosystems be evaluated against the same workload-level benchmarks and acceptance methodology, irrespective of OEM or underlying accelerator architecture?

Require NVIDIA, Huawei, AMD, etc. onto the same measurable benchmark rather than architecture-specific claims.

Requirements throughout Layer 1 are stated as quantified, workload-level outcomes evaluated identically regardless of OEM or accelerator architecture, provided the thresholds are met and substantiated by manufacturer documentation.

39

Cross-Cutting – Technology Neutrality, Equivalence & Performance Evaluation

For any requirement that can only be satisfied through an OEM-specific/proprietary implementation, will functionally equivalent standards-based implementations from other OEM ecosystems be accepted where the bidder demonstrates equal or superior end-to-end performance and functionality?

Prevents feature from becoming a de-facto qualification barrier.

Yes — the RFP is stated to be technology- and vendor-neutral, accepting any architecture or implementation meeting the stated outcome as per the requirements in the RFP

40

Cross-Cutting – Technology Neutrality, Equivalence & Performance Evaluation

Will IGNITE confirm that no particular accelerator architecture, proprietary software framework, interconnect protocol, storage technology or OEM-specific implementation is mandatory unless explicitly identified as such in the RFP?

Gets technology neutrality formally on record.

Confirmed as a general principle — no accelerator architecture, proprietary framework, interconnect, storage technology, or OEM-specific implementation is mandated.

41

Cross-Cutting – Technology Neutrality, Equivalence & Performance Evaluation

Where compliance depends upon integration between accelerator, fabric, storage, orchestration and AI platform layers, will IGNITE assess compliance on the demonstrated end-to-end functional/performance outcome rather than requiring all layers to originate from a single OEM ecosystem?

Protects a best-of-breed architecture against a vertically integrated competitor.

Consistent with the RFP's stated approach, compliance is assessed on the demonstrated end-to-end functional/performance outcome; no clause requires all layers to originate from a single OEM ecosystem as long as the requirements in the RFP are met.

42

Cross-Cutting – Technology Neutrality, Equivalence & Performance Evaluation

For technical evaluation and acceptance, will equivalent or superior technologies receive equal consideration where they meet the stated functional, performance, sovereignty and SLA requirements, even if their implementation architecture differs from any reference architecture considered during preparation of the RFP?

Addresses possibility of different reference/pre-engineered architecture

Consistent with the RFP's outcome-based, vendor-neutral drafting, an equivalent or superior technology meeting the stated functional, performance, sovereignty and SLA requirements would be evaluated on that basis; no clause privileges a specific reference architecture.

43

Cross-Cutting – Technology Neutrality, Equivalence & Performance Evaluation

If any specification, benchmark, terminology or architectural requirement is subsequently found to correspond predominantly to a particular OEM implementation, will IGNITE permit bidders to demonstrate technical equivalence through an alternative architecture and agreed benchmark methodology?

Creates an escape route if we later discover OEM-specific requirements.

Consistent with the RFP's stated technology-neutral basis (any architecture meeting the outcome, evidenced by manufacturer documentation) as long as the RFP requirements are met.

44

Cross-Cutting – Technology Neutrality, Equivalence & Performance Evaluation

For accelerator sizing, will IGNITE evaluate the proposed solution based on application/workload outcomes such as model size, training/fine-tuning performance, inference throughput, latency and concurrency rather than comparing theoretical accelerator PFLOPS alone?

Very important against potentially misleading NPU-vs-GPU theoretical compute comparisons.

The Layer 1 thresholds are already framed as workload-level outcomes (training/inference throughput, memory bandwidth, interconnect latency, etc.) consistent with evaluating on delivered performance rather than theoretical peak compute alone, as well as ensuring the thresholds are met and substantiated by manufacturer documentation. Ignite may carry out evaluation of the infrastructure at any point in time.

45

Cross-Cutting – Technology Sovereignty & Vendor Independence

For the National AI Ecosystem, how does IGNITE define the required level of technology sovereignty? Should sovereignty cover only in-country hosting and operational control, or also data, infrastructure, AI platform, foundation models, software licensing, technology lifecycle, and the ability to operate independently of foreign technology providers?

Establishes what “sovereignty” means for solution architecture and BOT.

The focus should be on the requirements of the RFP.

46

Cross-Cutting – Technology Sovereignty & Vendor Independence

Does IGNITE expect the same level of sovereignty across all technology layers, or may different levels apply to accelerator infrastructure, storage/networking, orchestration, AI platform, foundation models, and applications?

Enables a practical sovereignty architecture instead of treating sovereignty as a single requirement.

The stated sovereignty principles (ownership, no lock-in, no kill-switch, IP assignment for the sovereign model) are expressed as applying across the Ecosystem rather than tiered by layer. Please refer to form B12 – SOVEREIGNTY & SUPPLY-CHAIN ASSURANCE.

47

Cross-Cutting – Technology Sovereignty & Vendor Independence

Considering long-term sovereignty, supply-chain continuity, and technology availability, does IGNITE have any preference or policy direction regarding the accelerator ecosystem (e.g., NVIDIA, Huawei, AMD, or equivalent), or should bidders propose the most appropriate ecosystem based on performance, interoperability, commercial viability, and long-term sustainability?

Accelerator selection can create long-term technology and ecosystem dependencies extending beyond hardware.

The bidders are expected to propose the most appropriate ecosystem based on performance, interoperability, and sustainability, consistent with the RFP's requirement.

48

Cross-Cutting – Technology Sovereignty & Vendor Independence

Where proprietary technologies are proposed, what level of dependency on foreign OEMs for licensing, subscriptions, firmware/software updates, technical support, and future expansion would IGNITE consider acceptable within a sovereign national AI platform?

Clarifies the acceptable level of external technology dependency.

Please refer to the section 24.2 GUIDING PRINCIPLES.

49

Cross-Cutting – Technology Sovereignty & Vendor Independence

For foundation models, what capabilities must remain under local/customer control for a model to be considered “sovereign”—for example, model weights, local inference, fine-tuning, derived models, deployment, lifecycle management, and the ability to continue operating without dependency on the original model provider?

Defines model sovereignty, which may otherwise be interpreted differently by different bidders.

For the sovereign model specifically, "sovereign" requires full IP assignment (not licence) of weights, in-country ownership of the training corpus, full control of deployment infrastructure, and unrestricted rights to maintain, extend, redistribute and rebrand independently of the original developer, in perpetuity.

50

Cross-Cutting – Technology Sovereignty & Vendor Independence

Where AI platform or model technologies are provided by international technology partners, does IGNITE require these technologies to remain independently deployable, manageable, and supportable by the local operating organization after BOT transfer?

Determines the required level of platform independence at Transfer.

Yes, the Anti-Lock-In and platform-handover provisions require the platform to remain fully operable by the in-country team without bidder/vendor dependency, and Final Operational Handover must confirm independent operability with no residual dependency.

51

Cross-Cutting – Technology Sovereignty & Vendor Independence

Where technically feasible, does IGNITE expect preference for open standards and open-source technologies to reduce long-term vendor dependency, or are proprietary technologies equally acceptable where interoperability, portability, and an appropriate exit mechanism are demonstrated?

Establishes the overall technology-selection philosophy.

The RFP's default posture is technology-neutral and outcome-based, accepting proprietary technologies equally provided interoperability, portability, and an appropriate exit mechanism are demonstrated; no blanket preference for open-source over proprietary is stated.

52

BOT Details

At completion of the BOT period, what level of independent operational capability must be transferred to IGNITE: infrastructure operations only, or end-to-end capability covering accelerator infrastructure, storage/networking, orchestration, AI platform, MLOps, inference, models, security, and observability?

Defines what “Transfer” means technically and operationally.

End-to-end capability.

53

BOT Details

After BOT transfer, is continued OEM/specialist-partner support acceptable for advanced technologies, or is the objective for IGNITE/local resources to independently operate and evolve the ecosystem except for conventional OEM support?

Establishes the acceptable residual technology dependency after BOT.

Continued conventional OEM/warranty support is acceptable and expected (e.g., back-to-back OEM warranty support is a stated obligation);

54

BOT Details

Does IGNITE expect the bidder to establish and progressively develop a dedicated local technical organization during the BOT period capable of operating and supporting the complete ecosystem, including specialist AI platform and model technologies?

Directly affects manpower, skills development, training, OPEX, and the BOT operating model.

Please refer to the section of the RFP 26.2.7 Knowledge Transfer, Skilling & Ecosystem Capability Building, as well as Form B10 which requires the bidder to propose a capacity-building methodology, with a declining-dependency schedule and measurable handover-readiness criteria, evaluated as part of the technical proposal.

55

BOT Details

Considering that the solution may involve multiple OEMs and specialist technology partners, what L1, L2 and L3 support, escalation, upgrade, and lifecycle-management model does IGNITE expect during the Managed Operations period? Specifically, should specialist technology partners remain responsible for L3 support of their respective domains while the Prime Bidder maintains overall service accountability?

Defines post-Build support responsibilities and avoids gaps between Prime Bidder, OEMs, and specialist partners.

The RFP requires the bidder to propose the L1/L2/L3 escalation model (Form B9-3); the proposed division (with specialist partners retaining domain L3 support while the Prime Bidder holds overall accountability) (clause 29.1 of the RFP).

56

BOT Details

Please clarify the formal BOT acceptance framework separately for the Build, Operate, and Transfer phases. What key deliverables, performance criteria, operational-readiness requirements, knowledge/capability-transfer requirements, and acceptance milestones will determine successful completion of each phase?

Establishes measurable acceptance criteria across the complete BOT lifecycle rather than treating BOT as a single final handover.

The RFP's own framework is Delivery Acceptance → Operational Acceptance → Sovereign-Model Acceptance → Final Operational Handover, each mapped to measurable criteria and payment milestones via a bidder-proposed phased acceptance plan or as agreed upon during the contract signing;

57

BOT Details

Where critical AI/platform capabilities are initially designed or implemented with support from international technology partners, does IGNITE require such specialist technical capability/support to remain available throughout the Managed Operations period, or is progressive localization and transfer to the bidder's in-country team considered sufficient?

clarifies whether long-term specialist support must remain embedded throughout Managed Operations or whether progressive localization is an acceptable BOT outcome, directly affecting operating model, manpower, support commitments and capability-transfer planning

Progressive localisation model is the expected model. .

58

BOT Details

Considering the BOT nature of the programme, does IGNITE expect the Prime Bidder to maintain complete technical visibility, administrative control and operational ownership of all major technology layers from Day-1, even where individual layers are designed or implemented by specialist OEM/technology partners?

Ensures that operational control of the National AI Ecosystem remains with the accountable operating entity rather than becoming dependent on individual technology providers.

Yes.

59

BOT Details

During Build, does IGNITE expect the Prime Bidder's local technical resources to participate directly in architecture, implementation, configuration, integration and testing rather than receiving the environment only after implementation is completed?

Develops in-country capability from the beginning and preserves technical knowledge of how the ecosystem has been designed, configured and integrated.

It is not a requirement but it is recommended that the lead bidder’s resources be engaged in such steps.

60

BOT Details

Will Operational Acceptance require demonstration that the Prime Bidder/local operating team can independently perform agreed day-to-day administration, monitoring, troubleshooting, backup/recovery and operational procedures for the deployed ecosystem?

Ensures that successful implementation results in a genuinely operable national platform rather than only technically commissioned infrastructure.

No.

61

BOT Details

For specialist technologies requiring OEM/vendor L3 expertise, should the operating model clearly distinguish capabilities expected to reside with the local operating team from those legitimately remaining with OEM L3 support?

Establishes a sustainable support model while ensuring that routine and critical operational knowledge is retained locally and specialist OEM dependency is clearly controlled.

Yes — this distinction is exactly what Form B9-3 requires the bidder to define (the L1/L2/L3 escalation model), evaluated as part of the technical proposal. But the responsible entity will be the lead bidder.

62

BOT Details

Does IGNITE expect complete architecture documentation, configurations, runbooks, SOPs, integration details, dependency maps and troubleshooting/escalation procedures to remain under the control of the Prime Bidder throughout the BOT period?

Preserves institutional knowledge and ensures continuity of operations despite changes in personnel, OEMs or specialist technology partners during the programme.

Yes.

63

BOT Details

Should successful transition from Build to Managed Operations be subject to a formal Operational Readiness Assessment demonstrating that the operating organization has the required people, access, documentation, tools and competency before assuming operational responsibility?

Provides IGNITE with an objective assurance that the ecosystem is not only technically complete but also operationally ready before entering the Managed Operations phase.

Operational Acceptance (demonstrating the integrated services meet stated criteria) functions will be evaluated before Complete Operationalisation and the Managed Operations Term begin. The responsible entity will be the lead bidder with defined roles of consortium partners (form B11).

64

BOT Details

Where an OEM/specialist technology partner materially reduces or discontinues its project involvement after Build, does IGNITE expect the solution to remain fully supportable through the Prime Bidder's local organization together with formally established OEM escalation/support arrangements?

Protects service continuity and reduces the risk of the National AI Ecosystem becoming dependent on the continued availability of specific external project resources.

It is expected that the consortium be intact throughout the project lifecycle.

65

BOT Details

During Managed Operations, does IGNITE expect periodic assessment of operational independence, knowledge retention and capability localization to ensure that the ecosystem does not remain dependent on individual external/OEM resources?

Allows IGNITE to measure whether genuine national operational capability is being developed progressively during the BOT period rather than only near final handover.

Please refer to sections 32.1 to 32.5 (Draft SLA schedule) as well as sections 33.1 to 33.6 KPIs and Program Indicators)

66

BOT Details

At Transfer, should acceptance include practical capability demonstration by the receiving team—covering operations, administration, troubleshooting, recovery and lifecycle activities—in addition to transfer of infrastructure, documentation and other project assets?

Ensures that BOT concludes with transfer of an operational capability, not merely transfer of physical infrastructure and documentation.

Yes — Final Operational Handover must be certified against defined criteria confirming the Company or successor can operate the Ecosystem independently, which implies practical capability demonstration, not just asset/documentation transfer.

67

BOT Details

Does IGNITE expect the approved architecture, configurations, administrative access model, operational documentation and knowledge artefacts to remain under programme governance throughout BOT so that replacement or change of any specialist technology partner does not compromise continuity of operations?

Protects IGNITE against technology-partner dependency and ensures that the programme can continue even if individual ecosystem participants change during its lifecycle.

Yes.

68

BOT Details

Does IGNITE expect the BOT model to progressively reduce dependency on external/OEM specialist resources through measurable localization and capability-transfer milestones, so that the ecosystem reaches the Transfer stage with sustainable in-country technical and operational capability?

Ensures that the strategic outcome of BOT is the creation of a sustainable national AI capability, rather than long-term dependence on external technology resources.

Yes.

69

BOT Details

Does IGNITE expect the Build → Operate → Transfer transition to be governed through formally defined responsibility and capability-transfer milestones, including operational readiness, knowledge transfer, competency validation and formal handover?

Establishes whether a lifecycle RACI/RBM is an expected formal governance artefact.

Yes.

70

BOT Details

Where operational responsibility transitions during the BOT lifecycle, does IGNITE expect formal capability-readiness gates covering documentation, training, shadow operations, competency validation and operational handover before the responsibility is considered successfully transferred?

Defines how Build → Operate → Transfer capability should be demonstrated.

Consistent with the RFP's requirements - requires bidders to propose shadowing/joint-operations, a declining-dependency schedule, and measurable handover-readiness criteria;

71

BOT Details

Should the approved Responsibility Matrix and capability-transfer plan form part of the project governance and acceptance baseline throughout the BOT period, with responsibilities and handover milestones tracked as formal project deliverables?

Makes responsibility and capability transfer measurable rather than simply an internal consortium arrangement.

The RACI/responsibility matrix (TOR 29.1), the bidder's capacity-building/handover plan (Form B10), as well as form B11-4 are all part of the accepted technical proposal, tracked through the phased acceptance plan and governance.

72

Sovereign Model & Data — LLM-4

Will IGNITE provide and curate the Urdu and local-context datasets (with the necessary rights and clearances), or is data collection within the bidder's scope?

Fundamental to the scope, cost and schedule of the data-acquisition and model-training workstream. (Must-know)

Assembling, cleansing and curating the Urdu/local-context corpora is the bidder's scope; Ignite/MoITT will provide all possible support to facilitate access to relevant data-holding organisations. .

73

Technical / Scope — MKT-1 / MKT-2

Should the AI marketplace support paid transactions / procurement, or is it catalogue and documentation only?

Defines the marketplace's functional scope, affecting payment-gateway, compliance and development effort. (Nice-to-know)

Section 26.5 LAYER 5: AI MARKETPLACE & ADOPTION ECOSYSTEM may be referred for further details.

74

SLA & Support — Draft SLA

The draft SLA leaves the warranty period blank months) — please confirm the minimum required warranty period.

Required to correctly price and structure the warranty/support commercial offer. (Nice-to-know)

The entire project lifecycle.

75

Data for AI — Model Training

Will Ignite provide all the historical and large-scale datasets required to train the model for Urdu and other languages, including but not limited to audio recordings, videos, documents (PDFs, Word documents, etc.), images, and other relevant data sources?

Determines the extent of data-sourcing effort required from the bidder for model training. (Must-know)

No, Ignite/MoITT will provide all possible support to facilitate access to relevant data-holding organisations.

76

Data for AI — Model Training

How will access to these datasets be provisioned? Will the data be made available through a centralized repository, secure data-sharing platform, APIs, or another controlled access mechanism? Additionally, what governance, security, and usage policies will apply to accessing and utilizing this data for model training?

Clarifies the data-access architecture and governance obligations needed to plan the technical integration. (Nice-to-know)

Ignite/MoITT will provide all possible support to facilitate access to relevant data-holding organisations. Data will be governed through the applicable laws, regulations and policies.

77

BDS Cl. 19 / Evaluation Criteria, p. 27, 30 — Selection Technique (QCBS)

The QCBS Technical marks (1000, passing 750) are specified, but the combined Technical:Financial weightage ratio and scoring formula for arriving at the final ranking are not stated anywhere in the RFP. Kindly confirm the exact weightage split and formula for combining Technical and Financial scores.

Without the scoring formula, bidders cannot model how technical differentiation trades off against price in the final ranking.

The Technical: financial weightage is a 60:40 ratio with the bidder expected to get a minimum of 75% passing marks, i.e. 750/1000 Technical marks.

78

BDS Cl. 14, p. 26 — Bid Security (Acceptable Form)

Only “Pay Order” is listed as an acceptable form of Bid Security. Given the scale of this Contract, may a Bank Guarantee from a scheduled bank also be accepted as an alternative form of Bid Security?

A Pay-Order-only requirement ties up significant working capital at bid stage; confirming Bank Guarantee eligibility affects bid financing strategy.

As issued, no — "Pay Order" is the only acceptable form of Bid Security.

79

BDS Cl. 13 & 15, p. 26 — Bid Security Validity

Bid Validity is specified as 360 days. Kindly confirm that Bid Security validity is accordingly required to be 360 + 28 = 388 days from bid submission, consistent with the worked example in BDS Clause 15.

Bid Security must be procured for the correct validity period; an incorrect duration risks bid rejection or unnecessary extension costs.

Confirmed — BDS Clause 15's stated formula (bid validity + 28 days) applied to the 360-day bid validity in BDS Clause 13 gives a Bid Security validity of 388 days from bid submission.

80

BDS Cl. 20, p. 27 — Performance Guarantee

Performance Guarantee is stated as 0% / Nil. Kindly confirm that no Performance Guarantee will be required from the Successful Bidder post-award, and that this will not be revised during Contract negotiations.

Removes ambiguity on a major post-award financial commitment and protects the commercial offer from being revised after award.

Confirmed as issued — BDS Clause 20 and the Special Conditions of Contract both state the Performance Guarantee at 0%, form "Nil." The RFP does not state whether this could be revised during contract negotiations.

81

BDS Cl. 11 & 12 / Form C2, pp. 26, 123 — Fixed Price in PKR / FX Exposure

Bids are required to be fixed-price and denominated in PKR. Major CAPEX items (A1 AI Compute Hardware, A2 Networking & Interconnect, A3 Storage Systems) are import-dependent and typically OEM-priced in USD. Kindly clarify whether any exchange-rate adjustment or price-variation mechanism is permissible between bid submission and actual import/delivery, given the fixed PKR pricing requirement over a multi-year OPEX term (up to 36 months).

FX exposure on USD-denominated import-dependent CAPEX under a fixed PKR bid is a material pricing and risk-allocation issue over a multi-year term.

No.

82

Form C2, p. 123 — Import Duties & Customs

Kindly clarify whether import duties, customs clearance charges, and L/C/bank charges on imported AI hardware are to be included within the CAPEX price (Form C2, Item A1–A3), or will be reimbursed separately by the Procuring Agency / Ignite.

Determines whether these charges must be embedded in the CAPEX price or billed separately, affecting BOQ structuring and pricing accuracy.

C1 states the Financial Proposal is inclusive of "all local taxes, duties, fees, levies and other charges"; no separate reimbursement mechanism is stated.

83

Form C1, p. 122 — Taxes: Scope of “Inclusive of All Taxes”

Form C1 states the Financial Proposal is inclusive of “all local taxes, duties, fees, levies and other charges.” Kindly confirm the treatment of Sales Tax/GST on imported hardware versus locally rendered services, and confirm the withholding-tax deduction mechanism applicable to invoiced payments.

Tax treatment materially affects net pricing and cash flow; clarity is needed to price correctly and plan invoicing/withholding compliance.

All quoted prices should be inclusive of all applicable taxes

84

GC Cl. F, p. 53 — Payment Terms / Schedule

GC Clause F states payment will be made against “actual invoice or running bills... within the time given in the conditions of the contract,” but no defined payment milestone schedule is set out against the CAPEX/OPEX heads in Form C2. Kindly confirm whether a defined payment milestone schedule (e.g., % on commissioning, % on go-live, monthly OPEX billing) will be issued, and whether any mobilization/advance payment is permissible against CAPEX procurement.

A defined milestone schedule and advance-payment position are essential for cash-flow planning and financing of upfront CAPEX procurement.

Please refer to section 40. PAYMENT / DISBURSEMENT PLAN, which outlines the proposed payment plan which will be finalized in agreement with the successful bidder.

85

Form C2, Item B11–B12, p. 123 — Management Fee & OPEX Contingency Caps

Form C2 caps the Management Fee at “not to exceed 20% of annual OPEX” (B11) and OPEX Contingency at a maximum of 5% (B12). Kindly clarify the exact base for the 20% Management Fee calculation — i.e., whether it is computed on gross annual OPEX or net of contingency and insurance line items.

The calculation base changes the effective fee amount; needed to price the Management Fee line accurately within the cap.

Baseline is the annual OPEX.

86

GC Cl. 20, p. 53 — Liquidated Damages: Basis of Calculation

GC Clause 20 sets Liquidated Damages at 0.00%–1.00% “of the Contract value” for service failures, data-loss/breach incidents, or other failures. Kindly define “Contract value” for this purpose — i.e., whether it refers to the total Grand Total of the Financial Proposal (CAPEX + OPEX), or the value of the specific deliverable/service found in breach — and confirm whether an aggregate cap on total LDs applies.

The LD exposure basis and any aggregate cap are material risk factors that must be quantified before commercial commitment.

Grand Total of the Financial Proposal (CAPEX + OPEX).

87

Annexure AC, p. 72 — Financing Capacity: JV Basis

Annexure AC requires the lead bidder to demonstrate a minimum net worth of PKR 500 million (or an equivalent AA+/AAA credit line) before technical evaluation proceeds. Where a bid is submitted as a JV/Consortium (permitted up to 5 members per BDS Clause 3), kindly confirm whether this financing-capacity threshold must be met by the lead bidder alone, or may be demonstrated cumulatively/severally across JV members.

Determines eligibility of the proposed consortium structure and whether financial capacity can be pooled across JV members.

The lead bidder alone.

88

Eligibility Criteria (JV/Consortium), pp. 5, 28 — OEM Participation as JV Member

Kindly confirm whether an OEM / technology partner may participate as a named JV/Consortium member for commercial purposes (pricing, liability, invoicing), or whether OEMs may only feature as subcontractors / reference sources under Form B4 (Proven Capability & Delivery Track Record).

Affects consortium structuring, liability allocation and invoicing arrangements with OEM/technology partners.

OEM/technology partner may participate as a subcontractor/ reference source, where the OEM's reference will be counted only where the OEM is engaged by the Lead Bidder under a formal OEM support/vendor agreement covering the specific aspects being referenced, contractually binding the OEM to the bid in a supporting-vendor capacity to fulfill the requirements of the RFP.

89

Form C2, Item B9, p. 123 — Insurance: Minimum Coverage Standard

Form C2 lists Equipment, Transit, and Operational Risk Insurance (B9) as an OPEX cost item, but no minimum insured value or coverage standard is specified. Kindly confirm whether a minimum insured value/coverage benchmark will be prescribed, or whether this is left entirely to the bidder's proposal.

Without a minimum benchmark, insurance costs cannot be reliably estimated or compared across bidders.

This is left to the bidder's proposal.

90

Section 31.9, p. 183 — Exit / Anti-Lock-In: Cost-Based Exit Fees

Section 31.9 (Commercial Protection & Anti-Lock-In) requires that any exit-related charges be “limited to fair, pre-agreed, cost-based amounts stated in the contract,” with no punitive exit fees. Kindly confirm whether the cost-based exit-fee schedule will be pre-agreed and benchmarked at Contract signing or negotiated only at the time of exit/handover.

Determines whether exit-cost exposure is fixed and known at signing or remains an open negotiation risk at contract end.

This will be pre-agreed and benchmarked at Contract signing.

Ref

Topic / Reference

Question

Reason for Asking

Ignite's Response

Q-SW-01

Architecture

RFP Ref: 26.2.1 / B12

Is the production environment intended to operate permanently air-gapped, or must it merely be capable of air-gapped operation while normally connected?

This is the single largest architectural determinant in the bid. It changes patching, model updates, marketplace connectivity, telemetry and support entirely.

The Solution shall provide air-gapped operability; the bidder proposes the zoning architecture reconciling this with public-facing services, for Company approval. RFP Ref: TOR Clause 26.2.1, Item 14 (p.145).

Q-SW-02

Architecture

RFP Ref: 26.2.5 / 26.5 / 27.1

The tiered inference service, marketplace and investor matchmaking capability are inherently internet-facing. Please confirm the intended network zoning between the sovereign air-gapped domain and public-facing services.

These two requirements appear to conflict. We cannot design the security architecture without a ruling.

Network zoning between the sovereign domain and public-facing services is proposed by the bidder as part of the security architecture. RFP Ref: TOR Clause 26.2.1 (p.145); Clause 26.2.5 (p.160); Clause 27.1 (p.170).

Q-SW-03

Licensing

RFP Ref: 26.2.1 / B12

Clause 27 and Form B12 require no licence check-in or remote enforcement, while clause 26.2.1 requires vendor enterprise support. Is commercially licensed software with offline entitlement acceptable?

Most enterprise AI software entitlement models involve some form of licence validation. A strict reading would force us to open-source-only components.

Yes — offline-entitlement commercial licensing is acceptable; only foreign-controlled remote disablement is prohibited. (no vendor lock-in) RFP Ref: Draft SLA Clause 18.7 (p.239); TOR Clause 31.9, Item 7 (p.187).

Q-SW-04

Sovereign model

RFP Ref: B4 #2 / 26.2.4

Form B4 criterion 2 requires a reference for a production model of 100 billion parameters or more, while the programme target at clause 26.2.4 is 70 billion. Will references at 70 billion or above qualify for full marks?

Twenty all-or-nothing marks, and the criterion largely determines which partner must lead our model workstream.

No — the ≥100B reference threshold under Form B4 is a distinct track-record criterion, scored as stated, separate from the 70B delivery target. RFP Ref: Form B4, Item 2 (p.34); Form B6, Key Definitions (p.101).

Q-SW-05

Sovereign model

RFP Ref: 26.2.4

Is the 70 billion parameter figure a binding requirement or an indicative target? Would a smaller model demonstrating superior Urdu performance be acceptable?

Model scale drives training compute, schedule and cost. A smaller, better model may serve the objective more cheaply.

Binding — 70B parameters is the stated target model scale starting at a minumum 30B (dense equivalent or MoE active parameters) RFP Ref: Form B6, Key Definitions — "LLM" (p.101).

Q-SW-06

Sovereign model

RFP Ref: 26.2.4

Please confirm whether community licences that are permissive in practice but not Apache 2.0, such as the Llama community licence, satisfy the base-model licensing requirement.

Restricting to strictly Apache-2.0 base models materially narrows the achievable quality ceiling for the national model.

Apache 2.0, or an equivalent OSI-approved permissive licence, with no ban list of specific models or origins in the RFP. However, it is advised that any open source model considered should comply with the applicable laws and regulations of Pakistan.

Q-SW-07

Sovereign model

RFP Ref: 26.2.4 / 31.1

Is there a defined benchmark suite and target score against which sovereign-model acceptance will be judged, or does the bidder propose the evaluation framework?

Measured uplift without a defined target is an open-ended acceptance obligation attached to a payment milestone.

As long as the defined RFP targets are met, the evaluation framework and target uplift are proposed by the bidder. RFP Ref: TOR Clause 26.2.4(iii), Item 3.2 (p.159); Draft SLA Clause 5.3.3 (p.235).

Q-SW-08

Training data

RFP Ref: 26.2.4

Does Ignite hold, or has it secured, any Urdu or local-language corpora and data-sharing agreements, or must the supplier source, licence and clear all training data?

Corpus acquisition at national scale is a major cost and schedule item that is currently entirely unquantified.

Sourcing, licensing and clearing training data is the bidder's scope; Ignite will provide all possible supportto access relevant data-holding organisations. RFP Ref: TOR Clause 26.2.3(ii), Items 2.1–2.2 (p.159).

Q-SW-09

Training data

RFP Ref: 26.2.4 / 39

Where corpora are licensed from third parties, how is the requirement for full assignment of datasets to Ignite to be satisfied, given such rights are typically non-assignable?

We cannot assign what we do not own. Without a ruling this requirement may be impossible to meet as written.

Ownership/assignment terms for third-party-licensed corpora are proposed by the bidder within its data-partnership framework, to be governed by the applicable laws, regulations and policies of Pakistan. RFP Ref: TOR Clause 26.2.3(ii), Item 2.4 (p.159).

Q-SW-10

Training data

RFP Ref: 26.2.4 / 26.1.1

What accelerator-hour envelope does Ignite anticipate for sovereign-model training, and is that to be met from the 64-accelerator cluster alongside production inference workloads?

Determines whether the specified cluster is adequately sized for both training and service delivery, or whether we must bid more.

Training and inference scheduling across the delivered cluster is proposed by the bidder as part of its sizing methodology. RFP Ref: TOR Clause 26.1.1, Item 1 (p.145); Clause 26.2.4 (p.159).

Q-SW-11

Sovereign model

RFP Ref: 26.2.4

Is a single model required, or a family comprising base, instruction-tuned and domain-specific variants?

Materially changes the training compute budget and the delivery schedule.

A single sovereign model at the 70B target is required. RFP Ref: Form B6, Key Definitions (p.101).

Q-SW-12

Inference service

RFP Ref: 26.2.5

Does Ignite require particular models among the 20 open-weight models to be offered, or is selection at the supplier's discretion subject to approval?

Certain models carry licensing or export restrictions that would need to be assessed before commitment.

Selection is at bidder discretion, subject to each model's licence permitting the intended hosted-inference service and the catalogue spanning general, coding, reasoning and multilingual capabilities; However it is advised that any open source model that is considered should comply with the applicable laws and regulations of Pakistan.

Q-SW-13

Inference service

RFP Ref: 26.2.5

What concurrent user volumes, request rates or token throughput should the tiered inference service be sized for at launch and at Year 3?

Without a demand assumption the inference tier cannot be sized or priced, and the subsidised access model cannot be costed.

Sizing for concurrent users, request rates and throughput is proposed by the bidder. Please refer to form B9 as well.

Q-SW-14

Marketplace

RFP Ref: 26.5

May a proven commercial or open-source marketplace platform be configured to meet the requirement, or must the marketplace be purpose-built for NAIIH?

Build-from-scratch versus configure is one of the largest cost and schedule differences in the whole bid.

Either approach is acceptable, provided there is no vendor lock-in and the requirements in the RFP (particularly section 26.5) are met.

Q-SW-15

Intellectual property

RFP Ref: 38 / 39

Will Ignite accept that the supplier's pre-existing tools, frameworks and platform components are licensed perpetually and irrevocably to Ignite rather than assigned, with assignment applying to bespoke sovereign artefacts?

Without a background IP carve-out we cannot deploy any pre-existing product, which materially raises both cost and delivery risk.

Embedded third-party components are licensed to the Company in perpetuity; bespoke Developed IPR is assigned.

Q-SW-16

Intellectual property

RFP Ref: 39

How is the requirement that all IP vests exclusively with Ignite to be reconciled with embedded OEM software and open-source components, whose ownership cannot be assigned?

As written the clause cannot be complied with. We need the intended scope before we can accept the term.

Embedded third-party components are licensed to the Company in perpetuity; bespoke Developed IPR is assigned.

Q-SW-17

Marketplace

RFP Ref: 26.5.4

Who is merchant of record for marketplace transactions, is PCI-DSS scope anticipated, and is integration with local payment rails such as Raast or 1LINK required?

Payment scope changes compliance obligations, cost and whether an additional partner is required.

The standard features for the marketplace should be there which include but not limited to, payment and compliance model, including merchant-of-record and payment-rail integration, to be proposed by the bidder. Regarding the merchant-of-record, given the requirements in the RFP and dynamics of the project the bidder can propose different models.

Q-SW-18

Marketplace

RFP Ref: 26.5.4 / 31.10

Who operates collection and disbursement of the developer revenue share, and does the supplier bear payment processing costs?

Affects both the operating cost base and our exposure to transaction risk over three years.

Reference above, this will be based on the options proposed by the bidder. Operation of revenue-share collection/disbursement and associated costs are proposed by the bidder within its commercialisation model.

Q-SW-19

Marketplace

RFP Ref: 26.5.8

Is the investor connection capability intended as an introduction and directory function only, or does Ignite anticipate any regulated activity requiring SECP licensing?

A regulated interpretation would require a licensed partner and change the delivery model.

Investor Connection is a discovery/matching capability under Company governance; the bidder assesses and proposes any regulatory positioning required. RFP Ref: TOR Clause 26.5.8 (p.167).

Q-SW-20

Integration

RFP Ref: 26.3.4

Which national and enterprise identity providers must the platform federate with, for example NADRA, HEC or PSEB, and are integration specifications and test environments available?

National identity integration is rarely straightforward and needs early technical access to be deliverable within the schedule.

Identity-federation partners and integration approach are proposed by the bidder, with Company coordination on access. This may vary sector to sector.

Q-SW-21

Integration

RFP Ref: 27.4

Is there an existing Ignite or MoITT system landscape, such as identity, finance or existing portals, that the platform must integrate with?

Undisclosed integration scope is a common source of overrun. It is not described anywhere in the RFP.

Integration scope with existing Ignite/MoITT systems is confirmed at detailed design; the bidder proposes the integration architecture to be flexible enough to allow for integrations with existing and upcoming portals/ applications etc.

Q-SW-22

Governance

RFP Ref: 27.2

Will Ignite provide the government data classification taxonomy and residency rules to be implemented, or is the supplier to propose them?

Determines whether we are implementing a defined standard or authoring one, which is a very different effort.

Th bidder proposes the data-classification and residency framework. Ignite/MoITT will provide all possible support to facilitate access to relevant data-holding organisations. Data will be governed through the applicable laws, regulations and policies.

Q-SW-23

Compliance

RFP Ref: 27.2

Which Pakistani data protection and cybersecurity instruments should the design comply with, and how should the draft Personal Data Protection Bill be treated if enacted during the term?

A regulatory change mid-term is a scope and cost risk under a fixed price with no adjustment mechanism.

Compliance mapping to applicable Pakistani law and standards (including but not limited to sectoral regulations), including regulatory change during the term, is proposed by the bidder.

Q-SW-24

Applications

RFP Ref: 26.5 / 26.2.7

Must the portal and marketplace user interfaces be delivered in Urdu as well as English, and to which accessibility standard?

Full bilingual delivery including right-to-left layout is a significant additional build and testing effort.

UI language and accessibility approach are proposed by the bidder as part of the portal/marketplace design. However, the system should comply with global accessability standards and should have support for English and Urdu languages.

Q-SW-25

Portability

RFP Ref: 27.5 / B7b

Clause 27.5 requires substitutability above the kernel layer. Will Ignite accept vendor-optimised libraries where a documented open fallback exists, and how is that treated in Form B7 scoring?

A strict interpretation would exclude the optimised libraries that deliver most of the performance we would be bidding.

Yes — vendor-optimised libraries are acceptable where a documented open fallback exists.

Q-SW-26

Platform

RFP Ref: 26.2.1

Must every accelerator support at least four concurrent isolated workloads simultaneously in production, or is this a capability requirement to be demonstrated?

Affects the partitioning design and the achievable utilisation model across the four beneficiary tiers.

Yes — a binding minimum of 4 isolated workloads per accelerator.

Q-SW-27

Analytics

RFP Ref: 26.6.2

Does Ignite have a defined economic and sectoral impact measurement methodology to be implemented, or is the supplier to propose the framework?

Impact measurement is a scored deliverable but the methodology is undefined, making the effort unbounded.

The bidder proposes the impact-measurement methodology for Company approval.

Q-SW-28

Handover

RFP Ref: 31.8 / 39

At Final Handover, does Ignite expect source code for all platform components, including any configured commercial products?

Determines whether commercial products can be used at all, and connects directly to the background IP question above.

Yes.

Q-SW-29

Sovereign model

RFP Ref: 26.2.4 iii 3.1 / B6 Key Definitions

The Form B6 Key Definitions state that Apache 2.0 and MIT, or equivalent, are the only base licences acceptable for sovereign redistribution, while Clause 26.2.4 sub-clause iii Ref 3.1 requires a base model under an OSI-approved permissive licence providing an explicit patent grant. The MIT licence contains no express patent grant. Please confirm how these two provisions are to be read together, and whether other OSI-approved permissive licences may be proposed.

Internal contradiction between the definition and the requirement. Replaces Q-SW-06 with a formulation that cannot be answered by restating the licence list.

Apache 2.0, or an equivalent OSI-approved permissive licence, with no ban list of specific models or origins in the RFP. However, it is advised that any open source model considered should comply with the applicable laws and regulations of Pakistan.

Q-SW-30

Intellectual property

RFP Ref: Agreement 14.1 / 14.2 / 14.4

Clause 14.1 of the Draft Agreement vests all intellectual property created in the course of the Project in the Company with immediate assignment upon creation, while Clause 14.4 provides for pre-existing intellectual property to be made available to the Company under a royalty-free, non-exclusive, freely transferable licence in perpetuity. Please confirm

• (a) that Clause 14.4 governs the treatment of the bidder's pre-existing platform components and that Clause 14.1 does not operate to assign them,
• (b) the intended scope of freely transferable and whether it extends beyond transfer to a Government entity or a successor operator for NAIIH purposes, and
• (c) whether improvements to pre-existing products that are not specific to NAIIH fall within Developed IPR.

Replaces Q-SW-15 with a defect-based formulation anchored on the existing Clause 14.4 mechanism rather than requesting a new carve-out. Without a ruling no pre-existing product can be deployed.

The draft agreement will be finalised in consultation with the successful bidder.

Q-SW-31

Sovereign model

RFP Ref: 26.2.4 / B6 Sections B-C

Please specify the expected knowledge and domain coverage of the sovereign model: which subject domains (for example general knowledge, government and public services, law, education, health, agriculture, finance) and which languages (Urdu, regional languages, English) the model must cover, and to what depth. Is a domain priority list defined by Ignite, or does the bidder propose the coverage scope as part of the corpus and fine-tuning plan, to be fixed at contract formation?

Domain coverage drives corpus acquisition cost, evaluation-set design and training compute. Coverage scope is currently undefined yet feeds directly into the Sovereign-Model Acceptance gate, making the obligation unbounded as written.

To be proposed by the bidder aligned with the best practices and bidders experience of implementing similar projects. Prime focus on Urdu with other local and regional languages to be proposed by the bidder.

Q-SW-32

Sovereign model

RFP Ref: 26.2.4 / 31.2 / SLA 5.3.3

Beyond conversational text generation in Urdu and local languages, is the sovereign model required to perform task-oriented capabilities such as instruction following, structured output, function or tool calling, retrieval-augmented workflows, summarisation, translation, or agentic task execution? If so, please state which task capabilities are required and at which phase or milestone each must be demonstrated (initial model delivery, Sovereign-Model Acceptance, or during managed operations).

Task capabilities materially change base-model selection, fine-tuning datasets, the evaluation harness and the delivery schedule. The RFP describes capability only in terms of Urdu/local-context uplift and never states what the model must be able to do.

Task capabilities beyond Urdu/local-context uplift are proposed by the bidder and agreed within the Sovereign-Model Operationalisation Plan.

Q-SW-33

Sovereign model

RFP Ref: 26.2.4 / 31.2 / 33.2-33.3 / SLA 5.3.2-5.3.3

Please confirm the KPIs and baselines for model performance:

• (a) which metrics will constitute the agreed Urdu/local-context capability criteria at Sovereign-Model Acceptance;
• (b) whether the baseline is the un-tuned base model as delivered, and whether a minimum uplift magnitude will be specified;
• (c) whether any in-production model-quality KPIs will apply during managed operations beyond the operational KPIs of Section 33.2; and
• (d) at what point these criteria will be fixed - by addendum, at contract formation, or within the Sovereign-Model Operationalisation Plan.

Complements Q-SW-07. The RFP states the baseline concept (uplift versus the un-tuned base) but not the metric set, the required uplift magnitude, or when the criteria are frozen. Payment and continued SLA-bound engagement under clause 5.3.2 hang on this gate.

Capability criteria and baselines are fixed within the bidder-proposed Sovereign-Model Operationalisation Plan, In consultation with the Company. Please also refer to Section 40 PAYMENT / DISBURSEMENT PLAN which will be finalized in agreement with the successful bidder.

Q-SW-34

Training platform

RFP Ref: B7 A-2 / A-18 / M6 / SLA 5.4

Acceptance testing includes performance benchmarking of training workloads. Will Ignite specify the distributed-training benchmarks and pass thresholds (for example multi-node scaling efficiency, time-to-train on a reference workload, or checkpoint-recovery time under node failure), or is the benchmarking methodology bidder-proposed and fixed at the phased acceptance-plan stage?

Forms B7 (multi-node parallelism, fault tolerance) and B5 (all-reduce efficiency, interconnect latency) imply scaling-efficiency expectations, but no training-side acceptance benchmark or threshold is defined. SAT carries a 10% payment milestone; an unspecified benchmark is a moving target.

Benchmarking methodology and pass thresholds are proposed by the bidder and agreed within the Acceptance Test Plan.

Q-EX-1

Scope of GCC 16.2 (non-compete / disqualification)

RFP Ref: GCC Clause 16.2

We would appreciate the Procuring Agency's guidance on the intended scope of GCC 16.2, which disqualifies the Contractor, its affiliates, subcontractors and their affiliates from providing services for any project resulting from or closely related to the Services. Specifically, whether participation in unrelated future procurements, or services to other clients on their own infrastructure, would fall outside its scope.

—

Yes - unrelated future procurements, or services to other clients on their own infrastructure, would fall outside its scope.

Q-EX-2

Pre-existing intellectual property (Agreement Clause 14.1 / 14.4)

RFP Ref: Draft Agreement Clause 14.1 / 14.4

Whether the licence contemplated in Clause 14.4, described as freely transferable, is intended to support transfer to a Government entity or successor operator for the purposes of the NAIIH programme; whether improvements to such pre-existing products that are not specific to NAIIH are intended to fall within Developed IPR under Clause 14.1; and whether escrow or documented continuity arrangements covering source code, build pipelines and operational documentation would be an acceptable means of securing operational continuity.

—

Confirmed — Clause 14.4 licenses pre-existing IP rather than assigning it; transferability scope and improvement treatment are settled at contract finalisation.

Q-EX-3

Termination under GCC 14.1.5

RFP Ref: GCC Clause 14.1.5

Whether equipment procured or irrevocably ordered, committed facility obligations and demobilisation costs would be reimbursable in that event; the intended duration of continued service under SCC GC 14 and its relationship with Clause 16.6(vii) to (ix); and which remuneration basis at Clause 16.6(vii) to (ix) would apply to continued service in this scenario.

—

Reimbursement and continued-service terms following termination are governed by relevant clauses and settled at contract finalisation.

Q-EX-4

Annual review of the KPI catalogue (Agreement Clause 7(e))

RFP Ref: Agreement Clause 7(e) / 31.7 / 33.1

Confirmation of the process envisaged for the annual review, in particular whether revisions would be agreed through the governance forums of Clause 31.7, and whether revised KPIs would remain confined to matters within the Successful Bidder's control, consistent with Clause 33.1.

—

Annual KPI revisions are managed through Company governance under the relevant clauses.

Ref

Topic / Reference

Question

Reason for Asking

Ignite's Response

1

Retrieval-Augmented Generation (RAG) Scope

The RFP specifies the sovereign fine-tuned model, production inference services, data pipelines, developer environments and integration capabilities; however, it does not expressly state whether Retrieval-Augmented Generation (RAG) is required as a core capability of the sovereign-model service. Please clarify whether the Successful Bidder is required to provide a centrally managed RAG capability as part of the sovereign AI platform, including: - document/data ingestion for retrieval; - chunking and preprocessing; - embedding generation; - vector/index storage; - semantic and/or hybrid retrieval; - retrieval orchestration; and - grounding/citation capabilities. Alternatively, please confirm whether RAG is intended to be implemented independently by individual tenants/developers using the platform's compute, storage and development environments. If a central RAG capability is required, please specify the expected scale, supported data sources and acceptance criteria.

—

RAG is not a named platform requirement; central retrieval capability, if any, is proposed by the bidder as part of the AI software stack and developer environments.

2

External / Live Information Access by the Sovereign Model

Please clarify whether the sovereign-model inference service is expected to access live or external information sources at inference time, including: - Government databases and APIs; - public-sector information systems; - web search; - news/current-information sources; or - other external enterprise data sources. If such live access is required, please clarify the permitted architecture considering the air-gapped/sovereign-operation requirements, including whether access shall be provided through approved gateways, replicated datasets, controlled API intermediaries or another mechanism. If live external retrieval is not required, please confirm that the sovereign model may operate solely on approved locally hosted datasets and that current-information limitations may be documented in the model card.

—

The sovereign model operates on approved, locally hosted datasets; current-information limitations are documented in the model card, consistent with the air-gapped/sovereignty requirements. The system should have the provision to incorporate RAG in the future if and when needed.

3

Corpus Refresh and Sovereign Model Re-Training/Fine-Tuning Cadence

The RFP requires the Successful Bidder during managed operations to continuously maintain the Urdu and local-context data pipelines and support continued/iterative fine-tuning of the sovereign model under Ignite's direction. Please clarify the expected minimum frequency and scope of: a. corpus ingestion and refresh; b. dataset cleansing/re-curation; c. model continued training/fine-tuning/alignment; and d. re-evaluation and production release of updated model versions. Please also specify the events or thresholds that will trigger a model refresh, such as: - availability of material new datasets; - scheduled periodic refresh; - degradation against evaluation benchmarks; - policy/regulatory changes; - model-quality improvement requirements; or - direction from Ignite. Please further confirm whether a defined number of model refresh/fine-tuning cycles per year should be assumed for Financial Proposal purposes, together with the acceptance criteria applicable to each refresh cycle.

—

Corpus refresh and fine-tuning cadence, triggers and release criteria are directed by Ignite during Managed Operations; the bidder proposes an assumed cycle count for Financial Proposal purposes in form C3. Draft Service level agreement (clause 5.3) may also be referred.

4

Corpus Curation and Model Refresh Responsibility After Handover

The RFP requires the Successful Bidder during the managed-operations period to continuously operate and maintain the Urdu/local-context data pipelines and support iterative fine-tuning of the sovereign model under Ignite's direction. Please clarify the intended operating model following completion of the managed-operations period and final handover. Specifically, please confirm whether: a. Ignite's in-country team will assume full responsibility for ongoing corpus acquisition, curation, refresh, model fine-tuning and model release management; or b. continued support from the Successful Bidder will be required after handover under an extension/support arrangement. Where Ignite is expected to assume these functions, please clarify whether the Successful Bidder is required to deliver an automated/self-service corpus-curation and model-refresh pipeline enabling Ignite personnel to independently: - ingest new datasets; - perform cleansing, de-duplication and PII handling; - approve/version datasets; - initiate fine-tuning or continued-training runs; - execute evaluation and safety validation; and - promote approved model versions into production.

—

As part of the bidder responsibility, developing local capabilities is in the scope of the bidder and therefore the trained team assumes full responsibility at Final Operational Handover; the delivered platform, including data-pipeline tooling, must remain fully operable by that team without bidder dependency. However the intended operating model following completion of the managed-operations period and final handover will be decided by Ignite upon the successful handover.

5

Base-Model Licence -- Explicit Patent Grant

The RFP requires the sovereign model to use a base model licensed under Apache 2.0, or an equivalent OSI-approved permissive licence providing an explicit patent grant. Please confirm whether a model released under the standard MIT licence would satisfy this requirement, or whether the underlying licence must contain an express patent-licence provision comparable to Section 3 of Apache License 2.0. This clarification is required to determine the eligible universe of base models before final model selection.

—

Apache 2.0, or an equivalent OSI-approved permissive licence, with no ban list of specific models or origins in the RFP. However, it is advised that any open source model considered should comply with the applicable laws and regulations of Pakistan.

6

Scope of Air-Gapped Operation

The RFP requires core AI infrastructure to support air-gapped/on-premises operation while also requiring the NAIIH Innovation Marketplace to act as a public-facing adoption surface for public-sector, private-sector, startup, researcher and investor users. Please clarify whether the air-gapped requirement applies: a. only to the core compute, training, model, data and orchestration environment; or b. to the Access Portal and Innovation Marketplace as well. If the Marketplace is required to be publicly accessible while its backend services remain within an air-gapped or restricted sovereign environment, please specify the intended security architecture or permitted interface mechanism, such as a controlled DMZ/API gateway, replicated public-facing layer, or other approved architecture. This materially affects whether a single Marketplace deployment is sufficient or separate internal and external-facing deployments are required.

—

The air-gap requirement applies to the core compute, training, model, data and orchestration environment; the bidder proposes the zoning/interface architecture for the public-facing Portal and Marketplace.

7

Patch, CVE and Software/Model Update Mechanism for Air-Gapped Infrastructure

The solution is required to operate in an air-gapped environment while also supporting vulnerability management, security patching and long-term operation. Please clarify the approved mechanism for introducing security patches, CVE remediation packages, container images, software upgrades, firmware updates and approved model updates into the air-gapped environment. In particular, please confirm whether updates are expected to be transferred through: - controlled/removable media; - an approved staging or quarantine environment; - a secure one-way/update gateway; - scheduled maintenance windows; or - another Government-approved process. Please also clarify which party will be responsible for security validation and approval of update packages before introduction into the sovereign environment.

—

The update-transfer mechanism (staging, one-way gateway, controlled media, or equivalent) is proposed by the bidder as part of its vulnerability-management process, with validation/approval governed under Ignite's oversight in line with best international practices as well as the applicable policies, laws and regulations etc. of Pakistan.

8

G. Government Identity Systems for Access Portal Integration {#g.-government-identity-systems-for-access-portal-integration .unnumbered}

The RFP requires the NAIIH Access Portal to integrate with Government identity systems. Please identify the specific Government identity platform(s) with which integration will be required, for example NADRA/Pak-ID, a MoITT-managed identity provider, another federated Government IAM platform, or any combination thereof. Please also confirm whether the Successful Bidder will be provided with: - API/integration specifications; - authentication/federation protocols; - required security certificates or credentials; - sandbox/UAT environment; and - technical coordination with the relevant Government entity.

—

Identity-federation partners and integration approach are proposed by the bidder, with Company coordination on access. This may vary sector to sector.

9

Agentic AI, Tool Calling and Function Calling

The RFP requires developer environments, APIs, SDKs, integration capabilities and production model-serving infrastructure but does not expressly identify agent orchestration, tool calling or function calling as a mandatory platform capability. Please clarify whether the Successful Bidder is expected to provide platform-level support for agentic AI capabilities, including: - structured function/tool calling; - connection of models to approved APIs and enterprise systems; - agent/workflow orchestration; - tool registries and permission governance; - multi-step AI workflows; - agent execution monitoring/audit; and - standards-based agent/tool integration protocols such as MCP or equivalent. Alternatively, please confirm whether such capabilities are expected to be developed independently by tenants using the platform's APIs and developer environments. Please also confirm whether provision of an agentic-AI framework will form part of technical evaluation or will be treated solely as an optional value-added capability.

—

Please refer to section '26.4.1 Developer Environments' for context. Hence structured function / Agent development may not be required but client libraries for the platform's APIs and services (in commonly-used languages, or equivalent), integration of environments with identity, quota, and metering maybe needed.

10

Meaning of "Complete Source Code Ownership" Where an Existing Product Is Used

Form B8 requires the NAIIH Access Portal and Innovation Marketplace to be fully sovereign, with complete source-code ownership vested in the Government of Pakistan and without dependency on external or vendor-controlled services. At the same time, the RFP permits vendor-native, third-party and open-source components where they deliver the required outcome. Where a Successful Bidder proposes to deliver the Access Portal or Marketplace by extending an existing software product/platform, please clarify the required intellectual-property treatment. Specifically, would the requirement be satisfied through: a. assignment to the Government of all source code, configurations, integrations, APIs, deployment artefacts and custom/bespoke developments created specifically for NAIIH, together with perpetual rights necessary to independently operate, modify and redeploy the delivered solution; while b. pre-existing/background IP and reusable underlying product components remain the property of their original owner and are provided to the Government under an appropriate perpetual, irrevocable and transferable licence; or does the RFP require assignment to the Government of the bidder's entire underlying pre-existing product/platform source code as well? Please also clarify the treatment of third-party and open-source components incorporated into either platform.

—

Confirmed as

• (a) and
• (b) --- bespoke NAIIH-specific developments are assigned to the Government with full source code, while pre-existing/background product components are licensed to the Government in perpetuity.

11

Marketplace Payments, Collection and Settlement Responsibility

Layer 5 requires the Innovation Marketplace to support procurement, subscription and usage-based billing, monetisation and revenue-sharing between the platform and solution providers. Please clarify whether the Successful Bidder is expected only to develop and operate the technical billing, metering, accounting and settlement functionality, or is also expected to establish and operate the commercial payment-collection mechanism. In particular, please clarify which party will be responsible for: - appointment/integration of the payment service provider or payment gateway; - establishment and ownership of the merchant account; - receipt of buyer funds; - settlement to solution providers; - tax withholding/invoicing requirements; and - financial reconciliation. Please confirm whether Ignite/the Company will act as the merchant/settlement entity or whether this responsibility is expected to rest with the Successful Bidder.

—

The standard features for the marketplace should be there which include but not limited to, payment and compliance model, including merchant-of-record and payment-rail integration, to be proposed by the bidder. Regarding the merchant-of-record, given the requirements in the RFP and dynamics of the project the bidder can propose different models.

12

Marketplace Listing, Certification and Compliance Approval

The Marketplace requires ratings, performance benchmarking, certification and compliance badging that is "administrable under governance." Please clarify the respective responsibilities of Ignite/the Company and the Successful Bidder for marketplace governance. Specifically, is the Successful Bidder required to: a. develop the workflows, dashboards, review tools, audit trails and approval mechanisms through which Ignite-appointed reviewers administer listings and certifications; or b. also operate the substantive review, certification, compliance assessment and listing-approval process itself? Please also confirm whether the applicable listing criteria, certification standards, review policies and compliance/badging framework will be defined and approved by Ignite/the Company.

—

The bidder develops the workflows, dashboards and audit trails through which Ignite-appointed reviewers administer listings and certifications; listing criteria and certification standards are defined by Ignite/the Company.

Ref

Topic / Reference

Question

Reason for Asking

Ignite's Response

1

—

Is a formal JV/consortium mandatory, or can the solution be delivered through partnerships/supplier under a single lead bidder and what's the requirement for that?

—

There is no restriction. However, the lead bidder must meet the mandatory eligibility criteria along with the requirements of the RFP.

2

—

Please confirm the ratio of Technical-Financial weightage.

—

The Technical:Financial weightage is a 60:40 ratio, with bidders required to achieve a minimum of 75% passing marks (750/1000) on the Technical evaluation to be eligible for financial evaluation.

3

—

Is the 1 PB requirement specifically for parallel storage, or would object storage also be acceptable?

—

Parallel storage.

4

—

Is the 500 TB raw NVMe All-Flash capacity required in addition to the 1 PB raw parallel/object storage, or is it part of the 1 PB requirement?

—

500 TB is required in addition to the 1PB for Data-Pipeline / General-Purpose Compute Tier.

Ref

Topic / Reference

Question

Reason for Asking

Ignite's Response

1

Question 1

The criterion awards marks for general experience exceeding 5 years based on the Lead Bidder's registered age. Where the Lead Bidder is a subsidiary or group company, please clarify whether the registered age / general experience of the parent (holding) company or a group affiliate may be counted toward this criterion, supported by documentary evidence of the parent-subsidiary relationship (e.g. SECP records, shareholding/group structure). If permitted, please confirm the evidence required to substantiate the claim.

—

No. This criterion is assessed solely on the Lead Bidder's own registered age, verified from its certificate of incorporation and related documents. Please refer to form B2 as well as Evaluation Criteria table.

2

Question 2

The criterion scores the net worth of the Lead Bidder based on audited financials with a period ended not older than 18 months. Where the Lead Bidder is a newly established entity within a larger group, please clarify whether the parent (holding) company's audited financial statements and net worth may be used to demonstrate financial capacity --- both for scoring under this criterion and for meeting the Annexure AC financing gate (net worth ≥ PKR 500M or an AA+/AAA line of credit). If a parent guarantee, letter of financial support, or consolidated group audited accounts would be acceptable in lieu of the Lead Bidder's own standalone audited accounts, please confirm the specific form and documentation required.

—

No. Both the Annexure AC financing gate and the net worth scoring criterion (evaluation criteria table) must be met using the Lead Bidder's own standalone audited financial statements.

3

Question 3

This criterion requires verifiable reference projects demonstrating proven delivery capability. Please clarify whether reference projects delivered for international (non-Pakistan) clients are acceptable to substantiate the Lead Bidder's track record under this criterion, and whether such references are scored on the same basis as domestic references. If permitted, please confirm the evidence acceptable to verify an international reference (e.g. client completion certificate, contactable client reference, contract documentation) where the client is located outside Pakistan.

—

Yes. Form B4 does not restrict references to Pakistani clients; both national and international references from the Lead Bidder or a named consortium partner(s) are scored on the same basis as domestic references, provided they meet the Reference Submission Template's requirement for a named, contactable client contact and relevant verifiable documentation. However, it is encouraged that the quoted accelerators may have at least one local deployment.

4

Question 3 (Rephrased)

This criterion requires verifiable reference projects demonstrating proven delivery capability. We request clarification on the following:

• (i) Whether reference projects delivered by our subcontractor or vendor are acceptable to substantiate the Lead Bidder's track record under this criterion;
• (ii) Whether such references are scored on the same basis as directly contracted domestic references; and
• (iii) If international references are permitted, what evidence is acceptable for verification where the client is located outside Pakistan (e.g. client completion certificate, contactable client reference, or contract documentation).

—

• (i) Form B4 limits eligible references to the Lead Bidder or a named consortium partner(s); a subcontractor or vendor not formally declared as a consortium/JV partner does not qualify as a reference source --- except where the subcontractor is an OEM formally engaged by the Lead Bidder under a formal OEM support/vendor agreement to fulfill the requirements of the RFP.
• (ii) Qualifying references are scored on the same basis regardless of domestic or international origin.
• (iii) The evidence required is the same for both: the completed Reference Submission Template with a named, contactable client contact and relevant verifiable documentation.

Ref

Topic / Reference

Question

Reason for Asking

Ignite's Response

1

DR / Colocation Requirements; Draft SLA §11–12, pp. 234 onward

The RFP requires Primary and DR facilities with defined recovery targets. Kindly clarify the intended overall resilience architecture: should both sites provide equivalent AI compute, storage, network and platform capacity, or may bidders propose an appropriately sized DR environment capable of restoring the required critical services within the prescribed RPO/RTO?

Defines the complete Primary/DR architecture, capacity, replication model and major cost baseline. The SLA defines recovery targets but not equivalent infrastructure capacity.

Bidders may propose an appropriately sized DR environment based on industry best practices (baseline 75% primary 25% DR); The proposal should support the core platform, including orchestration platform and AI stack, to be deployed both in Primary and DR environment to meet the SLA requirement.

2

DR / Colocation Requirements; Technical Evaluation – DR, p. 81

As part of the end-to-end DR solution, should bidders determine whether the two sites operate Active/Active or Active/Passive, together with the required inter-site bandwidth, provided the committed availability, RPO and RTO are achieved? If not, Kindly provide IGNITE's preferred operating model and minimum inter-site connectivity requirements.

Architecture, WAN capacity, replication technology and DR investment all depend on this decision.

Bidders shall declare their proposed design and demonstrate it meets the committed availability and RPO/RTO targets in the SLA.

3

Layer 1 – Accelerator / AI Fabric Requirements

The solution is expected to support future AI capacity growth in addition to the initial accelerator deployment. Kindly clarify whether the required 25% growth headroom means only that the architecture must be expandable, or whether Day-1 facility capacity—including rack space, power, cooling and network ports—must also be reserved for this expansion.

Ensures compute, network and colocation facilities are engineered as one scalable solution rather than independently sized components.

Treated differently by domain: facility power/cooling headroom (25%) must be an actual, physically guaranteed Day-1 capacity; network-fabric headroom is an architectural requirement (topology must accommodate 25% growth without re-architecting), not a Day-1 port-population mandate.

4

Layer 1 – Accelerator Requirements

Given the rapid evolution of AI accelerator technologies, Kindly clarify at what project milestone the requirement for “latest-generation, in-production” accelerators will be assessed—bid submission, contract award, procurement or delivery. May the bidder upgrade to a newer equivalent/superior generation during execution, subject to compatibility and approval?

Prevents the overall solution becoming technologically outdated during a potentially long procurement and deployment cycle.

Assessed as declared at bid submission and re-confirmed at Delivery/Operational Acceptance; any change requires the Company's prior written approval and compliance with procurement rules.

5

Data-Pipeline / General-Purpose Compute Tier, p. 92

The RFP requires a dedicated data-pipeline compute tier with ≥1,500 physical CPU cores, ≥1 TB memory per node and ≥500 TB flash-class working storage. Kindly clarify whether IGNITE's objective is physical separation of compute and storage resources, or guaranteed dedicated performance and isolation. Accordingly, may bidders integrate the 500 TB scratch requirement with the high-performance parallel-storage architecture if the required ≥100 GB/s read/write performance and workload isolation are demonstrably achieved?

Allows the complete data path—ingestion → processing → storage → GPU training—to be optimized as one architecture rather than creating potentially duplicated storage islands.

Both physical separation of compute and storage resources, as well guaranteed dedicated performance and isolation.

6

Parallel Storage System, §26.1 / Technical Evaluation Section D, pp. 93 onward

For the parallel-storage solution, Kindly confirm whether the ≥1 PB hot-tier expansion requirement represents usable capacity after data protection. Further, will IGNITE prescribe a standard benchmark methodology for validating ≥380 GB/s read, ≥190 GB/s write and ≥6 GB/s concurrent delivery per accelerator node, or should bidders propose an OEM-validated test methodology for acceptance?

Capacity and performance must be evaluated together to correctly engineer the storage nodes, media, protection scheme and storage fabric.

≥ 200 TB usable (post-data-protection) for the active training working set, non-disruptively expandable to ≥1 PB. The bidders shall propose an OEM-validated methodology, for the Company's review as part of the Acceptance Test Plan.

7

Parallel Storage §26.1.4 – Direct Storage-to-Accelerator DMA

The RFP requires a direct data path from parallel storage to accelerator memory. Is the functional objective to achieve CPU-bypass/high-performance accelerator data movement, allowing any OEM-supported standards-based or equivalent implementation, rather than requiring a specific proprietary technology?

Maintains interoperability and allows the storage, accelerator and network ecosystem to be selected as an integrated solution rather than locking the architecture to one implementation.

Yes — the requirement is technology-neutral outcome, no specific proprietary technology is mandated. So, architecture will remain same as required.

8

AI Fabric / Networking Requirements; Scope Overview

For clarity of the complete network architecture, Kindly confirm whether bidder responsibility extends across all required connectivity domains—AI accelerator fabric, parallel-storage fabric, service/data network, management/OOB network, security perimeter, Internet/external connectivity and Primary-to-DR connectivity—or identify any connectivity that will be provided by IGNITE or another nominated party.

Establishes the end-to-end network boundary and prevents interface gaps between different partners/OEMs. The Prime Bidder otherwise carries end-to-end integration accountability.

Bidder responsibility extends across all listed connectivity domains.

9

§26.1.6 – Container Orchestration, pp. 151–152

The RFP intentionally permits a CNCF-conformant Kubernetes platform without mandating a vendor. To support long-term technology sovereignty and portability, Kindly confirm whether a production-grade open-source Kubernetes architecture with enterprise-grade 24×7 support is acceptable, or whether IGNITE expects commercial OEM subscriptions for the complete Managed Operations Term.

Determines the overall platform strategy, long-term licensing model, support responsibility and degree of vendor independence.

Yes — a production-grade open-source Kubernetes architecture is acceptable; no commercial OEM subscription is mandated, provided the RFP's 24×7×365 support and Anti-Lock-In obligations are met.

10

§26.1.8 – DR & Backup; Draft SLA §11

The RFP defines different RPO/RTO targets for critical, standard and bulk/archival services. Should bidders therefore design a policy-based data-protection architecture in which datasets, model artefacts, platform state and other data are protected according to their service criticality, or is the complete parallel-storage dataset expected to be replicated at the DR facility?

This is fundamental to DR storage capacity, backup sizing, replication bandwidth and overall solution economics.

A policy-based, criticality-driven architecture is intended, confirmed by the SLA's differentiated RPO/RTO targets by service tier; full replication of the entire dataset is not mandated. The protection of core platform, including orchestration platform and AI stack, should support operation in both in Primary and DR environment to meet the SLA requirement.

11

§26.1.8 – Backup & DR; Draft SLA §11

To engineer the complete data-protection solution, Kindly confirm whether IGNITE will prescribe backup retention, backup frequency, immutability and archival requirements, or whether bidders should propose an appropriate policy aligned with the RFP-defined service tiers and RPO/RTO objectives.

Without the protection policy, backup capacity, technology and long-term storage requirements cannot be accurately sized.

Bidders shall propose a backup architecture with defined retention, aligned with the RFP's tiered RPO/RTO framework, for the Company's review and approval.

12

Cross-Cutting Security / IAM / Security Operations

Should NAIIH be designed with its own complete cybersecurity operations environment—including IAM, MFA/PAM, SIEM/SOC and associated security controls—or are any existing IGNITE/Government identity or SOC platforms expected to be integrated with the proposed ecosystem?

Determines whether we build a self-contained security ecosystem or an integrated security architecture and avoids duplicate technology investment.

A complete, self-contained security operations capability is required as part of scope.

13

§26.1.7 – Infrastructure Monitoring & Telemetry, p. 151; Cross-Cutting Monitoring/Logging

Does IGNITE expect a unified observability and operations platform covering compute, accelerators, network, storage, facilities, Kubernetes and platform services, or should the solution integrate with any existing NOC/SOC/ITSM platforms?

The ecosystem requires end-to-end operational visibility; this clarifies whether monitoring is a complete new solution or an integration requirement.

A unified, complete observability capability is required as part of scope for the solution to integrate with.

14

Colocation Requirements; Draft SLA §12, pp. 234 onward

Considering the high-density accelerator infrastructure, Kindly confirm whether bidders may propose liquid-cooled/high-density AI systems together with the necessary CDU, manifolds and facility integration. Additionally, must both proposed facilities already hold operational Tier III/TIA-942 Rated-3 certification at bid submission, or may certification be completed before deployment/Operational Acceptance?

AI system selection, colocation selection, rack density, power and cooling must be engineered together. The RFP requires operationally certified, concurrently maintainable facilities.

Kindly refer to form B3 and form B5.

15

Technical Evaluation B9-2 – Core Component Implementation & Testing

The RFP requires OEM involvement for implementation and testing of “Core Components.” Kindly clarify which technology domains are considered Core Components and whether implementation by OEM-authorized/certified partners under OEM supervision/support is acceptable, while the Prime Bidder retains end-to-end integration accountability.

Critical for defining the delivery model across GPU, compute, storage, networking and platform OEMs and avoiding overlapping implementation responsibilities.

Some of the core components include, e.g., accelerators, storage, networking/ interconnects, cybersecurity, orchestration layer, AI Stack etc. Implementation by OEM, with the Prime Bidder retaining end-to-end accountability, is consistent with the RFP's broader Proven Capability framework.

16

§31.1 Acceptance; Draft SLA §5, pp. 230 onward

Since Operational Acceptance depends on the integrated operation of compute, storage, network, orchestration, software and management layers, will IGNITE and the Successful Bidder jointly finalize an end-to-end Acceptance Test Plan during detailed design, defining workload profiles, benchmarks, test conditions and measurable pass/fail criteria before deployment?

Ensures the entire ecosystem is accepted based on agreed end-to-end outcomes rather than isolated component specifications.

Yes. The Successful Bidder must provide a phased acceptance plan for the Company's approval, mapping each acceptance milestone to measurable criteria, to be finalised jointly during detailed design.

17

End-to-End Capacity / Sizing

Are the capacities stated in the RFP intended as fixed minimum Day-1 capacities, or should bidders perform end-to-end sizing and may propose higher capacities where necessary to ensure that compute, GPU, storage, network and platform layers operate as a balanced solution?

Prevents us from treating individual minimum specifications as independently sized components.

The stated capacities are binding Day-1 minimums, not fixed specifications; bidders are expected to perform their own end-to-end sizing and may propose higher capacities for a balanced solution.

18

Technology / OEM Interoperability

Does IGNITE expect bidders to propose a best-of-breed multi-vendor architecture where appropriate, provided end-to-end interoperability and single-point accountability are demonstrated, or is preference given to a more tightly integrated OEM ecosystem?

Very important for deciding NVIDIA/compute/storage/network/platform vendor strategy and consortium structure. The RFP already emphasizes interoperability and support accountability in areas such as storage.

The RFP is vendor- and technology-neutral and permits a best-of-breed approach; no preference for a single, tightly integrated OEM ecosystem is stated.

19

Management & Control Infrastructure

Should management, control-plane and platform-support services be deployed on dedicated infrastructure independent of the AI/GPU workload clusters, and should equivalent management capability also be maintained at DR?

Defines the “brains” of the ecosystem and avoids using expensive GPU resources for management/platform services.

Yes to dedicated infrastructure — the RFP defines a distinct Management & Control-Plane Node Tier, physically separate from the accelerator host tier. the DR site must restore critical services within the stated RPO/RTO. However, the bidder may propose industry best practices with clear evidence.

20

Day-1 vs. Future Expansion

For requirements specifying future scalability or expansion, Kindly clarify which capacities must be physically delivered and licensed at Day-1 versus capabilities that only need to be architecturally supported for future expansion.

This has major implications for BOQ, licensing, facility reservation and commercial pricing.

The infrastructure needs to be interoperable and expandable based on future requirements and plans.

21

Prime vs Consortium Liability

Where the solution is delivered through a consortium involving a Prime Bidder, global AI/technology partner, local SI and multiple OEMs, please clarify whether contractual responsibility remains entirely with the Prime Bidder or whether specific obligations, liabilities and acceptance responsibilities may be contractually allocated to respective consortium members.

A prospective parent/prime needs to know whether it carries 100% liability for work actually delivered by other parties.

External contractual accountability to Ignite rests with the single Prime Bidder; however, consortium members remain jointly and severally liable. Internal obligations may be allocated via a RACI matrix, but this does not reduce the Prime Bidder's external accountability.

22

Responsibility Boundaries

Will IGNITE allow the proposal and subsequent contract to establish clearly defined responsibility boundaries for infrastructure, AI platform, colocation, managed operations, OEM support and other major workstreams while maintaining overall programme governance through the Prime Bidder?

Allows a workable consortium structure instead of placing every technical risk on one entity.

Yes. The RFP expressly requires a consortium governance structure with a RACI matrix mapping deliverables to accountable parties, while the Prime Bidder retains overall programme governance to Ignite.

23

Phased Acceptance & Payment

Given the scale and multi-layer nature of the programme, can infrastructure, platform, DR and operational capabilities be commissioned through defined stage-gates with independent acceptance and corresponding commercial/payment milestones rather than making overall acceptance dependent upon completion of the entire ecosystem?

Probably one of the most important questions for partner risk. It limits accumulated delivery and cash-flow exposure.

Yes. The RFP expressly stages acceptance into defined milestones, each mapped to measurable criteria and corresponding payment milestones, which will be finalized in agreement with the successful bidder.

24

Dependency / Third-Party Risk

Where achievement of a project milestone depends upon facilities, connectivity, approvals, data, access, integrations or services to be provided by IGNITE or another nominated stakeholder, how will delays outside the Successful Bidder's control be treated for schedule, SLA and acceptance purposes?

Prevents the prime from absorbing delays it cannot control.

The end-to-end project delivery is the bidder's responsibility. However, where applicable, force majeure rule may apply. Furthermore, based on the responsibility matrix Ignite/MoITT will provide possible support to facilitate access to relevant data-holding organisations.

25

Technology Evolution / Obsolescence

Given the project duration and rapid evolution of AI technologies, will a formal technology-refresh/change-control mechanism allow equivalent or superior technologies to be introduced during Build and Operate phases without being treated as deviation from the originally accepted solution?

Protects the consortium against accelerator/platform obsolescence during a multi-year programme.

Introducing an equivalent or superior technology is treated as a change requiring Ignite's prior written approval.

26

Performance Responsibility

Where end-to-end performance depends on components from multiple OEMs and service providers, will compliance be assessed against the integrated solution's committed performance, with component-level responsibilities governed through the approved responsibility matrix and OEM support arrangements?

Important for determining who owns performance failures across GPU–network–storage–platform boundaries.

Yes. Service Levels are measured at the integrated service-class level, not per component/OEM; internal component-level responsibility is governed through the Prime Bidder's RACI matrix and OEM/partner support arrangements.

27

BOT Risk Boundary

Please clarify the point at which operational responsibility and associated service risk transfer from Build/Implementation into the Managed Operations phase, and subsequently from the Successful Bidder to IGNITE at completion of BOT.

Establishes when each major category of delivery and operational liability begins and ends.

Please refer to section 40. PAYMENT / DISBURSEMENT PLAN of RFP for clarity.

Ref

Topic / Reference

Question

Reason for Asking

Ignite's Response

1

Large-scale AI/HPC infrastructure delivery

On Page 86, Criterion 1 requires 2 references. Please clarify whether the references are only from the bidder or also required the local reference of quoted AI accelerator from OEM.

To clarify the requirement about delivery case.

The OEM's reference will be counted only where the OEM is engaged by the Lead Bidder under a formal OEM support/vendor agreement covering the specific accelerator deployment being referenced, contractually binding the OEM to the bid in a supporting-vendor capacity to fulfill the requirements of the RFP.

2

Parallel Storage System

On Page 97, Hot-tier performance capacity, Ignite requires 200TB usable (post-data-protection) storage for the active training working set (shards, checkpoints, KV cache). However, the current requirement only defines it as stored data, without reusing the data. Please clarify whether it is only necessary to store the data and not implement the following functions: resuming training from a checkpoint, KV cache acceleration, i.e., achieving inference acceleration by avoiding re-prefilling.

To clarify the function requirement about storage.

No, the reuse of the data is required, including resuming training from a checkpoint and reusing KV cache to accelerate inference by avoiding repeated prefill computation.

3

Parallel Storage System

On Page 97, Aggregate read/write throughput. Ignite defines performance requirements only for the future “full cluster scale” configuration. Given that distributed storage systems can generally scale up to thousands of nodes, and the required capacity for this project is small, resulting in a very limited number of actual configured nodes, the actual performance may differ significantly from the performance of a full cluster. Please specify the expected maximum performance percentage that this configuration needs to achieve, for example, 30%.

To clarify the performance requirement about storage.

The bidders shall propose an OEM-validated methodology, for the Company's review as part of the Acceptance Test Plan.

4

Container Orchestration

On Page 151, Ignite specifies “Container Orchestration (Foundation Level)”. Considering that different workloads may have different deployment requirements, including containerized applications as well as VM-based workloads, so does Ignite require that proposed platform should support hybrid workloads including Containers and Virtual Machines (VMs) under a unified management platform?

To avoid the actual needs from users may not be support.

A hybrid solution may be proposed by the bidder under unified management.

5

Environment Provisioning

One Page 161, 26.3.3 Environment Provisioning, Ignite requires “strict tenant isolation”. If hybrid workloads are required by start-ups, please clarify whether VM and container workloads are required to follow consistent tenant-level policies, including network isolation, IAM/access control, resource quota, QoS, and storage isolation.

To clarify the tenant isolation requirement

Yes, strict tenant isolation is required.

6

DR

On Page 186, Section 32.3 requires critical hardware to be replaced on-site within 24 hours from in-country spares. Considering the high cost of critical components and the geographic separation of the Primary and DR sites, please clarify whether a centralized spare-parts holding is acceptable, subject to an effective inter-city emergency logistics arrangement?

To clarify the requirement of spare-parts

Hardware OEM in Pakistan for spares are acceptable, provided the SLA is met at both sites; logistics remain the bidder’s responsibility.

7

DISASTER RECOVERY TARGETS

On Page 187, Section 32.4 requires an RTO of ≤4 hours for critical services. Storage-level backup could meet this target for most common failures where the primary-site platform remains available; however, it would not normally meet the RTO if the primary site is completely lost and the platform must be rebuilt manually. Please clarify whether the ≤4-hour RTO is also required to cover complete primary-site loss.

To clarify the requirement of RTO

Yes. The ≤4-hour RTO applies to complete Primary-site loss; all critical service components, including the container orchestration platform, and AI/model platform, shall be operational at the Secondary Site within this RTO.

8

DISASTER RECOVERY TARGETS

On Page 148, Management & Control-Plane Node Tier. Considering that the number of management nodes required varies for different container platforms, and the 5 nodes specified in this requirement can only meet the management of a K8S cluster in one data center, does the bidder need to independently supplement the remaining management nodes for the primary and backup centers? In addition, what level of RTO objective must the disaster recovery of the management & control-plane in the primary and backup centers meet?

To clarify the requirement of management & Control-Plane

The RFP is vendor- and technology-neutral. Bidders should determine the number of management nodes based on their chosen solution. The RTO of the management & control-plane should comply with the requirement of ≤ 4 hours for Critical services.