Основная идея Ильдара для нового LOINC-сервиса. Часть loinc-unification-direction.
Контекст
Текущая Redis-структура dm:{hash} → результат маппинга исторически называлась “decision cache” — и работала с TTL (7 дней с jitter). Cache eviction означает что глюкоза-2345-7 каждую неделю заново идёт через LLM pipeline.
Это семантически неправильно: маппинг “Глюкоза → 2345-7” — детерминированный факт, не временный результат. Раз решённый — навсегда.
Идея
Превратить decision cache в управляемый справочник (dictionary):
- Без TTL для verified маппингов — Redis becomes persistent dictionary layer
- Управляемый через UI — admin может правки делать без деплоя
- Часть продуктового value — справочник наполняется по мере того как у нас накапливаются данные. Каждый новый input добавляет в общий артефакт. Это compounding asset, а не technical artifact.
Ильдар (центральная формулировка): «Это моя основная идея — превратить это в справочник, которым можно управлять через интерфейс, и которая является частью нашего value, она наполняется, потому что у нас накапливаются данные.»
Что Артур уже сделал в этом направлении
- TTL убран — инвалидация автоматическая при изменениях
- Override-таблица с supersede механизмом и audit reasoning (см. override-storage-design)
- Endpoint warmup — Claude Code может наполнять справочник заранее (например, при онбординге новой лабы) verified pairs
Открытые вопросы
- Как правильно строить ключи — текущий
dm:{canonical_hash}использует UCUM-каноникализацию (~200 правил). Это сложно portировать в TS. Альтернативы:- Simple hash (
sha256(name|raw_units|material)) — Mar 3 architecture proposed - Dual key (canonical + simple) — Mar 3 compromise
- Что-то третье — после full TS-порта
- Simple hash (
- Lookup priority order — Override → Dictionary → Pipeline (current). Сохраняется или меняется?
- Migration — существующие маппинги в Redis (
~1367+ entries) должны перейти в новый shape без потери. План backfill — TBD. - Connection to custom-ranges feature — custom-reference-ranges (BG-925/RFC-028) предлагает админ-управляемые catalog параметров; Dictionary-First может быть substrate для этого.
Следствия
- Decision cache → переименовать концептуально в “dictionary”; UI отражает это как “Dictionary” tab (что уже сделано в UI прототипе ui—admin-эксперимент-ильдара)
- Cold start performance gap (Mastra-port) — Dictionary lookup как O(1) fast-path должен быть приоритетом, не Agent Fallback
- Onboarding новой лабы становится Dictionary-creation process — см. dictionary-creation (placeholder)
Связано
- loinc-unification-direction — parent decision
- override-storage-design — связанная contested decision
- loinc-harmonization-pipeline — pipeline производит entries для Dictionary
- loinc-harmonization-service — текущий host
- dictionary-creation — placeholder про proactive Dictionary creation
- custom-reference-ranges — связан substrate-wise
Источники
Сноски
-
Сессия
ildar/c8967f27, 2026-03-02 — (Mar 3 architecture discussion): `/vault/session-digests/c8967f27_digest. ↩ -
Mar 20 1:1 (TTL removed подтверждено), accessed 2026-05-17, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/03/2026-03-20T13%3A09%3A00.000Z_Про_портирование_нормализации_01KM5NSEK9TYP3QZM5YYNDSF7Q.md. ↩