Rules of the Contest “Digital Mine on OpenEgiz”

Edition of 12 October 2026. Changes from the previous edition:

• section 2: the terms “Concept” and “Default Solution” are added;
• clause 6.5: SUBMISSION.md starts with the Concept; clause 6.13 on the Concept is added;
• clause 9.1: the “Presentation” criterion (10 points) is replaced by the “Concept and Presentation” criterion (15 points); the weights of criteria are changed: Mine Visualization — 25 points (previously 20), What-if Scenarios — 10 points (previously 15), Modules — 5 points (previously 10);
• clause 9.4 on the Default Solution is added;
• clause 10.2: in the Final, the Judges take into account how well thought out the Concept is;
• clause 14.2: the Rubric in this edition and the Tie-break Rule shall not be changed further.

1. General Provisions

1.1. These Rules set out the procedure for holding the open contest “Digital Mine on OpenEgiz” (the “contest”). The subject of the contest is the creation of a digital twin of a mine on the OpenEgiz platform.

1.2. The organizer of the contest is the individual Gulshat Amanzholovna Amirkhanova (the “Organizer”). The Organizer holds the contest in her own name, approves the Rules, publishes Official Clarifications and pays the prize from her personal funds. The contest is held with the support of the DigitalEgiz lab of al-Farabi Kazakh National University (KazNU).

1.3. Places in the contest are determined by the AI Jury in accordance with the Rubric and the AI Jury pipeline fixed before the Freeze (clause 8.5). The Organizer and any other persons take no part in determining places.

1.4. The terms of the contest are established by these Rules. Official Clarifications interpret the Rules and do not change them. The Rules are published in English, Kazakh and Russian; in the event of any discrepancy between the texts, the Russian text shall prevail.

1.5. Official resources of the contest:

• contest website — openegiz-contest.github.io;
• contest organization on GitHub — openegiz-contest;
• contest GitHub Discussions — questions and Official Clarifications;
• Instagram digital_twin_kaznu — announcements.

1.6. All dates and times are given in Astana time (UTC+5).

2. Terms

• AI Jury — the Judges taken together.
• Appeal — a Team's claim of a factual error in a Build Report or in a finding on an attempt to influence the AI Jury (section 12).
• Build Report — the report compiled by the Builder on running a Submission: the results of executing the instructions, whether the declared functions work, and logs.
• Builder — an AI agent that runs a Submission following the README instructions and compiles the Build Report. The Builder does not award points.
• Concept — the first section of SUBMISSION.md, in which the Team itself states the enterprise or its part, who uses the digital twin and which decision it helps to make (clause 6.13).
• Default Solution — a digital mine created from the Template by AI agents without a Team's Concept; the Organizer publishes it on the contest website as the reference point for the Judges (clause 9.4).
• Example Mine — the demonstration digital mine included in OpenEgiz (examples/mine), which shows how a digital mine is structured on the platform. The Example Mine is not a Submission and is not a mandatory basis for one.
• Final — the concluding stage of the contest, broadcast live, at which the Judges determine first to third places.
• Finalists — the Teams whose Submissions have advanced to the Final (clause 10.1).
• Freeze — the moment at which acceptance of Submissions ends, after which Team Repositories are read-only (clause 7.1).
• Judge — an AI model that operates within an agent and awards points according to the Rubric independently of the other Judges.
• Judge Environment — the reference computing environment in which every Submission is run. Its specifications are published on the contest website.
• Mine Map — the list of digital mine Modules published on the contest website.
• Module — a functional area of a digital mine (for example, haulage and dispatch, ventilation).
• Official Clarification — an answer by the Organizer in the contest GitHub Discussions that interprets the Rules (clause 14.1).
• OpenEgiz — an open platform for digital twins (github.com/aleka07/openegiz).
• Organizer — Gulshat Amanzholovna Amirkhanova (clause 1.2).
• Participant — an individual registered as a member of a Team.
• Qualifying Round — the evaluation of all Submissions by all Judges that precedes the Final.
• Registration — the filing of a Team's application through the form on the contest website (section 5).
• Rubric — the criteria and weights according to which the Judges award points (section 9).
• Runners-up — the Teams that have taken second and third places.
• Stand — an instance of OpenEgiz with a Submission, running in the Judge Environment.
• Submission — the contents of the main branch of a Team Repository at the moment of the Freeze.
• Team — a group of one to four Participants presenting one Submission.
• Team Repository — a Team's private repository in the openegiz-contest organization on GitHub, created from the Template.
• Template — a complete copy of the OpenEgiz release fixed for the contest, from which Team Repositories are created.
• Tie-break Rule — the procedure for awarding a place when there is no majority of the Judges' votes (clause 10.4).
• What-if Scenario — a change of an operating condition of the mine on the Stand (for example, closing a road or stopping equipment) whose consequences are reflected in the data of the twins.
• Winner — the Team that has taken first place.

3. Prize

3.1. The Winner is awarded a prize of 1,000,000 (one million) tenge.

3.2. If the Winner consists of more than one Participant, the prize is divided equally among them. The shares are received by the Participants who are members of the Team at the moment Registration closes. Participants confirm their agreement to this procedure at Registration.

3.3. The prize is paid to each Participant in the amount of their share, in tenge, in cash or by transfer to the Participant's personal bank account.

3.4. The Runners-up are awarded diplomas and receive an offer of an internship or employment at the DigitalEgiz lab; their Submissions are published on the OpenEgiz website. No cash prize is paid to the Runners-up.

3.5. The prize is not awarded if no Submission scores more than 40 points (clause 9.3).

3.6. The prize is paid without tax withholding, unless the laws of the Republic of Kazakhstan require the Organizer to withhold tax when paying it. Taxes, duties, bank fees and other expenses related to receiving the prize are borne by the Participant personally, in accordance with the laws of the country of their tax residence.

3.7. The time limit and procedure for paying the prize are set out in clause 13.3.

4. Participants

4.1. Any individual may become a Participant in the contest. A person under 18 takes part with the consent of their legal representative.

4.2. A Participant may be a member of only one Team.

4.3. Any tools, including artificial intelligence tools, may be used to create a Submission.

5. Registration

5.1. A Team registers through the form posted on the contest website. The form requires the Team name and, for each Participant, their full name, place of study or work, email address and GitHub username.

5.2. At Registration, each Participant confirms:

• agreement with these Rules;
• that they are 18 or older or have the consent of a legal representative (clause 4.1);
• consent to the distribution of the Submission under the MIT license and the right to distribute their own contribution to the Submission on those terms (clause 6.6);
• agreement with the procedure for dividing and paying the prize (clauses 3.2 and 3.6);
• consent to the processing of personal data, including its transfer outside the Republic of Kazakhstan (section 15).

5.3. After Registration, a Team Repository openegiz-contest/team-NNN, where NNN is the sequential number of the Registration, is created for the Team, and GitHub invitations are sent to the Participants. Participants receive write access to the Team Repository without the right to change its settings or to delete it.

5.4. Until Registration closes, the membership of a Team is changed using the “Edit response” function of the registration form. If the same GitHub account or email address is listed as a member of two Teams, the person is included in the Team that registered earlier.

5.5. Registration closes at the moment of the Freeze. After Registration closes, the membership of Teams does not change.

6. Task and Submission

6.1. The contest task is to create the Team's own digital mine on the OpenEgiz platform. The digital mine may represent any part of a mining enterprise, including an open pit, an underground mine or a processing plant. There are no tracks or categories. The Team determines its set of Modules at its own discretion, guided by the Mine Map; Modules not included in the Mine Map are evaluated on an equal footing with those included. The depth of development of Modules takes priority over their number.

6.2. The Submission must be built on OpenEgiz. This means that:

• mine objects are represented by twins in Eclipse Ditto;
• data is transmitted through the platform (MQTT → Ditto);
• the user interface obtains data from the platform.

An application that operates separately from the platform and is connected to it only formally is not considered to be built on OpenEgiz (clause 9.3).

6.3. Work is carried out in the Team Repository. Changes to any parts, including the platform core, are permitted. The Example Mine demonstrates how a digital mine is structured on the platform; its use is not mandatory. Only what has been created by the Team is evaluated (clause 9.1).

6.4. The Submission must start in the Judge Environment by following the README.md instructions without manual intervention. The Builder follows the instructions literally; a Submission that has not been started by following the instructions is deemed to have failed to start. An instruction step that ends in an error is repeated once without changes; the result of the last attempt counts. The specifications of the Judge Environment, including the start-up time limit, are published on the contest website. The Judge Environment contains no access keys, paid services or accounts of the Organizer.

6.5. The Submission must contain in the repository root:

• README.md — instructions for installing and running the Submission from scratch;
• SUBMISSION.md — a description of the Submission in the form provided in the Template: the Concept (clause 6.13), Team members (GitHub usernames), implemented Modules, their working status and limitations, a “Data and Assumptions” section, and a pointer to the visualization;
• presentation.pdf — a presentation of the Submission.

A video may be provided at the Team's discretion as a link in SUBMISSION.md.

6.6. The Submission is distributed under the MIT license. Copyright belongs to the Team; the Team is entitled to name itself in the LICENSE file. Each Participant distributes their own contribution to the Submission under the MIT license and confirms at Registration that they have the right to do so. The OpenEgiz code included in the Template, as well as third-party software and data included in the Submission, are distributed under their own licenses. Materials whose license does not permit their publication are not placed in the Team Repository.

6.7. Submissions are accepted in Kazakh, Russian or English.

Data

6.8. Synthetic data and simulation may be used, provided that the parameters are justified.

6.9. Open datasets may be used. A dataset placed in the Team Repository must have a license that permits the distribution of copies. The Team is responsible for the availability of a dataset downloaded from an external source following the README.md instructions; if the dataset is not downloaded, the Submission is deemed to have failed to start. The license and source of a dataset are stated in README.md or next to the data.

6.10. The use of confidential data of organizations and of personal data is prohibited. The Team is responsible for the lawfulness of its use of data.

6.11. SUBMISSION.md must contain a “Data and Assumptions” section stating which data are synthetic and which are real, the sources of parameters (equipment data sheets, reference literature, standards, datasets) and the licenses of the datasets.

6.12. For each Module and What-if Scenario, SUBMISSION.md states what it does and how to see it working on the Stand; for a What-if Scenario, it also states how to undo it. Only Modules and What-if Scenarios whose operation is confirmed on the Stand are taken into account.

6.13. The first section of SUBMISSION.md is the Concept, written by the Team itself. The Concept states the enterprise or its part represented by the Submission, who uses the digital twin, which decision it helps to make, and why this choice was made. The object may be real or fictional; for a fictional object, the Concept states which real objects it resembles and where its numerical values come from.

7. Timeline

7.1. At the moment of the Freeze, the Participants' write access is revoked and the last commit of the main branch of each Team Repository is recorded, after which the repositories are made public and read-only. The recorded commit is deemed to be the Submission. Other branches, pull requests and changes made after the Freeze are not considered. The list of recorded commits is published.

7.2. A Submission whose main branch does not differ from the Template is deemed not to have been submitted.

8. AI Jury

8.1. The composition of the AI Jury is published before the Freeze (clause 8.5).

8.2. A Submission is evaluated in two stages:

1. The Builder runs the Submission following the README.md instructions in the isolated Judge Environment and compiles the Build Report.
2. The Judges, independently of each other, award points according to the Rubric on the basis of the Build Report, the source code, SUBMISSION.md, the presentation and the user interface of the Stand.

8.3. In the Qualifying Round, each Submission is evaluated by all Judges. Build Reports, the Judges' scores with their reasoning, and work logs are published.

8.4. If technical limitations of AI services prevent a Judge from evaluating, before the Qualifying Round reports are published, all the Submissions evaluated by the other Judges, that Judge's scores are not taken into account in the Qualifying Round. The date of the Final is not postponed.

8.5. The Rubric forms part of these Rules. The AI Jury pipeline (the Judges' prompts and the program code) is fixed before the Freeze. Before the Freeze, the composition of the AI Jury and a checksum (hash) of the fixed version of the pipeline are published; after the Qualifying Round results are published, the Judges' prompts and the program code of the pipeline are published, against which the checksum can be verified. Once fixed, the pipeline is not changed, except for corrections of errors that do not affect evaluation. A notice stating the reasons and the new checksum is published for each such correction.

9. Rubric

9.1. Each Judge scores a Submission on a scale from 0 to 100 points according to the following criteria. For each criterion the Judge determines a level from 0 to 4; the score for the criterion equals the criterion's maximum points multiplied by the level and divided by 4. Only what has been created by the Team and confirmed by the Judge on the Stand or in the source code is taken into account; statements in SUBMISSION.md and in the presentation that are not confirmed on the Stand earn no points. The Example Mine and its parts used without modification earn no points.

9.2. The score of a Submission in the Qualifying Round is the arithmetic mean of the Judges' scores.

9.3. The score of a Submission that has failed to start by following README.md or is not built on OpenEgiz (clause 6.2) may not exceed 40 points. The Team of such a Submission may not become the Winner.

9.4. The Organizer publishes the Default Solution on the contest website. The Judges use the Default Solution as the reference point when determining levels. A Submission that does not go beyond the Default Solution receives low levels for the criteria “Mine Model”, “Mine Visualization” and “Concept and Presentation”.

10. Final and Determination of Places

10.1. The 10 Submissions with the highest Qualifying Round scores, taking into account the outcome of Appeals, advance to the Final. If there are fewer than ten Submissions, all Submissions advance to the Final.

10.2. The Final is held live on YouTube. The Judges discuss the Finalists' Submissions and determine first to third places. In the discussion, the Judges take into account how well thought out the Team's own Concept is, taking the Default Solution as the reference point. The discussion logs are published.

10.3. Places are awarded in order, starting with first place. A place is awarded to the Finalist for whom more than half of the Judges have voted. If there is no majority, a further round of discussion is held. The maximum number of rounds is published together with the AI Jury pipeline.

10.4. Tie-break Rule. If no majority is reached after the last round, the place is awarded to the Finalist with the highest Qualifying Round score among those that have not yet received a place. If the scores are equal, the place is awarded to the Finalist with the highest average score for the “Mine Model” criterion and, if they are still equal, to the Team that registered earlier.

10.5. If a Judge is unavailable during the Final, the decision is taken by a majority vote of the remaining Judges; if the votes are tied, the Tie-break Rule applies.

11. Disqualification

11.1. A Submission is disqualified for an attempt to influence the AI Jury, that is, placing in the instructions, code, data, presentation or interface hidden or explicit instructions addressed to the Builder or the Judges and aimed at changing their work or scores (prompt injection). Instructions addressed to people, and prompts of the Submission's functions addressed to its own AI models, are not an attempt to influence the AI Jury.

11.2. The presence of such instructions is determined by a separate AI agent. Its finding is published together with the Qualifying Round reports and may be appealed under the procedure set out in section 12.

12. Appeals

12.1. A Team is entitled to file an Appeal within 48 hours after the publication of the Qualifying Round reports. The reports are published no later than 28 October 2026, 12:00. The procedure for filing is announced at the same time as the reports are published. The Finalists are determined after all Appeals filed in time have been reviewed.

12.2. An Appeal is accepted only in respect of a factual error in a Build Report or in a finding on an attempt to influence the AI Jury — for example, if the Build Report states that a Module does not start and the Team presents a log confirming that it starts. Disagreement with the points awarded is not grounds for an Appeal.

12.3. Appeals are reviewed automatically: the Submission is run again, and the dispute is resolved by a separate Judge. If an Appeal is upheld, the Judges re-evaluate the Submission on the basis of the corrected Build Report; the final score cannot be lowered as a result. The outcome of the review is published and is final.

12.4. The procedure set out in this section does not limit a Participant's right to protect their rights in the manner established by the laws of the Republic of Kazakhstan.

13. Winner

13.1. The Winner confirms participation within 72 hours after the results are announced, by an email to developerbeck@digitalegiz.kz or a message in the contest GitHub Discussions from any Participant of the Team. If no confirmation is received, the Team next in the final ranking of the Final is recognized as the Winner.

13.2. A talk by the Winner is a condition for receiving the prize. The talk does not affect the allocation of places and is given in person at al-Farabi Kazakh National University or online, at the Winner's choice, at a time agreed with the Organizer, no later than 30 November 2026. If the talk has not taken place by then for reasons beyond the Winner's control, the talk condition is deemed fulfilled.

13.3. The prize is paid no later than 30 days after the Winner's talk or, if the talk condition is deemed fulfilled under clause 13.2, no later than 30 December 2026. For the payment, each Participant of the Winner provides the Organizer with their full name and bank account details or receives their share in cash (clause 3.3). For a Participant who has not provided the details, the time limit for paying their share is extended by the length of the delay.

14. Questions and Amendments to the Rules

14.1. Questions about the contest are asked in the contest GitHub Discussions. The Organizer's answers in GitHub Discussions are Official Clarifications. Answers given in other channels are not official.

14.2. The Rubric in the edition of 12 October 2026 and the Tie-break Rule shall not be changed further; the composition of the AI Jury shall not be changed after its publication. Other amendments to the Rules are published on the contest website as a new edition with its date and a list of changes and are announced in the contest GitHub Discussions. Amendments do not worsen the position of registered Participants; the contest dates may only be moved to later dates.

15. Personal Data

15.1. Participants' personal data (full name, place of study or work, email address, GitHub username and, for paying the prize, bank account details) are processed by the Organizer. The data are used solely for running the contest and paying the prize, are stored with restricted access and are deleted no later than 30 April 2027.

15.2. To run the contest, personal data are transferred, including outside the Republic of Kazakhstan, to the services through which the contest is held: Google (the registration form and the table of responses), GitHub (Team Repositories and invitations) and the providers of the AI Jury models (GitHub usernames contained in Submissions).

15.3. Only the Team name, the Participants' GitHub usernames and, after the Freeze, the contents of the Submission, including its commit history, are published. Participants include any other personal data in the Submission, including in the LICENSE file and the commit history, at their own discretion.