SOLPDT 1.0 | SPECIFICATION
SOL PERFORMANCE DIGITAL TWIN
ВЕРСИЯ 1.0.0

СПЕЦИФИКАЦИЯ ФОРМАТА .SOLPDT
SOL Performance Digital Twin — Версия 1.0

Статус документа: Открытая спецификация (публичный релиз) | Дата публикации: 30 января 2026 г. | Автор: Соколов Юрий Иванович | Правообладатель спецификации и связанных методологий (FEBA, SOL): ООО «Скайлайн Риск Солюшенс»

Лицензионное уведомление и условия использования

1. Лицензия на текстовую спецификацию

Данный документ (текстовая спецификация формата .SOLPDT) распространяется на условиях международной общественной лицензии Creative Commons Attribution 4.0 (CC BY 4.0).

Вы вправе:

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

При единственном условии:

  • Указание авторства — Вы должны указать соответствующее авторство, предоставить ссылку на лицензию и обозначить изменения, если таковые были сделаны.

Полный юридический текст лицензии CC BY 4.0 доступен по адресу: https://creativecommons.org/licenses/by/4.0/legalcode

2. Право на реализацию формата

ООО «Скайлайн Риск Солюшенс» безвозмездно предоставляет любому лицу неисключительное, безотзывное, всемирное право на создание, использование, продажу и распространение программных и аппаратных реализаций, которые генерируют, читают, обрабатывают или проверяют файлы в формате .SOLPDT, при условии, что такие реализации соответствуют требованиям, изложенным в данной спецификации версии 1.0. Для создания совместимых реализаций не требуется заключение каких-либо дополнительных лицензионных соглашений с правообладателем.

3. Товарные знаки и коммерческие сервисы

Названия «SOLPDT», «SOL Performance Digital Twin», «Скайлайн Риск Солюшенс», а также связанные с ними логотипы и элементы фирменного стиля являются товарными знаками или зарегистрированными товарными знаками ООО «Скайлайн Риск Солюшенс» в Российской Федерации и/или других странах. Данная лицензия НЕ предоставляет права на их использование.

Информация о коммерческих предложениях и партнёрской программе доступна на официальном сайте стандарта: https://solpdt.com/commercial

4. Отказ от гарантий и ограничение ответственности

Данная спецификация предоставляется «как есть» (AS IS), без каких-либо гарантий, явных или подразумеваемых. Правообладатель не несет ответственности за любые прямые или косвенные убытки, возникшие в результате использования или невозможности использования данного документа.

© 2026 ООО «Скайлайн Риск Солюшенс». Все права на текст спецификации изначально принадлежат автору и переданы правообладателю. Право на реализацию формата предоставляется на условиях, изложенных выше.

1. Введение

1.1. Назначение формата

Формат .SOLPDT (SOL Performance Digital Twin) — это открытый стандарт для создания криптографически верифицированных цифровых активов, представляющих измеримые показатели результативности, качества, экспертизы и соответствия стандартам организации или её продукта. Актив агрегирует и доказывает ключевые метрики цепочки создания ценности, превращая операционные данные и доказательную базу в капитализируемый нематериальный актив (НМА).

1.2. Связь с концепцией Performance Digital Twin

Формат .SOLPDT является технической реализацией и материальным носителем концепции Capitalized Performance Digital Twin (Капитализируемого Цифрового двойника эффективности), описанной в методологической литературе. .SOLPDT-файл представляет собой SOL-Актив — криптографически верифицированный цифровой актив, готовый к использованию в алгоритмических экосистемах (SGE) и учёту в качестве нематериального актива (НМА).

1.3. Архитектурные принципы

Формат реализует архитектуру Двухкондуитной экономики:

  • Кондуит 1 (Данные): Структурированные метрики и доказательная база по методологии SOL (от входного сигнала/соответствия (S) → к верифицируемому результату (O) → к устойчивой ценности (L)).
  • Кондуит 2 (Доверие): Встроенный протокол двух независимых подписей (Слой суверенного утверждения + Слой аналитической верификации).

Дополнительные принципы:

  • Принцип криптографической доказательности: Все заявленные данные подтверждаются цифровыми подписями.
  • Принцип разделения ответственности: Организация-владелец подтверждает достоверность данных, Правообладатель верифицирует методологию.
  • Принцип многоуровневой верификации: Цифровые артефакты подписываются по иерархической цепочке (специалист → организация).
  • Поддержка жизненного цикла: Актив поддерживает версионирование, трансфер прав и отслеживание истории владения.

1.4. Основные сценарии использования

  • Создание верифицированного цифрового профиля организации для различных секторов экономики (услуги, производство, экспертиза).
  • Капитализация репутационного капитала, экспертизы и объективного качества как НМА.
  • Поддержка контекстного позиционирования в системах поиска и рекомендаций (SGE).
  • Обеспечение прозрачного Due Diligence для инвесторов, банков, регуляторов и покупателей.
  • Формирование доказательной базы для снижения страховых тарифов, получения финансирования и участия в госзакупках.

2. Общая структура файла

2.1. Рекомендуемое расширение и MIME-тип

  • Основной формат: .solpdt
  • MIME-тип (предлагаемый): application/vnd.solpdt+json

2.2. Корневая структура JSON

Файл представляет собой валидный JSON-объект со следующей обязательной структурой. Порядок полей не является значимым, но рекомендуется следовать указанной последовательности для лучшей читаемости.

{
  "format": "SOLPDT 1.0",
  "created": "YYYY-MM-DDThh:mm:ssZ",
  "asset_id": "string",
  "lifecycle": { /* Обязательный. Данные жизненного цикла */ },
  "ownership_chain": [ /* Обязательный. Цепочка владения */ ],
  "entity": { /* Обязательный. Текущий владелец */ },
  "methodology": { /* Обязательный. Методологическая основа */ },
  "data_core": { /* Обязательный. Базовые метрики по гибкой схеме */ },
  "data_targeted": { /* Опционально. Таргетированные стратегии */ },
  "verification_artifacts": [ /* Опционально. Ссылки на цифровые артефакты */ ],
  "trust_architecture": { /* Обязательный. Архитектура доверия */ }
}

3. Детальная спецификация разделов

3.1. Раздел format (обязательный)

  • Тип: Строка (String)
  • Описание: Указывает версию спецификации формата.
  • Значение: Должно быть строго "SOLPDT 1.0".

3.2. Раздел created (обязательный)

  • Тип: Строка (String) в формате ISO 8601
  • Описание: Дата и время создания данной конкретной версии файла в формате UTC.
  • Пример: "2026-01-30T14:30:00Z"

3.3. Раздел asset_id (обязательный)

  • Тип: Строка (String)
  • Описание: Глобально уникальный, неизменный идентификатор актива, присваиваемый при первичном выпуске. Рекомендуемый формат: "ASST_<КодВладельца>_<УникПоследовательность>".
  • Пример: "ASST_SPECTRAMED_001"

3.4. Раздел lifecycle (обязательный)

Содержит информацию о текущем статусе и управлении активом.

{
  "lifecycle": {
    "status": "active",
    "current_version": 3,
    "history_root": "sha3-256_хеш_первой_версии",
    "governance": {
      "licensor": "Skyline Risk Solutions",
      "licensor_public_key": "base64_encoded_public_key",
      "current_license_id": "LIC_XYZ_123"
    }
  }
}
  • status (String, обязательный): Текущий статус актива.
    • "active" — активен и валиден.
    • "pending_transfer" — ожидает подтверждения трансфера.
    • "suspended" — действие приостановлено (например, при нарушении лицензии).
    • "retired" — вывод из обращения.
    • "disputed" — оспаривается (в процессе арбитража).
  • current_version (Number, обязательный): Целое число, инкрементируемое при любом изменении, влекущем переподписание. Начинается с 1.
  • history_root (String, опционально): Хеш (SHA3-256) самой первой версии актива.
  • governance (Object, обязательный): Сведения об управляющей стороне (Лицензиаре).
    • licensor (String): Наименование Лицензиара.
    • licensor_public_key (String): Открытый ключ Лицензиара в кодировке Base64.
    • current_license_id (String): Идентификатор действующей лицензии.

3.5. Раздел ownership_chain (обязательный)

Неизменяемый (append-only) массив, фиксирующий полную историю владения активом. Каждая запись соответствует одной версии файла.

{
  "ownership_chain": [
    {
      "version": 1,
      "owner": {
        "id": "SPECTRAMED_LLC",
        "name": "ООО «Спектрамед»"
      },
      "valid_from": "2025-01-20T12:00:00Z",
      "valid_to": "2026-10-15T14:30:00Z",
      "transaction": {
        "type": "issuance",
        "hash": "0xa1b2c3...",
        "signed_by_licensor": true
      }
    },
    {
      "version": 2,
      "owner": {
        "id": "DENTAL_HOLDING_LLC",
        "name": "ООО «Дентал Холдинг»"
      },
      "valid_from": "2026-10-15T14:30:00Z",
      "valid_to": null,
      "transaction": {
        "type": "transfer",
        "hash": "0xd4e5f6...",
        "signed_by_licensor": true,
        "previous_version": 1
      }
    }
  ]
}
  • version (Number, обязательный): Номер версии актива.
  • owner (Object, обязательный): Сведения о владельце.
    • id (String): Внутренний идентификатор организации в системе Лицензиара.
    • name (String): Официальное наименование.
  • valid_from (String, обязательный): Дата начала владения (ISO 8601).
  • valid_to (String, может быть null): Дата окончания владения. null указывает на текущего владельца.
  • transaction (Object, обязательный): Информация о транзакции.
    • type (String): "issuance", "transfer", "update".
    • hash (String): Хеш транзакции.
    • signed_by_licensor (Boolean): Подтверждение Лицензиара.
    • previous_version (Number, опционально): Для "transfer" указывает предыдущую версию.

Важно: Данные в блоке entity должны соответствовать последней записи в ownership_chain с valid_to: null.

3.6. Раздел entity (обязательный)

Содержит идентификацию организации-владельца на момент создания этой версии.

{
  "entity": {
    "id": "DENTAL_HOLDING_LLC",
    "name": "ООО «Дентал Холдинг»",
    "type": "medical_clinic",
    "legal_id": "1234567890",
    "website": "https://clinic-example.ru",
    "jurisdiction": "RU"
  }
}
  • id (String, обязательный): Уникальный ID организации в системе Лицензиара.
  • name (String, обязательный): Полное наименование.
  • type (String, обязательный): Тип организации. Возможные значения: "medical_clinic", "dental", "hospital", "beauty_clinic", "manufacturer", "research_institute", "audit_firm", "educational_institution".
  • legal_id (String, опционально): ОГРН/ИНН или иной гос. номер.
  • website (String, опционально): Официальный сайт.
  • jurisdiction (String, опционально): Код страны юрисдикции (ISO 3166-1 alpha-2).

3.7. Раздел methodology (обязательный)

Фиксирует методологическую основу.

{
  "methodology": {
    "framework": "FEBA/SOL v2.1",
    "author": {
      "name": "Соколов Юрий Иванович",
      "affiliation": "ООО «Скайлайн Риск Солюшенс»"
    },
    "description": "Методология агрегации эндогенного поведенческого фактора (FEBA) и операционализации цепочки создания ценности через универсальный S-O-L континуум.",
    "recognition": {
      "by": "Rubini Global Economics",
      "type": "methodological_validity",
      "date": "2010-11-15",
      "reference": "RGE-MV-2010-0115"
    }
  }
}
  • framework (String, обязательный): "FEBA/SOL v2.1".
  • author (Object, обязательный): Сведения об авторе.
  • description (String, опционально): Текстовое описание.
  • recognition (Object, обязательный): Информация о внешнем признании.

3.8. Раздел data_core (обязательный)

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

{
  "data_core": {
    "reporting_period": {
      "start": "2025-10-01",
      "end": "2025-12-31"
    },
    "metric_framework": {
      "primary_profile": "service",
      "profiles": {
        "service": {
          "satisfaction": {
            "score": 94,
            "sample_size": 1247,
            "definition": "Индекс удовлетворенности клиентов (CSAT), %",
            "period": "2025-Q4"
          },
          "outcome": {
            "score": 96,
            "definition": "Процент успешных клинических исходов",
            "sample_size": 845,
            "measurement_standard": "Внутренний клинический аудит"
          },
          "loyalty": {
            "score": 87,
            "nps": 65,
            "repeat_ratio": 45,
            "sample_size": 1100,
            "definition": "Композитный индекс лояльности"
          }
        },
        "production": { /* ... */ },
        "expertise": { /* ... */ }
      }
    },
    "verification_samples": {
      "total_data_points": 3200,
      "coverage": "92%",
      "audit_trail_hash": "sha3-256_хеш_логов_аудита_и_первичных_данных"
    }
  }
}
  • reporting_period (Object, обязательный): Период, за который представлены данные.
  • metric_framework (Object, обязательный): Ядро раздела, содержащее гибкую систему профилей.
    • primary_profile (String, обязательный): Указывает первичный профиль (service, production, expertise).
    • profiles (Object, обязательный): Контейнер для профилей. Должен содержать как минимум профиль, указанный в primary_profile.
  • verification_samples (Object, опционально): Сводка по объему и покрытию данных.

Примечание: Структура каждого под-объекта в профиле может быть расширена. Ключевое требование — наличие числового score и definition.

3.9. Раздел data_targeted (опциональный)

Таргетированные стратегии для контекстного позиционирования. Присутствует в активах уровня SOL-2 и выше.

{
  "data_targeted": {
    "strategies": [
      {
        "id": "dental_implants",
        "name": "Имплантация зубов",
        "profile_type": "service",
        "core_metrics_ref": {
          "satisfaction_score": 94,
          "outcome_success_rate": 96,
          "loyalty_index": 87
        },
        "sge_queries": ["имплантация зубов Москва", "зубные импланты цена"],
        "target_audience": "пациенты 35-60 лет",
        "verification_artifacts_refs": ["ARTF_IMPLANT_001", "ARTF_IMPLANT_002"]
      }
    ]
  }
}

3.10. Раздел verification_artifacts (опциональный)

Ссылки на цифровые артефакты. Исходные файлы НЕ включаются.

{
  "verification_artifacts": [
    {
      "@type": "DigitalArtifactReference",
      "artifact_id": "ARTF_CASE_245_IMG",
      "artifact_type": "medical_image",
      "description": "Панорамный снимок до и после имплантации (кейс #245)",
      "content_hash": {
        "algorithm": "sha3-256",
        "value": "0xd4e5f6..."
      },
      "attestation_chain": [
        {
          "level": "expert",
          "signer": {
            "role": "Врач-рентгенолог",
            "name": "Иванов А.А.",
            "qualification_ref": "DIP_123456"
          },
          "signature": {
            "algorithm": "ed25519",
            "value": "base64_sig_expert",
            "timestamp": "2025-01-15T14:20:00Z"
          },
          "purpose": "Подтверждение подлинности"
        }
      ],
      "storage_reference": {
        "type": "external_secure",
        "identifier": "case245_original.dicom",
        "storage_provider": "клиентская СХД"
      },
      "privacy": {
        "patient_consent_id": "consent_form_#245_hash",
        "data_retention": "10y",
        "anonymization_level": "full"
      }
    }
  ]
}

3.11. Раздел trust_architecture (обязательный)

Ядро формата — архитектура доверия с двумя независимыми подписями.

{
  "trust_architecture": {
    "protocol": "two_signature_v1",
    "hash": {
      "algorithm": "sha3-256",
      "value": "0xa1b2c3d4e5f6...",
      "of_fields": ["/lifecycle", "/ownership_chain", "/data_core", "/data_targeted", "/verification_artifacts"]
    },
    "signatures": {
      "sovereign_assertion": {
        "signer": {
          "role": "Генеральный директор",
          "entity_id": "DENTAL_HOLDING_LLC"
        },
        "signature": {
          "algorithm": "ed25519",
          "value": "base64_encoded_signature_1",
          "timestamp": "2026-01-30T14:25:00Z"
        },
        "purpose": "Фактическое подтверждение достоверности данных и цифровых артефактов",
        "verification_url": "https://verify.skylinerisk.ru/DENTAL_HOLDING_LLC"
      },
      "analytical_verification": {
        "signer": {
          "platform": "Skyline Risk Solutions",
          "methodology_version": "FEBA/SOL v2.1"
        },
        "signature": {
          "algorithm": "ed25519",
          "value": "base64_encoded_signature_2",
          "timestamp": "2026-01-30T14:30:00Z"
        },
        "purpose": "Верификация методологии расчёта, структуры данных и корректности цепочек подписей артефактов",
        "scope": ["/methodology", "/data_core", "/lifecycle", "/verification_artifacts"]
      }
    }
  }
}
  • protocol (String): Идентификатор протокола.
  • hash (Object): Информация о хеше, который был подписан.
  • signatures (Object): Две подписи.
    • sovereign_assertion: Подпись владельца.
    • analytical_verification: Подпись Лицензиара.

4. Иерархия верификации и подписей

4.1. Многоуровневая цепочка доверия

  1. Уровень 0: Исходный файл артефакта — хранится у клиента.
  2. Уровень 1: Подпись специалиста (expert) — подтверждает профессиональное содержание.
  3. Уровень 2: Подпись организации (institutional) — утверждает артефакт как доказательство.
  4. Уровень 3: Подпись организации за весь актив (sovereign_assertion).
  5. Уровень 4: Подпись Лицензиара (analytical_verification).

4.2. Юридическая ответственность по уровням

  • Уровень 1-2: Специалист и организация несут ответственность за фактическую достоверность артефакта.
  • Уровень 3: Организация несет ответственность за полноту и репрезентативность всего набора данных.
  • Уровень 4: Лицензиар несет ответственность за корректность методологических принципов.

5. Жизненный цикл SOL-актива

5.1. Типовые этапы

  1. Выпуск (Issuance): Первичное создание.
  2. Обновление (Update): Периодическое обновление метрик.
  3. Трансфер (Transfer): Передача прав владения.
  4. Архивация/Вывод (Retirement).

5.2. Протокол трансфера SOL-активов (SATP)

Формализованная процедура передачи прав под контролем Лицензиара.

6. Процесс верификации файла

  1. Синтаксическая проверка (JSON).
  2. Структурная проверка (наличие обязательных блоков).
  3. Проверка хеша.
  4. Верификация подписей артефактов.
  5. Верификация подписи владельца (sovereign_assertion).
  6. Верификация подписи Лицензиара (analytical_verification).
  7. Проверка целостности цепочки владения.
  8. Проверка статуса через реестр Лицензиара.

7. Уровни соответствия (Compliance Levels)

УровеньОбязательные блокиНазначение
SOL-1 (Базовый) Все обязательные (format, created, asset_id, lifecycle, ownership_chain, entity, methodology, data_core, trust_architecture). data_core должен содержать корректный primary_profile. Создание верифицированного профиля. Капитализация как НМА. Базовый Due Diligence.
SOL-2 (Профессиональный) SOL-1 + data_targeted (1-3 стратегии). Контекстное позиционирование в поисковых системах и агрегаторах для ключевых услуг/продуктов. Повышенное доверие партнеров.
SOL-3 (Корпоративный) SOL-2 + неограниченное число стратегий + verification_artifacts. Полное цифровое досье с доказательной базой. Использование в комплексном Due Diligence при M&A, страховании, крупном финансировании. Поддержка трансфера.

8. Алгоритмы и криптография (рекомендации)

  • Хеширование данных: SHA3-256 (предпочтительно) или SHA-256.
  • Цифровая подпись: Ed25519 (предпочтительно) или ECDSA с secp256k1. Допустимы подписи, соответствующие ФЗ-63.
  • Кодировка: Base64 (URL-safe) или Hex.
  • Формат времени: ISO 8601 (RFC 3339), UTC.
  • Идентификаторы: Рекомендуется UUID v4 или детерминированные ID на основе хеширования.

9. Безопасность и конфиденциальность

  1. Суверенитет данных: Персональные данные и исходные файлы не покидают инфраструктуру клиента.
  2. Многоуровневая криптографическая защита: Каждый уровень верификации защищен отдельной подписью.
  3. Юридическая сила подписей: Соответствуют требованиям ФЗ-63.
  4. Аудитопригодность: Полная история сохраняется в неизменном виде.
  5. Контроль экосистемы: Лицензиар как арбитр.
  6. Конфиденциальность: Все ссылки на артефакты содержат поля privacy.

10. Приложения (справочная информация)

10.1. Пример минимального валидного файла (SOL-1) для сервисной компании

Пример включает все обязательные разделы с primary_profile: "service".

10.2. Пример SOL-1 для производственной компании

Краткий пример файла для производственной компании.

{
  "format": "SOLPDT 1.0",
  "created": "2026-01-30T10:00:00Z",
  "asset_id": "ASST_NUTRIHEAL_001",
  "lifecycle": {
    "status": "active",
    "current_version": 1,
    "governance": {
      "licensor": "Skyline Risk Solutions",
      "licensor_public_key": "MCowBQYDK2VwAyEA...",
      "current_license_id": "LIC_NUTRI_001"
    }
  },
  "ownership_chain": [ /* ... */ ],
  "entity": {
    "id": "NUTRIHEAL_LLC",
    "name": "ООО «НутриХил»",
    "type": "manufacturer",
    "legal_id": "0987654321",
    "jurisdiction": "RU"
  },
  "methodology": {
    "framework": "FEBA/SOL v2.1",
    /* ... */
  },
  "data_core": {
    "reporting_period": { "start": "2025-07-01", "end": "2025-12-31" },
    "metric_framework": {
      "primary_profile": "production",
      "profiles": {
        "production": {
          "compliance_score": { "score": 99.8, "definition": "Соответствие ТР ТС 027/2012 и GMP" },
          "output_quality_score": { "score": 99.5, "definition": "Индекс качества партии", "defect_rate_ppm": 500 },
          "stakeholder_retention_score": { "score": 96, "definition": "Доля долгосрочных контрактов", "long_term_contract_ratio": 85 }
        }
      }
    }
  },
  "trust_architecture": { /* ... */ }
}

10.3. Ссылки и контакты

Стандарт SOLPDT разработан и поддерживается Юрием Соколовым. Права на связанные методологии (FEBA, SOL) принадлежат ООО «Скайлайн Риск Солюшенс».

10.4. Связанные документы

  • Глоссарий ключевых терминов SOL-Актив v2.0
  • Протокол трансфера SOL-активов (SATP) v1.0
  • Протокол прозрачной сверки (Transparent Audit Protocol) v1.0
  • Методологическое описание FEBA/SOL v2.1

Доступно добавление к спецификации

Спецификация открыта для обсуждения. Предложения по развитию формата принимаются по указанным контактам. Следующая версия (2.0) планируется к публикации в июне 2026 года.

Перейти к SOLPDT 1.1 (Agentic Trust Layer Extension) →