Назначение
Это Reference Case. Он демонстрирует модель, а не расширяет её. Каждое понятие здесь определено нормативно в Core Vocabulary или на уровне Models спецификации и лишь упоминается в этом документе.
Внедрения, стоящие за этим кейсом, реальные и проводились под NDA; организация, имена и детали изменены. «Meridian» — это условное обозначение любого оператора перформанс-маркетинга, используемое исключительно для иллюстрации. Ни одна реальная компания, ни один бренд или человек не названы и не подразумеваются. Чего стоит это утверждение, записано в Evidence Register: это заявление владельца, нижний из четырёх уровней доказательности, публично не проверяемое.
Организация до OCOM
Meridian — цифровой оператор перформанс-маркетинга. Он берёт офферы у рекламодателей, перепродаёт их трафик-партнёрам на своих условиях, отслеживает приходящие конверсии и рассчитывает выплаты с обеих сторон.
В начале всё работало на четырёх несвязанных системах, и именно поэтому был внедрён OCOM.
| Система | Что там жило |
|---|---|
| Мессенджер | переписка с партнёрами, ключ — хэндл чата |
| CRM | имена контактов и платёжные почты |
| Трекер | числовые affiliate ID, клики, конверсии |
| Финансы | выплаты, вбитые в таблицу вручную |
Один и тот же партнёр существовал как четыре разные вещи, и ни одна система не была авторитетной. Свести одну выплату означало, что человек угадывает, что хэндл чата, почта, affiliate ID и строка в таблице — это один и тот же партнёр. Каждый отчёт был спором о том, чья копия верна.
Цель внедрения была не «внедрить модель данных». Она была такой: один управляемый источник, который человек, трекер, API и ИИ-ассистент читают одинаково.
Как внедрялся OCOM
Внедрение шло по логике собственных принципов модели: Evidence Before Belief (сначала свидетельство, потом утверждение) и управляемость, заложенная с самого начала. На практике это и задало порядок. Нельзя управлять тем, что нельзя идентифицировать, и нельзя доверять тому, что нельзя подтвердить, поэтому Identity и события шли первыми, а коммерческий слой только после них.
Сначала Identity
Проблема. Ничего нельзя было свести, потому что ни у чего не было единого имени.
Что применили. Самым первым понятием OCOM ввели Identity. Каждому партнёру, рекламодателю и офферу дали один канонический идентификатор (партнёр стал PRT-00417), а четыре системных имени превратились в алиасы, которые к нему резолвятся.
Решение, которое всё определило. Резолвинг сделали детерминированным и основанным на свидетельстве, никогда не автоматическим. Новый алиас привязывается к существующей Identity только по свидетельству. Когда уверенного совпадения нет, система не придумывает слияние и не создаёт молча дубликат: она выносит неоднозначность человеку. Именно это правило не пустило старый хаос обратно через новую модель.
Результат. Впервые партнёр стал одной вещью. История чата, ID в трекере и строка выплаты теперь висели на одном объекте.
События и свидетельство, а не текущее состояние
Проблема. Старые системы хранили только последнее значение. Никто не мог ответить, почему баланс или статус именно такой.
Что применили. Meridian начал записывать события как неизменяемую операционную историю: партнёр зарегистрирован, сделка подписана, конверсия подтверждена, выплата проведена. Коммуникации фиксировались с полным конвертом (кто, когда, по какому каналу) как свидетельство, привязанное к Identity из Фазы 1.
Решение, которое всё определило. Ничего нельзя утверждать без события за спиной. Это Evidence Before Belief в буквальном виде: утверждение о бизнесе должно резолвиться в записанное свидетельство, иначе оно не делается.
Результат. Состояние стало объяснимым. «Этот партнёр одобрен» теперь резолвится в событие, которое его одобрило.
Один вычисляемый источник истины
Проблема. Финансовая таблица хранила балансы напрямую, поэтому две копии всегда расходились.
Что применили. Единый управляемый журнал денежных событий стал источником истины. Баланс никогда не хранился, всегда вычислялся из событий. Это было проектное решение данного оператора; спецификация не предписывает, как хранятся события и хранятся ли они вообще.
Решение, которое всё определило. Производное число никогда не записывается обратно как факт. Это проекция событий, поэтому оно не может разойтись с ними. Это принцип Immutable Memory из Конституции (память только дописывается; исправления оформляются новыми записями), применённый к деньгам.
Результат. У партнёра был ровно один баланс, и он всегда совпадал с собственной историей.
Реестры
Проблема. Два человека могли создать двух «одинаковых» партнёров, и часто создавали.
Что применили. Коллекции стали управляемыми реестрами (Registry): реестр партнёров, каталог офферов, реестр рекламодателей. У каждого есть правила членства и уникальности, а не просто строки.
Результат. Онбординг партнёра или оффера пошёл через управляемое членство. Дубликаты останавливались на входе, а не вычищались потом.
Коммерческий слой (Contract, Policy, Constraint)
Проблема. Условия сделок жили в головах людей и в сообщениях чата.
Что применили. Сделки стали объектами Contract, связывающими партнёра и оффер явными условиями (модель, ставка, гео, кап, срок оплаты). Правила, которым сделка обязана следовать, стали политиками (Policy) (KYC до первой выплаты, оплата после подтверждения). Жёсткие пределы, которые нельзя пересекать, стали ограничениями (Constraint) (выплата_партнёру <= ставка_рекламодателя, дневной кап).
Решение, которое всё определило. Сделка, нарушающая Constraint, не может быть активирована. Управляемость обеспечена на самом объекте, а не оставлена на память проверяющего.
Результат. Коммерческие условия стали проверяемыми и машиночитаемыми вместо «племенного знания».
Ownership на роль
Проблема. Когда сотрудник уходил, партнёры, которых он вёл, оставались без ответа.
Что применили. Ownership каждого партнёра и сделки назначили на роль, а не на человека.
Результат. Ответственность пережила смену кадров. У каждого объекта был чёткий текущий владелец.
Заморозка ядра
Проблема. Когда всё заработало, возник соблазн добавлять новый концепт под каждый частный случай.
Что применили. Core заморозили. Новые концепты перестали добавлять напрямую. Кандидат теперь должен быть замечен в реальном использовании, оформлен как Reference Case и пройти рассмотрение как Architecture Observation, прежде чем что-то поменяется. Это управляемость, заложенная с самого начала, применённая к самой модели.
Результат. Модель осталась маленькой. Весь бизнес по-прежнему помещается в тринадцать терминов Core Vocabulary и уровень Models, что и есть смысл этого документа.
Всё остальное — проекция
Проблема. Каждая старая система держала свою копию, а копии расходятся.
Что применили. Внутренние административные экраны, JSON API, граф знаний и контекст ИИ-ассистента пересобрали как проекции одних и тех же управляемых объектов, а не как параллельные хранилища.
Результат. Человек и ИИ-ассистент, читая партнёра, читают одну запись. Второй копии, которой можно разойтись, нет.
Чему учит эта последовательность
Порядок был не случайным, и это самая переносимая часть кейса.
- Identity — краеугольный камень. Пока у вещей нет одной канонической идентичности, ничему ниже по цепочке нельзя доверять. Он должен быть первым.
- Детерминированный резолвинг лучше «умного». Отказ авто-сливать по слабому свидетельству — это то, что держит модель чистой со временем.
- Сначала свидетельство, потом состояние. Записывай события, вычисляй текущий вид. Никогда не храни вывод, который не можешь пересчитать заново.
- Управляй моделью в последнюю очередь и жёстко. Заморозь ядро, когда оно заработало, чтобы оно осталось маленьким.
Команда, внедряющая OCOM, может взять эту последовательность напрямую: Identity, затем события, затем вычисляемый источник истины, затем реестры, затем коммерческий и управляющий слои, затем проекции. Эта последовательность задаёт порядок, а не список того, что нужно построить: ни одна из фаз, ни выбор хранения, ни проекции не являются требованием спецификации.
Приложение: результат одним взглядом
После внедрения у каждого из 13 терминов Core Vocabulary есть конкретный аналог в бизнесе. Lifecycle, State и Domain, определённые на уровне Models, в этой таблице не отображены.
| Концепт OCOM | Чем является у оператора | Конкретный пример |
|---|---|---|
| Object | любая управляемая единица бизнеса | партнёр, оффер, сделка, инвойс |
| Identity | единый канонический ключ, который вещь держит во всех системах | PRT-00417 за хэндлом чата, почтой и ID в трекере |
| Metadata | описательные и управляющие атрибуты | гео, вертикаль, дневной кап, статус оффера |
| Relationship | управляемая связь, несущая бизнес-смысл | «партнёр продвигает оффер» |
| Reference | направленный указатель, легче Relationship | конверсия указывает на оффер, который её породил |
| Registry | управляемая коллекция с правилами членства | реестр партнёров, каталог офферов |
| Classification | категории, присвоенные объекту | вертикаль оффера = finance; тир партнёра = A |
| Capability | управляемая способность, которую объект предоставляет | партнёр даёт мобильный app-install трафик в Tier-1 EU |
| Contract | управляемое соглашение между объектами | выплатная сделка: CPA 180, гео DE, NET-30 |
| Policy | управляемые правила для объектов | «KYC до первой выплаты» |
| Constraint | конкретное ограничивающее условие | выплата_партнёру <= ставка_рекламодателя |
| Ownership | назначенная ответственность | роль аккаунт-менеджмента владеет партнёром |
| Organization | независимый участник, сам являющийся объектом | компания-партнёр, рекламодатель, сам Meridian |