LEFEBVRE DATA STANDARD

Intelligence lives in data, not models.

The Lefebvre Data Standard (LDS) defines how deterministic systems store, validate, and govern structured data. Pre-computed logic. Sub-millisecond validation. Zero ambiguity.

"Pre-compute the reasoning. Store the result. Traverse the graph. Skip the inference."

0.01ms Validation Latency

82,000+ Validations / Sec

100% Deterministic

5,600:1 Compression Ratio

System Architecture

Four Components

The LDS Boundary System consists of four primary components. Each is stateless, deterministic, and independently testable.

COMPONENT 01

Logic Kernel

Core validation engine performing sub-millisecond boundary checks through indexed lookups and pre-compiled escalation rules. Stateless. Fail-closed.

COMPONENT 02

Entity Store

Indexed storage for boundary entities with O(1) retrieval by UUID, domain, role, and organization. ~5 KB memory per boundary.

COMPONENT 03

Knowledge Graph

Relationship management for requirements, conflicts, supersession chains, and transitive dependency resolution. Declared, not inferred.

COMPONENT 04

REST API

FastAPI-based HTTP interface with OpenAPI documentation, white-label customization, and multi-tenant support.

Traditional Guardrails

User Request
  → LLM Generates Response
  → Check Response (100-500ms)
  → Allow / Block

LDS Boundary System

User Request
  → Check Boundary (0.01ms)
  → If Allowed → Generate Response
  ✓ 10,000× faster

Kernel Document Specification v1.1

5-Layer Document Structure

All .ldk.* and .vk.* files contain exactly 5 layers. Self-contained. Self-describing. Self-authorizing.

LAYER 0: HEADER ├── version ├── doc_id ├── created_at ├── created_by ├── signature └── authority_chain[] LAYER 1: SCHEMA ├── taxonomy_version ├── axes[] ├── depth_limit ├── allowed_states[] └── strict_mode LAYER 2: DATA ├── entities[] ├── relations[] └── metadata LAYER 3: PERMISSIONS ├── read_access[] ├── write_access[] ├── execute_access[] └── delegation_rules LAYER 4: AUDIT ├── event_log[] └── hash_chain

LAYER 0

Header

Identity and authority chain. Establishes who created the document, who authorized it, and which governance level issued it.

Field	Type	Required
version	string	YES
doc_id	string	YES
created_at	datetime	YES
created_by	string	YES
signature	string	NO
authority_chain	array	YES

LAYER 1

Schema

Ontology definition. Taxonomy axes (max 8), depth limit (max 5), allowed states, and strict mode toggle. Immutable after creation.

Field	Type	Required
taxonomy_version	string	YES
axes	array	YES
depth_limit	int	YES
allowed_states	array	YES
strict_mode	boolean	YES

LAYER 2

Data

Payload with entities and a typed relation graph. Six relation types: DEPENDS_ON, VALIDATES, EXTENDS, COMPLIES_WITH, SUPERSEDES, CONFLICTS_WITH.

Field	Type	Required
entities	array	YES
relations	array	NO
metadata	object	NO

LAYER 3

Permissions

Access control with separate read, write, and execute permissions. Execute access grants rights to named runtimes, not people. Empty array = execution denied.

Field	Type	Required
read_access	array	YES
write_access	array	YES
execute_access	array	YES
delegation_rules	array	NO

LAYER 4

Audit

Immutable event log with optional Merkle hash chain for tamper-evidence. Append-only. Survives legal discovery.

Field	Type	Required
event_log	array	YES
hash_chain	string	NO

Entity Specification

Entity Structure

Each LDS entity has three sections. Metadata for identity. Core for semantics. Inference for pre-computed logic.

_lds

Metadata Block

uuid — Unique identifier
type — Entity type
version — Semantic version
content_hash — SHA-256 integrity
compliance — Framework mappings

core

Identity Block

name — Human-readable name
description — Purpose and scope
domain — Operational domain
role — Agent role in domain

inference

Logic Block

requires — Prerequisites
allowed_actions — Whitelist
denied_actions — Blacklist + reasons
escalation_rules — Thresholds
data_access — Source permissions
output_constraints — Format rules

THE LDS ADVANTAGE

Conflicts are stated

Not inferred at runtime

Dependencies are explicit

Not discovered by models

Relationships are declared

Not computed at runtime

Validation is graph traversal

Not model inference

Performance

Benchmarks

Tested on standard enterprise hardware (Intel Xeon, 32GB RAM). These are measured results, not projections.

Metric	LDS	Traditional	Improvement
Validation Latency	0.01 – 0.03 ms	100 – 500 ms	10,000×
Cached Latency	~0.005 ms	50 – 200 ms	40,000×
Throughput	82,435 /sec	~10 /sec	8,200×
P99 Latency	0.08 ms	800+ ms	10,000×
Memory / Boundary	~5 KB	N/A	—
Determinism	100%	Probabilistic	∞

Optimization Techniques

Pre-indexed Lookups — O(1) hash-based action verification

Pre-compiled Rules — Escalation compiled at load time

Redis Caching — Repeated decisions at ~0.005ms

Bloom Filters — Quick deny-list pre-checks

Invariants

Document Invariants

Five non-negotiable rules that every LDS Kernel Document must satisfy. Distinct from runtime kernel invariants (KRN.IV).

DOC.IV.01

Taxonomy depth SHALL NOT exceed 5 levels.

DOC.IV.02

Schema is immutable after document creation. Changes require a version bump.

DOC.IV.03

Audit log entries cannot be modified or deleted.

DOC.IV.04

Permissions govern all read, write, and execute operations.

DOC.IV.05

Document identity (doc_id) is globally unique.

Regulatory Alignment

Compliance Mapping

LDS already implements the core patterns that AI governance frameworks are converging toward.

Framework	LDS Support
NIST AI RMF	GOVERN: Boundary entities encode policies. MAP: Domain and role context. MEASURE: Conflict detection. MANAGE: Versioned updates via supersedes.
EU AI Act	Risk categorization via entity type. Human oversight in escalation rules. Audit trails via content hashes and version history.
ISO/IEC 42001	AI management system requirements map to structured boundary definitions. Continuous improvement via version evolution.

Industry Feature Mapping

Requirement	LDS Feature	Implementation
Declared constraints	inference.conflicts	Explicit forbidden actions with reasons
Dependency management	inference.requires	Preconditions that must be satisfied
Version control	inference.supersedes	Explicit version history chain
Content verification	_lds.content_hash	SHA-256 cryptographic integrity
Semantic indexing	vectors	Pre-computed embeddings for retrieval
Audit trail	_lds.uuid + version	Immutable identity and versioning

File Conventions

Extension Policy

Three extensions. Three authority levels. The naming convention is the product packaging story.

.ldk.*

Lefebvre Data Kernel

Open format. General purpose data structures. The foundation layer that anyone can build on.

.vk.*

ValidKernel

Certified compliance. Signed and validated by L0/L1 authority. The paid layer.

.ck.*

Canonical Kernel

Frozen standard. Immutable reference specifications. The law.

Design Requirements

Requirements

Every LDS document must satisfy these five constraints.

Self-contained — Single file, no external dependencies.
Self-describing — Schema embedded within document.
Self-authorizing — Permissions embedded within document.
Cryptographically signable — Supports Ed25519 / SHA-256.
Human-readable — JSON, Markdown, or text format. Not binary.

Reference

Example Document

A complete v1.1 kernel document: a validated roofing assembly that complies with global energy code 2026.

{
  "header": {
    "version": "1.1",
    "doc_id": "550e8400-e29b-41d4-a716-446655440000",
    "created_at": "2026-02-03T12:00:00Z",
    "created_by": "armand@lefebvre.design",
    "authority_chain": [
      { "level": "L0", "authority": "succinctauthority.com", "role": "GOVERNANCE" },
      { "level": "L1", "authority": "validkernel.com", "role": "ENFORCEMENT" }
    ]
  },
  "schema": {
    "taxonomy_version": "2026.1",
    "depth_limit": 5,
    "axes": ["category", "domain", "entity", "attribute", "state"],
    "allowed_states": ["DRAFT", "PENDING", "VALIDATED", "REJECTED", "ARCHIVED"],
    "strict_mode": true
  },
  "data": {
    "entities": [{
      "id": "ent_01",
      "path": "Construction.Roofing.Assembly.RValue.Validated",
      "value": 30
    }],
    "relations": [{
      "source": "ent_01",
      "target": "global_energy_code_2026",
      "type": "COMPLIES_WITH",
      "direction": "ONE_WAY"
    }]
  },
  "permissions": {
    "read_access": ["*"],
    "write_access": ["armand@lefebvre.design"],
    "execute_access": ["kernel:validkernel-runtime-v2"]
  },
  "audit": {
    "event_log": [{
      "timestamp": "2026-02-03T12:00:00Z",
      "action": "CREATED",
      "actor": "armand@lefebvre.design"
    }]
  }
}

Specification Status

Version 1.1.0

Semantic versioning. MAJOR = breaking changes. MINOR = backward-compatible additions. PATCH = clarifications.

CURRENT: v1.1.0 KDS-2026-02-03-001