Допустим, команда Atlas получает требование:

Авторизованный пользователь может открыть отчёт.

Это ещё не спецификация. Здесь смешаны идентичность, состояние аккаунта, роль, отношение пользователя к ресурсу, свежесть аутентификации, область арендатора, время действия разрешения и поведение системы при недоступности зависимостей. Если сразу написать if, неявная логика распределится между контроллером, React-компонентом, SQL-запросом и middleware.

Инженерная редакция главы проследит один и тот же путь:

неясное требование
  → аргумент и скрытые посылки
  → доменные понятия
  → предикаты и таблица решений
  → типы и инварианты
  → исполнимая политика
  → эффекты и отказы
  → архитектурная граница

Мы не будем переводить один if на шесть языков. C# и Java покажут объектную модель и спецификации, TypeScript и JavaScript — алгебраические типы и композицию предикатов, Python — декларативную политику и свойства, Elixir — сопоставление с образцом, конвейер и явные ошибки. Это разные способы думать о правиле, а не витрина синтаксиса.

Архитектурные обсуждения тоже начинаются с риторики:

Пользователи жалуются на скорость, поэтому перепишем сервис на Elixir.

Elixir может быть отличным выбором, но посылка описывает симптом, а вывод — конкретное и дорогое решение. Между ними отсутствуют профиль задержек, граница узкого места, модель нагрузки, стоимость миграции и критерий успеха. Даже технически верное утверждение «BEAM хорошо работает с большим числом лёгких процессов» не доказывает, что задержка возникла из-за модели конкурентности.

Инженерный аргумент полезно раскладывать как ADR:

Наблюдение: p95 открытия отчёта вырос с 280 мс до 1,8 с.
Причина: 74% времени занимает последовательный вызов трёх policy-сервисов.
Ограничение: нельзя ослаблять аудит и изоляцию арендаторов.
Варианты: параллельные вызовы, локальный снимок политики, смена протокола,
          перенос вычисления или переписывание сервиса.
Решение: ...
Проверка: p95 < 500 мс при 2 000 RPS, решения совпадают с эталоном.

Так логика входит в архитектуру раньше кода. RFC, ADR и design review нужны не для бюрократии, а для восстановления моста между фактом и решением. Хороший документ отделяет измерение от интерпретации, ограничение от предпочтения и обратимое решение от необратимого.

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

Требование «пользователь может экспортировать отчёт» — инженерная энтимема. В нём пропущено общее правило: какой пользователь, какой отчёт, в каком tenant, при каком состоянии сессии и что означает «может» — увидеть кнопку, получить 200 OK или завершить асинхронный экспорт?

ООП полезно здесь не потому, что «всё является объектом», а потому, что модель может закрепить понятия и запретить случайные подстановки. В C# начнём не с User.IsAdmin, а с разных идентичностей и явного решения:

public readonly record struct EmployeeId(Guid Value);
public readonly record struct ReportId(Guid Value);
public readonly record struct TenantId(Guid Value);

public sealed record AccessRequest(
    EmployeeId EmployeeId,
    ReportId ReportId,
    TenantId TenantId,
    DateTimeOffset RequestedAt);

public abstract record AccessDecision
{
    public sealed record Allowed(string PolicyVersion) : AccessDecision;
    public sealed record Denied(DenialReason Reason) : AccessDecision;
}

Отдельные типы не доказывают право доступа, зато не дают перепутать EmployeeId и ReportId. Иерархия решения заставляет вызывающий код разобрать не только true, но и причину отказа. Это современная версия аристотелевского шага: убрать сюжет и назвать форму операции.

Затем восстанавливаем скрытые посылки как доменные утверждения:

1. Employee активен в Tenant.
2. Report принадлежит тому же Tenant.
3. Employee является владельцем Report или имеет роль Auditor в его области.
4. Для чувствительного Report сессия должна быть повторно подтверждена.
5. Явный запрет сильнее разрешающей роли.

В Java тот же приём удобно выразить record для значений и sealed interface для конечного набора решений. Смысл не в языке: мы превращаем разговорные существительные в типы, а скрытый переход — в контракт. После этого спор «админ же всё может» становится конкретным вопросом к политике.

Антипаттерн: объект User с десятками флагов и методом CanDoEverything() не моделирует область — он консервирует энтимему внутри универсального контейнера.

Логика высказываний — это фундамент guard clauses, feature flags, firewall rules и условий маршрутизации. Но программисту важно различать импликацию и обычное ветвление. Правило blocked → denied не означает denied → blocked. Если API возвращает только 403, клиент не может восстановить причину.

На JavaScript полезно сначала сделать решение явным, а уже потом сокращать:

function decideAccess(context) {
  if (context.user.blocked) {
    return { kind: "denied", reason: "account-blocked" };
  }

  if (context.report.tenantId !== context.user.tenantId) {
    return { kind: "denied", reason: "tenant-mismatch" };
  }

  if (!context.user.isOwner && !context.user.roles.includes("auditor")) {
    return { kind: "denied", reason: "missing-grant" };
  }

  return { kind: "allowed" };
}

Это длиннее булевого выражения, зато порядок правил и приоритет запрета видны. Если причины нужны для аудита, boolean уже слишком бедный тип результата.

Теперь проверим форму таблицей решений. Для каждого фактора выбираем эквивалентный класс, а не перебираем весь мир:

Таблица выявляет семантику короткого замыкания. Это уже архитектурное решение: если сначала запросить удалённый сервис ролей, а потом проверить локальную блокировку, система тратит сеть и может утечь через различия во времени ответа.

Законы де Моргана помогают ревьюить отрицания:

НЕ (owner ИЛИ auditor) = НЕ owner И НЕ auditor
НЕ (owner И auditor)   = НЕ owner ИЛИ НЕ auditor

Ошибки здесь регулярно переживают code review, особенно когда позитивная бизнес-фраза превращается в несколько отрицательных guard clauses.

Булева алгебра даёт вычислимую форму, но инженерная задача только начинается. В TypeScript лучше вернуть алгебраический тип решения, а не протащить boolean через всю систему:

type DenialReason =
  | "account-blocked"
  | "tenant-mismatch"
  | "reauth-required"
  | "missing-grant";

type AccessDecision =
  | { kind: "allowed"; policyVersion: string }
  | { kind: "denied"; reason: DenialReason };

type AccessFacts = Readonly<{
  blocked: boolean;
  sameTenant: boolean;
  owner: boolean;
  auditor: boolean;
  reauthenticated: boolean;
}>;

function decide(facts: AccessFacts): AccessDecision {
  if (facts.blocked) return { kind: "denied", reason: "account-blocked" };
  if (!facts.sameTenant) return { kind: "denied", reason: "tenant-mismatch" };
  if (!facts.reauthenticated) return { kind: "denied", reason: "reauth-required" };
  if (!facts.owner && !facts.auditor) {
    return { kind: "denied", reason: "missing-grant" };
  }
  return { kind: "allowed", policyVersion: "reports/v3" };
}

Здесь функция чистая: одинаковые факты дают одинаковое решение, сеть и БД не спрятаны внутри. Readonly не делает программу математически чистой, но закрепляет намерение не менять вход во время вычисления.

Чистое ядро позволяет проверять не только примеры, но и свойства:

// Псевдокод property-based теста
forAll(accessFacts, (facts) => {
  if (facts.blocked) {
    expect(decide(facts)).toEqual({
      kind: "denied",
      reason: "account-blocked"
    });
  }
});

Полезные свойства политики:

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

Это уже функциональный дизайн: данные неизменяемы, решение выражено значением, эффекты вынесены за границу. Позже мы сравним его с объектной спецификацией.

Фрегеанский переход от высказывания к предикату знаком любому разработчику:

canOpen(user, report) → Decision

В Python удобно отделить факты от политики и сделать зависимости явными:

from dataclasses import dataclass
from datetime import datetime
from enum import StrEnum

class Role(StrEnum):
    AUDITOR = "auditor"
    MANAGER = "manager"

@dataclass(frozen=True)
class User:
    id: str
    tenant_id: str
    roles: frozenset[Role]
    blocked: bool

@dataclass(frozen=True)
class Report:
    id: str
    tenant_id: str
    owner_id: str
    sensitive: bool

@dataclass(frozen=True)
class AccessContext:
    user: User
    report: Report
    reauthenticated_at: datetime | None

def has_grant(ctx: AccessContext) -> bool:
    return (
        ctx.user.id == ctx.report.owner_id
        or Role.AUDITOR in ctx.user.roles
    )

Теперь кванторы проявляются в API коллекций:

all(can_open(user, report) for report in reports)  # ∀ report
any(can_open(user, report) for report in reports)  # ∃ report

Подмена all на any — не мелкая ошибка цикла, а изменение логического утверждения. В SQL та же разница скрывается между NOT EXISTS и EXISTS, а в ORM может потеряться за удобным именем метода.

Ещё важнее область действия квантора. Проверка «пользователь имеет роль аудитора в какой-нибудь организации» не равна «пользователь является аудитором организации этого отчёта». Предикат должен включать ресурсную область:

def is_auditor_for(user: User, report: Report) -> bool:
    return (
        user.tenant_id == report.tenant_id
        and Role.AUDITOR in user.roles
    )

На архитектурном уровне это защита от confused deputy и cross-tenant access. Роль без области — почти всегда неполная модель. Если политика переводится в SQL, фильтр tenant должен быть частью запроса, а не постфильтрацией после загрузки данных.

Инженеры часто пересказывают Гёделя как «невозможно доказать программу», но это слишком грубо. Для конкретных программ доказывают свойства, используют типы, model checking и proof assistants. Ограничение в другом: выразительность, непротиворечивость, разрешимость и полнота не выдаются одновременно бесплатно.

В прикладной модели первая линия защиты — сделать недопустимые состояния непредставимыми. Java sealed interface ограничивает пространство principal:

public sealed interface Principal
        permits Employee, ServiceAccount, Anonymous {}

public record Employee(
        EmployeeId id,
        TenantId tenantId,
        Set<Role> roles,
        AccountStatus status
) implements Principal {}

public record ServiceAccount(
        ClientId id,
        TenantId tenantId,
        Set<Scope> scopes
) implements Principal {}

public record Anonymous() implements Principal {}

Компилятор может потребовать полный switch по вариантам. Но он не докажет, что tenantId пришёл из доверенного источника, что роль не отозвана секунду назад или что часы двух сервисов согласованы. Типовая модель очерчивает одну границу доказательства, а не заменяет систему безопасности.

В C# nullable reference types отличают «значение может отсутствовать» от случайного null, required не даёт забыть поле при инициализации, а закрытый конструктор может сохранять инвариант:

public sealed class TemporaryGrant
{
    public EmployeeId EmployeeId { get; }
    public ReportId ReportId { get; }
    public DateTimeOffset ExpiresAt { get; }

    private TemporaryGrant(
        EmployeeId employeeId,
        ReportId reportId,
        DateTimeOffset expiresAt)
    {
        EmployeeId = employeeId;
        ReportId = reportId;
        ExpiresAt = expiresAt;
    }

    public static TemporaryGrant Create(
        EmployeeId employeeId,
        ReportId reportId,
        DateTimeOffset expiresAt,
        DateTimeOffset now)
    {
        if (expiresAt <= now) throw new ArgumentOutOfRangeException(nameof(expiresAt));
        return new(employeeId, reportId, expiresAt);
    }
}

Но время передано аргументом не случайно. Если класс сам вызывает DateTimeOffset.UtcNow, тест и доказательство свойства начинают зависеть от неявного эффекта.

Граница формализации должна быть записана рядом с моделью:

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

Чистая функция decide(facts) ничего не знает о получении фактов. Настоящий use case читает пользователя, отчёт, роли и состояние сессии, затем пишет аудит. Это граница между functional core и imperative shell.

Elixir делает возможные отказы видимыми через значения и pattern matching:

def open_report(user_id, report_id, now) do
  with {:ok, user} <- Users.fetch(user_id),
       {:ok, report} <- Reports.fetch(report_id),
       {:ok, session} <- Sessions.current(user_id),
       facts <- AccessFacts.from(user, report, session, now),
       {:allow, policy_version} <- Policy.decide(facts),
       :ok <- Audit.record(user, report, policy_version) do
    Reports.open(report)
  else
    {:deny, reason} -> {:error, {:forbidden, reason}}
    {:error, :not_found} -> {:error, :not_found}
    {:error, :dependency_unavailable} -> {:error, :temporarily_unavailable}
  end
end

Оператор with не «делает код функциональным» автоматически. Его ценность в явной форме конвейера: каждый шаг возвращает значение успеха или ошибки, а ветка else задаёт семантику отказа. Скрытый сетевой вызов внутри Policy.decide/1 снова смешал бы вычисление и эффект.

Здесь появляется проблема TOCTOU: роль может быть отозвана после чтения, но до открытия отчёта. Возможные архитектурные ответы различны:

• принять eventual consistency и ограничить время жизни снимка;
• выполнять проверку и чтение в одной транзакционной границе;
• выдавать короткоживущий capability token на конкретный ресурс;
• версионировать политику и проверять версию на стороне ресурса;
• отправлять события отзыва и уметь закрывать уже открытые сессии.

Шенноновский взгляд полезен для оптимизации: сложная политика является схемой из логических вентилей. Можно минимизировать повторные условия, но нельзя терять диагностические причины и порядок правил. Самое короткое булево выражение не всегда лучший production-код.

Инженерное правило: сначала определите семантику отказа, затем выбирайте между fail-open и fail-closed. Для доступа к чувствительному отчёту недоступный policy service обычно означает deny или retry, а не молчаливое разрешение.

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

Объектная спецификация на C#

Specification Pattern полезен, когда правила нужно именовать, комбинировать и объяснять:

public interface ISpecification<in T>
{
    bool IsSatisfiedBy(T candidate);
    string Code { get; }
}

public sealed class ActiveAccount : ISpecification<AccessFacts>
{
    public string Code => "active-account";
    public bool IsSatisfiedBy(AccessFacts facts) => !facts.User.IsBlocked;
}

public sealed class SameTenant : ISpecification<AccessFacts>
{
    public string Code => "same-tenant";
    public bool IsSatisfiedBy(AccessFacts facts) =>
        facts.User.TenantId == facts.Report.TenantId;
}

Не стоит строить бесконечное дерево AndSpecification<OrSpecification<...>>, если бизнесу важен порядок причин отказа. Композиция должна сохранять не только bool, но и объяснимость.

Предикаты на Java

Java уже содержит функциональный интерфейс Predicate<T>:

Predicate<AccessFacts> active = facts -> !facts.user().blocked();
Predicate<AccessFacts> sameTenant = facts ->
        facts.user().tenantId().equals(facts.report().tenantId());
Predicate<AccessFacts> hasGrant = facts ->
        facts.user().id().equals(facts.report().ownerId())
        || facts.user().roles().contains(Role.AUDITOR);

Predicate<AccessFacts> canOpen = active.and(sameTenant).and(hasGrant);

Это компактно для фильтрации. Для авторизации production-уровня снова нужен богатый результат: какой предикат не прошёл, какая версия политики действовала, какие факты можно безопасно положить в аудит.

Композиция на TypeScript

Функциональные комбинаторы позволяют собирать policy as data:

type Rule<A> = (value: A) => AccessDecision;

const allow: AccessDecision = { kind: "allowed", policyVersion: "reports/v3" };

const denyWhen = <A>(
  predicate: (value: A) => boolean,
  reason: DenialReason
): Rule<A> => value => predicate(value)
  ? { kind: "denied", reason }
  : allow;

const firstDenial = <A>(...rules: Rule<A>[]): Rule<A> => value => {
  for (const rule of rules) {
    const decision = rule(value);
    if (decision.kind === "denied") return decision;
  }
  return allow;
};

Композиция хороша, пока тип результата сохраняет доменный смысл. Если всё свести к A => boolean, потеряются причины и возможность эволюции контракта.

Динамическая граница на JavaScript

JavaScript удобен для простых предикатов, но вход из HTTP нельзя считать типизированным только потому, что IDE знает JSDoc:

function parseAccessRequest(input) {
  if (!input || typeof input !== "object") {
    return { ok: false, error: "invalid-body" };
  }
  if (typeof input.userId !== "string" || typeof input.reportId !== "string") {
    return { ok: false, error: "invalid-identifiers" };
  }
  return {
    ok: true,
    value: Object.freeze({ userId: input.userId, reportId: input.reportId })
  };
}

Валидация на границе и неизменяемое внутреннее значение важнее классов ради классов. После разбора обычный JavaScript способен поддерживать тот же functional core.

Pattern matching на Elixir

В Elixir правила естественно выражаются несколькими предложениями функции:

def decide(%{blocked: true}), do: {:deny, :account_blocked}
def decide(%{same_tenant: false}), do: {:deny, :tenant_mismatch}
def decide(%{reauthenticated: false}), do: {:deny, :reauth_required}
def decide(%{owner: false, auditor: false}), do: {:deny, :missing_grant}
def decide(_facts), do: {:allow, "reports/v3"}

Порядок предложений является частью политики. Это очень читаемо для first-match семантики, но новый разработчик должен понимать, что перестановка строк меняет результат.

Декларативные правила на Python

Python позволяет собрать правила как данные и получить трассу решения:

Rule = tuple[str, callable]

RULES: tuple[Rule, ...] = (
    ("account-blocked", lambda f: f.user.blocked),
    ("tenant-mismatch", lambda f: f.user.tenant_id != f.report.tenant_id),
    ("missing-grant", lambda f: not has_grant(f)),
)

def decide_with_trace(facts: AccessContext):
    for reason, rejects in RULES:
        if rejects(facts):
            return {"kind": "denied", "reason": reason}
    return {"kind": "allowed", "policy_version": "reports/v3"}

У декларативности есть цена: слабее статические гарантии, легко положить в лямбду эффект и сложнее навигировать по слишком абстрактному DSL.

Итоговый выбор обычно гибридный: доменные объекты защищают локальные инварианты, чистая функция принимает снимок фактов, а application service координирует эффекты. Это не компромисс «ни рыба ни мясо», а разделение разных видов сложности.

Эти три линзы напрямую связаны с архитектурой.

Множества: RBAC, ABAC и область данных

RBAC описывает принадлежность множествам ролей. ABAC вычисляет решение из атрибутов пользователя, ресурса и окружения. Реальная система часто сочетает оба подхода: роль даёт кандидатное разрешение, tenant и классификация ресурса сужают область, явный deny исключает объект.

allowedReports(user)
  = ownedReports(user)
    ∪ auditedReports(user.tenant)
    − explicitlyDeniedReports(user)

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

Инварианты: что обязано сохраниться

При рефакторинге policy engine важны не одинаковые классы, а наблюдаемые свойства:

• cross-tenant запрос никогда не разрешается;
• отзыв роли монотонно уменьшает множество доступных отчётов;
• кеширование не меняет решение дольше допустимого окна;
• ретраи не создают дубликаты аудита;
• новая версия политики может объяснить отличие от старой.

Эти свойства подходят для property-based, differential и mutation testing. Можно прогнать старый и новый движок на записанном наборе обезличенных фактов и сравнить решения до переключения трафика.

Композиция: контракты между шагами

Архитектурная цепочка выглядит так:

HTTP request
  → Authentication
  → Tenant resolution
  → Fact loading
  → Policy decision point
  → Policy enforcement point
  → Report storage
  → Audit log

Локально корректные компоненты не гарантируют корректную композицию. Если authentication выдаёт глобальную роль, tenant resolution выбирает tenant из URL, а policy engine предполагает, что роль уже ограничена tenant, появляется уязвимость на стыке контрактов.

Категорная интуиция здесь практична: выход одного преобразования должен соответствовать входу следующего, композиция должна сохранять законы, а тождественное преобразование не должно менять смысл. Не обязательно писать термины Functor и Monad в business-коде, чтобы проверять композицию.

Одна и та же policy function размещается по-разному в зависимости от масштаба.

Модульный монолит

AccessPolicy находится в доменном модуле Reports. Application service загружает факты через репозитории и вызывает чистое решение. Это лучший старт, если нет независимого масштабирования и десятков систем-потребителей.

Плюсы: одна транзакционная граница, простая трассировка, быстрые тесты. Риск: контроллеры и ORM-запросы начинают обходить policy API. Архитектурный тест может запретить зависимость Web → Persistence минуя Application.

Hexagonal architecture

Домен знает AccessFacts и AccessDecision, но не знает HTTP, Entity Framework, Spring, Ecto или SQLAlchemy. Порты описывают получение фактов и аудит, адаптеры реализуют конкретную инфраструктуру.

Inbound adapter  →  OpenReport use case  →  AccessPolicy
                            ↓                    ↑
                    FactProvider port      pure domain
                            ↓
                    DB / IAM / cache adapters

Такую границу одинаково можно реализовать в ASP.NET Core, Spring Boot, FastAPI или Phoenix. Hexagonal architecture — не структура папок, а направление зависимостей.

Отдельный policy service

Когда много продуктов используют общие правила, появляется Policy Decision Point. Сервисы остаются Policy Enforcement Point: они запрашивают решение и обязаны применить его.

Новые проблемы:

• сетевой отказ и выбор fail-open/fail-closed;
• latency budget и пакетные решения для списков;
• версия политики и обратная совместимость;
• защита самого запроса к policy service;
• утечка чувствительных атрибутов;
• согласованность кеша и отзыв разрешений.

API должен возвращать не только allow, но и decisionId, policyVersion, безопасный reason code и срок действия решения. Полную трассу нельзя бездумно показывать клиенту: она может раскрыть устройство защиты.

Event-driven проекции

Для быстрого чтения сервис поддерживает локальную проекцию ролей и grants из событий RoleGranted, RoleRevoked, EmployeeBlocked. Это уменьшает сетевые вызовы, но решение принимается по потенциально устаревшему снимку.

Нужны идемпотентные handlers, позиция потока, метрика lag, процедура rebuild и правило поведения при превышении допустимой давности. Слово «eventual» без численного SLO ничего не объясняет.

CQRS и списки отчётов

Query side должен сразу фильтровать доступные отчёты, иначе приложение сначала выгрузит секретные строки, а затем скроет их в памяти. Command side повторно проверяет конкретный ресурс: видимость в списке не является capability на последующее действие.

Frontend

React или любой другой frontend может скрывать кнопку для удобства, но не является enforcement point. TypeScript-тип CanExport = true не защищает API. Клиент использует capabilities от backend для интерфейса, а сервер повторяет авторизацию на каждой операции.

Архитектура здесь продолжает историю логики: каждое новое распределение компонентов добавляет неявные посылки. Их нужно превращать в контракты, наблюдаемость и тестируемые свойства.

Для Atlas Reports полный инженерный маршрут выглядит так.

1. Создать decision record

Зафиксировать угрозы, бизнес-правила, владельца политики, допустимую рассогласованность, fail-open/fail-closed и критерии аудита. Отдельно выписать нецели: например, UI-видимость кнопки не является безопасностью.

2. Построить ubiquitous language

Определить Principal, Tenant, Report, Grant, Deny, Scope, AccessFacts, AccessDecision. Избегать универсальных UserType, PermissionData и IsAdmin, которые скрывают разные отношения.

3. Составить decision table

Проверить приоритет deny, границы tenant, истечение grants, блокировку, повторную аутентификацию и недоступность источника фактов. Согласовать таблицу с безопасностью и продуктом до реализации.

4. Выделить чистую политику

Функция принимает неизменяемый снимок фактов и возвращает объяснимое решение. Она не читает сеть, БД, часы или глобальную конфигурацию. В ООП это может быть доменный service со спецификациями; в ФП — композиция чистых функций.

5. Обернуть эффекты application service

Загрузить факты, проверить их свежесть, вызвать policy, применить решение и записать аудит. Таймаут, retry и circuit breaker относятся к оболочке, а не к логике allow/deny.

6. Построить пирамиду доказательств

• example tests проверяют строки decision table;
• property-based tests проверяют инварианты на множестве входов;
• mutation tests показывают, замечают ли тесты изменение && на ||;
• contract tests проверяют форму данных IAM и policy service;
• integration tests проверяют tenant-фильтрацию и транзакции;
• end-to-end tests проверяют критические пользовательские маршруты;
• differential tests сравнивают версии движка на реальных обезличенных фактах.

7. Сделать решение наблюдаемым

Логировать decisionId, версию политики, категорию причины, latency и свежесть фактов. Не логировать токены и лишние персональные данные. Метрики должны показывать рост deny, ошибки зависимостей, cache lag и расхождения shadow-mode.

8. Выпускать политику как код

Версионировать, ревьюить, прогонять corpus решений, включать новую версию в shadow mode, сравнивать результаты и только потом переключать enforcement. Rollback политики должен быть таким же понятным, как rollback приложения.

Главный результат не конкретный паттерн. Команда должна уметь ответить: почему решение принято, на каких фактах, какой закон сохраняется при рефакторинге и что произойдёт при отказе каждого внешнего компонента.

Проверьте, можете ли вы спроектировать политику без кода:

• восстановить скрытые посылки из product requirement;
• назвать доменные типы и недопустимые состояния;
• составить decision table и указать приоритет правил;
• отделить чистое решение от I/O и времени;
• выбрать объектную, функциональную или гибридную модель осознанно;
• описать TOCTOU, cache staleness и fail-open/fail-closed;
• сформулировать свойства для property-based и differential tests;
• объяснить, где находится enforcement point в frontend, backend и распределённой системе.

Если один из пунктов остаётся туманным, вернитесь не к языку, а к тому историческому повороту, который сделал соответствующую неопределённость явной.