CONTROL PLANE · OWNERSHIP · EVIDENCE FLOW

Архитектура и границы ответственности

CertaRail отделяет намерение и проверяемое решение от внешнего исполнения. Организация остаётся владельцем identity, денег и полномочий; CertaRail нормализует intent, применяет policy и сохраняет evidence; провайдер подтверждает только собственный внешний эффект.

Граница выполнения
CONTROL PLANE · EXTERNAL EXECUTION SEPARATE
Control-plane и evidence architecture
РЕАЛИЗОВАНО
Контракты и исходные файлы

OpenAPI, схемы и примеры для скачивания.

Роль CertaRail в системе

CertaRail — control plane, а не биржа, wallet, custody или платёжный rail. Он принимает заверенные организацией факты, вычисляет допустимость следующего шага и сохраняет воспроизводимый след решения.

Статус ALLOW или APPROVED не означает order, payment, withdrawal, blockchain broadcast либо regulator submission. Такой эффект существует только после отдельной команды активированному внешнему контуру и authoritative receipt от его владельца.

Evidence before execution
Ни UI, ни успешный HTTP response не повышают capability до внешнего исполнения. Implementation, activation, environment, external effect и production readiness проверяются независимо.

Границы ответственности

Владельцы фактов и эффектов
КонтурВладеетПередаёт дальшеНе делегирует CertaRail
ОрганизацияIdentity, KYC/KYB, consent, account authority, лимиты и customer masterOpaque references и заверенные assertionsПДн, деньги, private keys и финальное полномочие на действие
CertaRailIntent normalization, policy decision, reason trace, idempotency и evidenceAdmission result, audit receipt, provider-neutral command/evidence referencesExternal execution, legal approval или истинность исходных assertions
Внешний провайдерVenue, payment, custody, KYT либо иной provider-specific lifecycleAuthoritative provider object и receiptPolicy и tenant authority организации
Официальный каналФорма, подпись, транспорт и receipt регулятораЮридически значимое подтверждение при отдельной активацииНе выводится из локального report draft

Путь от intent до evidence

  1. Организация создаёт intent

    Канал организации подтверждает действие пользователя и добавляет только server-trusted facts и opaque references.

  2. Policy вычисляет decision

    ALLOW, REVIEW или DENY фиксируются вместе с versioned rule trace; это admission, не execution.

  3. Commit сохраняет evidence

    Decision, canonical digests, audit sequence и outbox record коммитятся в authoritative store.

  4. Активированный adapter получает отдельную команду

    Только доступный provider route может создать внешний эффект; отсутствие authority закрывает gate.

  5. Receipt возвращается как observation

    Provider result, movement или official receipt связываются с исходным decision без переписывания истории.

Runtime-компоненты и authoritative state

Роль компонентов в control plane
КомпонентНазначениеГраница истины
Go APIHTTP contracts, tenant boundary, validation и domain orchestrationНе повышает ответ до external effect без provider evidence
PostgreSQLAuthoritative decisions, lifecycle state, audit chain, idempotency и transactional outboxDurable source of truth внутри доступного runtime
RedisНеавторитетное ускорение чтений и bounded coordinationCache miss или error не создаёт eligibility-факт
KafkaАсинхронная доставка committed events через outboxAt-least-once требует idempotent consumer; schema-only не равно published
Nginx / gateway boundaryRouting, headers и входные transport controlsProduction WAF, mTLS, certificates и operations активируются отдельно

Цифровые активы и внешнее исполнение

  • Asset code обозначает экономический актив; network — конкретный blockchain или расчётный контур. Допустимость пары задаёт governed registry.
  • Wallet ref — opaque ссылка, address — публичный сетевой идентификатор, private key или seed — право подписи. Key material не входит в CertaRail domain payload.
  • Суммы цифровых активов передаются целыми atomic units и decimals, а не float.
  • Transaction ID идентифицирует сетевую транзакцию, но сам по себе не доказывает ownership, confirmations или finality. Порог подтверждений и reorg risk задаются network-specific policy.
  • Decision не является venue order или fill; movement endpoint фиксирует observation и не является withdrawal/transfer command.
  • KYT, payment, venue, custody, mainnet broadcast и official reporting имеют отдельные credentials, owners, activation gates и receipts.

Ключевые термины архитектуры

Термины без привязки к экрану Console
ТерминКанонический смысл
AdapterProvider-specific перевод нейтрального контракта в auth, payload и lifecycle внешней системы
Canonical digestSHA-256 от однозначно сериализованных данных для обнаружения изменения
IntentНормализованное намерение; ещё не внешняя команда
DecisionALLOW, REVIEW или DENY с versioned reason trace
EvidenceПроверяемый след входа, решения и наблюдаемого результата
Opaque referenceИдентификатор без встроенных ПДн и бизнес-смысла
IdempotencyОдна command identity не создаёт два бизнес-эффекта
ObservationЗапись уже увиденного факта; сама ничего не исполняет
ReconciliationСверка внутреннего state с authoritative state владельца
Fail-closed / fail-softОпасный side effect закрывается при неопределённости; неавторитетный cache может деградировать без создания нового факта
TenantИзолированная организация; identity и scope выводятся из trusted principal, а не из URL или свободного поля
Activation gateПроверяемое условие допуска к следующему environment/effect

Нашли неточность?

Участники private repository могут предложить правку через reviewed pull request. Остальные пользователи — отправить техническое сообщение без credentials и чувствительных данных.