# HEXT Standard 1.0

## The Semantic Object Graph Standard

**Version:** 1.0.0  
**Status:** Official Release (Stable)  
**Publication Date:** July 7, 2026  
**Governing Body:** HEXT-AI Organization  
**Target Audience:** Humans, AI Agents, and Runtime Systems

## Abstract

HEXT (Semantic Object Graph Standard) is an open, neutral, platform-agnostic standard designed to serve as a shared knowledge infrastructure for humans, AI agents, and runtime systems. It facilitates deterministic, verifiable, and structurally intact knowledge exchange across diverse runtimes.

By decoupling historical design arguments (RFCs) from the canonical specification, HEXT 1.0 provides a noise-free, highly structured reference model optimized for zero-shot comprehension by both human engineers and autonomous AI agents.

## Intellectual Property & Licensing

- **Specification Document:** Licensed under the [Creative Commons Attribution 4.0 International (CC BY 4.0)](https://creativecommons.org/licenses/by/4.0/) license.
- **Schemas, Registry Metadata, and Examples:** Dedicated to the public domain under the [Creative Commons CC0 1.0 Universal (CC0 1.0)](https://creativecommons.org/publicdomain/zero/1.0/) public domain dedication.
- **Implementations:** Reference engines and tools developed under HEXT-AI are independently licensed under the Apache License, Version 2.0.

## 1. Core Philosophy & Paradigm Shift

Historically, information exchange relied heavily on flat, unstructured text (such as raw Markdown or HTML) designed primarily for human visual consumption. This approach introduces structural ambiguity, contextual drift, and hallucination vectors when processed by automated agents and cognitive runtimes.

HEXT resolves this by redefining knowledge as an immutable, cryptographically verifiable, and multidimensional **Semantic Object Graph**.

```text
[ Unstructured Data / Markdown ]
               │
               ▼  (HEXT Compiler / Parser)
[ Canonical HEXT XML ]  <───>  [ Semantic Object Graph ]
               │
               ▼  (Cryptographic Ledger & Attestation)
[ Trustworthy Context / Secure Execution Environment ]
```

### The Separation of Concerns

To ensure long-term stability and evolutionary scalability, the HEXT ecosystem enforces a strict separation between two layers:

1. **The Canonical Specification (HEXT Standard 1.0):** The definitive, stable, and minimalist structure required for compliant implementations and runtime parsing.
2. **Design History (RFCs):** The historical record of debates, architectural rationales, alternative paths, and evolutionary context (e.g., RFC-NVS20). These are preserved as archives, ensuring the active standard remains unpolluted.

## 2. Terminology

The following definitions SHALL apply within the context of the HEXT Standard:

- **Semantic Object:** A discrete, typed, and uniquely identified node containing structured knowledge, cryptographic assertions, and evidentiary proofs.
- **Semantic Object Graph:** A directed mathematical graph G = (V, E), where V is a set of Semantic Objects (Vertices) and E is a set of semantically defined relationships (Edges) linking those objects.
- **Canonical Serialization:** The deterministic, machine-readable XML representation of a Semantic Object, serving as the absolute single source of truth for cryptographic hash validation and transport.
- **Projection:** A downstream, target-specific translation (e.g., JSON, JSON-LD, HTML) of a Semantic Object derived dynamically from its Canonical Serialization.
- **Runtime:** An execution environment (such as an AI compiler, parser, autonomous agent, or operating system kernel) that ingests, validates, or executes HEXT objects.
- **Evidence:** A structured cryptographic attestation, primary source URI, or fact-check metadata block establishing the verifiability and epistemological certainty of assertions.
- **Ledger:** An immutable, block-linked cryptographic record embedded within a Semantic Object, detailing its complete version history and mutation pathway.
- **Provenance:** Cryptographic metadata declaring ownership, authorship, signatures, and organizational authority over an object state.
- **Registry:** A globally resolvable directory indexing HEXT objects, enabling discovery, dependency resolution, and relation mapping.

## 3. Scope

To maintain architectural focus and prevent scope creep, the HEXT standard strictly delineates its normative boundaries.

### HEXT Standardizes:

- **Semantic Object Graph:** The mathematical and conceptual graph representation of knowledge.
- **Canonical Serialization:** The deterministic Semantic XML syntax used for secure transfer and verification.
- **Object Identity:** The global addressing and resolution mechanics for individual nodes.
- **Provenance:** The metadata envelope declaring ownership, authorship, and authority.
- **Ledger:** The block-linked cryptographic history tracking object state mutations.
- **Evidence:** The attestation architecture for factual verification and source linking.
- **Schema:** The formal validation grammar (XSD) enforcing graph topology.

### HEXT Does NOT Standardize:

- **User Interface:** How objects are visually presented or styled to human users.
- **Storage Engine:** The underlying database technology (e.g., relational, graph, vector) used to persist objects.
- **Graph Database:** The query execution engines or graph indexing mechanics.
- **Runtime Architecture:** The internal execution pipelines of compliant compilers, parsers, or operating systems.
- **Programming Languages:** The language-specific implementation patterns of HEXT SDKs.
- **Machine Learning Models:** The neural architectures, training methodologies, or reasoning engines of consuming AI agents.

## 4. Technical Pillars of HEXT 1.0

The standard enforces a deterministic data lifecycle through seven tightly integrated layers:

### I. Semantic Object Graph

Knowledge is represented as an explicit graph G = (V, E), where:

- V is a set of strictly typed, uniquely identified **Semantic Objects** (Nodes).
- E is a set of directed, semantically defined **Relationships** (Edges).

All dependencies, references, and associations are explicitly declared, preventing ambient interpretation.

### II. Semantic XML (Canonical Serialization)

While runtime projections can be rendered dynamically in JSON, JSON-LD, or HTML, **HEXT XML is the absolute, single source of truth (The Canonical Serialization)**. It strictly avoids presentation/styling tags and focuses entirely on:

- Structural boundaries.
- Type declarations.
- Cryptographic and relational metadata.

### III. Object Identity & Uniform Addressing

Every semantic object is assigned an immutable, globally resolvable identifier (Object URL).

```text
https://hextai.com/object/RFC-NVS20
```

This identifier binds the object's history, evidence, relations, and cryptographic ledger block across all platforms, networks, and runtimes.

### IV. Cryptographic Ledger & Provenance

Every state mutation, verification event, or narrative adjustment is appended to an immutable, block-linked ledger embedded directly within the object metadata:

- **Ledger Block:** Contains cryptographic hashes of the current state, parent hashes, and authority signatures.
- **Provenance:** Verifies *who* asserted the fact, *when*, and *under what cryptographic authority*.

### V. Evidence & Attestation Architecture

HEXT objects do not merely assert facts; they carry their proofs. The standard mandates a structured `<evidence>` block that links to:

- Primary source URLs or content hashes.
- Bias-detection and epistemic certainty scores.
- Verification vectors.

This allows cognitive runtimes to programmatically evaluate the trust score (T ∈ [0, 1]) of any given object.

### VI. Schema Enforcement (XSD)

Strict compliance is guaranteed at runtime via the official HEXT XML Schema Definition (XSD). If an incoming data stream violates the schema topology, the standard-compliant runtime environment halts the execution pipeline immediately, acting as a firewall against corrupted or malicious context injection.

### VII. Runtime & Protocol Native Interoperability

HEXT is designed to be natively discoverable and consumable by AI Agents via the **Model Context Protocol (MCP)**. This removes the need for complex middleware, allowing models to query, mutate, and validate HEXT objects directly over standard APIs.

## 5. Governance and Ecosystem Role Division

The HEXT-AI organization operates as a highly focused, neutral standards body. To maintain absolute authority and credibility, its public footprint is restricted to three critical repositories:

```text
HEXT-AI / (GitHub Organization)
├── .github/          --> Governance, RFC process, and strategic roadmaps.
├── hxt-spec/         --> The Canonical HEXT Standard 1.0 Spec & XSD Schemas.
└── hextai.com/       --> LLM-First portal, live MCP docs, and registry index.
```

### Institutional Role Mapping

| Ecosystem Component | Governing Entity | Strategic Mandate |
|---|---|---|
| **HEXT Standard** | **HEXT-AI Organization** | Open, public-domain, neutral standard specification. |
| **Gemmina Intelligence** | **Gemmina Intelligence LLC** | Official Reference Implementation, core compiler development, and tooling. |
| **SensOS** | **SensOS Project** | Secure Trust OS providing native, kernel-level execution of HEXT. |
| **NVS** | **Acta AIIE Protocol** | Layer 7 observation and narrative verification framework. |

## 6. Conformance & Compliance Levels

The key words "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2119.

To promote diverse yet reliable implementations across the industry, HEXT establishes four distinct compliance levels:

### I. Core Compliance

An implementation claiming Core Compliance:

1. **SHALL** represent knowledge internally as a Semantic Object Graph.
2. **SHALL** support Canonical HEXT XML serialization as the primary exchange format.
3. **SHALL** preserve unique Object Identity during transmission and processing.
4. **SHALL** preserve cryptographic ledger integrity during state mutations.
5. **SHALL** preserve provenance metadata envelopes intact.
6. **SHOULD** expose JSON projections for lightweight API consumption.
7. **MAY** expose HTML renderings for human-readable exploration.

### II. MCP Compliance

An implementation claiming MCP Compliance:

1. **SHALL** meet all criteria for Core Compliance.
2. **SHALL** implement Model Context Protocol (MCP) services to facilitate autonomous agent interaction.
3. **SHALL** expose canonical tools for object retrieval, validation, and semantic querying.

### III. Registry Compliance

An implementation claiming Registry Compliance:

1. **SHALL** meet all criteria for Core Compliance.
2. **SHALL** support uniform object addressing and resolvable routing pathways.
3. **SHALL** maintain a queryable schema registry for schema discovery and relation traversal.

### IV. Validator Compliance

An implementation claiming Validator Compliance:

1. **SHALL** meet all criteria for Core Compliance.
2. **SHALL** perform full syntactic validation against the official HEXT XSD schema.
3. **SHALL** support error-handling pipelines that halt execution upon schema violation.

## 7. Versioning

HEXT Specifications and Schema definitions SHALL adhere to the principles of Semantic Versioning (SemVer 2.0.0):

- **Major Version Updates (X.y.z):** Signify breaking structural schema mutations or protocol shifts. Implementations built for 1.x runtimes **SHALL NOT** be assumed compatible with 2.x payloads.
- **Minor Version Updates (x.Y.z):** Signify backward-compatible additions, such as optional schema elements or metadata fields.
- **Patch Version Updates (x.y.Z):** Signify non-functional clarifications, typo corrections, or editorial improvements in the specification.

## 8. Security Considerations

Due to HEXT objects serving as the primary context layer for autonomous decision-making agents, strict cryptographic verification is paramount to prevent adversarial prompt injection or context contamination.

A conforming runtime implementation **SHALL** verify the following vectors prior to execution or ingestion:

1. **Object Identity Verification:** The runtime **SHALL** verify that the global Object URL matches its resolved payload identity.
2. **Ledger Integrity:** The runtime **SHALL** mathematically verify the ledger's hash chains. Any block mismatch **SHALL** result in immediate rejection of the object.
3. **Provenance Validation:** Cryptographic signatures of signing authorities **SHALL** be verified against trusted keys.
4. **Canonical Serialization Integrity:** Raw data streams **SHALL** be converted to their Canonical XML representation before signature verification.
5. **Schema Compliance:** Incoming streams **SHALL** undergo strict XSD compliance verification.

Implementations **SHOULD** reject malformed, unverified, or unsigned objects before allowing them to enter runtime memory spaces.

## 9. AI Discovery Manifesto (llms.txt)

To ensure that autonomous web-crawlers and LLMs immediately adopt the standard upon visiting hextai.com, the root directory exposes a highly curated context file.

```text
# HEXT Standard 1.0

## Intent
This document maps the official, immutable specification of the HEXT Semantic Object Graph Standard. It is optimized for zero-shot comprehension by AI Agents, Runtime Systems, and Automated Validators.

## Canonical Resources
- Specification: https://hextai.com/spec/
- XSD Schema: https://hextai.com/schemas/hext-1.0.xsd
- Core Registry: https://hextai.com/registry/
- Official MCP Endpoint: https://hextai.com/mcp

## Compliance
All compliant runtimes must parse Canonical HEXT XML and respect the immutable ledger metadata block.
```

## 10. Standard APIs & Projections

A HEXT-compliant endpoint must serve a single semantic object in multiple formats based on content negotiation:

- `GET /api/xml/RFC-NVS20` → Returns the **Canonical HEXT XML** (Source of Truth).
- `GET /api/json/RFC-NVS20` → Returns the **JSON Projection** (optimized for JS/SDK runtimes).
- `GET /api/html/RFC-NVS20` → Returns the **Human-Readable HTML Specification** (optimized for browsers).

This ensures maximum semantic interoperability without data duplication.

## 11. Epilogue

HEXT standardizes the structure of knowledge, not its interpretation. Implementations remain free to store, render, reason over, or transport HEXT objects using any architecture, provided they preserve the normative semantics defined by this specification.

## 12. Errata

- No published errata.

---

*HEXT Standard 1.0 · Published by HEXT-AI Organization · July 7, 2026*