Captura
Guardar metadatos del run y una representación auditable de la respuesta.
Documentación técnica K-AIVS
Especificación técnica pública del Kursery AI Visibility Score.
Modelo de datos, pipeline de medición, normalización, Confidence Score, versionado y reglas de auditoría para implementar K-AIVS V1.0.
Especificación técnica V1.0 · 1 de octubre de 2026
Alcance
Cómo convertir K-AIVS en un sistema auditable.
Esta especificación describe la estructura mínima de datos necesaria para ejecutar el Kursery AI Visibility Score de forma repetible. No documenta secretos de modelos externos ni afirma acceso a señales internas de plataformas. Su propósito es registrar lo observable con suficiente precisión para reconstruir una medición después.
La regla principal es sencilla: ningún score debe existir sin poder bajar hasta la evidencia que lo produjo.
Documento relacionado
La definición metodológica vive en la página canónica de K-AIVS.
La fórmula, las siete dimensiones, Confidence Score, Prompt Universe, versionado y limitaciones metodológicas se documentan en la página principal. Este documento se concentra en implementación y trazabilidad.
Volver a K-AIVSModelo de datos
Objetos mínimos de la implementación.
| Objeto | Función | Campos clave |
|---|---|---|
| ai_engines | Catálogo de experiencias o motores medidos. | engine_id, name, provider, status |
| ai_models | Modelo o versión observable cuando puede identificarse. | model_id, engine_id, label, observed_from, observed_to |
| ai_prompt_sets | Conjunto versionado de prompts. | prompt_set_id, version, locale, purpose |
| ai_prompts | Pregunta individual y sus metadatos. | prompt_id, topic_id, family, branded_flag, intent_type, weight |
| ai_scans | Ejecución completa de un benchmark. | scan_id, entity_id, prompt_set_id, started_at, completed_at |
| ai_runs | Una observación puntual. | run_id, scan_id, prompt_id, engine_id, model_id, locale, observed_at |
| ai_responses | Snapshot o referencia de la respuesta observada. | response_id, run_id, raw_text_hash, snapshot_ref |
| ai_mentions | Entidades detectadas dentro de una respuesta. | run_id, entity_id, present_flag, prominence_score |
| ai_citations | Fuentes visibles asociadas a una ejecución. | run_id, source_url, source_domain, owned_flag |
| ai_associations | Relaciones observadas entre entidad y topic. | run_id, entity_id, topic_id, association_score |
| ai_accuracy_checks | Validación contra facts canónicos. | run_id, fact_id, status, reviewer |
| ai_visibility_scores | Resultado agregado y versionado. | entity_id, topic_id, period, kaivs_version, score, confidence |
Registro de un run
Una observación debe poder reconstruirse.
run_id · entity_id · topic_id · prompt_id · engine_id · model_id · language · locale · observed_at · repetition · context_mode
Además del identificador del prompt, conviene conservar su versión y el contexto usado durante la ejecución. Los benchmarks deben ejecutarse en contextos comparables; una conversación previa que ya mencione a la entidad puede contaminar la medición y elevar artificialmente la visibilidad branded.
Pipeline
De respuesta observada a score.
Extracción
Detectar menciones, URLs, fuentes, entidades y relaciones relevantes.
Clasificación
Asignar prominence, asociación, exactitud y contexto de recomendación.
Normalización
Convertir cada dimensión a una escala comparable de 0 a 100.
Agregación
Aplicar pesos de la versión vigente y calcular K-AIVS sin ocultar componentes.
QA
Revisar muestras, inconsistencias, runs fallidos y cambios metodológicos.
Normalización
Cada componente debe conservar su denominador.
Presence, Citation o Recommendation no pueden calcularse sobre universos ambiguos. Cada componente debe registrar cuántas oportunidades eran elegibles, cuántas se observaron y qué peso tuvo cada prompt. Recommendation, por ejemplo, no debe penalizar una respuesta puramente definicional donde ninguna recomendación tenía sentido.
La normalización también debe separar branded y unbranded, además de intención informacional, autoridad, comparación y comercial. El score global puede agregarlas; el diagnóstico nunca debe esconderlas.
Confidence Score
La calidad de la evidencia se calcula por separado.
| Factor | Qué evalúa |
|---|---|
| Cobertura de prompts | Qué proporción del Prompt Universe pudo ejecutarse correctamente. |
| Repetición | Si existen suficientes runs para estimar variabilidad. |
| Diversidad de motores | Si la lectura depende de una sola experiencia. |
| Profundidad temporal | Si existe historia suficiente para hablar de estabilidad. |
| Completitud | Si respuesta, citas y clasificaciones necesarias quedaron registradas. |
| Control de calidad | Qué proporción fue revisada o contrastada mediante reglas de QA. |
Versionado y auditoría
La historia no se sobrescribe.
Cada cálculo debe registrar kaivs_version, versión del Prompt Universe, pesos, reglas de clasificación y fecha de cálculo. Si V1.1 modifica un peso o una regla, el resultado anterior permanece asociado a V1.0. La comparabilidad histórica sólo debe afirmarse cuando ambas versiones sean compatibles o cuando exista una reconstrucción documentada.
Privacidad
AI Visibility no necesita PII para medir una entidad pública.
La capa de AI Visibility trabaja principalmente con entidades, prompts, motores, contenido, fuentes y respuestas. La información de personas identificadas sólo entra cuando se conecta posteriormente con first-party data y atribución dentro de Kursery Intelligence, bajo reglas separadas de consentimiento y privacidad.
Límites
La implementación registra lo observable.
No se deben guardar ni inferir variables supuestamente internas de modelos externos. Tampoco deben inventarse posiciones, probabilidades o causas que la plataforma no exponga. Cuando un dato no puede observarse, se registra como desconocido.
La especificación técnica existe para que el score pueda auditarse.
Vuelve a la metodología pública K-AIVS para revisar definición, dimensiones, pesos y limitaciones.
Volver a K-AIVS