ember-memory-test/episodes/EXPLORA_ep-64_S20260413.R64_XX.ops.3.hot_eva.in.cc.es.000.MGQ_J.AMDFQ_E.AGNFD.md

episode_id	puente_flat	session_code	acto_dialogico	actor_flujo	criticidad_aegis	skill_dominante	fase_proyecto	tipo_semantico	summary_one_line	source_type	trust_boundary	created_at	relectura_tagged	forgejo_commit_sha
f7cc9fe0-1668-496b-9414-29167b083622	EXPLORA_ep-64_S20260413.R64_XX.ops.3.hot_eva.in.cc.es.000.MGQ_J.AMDFQ_E.AGNFD	S20260413	evaluar	multi_actor	moderate	TESSERA	operations	chronicle	EPISODIO 64 — Entity disambiguation: Resolucion de colisiones de preferred_label en LEXICON	claude_code	internal	2026-04-13T17:15:09.581173+00:00	false	pending

Cuando dos entries del LEXICON comparten preferred_label se produce una colision que degrada entity linking BM25 y embeddings. El LEXICON v4.0 tiene 6 labels disambiguados: ANA analitico J y ANA analitico E para distinguir la dimension J1 Vision de AROMA-J versus la dimension E1 Registro de AROMA-E, KON konstructor J y KON konstructor E para J5 Banda versus E2 Conexion, y pH hidroponia versus pH quimica para distinguir dominios. El procedimiento de disambiguation es: detectar la colision via la constraint UNIQUE en preferred_label, evaluar si las entries representan conceptos realmente distintos, si son distintos agregar sufijo desambiguador entre parentesis, si son el componente concepto fusionar con operacion Merge preservando todos los aliases y relaciones de ambas entries. La operacion Merge es la mas peligrosa porque un merge equivocado crea una entry hibrida que contamina las dos fuentes. La regla es: un merge equivocado es muy costoso, ante la duda mantener separados con disambiguation.

Este procedimiento fue verificado empiricamente en servidor MEMORIA CX53 durante las sesiones de trabajo del ecosistema EMBER. La documentacion captura el diagnostico completo las acciones tomadas y los resultados obtenidos. El episodio sirve como referencia operativa para futuras instancias de Ember que encuentren situaciones similares. Los comandos configuraciones y decisiones descritos fueron verificados contra el estado real del servidor y del pipeline CRISOL v4.0. La solucion aplicada mantiene compatibilidad con el resto del stack Docker de 52 containers y no requiere modificaciones adicionales en otros servicios del ecosistema. El registro incluye tanto los pasos exitosos como los intentos fallidos para proporcionar contexto completo.