Marco de estabilidad, resiliencia y horizontes del Lenguaje SV
Destinatario: agentes dedicados al desarrollo del Lenguaje SV
Ámbito: repositorio del Lenguaje de Programación del Sistema Vectorial SV
Fecha: 22 de marzo de 2026
Estatuto: documento rector normativo-operativo de cautela de arquitectura
0. Objeto del documento
Este documento existe para proteger al Lenguaje SV de dos riesgos simétricos:
- Cierre prematuro: fijar gramática, IR, validator, runner o backend de manera que el sistema no pueda hospedar desarrollos semánticos y matemáticos ya plausibles.
- Implementación precipitada: traducir de forma temprana al lenguaje desarrollos semánticos y matemáticos que todavía no están cerrados como semántica operativa.
La función de este texto no es ordenar implementaciones inmediatas.
Su función es dar al desarrollo del lenguaje un marco de resiliencia que permita avanzar hoy sin hipotecar el mañana.
1. Principio rector
El Lenguaje SV debe saber ya qué horizontes futuros ha de poder soportar, sin intentar resolverlos todavía.
Dicho de forma más estricta:
el Lenguaje SV no debe implementar todavía las aperturas semánticas y matemáticas futuras, pero sí está obligado a no cerrarse contra ellas.
Esta regla se aplica a:
- gramática;
- IR;
- validator;
- runner;
- backend.
2. Por qué se hace este documento
El desarrollo del SV necesita seguir avanzando en paralelo en dos frentes:
- frente semántico-matemático;
- frente de lenguaje de programación.
Si el segundo avanza sin horizonte, quedará estrecho y habrá que rehacerlo.
Si el segundo intenta anticiparlo todo, se rigidizará antes de tiempo y convertirá cautelas semánticas en implementaciones prematuras.
Este documento se crea para evitar ambas cosas.
3. Qué le dice este documento al Lenguaje SV
3.1. Lo que no debe hacer
El Lenguaje SV no debe:
- abrir nuevas categorías gramaticales por inercia;
- sobrerreificar en IR desarrollos aún no cerrados;
- fijar validator o runner con supuestos temporales, lineales o uniformes demasiado fuertes;
- endurecer el backend con una ontología demasiado plana o demasiado cerrada.
3.2. Lo que sí debe hacer
El Lenguaje SV sí debe:
- conservar elasticidad semántica;
- evitar decisiones irreversibles incompatibles con desarrollos futuros plausibles;
- registrar explícitamente sus deudas vivas;
- detenerse en hitos verificables antes de seguir ampliando alcance.
3.3. Lo que debe saber
El Lenguaje SV debe poder hospedar, cuando proceda y solo cuando proceda, al menos estos horizontes:
- relaciones no triviales entre sucesos;
- cadenas y acumulaciones no banales;
- persistencia, umbral y transición;
- datos de enlace entre regímenes;
- equivalencias parciales entre regímenes;
- preservaciones localizadas e invariancias locales;
- familias de preservación, clases de régimen y posibles tránsitos entre clases.
4. Regla de gobierno por hitos
El desarrollo del lenguaje no debe evolucionar por entusiasmo de implementación, sino por hitos asegurables.
Hito 1 — Base segura
Objetivo:
- consolidar una base funcional sin contradicción con los horizontes ya identificados.
Se asegura:
- gramática mínima estable;
- IR no incompatible con relaciones ni acumulaciones futuras;
- validator coherente con la base semántica actual;
- runner funcional sin presuposiciones indebidas.
No se permite:
- introducir formalización operativa de invariancia;
- introducir clases de régimen;
- introducir equivalencia parcial operativa.
Hito 2 — Elasticidad controlada
Objetivo:
- preparar la arquitectura para alojar desarrollos posteriores, sin implementarlos.
Se asegura:
- IR no bloqueante para familias de propiedades;
- validator no rígido ante patrones de transición no uniformes;
- runner no dependiente de una continuidad fuerte implícita.
No se permite:
- semántica cerrada de preservación;
- clases formales de régimen;
- ABI semántico rígido para equivalencias.
Hito 3 — Preparación de integración futura
Objetivo:
- dejar listo el terreno para futuras integraciones semánticas, manteniendo aún separación de niveles.
Se asegura:
- IR capaz de admitir extensiones localizadas;
- puntos de extensión claros para validator y runner;
- backend no hipotecado por decisiones irreversibles.
No se permite:
- implementar teoría completa de invariantes;
- equivalencia global;
- límite, topología o reconstrucción geométrica.
5. Criterios de parada obligatoria
Toda línea de desarrollo del lenguaje deberá detenerse y auditar antes de pasar de un hito a otro si ocurre cualquiera de estas situaciones:
- necesidad de ampliar el sentido de una construcción IR ya fijada;
- tentación de introducir nuevas categorías sintácticas para hospedar semántica todavía abierta;
- detección de que validator o runner presuponen transiciones uniformes, lineales o temporalistas;
- necesidad de que el backend represente ya estructuras que aún solo existen como horizonte semántico;
- duda real sobre si una decisión actual reduce capacidad futura del sistema.
6. Regla de interpretación de los documentos de control
Los documentos que acompañan a este marco deben leerse así:
- Matriz UCBC: identifica horizontes, riesgos y hito correcto de contemplación.
- Registro de calidad: documenta decisiones tomadas y puntos de verificación.
- Deuda viva: registra explícitamente lo que no se implementa todavía y por qué.
Ninguno de estos documentos autoriza por sí mismo cambios de gramática, IR, validator, runner o backend.
7. Regla maestra final
Toda decisión de diseño del Lenguaje SV que reduzca su capacidad futura de hospedar relaciones, cadenas, persistencias, enlaces, equivalencias parciales o invariancias locales deberá tratarse como defecto estructural, aunque el sistema funcione correctamente en el presente.
8. Cierre
Este documento no entrega una hoja de ruta de implementación por temas concretos.
Entrega algo más importante: un marco de resiliencia.
Debe usarse para saber:
- hasta dónde puede llegarse ahora;
- dónde hay que detenerse;
- qué no debe cerrarse;
- y cómo seguir avanzando sin hipotecar el sistema.