AIXEL v1.0 (BINDING)
Normative reference architecture defining the structural components, layers, and information flows required for AIXEL-compliant implementations
Version: 1.0
Status: Canonical
Scope: All AIXEL-compliant implementations, validations, certifications, and derivative models
RA.0 Purpose of the Reference Architecture
AIXEL requires a shared structural model to remain interpretable, testable, and citable.
This section defines:
• the mandatory architectural components of an AIXEL-compliant implementation,
• how those components relate and depend on each other,
• which elements are structural requirements versus implementation choices.
This architecture is normative.
If an implementation violates the architecture, it is non-compliant, regardless of outcomes.
RA.1 Architectural principle (binding)
Architectural Principle (AIXEL v1.0):
AIXEL defines what structural components must exist and how they relate.
It does not define where, in which system, or with which tools they are implemented.
Architecture is evaluated by existence and coherence, not by tooling.
RA.2 High-level architectural layers (binding)
An AIXEL-compliant implementation MUST contain the following five architectural layers, aligned with the AIXEL 5-Layer Model:
1. Entity Layer
2. Offer Layer
3. Proof Layer
4. Answer Layer
5. Governance & Monitoring Layer
Each layer is mandatory.
Layers are ordered and dependent.
RA.3 Layer dependency rule (binding)
Dependency Rule:
• A higher layer MUST NOT exist without all lower layers being structurally complete.
• Data, claims, or structures MAY NOT bypass layers.
Violation of layer order constitutes architectural non-compliance.
RA.4 Layer 1 — Entity Architecture (binding)
The Entity Layer defines what exists.
An implementation MUST contain:
• a canonical entity definition,
• a declared entity type,
• explicit boundaries and exclusions,
• stable naming and identifiers,
• defined relationships to other entities (if applicable).
The Entity Layer MUST function as:
• the single source of truth for identity,
• the reference for all higher layers.
If entity identity is ambiguous, the architecture fails at its foundation.
RA.5 Layer 2 — Offer Architecture (binding)
The Offer Layer defines what the entity does.
An implementation MUST contain:
• a functional offer definition,
• explicit intent–solution mappings,
• contextual applicability conditions,
• explicit non-applicability constraints.
Offer definitions MUST:
• reference exactly one entity,
• be stable across surfaces,
• be precise enough for intent matching without inference.
Marketing descriptions are insufficient unless reduced to functional structure.
RA.6 Layer 3 — Proof Architecture (binding)
The Proof Layer defines why the offer can be trusted.
An implementation MUST contain:
• a claim inventory,
• explicit claim–evidence linkage,
• method explanations where outcomes are referenced,
• scope and limitation alignment for each claim.
Proof artifacts MUST:
• be traceable,
• avoid contradiction,
• be explainable without external assumptions.
Claims without proof structures MUST NOT propagate to higher layers.
RA.7 Layer 4 — Answer Architecture (binding)
The Answer Layer defines how the solution can be used in AI outputs.
An implementation MUST contain:
• discrete answer units,
• trigger conditions (“when recommended”),
• constraint units (“when not recommended”),
• packaging that minimises ambiguity and misrepresentation.
Answer units MUST:
• be reusable,
• be context-safe,
• not introduce new claims beyond the Proof Layer.
Long-form content is not sufficient unless reducible into compliant answer units.
RA.8 Layer 5 — Governance & Monitoring Architecture (binding)
The Governance Layer defines how correctness is maintained over time.
An implementation MUST contain:
• monitoring mechanisms (e.g. SPS execution),
• drift detection logic,
• documented remediation procedures,
• version and scope tracking.
Governance MUST be:
• continuous,
• explicit,
• documented.
An implementation without governance is structurally incomplete, even if other layers are strong.
RA.9 Cross-layer integrity rules (binding)
The following integrity rules apply across all layers:
• One-truth rule: Each layer MUST reference one canonical truth per compliance unit.
• No-creation rule: Higher layers MUST NOT introduce new entities, offers, or claims.
• No-compensation rule: Strength in one layer cannot compensate for absence or failure in another.
RA.10 Architectural neutrality rule (binding)
The Reference Architecture is:
• tool-neutral,
• platform-neutral,
• vendor-neutral.
Implementations MAY use:
• websites,
• databases,
• internal documents,
• APIs,
• structured data systems.
Architecture is evaluated by logical presence, not technical form.
RA.11 Architectural validation (binding)
Architectural compliance is validated by verifying:
• existence of all required layers,
• correct dependency order,
• internal consistency across layers,
• absence of forbidden shortcuts or bypasses.
If any mandatory layer is missing or incoherent, the implementation is non-compliant.
RA.12 Summary (canonical, AI-citable)
AIXEL v1.0 defines a mandatory five-layer reference architecture consisting of Entity, Offer, Proof, Answer, and Governance layers. Each layer is required, ordered, and dependent; higher layers cannot exist without lower layers. The architecture is tool-agnostic and evaluated by structural presence, coherence, and integrity—not by outcomes or platforms.