ADR-0009: M1 Product Vision — Investment Navigator

Status

accepted

Context

Module M1 до сих пор описывался как техническая абстракция — “Niche Evaluation Pipeline”. Это давало направление для архитектуры (DAG, агенты, fan-in), но не определяло конкретный продукт: что видит пользователь, какой output получает, чем это отличается от Perplexity или ChatGPT Deep Research.

Founder зафиксировал конкретное product vision: инвестиционный навигатор с веб-интерфейсом (Perplexity-style search bar), определёнными типами входов (текстовый запрос / URL компании / описание ниши) и структурированным выходом из 10 секций — от Market Overview до Executive Summary.

Техническая архитектура (CEO → Director → Scout → Researcher → Judge → Aggregate) уже реализована в MVP (Weeks 1-3). Нужно определить product layer поверх неё.

Decision

M1 переопределён как “Investment Navigator” — конкретный продукт с:

  • Входы: текстовый запрос / URL компании / описание ниши в свободной форме
  • Выход: структурированный отчёт из 11 секций (Market Overview, Competitive Landscape, Legal & Regulatory, Lean Canvas Snapshot, Financial Model, Investment Attractiveness, Roadmap, Resources Required, Visual Scorecards, Elevator Pitch, Executive Summary)
  • UX: Perplexity-style search bar → единый отчёт
  • Позиционирование: 80% качества консалтингового отчёта за минуты и центы

Техническая архитектура остаётся, добавляется product layer поверх неё.

Alternatives Considered

Option A: Оставить M1 как generic “Intel module”

  • Pros: Максимальная гибкость, подходит для любого use-case
  • Cons: Слишком абстрактно, не даёт direction для разработки. Непонятно что оптимизировать, как оценивать качество, что показывать пользователю
  • Not chosen: отсутствие конкретного product definition тормозит разработку

Option B: Сразу строить multi-module platform

  • Pros: Масштабируемо, единая платформа для M1/M2/M3
  • Cons: Преждевременно. Нет product-market fit даже на одном модуле. Распыление фокуса
  • Not chosen: сначала M1 должен работать как standalone product

Option C: Определить M1 как конкретный продукт с конкретным output ← chosen

  • Pros: Чёткий direction для разработки. Измеримое качество (10 секций — каждая оценивается). Конкретный UX. Понятное позиционирование vs конкуренты
  • Cons: Сужает scope M1. Структура 10 секций может не подходить для всех ниш
  • Why chosen: конкретность > гибкость на стадии MVP. Структуру можно адаптировать позже, но без неё нет product

Consequences

Positive:

  • Pipeline оптимизируется под конкретную структуру отчёта (10 секций), а не под generic research
  • Judge критерии привязываются к конкретным секциям — измеримое качество
  • UX определён — можно проектировать фронтенд (Week 5+)
  • Позиционирование ясно — можно тестировать с пользователями

Negative / Trade-offs:

  • Нужен веб-фронтенд (Week 5+) — дополнительная разработка
  • python_calc становится critical path (финансовые модели в отчёте)
  • Judge критерии нужно расширить под инвестиционный контекст (10 секций vs текущие 9+5 generic)
  • Структура 10 секций может быть избыточна для простых запросов

Mitigations:

  • Фронтенд — minimal viable: search bar + rendered markdown. Сложный UI позже
  • python_calc уже реализован (Week 3.3), нужно расширить формулы
  • Judge расширение — инкрементально, по мере появления реальных отчётов
  • Для простых запросов — CEO может выбрать direct_answer вместо полного pipeline

Follow-ups

  • Расширить Director decomposition под 10-секционную структуру
  • Добавить Legal & Regulatory research capabilities (новый Scout intent или агент)
  • Расширить python_calc формулами для Investment Attractiveness scoring
  • Расширить Judge критерии под 10 секций отчёта
  • Веб-фронтенд: minimal search bar + report viewer (Week 5+)
  • Тестирование product vision на 3+ реальных нишах

References