Lexery Wiki

Lexery - Idea Evolution

3 хв читання

Lexery - Idea Evolution

Core Thesis

Lexery починалась не як “brain-first infra company”. Спочатку це був consumer-friendly AI legal assistant, але з часом центр ваги змістився до зовсім іншої задачі:

  • не просто відповідати,
  • а відповідати підконтрольно, доказово, масштабовано і багатоетапно в юридичному домені.

Phase A — Ukrainian Lawyer / Mike Ross

Product identity

  • Назва: Український Юрист - AI Правовий Консультант
  • Persona: Mike Ross
  • Promise: швидкі legal пояснення, чат, історія, договірний генератор.

Technical shape

  • React 18
  • TypeScript
  • Tailwind
  • Shadcn/ui
  • Supabase
  • Edge Function chat handler
  • OpenAI GPT-4

Strategic reading

  • Observed: тут продукт мислиться як accessible legal AI app.
  • Inferred: legal domain expertise ще подана радше як prompt discipline + curated law list, а не як full retrieval/runtime system.

Phase B — law-data seriousness

Shift

  • З’являється rada.gov.ua integration.
  • З’являються legal database management tasks.
  • З’являється Supreme Court RAG direction.
  • З’являється великий legislation stack.

Meaning

  • Inferred: команда/автор вперлась у реальну доменну проблему: простий chat UX не дає достатньої якості для legal use-case без серйозної data plane.

Phase C — Lexery Legal AI Agent as separate brain

Key conceptual leap

У bridge repo Lexery вже описується як:

  • окремий Brain service
  • control-plane-aware microservice
  • tenant-aware
  • plan-aware
  • evidence-first
  • bounded by staged runtime

New objects appear

  • Gateway
  • RunRecord
  • SearchPlan
  • QueryProfile
  • EvidencePack
  • RetrievalTrace
  • ContextPack
  • Memory Manager
  • DocListDB
  • LLDBI

Meaning

  • Observed: це вже не UI app with AI.
  • Observed: це system design for a legal cognition engine.
  • Inferred: саме тут Lexery стає окремою product philosophy, а не лише ребрендингом старого beta app.

Phase D — architecture becomes execution

Linear translation

  • Великі architecture docs дробляться на LEX-31 through LEX-59.
  • З’являється disciplined decomposition: concept, components, pipelines, failures, memory, billing, Azure, final docs.

Meaning

  • Observed: architectural thinking стає explicit roadmap.
  • Inferred: це момент, коли проєкт переходить із “дуже глибоко продуманого” в “можна реально будувати”.

Phase E — monorepo split: product shell vs legal brain

New current shape

  • apps/brain
  • apps/api
  • apps/portal
  • apps/lldbi
  • doclist services

New tension

  • apps/brain рухається до bounded legal agentivity.
  • origin/dev рухається до auth/workspace/plans/frontend integration.

Meaning

  • Observed: сучасний Lexery already consists of two rhythms: runtime/brain rhythm and product/control-plane rhythm.
  • Inferred: головний future challenge не придумати ще одну архітектуру, а звести ці дві реальності назад в один продукт.

What Stayed Constant Through All Phases

  • Ukrainian legal domain as the center.
  • Desire for trustworthy rather than purely creative output.
  • Strong role of official or structured legal sources.
  • Product ambition bigger than “one chat screen”.

What Changed The Most

  • from persona-first to architecture-first
  • from one-shot prompt answers to staged runtime
  • from public beta UX to private monorepo productization
  • from general “legal AI” to evidence / retrieval / multi-tenant / plan-aware legal system

Best One-Sentence Synthesis

Lexery еволюціонувала з AI-юриста для користувача в юридичний operating stack, де frontend, control plane, corpus infra і bounded legal brain мають зрештою скластися в один SaaS.

See Also

Вигляд графа

Зворотні посилання