Платформа Vitiana API Plus — обзор

Версия: 1.0 Дата: 26.04.2026 Статус: Готов к обсуждению

Назначение этого документа

Этот документ написан простым языком без технических особенностей и терминов.

Документ объясняет: что такое платформа Vitiana API Plus, дальше "платформа Vitiana", какие задачи бизнеса она решает, кто и как на ней зарабатывает, чем она отличается от существующих систем, в каких странах работает, какие сроки и инвестиции реально требуются, и чего она сознательно не делает.

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

Что такое платформа Vitiana — короткий ответ

Платформа Vitiana — это технологическая платформа для туристической индустрии, которая объединяет данные от множества поставщиков туристических услуг и продаёт доступ к этим объединённым данным разным каналам продаж.

Если совсем просто — платформа Vitiana работает как современный «оптовый рынок туристических услуг», на котором:

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

При этом платформа Vitiana — не «ещё один сайт по продаже отелей». Сайт у Vitiana есть (например, vitrip.store), он работает как один из каналов продаж, но сама платформа значительно больше сайта.

Какую проблему решает платформа

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

Каждое туристическое агентство, каждая онлайн-витрина, каждый корпоративный сервис путешествий, который хочет продавать туры или отели:

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

Это огромный объём работы. Большинство малых и средних игроков на рынке либо не справляются (продолжают работать вручную), либо упрощают работу (снижают качество), либо отказываются от собственного канала (становятся посредниками крупных игроков на их условиях).

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

• единый формат данных от всех поставщиков;
• проверка качества данных и обнаружение проблем;
• готовые инструменты для бронирования, отмен, изменений;
• единый рабочий кабинет для агентств;
• единый программный интерфейс (API) для технических партнёров;
• готовые витрины (в случае нашего собственного канала vitrip.store);
• модуль сборки сложных туров (Tour Builder).

Покупатель платформы платит за доступ к этому платформенному слою — за труд платформы, не за «количество найденных отелей».

Главная новизна — Tour Builder

Большинство туристических платформ на рынке — это «каталоги отелей с возможностью бронирования». То есть один отель за раз. Если клиент хочет «3 дня в Праге, потом 5 дней в Карловых Варах с трансфером и экскурсией» — этим занимается человек-агент вручную, иногда по полдня.

Tour Builder — это технология автоматической сборки сложных туров, основное конкурентное преимущество платформы Vitiana.

Tour Builder позволяет собирать тур из модулей:

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

Tour Builder проверяет, что компоненты совместимы между собой:

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

Tour Builder работает в двух режимах:

1. Vitiana собирает свои собственные туры — для продажи через сайт vitrip.store. Например, готовая программа «Прага + Карловы Вары + экскурсия в Кутна-Гора, 8 дней».
2. Партнёры с платным доступом собирают свои туры — корпоративные службы путешествий, белые-лейбл-витрины, специализированные туроператоры используют наш Tour Builder для создания собственных продуктов.

Возможность собирать сложные туры через программный интерфейс (API) — это редкое свойство на рынке. Большинство конкурентов имеют только базовое бронирование отдельных отелей или авиабилетов.

Кто заказчики и партнёры платформы

Платформа Vitiana обслуживает четыре основных типа покупателей:

Покупатель 1. Туристические агентства

Малые и средние агентства в Украине, Чехии, Польше, Казахстане. Они:

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

Покупатель 2. Технические партнёры с платным API

Это разработчики и компании, которые встраивают данные и возможности Vitiana в свои собственные продукты:

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

Они получают:

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

Они платят:

• по динамическому тарифу — стоимость зависит от реальной нагрузки, которую партнёр создаёт на платформу.

Покупатель 3. Конечные клиенты собственных сайтов Vitiana

Сайт vitrip.store — это собственная B2C-витрина платформы для конечных туристов. Они покупают туры напрямую у Vitiana, и Vitiana получает обычную туристическую маржу.

Vitrip.store работает одновременно как:

• источник дохода (собственные продажи);
• демонстрация возможностей платформы для технических партнёров (партнёр видит, что можно построить на нашем API).

Покупатель 4. Крупные корпоративные клиенты (Enterprise)

Крупные туристические сети, корпоративные службы путешествий международных компаний, авиакомпании-агенты могут заключать индивидуальные контракты на:

• выделенную инфраструктуру;
• расширенный уровень обслуживания (SLA);
• персонального инженера сопровождения;
• кастомные коммерческие условия (revenue-share, гибридные модели).

Этот сегмент развивается на третьей-четвёртой фазе зрелости платформы.

География первой волны

Платформа выходит на рынок последовательно. Первая волна — это страны, рынки которых мы знаем и где у нас есть базовое supplier-покрытие через поставщиков:

• Украина (UA) — основной начальный рынок;
• Чехия (CZ) — второй рынок, входной EU-юрисдикции;
• Польша (PL) — расширение в EU;
• Казахстан (KZ) — расширение на восток.

Платформа поддерживает основные региональные языки и валюты:

• украинский, русский, английский, в перспективе чешский, польский — рабочие языки;
• евро - как основная валюта, украинская гривна, чешская крона, польский злотый, казахстанский тенге, доллар США — рабочие валюты конвертации.

Дальнейшее расширение по географии — на третьей-четвёртой фазах зрелости.

Чем платформа Vitiana отличается от Booking.com, Expedia и других

Booking.com, Expedia, Airbnb, Trivago — это B2C-витрины (продают конечным клиентам). Они хорошо известны, у них огромный маркетинговый бюджет, и на их территории конкурировать с ними напрямую — экономически неоправданно.

Vitiana работает в другом сегменте:

• основная монетизация — через B2B-доступ к платформе (продажа API);
• собственная B2C-витрина (vitrip.store) — это вспомогательный канал и демонстрация, не основной;
• ключевое преимущество — Tour Builder, которого в нужном виде нет ни у одного крупного конкурента;
• ключевая география — восточная Европа и Казахстан, где Booking и Expedia слабее представлены в B2B-сегменте.

Прямые конкуренты по сегменту B2B-API:

• TravelgateX (международный) — крупный, но не специализирован на восточной Европе и не имеет Tour Builder в формате модульного API;
• HotelBeds Apitude (международный) — большой, но фокусирован на отелях, без полноценного Tour Builder;
• Sabre, Amadeus — глобальные распределительные системы, но они работают в основном с авиакомпаниями и крупными корпоративными клиентами, для малого и среднего B2B-сегмента слишком сложны и дороги;
• Региональные конкуренты в восточной Европе — есть, но они либо только агентские платформы, либо без Tour Builder, либо без серьёзной технологии.

Главное отличительное предложение Vitiana:

• единственная платформа в восточной Европе, специализированная на B2B-API marketplace для туристической индустрии с модульным Tour Builder;
• открытая для самостоятельной интеграции (партнёры регистрируются и интегрируются сами, без длительных переговоров);
• прозрачная динамическая тарификация (партнёр видит реальную стоимость и предсказывает счёт);
• готова обеспечить соответствие требованиям регуляторов нескольких стран одновременно.

Как платформа зарабатывает — три источника дохода

Источник 1. Собственные продажи через vitrip.store

Это обычная B2C-маржа: турист покупает тур или отель на сайте, Vitiana получает разницу между ценой поставщика и ценой клиента. Размер маржи — стандартная отраслевая, динамически настраиваемая по сегментам.

Источник 2. Партнёры с платным API — главный долгосрочный источник

Партнёр платит платформе за доступ к платформенному слою, а не за «количество отелей». Тариф зависит от реальной нагрузки, которую партнёр создаёт:

• объём поисковых запросов;
• объём созданных коммерческих предложений (quote);
• объём бронирований;
• сложность запросов (узкая или широкая география, простые или сложные фильтры);
• использование «дорогих» поставщиков (некоторые поставщики имеют высокие лимиты вызовов или платные API);
• использование машинного обучения (рекомендации, ранжирование, динамическое ценообразование);
• использование Tour Builder (тяжёлая операция);
• объём данных, которые партнёр хранит у нас.

Тарифные уровни:

Уровень	Для кого	Что включено
Free	Разработчики, оценивающие платформу	Песочница с реалистичными тестовыми данными, ограниченный объём для тестирования
Starter	Малые партнёры	Боевой доступ с минимальными квотами, базовый набор поставщиков, стандартная поддержка
Professional	Растущие партнёры с реальным объёмом	Расширенные квоты, полный набор поставщиков, доступ к Tour Builder, партнёрская аналитика, повышенный SLA
Enterprise	Крупные корпоративные клиенты	Гарантированная мощность, кастомные коммерческие условия, выделенная инфраструктура (на четвёртой фазе), персональный инженер сопровождения

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

Источник 3. Туристические агентства — рабочая платформа

Агентство платит за рабочий кабинет на платформе:

• подписка на месяц/год;
• комиссия с продаж;
• опциональный платный доступ к Tour Builder.

Размер подписки и комиссии — зависит от тарифного уровня агентства и объёма продаж.

Цепочка ответственности — кто отвечает за что

Платформа работает по классической модели агрегатора с гибридной структурой ответственности:

поставщики (отели, авиакомпании, экскурсии)
   ↓ инвентарь, цены, обещания исполнения
   
платформа Vitiana
   ↓ нормализация, проверка качества, ответственность перед поставщиком, частичная ответственность перед клиентами
   
покупатели платформы (агентства, технические партнёры, vitrip.store)
   ↓ доступ к платформенному слою, ответственность перед своими клиентами
   
конечные клиенты
   ↓ оплата, потребление туристического продукта

Кто за что отвечает:

• Поставщики отвечают за фактическое исполнение туристической услуги (отель открыт, номер забронирован, перелёт совершён).
• Vitiana отвечает за корректное представление данных поставщиков своим покупателям, своевременную обработку бронирований, корректные взаиморасчёты с поставщиками, целостность платформы.
• Покупатели платформы (партнёры, агентства) отвечают за своё представление данных конечным клиентам, маркетинг, обслуживание клиентов, обработку платежей (если они принимают деньги напрямую) и информацию для своих клиентов.
• Конечные клиенты отвечают за корректные данные при бронировании, оплату, соблюдение условий поставщика.

В зависимости от тарифа партнёра возможны разные модели приёма платежей:

• Платформа сама принимает платёж от конечного клиента (актуально для собственного канала vitrip.store и для агентств с базовым тарифом без своей платёжной системы).
• Партнёр сам принимает платёж (актуально для крупных B2B-партнёров со своей платёжной инфраструктурой). Партнёр получает счёт от платформы за платформенные услуги.
• Гибрид — для разных продуктов разные модели.

В каких странах работаем — соответствие требованиям

Платформа изначально проектируется с учётом регуляторов в каждой целевой стране:

• Общий регламент защиты данных (GDPR, регламент EU 2016/679) — обязателен для всех граждан EU (Чехия, Польша, обширная EU-аудитория). Защищает персональные данные конечных клиентов.
• Директива EU о пакетных туристических продуктах (Package Travel Directive 2015/2302) — применяется к турам из нескольких компонентов в EU. Требует страхования финансовой несостоятельности (insolvency protection), полного информирования клиентов перед заключением договора, ответственности за исполнение.
• Маржинальный режим НДС для туроператоров (TOMS) — особый налоговый режим для трансграничных туристических продуктов в EU.
• Стандарты безопасности платежей (PCI DSS) — при приёме платежей картами.
• Усиленная аутентификация клиентов (PSD2 SCA) — при онлайн-платежах в EU.
• DAC7 и Digital Services Act (DSA) — обязательства платформ по отчётности и прозрачности.
• AML/KYC (Anti-Money Laundering / Know Your Customer) — проверка партнёров на признаки отмывания денег.
• Налоговые режимы Украины и Казахстана — отдельные от EU, требуют отдельного учёта и отчётности.
• Локальная защита прав потребителей — каждая юрисдикция имеет свои особенности (сроки возврата, обработка споров).

Все требования встраиваются в платформу как стандартный набор, не как «потом разберёмся». Это значительная часть инвестиций в разработку, но обеспечивает работу платформы без юридических проблем.

Чего платформа сознательно не делает

Чтобы границы продукта были честными:

• Платформа не конкурирует напрямую с Booking.com за конечных клиентов. Vitrip.store — собственный канал и демонстрация, не основной источник дохода.
• Платформа не подражает структуре одного поставщика. Внутренние данные платформы организованы по собственной модели; поставщики переводятся в эту модель адаптерами. Это означает, что любой поставщик может быть отключён или заменён без переделки платформы.
• Платформа не делает «белый-лейбл-сайт под ключ» для каждого партнёра. Партнёр получает API и инструменты; собственный сайт партнёр строит сам, на нашем API.
• Платформа не принимает на себя обязательство партнёра перед его клиентами. Если партнёр продаёт через свой канал и принимает платёж, ответственность перед его клиентами лежит на партнёре. Это нормальная практика B2B-distribution.
• Платформа не обещает быстрых результатов. Зрелая платформа уровня top-tier строится 30-36 месяцев. Любые обещания «за 6 месяцев под ключ» — это либо MVP с серьёзными ограничениями, либо неправда.

Реалистичные сроки и инвестиции

Этот раздел — для инвестора и совета директоров. Цифры — оценочные, в долларах США.

Этапы развития

Платформа развёртывается по фазам с метрическими и доменными триггерами перехода — не по календарю.

Фаза	Длительность от старта	Что происходит
Фаза 1 — Запуск (Bootstrap)	0-12 месяцев	Сборка ядра платформы, разработка каноничной модели, прототип подключения второго поставщика, базовая команда 8-12 человек, инфраструктура минимальная
Фаза 2 — Изоляция сервисов (Service isolation)	12-24 месяца	Раздельная инфраструктура для разных контуров, запуск партнёрского API в боевом режиме, первые платные партнёры, команда 12-18 человек
Фаза 3 — Зрелая платформа (Production-capable)	24-36 месяцев	Полная зрелая архитектура, полная география, машинное обучение в действии, premium-партнёры, команда 18-28 человек
Фаза 4 — Глобальное расширение (Multi-region и enterprise)	36+ месяцев	Многорегиональная инфраструктура, enterprise-тенанты с выделенной инфраструктурой, расширение в новые географии, команда 25-40 человек

Инвестиции до зрелой платформы (фаза 3, 30-36 месяцев)

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

Сценарий	Что входит	Инвестиции в разработку
Минимум разумного	Узкая первая волна (2 страны), 2 поставщика, без полного машинного обучения, без полноценного Enterprise-уровня	$3.5–5 млн
Реалистичный зрелый сценарий	Вся первая волна (4 страны), 3-5 поставщиков, полное машинное обучение, полный B2B API marketplace, Tour Builder, partner-facing аналитика	$5–8 млн
Зрелая Enterprise-готовая платформа	Многорегиональная инфраструктура, выделенная инфраструктура для крупных клиентов, полная сертификация (SOC 2, ISO 27001)	$8–15 млн

Сюда входит: разработка, тестирование, архитектурное руководство, продакт-менеджмент, операции (DevOps), безопасность, начальная инфраструктура.

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

Инфраструктурные расходы

Серверные расходы (облачная инфраструктура у OVHcloud, основной провайдер):

Фаза	Длительность	Расходы инфраструктуры в год
Фаза 1	0-12 мес	$800–2900
Фаза 2	12-24 мес	$17 000–31 000
Фаза 3	24-36 мес	$77 000–166 000
Фаза 4	36+ мес	$130 000–300 000+

Это исключительно расходы на серверы и управляемые сервисы. Стоимость растёт по мере роста количества платных партнёров и объёма данных, но полностью покрывается платой партнёров.

Сроки до первого боевого запуска

• 6-9 месяцев от старта — внутренний запуск (controlled internal platform) с прототипом, на котором видна работа на реальных данных от поставщиков;
• 12-18 месяцев — первый боевой запуск с первыми платными партнёрами и реальной выручкой;
• 24-30 месяцев — зрелый партнёрский маркетплейс с десятками активных партнёров;
• 30-36 месяцев — переход в фазу глобального расширения.

Когда платформа окупается

Это зависит от темпа привлечения партнёров. Реалистичный прогноз:

• К 18 месяцу — первые 3-5 платных партнёров, начало регулярной выручки от B2B API;
• К 24 месяцу — 10-20 платных партнёров, выручка от B2B API становится основной;
• К 30 месяцу — 30-50 платных партнёров, операционная окупаемость текущих расходов;
• К 36-42 месяцу — окупаемость накопленных инвестиций при разумном темпе роста.

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

Что нужно для успеха

Для того, чтобы платформа достигла зрелости и окупаемости:

1. Команда уровня senior+. Платформа верхнего уровня требует опытных инженеров, не junior-команды. Команда 12-18 человек на фазе 2, 18-28 на фазе 3.
2. Архитектурная дисциплина. Все принципы (правило 00000, развитие без деградации, тезисное обоснование, удержание контекста) — соблюдаются на протяжении всей разработки.
3. Партнёрская стратегия. Параллельно с разработкой ведётся работа с потенциальными партнёрами: формирование тарифов, юридические договоры, программа сертификации. Без потока партнёров технология не окупается.
4. Юридическая поддержка нескольких юрисдикций. Соответствие требованиям регуляторов EU, Украины, Казахстана требует внимания и квалифицированного юриста.
5. Дисциплина фазового развёртывания. Не пытаться сразу строить всё одновременно. Каждая фаза достигается по триггерам, не по календарю.

Открытые вопросы для решения заказчика

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

1. Какой бюджет реально доступен на первые 12-24 месяца? От ответа зависит размер команды и темп фаз.
2. Сколько крупных партнёров планируется привлечь к моменту фазы 3? От этого зависит, насколько быстро нужна инфраструктура уровня enterprise.
3. Какова стратегия маркетинга и продаж B2B API? Платформа технически готова, но требуется план привлечения партнёров.
4. Кто принимает платежи от конечных клиентов на собственном канале vitrip.store? Платформа сама как merchant-of-record (требует регистрации и сертификации) или внешний платёжный сервис?
5. Какие конкретные партнёрские тарифы (цены) запускаются на старте? Архитектура поддерживает динамическую тарификацию; конкретные цены — коммерческое решение.
6. Готовы ли инвесторы к 30-36-месячному горизонту до зрелой выручки? Если короче — необходимо сокращение архитектурного scope.

Что делать дальше — для каждой роли читателя

Если читатель — инвестор:

1. Прочитать этот документ.
2. Прочитать архитектурный якорь и бизнес-модель для понимания экономической логики.
3. Прочитать манифест переосмысления платформы для понимания позиционирования.
4. Запросить детализированный финансовый прогноз и план продаж.
5. Запросить состав команды и резюме ключевых членов.

Если читатель — потенциальный партнёр (B2B API):

1. Прочитать этот документ.
2. Запросить документацию по партнёрскому API (она будет готова в фазе 2).
3. Запросить доступ к песочнице (sandbox) после её запуска в фазе 1.
4. Обсудить интеграционные тесты, сертификацию, тарифный уровень.

Если читатель — туристическое агентство:

1. Прочитать этот документ.
2. Запросить демонстрацию рабочего кабинета (готов в фазе 2-3).
3. Обсудить тарифные условия и комиссию.

Если читатель — юрист:

1. Прочитать этот документ.
2. Запросить документ соответствия требованиям регуляторов (reference/compliance-and-legal.md, готовится в фазе 4).
3. Обсудить специфику merchant-of-record модели для конкретных юрисдикций.

Если читатель — член совета директоров или руководитель проекта:

1. Прочитать этот документ.
2. Прочитать манифест переосмысления, архитектурный якорь и главную архитектурную ось.
3. Запросить детализацию по фазам разработки.
4. Принять решения по открытым вопросам выше.

Связанная документация

Документы для общего понимания

• Главная архитектурная ось (overview/index.md) — для тех, кто хочет глубже разобраться в архитектуре.
• Манифест переосмысления платформы (overview/platform-vision-and-manifest.md) — формальное переосмысление роли платформы.
• Архитектурный якорь и бизнес-модель (overview/architectural-anchor-and-business-model.md) — детальное обоснование выбора стратегии.

Документы для технического читателя

• Платформа как продукт (overview/platform-as-product.md) — атрибуты B2B SaaS-продукта.
• Каноничная доменная ось (overview/canonical-domain-spine.md) — ключевые сущности.
• Поверхности взаимодействия (overview/layers.md) — каналы взаимодействия.
• Ось данных и интеллекта (overview/data-and-intelligence-spine.md) — события, машинное обучение, эксперимент.
• Операционная ось (overview/operational-spine.md) — масштабирование, надёжность, инциденты.

Документы для технического подрядчика

• Техническое задание для подрядчика — в development/technical-specification-for-development-contractors.md (создаётся параллельно с этим документом).
• Дорожная карта инфраструктурного масштабирования — в operations/scaling-and-packaging-roadmap.md.

Уточнение под Фазы 4–10 (28.04.2026) — обзор для стейкхолдеров

Документ опубликован 26.04.2026. После Фаз 4–10 архитектурный baseline существенно расширен — 16 новых каноничных reference и operations документов + 5 архитектурных правил + governance + team-and-staffing-plan.

Что изменилось для stakeholders

Production-readiness picture теперь полная:

• Tier model коммерческий: Free / Starter / Professional / Enterprise → 4 SLA уровня (best-effort / 95% / 99% / 99.9%) (см. api-as-product.md, sla-and-on-call-model.md);
• Tour Builder как core peer: партнёры с платным доступом получают полноценный Tour Builder с raw API + UI/SDK, не упрощённую копию (правило 00000);
• Регуляторное покрытие: GDPR + PSD2 + EU TOMS + Package Travel Directive + KZ data law от Phase 1, SOC 2 Type 1 — Phase 4, ISO 27001 — Phase 6 (см. compliance-and-legal.md);
• Безопасность: STRIDE threat model, IAM RBAC+ABAC, encryption at-rest+in-transit, automated secret rotation, supply chain security (см. security-architecture.md);
• Operational maturity: 8 каноничных incident classes с runbooks, 5-уровневая on-call structure, 4 recovery tiers с DR drills (см. runbooks-incident-playbooks.md, sla-and-on-call-model.md, disaster-recovery-and-capacity.md);
• Multi-tenant isolation: 3 уровня (logical / dedicated_compute / dedicated_infrastructure) с continuous IsolationBoundaryCheck (см. multi-tenant-isolation-strength.md);
• Data infrastructure first-class: events tracking, DWH, ETL, ML platform, A/B testing, partner-facing analytics — все с phase 1 (см. data-platform-and-events-tracking.md, ml-platform.md, ab-testing-platform.md, analytics-and-bi.md);
• Economic model синтезирован: revenue streams + cost structure + unit-economics + dynamic pricing formula (см. economic-model.md).

Stage 0 архитектурный baseline закрыт

Согласно development/roadmap.md, стадия 0 (architectural baseline) — закрыта на 100%. Следующий шаг — стадия 1 implementation baseline.

Уточнение выполнено через no-destruction.