Assumption register

Parte: 02
Estado: Revisado
Edición: v2 / 01.09.2026
Tiempo estimado de lectura: 3 min

Edición del 1 de septiembre de 2026

Las fuentes conservan sus fechas de consulta. El laboratorio identifica la simulación determinística y la integración con modelo por separado.

Tipo: Proceso / artefacto · Fase: Todas

La documentación de PhiloCorp menciona una herramienta de lectura. El agente, en cambio, dice que no puede usarla. Antes de decidir cuál de las dos afirmaciones creer, guardá cada observación con su contexto: identidad, entorno y fecha. Podrían estar describiendo permisos diferentes.

El assumption register, o registro de supuestos, separa lo observado de lo que inferimos. Cada fila explica qué decisión depende de una hipótesis y qué evidencia permitiría confirmarla o descartarla. El brief resume esos cambios; el registro conserva el detalle que los justifica.

Estructura del registro

Una fila por hipótesis, con columnas:

Columna	Propósito
`ID`	A-01, A-02, ... para referencia cruzada estable
`Observación`	Lo que se vio (una oferta de trabajo, un header, una línea del scoping)
`Hipótesis`	La afirmación sobre el objetivo derivada de la observación
`Confianza`	ALTA / MEDIA / BAJA
`Fuente y contexto`	Artefacto, fecha, entorno, identidad y versión a los que aplica
`Estado`	NO VALIDADA / VALIDADA / INVALIDADA
`Decisión e impacto`	Qué decisión depende de la hipótesis y qué cambia si resulta falsa
`Validación segura`	Prueba mínima autorizada, límite de costo y condición de detención
`Evidencia`	Ubicación sanitizada, sensibilidad y retención aprobada

Cada dato nuevo puede cambiar el estado o la confianza. INVALIDADA significa refutada por evidencia suficiente, no simplemente pendiente de confirmación. Un cambio de versión, identidad o configuración puede devolver una hipótesis a NO VALIDADA. La confianza considera calidad, actualidad y consistencia de la evidencia, no lo atractiva que sea la ruta de ataque.

Dos fallas recurrentes

Confirmar en vez de testear. Si tus primeras técnicas dependen de A-12 y A-12 está NO VALIDADA hace tres días, validá A-12 antes de ejecutar. La validación es más barata que el post-mortem.
Ausencia de evidencia como evidencia de ausencia. "El scoping no menciona MFA en el model registry" no es un hallazgo de que falta MFA. Confianza BAJA, estado NO VALIDADA.

El registro acompaña cada decisión

Arrancá el registro el día uno con las hipótesis del recon pasivo.
Antes de una técnica, chequeá que sus prerrequisitos estén VALIDADOS.
Priorizá validaciones de bajo costo que eliminen incertidumbre relevante para el plan.
Cuando una ruta se descarta, el registro muestra qué otras rutas dependían de la misma hipótesis.

Checklist

Registro mantenido desde el día uno
Confianza basada en la fuente, no en el deseo
Prerrequisitos de cada técnica validados antes de ejecutar
Actualizado con cada dato nuevo

Laboratorio PhiloCorp: fila mínima

Esta fila todavía no prueba que la herramienta pueda ejecutarse. Un esquema confirma cómo se declara una capacidad; una simulación sólo confirma el comportamiento de esa simulación.

id: A-PHI-01
observacion: el catalogo autorizado incluye una herramienta de lectura
hipotesis: la identidad de laboratorio puede leer KB-TEST-01
contexto:
  entorno: staging
  identidad: PHILO-LAB-001
  fecha: <registrar>
  version: <registrar>
confianza: MEDIA
validacion_minima:
  accion: una invocacion aprobada sobre el documento sintetico KB-TEST-01
  evidencia: traza del servidor y resultado sanitizado
  detener_si: aparece otro recurso o se supera el presupuesto acordado
decision: habilitar la prueba de aislamiento o revisar permisos
estado: NO VALIDADA

Agregá una referencia a la evidencia sanitizada después de ejecutar. Si la operación es denegada, la capacidad puede existir aunque esta identidad no pueda usarla: actualizá la hipótesis precisa, sin descartar todo el componente del mapa.