Вот подробный разбор, который подтверждает это мнение:

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

• "Mission-Critical Systems" и "авиационный уровень надежности": Это огромные, дорогие системы с многократным резервированием (например, авионика), написанные на строгих языках (Ada, SPARK).

• Применять этот термин к Lua-скрипту в QUIK'e, который работает в пользовательском процессе и даже не является надежным с точки зрения транзакций, — это или заблуждение, или намеренное преувеличение.

• Иерархический конечный автомат (HFSM): В своих модулях (MEO_Order_Stream, MEO_Pos_Stream) он описывает обычные линейные диаграммы состояний, где у ордера или позиции есть жизненный цикл.

• Иерархия же подразумевает вложенные состояния (state within a state).

• В его описании нет ничего иерархического — это просто плоский FSM.

• Event Sourcing (Хроника событий): Он использует этот термин, но подразумевает под ним обычную запись сделок в CSV-файл и пересчет позиции. Настоящий Event Sourcing — это архитектура, где состояние приложения полностью строится из событий, которые неизменяемы (immutable) и хранятся в специализированных стораджах (Event Store).

• Использование CSV-файлов для этого — нонсенс, это просто логирование.

• "Двойной ДНК-Маркер": Этот яркий, но бессмысленный с технической точки зрения термин скрывает за собой банальную идею использования двух цифр в trans_id в качестве префикса стратегии.

• Это распространенный, но крайне хрупкий и непрофессиональный способ маркировки для мультистратегической среды, который не выдерживает критики.

Это самый яркий признак недостаточного практического опыта.

• Спор о TRANS_ID: Его оппонент Nikolay абсолютно прав.

• TRANS_ID — это временный транзакционный идентификатор, который генерируется на стороне клиента для сопоставления ответа.

• Как только заявка (ордер) создана, ее постоянным и надежным ключом является биржевой номер (order_num).

• Упорно пытаться использовать TRANS_ID как первичный ключ для долгосрочного учета сделок — это фундаментальная архитектурная ошибка, которую допускают новички.

• Автор пытается выдать это за инновационный подход, игнорируя базовую документацию QUIK.

• Надежда на "сквозной" TRANS_ID: Он радуется, что биржа теперь не стирает TRANS_ID при клиринге, и считает это "современным стандартом".

• Но разработчики, знающие платформу, понимают, что полагаться на это поведение — крайне ненадежно.

• Это внутренний механизм, который может измениться с любым обновлением.

• Профессионал всегда строит систему на документированных и гарантированных API-методах (order_num, trade_num), а не на "побочном эффекте".

Его собственные посты полны внутренних противоречий:

• С одной стороны, он говорит о "потиковом On-line обучении", что является признаком очень сложного алгоритма.

• С другой стороны, в ответ на просьбу показать результаты он говорит, что идет "стадия 'Работы над ошибками'" и что-то делает на "фьючерсе серебра, формирует небольшую сетку".

• Это типичное описание простого сеточного мартингейла или усреднятора, а не высокоинтеллектуальной системы с цепями Маркова, о которых он говорит.

Его крик души: "Мне даже странно почему разработчики внедряя Луа, не предложили свои варианты OMS / PB" — выдает в нем человека, не понимающего экосистему.

Разработчики QUIK предоставляют инструменты (API, таблицы, события), а не готовые бизнес-решения.

Строить OMS/PB — это задача самого трейдера или его команды, которая требует высокой квалификации.

Он просит "базу для написания просто стратегий", не осознавая, что создание такой базы (фреймворка) и есть самая сложная часть работы.

Ваше впечатление абсолютно верно.

С высокой долей вероятности, перед вами человек, который:

1. Начитался умных статей и форумов о HFT, марковских цепях и распределенных системах.

2. Выучил оттуда множество терминов.

3. Пытается применить их к своему довольно простому Lua-скрипту в QUIK'e, чтобы казаться более экспертым, чем он есть на самом деле.

Отсутствие этих терминов в интернете в его трактовке ("Двойной ДНК-Маркер") — результат его собственного "творчества", а не открытия.

Его сопротивление практическим советам от Nikolay и стремление перевести разговор в плоскость "высоких архитектур" — классический признак того, что он не может ответить по существу на простые, прикладные вопросы.

Простой тест на профессионализм:

спросите его, что произойдет с его "ДНК-Маркером",

если биржа или брокер изменит логику генерации или валидации TRANS_ID на своем шлюзе.

Если он начнет говорить про "инвариантность" или "суверенный трекер" вместо конкретного плана действий, — сомнений не останется.