Концепция интерактивного справочника вузов Узбекистана

Статус: рабочая концепция
Дата фиксации: 6 сентября 2026 года
Языки продукта: русский, узбекский, английский

1. Назначение проекта

Проект — единый многоязычный справочник вузов и образовательных программ Узбекистана. Он должен помогать абитуриенту найти программу, проверить условия обучения, сравнить варианты и перейти к официальному способу поступления.

Одновременно это рабочая платформа для самих вузов. После подтверждения полномочий представитель получает доступ к странице своего учреждения, поддерживает сведения в актуальном состоянии и отвечает за внесённые изменения. Администратор платформы подтверждает учреждения и представителей, контролирует источники, рассматривает спорные правки и управляет безопасностью.

По модели взаимодействия проект можно считать профессиональной сетью вузов, но публичная часть остаётся прежде всего справочником. У каждого учреждения есть официальная страница, подтверждённые представители, новости и события; у абитуриентов — профиль, избранное, сравнения и подписки.

2. Основные принципы

1. Программа важнее рекламного описания. Абитуриент сравнивает конкретные программы: квалификацию, язык, формат, город, стоимость, гранты, сроки и требования.
2. У каждого факта есть происхождение. Для цены, срока подачи, проходного требования, лицензии и другого изменяемого сведения хранятся источник, дата проверки и ответственный редактор.
3. Официальные и редакционные данные разделены. Государственный статус и лицензия не должны меняться обычным редактором вуза. Описание кампуса, фотографии, контакты и события может поддерживать подтверждённый представитель.
4. Изменения прозрачны и обратимы. Система сохраняет версии, автора, время, причину изменения и позволяет сравнить или откатить редакции.
5. Три языка равноправны. Интерфейс хранится в файлах локализации, а переводимые сведения о вузах и программах — в базе данных. Для каждого текста видны язык оригинала, состояние перевода и дата обновления.
6. Минимум персональных данных. Профиль абитуриента хранит только сведения, необходимые для работы выбранных функций. Внутренние контакты представителей не публикуются без отдельного согласия.
7. Справочник не подменяет официальный приём. Пока платформа не интегрирована с официальной системой подачи документов, она показывает проверенную информацию и ведёт пользователя на официальный канал поступления.

3. Пользователи и права

Посетитель

Ищет вузы и программы, использует фильтры, карту и сравнение, читает информацию без регистрации.

Абитуриент

Создаёт профиль, сохраняет программы и сравнения, подписывается на вузы, получает напоминания о сроках и задаёт вопросы через предусмотренный публичный канал. Чувствительные данные об оценках и документах не нужны для первой версии.

Представитель вуза

Редактирует только закреплённые за ним учреждения и программы в пределах выданных прав. Для одного вуза можно назначить нескольких представителей с разными ролями: владелец профиля, редактор программ, редактор новостей, только просмотр аналитики.

Модератор

Проверяет заявки представителей, новые страницы, правки ключевых полей, жалобы и расхождения с источниками.

Администратор

Управляет реестром вузов, пользователями, ролями, политиками публикации, справочниками, интеграциями, журналами действий и резервным восстановлением. Доступ администратора должен быть защищён многофакторной аутентификацией.

4. Структура справочника

Страница вуза

• официальное и краткое название на трёх языках;
• статус учреждения и форма собственности;
• идентификатор в официальном реестре, лицензия или аккредитация со ссылкой на источник;
• адреса, кампусы, географические координаты и официальные контакты;
• официальный сайт и проверенные социальные каналы;
• описание, специализация, инфраструктура и доступность;
• общежития, студенческая поддержка, международные возможности;
• фотографии и видео с указанием правообладателя;
• список образовательных программ;
• дни открытых дверей, новости и объявления;
• подтверждённые публичные представители, если они согласились отображаться;
• дата последней проверки и история изменений.

Страница программы

• вуз, факультет, кампус и направление;
• уровень образования и присваиваемая квалификация;
• форма и продолжительность обучения;
• языки обучения;
• стоимость по учебному году и валюта;
• гранты, стипендии и доступные льготы;
• количество мест, если опубликовано официально;
• требования, экзамены, необходимые документы;
• сроки приёма и дата начала обучения;
• аккредитация и источник сведений;
• официальный адрес подачи заявления;
• дата проверки каждого изменяемого блока.

Значения, которые отсутствуют в надёжном источнике, показываются как «не опубликовано» или «требует подтверждения». Они не заполняются предположениями.

5. Подтверждение полномочий представителя

Предлагается многоступенчатая проверка, а не выдача доступа только по адресу электронной почты.

1. Пользователь создаёт учётную запись, подтверждает email и телефон и включает второй фактор входа.
2. Он выбирает вуз и указывает должность, рабочие контакты и требуемый уровень доступа.
3. Система проверяет email на официальном домене вуза. Совпадение домена усиливает заявку, но само по себе не завершает проверку.
4. Заявитель прикладывает один из документов: официальное письмо на бланке, доверенность или подтверждение руководителя/ответственного подразделения. Файл доступен только уполномоченному администратору.
5. Модератор сверяет вуз с официальным реестром, домен и контакты — с официальным сайтом, а полномочия — через независимый канал: звонок на опубликованный общий номер или письмо на официальный адрес, полученный не из заявки.
6. Решение и основание фиксируются в журнале. После одобрения учётная запись связывается с конкретным вузом и получает минимально необходимые права.
7. Вуз назначает основного владельца профиля. Передача роли владельца требует повторной проверки.
8. Полномочия периодически подтверждаются, например раз в год, а также после смены домена, должности или длительной неактивности. Администратор может немедленно приостановить доступ.

Для филиалов и нескольких юридических лиц связь должна быть явной: один представитель не получает автоматически доступ ко всей группе учреждений.

6. Редактирование и публикация

Каждая правка проходит состояния: черновик → на проверке → опубликовано / отклонено → архив.

На первом этапе все изменения представителей лучше модерировать. После накопления истории надёжным вузам можно разрешить сразу публиковать низкорисковые поля: описание, фотографии, события и общие контакты. Стоимость, сроки приёма, требования, лицензии, статус и официальные идентификаторы продолжают проходить проверку или автоматическую сверку с источником.

Для каждой версии сохраняются:

• автор и организация;
• время и перечень изменённых полей;
• комментарий редактора;
• источник и дата его проверки;
• решение модератора и причина отклонения;
• предыдущая опубликованная версия для быстрого отката.

На публичной странице следует показывать понятные отметки: «вуз подтверждён», «данные обновлены представителем», «проверено редакцией», «источник — официальный реестр», «информация устарела». Значок подтверждения относится к личности и полномочиям представителя, а не означает оценку качества образования.

7. Административная панель

Отдельная закрытая панель должна включать:

• обзор новых заявок, ожидающих правок, жалоб и просроченных данных;
• реестр вузов, филиалов, программ и официальных идентификаторов;
• карточку представителя: ФИО, должность, служебные контакты, закреплённые вузы, уровень доступа, документы проверки, даты выдачи и окончания полномочий;
• очередь модерации с визуальным сравнением старой и новой версии;
• управление ролями и точечными разрешениями;
• журнал входов, изменений, решений и административных действий;
• контроль источников и напоминания об истечении сроков актуальности;
• управление справочниками фильтров и качеством переводов;
• обработку жалоб, запросов на исправление и конфликтов между представителями;
• статус интеграций, резервных копий и технических проверок.

Под словом «ключи» нужно разделять два типа данных. Контакты, идентификаторы учреждений и сведения о доступе можно хранить в защищённой базе и показывать только администраторам с соответствующим правом. Пароли пользователей хранятся только в виде стойких хешей. API-ключи, ключи карт, почты и других сервисов хранятся в переменных окружения локальной системы, а на хостинге — в специальном хранилище секретов. В админ-панели показываются назначение, владелец, срок и последние символы ключа, но не полное значение. Такой подход соответствует рекомендациям OWASP по управлению секретами.

8. Функции профессиональной сети вузов

После надёжного справочника можно добавить:

• подтверждённые новости, дни открытых дверей и объявления вузов;
• подписки абитуриентов на вузы и программы;
• публичные вопросы и официальные ответы представителей;
• совместные программы, партнёрства и академическую мобильность;
• страницы факультетов, исследовательских центров и лабораторий;
• календарь приёмных кампаний и персональные напоминания;
• вакансии, стажировки и мероприятия для студентов;
• статистику просмотров и интереса для представителей без раскрытия личности абитуриентов.

Личные сообщения между абитуриентами и представителями лучше отложить: они требуют усиленной защиты от спама, мошенничества и нежелательных контактов. На раннем этапе безопаснее публичные вопросы с модерацией и официальные контактные формы.

9. Что добавить с учётом мирового опыта

1. Самообслуживание вузов с централизованной проверкой. Немецкий Hochschulkompass публикует данные государственных и признанных вузов, а сведения обновляют сотрудники самих учреждений. Это близкая модель для нашего проекта: описание Hochschulkompass, критерии включения.
2. Богатая официальная страница учреждения. UCAS позволяет провайдерам дополнять профиль медиа, сведениями о кампусе, студенческой жизни и поддержке, при этом сведения о курсах связаны с общей системой: UCAS Provider Pages.
3. Сравнение конкретных программ, а не только вузов. Discover Uni сопоставляет курсы и явно сообщает период, размер выборки и ограничения показателей: руководство по сравнению.
4. Разделение источников данных. Discover Uni сочетает сведения, поданные учреждениями, официальную статистику и результаты исследований, объясняя происхождение каждого показателя: о данных Discover Uni, информация для вузов.
5. История правок. В MediaWiki каждое изменение создаёт отдельную версию с автором и временем; версии можно сравнивать и откатывать. Нам нужна такая же логика, но с более строгими правами на официальные поля: модель версий MediaWiki.
6. Карточка достоверности данных. Рядом с важным значением полезно показывать источник, период действия, дату последней проверки и тип подтверждения. Это важнее общего значка «проверено».
7. Контроль актуальности. Система должна заранее напоминать вузу о необходимости подтвердить стоимость, сроки и программы следующего учебного года, а просроченные сведения помечать автоматически.
8. Импорт и экспорт. Вузам стоит дать загрузку программ из таблицы и позднее API. Это уменьшит ручную работу и позволит использовать один проверенный набор данных в нескольких системах.
9. Калькулятор полной стоимости. Помимо контракта, сравнение может учитывать общежитие, транспорт и другие опубликованные расходы, всегда с датой и источником.
10. Нейтральность результатов. Платное продвижение, если оно появится, должно явно помечаться и не влиять скрытно на органический порядок поиска.

Отзывы и рейтинги студентов можно добавить позднее, когда будут правила подтверждения обучения, модерации и методика расчёта. До этого лучше показывать проверяемые факты и официальные показатели, а не создавать псевдоточную оценку вузов.

10. Техническая и хостинговая модель

Разработка может полностью идти локально. Рекомендуемый стек остаётся переносимым:

• Next.js и TypeScript — публичный сайт и кабинеты;
• Django и Django REST Framework — серверная логика, роли, модерация и административная панель;
• PostgreSQL — основная база данных;
• объектное хранилище — документы подтверждения и медиа;
• файлы локализации ru, uz, en — системный интерфейс;
• Docker Compose — одинаковый запуск локально и на сервере.

При переносе меняются адрес базы, хранилища, почтового сервиса, карт и домена; прикладной код и структура данных остаются теми же. Для независимости от одного поставщика следует использовать стандартный PostgreSQL, S3-совместимое хранилище и хранить конфигурацию вне кода.

Локальная разработка не означает хранение реальных паспортов, доверенностей и контактов в тестовой базе. До появления защищённого сервера используются вымышленные тестовые записи. Реальные документы представителей загружаются только после настройки шифрования, разграничения доступа, резервного копирования и политики хранения.

11. Предлагаемые этапы

Этап 1. Основа справочника

Согласовать модель данных, критерии включения вузов, перечень официальных источников, три языка и структуру страниц. Создать каталог вузов и программ с поиском, фильтрами, картой, сравнением и отметками актуальности.

Этап 2. Учётные записи и кабинеты

Добавить абитуриентов, представителей и администраторов; заявки на подтверждение полномочий; кабинет вуза; версии и очередь модерации.

Этап 3. Взаимодействие

Добавить избранное, подписки, события, публичные вопросы и официальные ответы, уведомления о сроках.

Этап 4. Интеграции и аналитика

Подключить официальные источники, импорт таблиц и API, аналитику для вузов и обезличенные показатели для абитуриентов.

12. Решения, которые нужно принять до разработки

• какие учреждения имеют право попасть в каталог и какой реестр считается основным;
• должны ли все правки проходить модерацию или часть полей публикуется сразу;
• какие документы допустимы для подтверждения представителя и сколько они хранятся;
• кто отвечает за узбекскую версию: сам вуз, редакция или совместный процесс;
• будет ли узбекский интерфейс поддерживать только латиницу или также кириллицу в пользовательском контенте;
• какие данные об абитуриенте действительно нужны первой версии;
• какие уведомления разрешены и через какие каналы;
• нужен ли при запуске только справочник или также публичные вопросы и подписки;
• кто юридически является оператором персональных данных и утверждает правила публикации.

Эта концепция описывает целевой продукт. Она не подтверждает сведения о конкретных вузах; фактическое наполнение должно выполняться отдельно по согласованному перечню официальных источников.

13. Публичный раздел «О проекте»

Актуальная версия этой концепции должна быть доступна партнёрам через пункт главного меню «О проекте» на всех трёх языках. Исходный Markdown-файл является единым источником русской версии страницы, чтобы сайт и проектная документация не расходились.

Публичная страница должна содержать назначение проекта, принципы достоверности, роли участников, порядок подтверждения представителей, общую модель модерации и этапы развития. Перед публикацией в ней не должно быть внутренних адресов, персональных данных, документов проверки, секретов, технических реквизитов инфраструктуры или инструкций, упрощающих обход защиты.

При изменении концепции сайт должен получать обновлённое содержимое автоматически при следующей сборке или через управляемую публикацию из административной панели. Переводы хранятся как отдельные версии содержимого с указанием состояния и даты синхронизации с русским оригиналом.

14. ИИ-инспектор проекта

ИИ-инспектор является обязательным внутренним инструментом разработки. Его задача — преобразовывать проект в компактный структурированный индекс, чтобы ИИ мог быстро находить нужные части системы и получать минимальный достаточный контекст без повторного чтения всего репозитория.

Подробная архитектура, требования безопасности и этапы реализации описаны в документе «ИИ-инспектор проекта».