Design Principles & Boundaries
This document declares the architectural principles and the non-negotiable boundaries of the protocol, as infrastructural invariants: properties that the system must preserve across every implementation and every future revision.
§ 01 · Introduction
The principles that follow and the boundaries that accompany them constitute the invariants of the protocol. They are stated explicitly so that every implementation and every revision can be measured against them.
The invariants are not recommendations: they are structural properties. An implementation that violates them does not realise AIKNOCK, even if it adopts its name or terminology.
§ 02 · Design Principles
The following principles define the technical behaviour of the system during the execution of artificial intelligence operations. The eight principles define the architectural properties the protocol must preserve. They are numbered for reference and read as a whole: no principle is dispensable without altering the nature of the protocol.
AI is treated as a critical capability of the system, not as a library or an application feature. Its use is subject to the properties the system reserves for critical resources.
Every invocation of AI traverses the protocol. Interposition is not optional and does not depend on the cooperation of the calling code.
The evaluation of context and intent is ex-ante: it precedes the invocation of the model. It is not a subsequent control nor a sample-based verification.
The decision is applied by a technical mechanism at the system level. Statements of intent and organisational rules do not replace enforcement.
Evidence is an effect of the protocol's operation, not an additional feature. The verifiability of decisions is structural.
The technical presence of a model does not imply authorisation of its use. The two layers — availability and authorisation — remain distinct by construction.
Where required, human intervention is not an operational procedure but a requirement imposed by the system. The protocol does not proceed in its absence.
The protocol does not depend on a particular model, runtime or commercial provider. It defines an execution-control interface to which every implementation conforms.
§ 03 · Boundaries
To the principles correspond explicit boundaries. These boundaries delimit what the protocol, by construction, does not occupy: they are as binding as the principles and contribute to defining its identity.
The protocol does not inspect, filter or evaluate the contents exchanged with the models. Its domain is the right of use, not the merit of the result.
Legal obligations remain such. AIKNOCK does not interpret norms, does not guarantee compliance, does not overlap with the competent jurisdiction.
The protocol describes technical properties of the system. It does not define certification processes, does not issue attestations, does not replace the relevant bodies.
Construction, training, selection and evaluation of models are out of scope. The protocol acts at the moment of use, not upstream.
AIKNOCK does not include dashboards, consoles or end-user experiences. It is an infrastructural layer: interfaces remain the responsibility of implementations.
The boundaries listed above are not gaps in the protocol: they are deliberate architectural choices. Restricting scope is a necessary condition for what the protocol declares it does to be guaranteed with precision.
§ 04 · Synthesis
The principles define what the protocol is. The boundaries define what the protocol is not.
Together they constitute the invariants: the condition for AIKNOCK to remain recognisable across every implementation, every revision and every adoption.
A specification that changes identity at every revision is not a standard. Invariants are the way an open protocol makes itself durable.