## 4 Results
### 4.5 Stakeholder Roles and Technical Debt Responsibility  
To support the practical application of our findings, we mapped each technical debt type to the primary stakeholder responsible for its prevention, management, or resolution within AI/ML competition platforms. This mapping is based on a synthesis of the reviewed literature and real-world examples encountered in competition settings.  
Table 5 provides an overview of the primary stakeholder roles associated with each of the 18 technical debt types. The classification distinguishes between  
* Competition Organizers: Those responsible for designing and maintaining the platform, defining evaluation protocols, providing infrastructure, and ensuring transparency and fairness.
* Participants: Teams or individuals who submit AI models or agents to the competition and are accountable for code quality, reproducibility, and ethical compliance.
* Both: Debt types where responsibility is shared between organizers and participants due to their interdependent nature.  
For clarity and conciseness, the term Organizer is used here as an umbrella role that encompasses several functionally distinct sub-roles frequently encountered in competition platforms. These include, among others, the Data Provider, who supplies and curates the competition datasets; the Platform Provider, responsible for maintaining the underlying infrastructure and interface; and the Evaluation Designer, who defines performance metrics and scoring protocols. These sub-roles, while analytically distinct, often overlap in practice and are collectively represented as Organizer to streamline the stakeholder mapping.  
Similarly, the term Participant denotes any individual or team submitting AI models to the competition, and may include distinct roles such as model developers, data preprocessors, or post-evaluation analyzers, whose responsibilities vary depending on the competition's scope and structure.  
This mapping enables competition stakeholders to better allocate responsibility, prioritize mitigation actions, and reflect on the structural sources of technical debt in their systems. It also serves as a foundation for customizing the assessment questionnaire introduced in Section 5. A visual representation of stakeholder-specific impact levels per debt type is provided in Figure 3.  
Figure 3: Stakeholder impact matrix for technical debt types.  
\begin{table}
\begin{tabular}{c c} \hline \hline
**Technical Debt Type** & **Primary Responsible Stakeholder** \\ \hline Algorithm & Participant \\ Architectural & Organizer \\ Build & Organizer \\ Code & Both, Organizer and Participant \\ Configuration & Both, Organizer and Participant \\ Data & Organizer \\ Defect & Organizer \\ Design & Organizer \\ Documentation & Organizer \\ Ethics & Both, Organizer and Participant \\ Infrastructure & Organizer \\ Model & Organizer \\ People & Both, Organizer and Participant \\ Process & Organizer \\ Requirements & Organizer \\ Self-Admitted (SATD) & Participant \\ Test & Both, Organizer and Participant \\ Versioning & Organizer \\ \hline \hline \end{tabular}
\end{table}
Table 5: Technical debt types and primary stakeholders.  
Heatmap illustrating the relative impact of each debt type on organizers and participants. The matrix complements Table 5 by visually emphasizing shared and high-risk responsibilities.