Open Manuscript Initiative Матрица за състоянието на внедряването

Метаданни на документа

Поле	Стойност
Вид документ	Доклад за състоянието на управлението
Статус	Чернова
Версия	0.3.0
Нормативна терминология	Английски
Последно актуализирано	05.09.2026
Обхват	Всеки идентификатор в регистъра на спецификациите на „OMI“
Базова линия на доказателствата	Пълен преглед на клон „main“ от 06.08.2026 г., допълнен със спецификацията, схемата, тестовата среда, валидатора и текущия експорт от Studio .omi.json за „“ – прегледани на 05.09.2026 г.
Авторитет	Информационен характер; Регистърът на спецификациите и отделните спецификации запазват авторитетния си характер

1. Цел

В настоящия документ се отразява текущото състояние на внедряването и проверката на всеки идентификатор на спецификация, присвоен от Съвета за стандартизация на интернет (Open Manuscript Initiative).

В него се разграничават пет въпроса, които не трябва да се смесват:

1. Има ли каноничен документ със спецификациите?
2. Този документ прехвърлен ли е към актуалния шаблон за спецификация на OMI?
3. Публикувани ли са машинно четимите артефакти и приспособленията за проверка на съответствието?
4. Open Manuscript Studio прилага ли конкретни части от спецификацията?
5. Дали поведението е било валидирано, тествано за съответствие или демонстрирано независимо?

Матрицата има за цел:

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

2. Правомощия и тълкуване

„OMI Specification Registry“ е авторитетен източник за:

• постоянни идентификатори на спецификации;
• официални длъжности;
• състояния на разпределение;
• състояния на жизнения цикъл;
• точните версии;
• канонични пътища.

Отделните спецификации са определящи по отношение на съдържащите се в тях нормативни изисквания.

Тази матрица представлява доклад с информативни данни. Тя не:

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

Една спецификация може да бъде завършен документ, без да има реализация. Реализацията може да съдържа значителна функционалност, докато съответната спецификация все още е в етап на проект. Това са независими аспекти.

3. Лексика, свързана със състоянията

3.1 Спецификация и състояния на артефактите

Състояние	Значение
Активен проект	Съществува каноничен спецификационен документ, който е регистриран със статус „Проект“ в жизнения цикъл.
Запазено	Идентификаторът и предметът са определени, но все още няма приет проект на спецификация.
Текущ шаблон	Активната спецификация е създадена или изцяло преработена с помощта на текущия шаблон за спецификация.
Необходима миграция	Активният документ е създаден преди въвеждането на каноничния шаблон за спецификация или все още не съдържа всички задължителни раздели за метаданни, съответствие, съвместимост, доказателства и история на промените.
Публикуван чернови вариант на артефакта	На официално място е налице версиониран, машинно четим артефакт, но той все още е подложен на несъвместими промени преди достигането на стабилна версия.
Публикувани са първоначалните набори от тестови случаи	Има версии на положителни и отрицателни примери, но те все още не съставляват пълен набор от формални тестове за съответствие.
Не е публикувано	Съответната канонична схема, набор от тестови данни, формат на отчета или друг машинно четим артефакт не се намира в авторитетно хранилище.
Не е започнато	Не е потвърдено наличието на доказателства в хранилището за съществена работа по посоченото измерение.
Не се прилага	Посочената величина не е необходима за спецификацията в настоящия ѝ контекст.

3.2 Състояния на доказателствата за внедряване

Състояние	Значение
Проучвателен	Съществуват свързани типове, полета, концепции за потребителски интерфейс или работни потоци, но те са непълни, специфични за конкретна реализация или не са доказано съгласувани с каноничната спецификация.
Частично	Представено е или може да се използва идентифицируемо подмножество от домейна на спецификацията, но липсват основни изисквания, валидиране, оперативна съвместимост или поведение през жизнения цикъл.
Реализирано	Приложимото нормативно поведение е реализирано и съпоставено с декларирана версия на спецификацията, но формалното тестване за съответствие не е приключило.
Тествано	Реализацията разполага с автоматизирани доказателства, които покриват приложимите нормативни изисквания за декларираната версия.
Съответствие	Реализацията отговаря на публикуван клас на съответствие, като използва одобрения набор от тестове за съответствие, и отразява всички допустими ограничения.
Не е проверено	Възможно е да съществуват доказателства извън прегледаните хранилища, но те не са били проверени за тази базова линия.

Думите реализирано, тествано и съвместимо са избрани умишлено в строгия смисъл на думата. Те не трябва да се извеждат от наличието на класове, интерфейси, страници или примери с подобни наименования.

4. Изходни данни за доказателствата

При изготвянето на базовия преглед бяха използвани публичното хранилище със спецификации OMI и актуалното хранилище Open Manuscript Studio.

Доказателствата за „Verified Studio“ включват:

• обхватът „alpha“, деклариран в README.md;
• интерфейсите за ръкописи, анотации, цитиране, блокове, раздели, агенти и приноси на src/types/omi.ts и src/model/identity.ts;
• редактиране на ръкописи и действия на авторите в src/app/useStudioStore.ts;
• миграция на автори от старата версия в src/document/migrateIdentityModel.ts;
• разделяне на сметката и агента в src/model/user.ts;
• роли в работната среда, разрешения, покани, роли на рецензенти и преводачи в src/model/workspace.ts;
• настоящата реализация на работната среда с локално съхранение в src/store/workspaceStore.ts;
• тестове за идентичност и за единици-приносители в „tests/identity-model.test.ts“;
• моделът „OMI-SPEC-160@0.1.0“ (ревизия, набор от промени, събитие на промяна, моментална снимка, пълнота на историята, потвърждение и отмяна) в src/model/versioning.ts;
• миграция на историята на ревизиите само с времеви отметки в src/document/migrateVersioningModel.ts;
• многоезичният интерфейс за история на промените на адрес src/components/HistoryPanel.tsx;
• версиониране на единични тестове в tests/versioning-model.test.ts, обхващащо неизменни корени, запазване на родителските елементи, линейна история, атомарни набори от промени, връщане към предишни версии, повърхностна миграция, валидиране и експортиране.

Настоящата реализация на системата за версии беше обединена в Open Manuscript Studio чрез PR № 2 с коммит за обединяване 65f3a2f4fa9eaf6adf370f4bae5eec1e98521db2.

При пълната проверка от 06.08.2026 г. не бяха открити достоверни артефакти от хранилището OMI за:

• формат на доклад за валидиране, подходящ за машинно четене;
• набор от формални тестове за съответствие;
• независимо проверени реализации.

Актуализацията OMI-SPEC-320 от 05.09.2026 г. добавя първия каноничен вариант на схемата „JSON“, първоначален набор от осем документа с положителни и отрицателни тестови случаи, както и референтен валидатор на тестови случаи. Тези елементи обхващат структурна валидация и избрани семантични проверки; те не представляват пълен набор от схеми „OMI“ или формален набор за проверка на съответствието.

Open Manuscript Studio понастоящем се позовава на URI https://openmanuscript.org/schemas/omi-manuscript-0.1.json в типа на ръкописа „TypeScript“. Наличието на този URI в изходния код не е доказателство, че е публикувана канонична схема или че реализацията се валидира спрямо нея.

5. Снимка на съвкупността

Показател	Текуща базова стойност
Идентификатори на регистрирани спецификации	23
Активни проекти на спецификации	17
Запазени спецификации	6
Активни спецификации, използващи текущия шаблон	3
Активни спецификации, изискващи миграция на шаблони	14
Публикувани са канонични набори от спецификационни артефакти, подходящи за машинно четене	1 Проверен чернови набор
Публикувани комплекти приспособления за проверка на съответствието	1 първоначален комплект е проверен
Реализации на валидатори	Проверен е 1 валидатор на референтен фикстър
Набори от тестове за формално съответствие	0 проверени
Независими реализации	0 проверени
Статус на студиото: Частичен	8 спецификации
Статус на проекта: Предварителен	6 спецификации
Статус на студиото: Не е започнато	8 спецификации
Статус на студиото: Неприложимо	1 спецификация

Тези показатели описват категориите доказателства, използвани в настоящия документ. Те не измерват процента на завършеност или качеството на спецификацията.

6. Матрица за готовност на спецификациите

6.1 Основи и основни семантични модели

Идентификатор	Спецификация	Статус в регистъра	Версия	Шаблон	Машинно четими артефакти	Устройства за проверка на съответствието
OMI-SPEC-000	Core Principles	Активен проект	0.1.0	Необходима миграция	Неприложимо	Непубликувано
OMI-SPEC-100	Document Model	Активен чернови вариант	0.1.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-110	Anchor Model	Активен чернови вариант	0.1.0	Необходима миграция	Непубликувано	Непубликувано
OMI-SPEC-120	Scholarly Object Model	Активен чернови вариант	0.1.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-130	Annotation Model	Активен проект	0.2.0	Необходима миграция	Непубликувано	Непубликувано
OMI-SPEC-140	Metadata Model	Активен проект	0.1.0	Необходима миграция	Непубликувано	Непубликувано
OMI-SPEC-150	Identity and Contributor Model	Активен чернови вариант	0.1.0	Текущ шаблон	Непубликуван	Непубликуван
OMI-SPEC-160	Versioning and Change Model	Активен чернови вариант	0.1.0	Текущ шаблон	Непубликуван	Непубликуван
OMI-SPEC-170	Модел за превод	Запазено	—	Неприложимо	Не е започнато	Не е започнато
OMI-SPEC-180	Модел за валидиране	Запазено	—	Неприложимо	Не е започнато	Не е започнато
OMI-SPEC-190	Модел за сътрудничество и разрешения	Запазено	—	Неприложимо	Не е започнато	Не е започнато

6.2 Научен работен процес, източници и публикуване

Идентификатор	Спецификация	Статус в регистъра	Версия	Шаблон	Машинно четими артефакти	Устройства за проверка на съответствието
OMI-SPEC-200	Review Model	Активен чернови вариант	0.1.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-210	Citation Model	Активен чернови вариант	0.2.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-220	Bibliographic Record Model	Активен чернови вариант	0.1.0	Необходимо прехвърляне	Непубликувано	Непубликувано
OMI-SPEC-221	Reference Library and Registry Architecture	Активен чернови вариант	0.1.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-230	Publishing Model	Активен чернови вариант	0.1.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-240	Модел на профила за визуализация и публикуване	Запазено	—	Неприложимо	Не е започнато	Не е започнато

6.3 Платформа, обмен и съответствие

Идентификатор	Спецификация	Статус в регистъра	Версия	Шаблон	Машинно четими артефакти	Устройства за проверка на съответствието
OMI-SPEC-300	Plugin Architecture	Активен чернови вариант	0.1.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-310	Platform API	Активен чернови вариант	0.1.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-320	File Format	Активен проект	0.2.0	Текущ шаблон	Draft schema	Initial fixtures
OMI-SPEC-330	Container Architecture	Активен чернови вариант	0.1.0	Необходима миграция	Непубликуван	Непубликуван
OMI-SPEC-340	Модел за внос и износ	Запазено	—	Неприложимо	Не е започнало	Не е започнало
OMI-SPEC-350	Модел на възможностите и съответствието	Запазено	—	Неприложимо	Не е започнато	Не е започнато

7. Данни за внедряването на „Open Manuscript Studio“

Понастоящем нито един ред в този раздел не отговаря на критериите за Реализирано, Тествано или Съвместимо съгласно строгите дефиниции по-горе.

Репозиториумът „OMI“ вече съдържа еталонен валидатор за фиксираните елементи за OMI-SPEC-320@0.2.0. Към момента нито една реализация в Studio не използва този валидатор, а за никоя спецификация не са проверени официални тестове за съответствие или независими доказателства за реализация. Поради това тези показатели са обобщени за цялата базова линия, вместо да се повтарят във всеки ред.

7.1 Основи и основни семантични модели

Идентификатор	Статус на студиото	Потвърдени доказателства	Основна липса преди по-висок статус
OMI-SPEC-000	Не се прилага	Принципите насочват архитектурата, вместо да дефинират компонент, който може да се изпълни директно.	Преобразувайте принципите, валидни за всички пакети, в проследими изисквания и критерии за преглед.
OMI-SPEC-100	Частично	OmiManuscript съдържа секции и блокове; магазинът „Studio“ избира секции, редактира блокове и добавя секции.	Канонична схема, инварианти, семантика на блоковете, правила за разширение, валидиране и съпоставяне на изискванията.
OMI-SPEC-110	Проучвателна	Анотациите могат да се отнасят до targetBlockId и (по избор) targetText.	Стабилна идентичност на котвата, селектори, разрешаване, поведение при мутации, справяне с двусмислията и тестове.
OMI-SPEC-120	Частично	Съвкупността от машинописни ръкописи съдържа агенти, приноси, раздели, блокове, анотации, цитати, идентификатори, времеви отметки и история на ревизиите.	Съгласуване на границите и жизнените цикли на обектите със спецификацията; публикуване на схемата и доказателствата за валидиране.
OMI-SPEC-130	Частично	OmiAnnotation дефинира идентификатор, тип, целеви блок, незадължителен целеви текст, тяло и указание за визуализация; анотациите се показват в състоянието „ръкопис“.	Канонични цели, мотиви, авторство, жизнен цикъл, връзки, разрешения, валидиране и обмен.
OMI-SPEC-140	Частично	Състоянието на ръкописа включва локализация, заглавие, подзаглавие, резюме, ключови думи, идентификатори, автори, приноси и времеви отметки.	Произход на метаданните, контролирани термини, кардиналности, профили, валидиране и външни съответствия.
OMI-SPEC-150	Частично	The Studio декларира OMI-SPEC-150@0.1.0, разделя акаунтите от агентите, представя форми на имена, твърдения за идентификатори и принадлежност, контекстуални приноси, роли, ред и съответния статус, мигрира автори от стари версии, предоставя многоезичен редактор за сътрудници и включва целенасочени единични тестове.	Канонична схема, пълна прозрачност и обработка на произхода, допълнителни типове агенти, съгласуване, съхранение в бекенда, съпоставяне на изисквания и тестови набори за съответствие.
OMI-SPEC-160	Частично	The Studio декларира OMI-SPEC-160@0.1.0; създава неизменни коренови и подчинени ревизии с линейно родословие с един родител; записва семантични набори от промени и събития за промени в ръкописа и от страна на съавторите; съхранява пълни или повърхностни моментални снимки; извършва неразрушителни възстановявания като нови ревизии; определя авторството по консервативен начин; предоставя многоезичен интерфейс за историята; експортира историята на ревизиите; и включва целенасочени единични тестове.	Групиране на работни състояния и комити на контролни точки, „надгробни камъни“, дайджести за целостност/състояние, експлицитно съпоставяне на „REQ-VCH-*“, канонични схеми и фиксирани данни, поддръжка на разклоняване и сливане, укрепване на персистираността и формални тестове за съответствие.
OMI-SPEC-170	Изследователски	Ръкописите имат локал; моделите за потребители и работни пространства включват работни езици и ролята на преводача.	Преводни обекти, връзки между изходния и целевия текст, еквивалентност, различия, синхронизация и произход.
OMI-SPEC-180	Не е започнато	Не е проверен нито един каноничен валидатор, нито модел на доклад за валидиране.	Да се изготви моделът за валидиране и да се публикуват семантиката на доклада в машинно четим формат, както и тестовите набори.
OMI-SPEC-190	Експериментален	Кодът на работната среда дефинира роли, права за достъп, членове, покани, роли на рецензенти и преводачи, с локално съхранение.	Напишете спецификацията; добавете авторизация, налагана от сървъра, права за достъп в рамките на конкретен ръкопис, възможност за одит и тестове за съответствие.

7.2 Научен работен процес, източници и публикуване

Идентификатор	Статус на студиото	Потвърдени доказателства	Основна липса преди по-висок статус
OMI-SPEC-200	Проучвателна	Ролите в работната среда включват „рецензент“, а на членовете може да бъде разрешено да създават бележки.	Преглед на обекти, задания, кръгове, състояния, решения, поверителност, разкриване на самоличност и история на събитията.
OMI-SPEC-210	Частично	OmiCitation, както и масивът с цитати от ръкописа, представляват ключове за цитати, етикети, типове източници и дати.	Отделяне на цитатите от библиографските записи; фиксиране на цитатите и дефиниране на семантика, независима от начина на представяне.
OMI-SPEC-220	Изследователски	Настоящият тип цитиране съдържа малък набор от полета, подобни на тези в библиографските записи.	Специфичен идентификатор на библиографския запис, автори, заглавия, контейнери, идентификатори, произход, обединяване и валидиране.
OMI-SPEC-221	Не е започнало	Не е потвърдена интеграция с библиотека с референции на ниво ръкопис или с външен регистър.	Поведение при членство в библиотеката, повторна употреба на записи, търсене, съгласуване, кеширане, проследяване на произхода и премахване на дублираните записи.
OMI-SPEC-230	Не е започнато	Алфа-редакторът може да обработва и експортира данни от ръкописи, но не е проверена никаква публикационна верига, съобразена със спецификациите.	Задачи за публикуване, профили, трансформации, проследяемост на резултатите, обработка на грешки и запазване на семантичния източник.
OMI-SPEC-240	Не е започнато	Не е проверена нито декларация за рендериране, нито за профил за публикуване.	Изгответе спецификацията и дефинирайте идентичността на профила, изискванията, наследяването, ограниченията за изходните данни и валидирането.

7.3 Платформа, обмен и съответствие

Идентификатор	Статус на студиото	Потвърдени доказателства	Основна липса преди по-висок статус
OMI-SPEC-300	Не е започнато	Не е проверено наличието на манифест на плъгина, точка за разширение API, граници на възможностите или механизъм за изолация.	Определете и реализирайте идентичността на плъгина, неговия жизнен цикъл, разрешенията, точките за разширение, съвместимостта и ограничаването на грешките.
OMI-SPEC-310	Не е стартирано	Настоящата алфа версия е предимно от страна на клиента; не е потвърдена никаква реализация, която да използва регистрираната платформа API.	Контракт с версии API: автентификация, оторизация, ресурси, събития, грешки, пагинация и тестове.
OMI-SPEC-320	Частично	The Studio експортира .omi.json като application/vnd.openmanuscript+json, запазва URI на схемата на предшественика 0.1, изключва остарялото вградено поле authors от каноничните експорти и включва преносима история на ревизиите.	Възприемете конверта и схемата 0.2.0; имплементирайте договаряне на версии, откриване на дублиращи се елементи, многослойна валидация, запазване на неизвестни полета, миграция и отчитане на загуби; съпоставяйте поведението с REQ-FMT-*.
OMI-SPEC-330	Не е започнало	Не е проверен нито един пакет „OMI“ (контейнер, манифест, графика на ресурсите, запис за целостта или работния процес по пакетиране).	Внедрете структурата на пакета, манифеста, обработката на медийни файлове, контролните суми, подписите, безопасността при извличане и правилата за съхранение.
OMI-SPEC-340	Проучвателен етап	Има възможност за експортиране на ръкопис в формат „JSON“, както и пътища за миграция на идентичността и историята на версиите; не е потвърдено наличието на общ потребителски интерфейс за импортиране или доказателства за двупосочна синхронизация.	Напишете спецификацията; добавете функции за импортиране, експортиране, съпоставяне, отчети за загуби, обработка на неподдържано съдържание и тестови случаи за двупосочна синхронизация.
OMI-SPEC-350	Не е започнато	Не е проверена нито декларация за възможности, нито формат на заявления за имплементация, нито програма за проверка на съответствието.	Дефинирайте класове за съответствие, декларации за възможности, тестови манифести, отчети за резултати и правила за проверка на заявленията.

8. Общи констатации и известни отклонения

8.1 Миграция на шаблони за спецификации

OMI-SPEC-150 а OMI-SPEC-160 са създадени директно въз основа на каноничния шаблон за спецификации. OMI-SPEC-320 беше изцяло пренаписан съгласно него във версия 0.2.0. Останалите 14 активни спецификации изискват контролирана миграция, която запазва постоянните идентификатори, каноничните маршрути и историята на промените, като същевременно добавя необходимите раздели за метаданни и доказателства.

8.2 Проект на схема и препратка към старите заместващи символи

Официалният проект на схемата за „OMI-SPEC-320@0.2.0“ е публикуван на адрес https://openmanuscript.org/schemas/omi-manuscript-0.2.schema.json. Типът „Studio manuscript“ все още посочва по-ранния URI https://openmanuscript.org/schemas/omi-manuscript-0.1.json. Няма публикувана официална схема за „0.1“, поради което по-ранният URI остава заместител в имплементацията и не установява съответствие с „0.2.0“.

8.3 Модели, специфични за конкретно приложение

Типовете „Studio“ са полезни доказателства за дизайна, но не представляват автоматично нормативния модел на данни „OMI“. Разликите трябва да бъдат документирани и разрешени чрез корекции в спецификацията или промени в имплементацията.

8.4 Устойчивост на местното сътрудничество

Настоящото хранилище за работни пространства изрично използва локалното съхранение на браузъра и посочва, че поведението в производствена среда при работа с множество потребители изисква удостоверени бекенд API. По този начин то демонстрира проучване на домейна, а не наложено от сървъра спазване на правилата за сътрудничество.

8.5 Цитиране и разделяне на записите

Настоящото представяне на цитиранията в Studio съдържа както информация, ориентирана към появленията, така и към библиографските записи. Моделът на цитиранията и моделът на библиографските записи изискват по-ясно разграничаване, преди някоя от двете реализации да може да се счита за завършена.

8.6 Версии и история на промените

OMI-SPEC-160 вече разполага с първата преносима референтна реализация в Studio. Обединената реализация предлага неизменни линейни ревизии, родословие с един родител, семантични набори от промени и събития, пълни или повърхностни моментални снимки, консервативно приписване на участници, неразрушителни възстановявания, многоезичен изглед на историята, преносим износ на историята и целенасочени единични тестове.

Реализацията остава Частична. Наличните елементи за управление на редактора извършват потвърждаване при текущата си степен на детайлност на актуализацията, поради което редактирането на форматиран текст и текстови полета може да доведе до прекалено детайлни ревизии. Следователно групирането на работни състояния и изричното записване на контролни точки са следващата стъпка в реализацията, преди да се пристъпи към поведението при разклоняване и сливане. Все още предстои да бъдат реализирани „томбстоуни“, обобщения на състояния, по-силна персистентност, изрично съпоставяне на „REQ-VCH-*“, канонични фиксирани данни, разклоняване, бази за сливане, конфликти и формални доказателства за съответствие.

Самите целенасочени единични тестове не са достатъчни, за да се квалифицира реализацията като Тествана съгласно тази матрица, тъй като все още не съществува одобрен набор от тестови случаи за съответствие с OMI, нито програма за тестване на съответствието, съобразена с изискванията.

8.7 Валидиране и съответствие

Схемата „OMI“ (SPEC-320), началните тестови набори и референтният валидатор установяват първата базова линия за изпълними доказателства. Те все още не обхващат всички изисквания на „REQ-FMT-*“, анализа на байтове при дублирани имена, ограниченията на ресурсите, миграцията или кръговите цикли между различните реализации и следователно не квалифицират никоя реализация като Тествана или Съответстваща.

За напредъка по всяка спецификация все още се изисква, според случая:

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

9. Необходими доказателства за повишаване на статуса

9.1 От проучвателен към частичен

Дадена функция може да премине от Експериментална към Частична, когато:

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

9.2 От „Частично“ до „Приложено“

Дадена функция може да премине в състоянието Реализирана само когато:

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

9.3 От „Внедрено“ до „Тествано“

Дадена функция може да бъде преместена в категорията Тествана само когато:

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

9.4 Тествано за съответствие

Дадена функция може да бъде преместена в категорията Съвместима само когато:

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

10. Процедура за поддръжка

Тази матрица трябва да се актуализира при всяко подаване на pull request:

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

Всяка актуализация, свързана с промяна на статуса, трябва да съдържа доказателства като:

• каноничен път към документ или артефакт;
• непроменима комита;
• пробно изпълнение или отчет за резултатите;
• проблем с реализацията или заявка за включване;
• точна версия на спецификацията;
• деклариран клас на съответствие.

Статусът трябва да бъде понижен, когато доказателствата загубят актуалност, станат несъвместими, бъдат оттеглени или вече не могат да бъдат възпроизведени.

Пълната матрица трябва да се преглежда преди всяко пускане на версия от типа „OMI“ и при всеки преход в жизнения цикъл към статуса „Review Candidate“, „Implementation Candidate“ или „Stable“.

11. Програма за незабавни доказателства

Следващата дейност по събиране на доказателства трябва да се проведе в следния ред:

1. да се добави групиране по работно състояние и изрично записване на контролни точки в реализацията на Studio на OMI-SPEC-160, така че обикновеното въвеждане на текст да не създава прекалено детайлни фиксирани ревизии;
2. да съпоставите реализираното подмножество „История на ревизиите на ядрото“ с нормативните изисквания на „REQ-VCH-*“ и да документирате изрично отклоненията;
3. добавяне на „tombstone“ и поведение, свързано с целостта/state-digest, изисквано от избрания профил за версиониране;
4. да внедрим „OMI-SPEC-320@0.2.0“ в Studio и да добавим парсер, сериализатор, миграция и доказателства за двупосочна синхронизация, съответстващи на изискванията;
5. да публикува канонични схеми за идентичност и версиониране с минимален брой валидни и невалидни фиксирани данни;
6. да прехвърлим останалите активни спецификации на ядрата към каноничния шаблон за спецификации;
7. да се дефинират моделът за валидиране и форматът на доклада за валидиране;
8. да въведе автоматизирани проверки на схемите и съответствието между спецификациите;
9. чернова на „OMI-SPEC-170“, модел за превод, използващ регистъра за ревизии като основа, отчитаща версиите;
10. да регистрирате известните отклонения като свързани проблеми и да потърсите независимо разработен парсер, валидатор или прототип за оперативна съвместимост.

12. История на промените

Версия	Дата	Обобщение
0.3.0	05.09.2026	Записани са шаблона „OMI-SPEC-320@0.2.0“, първата канонична схема на черновия вариант на ръкописа, първоначалните тестови данни и референтен валидатор; актуализирани са оставащите пропуски в прилагането на Studio и общите данни за доказателствата.
0.2.1	06.08.2026	Поддръжката на „OMI-SPEC-160“ в Promoted Studio беше преместена от ниво „Exploratory“ на ниво „Partial“ след сливането на неизменния линеен регистър за ревизии; записани бяха доказателства за ревизии, набори от промени, моментални снимки, възстановявания, експортиране на историята и целенасочени тестове; преминаване към следващия приоритет за доказателства – групиране в работно състояние, фиксиране на контролни точки и съпоставяне на изисквания.
0.2.0	06.08.2026	Активиран беше OMI-SPEC-160, записани бяха две спецификации за текущи шаблони, актуализирани бяха данните в Studio след интеграцията с OMI-SPEC-150, а програмата за данни беше превърната в линеен регистър за ревизии.
0.1.1	06.08.2026	Активирахме „OMI-SPEC-150“ в матрицата за готовност, регистрирахме го като първата спецификация, изготвена по настоящия шаблон, и актуализирахме програмата за непосредствени доказателства.
0.1.0	06.08.2026	Първоначална матрица, основана на доказателства, обхващаща всички 23 регистрирани идентификатора, текущите артефакти на спецификацията, поддръжката на „Open Manuscript Studio“, валидирането, тестването, отклоненията и правилата за промяна на статуса.