Design Principles & Boundaries
Este documento declara los principios arquitectónicos y los límites no negociables del protocolo, como invariantes infraestructurales: propiedades que el sistema debe preservar a través de cada implementación y de cada revisión futura.
§ 01 · Introducción
Los principios que siguen y los límites que los acompañan constituyen las invariantes del protocolo. Se enuncian explícitamente para que toda implementación y toda revisión puedan medirse con ellos.
Las invariantes no son recomendaciones: son propiedades estructurales. Una implementación que las viole no realiza AIKNOCK, aun cuando adopte su nombre o su terminología.
§ 02 · Design Principles
Los principios que siguen definen el comportamiento técnico del sistema durante la ejecución de operaciones de inteligencia artificial. Los ocho principios definen las propiedades arquitectónicas que el protocolo debe preservar. Están numerados a efectos de referencia y se leen como un conjunto: ningún principio es prescindible sin alterar la naturaleza del protocolo.
La IA se trata como una capability crítica del sistema, no como una biblioteca o una funcionalidad aplicativa. Su uso queda sujeto a las propiedades que el sistema reserva a los recursos críticos.
Toda invocación de la IA atraviesa el protocolo. La interposición no es opcional y no depende de la cooperación del código que la solicita.
La evaluación del contexto y la intención es ex-ante: precede a la invocación del modelo. No es un control posterior ni una verificación por muestreo.
La decisión es aplicada por un mecanismo técnico a nivel del sistema. Las declaraciones de intención y las reglas organizativas no sustituyen el enforcement.
Las evidencias son un efecto del funcionamiento del protocolo, no una funcionalidad adicional. La verificabilidad de las decisiones es estructural.
La presencia técnica de un modelo no implica la autorización de su uso. Los dos planos — disponibilidad y autorización — permanecen distintos por construcción.
Cuando se requiere, la intervención humana no es un procedimiento operativo sino un requisito impuesto por el sistema. El protocolo no avanza en su ausencia.
El protocolo no depende de un modelo, runtime o proveedor comercial concretos. Define una interfaz de control de ejecución a la que toda implementación se ajusta.
§ 03 · Boundaries
A los principios corresponden límites explícitos. Estos límites delimitan lo que el protocolo, por construcción, no ocupa: son tan vinculantes como los principios y contribuyen a definir su identidad.
El protocolo no inspecciona, no filtra ni evalúa los contenidos intercambiados con los modelos. Su dominio es el derecho de uso, no el mérito del resultado.
Las obligaciones jurídicas siguen siendo tales. AIKNOCK no interpreta normas, no garantiza cumplimiento, no se superpone a la jurisdicción competente.
El protocolo describe propiedades técnicas del sistema. No define procesos de certificación, no emite atestaciones, no sustituye a los organismos competentes.
La construcción, el entrenamiento, la selección y la evaluación de los modelos quedan fuera de ámbito. El protocolo actúa en el momento del uso, no aguas arriba.
AIKNOCK no incluye paneles, consolas ni experiencias de uso. Es un plano infraestructural: las interfaces siguen siendo responsabilidad de las implementaciones.
Los límites enumerados arriba no son lagunas del protocolo: son elecciones arquitectónicas deliberadas. Restringir el ámbito es condición necesaria para que aquello que el protocolo declara hacer pueda garantizarse con precisión.
§ 04 · Síntesis
Los principios definen lo que el protocolo es. Los límites definen lo que el protocolo no es.
Juntos constituyen las invariantes: la condición para que AIKNOCK siga siendo reconocible a través de cada implementación, cada revisión y cada adopción.
Una especificación que cambia de identidad en cada revisión no es un estándar. Las invariantes son el modo en que un protocolo abierto se hace durable.