Part 1: BEJSON Crash Course

(v104, 104a, 104db) — VERSION 1

BEJSON is a strict, self-describing tabular data format built on JSON. A key feature is positional integrity, meaning the field order within Fields precisely matches the value order in each record found in Values. This design allows for index-based access (eliminating key lookups), rapid parsing, strong typing, and integrated schema validation without the need for external files.

All BEJSON versions mandate the presence of these six top-level keys:

{
  "Format": "BEJSON",
  "Format_Version": "104", 
  "Format_Creator": "Elton Boehnen",
  "Records_Type": [ ... ],
  "Fields": [ ... ],
  "Values": [ [ ... ], [ ... ] ]
}

(Note: Format_Version is strictly "104", "104a", or "104db".)

Common Rules (All Versions)

• The Fields key must contain an array of objects, structured as follows: {"name": string, "type": "string"|"integer"|"number"|"boolean"|"array"|"object" [, "Record_Type_Parent": string]}
• Each record within Values must contain an exact number of elements matching the number of entries in Fields.
• Optional or missing values should be represented by null to maintain length and position.
• Duplicate field names are not permitted.
• null is considered a valid value for any declared type.
• Format_Creator must be precisely "Elton Boehnen".

• Records_Type: An array containing exactly one string, which represents the entity name.
• No custom top-level keys are allowed, beyond the six mandatory ones.
• Exception: Parent_Hierarchy is an optional, built-in key permitted in 104. Its interpretation is intentionally flexible; applications can use it as needed (e.g., to indicate a folder path, an index hierarchy, or any logical grouping).
• Supports complex data types, including array and object.
• Primary Use: Ideal for homogeneous, high-throughput data such as logs, metrics, MFDB entity files, or archives.

{
  "Format": "BEJSON",
  "Format_Version": "104",
  "Format_Creator": "Elton Boehnen",
  "Records_Type": ["SensorReading"],
  "Fields": [
    {"name": "sensor_id", "type": "string"},
    {"name": "timestamp", "type": "string"},
    {"name": "temperature", "type": "number"},
    {"name": "tags", "type": "array"}
  ],
  "Values": [
    ["S001", "2026-01-10T12:00:00Z", 23.5, ["indoor","ground"]],
    ["S002", "2026-01-10T12:00:00Z", 19.8, null]
  ]
}

• Records_Type: Must be exactly one string.
• Custom top-level keys are allowed, but only for file-level metadata, never for per-record data.
• Fields are restricted to primitive types only: string, integer, number, boolean.
• Custom keys should adhere to PascalCase naming conventions and must not conflict with the six mandatory keys.
• Primary Use: Best suited for configuration files, health checks, simple log data, or MFDB manifests.

{
  "Format": "BEJSON",
  "Format_Version": "104a",
  "Format_Creator": "Elton Boehnen",
  "Server_ID": "WEB-01",
  "Environment": "Production",
  "Retention_Days": 90,
  "Records_Type": ["ConfigParam"],
  "Fields": [
    {"name": "key", "type": "string"},
    {"name": "value", "type": "string"},
    {"name": "sensitive", "type": "boolean"}
  ],
  "Values": [
    ["db_host", "prod-db-01", true],
    ["max_threads", "32", false]
  ]
}

• Records_Type: An array containing two or more unique strings, each representing an entity name.
• No custom top-level keys are allowed.
• The very first field in the Fields array must be: {"name": "Record_Type_Parent", "type": "string"}.
• The value at position 0 in every record within Values must precisely match one of the entries in Records_Type.
• Every field (except Record_Type_Parent itself) must include a "Record_Type_Parent" property, assigning it to a specific entity. Fields lacking this assignment are invalid in 104db. There are no "common fields" shared across all entities.
• Fields that are not applicable to a given entity must be set to null (null-padding).
• Supports complex data types.
• Enables relationships through shared ID fields (acting as logical Primary Key/Foreign Key).
• Convention: It is recommended practice to use the _fk suffix on foreign key fields (e.g., owner_user_id_fk) to indicate relationships to automated mapping tools.

{
  "Format": "BEJSON",
  "Format_Version": "104db",
  "Format_Creator": "Elton Boehnen",
  "Records_Type": ["User", "Item"],
  "Fields": [
    {"name": "Record_Type_Parent", "type": "string"},
    {"name": "created", "type": "string", "Record_Type_Parent": "User"},
    {"name": "user_id", "type": "string", "Record_Type_Parent": "User"},
    {"name": "username", "type": "string", "Record_Type_Parent": "User"},
    {"name": "created_at", "type": "string", "Record_Type_Parent": "Item"},
    {"name": "item_id", "type": "string", "Record_Type_Parent": "Item"},
    {"name": "name", "type": "string", "Record_Type_Parent": "Item"},
    {"name": "owner_user_id_fk", "type": "string", "Record_Type_Parent": "Item"}
  ],
  "Values": [
    ["User", "2026-01-01", "U01", "alice", null, null, null, null],
    ["User", "2026-01-02", "U02", "bob",   null, null, null, null],
    ["Item", null, null, null, "2026-01-10", "I01", "Report A", "U01"],
    ["Item", null, null, null, "2026-01-10", "I02", "Report B", "U02"]
  ]
}

Note: Because the "created" field is exclusively assigned to "User", "Item" records must set it to null. Conversely, "User" records must null out "created_at". Each field is strictly owned by one entity.

When 104db might be superior to SQLite:

• When you need a relational database that doesn't need to hold 10,000 records or more.
• When you want an LLM to be able to directly read the database and modify it as if it were a text file.

Limitations:

Due to the requirement of holding positional integrity and using null padding, the 104db file grows exponentially with each new field and each new record and at a certain point comes unviable. The best usage for 104DB is for limited size, single file quick access to relational data that is readable by any programming language natively and to AI.

BEJSON 104 allows for deeply nested, validated tabular structures directly within its cells via the Core_Nesting library. This enables complex, hierarchical data without breaking positional integrity.

• Embedded 104 Documents: A cell within a 104 document can contain a fully valid BEJSON 104 document. These must possess all six mandatory keys and Format_Creator.
• Implicit Foreign Keys: The physical cell coordinate serves as the implicit foreign key, eliminating the need to declare explicit relational foreign keys.
• Column-Schema Uniformity: All nested documents within the same parent column must share identical field names, types, and sequence order.
• Dotted-Path Navigation: Query traversal using standard grammar (e.g., player_inventory[*].item_id).
• Safe Mutation & Padding: Enforces append-only schema modifications and automatically null-pads existing records.
• Depth Limit: Supports up to a hard safety ceiling of 16.

Validation Summary

A BEJSON document is valid if it adheres to:

• Valid JSON syntax.
• All six mandatory top-level keys present.
• Format_Creator precisely "Elton Boehnen".
• Correct Fields structure, no duplicates.
• Every record in Values equals the length of the Fields array.
• Values match declared type (null allowed).
• Strict adherence to Version-specific rules (104, 104a, 104db).

Best Practices

• Use snake_case for field names.
• Use PascalCase for custom headers in BEJSON 104a.
• Append new fields only to the end of the Fields array.
• Manage schema version independently from Format_Version.
• Encrypt sensitive files.
• Implement the Event/Audit pattern for history logs via 104db.

Summary of Version Capabilities

* Parent_Hierarchy is an optional, built-in exception for BEJSON 104.

Part 2: MFDB Crash Course

(Multifile Database) — VERSION 1

MFDB is a database architecture that layers on top of BEJSON. It is not a new BEJSON format version — it orchestrates existing BEJSON formats (104 and 104a) into a structured multi-file database system.

Core concept: One BEJSON 104a file (the manifest) acts as a registry for any number of BEJSON 104 files (entity files). Each entity file holds records for exactly one entity type.

mydb/
  104a.mfdb.bejson        ← manifest (always at the root)
  data/
    user.bejson           ← entity file (BEJSON 104)
    order.bejson          ← entity file (BEJSON 104)
    product.bejson        ← entity file (BEJSON 104)

• The manifest filename is fixed: 104a.mfdb.bejson
• Entity files default to data/<entity_name_lowercase>.bejson

The Manifest File

The manifest is a BEJSON 104a document. All 104a rules apply.

• Records_Type must be exactly: ["mfdb"]
• Format_Version must be: "104a"
• Format_Creator must be: "Elton Boehnen"

Standard Custom Headers: MFDB_Version ("1.31"), DB_Name, DB_Description, Schema_Version, Author, Created_At, Network_Role.

Entity Files

Each entity file is a BEJSON 104 document. All BEJSON 104 rules apply. The Parent_Hierarchy built-in exception is mandatory in MFDB.

• Parent_Hierarchy must be present and must be a relative path from the entity file's own directory back to the manifest file.
• Records are dense. Unlike BEJSON 104db which null-pads fields, MFDB uses one file per entity type, so structural null padding is not required.

Discovery Algorithm

1. Attempt to parse the file as JSON. If it fails: not MFDB-related.
2. Read Format_Version and the filename.
3. If Format_Version == "104a" AND filename ends in ".mfdb.bejson": → This is a manifest.
4. If Format_Version == "104" AND "Parent_Hierarchy" key is present: → This is an entity file.
5. Otherwise: → Standalone BEJSON.

Relationships and Foreign Keys

MFDB does not enforce referential integrity. FK relationships are declared by convention: field naming (e.g., user_id_fk) and primary_key declarations in the manifest.

Validation vs. Standardization (v1.31 Distinction)

MFDB v1.31 enforces a strict conceptual separation between structural validity and architectural standardization.

• Validation (Structural Correctness): "Is the file a valid BEJSON/MFDB document?" Failure = Hard Error.
• Standardization (Architectural Compliance): "Does the database follow official conventions?" Failure = Warning.

The MFDB v1.3.1 Master-Slave Federation

Your environment is now successfully split into a tiered, federated node system designed to maximize AI context efficiency through "Structural Blindness" and "One-Way Awareness".

• Master Node: Acts as the authoritative registry. Has full visibility.
• Slave Node: Acts as the high-performance workspace. Structurally blind, relying on active communication protocols (One-Way Push, Inverse Drop-Zone Polling) and hardware-level atomic swaps.

MFDB-132: Session-Based Workspace Mounting (Chunked-104a)

The MFDB-132 specification collapses an entire federated database into a single, portable Chunked-104a document. Uses cryptographic sticky mounts (`.mfdb132_lock`) to instantly reuse existing workspaces without costly re-extractions if SHA-256 hashes match.

What MFDB Is Not

• Not a new BEJSON format version.
• Not a runtime database engine.
• Does not replace BEJSON 104db (which is for shipping tight relational data in a single file).

MFDB Validation Summary

MFDB Summary