Submission (ENG)

A product requirements document (PRD) is a document containing all the requirements for a certain product. It is written to allow people to understand what a product should do. A PRD should, however, generally avoid anticipating or defining how the product will do it in order to later allow interface designers and engineers to use their expertise to provide the optimal solution to the requirements.

It is in Markdown, because that is what developers are familiar with and also compatible with GitHub and many IDEs.

It is in A4 IEEE Conference Paper Format, because that is what technical whitepapers are usually formatted in for academic publications.

No.

Other than adhering to the format of the chapter headings convention — e.g. 1. for section one, 1.1 for the first subsection of section one, and 1.1.1 for the first subsubsection of the first subsection of section one — you may use any formatting as you like, as well as any naming or organizational structure as you like. But the document should be in Markdown.

Yes. It would also be advantageous if you intend to publish in an IEEE journal.

Anything you like! Can you screen capture or talking heads or both. Whatever tells the adjudicator about the essence of your project.

You will not be disqualified for using AI as long as it does not infringe copyright. Please properly attribute all sources to avoid issues with copyright.

Having real data would make life easier, but quality data sets are usually hard to access or unavailable. If you use simulated data set, make note of it in your submission material.

It should be able to demonstrate the use cases you envisioned.

It can be anything to demo the use case you envisioned.

No. It is optional, but it is useful as supporting material and something you can use in your future academic and/or professional career.

The page limit of the main whitepaper forces teams to be very clear and concise with their information transmission. However, there are no limits to the length of supplementary Annex(es).

The chapter headings may be anything! Below are the Level 1 Chapter Headings used by previous IDSOL Whitepapers. As you can see, they are similar, but they fit the project's nature (which is inherently different), telling the story they want to tell in the way they want it to be told.

3 Chapters

1. Background

2. Solution

3. Next Steps

4 Chapters

1. Introduction

2. Related Work

3. Proposed Solution

4. Conclusion

5 Chapters

1. Problem Space

2. States-of-the-Art

3. Solution Overview

4. Solution Design

5. Challenges

6 Chapters

1. Orientation

2. Situation

3. Mission

4. Execution

5. Administration

6. Coordination

7 Chapters

1. Problem Statement

2. Vision

3. Use Case and Existing Solutions

4. Risks and Challenges

5. Architecture and Infrastructure

6. Distribution and Continuation

8 Chapters

1. Introduction

2. Problem Statement

3. Competitive Overview

4. Solution Overview

5. Solution Design

6. Impact, Governance, Scalability

7. Challenges and Future Plans

8. Conclusions

9 Chapters

1. Introduction

2. Problem Statement

3. Solution Architecture

4. Operations

5. Value Proposition

6. Features, Benefits, Impact

7. Competitive Analysis

8. Success Factors and Mitigated Risks

9. Conclusion

VERY. You will be penalized or even disqualified for the wrong format. The region under the thick, dark grey strip is not regulated, but everything including and above that thick, dark grey strip ("regulated region") may not be modified or interfered with.

Here is a checklist of things in the regulated region:

• Flag: to be the flag of the country or territory that you represent. To be sure you are within regulation, find your country or territory in the template.

• Project ID: the project will be assigned a project ID if and only if your project has been invited to the finals. Make sure it is the correct one.

• Project Name: a valid name as per the validity parameters; it can be in ALL CAPS or in Title Case.

• Project Tagline: a short description of the project in the thick, dark grey strip. Do not change the font. Do not change the size. 

• Project Team (Lead and Members): the names of the entire team, with the team lead or team captain labelled with a (C). This is the only part of the regulated region where some variance is tolerated. See below.

• Olympiad Logo: do not modify the position, size, colour, etc.

Project Team presentation:
Variation is allowed as long as the final result fits between the Project Name and the Olympiad Logo.

• Variant 1: team member name(s) only.

• Variant 2: team member name(s) with attribution, i.e. academic institution; may or may not include department (post-secondary) or grade level (secondary).

• Variant 3: supervisor name(s) with attribution —  unless there is room for the attribution, do not include the name of the supervisor(s).

The font in the regulated region is Lexend Extra Light or Lexend with Font Weight 200.