---
title: Оценка на DPP доставчик — нашите отговори
description: "Отговори за обществена поръчка на всеки въпрос към доставчик на цифров продуктов паспорт: API, GS1 resolver, Регламент за батерии, изход, цени, GDPR."
canonical: "https://www.tracepass.eu/bg/buyers-guide"
locale: bg
source: "https://www.tracepass.eu/bg/buyers-guide"
---

# Оценка на DPP доставчик — нашите отговори

> Отговори за обществена поръчка на всеки въпрос към доставчик на цифров продуктов паспорт: API, GS1 resolver, Регламент за батерии, изход, цени, GDPR.

Въпросите, които купувачът трябва да зададе на всеки DPP доставчик преди подписване — и как TracePass отговаря на всеки от тях. Препратете това към вашите отдели за обществени поръчки, регулаторния отдел и инженерните екипи; всеки отговор е подкрепен с доказателства.

## Имате ли публични APIs?

**TL;DR:** REST + OpenAPI. Четене и запис по паспорти, продукти и шаблони.

TracePass предоставя документирано REST API, обхващащо паспорти, продукти, шаблони, организации и webhooks. Повърхностите за четене и запис са симетрични — всичко, което може да се направи в UI, може да се управлява и през API.

Удостоверяването е чрез API ключове за всяка организация с обхватни права. OpenAPI спецификацията се публикува за всеки клиент в портала за разработчици — без NDA гейтинг, без триене с „говорете с нашия интеграционен екип".

Някои доставчици предоставят само endpoints за четене на публични паспорти. „Имаме API" може да означава един GET — настоявайте за покритие на запис и публикувана спецификация.

## Можете ли да импортирате паспорти масово чрез CSV или API?

**TL;DR:** CSV шаблони за всяка категория и endpoint за масов импорт. UI зона за пускане на файлове за нетехнически потребители.

Всеки шаблон на категория идва със собствен CSV шаблон — имената на колоните съответстват на схемата, типовете и ограниченията се валидират при качване. Пуснете файл в UI; endpoint за масов импорт приема същия CSV през API за автоматизирани пайплайни.

Валидацията е за всеки ред с отчитане на грешки на ниво колона; частичните импорти са атомарни (или всички редове се записват, или файлът се отхвърля с diff). За клиенти с голям обем API за импорт поддържа партиди от множество файлове.

Общите CSV импорти, независими от схемата, обикновено изискват седмици съпоставяне за всяка категория. Шаблоните за всяка категория свеждат това до минути.

## Кой притежава GS1 resolver — и какво се случва, ако напусна?

**TL;DR:** Персонализиран домейн при всеки платен план. Преносимостта на URL е постоянна, защото домейнът е ваш; 30-дневен гратисен период след прекратяване без такса.

Всеки платен план може да маршрутира QR кодове през собствения домейн на клиента (напр. id.your-brand.eu/01/...). TracePass резолвира под вашия домейн, така че URL преносимостта е постоянна — дори ако напуснете, URL върху опаковката продължава да работи.

Безплатните / пробните акаунти резолвират под tracepass.eu/p/...; преминаването към платен план не нарушава QR кодовете в обращение, които са започнали на споделения домейн. След прекратяване TracePass продължава да резолвира вашите съществуващи паспорти 30 дни без такса (вж. Общи условия) — за платени клиенти със собствен домейн това е прозорец, в който можете да пренасочите DNS към resolver на друг доставчик. След 30-дневния гратисен период URL на споделения домейн връщат „изтекъл” и TracePass спира да обслужва персонализирания домейн.

Някои доставчици отпечатват собствения си домейн върху QR кода без клаузи за напускане. В този модел напускането означава физическо препечатване на всеки продукт, който някога е бил изпратен.

## Поддържате ли EPCIS за проследяване на събития във веригата на доставки?

**TL;DR:** Да — пълен EPCIS 2.0 (експорт, заснемане, заявки), включен във всеки платен план. Метър по обем на план (1 000 събития/мес. при Basic до 10 000 000 при Pro, неограничено при Enterprise). Без добавка, без такса „свържете се с нас“.

EPCIS 2.0 експорт, заснемане и заявки са включени във всеки платен план. Доставчиците и ERP системите изпращат събития към нашия Capture endpoint; query възелът ни отговаря на интерфейса EPCIS Query; събитията на всеки паспорт се сериализират като валиден по стандарта EPCIS 2.0 JSON-LD документ, обявен в GS1 Digital Link резолвера на QR кода, така че система с поддръжка на EPCIS автоматично открива историята.

Метърът е по обем: Basic 1 000 събития/месец, Starter 10 000, Growth 100 000, Scale 1 000 000, Pro 10 000 000, Enterprise неограничено. Free има 10 събития/месец като ограничител за оценка. При платените планове достигането на лимита е надхвърляне по избор по такса за блок от 1 000 събития, която спада от €5 (Basic) до €1 (Pro) — вижте таблицата с цени на /pricing. При Free достигането на лимита изисква преминаване към платен план, без изненадващи такси.

AI агентът на TracePass допълнително изготвя EPCIS TransformationEvents от технически спецификации на доставчици и PDF документи, които вашият проверяващ да одобри — същата защита „AI предлага, човекът одобрява” като в останалата част от платформата.

Повечето EPCIS доставчици са само по оферта — Tracelink, rfXcel/Antares Vision, Evrythng, OpenEPCIS-като-услуга държат цените зад продажбени разговори. Публикувани квоти на събитията по план с твърди такси за надхвърляне са евтиният сигнал, че доставчик е сериозен за прозрачно SaaS ценообразуване, а не еднократен корпоративен договор, маскиран като продуктова страница.

## Може ли AI асистент да се свърже директно с платформата?

**TL;DR:** Да — сървър за Model Context Protocol (MCP). Хостван endpoint или локален npm пакет; използва вашия съществуващ API ключ.

TracePass предоставя сървър за Model Context Protocol. Два начина за използване: хостван endpoint, към който насочвате MCP клиент, или локален npm пакет, изпълняван чрез npx. Удостоверява се със същия API ключ като REST API, така че е наличен на всеки план.

Той излага платформата като MCP инструменти (продукти, паспорти, полета, страни, EPCIS), плюс ресурси и подсказки. Действията за запис са ясно обозначени — сървърът казва на асистента кои действия са платими или необратими, така че агентът ви предупреждава, преди да създаде паспорти или да архивира нещо.

Поддръжката на MCP е рядка сред доставчиците на DPP днес — повечето имат само REST API. Ако разговорните / агентно управляваните работни процеси са важни за екипа ви, реален MCP сървър (не обещание в пътна карта) си струва да се провери.

## Има ли интеграция за автоматизация без код (n8n / Zapier / Make)?

**TL;DR:** Да — безплатен n8n community node: n8n-nodes-tracepass. Инсталирайте от всяка n8n инстанция.

TracePass предоставя n8n community node — n8n-nodes-tracepass — изграден стриктно по текущия стандарт на n8n за верификация на community nodes. Декларативен routing, нулеви runtime зависимости, MIT лиценз, безплатно. Излага три ресурса (Product, Passport, EPCIS Event) с v1 API операциите за всеки.

Инсталирайте го от всяка n8n инстанция чрез Settings → Community Nodes → Install. Удостоверявайте се със същия API ключ `tp_` като REST API. Рисковите операции носят бележки за безопасност в описанията си — Create на Passport е платимo, Archive е необратимо — и идват с превключвател „Confirm Overage Charge“ с активиране по избор, така че работен процес да не таксува неочаквано акаунта.

Интеграции за Zapier и Make все още не са пуснати — междувременно извиквайте REST API директно през техните HTTP модули; същият API ключ `tp_` работи.

Верифициран n8n community node е малко нещо, което сигнализира, че доставчикът се отнася сериозно към „дългата опашка“ от интеграции. Стандартът за верификация означава, че се открива в UI-то на n8n, а не е скрит зад self-host конфигурация.

## Поддържате ли паспорти на ниво сериен номер?

**TL;DR:** Нативно. gs1.serialNumber е каноничният първичен ключ за свързване.

Всеки паспорт в TracePass се ключира по сериен номер. gs1.serialNumber е каноничното първично свързване, със SKU/модел като вторично поле за групиране. Моделът на данните е проектиран със сериен номер на първо място, защото регулаторната посока е такава.

Паспортите на ниво сериен номер поддържат данни за жизнения цикъл на всяка единица: състояние на здравето, история на ремонтите, прехвърляне на собственост, статус в края на живота. Масово създаване и масово обновяване по обхват от серийни номера са първокласни операции.

Доставчици, построени върху модели на ниво SKU, добавят серийния номер като персонализирано поле допълнително, което нарушава масовите операции и аналитиката. Сериен-номер-първо срещу сериен-номер-като-допълнителна-мисъл е видимо във формата на API.

## Версионирани и одитируеми ли са редакциите на паспортите?

**TL;DR:** Всяка редакция е в одитна следа. Времева линия на версиите видима за всеки паспорт. Заявките от компетентни органи могат да посочат версия.

Всяка редакция на паспорт се записва с времеви печат, извършител и diff на ниво поле. Страницата с детайли за паспорта рендерира времева линия на версиите; всяка историческа версия може да се извлече по ID през API.

Публичните URL на паспортите по подразбиране показват най-новата версия; ?version=N или ?as_of=DATE връщат историческото състояние. Това е повърхността, която компетентните органи използват по време на заявки за оценка на съответствието.

„Имаме одитна следа" без UI представяне обикновено означава сурови записи в базата данни, които никой не може да чете. Одиторите искат изгледи на времева линия, а не заявки към лог-агрегатор.

## Мога ли да експортирам данните си?

**TL;DR:** Пълен JSON-LD за всеки паспорт. Масов експорт за целия наемател. Медия включена със стабилни URL.

Всеки паспорт се експортира като JSON-LD през API или сваляне в UI. Експортът запазва метаданните на полетата, атрибуцията на източника, историята на версиите и преводите.

Масовият експорт за целия наемател опакова всеки паспорт, всеки продукт, всеки шаблон, който сте създали. Медийните прикачени файлове (изображения, тестови протоколи, PDF) идват със стабилни URL, които остават резолируеми по време на 30-дневния гратисен период след прекратяване — достатъчно дълго, за да мигрирате към следващ доставчик.

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

## Кои точно членове от Регламента за батерии (ЕС) 2023/1542 се поддържат?

**TL;DR:** Съпоставяне на ниво член за 6 (въглероден отпечатък), 7 (рециклирано съдържание), 11 (възможност за отстраняване), 14 (състояние на здравето), 77 (DPP).

Нашият шаблон за батерии моделира и петте основни члена: 6 (декларация за въглероден отпечатък), 7 (прагове за рециклирано съдържание), 11 (информация за възможност за отстраняване и подмяна), 14 (състояние на здравето за индустриални и EV батерии), 77 (DPP полета, включително QR код, идентификация на доставчика и статус на жизнения цикъл).

Имплементиращите актове продължават да прецизират някои прагове — по-конкретно процентите за рециклирано съдържание и методологията за измерване на SOH. Проследяваме всяка промяна в Регулаторния Changelog и правим версионна промяна на схемата, когато е същностна.

Пълно покритие на членовете е рядкост; частично с пътна карта е по-честно от безусловно „в съответствие".

## Кои делегирани актове по ESPR сте моделирали?

**TL;DR:** Матрица за всеки шаблон: бижутерия, химикали, мебели, гуми, електроника. Спекулативни преди финалните актове; изрично обозначени.

Доставяме шаблони за бижутерия, химикали, мебели, гуми и електроника. Всеки шаблон се съпоставя с предложените полета от делегираните актове, известни към момента на пускане; спекулативните полета са маркирани в метаданните на схемата.

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

Доставчици, които твърдят „вече поддържаме всички делегирани актове по ESPR", твърдят нещо, което още не съществува — актовете са все още в процес на изготвяне.

## Как обновявате схемите, когато регулацията се развива?

**TL;DR:** Версионирани шаблони. Публичен регулаторен changelog. Паспортите в обращение не се засягат от изменения.

Шаблоните са версионирани. Добавянето на поле не е промяна с прекъсване; промяната или премахването създава нова версия на схемата с изричен път за миграция. Паспортите в обращение остават валидни спрямо оригиналната си схема; изменените паспорти се валидират спрямо най-новата версия.

Всяка регулаторна промяна, която проследяваме, се записва в публичния Регулаторен Changelog с дата, обхват и въздействие върху миграцията. Клиентите се уведомяват преди всяка промяна на схемата да влезе в сила.

Доставчици, които казват „ще ви известим", прехвърлят разходите за миграция обратно към вас. Версионираните шаблони превръщат регулаторно изменение в 30-минутен преглед вместо в проект.

## Могат ли компетентните органи да правят заявки към машинно четими endpoints?

**TL;DR:** JSON-LD чрез content negotiation на всеки публичен URL на паспорт. Съответстващ на GS1 Digital Link.

Всеки публичен URL на паспорт връща валиден JSON-LD, когато заявката носи Accept: application/ld+json. Същият URL връща HTML за браузъри и JSON-LD за обхождачи и системи на компетентни органи — без отделен endpoint за откриване.

URL следват граматиката на GS1 Digital Link (.../01/{GTIN}/21/{serial}). Resolver се тества за съответствие спрямо референтния набор на GS1.

Доставчици, които връщат само text/html на URL на паспорта, не преминават основния тест за оперативна съвместимост.

## Идентифицира ли паспортът всички икономически оператори, които регулаторът очаква?

**TL;DR:** Да. Производител + рециклатор + организация за отговорност на производителя + вносител + упълномощен представител + дистрибутор като структурирана карта на ролите с валидирани GS1 GLN ключове. Изискваните роли по категория съответстват на всяко регулиране.

Всеки паспорт носи структурен блок `parties`, ключиран по роля на икономическия оператор. Всеки запис има валидиран GS1 GLN (13 цифри, mod-10 контролна цифра), правно име, ISO 3166-1 код на държава и опционален URL. GLN се излъчва и в `gs1:partyGLN` (GS1 Web Vocabulary, прецизен спрямо спецификацията), и в `schema:identifier` с `propertyID: "GS1:GLN"` (schema.org огледало), така че DPP-съвместимите четци и стандартните schema.org обхождачи да виждат това, което очакват.

За доставчици без GLN, поле `legacyOperatorId` приема VAT, EORI, национален данъчен идентификатор или вътрешен код на доставчик — всяка страна остава проследима дори преди GS1 онбординг на доставчика да е завършил.

Изискваните роли по категория съответстват на регулирането: паспортите на батерии изискват производител + рециклатор + PRO; играчките изискват производител + вносител; категориите с опаковки (FMCG, опаковки) изискват PRO. Опционалните роли се показват в редактора, но не блокират публикуването. Същата карта на ролите управлява редактора в таблото, v1 API (`PATCH /api/v1/passports/{id}/parties/{role}`) и CSV шаблоните за масово импортиране (колони с точкови ключове: `manufacturer.gln`, `recycler.legalName` и т.н.).

Повечето DPP доставчици днес моделират само производителя като свободен текст. Купувач със GS1-родни основни данни се нуждае от пълна верига от икономически оператори, валидирана и структурирана — единични текстови полета за производител не оцеляват при процедура на снабдяване в нито едно GS1-ключово предприятие.

## Какъв е вашият SLA?

**TL;DR:** 99,9% за портала, 99,95% за resolver. Resolver е отделен, защото регулаторите го заявяват директно.

Два отделни SLA: 99,9% за портала на приложението, в който вие и вашият екип работите; 99,95% за публичния resolver, който компетентните органи и крайните потребители достигат през QR кодове. Resolver е зад CDN и репликиран в няколко региона за по-високата цел.

Статус страницата проследява и двете повърхности независимо. Кредитите за прекъсване се прилагат за всяка повърхност — кредитите за портала не изискват прекъсване на resolver, и обратно.

Единен SLA за портала и resolver скрива асиметричния риск: resolver е частта, която не може да пада без регулаторни последици.

## Къде се съхраняват данните?

**TL;DR:** Само в ЕС. Основна база данни във Франкфурт; CDN, имейл, мониторинг — всички в ЕС.

Основна база данни: self-hosted MongoDB на Hetzner Falkenstein (Германия). Изпълнителна среда на приложението: Vercel EU edge региони. Доставка на имейли: Resend (ЕС). Мониторинг и логване: в ЕС регион. Пълен списък на под-обработващите с юрисдикции на trust страницата.

Не използваме под-обработващи само в САЩ за пътища с продукционни данни. Пътят за AI обработка през Anthropic (използван за извличане на категории и преводи) се извиква само по заявка на клиента и е управляван от изричен DPA — trust страницата документира това в детайли.

Доставчик със седалище в САЩ с превключвател „ЕС регион" не е същото като ЕС-резидентна операция; проверявайте под-обработващите внимателно.

## Как работите с GDPR — достъп на субекта на данните, изтриване, разкриване на под-обработващи?

**TL;DR:** Налице DPA. Публикуван регистър на под-обработващите. Endpoints за SAR и изтриване съществуват. 72-часово известяване при пробив.

Стандартен DPA за обработващ е наличен; подписва се преди да потекат клиентски данни. Регистърът на под-обработващите на trust страницата изброява всеки обработващ с роля и юрисдикция; добавянията предизвикват предварително известяване съгласно член 28.

Заявките за достъп на субекта и изтриване могат да бъдат обслужени срещу аналитичната повърхност (съдържанието на самия паспорт е продуктови данни, а не лични данни). Известяване при пробив: 72 часа от потвърден инцидент, кодифицирано в DPA.

Повечето DPP полета не са лични данни, така че рискът по GDPR се концентрира в аналитиката на сканирания. Доставчиците, които логват IP, user-agent и referrer при всяко сканиране, създават експозиция, за която вашият екип по поверителност трябва да знае.

## Какви са вашите политики за резервно копие и съхранение?

**TL;DR:** Операционни резервни копия (30-дневно PITR) и съхранение по жизнения цикъл на продукта, съобразено с категорията, проследявани отделно.

Операционни резервни копия: ежедневно автоматизирано логическо копие на основната база данни се записва в криптирано EU обектно хранилище (Cloudflare R2), съхранявано извън сървъра на базата данни със 7-дневно задържане.

Съхранение по жизнен цикъл на продукта: паспортите остават активни и заявими през целия регулаторен жизнен цикъл, приложим към всяка продуктова категория, в съответствие с относимите ESPR или секторно-специфични очаквания за съхранение. Жизненият цикъл се прилага дори след прекратяване на абонамента, за продължителността на прозореца за непрекъснатост на resolver.

„Резервно копие всяка нощ" не е отговорът на този въпрос. Релевантната политика е дали паспортът все още се резолвира в 12-та година от живота на продукта.

## Как са изолирани данните на наемателите?

**TL;DR:** Логическа изолация (обхват по companyId) по подразбиране. Ниво физическа изолация на Enterprise.

Изолацията по подразбиране е логическа: всяко четене и запис е с обхват по companyId, налаган на слоя за достъп до данни (не на контролера). Тестове проверяват, че обхватът не може да бъде заобиколен дори с умишлено пропускане на companyId в заявките.

Enterprise клиентите могат да поискат физическа изолация: данните им живеят в отделен MongoDB клъстер, с отделен инстанс на приложението. Ценообразуването е по договаряне; време за изпълнение — дни, не седмици.

Логическа изолация, наложена само на контролерите (а не на слоя за данни), създава реален риск от изтичане; питайте къде се прилага обхватът.

## На паспорт, на сканиране, на SKU или на сериен номер — как работи ценообразуването?

**TL;DR:** Стъпаловиден лимит за паспорти. Никога на сканиране. Пакет за серийни обеми за производители с голям обем.

Стъпаловиден лимит за паспорти. Всеки план включва брой паспорти; надвишеният обем се измерва по публикувана цена, която намалява в мащаб. Никога не таксуваме на сканиране — обемът на потребителските сканирания е непредсказуем, и няма да ви изпратим изненадваща фактура, когато някой от продуктите ви стане модерен.

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

Ценообразуването на сканиране е най-опасният модел в DPP — нивата на сканиране се определят от вашите клиенти, не от вас. Нивата на паспорт връзват сметката с това, което вие контролирате: размера на каталога.

## Как изглеждат напускането и миграцията?

**TL;DR:** Пълен JSON-LD експорт, без такса. 30-дневен гратисен период за resolver след прекратяване. Клиентът-като-администратор през цялото време. По избор source escrow.

Пълен JSON-LD експорт на всеки паспорт, продукт, шаблон и медиен прикачен файл е наличен при поискване безплатно. Без „такса за експорт".

След прекратяване TracePass продължава да резолвира вашите съществуващи паспорти 30 дни без такса (кодифицирано в Рамковия договор за услуги). През този прозорец QR кодовете върху вече отпечатани опаковки продължават да резолвират към вашите данни, докато мигрирате; при персонализиран домейн пренасочвате DNS към следващ доставчик и отпечатаните кодове никога не се чупят.

Клиентът е администратор на данните през цялото времетраене на взаимоотношението и след прекратяване. По избор source escrow е наличен на Enterprise: тагнато копие на изходния код на приложението ни се съхранява от независима трета страна, освободимо към вас при определени тригерни събития.

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

## Какви са вашите условия за отговорност и носите ли E&O застраховка?

**TL;DR:** 12× месечен лимит по подразбиране; 24× допълнително за Enterprise. E&O застраховка налична; лимитът публикуван.

Стандартен лимит на отговорността: 12× месечни такси. Enterprise клиентите могат да договорят 24× допълнително за по-високи рискови профили.

E&O застраховка е налична; лимитът на полицата е публикуван на trust страницата. Trust страницата също изброява изключенията при обезщетяване (искове за IP от трети страни, регулаторни санкции, проследими до грешка на доставчика).

Повечето SaaS компании ограничават отговорността до 12× месечно. За производител в ЕС с потенциална експозиция към глоби това е малка утеха — настоявайте за изричен допълнителен лимит.

## Ако напуснем, какво всъщност е наше — данните, URL адресът, паспортите?

**TL;DR:** Всичко. Вие притежавате данните (пълен JSON-LD експорт, без такса), URL адреса (resolver на собствен домейн) и произхода (одитна следа на ниво поле). Без такса за напускане, без заложен resolver.

Данните са ваши. Всеки платен план включва пълен JSON-LD експорт на всеки паспорт, продукт и шаблон — със запазени произход и история на версиите — без такса, плюс CSV по категории, който се връща обратно във всеки ERP/PIM. Няма такса за експорт и няма собствен формат, който не можете да четете другаде.

URL адресът е ваш. На всеки платен план GS1 Digital Link се резолвира под ваш собствен домейн чрез DNS, който контролирате. Ако напуснете, пренасочвате този DNS към следващ доставчик и QR кодовете, вече отпечатани върху изпратени продукти, продължават да работят — най-големият и най-малко обсъждан риск от заключване в DPP, неутрализиран по дизайн.

Непрекъснатостта е договорна. 30-дневен гратисен период след прекратяване поддържа паспортите ви резолвиращи, докато мигрирате; вие оставате администратор на данните през цялото време; а Enterprise клиентите могат да добавят source escrow с дефинирани тригери за освобождаване (несъстоятелност, неотстранено нарушение, продължителен срив). Всяко от тези е описано в собствен отговор по-долу.

„Вие притежавате данните си" е минимумът и е лесно да се каже. Въпросите, които разделят доставчиците, са кой притежава resolver URL адреса върху отпечатания QR и какво се случва с 20-годишен паспорт, ако доставчикът не издържи 20 години. Ако тези две не са отговорени писмено, експортът на данни няма значение.

## Децентрализирани идентификатори и verifiable credentials — в пътната карта?

**TL;DR:** В пътната карта. Посока EBSI. Изграждане при първото изискване на потенциален клиент.

Поддръжка на DID/VC не е в продукта в момента. Архитектурата е съвместима — документите на паспорта са content-addressable, редакциите са подписани, и схемата може да носи credential доказателства като допълнителен набор от полета.

Тригер за пускане: първа сделка, която издига VC издаване като твърдо изискване. Бележки за дизайна на разположение при поискване.

Доставчици, които твърдят жива VC поддръжка днес, обикновено демонстрират прототипи. Самата EBSI екосистема все още е пред-продукционна за повечето сценарии на употреба.

## Могат ли паспортите да се отпечатват с времеви печат или нотариално заверяват за защита от подправяне?

**TL;DR:** Одитна следа на ниво поле с времеви печат и автор; видима в историята на паспорта. Криптографско закотвяне + нотариална заверка от трета страна — в пътната карта.

Всеки запис на поле минава през един единствен път на актуализация, който добавя одитен запис — времеви печат, автор, предишна стойност, източник (ръчно / AI / API / доставчик). Историята на ниво поле е заявима през API и видима във времевата линия на версиите на паспорта. Записите са само за добавяне по конвенция на приложението.

Криптографско закотвяне (верига от хешове на съдържанието върху одитните записи на всеки паспорт, евентуално съ-подписана от доверен орган за времеви печат или публичен регистър) е в пътната карта и все още не е изградено. Тригер: първи потенциален клиент, който го изисква за защита от подправяне, защитима пред регулатор. Дотогава одитната следа е проверима спрямо нашата база данни, а не независимо — посочвайте това изрично във всеки отговор на тръжна процедура, който пита за защита от подправяне.

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

## Съответствие спрямо публикувани стандарти за оперативна съвместимост?

**TL;DR:** Публикуван резултат от съответствие с GS1 Digital Link. Речник, съгласуван с CIRPASS. Schema.org JSON-LD + GS1 речник (gs1:partyGLN) на всеки паспорт. Валидирани GLN идентификатори по роля на икономическия оператор.

Публикуваме резултата от теста за съответствие с GS1 Digital Link на trust страницата. Schema.org JSON-LD се излъчва на всеки публичен URL на паспорт. Съгласуването на речника с препоръките на CIRPASS е документирано поле по поле.

GS1 GLN (Global Location Number) идентификаторите са първокласни полета на всеки паспорт — стриктна 13-цифрова mod-10 валидация, ключове по множество роли (производител / вносител / упълномощен представител / дистрибутор / рециклатор / организация за отговорност на производителя) и излъчване и в gs1:partyGLN, и в schema:identifier „GS1:GLN" форма, така че DPP-съвместимите четци и стандартните schema.org обхождачи да виждат това, което очакват.

Където съответствието е частично (напр. препоръки на CIRPASS, които са след последния ни преглед на съгласуването, или /414/{gln} резолвър пътят, който е в пътната карта build-on-first-ask), пропускът е изрично назован с целева версия.

„Следваме спецификацията" не е претенция за съответствие. Търсете тествани резултати, не заявени намерения.

## Могат ли потенциалните клиенти да влияят върху решения за схеми при пред-финални делегирани актове?

**TL;DR:** Да. Pro/Enterprise потенциални клиенти оформят шаблоните за пред-финални делегирани актове чрез документиран механизъм.

За категории, в които делегираният акт още не е финален, поддържаме изрични маркери за спекулативни полета в шаблона. Pro и Enterprise клиентите могат да подават предложения на ниво поле, които влизат в следващата версия на шаблона след кратък преглед.

Клиентите се изброяват като сътрудници в блока с метаданни на шаблона — кредит и проследимост за приноса.

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

## Source escrow, ако фалирате?

**TL;DR:** Достъпно на Enterprise. Тагнат изходен код се пази от независима трета страна с дефинирани тригери за освобождаване.

Enterprise клиентите могат да изберат source escrow чрез независим escrow агент от трета страна. Тагнато копие на изходния код на приложението се депозира и обновява на повтарящ се ритъм.

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

Source escrow без дефинирани тригери за освобождаване е театър; тригерите са същината.