diff --git a/docs/F7_SIMPLE_INVENTORY_MODEL.md b/docs/F7_SIMPLE_INVENTORY_MODEL.md
new file mode 100644
index 0000000..2bb0cb3
--- /dev/null
+++ b/docs/F7_SIMPLE_INVENTORY_MODEL.md
@@ -0,0 +1,136 @@
+# F7 · Modelo simple de Inventarios
+
+Este documento fija el nuevo eje funcional de Inventarios para DH Inspección V2. Su objetivo es reducir la complejidad visible y orientar toda la experiencia al trabajo real de inspección.
+
+## 1. Jerarquía
+
+La estructura física es única:
+
+**Departamento → Área → Yacimiento → Instalación → Subinstalación**
+
+- Departamento y Área organizan el territorio.
+- Yacimiento, Instalación y Subinstalación son niveles válidos para registrar Hallazgos.
+- Una Instalación pertenece a un Yacimiento.
+- Una Subinstalación pertenece a una Instalación.
+
+## 2. Empresas
+
+- Un Área puede estar explotada por varias Empresas al mismo tiempo.
+- Cada Yacimiento tiene una sola Empresa operadora vigente.
+- La Empresa del Yacimiento se elige entre las Empresas vinculadas al Área.
+- Instalaciones y Subinstalaciones heredan el contexto de Empresa desde su Yacimiento.
+- Cambiar la Empresa de un Yacimiento no mueve ni recrea su Inventario físico.
+
+## 3. Datos simples
+
+Todos los registros usan una base común reducida:
+
+- Nombre.
+- Código, opcional y autogenerable.
+- Ubicación jerárquica.
+- Estado.
+- GPS cuando corresponda.
+- Observaciones sólo cuando aporten valor.
+
+Departamento, Área y Yacimiento no necesitan un constructor técnico complejo.
+
+Instalaciones y Subinstalaciones pueden tener campos específicos configurados por el Superadmin técnico.
+
+Los tipos de campo visibles para la puesta a punto deben mantenerse simples:
+
+- Texto.
+- Número.
+- Fecha.
+- Sí / No.
+
+Teléfono, email o identificadores simples pueden resolverse como Texto. GPS es un dato básico del registro, no un atributo técnico configurable.
+
+## 4. Administración de tipos
+
+Sólo el Superadmin técnico modifica la configuración.
+
+La pantalla administrativa debe permitir únicamente:
+
+1. Crear/ocultar Tipos de Instalación.
+2. Crear/ocultar Tipos de Subinstalación.
+3. Definir qué Tipos de Subinstalación puede contener cada Tipo de Instalación.
+4. Agregar, mostrar/ocultar y marcar como obligatorios los campos simples de cada tipo.
+
+Los términos técnicos internos como `inventory_families`, reglas de compatibilidad o schemas no deben exponerse al usuario.
+
+## 5. Cambio de tipo / función
+
+La identidad física del elemento no cambia cuando cambia su función.
+
+Ejemplo: `TK-57` sigue siendo `TK-57`, aunque hoy funcione como tanque de petróleo y mañana como tanque de agua.
+
+El cambio debe registrarse cronológicamente con:
+
+- tipo / función anterior;
+- tipo / función nueva;
+- fecha efectiva;
+- observación opcional.
+
+No se crea un Inventario nuevo para representar un cambio de función.
+
+## 6. Cronología útil
+
+Para Yacimiento, Instalación y Subinstalación la cronología debe concentrar sólo hechos operativos relevantes:
+
+- Hallazgos.
+- Acta asociada.
+- Empresa operadora correspondiente a la fecha.
+- Cambio de tipo / función.
+- Cambio de ubicación cuando corresponda.
+- Alta e inactivación.
+
+La experiencia normal no debe obligar a navegar por procedencia, snapshots, registros técnicos o paneles administrativos separados.
+
+## 7. Filosofía de la APK
+
+La APK existe para **inspeccionar, generar Acta y generar Informe**.
+
+El Inspector no administra Inventarios como tarea separada.
+
+La mayoría de las altas reales ocurren en campo mientras se registra un Hallazgo.
+
+Flujo:
+
+1. La Inspección se planifica desde WEB y ya conoce el Yacimiento.
+2. El Inspector abre la Inspección al llegar.
+3. Pulsa `+ Crear hallazgo`.
+4. Decide si el Hallazgo corresponde a Yacimiento, Instalación o Subinstalación.
+5. Si la Instalación no existe, puede crearla rápidamente sin abandonar el flujo.
+6. Si necesita una Subinstalación que no existe, puede crearla rápidamente dentro de la Instalación seleccionada.
+7. El catálogo ayuda, pero `OTRO` siempre está disponible.
+8. Con el tiempo, el Inventario se completa naturalmente y disminuye la necesidad de altas nuevas.
+
+## 8. Planificación y recorrido
+
+La planificación WEB define:
+
+- Área.
+- Empresa.
+- Yacimiento.
+- Inspector.
+- Fecha/hora.
+- Instalaciones/Subinstalaciones elegidas preventivamente.
+- pendientes por vencer, mostrados por elemento a controlar.
+- pendientes vencidos, mostrados por elemento a controlar.
+
+La APK presenta ese conjunto como recorrido sugerido. No es una ruta rígida: el Inspector puede registrar Hallazgos nuevos en cualquier momento.
+
+## 9. Actas e Informes
+
+- Abrir una Inspección no crea automáticamente un Acta.
+- El Inspector pulsa `+ Nueva Acta` cuando empieza a documentar.
+- El número definitivo del Acta se genera al cerrarla.
+- Una Inspección puede tener varias Actas.
+- Al cerrar un Acta se pueden agregar uno o más acompañantes con Nombre + Email.
+- El Acta se envía a Empresa, Inspector y acompañantes.
+- El Informe se genera automáticamente en Word y se envía únicamente al Inspector que realizó el Acta.
+- La firma o validación legal definitiva queda para una etapa posterior; la prioridad actual es la usabilidad.
+
+## 10. Regla de diseño
+
+Si una pantalla, campo o estado necesita explicación técnica para ser usado correctamente, debe simplificarse antes de incorporarse a la experiencia cotidiana.