El registro responde a una sola pregunta: ¿qué le queda pendiente a este ítem?
Reúne todas las tareas que exigen el propio ítem o cualquiera de sus tipos, y muestra el estado de cada una. Es la misma estructura que un checklist — cambia el nombre porque, cuando los tipos son una norma y la instancia es una empresa, el checklist es el registro de cumplimiento.

Un registro no es un documento que alguien rellena y mantiene al día. Se deriva, en cada lectura, de dos cosas: el ítem — una empresa, un proyecto, un producto — y sus tipos.
Un tipo es un ítem corriente al que otro ítem apunta diciendo esto se basa en aquello: una norma, una línea de producto, un proyecto anterior. Puede descomponerse en componentes, puede llevar tareas y eventos propios, y puede tener tipos a su vez. Al crear el enlace no se copia nada. Cada vez que se abre el registro, KF recorre el ítem junto con sus tipos y deduce qué exigen los tipos que el ítem no tiene.
Por eso un requisito añadido hoy a una norma aparece como hueco en todos los ítems que
la declaran, de inmediato — sin reemisión, sin migración, sin nada que mantener
sincronizado. Y por eso missing se calcula y nunca se almacena: es la diferencia entre
lo que exige un tipo y lo que la instancia tiene.
Todo lo que llega por esta vía queda marcado con el tipo del que viene — su origen —
y recibe un estado por herencia. not_applicable y resolved se heredan del tipo tal
cual; cualquier otro estado pasa a ser missing. El done de un tipo, deliberadamente,
no se hereda: dice que el trabajo se terminó para ese ítem y para nadie más. La
página de checklists explica por qué esos dos son la
excepción.
El registro es una tabla plana, y cada línea es un par: un ítem y una cosa que ese ítem debe. El ítem no siempre es aquel por el que usted preguntó — los componentes se aplanan en la misma tabla, tan hondo como llegue la estructura. Lo debido es una comprobación: una acción que realizar, o un objeto o un documento que entregar. Lo que convierte algo en comprobación es el enlace que lo pone ahí, no la clase de ítem que sea; no hay ninguna marca de "requisito" que nadie ponga.
De ahí salen dos clases de línea, y toda la diferencia está en si la línea lleva una comprobación.
Un encabezado no tiene estado alguno, y es deliberado. No está pending: nadie debe
nada en él, y un encabezado que informara de un estado inflaría todos los recuentos de
la página en el número de encabezados. En pantalla va en negrita y etiquetado; en las
exportaciones se marca en una columna propia, porque una hoja de cálculo se ordena y se
filtra, y un encabezado que parece un requisito con el estado en blanco es el camino más
rápido a un recuento equivocado.
| Ítem | Código | Comprobación | Estado | Por debajo | Origen | Tipo de fila |
|---|---|---|---|---|---|---|
| Bicicleta Modelo A | B-01 | Expediente de homologación | pending | 2/3, 1 missing | requirement | |
| Cuadro | R08 | Inspección de pintura | missing | Tipo cuadro | requirement | |
| R09 | Certificado de material | resolved | Tipo cuadro | requirement | ||
| Frenos | R21 | Reapretar los tornillos de la pinza ← Fatiga de freno | done | requirement | ||
| Ruedas y neumáticos | heading | |||||
| Batería (missing) | R33 | Informe de cualificación de celdas | missing | Tipo bicicleta | requirement |
Ruedas y neumáticos es un componente que no debe nada — un encabezado. Batería es un
componente que la bicicleta no tiene en absoluto: su tipo lo exige, así que tanto él
como todo lo que debe salen como missing. La tarea de reapriete llegó a través de un
evento, y el evento se muestra como procedencia sobre la celda, no como columna
propia — una tarea es una tarea medie o no un evento entre ella y su ítem; el evento
dice por qué se debe el trabajo, no quién lo debe.
El código es el número del requisito tal como se cita — R08. Cuando la
comprobación tiene código propio, el registro muestra ese antes que el del ítem que la
sostiene: el código de la comprobación es aquello por lo que se cita un requisito; el
del ítem solo dice dónde está colocado.
Las cinco significan algo distinto de lo que aparentan, y citarlas sin esa distinción es la forma habitual de que un registro induzca a error a quien lo lee.
| Estado | Lo que significa realmente |
|---|---|
done | Alguien lo marcó como hecho. No equivale a que el requisito esté cumplido: la evidencia todavía hay que leerla. |
resolved | Resuelto a nivel de tipo, en nombre de todas las instancias. Todo lo anidado por debajo queda oculto en las listas de instancia. |
not_applicable | Declarado no aplicable. Debería existir una justificación; pídala. |
missing | Heredado de un tipo y nadie lo ha asumido. No dice nada sobre si existe evidencia — a menudo existe, sin enlazar. |
pending | Alguien asumió su titularidad. No equivale a que el trabajo se haya hecho. |
missing se calcula, nunca se almacena. Es la diferencia entre lo que exige un tipo y
lo que la instancia tiene.
Cada fila lleva un recuento de lo que hay por debajo — 0/4, 2 missing. Una fila
puede estar marcada como done mientras quedan obligaciones abiertas debajo, y cuando
eso ocurre el registro sigue mostrando el recuento en lugar de ocultarlo. La
contradicción debe estar en la página, no detrás de ella.
Una tarea es una sola celda por mucho trabajo que contenga, y la celda nunca se parte, así que ese recuento es lo único que dice cuánto representa una línea. Por debajo de una tarea todo es trabajo — sus componentes, los componentes de éstos, sus subtareas y las tareas que traen sus eventos — y el número de la celda es exactamente lo que informa la página que hay detrás de la celda.
Un registro que no cuadra no es evidencia. Todo registro informa de su propia aritmética y de si se sostiene:
79 rows · 69 requirements · 10 headings · 29 beneath Reconciliation: 69 + 29 = 98 vs summary total 98 [reconciled]
La lista de filas y el resumen que la encabeza son dos recuentos del mismo recorrido, y cuentan de forma distinta: una tarea es una fila por mucho que esconda debajo, mientras que el resumen cuenta lo acumulado. Así que hay exactamente una relación que los ata —
los requisitos más todo lo acumulado por debajo = el total del resumen
— y el servidor la enuncia, la hace y muestra las dos cifras comparadas, coincidan o no. Un escueto no cuadra diría al lector que algo va mal y nada sobre qué.
Compruébelo antes de citar cualquier número del registro — sobre todo en un informe, donde el número sobrevivirá a la sesión que lo produjo. Si no cuadra, ninguno de los dos recuentos puede usarse como población hasta que la diferencia esté explicada.
El cuadre es una comprobación de coherencia, no una verificación. Dice que los dos recuentos de un mismo recorrido coinciden; no dice nada sobre si los estados que contienen son ciertos.
Por la API y el endpoint MCP la misma comprobación es un parámetro: reconcile=true
devuelve los recuentos con la aritmética ya hecha.
Cuatro cosas que se leen habitualmente en un registro y que el registro no dice.
1. No toda línea es un requisito. Cuente los requisitos, nunca las filas. Diez de
las 79 líneas de arriba son encabezados.
2. missing no es "no existe evidencia". Significa que nadie trazó el enlace. Busque
por materia antes de redactar un hueco: en una auditoría de referencia, 16 de 36 no
conformidades menores resultaron ser contenido que ya estaba en el sistema de calidad
y simplemente no estaba enlazado.
3. done no es conformidad, y pending no es avance. Uno es una etiqueta que
alguien puso; el otro significa que alguien asumió la titularidad y no se ha hecho
nada.
4. Una línea cerrada puede esconder un subárbol abierto. Lea la columna por
debajo: una celda done con cuatro obligaciones incumplidas por debajo no está
hecha en cuatro quintas partes.
Register CSV y Register XLSX exportan el conjunto completo, con una cabecera de
procedencia que nombra la base de datos, los recuentos de ítems, la última escritura,
la revisión de configuración, la hora de exportación y el resultado del cuadre. Las
filas llevan row_type, ítem, código, comprobación, estado, lo que hay por debajo y
el tipo de origen del que vino cada requisito.
La página, las dos exportaciones y la API salen de un único recorrido de la estructura, y es deliberado: un registro y su resumen se separan justamente cuando a uno de los dos se le da un recorrido propio.
La columna de origen es la que se suele infravalorar: dice qué norma, biblioteca o predecesor puso ahí esa obligación.
El registro pregunta: ¿tiene esta instancia lo que exigen sus tipos?
El checklist invertido hace la pregunta espejo: para cada tarea que tiene esta instancia, ¿está reflejada en alguno de sus tipos? Una lección que se queda en una sola instancia es una lección perdida — no llegará al siguiente proyecto.
