Schedule 3 – Standard Drafting and Adoption Process

 Section 1: Stakeholder Review Proposal

1.1 Purpose: Prior to formal standardisation sprints under this Schedule, the OpenBharat.net Governing Council (OBGC), in administrative concurrence with the ISAIL Secretariat, shall prepare a Stakeholder Review Proposal identifying the candidate specification, its architectural scope, and the relevant developer and industry communities required for technical review.

1.2 Contents: A Stakeholder Review Proposal shall set out:

• A concise technical description of the proposed specification, benchmark harness, or architectural baseline;

• Categorization of target stakeholders across developer collectives, startup founders, infrastructure providers, academic laboratories, and legal-regulatory experts;

• The empirical engagement methodology, incorporating field surveys under Section 2, multi-sprint working sessions under Section 3, or open repository testbeds; and

• Indicative milestone timelines across draft maturation stages.

1.3 Initiation Authority: The OBGC and the Secretariat hold discretionary authority to approve, amend, defer, or shelve any Stakeholder Review Proposal. Formal approval of the proposal constitutes the official initiation of a standard development track within a designated OpenBharat.net Working Group (OWG).

Section 2: Survey-Based Evidence Collection

2.1 Purpose: Where the OBGC or Secretariat determines that standard development requires empirical field baselines on computational capacity, alignment benchmarks, deployment bottlenecks, or regulatory readiness, a targeted survey may be initiated either independently or in partnership with an accredited Knowledge Partner under Schedule 6.

2.2 Administrative Control: The Secretariat retains sole authority to:

• Determine the necessity, timeline, and data cutoff intervals for field evidence collection;

• Execute the survey directly or assign execution support to an accredited Knowledge Partner;

• Define the technical scope, sample methodology, and data validation rules; and

• Reserve sufficient review windows prior to public presentation or working sprint integration.

2.3 Independent Survey Track: Where conducted independently without an external Knowledge Partner, all administration, data processing, and resulting analytical reports vest solely in ISAIL and OpenBharat.net.

2.4 Knowledge Partner Execution Track: Where a survey is executed in cooperation with an accredited Knowledge Partner:

• ISAIL and the Knowledge Partner shall execute a simplified operational addendum specifying network distribution and timeline commitments.

• The Knowledge Partner shall circulate the survey across its enterprise or developer networks without altering the approved questions or data capture parameters.

• Attribution Safeguards: The Knowledge Partner receives an irrevocable right of institutional attribution in final published whitepapers, citing its capacity as an official survey execution partner under Schedule 6. The Secretariat may extend written co-attribution recognition where technical analysis warrants, but such recognition conveys no copyright, editorial veto, or derivative rights.

• Limited Non-Commercial License: Knowledge Partners retain the right to cite published findings for non-commercial research, academic study, and marketing attribution. Knowledge Partners hold no right to re-weight, re-process, modify, or release unauthorized private derivative cuts of the survey datasets.

2.5 Intellectual Property Custodianship: Pursuant to Article 6a and Article 23, all survey instruments, raw data submissions, analytical code, and final evaluation syntheses vest exclusively in ISAIL for the public commons.

2.6 Standard Input Distinction: Survey findings collected under this Section serve as foundational empirical inputs for technical drafting and remain strictly separate from educational curricula, certifications, or distinct bilateral MoUs.

2.7 Transition to Drafting: Following data validation, the Secretariat and presiding Convenors shall determine how findings are integrated into active OWG drafting sprints. Knowledge Partners possess no inherent drafting rights or review vetoes unless separately accredited as participating technical members.

Section 3: Working Group Drafting and Request for Comments (RFC)

3.1 Technical Working Drafts: Upon track initiation, the designated OWG Convenors shall lead iterative drafting sprints to produce a baseline working specification (OPENBHARAT-[TRACK]-[SEQUENCE]-DRAFT). All draft revisions must be maintained in version-controlled public repositories pursuant to Article 9.

3.2 Request for Comments (RFC) Phase:

• When a working draft achieves internal technical stability within the OWG, the Convenors shall issue an open Request for Comments (RFC) published under the Working-Group Public tier.

• The RFC period shall remain open for a minimum of twenty-one (21) calendar days to solicit technical feedback, architectural critiques, and compatibility reviews from independent developers and ecosystem participants.

• The OWG maintainers shall log, categorize, and publicly address all substantive issue tracker submissions prior to closing the RFC window.

Section 4: Technical Consensus and Formal Adoption Framework

4.1 Review and Convenor Recommendation: Following the close of the RFC period, the presiding Technical Convenors and Policy Convenors shall review the resolved specification, verify empirical test runs, and submit a formal Recommendation for Adoption to the OBGC.

4.2 Final Ratification by the OBGC:

• The OBGC evaluates the specification for technical coherence, absence of proprietary vendor capture, and compliance with the Bharat Pacific Principles of AI Standardisation.

• Formal ratification requires a concurring determination by the Chairperson and Co-Chairperson, alongside affirmative review by the assigned Executive Members.

4.3 Promulgation and Numbering: Upon ratification, the specification is cataloged as a formal normative standard (OPENBHARAT-[TRACK]-[SEQUENCE]-[YYYY]) and published under the permissive public licensing terms established in Article 6a and Article 23.

Section 5: Post-Adoption Empirical Effectiveness Review

5.1 Operational Field Audits: Ratified standards and evaluation suites shall undergo periodic effectiveness reviews at intervals not exceeding twenty-four (24) months, led by the relevant OWG.

5.2 Review Metrics: Reviews shall evaluate real-world implementation telemetry, including developer adoption curves, computational overhead across domestic testbeds, discovered security vulnerabilities, and interoperability friction.

5.3 Lifecycle Determinations: Following review, the OWG Convenors shall recommend to the OBGC whether the standard should be:

• Maintained in its current release;

• Scheduled for revision via a new minor or major semantic versioning sprint; or

• Formally deprecated and retired in favor of an updated architecture.

Section 6: Implementation, Sandboxes, and Ecosystem Deployment

6.1 Open Reference Implementations: Where feasible, ratified specifications must be accompanied by open-source reference code, API test suites, or validation harnesses made available in public OpenBharat.net repositories under approved open-source licenses.

6.2 Sandbox Deployment: Alliance Members, partnering incubators, and research facilities are encouraged to deploy ratified standards within localized regulatory sandboxes, academic test clusters, and commercial beta environments to validate performance under live operating constraints.

6.3 Non-Coercive Architecture: Implementation of OpenBharat.net standards remains voluntary, consensus-oriented, and open-access, serving as a technical benchmark for sovereign AI resilience and verifiable model safety rather than a mandatory bureaucratic hurdle.