Очевидно, что такая структура операционной системы требует особого подхода к организации взаимодействия разработчиков модулей с разработчиками операционной системы: в высшей степени наивно было бы полагать, что разработчики операционной системы смогут за один раз составить набор интерфейсов, покрывающий все будущие способы применения устройств под управлением данной ОС. Напротив, организация всеобщей совместимости требует непрерывного двустороннего сотрудничества между разработчиками ОС, предоставляющей интерфейсы и прототипы, и разработчиками ПО, использующего их.
Каждый интерфейс характеризуется целочисленным номером версии. С увеличением версии интерфейс может дополняться новыми сущностями, однако удаление или переделка уже существующих сущностей не допускается.
Все версии интерфейса совместимы между собой. В случае совпадения фактически реализуемого объектом и ожидаемого вызывающим контекстом номеров версий такая совместимость очевидна. Если фактически используемый объект реализует более высокую версию интерфейса, чем ожидает вызывающий контекст, то часть данных и функций, предоставляемых интерфейсом, попросту не используется. Если же объект реализует более низкую версию, чем ожидается, то при обращении к фактически не реализованным сущностям вызываются обработчики по умолчанию, работа которых основана на данных и алгоритмах, уже представленных в более ранней версии интерфейса. Так, если более поздняя версия интерфейса «Статья» добавляет к доступным через интерфейс данным поле «Текст рекламы», которое в некоторых изданиях используется, например, на баннерах, открывающих доступ к полному тексту статьи, то для совместимости обработчик по умолчанию может использовать в качестве такого текста первый абзац или первое предложение полного текста. Другой подход состоит в возврате специальных значений (исключений) «Не реализовано» при обращении к недоступным данным, что перекладывает обязанности по обработке подобных ограничений на вызывающий контекст.
Схожие правила применяются при изменении версий прототипов модулей. Поскольку основная задача модуля состоит в реализации интерфейсов данных, мы не будем останавливаться на этом подробнее.
Распространение интерфейсов происходит централизовано через репозиторий, поддерживаемый командой разработчиков операционной системы. Подгрузка новых версий осуществляется при обновлении операционной системы. Существование других репозиториев, распространяющих интерфейсы, не допускается, поскольку оно поставит крест на всеобщей совместимости, являющейся основной целью создания ОС «Сивелькирия». Единственным исключением могут быть внутрикорпоративные репозитории, используемые в случаях, когда сам факт разработки некоторых интерфейсов является коммерческой тайной. Такие интерфейсы, однако, не могут выходить за пределы фирм, использующих их для своей внутренней работы.
Распространение модулей возможно как через репозиторий, поддерживаемый командой разработки операционной системы, так и через репозитории, поддерживаемые третьими сторонами (фирмами, выпускающими коммерческое ПО, сообществами, разрабатывающими ПО с открытым исходным кодом, корпоративными серверами и т. п.). При этом центральный репозиторий, поддерживаемый командой разработки ОС, позиционируется в качестве основного, поскольку предоставляет некоторые ункальные сервисы.
Так, при загрузке новых версий модулей в репозиторий производится их тестирование с использованием пополняемой библиотеки интеграционных и модульных тестов, а также тестов производительности. Информация о прохождении таких тестов становится доступна как разработчикам, так и пользователям. При добавлении новых тестов они применяются также и к более старым версиям модулей, присутствующих в репозитории. Все тесты, предоставляемые центральным репозиторием, доступны всем разработчикам для использования как внутри него, так и на собственной инфраструктуре; единственное исключение состоит в противодействии оптимизации модулей под конкретные тесты в ущерб использованию в общем контексте.
Кроме того, центральный репозиторий собирает информацию обо всех модулях, доступных в других открытых репозиториях, а также по мере возможности выполняет их тестирование, хотя загрузка таких модулей по-прежнему доступна только из разместивших их репозиториев. Это позволяет пользователям иметь всю информацию о доступных модулях в одном месте, а разработчикам ПО — получать дополнительную раскрутку своих собственных репозиториев (магазинов).
Наконец, центральный репозиторий помогает осуществлять арбитраж в спорных случаях (например, при распространении нелицензионного ПО третьими лицами). Создание стороннего репозитория невозможно без регистрации в центральном репозитории (включая внутрикорпоративные репозитории); команда поддержки центрального репозитория имеет полномочия и возможности блокировать нарушителей правил (пиратов, хакеров, разработчиков ПО с закрытой архитектурой) как на уровне отдельных модулей, так и на уровне целых сторонних репозиториев.