Перейти к основному содержимому

Tenant Configuration And Enablement — Тенантная настройка, policy и ввод в эксплуатацию

Версия: 1.0
Дата: 24.04.2026
Статус: Готов к обсуждению

Назначение документа​

Этот документ фиксирует отдельный домен tenant configuration and enablement.

Его задача — определить:

  • как платформа включает в работу агентство, партнёра или другой tenant;
  • какие policy и capability настройки живут на tenant-layer;
  • как один и тот же platform core по-разному проявляется для разных tenant-ов;
  • где проходят tenant-specific supplier, channel, pricing, quote, booking and publication rules.

Этот документ дополняет, но не заменяет Tenancy And Identity — Субъекты платформы, изоляция и модель доступа.

Опорные документы​

Почему Этот Документ Нужен Отдельно​

Сам факт существования tenant, workspace и capability scope ещё не объясняет, как конкретный tenant реально работает на платформе.

Для промышленной distribution-platform этого недостаточно.

Нужно отдельно описать:

  • как tenant onboarded;
  • какие suppliers ему доступны;
  • какие рынки, currencies, languages and surfaces он использует;
  • какие commercial rules и financial rules на него действуют;
  • какие publication limits у него есть;
  • какие API quotas и product entitlements ему выданы.

Главный Принцип Tenant Enablement​

Tenant — это не только boundary of isolation, но и boundary of policy expression.

Из этого следует:

разница между tenant-ами должна определяться не хаотическими условными if-ами в surface code, а управляемым configuration and policy layer.

Основные Классы Tenant Настроек​

1. Identity And Access Configuration​

  • allowed actor roles;
  • workspace structure;
  • service credential policy;
  • environment binding;
  • allowed surfaces.

2. Supplier Configuration​

  • supplier allow-list / deny-list;
  • geography or market restrictions;
  • supplier priority;
  • fallback rules;
  • supplier-specific publication restrictions.

3. Commercial Configuration​

  • markup policy;
  • fee policy;
  • discount policy;
  • quote validity profile;
  • channel-specific price visibility;
  • override permissions.

4. Financial Enablement​

  • clearing mode;
  • deposit requirement;
  • credit limit;
  • billing model;
  • settlement timing expectations;
  • manual review thresholds.

5. Contract And Surface Enablement​

  • enabled API families;
  • enabled UI workflows;
  • rate limits and quota profiles;
  • booking permissions;
  • proposal/publication permissions;
  • webhook/event subscriptions.

6. Governance And Publication Configuration​

  • anomaly thresholds;
  • review requirements;
  • publication hold rules;
  • risk-gated supplier exposure;
  • operator escalation requirements.

Tenant Types Не Должны Быть Одинаковыми​

Платформа должна уметь различать как минимум:

  • internal tenant;
  • agency tenant;
  • partner tenant;
  • white-label / embedded tenant;
  • high-trust and low-trust partner profiles.

У них не обязаны совпадать:

  • доступные suppliers;
  • allowed booking models;
  • financial conditions;
  • publication rules;
  • API envelopes;
  • support expectations.

Tenant Enablement Lifecycle​

Каждый tenant должен проходить управляемый lifecycle:

  1. pre-onboarding assessment;
  2. configuration design;
  3. credentials and access issuance;
  4. supplier and commercial enablement;
  5. financial enablement;
  6. controlled activation;
  7. post-activation monitoring;
  8. change and re-certification where needed.

Tenant Configuration Is Product Logic​

Этот слой нельзя считать “админкой для галочек”.

Он определяет:

  • что tenant реально может продавать;
  • на каких основаниях он это продаёт;
  • как platform risk ограничивается;
  • какие promises получает downstream consumer;
  • какие operational and financial consequences допустимы.

Связь С Surface-ами​

Partner API​

Tenant configuration должна определять:

  • какие resources доступны;
  • какие rates and quotas разрешены;
  • какие booking actions допустимы;
  • какие webhooks and async surfaces включены.

Agency Surface​

Tenant configuration должна определять:

  • какой working model разрешён;
  • какие proposals and bookings можно создавать;
  • какие suppliers and markets доступны;
  • какие price views and overrides возможны.

Что Должно Быть Сделано Дальше​

После фиксации этого документа нужно:

  • синхронизировать tenancy-and-identity, commercial-model, api-contracts, clients, partner-finance-and-clearing;
  • определить persistent model tenant policy sets;
  • описать enablement states and certification gates;
  • оформить operational onboarding playbooks.

Уточнение под Фазы 4–6 (28.04.2026) — связь с tier, isolation, capability, security, certification​

Документ опубликован 24.04.2026 (Фаза 3). Tenant configuration напрямую интегрирована с каноничными доменами Фаз 4–6.

Связь с tier-моделью API as Product​

reference/api-as-product.md (Фаза 4) — каноничные 4 tier (Free / Starter / Professional / Enterprise) — первый параметр tenant configuration:

  • tier определяет SLA, rate limits, isolation level, supported features;
  • tier transitions (upgrade/downgrade) — каноничный flow через self-service для Starter/Professional, custom contract для Enterprise;
  • partner class (trusted / standard / sandbox-only) — поверх tier.

Связь с уровнями тенантной изоляции​

reference/multi-tenant-isolation-strength.md (Фаза 5) — каноничные 3 isolation levels (logical / dedicated_compute / dedicated_infrastructure) — конфигурация tenant:

  • по умолчанию logical для всех tier;
  • dedicated_compute опционально для Professional, mandatory для Enterprise (если регуляторное);
  • dedicated_infrastructure mandatory для regulated Enterprise.

TenantIsolationProfile — каноничная сущность tenant configuration.

Связь с capability matrix​

reference/clients.md (Фаза 7) — каждый tenant имеет capability set определяемый через (tier, isolation_level, partner_class). Tenant configuration explicit грантирует/revokes capabilities. Caнoнический resolver GET /capability/me.

Связь с certification flow​

reference/api-as-product.md — partner certification — operational часть tenant enablement:

  • sandbox provisioning — automated через self-service;
  • production certification — KYC + AML + DPA signed + integration tests passed;
  • production credentials issuance — после certification;
  • ongoing recertification (например, при major API version bump).

Связь с compliance — DPA management​

reference/compliance-and-legal.md (Фаза 4) — tenant enablement требует:

  • DPA (Data Processing Agreement) signed per partner;
  • sub-processor disclosure acknowledged;
  • privacy notice acceptance;
  • lawful basis zafiksирован для each data flow.

Без compliance — production credentials не выпускаются.

Связь с security baseline​

reference/security-architecture.md (Фаза 10) — security configuration per tenant:

  • MFA enforcement — Level 2 для Professional+, Level 3 (step-up) для critical operations;
  • API key lifecycle — automated rotation 90 дней;
  • Audit log access — read-only для tenant admin для собственных logs;
  • Per-tenant encryption keys для Enterprise.

Связь с partner finance configuration​

reference/partner-finance-and-clearing.md — финансовая часть tenant configuration:

  • credit limits per tier;
  • deposit requirements (по контракту);
  • payout frequency (weekly/monthly per tier);
  • netting rules для multi-currency partners;
  • clearing currency.

Связь с notification preferences​

reference/notification-and-communication.md (Фаза 4) — tenant configures:

  • webhook endpoints + signing secrets;
  • email contact lists для billing / SLA breach / incidents;
  • SLA breach notification preferences;
  • partner-facing dashboard subscriptions.

Связь с metering и quota​

reference/api-metering-and-usage-governance.md — tenant configuration включает:

  • quota envelope per tier;
  • rate limits per endpoint;
  • fair use rules для shared infrastructure tenants;
  • alerts thresholds (custom для Enterprise).

Связь с tenant economic profile​

reference/economic-model.md (Фаза 4) — TenantEconomicProfile каноничная сущность:

  • expected revenue per period;
  • expected cost (variable per usage);
  • expected margin;
  • service credits accumulation;
  • VAT regime.

Связь с DR posture per tier​

operations/disaster-recovery-and-capacity.md (Фаза 6) — DR class per tenant:

  • Free/Starter — Tier 1 baseline (shared infrastructure);
  • Professional — Tier 1 + ежемесячные partial restore drills;
  • Enterprise — Tier 1 + custom RTO/RPO в контракте + secondary region cold standby.

Связь со SLA tier​

operations/sla-and-on-call-model.md (Фаза 6) — каноничный SLAObligation per tenant:

  • Free — best-effort;
  • Starter — 95%;
  • Professional — 99%;
  • Enterprise — 99.9%+.

SLAClass — каноничная сущность tenant configuration.

Каноничный итог уточнения​

Tenant configuration становится central conjunction всех tier-зависимых характеристик. Реализация:

Уточнение выполнено через no-destruction.