A Literature Review on Academia–Industry Collaboration Portal

1Introduction

Universities are expected to help students develop capabilities relevant to their disciplines and to changing labour markets. Employability cannot be captured by a single score or a checklist of technical skills. Reviews describe it as context-dependent and multidimensional, encompassing disciplinary and transferable skills, career management, professional dispositions, and opportunities to apply learning [1], [2].

This creates a coordination challenge: students need useful evidence of their skills, employers need clear, current criteria, and institutions need reliable records of applications and outcomes.

Digital tools can help users explore careers and find opportunities, but a recommender alone cannot address the full transition from education to work. Existing systems demonstrate the use of competency-based career recommendations and gap analysis [3]. Research on digital competence assessment also highlights the need for reliable and valid instruments [4]. Studies of recruitment recommenders raise concerns about fairness in opportunity rankings [5].

Together, this work points to the need for a broader institutional platform that connects assessment, learning actions, opportunity information, eligibility checks, and oversight, while explaining how it produces its outputs.

This paper develops a conceptual, role-based platform architecture based on the project workflow provided for this study. It follows a conventional research-paper structure, presenting the motivation, approach, literature synthesis, design, implications, limitations, and future work. It does not claim to be a completed systematic review. Its main objective is to support student skill development and career management while keeping records accurate, explainable, and appropriately restricted.

The paper considers three design questions. First, what capabilities and information flows are needed to connect student skill development with employment and training opportunities? Second, how can the platform distinguish evidence, eligibility, and recommendation scores so users can understand and challenge its outputs? Third, how can institutional roles coordinate through shared records while limiting unnecessary access to student information?

The paper presents a conceptual architecture derived from a project workflow, a set of system-wide rules, and a staged validation plan. It is a research draft intended for review and further development. The workflow alone does not demonstrate technical feasibility, educational effectiveness, fairness, usability, or improved employment outcomes.

2Background and related literature

2.1Employability as a contextual and developmental construct

No single employability model is accepted across higher education. A systematic review of employability models identified several theoretical approaches and recommended that practitioners make their assumptions explicit before selecting a model for an educational intervention [1]. Another review found that employability programmes are often evaluated through small-scale studies focused on work-related learning; these studies cannot establish causal effects on skills or labour-market outcomes [2]. Accordingly, the proposed platform does not treat profile completion or an opportunity match as a measure of employability.

Instead, it presents specific evidence and development opportunities in the context of each student’s education and labour market.

2.2Competency evidence and assessment quality

Research on digital competence assessment reports a range of methods and ongoing concerns about reliability and validity [4]. Studies of practical coding assessments also show why a single attempt or score may provide an incomplete picture: task difficulty, adaptive tasks, repeated attempts, and fairness across groups all affect interpretation [6]. The proposed platform therefore distinguishes self-reported skills from assessed skills and records the method, rubric, task evidence, date, and status of each assessment. A score describes performance on the specified tasks; without further validation, it should not be treated as proof of broad occupational competence.

2.3Career matching and recommendation

CARIA provides an example of a competency-based career recommender. It compares an individual’s competencies with career requirements and reports recommendation performance using digital career data [3]. This illustrates how competency matching can support career guidance, although the results should not automatically be generalized to other disciplines, regions, or live job markets. Research on fairness in job recommendation also warns that ranking methods can shape which opportunities people see and may reproduce existing inequities [5].

In this design, recommendations serve as decision support: the platform displays criteria and missing skills, separates eligibility from ranking, uses active opportunities with stable identifiers, and allows human review of consequential decisions.

2.4Data governance and multi-role access

Different roles in education need different information to fulfil their responsibilities. OECD guidance on education data governance describes role-based access as a way to align information access with role and purpose while limiting exposure of identifiable records [7]. This supports the workflow’s use of a shared source of truth without making every record visible to everyone. Student documents, application details, and assessment evidence remain protected. Administrators and institutional users receive only the permissions needed for their assigned tasks, and privileged changes are logged.

2.5Gap addressed by the proposed architecture

The literature addresses employability development, competency assessment, career recommendation, fairness, and data governance, often as separate topics. The project workflow brings these functions together with company opportunity publishing, faculty–industry collaboration, institutional event requests, placement tracking, administration, and user support. The proposed architecture describes how these functions could connect. It does not claim that no comparable system exists; establishing novelty would require a reproducible search and systematic comparison with existing platforms.

3Research approach

This paper presents a conceptual design synthesis based on the supplied functional workflow and selected peer-reviewed studies. The workflow serves as a source of requirements, not as evidence that a platform has been built. Targeted scholarly searches covered employability frameworks, competence assessment in higher education, competency-based career recommendation, recruitment recommendation fairness, and education data governance. Sources were selected for their relevance to the design questions. Because the work did not use a multi-database search protocol, duplicate removal, a screening log, or quality appraisal, it is not presented as a systematic literature review. No corpus size or screening count is claimed.

A design-science approach can guide the next stage: define the problem, build an artifact, demonstrate it in a realistic setting, and evaluate whether it meets stakeholder needs. This paper covers only the conceptual framing and an initial artifact specification. Before reporting empirical results, a future implementation study should document its protocol, approvals, participants, system configuration, data sources, and evaluation instruments.

3.1Design objectives

The design objectives are summarised in Table 1.

ID	Design objective	Rationale
DO1	Connect skills, learning actions, opportunities, applications, and outcomes using stable shared records.	Avoid duplicate records and inconsistent status reports.
DO2	Show evidence provenance and explain all scores.	Support interpretation, correction, and responsible use.
DO3	Enforce mandatory eligibility and document requirements before application submission.	Make criteria operational and consistent.
DO4	Restrict personal information by role, purpose, and institution relationship.	Reduce unnecessary exposure of sensitive records.
DO5	Support reciprocal institution–company and faculty–company coordination.	Represent stakeholder workflows beyond student job matching.
DO6	Provide accessible, clear, responsive interactions and actionable status messages.	Make next steps understandable across devices and user roles.

4Proposed platform architecture

4.1Roles and module boundaries

The platform defines five roles: Student, Company/Recruiter, Academic/Faculty (called “Academican” in the project workflow), Institution/Training and Placement Administration, and Platform Administrator. Each role has a dedicated dashboard and permissions. The Academic/Faculty module handles faculty development programmes, training, workshops, and collaboration requests. As specified in the workflow, it has no direct operational link to the Student module. The roles are summarised in Table 2.

An institution may view permitted academic activity and collaboration status, but this does not create student-specific academic records in the Academic/Faculty module.

Role	Primary functions	Data and action boundaries
Student	Manage profile, education documents, skills, assessments, and learning actions; discover opportunities; submit applications; and track their status.	Own profile and submissions; may apply only when mandatory criteria and document requirements are met.
Company / Recruiter	Publish opportunities and training; define mandatory and preferred criteria; review applications; manage capacity; respond to events; and collaborate with faculty.	Company-owned posts and authorized application decisions; no access to unrelated student records.
Academic / Faculty	Manage FDPs, workshops, training, emerging skills, and company collaboration requests.	Separate module; no direct operations in the Student module.
Institution / Placement	Request company events; monitor authorized academic collaboration; track its own students’ applications and outcomes; and produce reports.	Scoped to its institution and authorized records.
Platform Administrator	Manage permitted roles, account states, and records, and review audits using a provisioned login.	No public sign-up; privileged actions require strong authentication and audit trails.

4.2Student development and evidence workflow

A student begins by creating a profile with education, course, branch, academic year, projects, certificates, experience, interests, and self-declared skills.

Relevant education documents may include school, diploma, semester, and degree records. The platform records upload and verification states separately: Missing, Uploaded, Verification Pending, Verified, or Verification Required. OCR may support data extraction, but neither an upload nor an OCR result proves authenticity. Sensitive files are accessible only to authorized users for a defined workflow. Students can add and revise skills from a searchable library that includes suggested synonyms and custom entries. For selected skills, the system may assign practical tasks with difficulty levels, hidden tests, edge cases, rubric-based scoring, and follow-up reasoning prompts. Each resulting report should include the assessed task scope, score, rubric breakdown, strengths, limitations, evidence, date, and next learning actions. Cheating signals prompt review but are not treated as conclusive proof. Multiple-choice questions can supplement practical evidence, but should not be the sole basis for proficiency claims when practical assessment is feasible.

4.3Opportunity matching, eligibility, and applications

Companies can publish jobs, internships, projects, and training opportunities with details on descriptions, required skills, education, branch, year, minimum marks or CGPA, experience, backlog rules, location or mode, capacity where applicable, and deadline. Each criterion is designated as mandatory or preferred. The backend evaluates mandatory eligibility separately from the ranked match score. If a student does not meet a mandatory rule, the platform blocks application submission and identifies the unmet requirement or document status. The rule is enforced in both the user interface and at the API/database boundary to prevent bypass.

Recommendations draw on active, published, non-expired opportunities stored on the platform. Each recommendation retains the company post identifier and provenance. Its explanation presents the criteria, weights, input values, matched and missing skills, and improvement steps. Eligibility appears separately as a pass/fail outcome. The platform prevents duplicate applications to the same post. Application states—including Applied, Under Review, Shortlisted, Interview, Selected, Rejected, and Pending—come from the same application record used in authorized company and institution dashboards.

4.4Company training, institution events, and collaboration

Company training records include the title, skills, duration, dates, mode, eligibility, registration deadline, and maximum capacity. The backend enforces registration capacity transactionally to prevent overbooking when requests are concurrent. The program lifecycle state is shared across dashboards. Institution event requests include the event type, topic, date, start and end times, venue, delivery mode, description, and expected audience. A company can accept or reject a request. Once it is accepted, an authorized representative may be assigned. Notifications link to the same request record and reflect its status changes.

Academic/Faculty and Company users can each initiate a collaboration request. The recipient can accept or reject it, and the platform retains its purpose, description, proposed dates, response details, and status history. The Institution dashboard can display authorized collaboration and faculty development records. These functions maintain the workflow boundary between academic activities and student-specific operational records.

4.5Shared backend, administration, and user support

The modules use a shared API and centralized database, with stable identifiers for users, roles, student profiles, documents, skills, assessments, companies, institutions, opportunities, eligibility criteria, applications, training, registrations, event requests, collaboration requests, notifications, and audit events. Backend validation, foreign-key relationships, duplicate prevention, capacity transactions, and role-aware authorization help preserve data integrity. The database serves as the source of truth, and dashboards read from the same authorized records rather than maintaining conflicting copies.

A Platform Administrator account is created through a protected process and cannot be registered publicly. Passwords are hashed, sessions are protected, privileged actions are logged, and sensitive changes require re-authentication. The existing “Need a Hand?” entry opens a chatbot through an authenticated service. The chatbot can explain platform functions and use only information the current user is authorized to access. A fixed list of answers would not provide the requested conversational support. Any model-generated response must remain within the user’s access permissions and the platform’s data controls.

5Cross-cutting rules and explainable measures

Each displayed percentage must have a defined purpose, formula, data source, and explanation. When evidence is missing, the platform shows “Not assessed yet” or “Not enough data” rather than an invented percentage. The following definitions are proposed starting points and require stakeholder validation before deployment. (Table 3).

Measure	Proposed definition	Interpretation constraint
Profile completion	Completed required fields ÷ total required fields × 100.	Indicates form completeness only; it does not measure skill or employability.
Assessment score	Marks earned ÷ total possible marks × 100, with rubric components.	Applies only to the tasks and assessment conditions shown.
Opportunity match	Weighted contribution across documented relevant criteria.	Display weights, inputs, missing criteria, and improvement path; do not present it as a probability of hiring.
Eligibility	Pass/fail decision against mandatory criteria and required verified documents.	Separate from the match score; show each unmet rule.
Progress or attendance	Completed required activities ÷ total required activities × 100, or attended sessions ÷ conducted sessions × 100.	Define the denominator and update rule for the context.

Security and privacy are system properties, not presentation settings. Hiding a button does not authorize or deny an operation; the backend authorizes every protected request. Institutions can access records only for their own students and permitted reporting purposes. Documents are protected at rest and in transit, retained only as needed, and managed under institutionally approved retention and access procedures. System logs record the actor, action, time, target record, and reason where appropriate.

Accessibility and usability requirements include readable text, adequate contrast, clear labels, responsive mobile, tablet, and desktop views, preservation of form entries when safe, and plain-language errors and status descriptions.

The proposed design makes explainability operational. An explanation identifies the criteria and values that shaped a recommendation and distinguishes ranking from eligibility. This matters because recruitment recommendation systems can raise fairness concerns [5]. Audits should examine both exposure (which opportunities are surfaced) and outcomes (who applies, advances, or is selected), using lawful, consented, and appropriately protected data. Human review and a way to correct errors are necessary when profile data or opportunity requirements are inaccurate.

6Discussion and implications

6.1Research implications

By linking skill evidence, learning actions, opportunity criteria, and outcomes, the architecture establishes a traceable process for study. Future research could examine whether transparent feedback prompts students to address skill gaps, whether practical assessment results are interpreted consistently, and how institutional coordination affects the transition from education to work. Because employability depends on context [1], [2], future implementations should align skills and outcome measures with the relevant discipline, labour market, and institutional goals.

6.2Practical implications

Students would use the platform to move from profile creation and skill assessment through gap analysis, opportunity discovery, applications, and outcome tracking. Employers could publish criteria and manage applications, while institutions could coordinate events and report placement activity using shared records. These functions depend on current opportunity data, useful assessments, staff participation, accurate status updates, clear governance, and adequate support. A shared database improves consistency only when stakeholders agree on definitions, ownership, and update responsibilities.

6.3Evaluation plan

The next stage should be a limited pilot to evaluate the artifact’s functionality, measurement approach, usability, security, and value to stakeholders. The proposed sequence is to: (1) review requirements with students, faculty, placement staff, and recruiters; (2) test a prototype using synthetic records; (3) test security and authorization, including attempts to access records across roles and institutions; (4) have subject experts review assessment rubrics and analyze reliability and validity in a pilot; (5) conduct usability sessions with representative users; and (6) run an ethically approved institutional pilot measuring workflow completion, data quality, recommendation usefulness, fairness indicators, and student learning actions. Employment outcomes require longer follow-up and an appropriate comparison strategy; platform use alone cannot establish those outcomes. Example evidence and measures are listed in Table 4.

Evaluation area	Example evidence	Example measures
Functional integrity	Test cases and audit records.	Eligibility blocks, duplicate prevention, concurrent capacity enforcement, and status consistency.
Assessment quality	Task, rubric, expert review, and pilot responses.	Content alignment, scoring reliability, subgroup task analysis, and feedback usefulness.
Recommendation quality	Relevant opportunity judgements and exposure logs.	Precision/recall or ranking measures, coverage, stale-post rate, and explanation correctness.
Usability and accessibility	Observed task sessions and user feedback.	Task completion, error rate, time, accessibility conformance, and perceived clarity.
Fairness and governance	Authorized subgroup audit and access logs.	Opportunity exposure and progression disparities, access violations, and correction resolution.
Educational and career outcomes	Longitudinal and institutionally approved data.	Skill development, application progression, placement outcomes, and context-adjusted comparisons.

The architecture has not been implemented or evaluated; therefore, its expected benefits are design intentions rather than measured results. The proposed matching approach has no validated weights or empirically calibrated model. Matching quality, assessment validity, privacy, and fairness will depend on local context, data quality, governance, and implementation.

7Threats to validity and limitations

This paper is a conceptual synthesis based on one project workflow and a targeted, non-systematic set of sources. The literature selection may be biased, and the review is not comprehensive.

The workflow brings together functions that may be governed by different institutional policies and jurisdictional rules. Before deployment, the institution would need to review education-document verification, hiring criteria, data retention, AI use, and access to student records. This paper does not claim compliance with any specific jurisdiction.

8Future work

Future work should begin with a reproducible systematic review that specifies the protocol, databases, search strings, eligibility criteria, duplicate handling, screening records, and quality assessment. The architecture can then be developed into a data model, API specification, access-control matrix, and prototype for user testing. Pilot studies should assess practical skills rubrics and score reliability across student groups.

Recommendation studies should compare transparent weighted matching with suitable baselines, examine stale data and opportunity coverage, and audit exposure and outcomes for group disparities.

Longer-term, multi-institution studies could assess whether students act on gap feedback, whether stakeholders use the collaboration workflows, and how educational or employment outcomes vary by discipline and labour market.

9Conclusion

This paper proposes a conceptual architecture for the Academia Industry Collaboration Portal. It connects practical skills evidence and student development activities with current opportunities, eligibility checks, applications, training, institutional events, faculty–industry collaboration, and placement outcomes. The design distinguishes self-reported skills from assessed skills, uploaded documents from verified documents, match rankings from mandatory eligibility, and shared records from unrestricted access. It also requires a definition for each displayed percentage and links each recommendation to an active opportunity on the platform. The result is a workflow-based specification and evaluation plan. Implementation and empirical evaluation are still needed before claims can be made about effectiveness, fairness, security, or employment outcomes.

References

1. [1]Eimer A, Bohndick C. Employability models for higher education: A systematic literature review and analysis. Social Sciences & Humanities Open. 2023;8(1):100588. https://doi.org/10.1016/j.ssaho.2023.100588
2. [2]Scandurra R, Kelly D, Fusaro S, Cefalo R, Hermannson K. Do employability programmes in higher education improve skills and labour market outcomes? A systematic review of academic literature. Studies in Higher Education. 2024;49(8):1381–1396. https://doi.org/10.1080/03075079.2023.2265425
3. [3]Seesukong S, Angskun T, Keandoungchun N, Thippongtorn A, Angskun J. CARIA: A personalized career recommender based on individual competency similarity measure. International Journal of Information and Communication Technology Education. 2024;20(1). https://doi.org/10.4018/IJICTE.356499
4. [4]Sillat LH, Tammets K, Laanpere M. Digital competence assessment methods in higher education: A systematic literature review. Education Sciences. 2021;11(8):402. https://doi.org/10.3390/educsci11080402
5. [5]Kumar D, Grosz T, Rekabsaz N, Greif E, Schedl M. Fairness of recommender systems in the recruitment domain: An analysis from technical and legal perspectives. Frontiers in Big Data. 2023;6:1245198. https://doi.org/10.3389/fdata.2023.1245198
6. [6]Guo H, Zhang M, Ko AJ, Li M, Zhou B, Lim J, et al. Measuring students’ programming skill via online practice. In: Proceedings of the 8th Educational Data Mining in Computer Science Education Workshop (CSEDM’24); 2024.
7. [7]OECD. Data and technology governance: Fostering trust in the use of data. In: OECD Digital Education Outlook 2023. Paris; 2023. https://doi.org/10.1787/c74f03de-en