Cobertura histórica del corpus
Esta página documenta —con orgullo y sin letra pequeña— hasta dónde llega el corpus neutral de INAPI
y desde qué año es denso. La honestidad es parte del contrato: un consumidor merece saber "hasta cuándo"
son fiables los datos antes de construir sobre ellos. El corpus es neutral — cero campos ni referencias
cruzadas de RMC (impuesto por pnpm neutrality).
Las cifras de abajo se midieron contra producción el 2026-07-08 (snapshot). Son re-ejecutables con la auditoría de solo lectura en
scripts/data-quality-audit.sql. Total del corpus al momento del snapshot: 829.757 filas deinstancia.
La frontera de cobertura, en una frase
El corpus es denso desde ~2007-2009 en adelante y residual antes (1994-2006). Esto no es un hueco a tapar ni un defecto: es la forma real de la fuente pública de INAPI, y la documentamos tal cual para que nadie se lleve una sorpresa.
Densidad por año de presentación
| Tramo | Cobertura | Volumen típico por año |
|---|---|---|
| 1994-2006 | Residual | del orden de 1 / 3 / 6 / … 474 solicitudes/año (crece lento hacia el final del tramo) |
| ~2007-2009 | Comienza a densificarse | miles de solicitudes/año |
| 2010 → hoy | Denso | decenas de miles de solicitudes/año |
Lectura clave: la frontera ~2007 separa "el corpus está sustancialmente completo" de "hay cobertura residual". Un análisis que arranque antes de ~2007 verá pocas filas porque en la fuente hay pocas filas, no porque falte ingesta.
Cómo el contrato de lectura expone esta frontera
Desde la honestidad del contrato (CONTRACT-01), cada respuesta de insights deja de ser un array desnudo y se envuelve en un envelope con metadata de frescura:
{
"data": [ /* … las mismas filas de la agregación, intactas … */ ],
"dataAsOf": "2026-03-06T10:05:00.000Z",
"coverageThrough": "2026-03-05"
}
data— exactamente las filas que la agregación devolvía antes (mismas filas, mismo orden, mismos conteos). El envelope envuelve, nunca muta.dataAsOf— timestamp ISO del último sync exitoso: hasta cuándo corrió la ingesta.coverageThrough— la frontera enriquecida: la fecha de presentación más reciente entre las instancias ya enriquecidas (con clase/titular). Más allá de esa fecha viven los stubs frescos del Buscador, vistos pero aún sin enriquecer — reportar SU fecha más nueva sobreestimaría la cobertura.
Ambos campos se omiten (nunca aparecen como null) cuando no hay dato, de forma aditiva y
retrocompatible — misma convención que detail y similar. REST y MCP devuelven el mismo envelope por
construcción (una sola capa en la capa de consultas compartida), probado con un test de paridad deep-equal.
El scoring por histórico hereda la frontera
El segundo moat del producto —el scoring por histórico de decisiones— se apoya en la historia de resoluciones de INAPI. Por definición hereda esta misma frontera: un análisis histórico anterior a ~2007 tiene cobertura residual, y eso es lo esperado, no un hueco. Cuanto más reciente el periodo analizado, más densa la evidencia sobre la que se apoya el score. Esto se documenta aquí para que la lectura de un score histórico se interprete con el contexto correcto de cobertura.
Notas de calidad relacionadas
- La brecha de
estado(~29,7k filas sin estado, ≈3,6% al 2026-07-11 — bajó desde ≈15,2% tras el fix de catálogo de estado que mapeó las etiquetas INAPI faltantes) es una cola larga repartida por todos los años, no un agujero de un año/fuente concreto — verSCHEMA-MAPPING.md(referencia interna de ingeniería). Se corrige por el barrido diario autoritativo de Sheets, no por re-barrer el Buscador. - La serie de numeración "99x" (~20.315 filas, mayoritariamente marcas extranjeras) es legítima — consistente con registros internacionales / Protocolo de Madrid hacia Chile— y se trata igual que la serie normal a efectos de lectura.
En resumen: el corpus es honesto sobre su propia frontera. Denso desde ~2007, residual antes, y cada respuesta de insights lo dice en voz alta vía
coverageThroughydataAsOf.