Concept for an interactive directory of universities in Uzbekistan

Status: working concept, describing the target product rather than a list of available features.
Original dated: 6 September 2026
Translation synchronised: 17 September 2026
Product languages: Russian, Uzbek and English

1. Purpose

The project is a multilingual directory of universities and educational programmes in Uzbekistan. It should help applicants find a programme, check study conditions, compare options and reach the official application channel.

It is also a working platform for universities. After their authority is verified, representatives can maintain their institution’s page and take responsibility for their changes. Platform administrators verify institutions and representatives, check sources, review disputed edits and manage security.

The collaboration model resembles a professional network of universities, while the public service remains primarily a directory. The target model includes institutional pages, verified representatives, news and events, and applicant profiles, favourites, comparisons and subscriptions.

2. Core principles

1. Programmes matter more than promotional descriptions. Applicants compare qualifications, teaching languages, formats, cities, costs, grants, deadlines and requirements for specific programmes.
2. Facts have a provenance. Changing information, including fees, deadlines, entry requirements and licences, has a source, a checking date and a responsible editor.
3. Official and editorial data are distinct. Ordinary university editors cannot change legal status or licensing. Verified representatives can maintain campus descriptions, photos, contacts and events.
4. Changes are transparent and reversible. Versions retain authors, times and reasons, with comparison and rollback facilities.
5. All three languages have equal standing. Interface text lives in localisation files; translated university and programme content lives in the database. Text should have an original language, translation status and update date.
6. Collect minimal personal data. Applicant profiles should contain only what selected features require. Internal representative contacts must not be published without separate consent.
7. The directory does not replace official admissions. Until integrated with an official application system, it provides checked information and directs applicants to official channels.

3. Users and permissions

Visitor

Searches universities and programmes, uses filters, maps and comparisons, and reads information without registering.

Applicant

Creates a profile, saves programmes and comparisons, subscribes to universities, receives deadline reminders and asks questions through a designated public channel. Sensitive grade records and identity documents are not needed for the first version.

University representative

Edits only assigned institutions and programmes within granted permissions. An institution may have several representatives: profile owner, programme editor, news editor or analytics viewer.

Moderator

Reviews representative applications, new pages, changes to key fields, complaints and discrepancies with sources.

Administrator

Manages institutions, users, roles, publication rules, reference lists, integrations, activity logs and recovery. Administrator access should use multifactor authentication.

4. Directory structure

Institution page

• Official and short names in three languages;
• institution status and ownership;
• official registry identifier, licence or accreditation with a source;
• addresses, campuses, coordinates and official contacts;
• official website and verified social channels;
• description, specialisation, facilities and accessibility;
• accommodation, student support and international opportunities;
• photographs and videos with rights-holder attribution;
• educational programmes;
• open days, news and announcements;
• verified public representatives who consent to being shown;
• last checking date and change history.

Programme page

• University, faculty, campus and subject area;
• education level and qualification;
• study format, duration and teaching languages;
• tuition by academic year and currency;
• grants, scholarships and concessions;
• officially published places;
• requirements, examinations and documents;
• application deadlines and study start date;
• accreditation and information source;
• official application address;
• checking date for every changeable information block.

Values absent from reliable sources are marked “not published” or “requires confirmation”. They must not be filled with assumptions.

5. Verifying representatives

Access should require several checks, rather than an email address alone.

1. The applicant registers, verifies email and telephone, and enables a second authentication factor.
2. They select an institution and state their position, work contacts and requested access.
3. The system checks whether the email domain belongs to the institution. A match supports the application but does not complete verification.
4. The applicant attaches an official letter, authorisation or confirmation from a responsible manager or department. Only an authorised administrator can access it.
5. A moderator checks the registry, website domain and official contacts, then independently confirms authority by calling a published central number or writing to an official address obtained outside the application.
6. The decision and its basis are logged. Approved accounts receive the minimum necessary permissions for the specific institution.
7. The institution designates its main profile owner. Transferring ownership requires another check.
8. Authority is reconfirmed periodically, for example annually, and following domain or job changes or prolonged inactivity. An administrator may suspend access immediately.

Branches and separate legal entities require explicit assignments. Representing one institution does not automatically grant access to its whole group.

6. Editing and publication

The intended workflow is draft → review → published / rejected → archive.

Initially, all representative edits should be moderated. With a reliable history, institutions may later publish low-risk descriptions, photos, events and general contacts directly. Fees, deadlines, requirements, licences, status and official identifiers continue to require review or automatic source checks.

Each version records its author and organisation, time, changed fields, editor’s comment, source and checking date, moderation decision and rejection reason, and the previous published version for rollback.

Public labels should distinguish institution verification, representative updates, editorial checks, official registry sources and outdated information. Verifying a representative’s identity and authority is not an assessment of educational quality.

7. Administration

The separate restricted panel should provide:

• New applications, pending edits, complaints and overdue data;
• institutions, branches, programmes and official identifiers;
• representative records: name, position, work contacts, assigned institutions, permissions, evidence and access dates;
• a moderation queue with old/new comparisons;
• roles and individual permissions;
• logs of sign-ins, edits, decisions and administrative actions;
• source monitoring and freshness reminders;
• filter reference lists and translation quality;
• correction requests and representative disputes;
• integration, backup and technical-check status.

Contacts, institutional identifiers and access records may be stored in a protected database and shown only to authorised administrators. Passwords are stored as strong hashes. Service credentials belong in environment configuration locally and secret storage on hosting. Administration should expose a key’s purpose, owner, expiry and final characters, never its full value. See the OWASP secrets management guidance.

8. A professional university network

After establishing a reliable directory, possible additions include verified news and open days, applicant subscriptions, public questions and official answers, joint programmes and mobility, faculty and laboratory pages, admissions calendars and reminders, internships and student events, and anonymous interest statistics for representatives.

Private messaging should wait because it requires stronger protection against spam, fraud and unwanted contact. Moderated public questions and official contact forms are safer early options.

9. Lessons from international services

1. Institutional self-service with central verification. Hochschulkompass publishes information about public and recognised institutions, maintained by their own staff: service description, inclusion criteria.
2. Rich institutional profiles. UCAS provider pages combine media, campus life and support with course information: UCAS Provider Pages.
3. Compare programmes, not just institutions. Discover Uni explains indicator periods, sample sizes and limitations: comparison guidance.
4. Distinguish sources. Institution submissions, official statistics and research results should have clear provenance: Discover Uni data, provider information.
5. Revision history. MediaWiki records authors and times and supports comparison and reversal: revision model. Official fields here need stricter permissions.
6. Evidence beside each fact. Show its source, validity period, last check and confirmation type.
7. Freshness monitoring. Remind institutions to confirm next year’s fees, deadlines and programmes; automatically flag expired data.
8. Import and export. Spreadsheet uploads and a later API reduce repeated manual entry.
9. Total-cost estimates. Include published accommodation, transport and other expenses, always dated and sourced.
10. Neutral results. Any future paid promotion must be clearly labelled and must not secretly affect organic search order.

Student reviews and ratings should wait for enrolment verification, moderation rules and a calculation method. Until then, present verifiable facts and official indicators, not misleadingly precise university scores.

10. Technical and hosting model

Development can be local. The proposed portable architecture comprises Next.js and TypeScript for the website and accounts, Django and Django REST Framework for server logic and administration, PostgreSQL for data, object storage for evidence and media, ru, uz, en localisation files, and Docker Compose for consistent environments.

Moving hosting changes database, storage, email, map and domain configuration, while keeping application code and data structure. Standard PostgreSQL, S3-compatible storage and configuration outside code reduce provider dependence.

Local development should use fictitious test records, not real passports, authorisations or contacts. Real evidence requires a protected server, encryption, access controls, backups and a retention policy.

11. Proposed stages

1. Directory foundation: data model, inclusion criteria, official sources, languages and page structure; university and programme search, filters, maps, comparisons and freshness labels.
2. Accounts and workspaces: applicant, representative and administrator roles, verification applications, institutional editing, versions and moderation.
3. Interaction: favourites, subscriptions, events, public questions, official answers and deadline notifications.
4. Integrations and analytics: official-source imports, spreadsheets and APIs, institutional analytics and anonymous applicant indicators.

12. Decisions to establish

Define eligible institutions and the primary registry; moderation rules; acceptable evidence and retention periods; responsibility for Uzbek translations; Latin-only or also Cyrillic user content; necessary applicant data; permitted notifications and channels; launch scope; and the personal-data operator and publication-policy owner.

This concept describes the target product. It does not verify any institution’s facts. Directory content requires separate work against agreed official sources.

13. Public “About” section

Partners should access the current concept through the main menu in all three languages. The original Markdown file is the single source for the Russian page. Public content explains the purpose, evidence principles, participant roles, representative verification, moderation and development stages. It must exclude internal addresses, personal information, evidence documents, secrets, infrastructure credentials and security-bypass instructions.

Updates should reach the site at the next build or through controlled publication. Translations are separate versions with a status and synchronisation date.

14. AI Inspector

The Inspector is an internal development tool. It builds a compact index so an AI assistant can locate relevant code and documentation without repeatedly reading the whole project. It is separate from the planned translation assistant and does not decide which university facts are true. Read the public explanation.