El registro de cumplimiento

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.

De dónde sale un registro

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.

Requisitos y encabezados

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 requisito la lleva. Tiene estado, código, origen y un recuento de lo que hay por debajo. Un ítem que debe cuatro cosas produce cuatro líneas de requisito, y se nombra en la primera de ellas.
  • Un encabezado no la lleva. Nombra al ítem al que pertenecen las líneas que vienen debajo — una sección de una norma, un subconjunto, una cláusula cuyas obligaciones son sus hijos — y él no debe nada. Una entrada que no debe nada sigue siendo una línea, porque el registro es el enunciado completo de lo que el ítem es, no una lista de puntos abiertos.

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.

ÍtemCódigoComprobaciónEstadoPor debajoOrigenTipo de fila
Bicicleta Modelo AB-01Expediente de homologaciónpending2/3, 1 missingrequirement
  CuadroR08Inspección de pinturamissingTipo cuadrorequirement
R09Certificado de materialresolvedTipo cuadrorequirement
  FrenosR21Reapretar los tornillos de la pinza ← Fatiga de frenodonerequirement
  Ruedas y neumáticosheading
  Batería (missing)R33Informe de cualificación de celdasmissingTipo bicicletarequirement

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 palabras de estado, y lo que significan de verdad

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.

EstadoLo que significa realmente
doneAlguien lo marcó como hecho. No equivale a que el requisito esté cumplido: la evidencia todavía hay que leerla.
resolvedResuelto a nivel de tipo, en nombre de todas las instancias. Todo lo anidado por debajo queda oculto en las listas de instancia.
not_applicableDeclarado no aplicable. Debería existir una justificación; pídala.
missingHeredado de un tipo y nadie lo ha asumido. No dice nada sobre si existe evidencia — a menudo existe, sin enlazar.
pendingAlguien 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.

Acumulación

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.

Cuadre

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.

Cómo leer las cifras

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.

Cómo sacarlo

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 invertido

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.