BEJSON + MFDB Crash Course (v21)

<!-- BEJSON + MFDB Crash Course | Document v20 | MFDB Spec v1.31 -->
<!-- Format Creator: Elton Boehnen | https:/boehnenelton2024.pages.dev -->

# BEJSON + MFDB Crash Course
**Document Version 21 · MFDB Spec Version 1.31 · BEJSON Formats: 104 · 104a · 104db**  
Format Creator: Elton Boehnen · https:/boehnenelton2024.pages.dev

---



# 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 top-level keys:

JSON
COPY
{
  "Format": "BEJSON",
  "Format_Version": "104" | "104a" | "104db",
  "Format_Creator": "Elton Boehnen",
  "Records_Type": [ ... ],
  "Fields": [ ... ],
  "Values": [ [ ... ], [ ... ], ... ]
}


---

## 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.

---

## Version Differences

### BEJSON 104 – Single Record Type, Full Types

* 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.
* Ideal for homogeneous, high-throughput data such as logs, metrics, or archives.

Example:

JSON
COPY
{
  "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]
  ]
}


---

### BEJSON 104a – Primitive Types + Custom Metadata

* 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.
* Best suited for configuration files, health checks, or simple log data.

Example:

JSON
COPY
{
  "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]
  ]
}


---

### BEJSON 104db – Multi-Entity Lightweight Database

* 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.
* 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. This is a convention and not strictly enforced by the BEJSON specification.

Example:

JSON
COPY
{
  "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". If a timestamp field is desired across multiple entities, it must be defined separately for each entity with consistent naming, or the duplication must be accepted. Each field is strictly owned by one entity.


### In certain cases 104db might be superior to SQL lite:
- 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, and that 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.

---

## Validation Summary

A BEJSON document is considered valid if it adheres to the following criteria:

* Valid JSON syntax.
* All six mandatory top-level keys are present with their correct values.
* Format_Creator must be precisely "Elton Boehnen".
* The Fields structure is correct, and no duplicate field names exist.
* The length of every record in Values equals the length of the Fields array.
* The type of each value matches its declared type in Fields (with null always being an allowed value).
* Version-specific rules:
* 104: Requires a single record type, allows complex types, and forbids custom headers (except for Parent_Hierarchy).
* 104a: Requires a single record type, allows only primitive types, and permits custom headers for file-level metadata (these must be PascalCase and not conflict with the six mandatory keys).
* 104db: Requires two or more record types, mandates that every field (except the Record_Type_Parent discriminator field itself) has a Record_Type_Parent assignment, forbids custom headers, and requires null for non-applicable fields.

---

## 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 to preserve positional integrity for existing parsers.
* Use null (rather than an empty array or object) for truly missing data, unless an empty state carries specific meaning.
* Manage your application schema version independently from Format_Version:
* For 104a / 104db: Use a custom header like Schema_Version (e.g., "v1.0").
* For 104: Custom headers are forbidden; embed the version within the Records_Type string (e.g., ["SensorReading_v1_0"]) or manage it externally.
* Schema changes: Appending fields is generally safe (minor change). Removing or retyping a field constitutes a breaking change (major change).
* For large datasets, consider splitting data into multiple complete BEJSON files.
* Encrypt sensitive files both at rest and during transit.
* In 104db, use the _fk suffix on foreign key fields (this is a convention, not enforced by the specification).
* The Event/Audit entity pattern: In 104db, define a dedicated "Event" entity within Records_Type to implement audit trails. Link it to other entities using fields like related_entity_id_fk, and store before/after state in a change_details field (of type object).

---

## Summary of Version Capabilities

| Feature | BEJSON 104 | BEJSON 104a | BEJSON 104db |
| :---------------- | :---------------------- | :------------------------ | :---------------------- |
| Primary Use | High-throughput Logs | Configs, Metrics | Multi-Entity Database |
| Record Types | Single (1) | Single (1) | Multiple (2+) |
| Custom Headers | ❌ Forbidden\* | ✅ Allowed (File Meta) | ❌ Forbidden |
| Data Types | Complex (Array/Object) | Primitives Only | Complex (Array/Object) |
| Discriminator | N/A | N/A | Record_Type_Parent |

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

---

This document comprehensively covers all essential rules and provides examples necessary to fully understand, generate, validate, and effectively use any BEJSON variant.

https:/boehnenelton2024.pages.dev
DBG

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. Every file in an MFDB is a fully
valid standalone BEJSON document. MFDB adds meaning through file naming, a key
field (Parent_Hierarchy), and a manifest registry.

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. The manifest and its entity files together form one
complete MFDB database.

---

Architecture

An MFDB database on disk:

  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 data/ subdirectory is the standard default. Any relative path is allowed
as long as it is recorded accurately in the manifest and the Parent_Hierarchy
resolves correctly. Relative paths must not escape the database root.

---

The Manifest File

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

Fixed values required by MFDB:
  Records_Type must be exactly: ["mfdb"]
  Format_Version must be: "104a"
  Format_Creator must be: "Elton Boehnen"

Standard custom headers (PascalCase, per 104a rules):
  MFDB_Version    string   MFDB spec version. Current value: "1.31". Required.
  DB_Name         string   Human-readable database name. Required.
  DB_Description  string   Short description of the database. Optional.
  Schema_Version  string   Application schema version (semver recommended). Optional.
  Author          string   Author name. Optional.
  Created_At      string   ISO 8601 UTC creation timestamp. Optional.
  Network_Role    string   Federation role: "Master" or "Slave". Optional (v1.31).

Custom headers must not collide with any of the 6 mandatory BEJSON keys.
MFDB_Version and DB_Name are treated as required standard headers.

Fields — required:
  entity_name    string   Unique name of the entity (e.g. "User"). Cannot be null.
  file_path      string   Relative path from the manifest directory to the entity
                          file (e.g. "data/user.bejson"). Cannot be null. Must be
                          unique across all records.

Fields — standard optional (include all if present, always in this order):
  description    string   Human-readable description of the entity.
  record_count   integer  Advisory count of records in the entity file. May drift.
                          Not enforced. Kept in sync by tooling, not the spec.
  schema_version string   Entity-level schema version. Optional per entity.
  primary_key    string   Field name of the entity's primary key (e.g. "user_id").
                          Used by FK resolution tooling. Not enforced by the spec.

No other custom fields in the manifest Fields array are defined by MFDB 1.0.
Applications may add fields beyond the standard set; they must follow BEJSON
104a positional rules and must be documented at the application level.

Manifest record constraints:
  entity_name must be unique across all records (no two entities share a name).
  file_path must be unique across all records (one file per entity).
  entity_name and file_path must not be null in any record.
  Every file_path must resolve to a file that exists on disk.

Example manifest:

{
  "Format": "BEJSON",
  "Format_Version": "104a",
  "Format_Creator": "Elton Boehnen",
  "MFDB_Version": "1.31",
  "DB_Name": "StoreFront",
  "DB_Description": "E-commerce product and order database",
  "Schema_Version": "1.0.0",
  "Author": "Elton Boehnen",
  "Created_At": "2026-04-14T00:00:00Z",
  "Records_Type": ["mfdb"],
  "Fields": [
    {"name": "entity_name",    "type": "string"},
    {"name": "file_path",      "type": "string"},
    {"name": "description",    "type": "string"},
    {"name": "record_count",   "type": "integer"},
    {"name": "schema_version", "type": "string"},
    {"name": "primary_key",    "type": "string"}
  ],
  "Values": [
    ["User",    "data/user.bejson",    "Registered users",   3, "1.0", "user_id"],
    ["Order",   "data/order.bejson",   "Customer orders",    5, "1.0", "order_id"],
    ["Product", "data/product.bejson", "Product catalogue",  8, "1.0", "product_id"]
  ]
}

---

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.

Fixed values required by MFDB:
  Format_Version must be: "104"
  Format_Creator must be: "Elton Boehnen"
  Records_Type must contain exactly one string — the entity name — and it must
    match the entity_name registered for this file in the manifest exactly
    (case-sensitive).
  Parent_Hierarchy must be present and must be a relative path from the entity
    file's own directory back to the manifest file. This value enables tools to
    discover the owning manifest without any external configuration.

Parent_Hierarchy is a relative path, not an absolute path.
  Entity in data/user.bejson pointing to root manifest: "../104a.mfdb.bejson"
  Entity at root level pointing to root manifest: "104a.mfdb.bejson"
  Parent_Hierarchy is always from the entity file's directory, never the DB root.

Records are dense. Unlike BEJSON 104db which null-pads fields across entity
types in a single file, MFDB uses one file per entity type. Records inside an
entity file should have no structurally-motivated null padding. A null value in
an entity record means the data is genuinely absent, not that the field belongs
to a different entity.

BEJSON 104 allows complex types (array, object). These are valid in entity files.
No custom top-level keys. Parent_Hierarchy is the only built-in exception key.

Example entity file (data/user.bejson):

{
  "Format": "BEJSON",
  "Format_Version": "104",
  "Format_Creator": "Elton Boehnen",
  "Parent_Hierarchy": "../104a.mfdb.bejson",
  "Records_Type": ["User"],
  "Fields": [
    {"name": "user_id",    "type": "string"},
    {"name": "username",   "type": "string"},
    {"name": "email",      "type": "string"},
    {"name": "created_at", "type": "string"},
    {"name": "active",     "type": "boolean"}
  ],
  "Values": [
    ["U01", "alice", "alice@example.com", "2026-01-01T00:00:00Z", true],
    ["U02", "bob",   "bob@example.com",   "2026-01-02T00:00:00Z", true],
    ["U03", "carol", "carol@example.com", "2026-01-05T00:00:00Z", false]
  ]
}

Example entity file (data/order.bejson):

{
  "Format": "BEJSON",
  "Format_Version": "104",
  "Format_Creator": "Elton Boehnen",
  "Parent_Hierarchy": "../104a.mfdb.bejson",
  "Records_Type": ["Order"],
  "Fields": [
    {"name": "order_id",     "type": "string"},
    {"name": "user_id_fk",   "type": "string"},
    {"name": "total",        "type": "number"},
    {"name": "placed_at",    "type": "string"},
    {"name": "items",        "type": "array"}
  ],
  "Values": [
    ["ORD01", "U01", 49.99,  "2026-02-01T10:00:00Z", ["P01","P03"]],
    ["ORD02", "U02", 120.00, "2026-02-03T14:30:00Z", ["P02"]],
    ["ORD03", "U01", 9.99,   "2026-02-10T09:15:00Z", ["P04"]]
  ]
}

---

Discovery Algorithm

A tool encountering any .bejson file can identify its MFDB role:

  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 (not part of any MFDB).

The discovery algorithm is file-local. No directory scanning required.
An entity file with Parent_Hierarchy present but pointing to a non-existent
manifest is an orphan — it is invalid as MFDB even though it is valid BEJSON 104.

---

Relationships and Foreign Keys

MFDB does not enforce referential integrity. FK relationships are declared by
convention and surfaced to tooling via two mechanisms:

  1. Field naming — FK fields end in _fk (e.g. user_id_fk, product_id_fk).
     This signals to tools that the field references a primary key elsewhere.

  2. primary_key declaration in the manifest — the primary_key field for an
     entity names the field that other entities' _fk fields reference.

Resolution rule for tooling (not enforced by spec):
  A field named X_id_fk in entity A is assumed to reference the entity whose
  primary_key in the manifest is X_id, or whose entity_name lowercased appears
  in the FK field name. Tooling should treat unresolved FKs as warnings only.

FK values in records must satisfy the declared type (typically string or integer).
null is valid for any FK field — it represents no relationship.

Joins between entity files are performed by the application or tooling layer.
MFDB provides no join syntax — it provides the structural signals (_fk suffix,
primary_key declaration) for tools to perform joins at runtime.

---

Validation Rules

Level 1 — Manifest validation:
  File exists and is valid BEJSON 104a.
  Records_Type is exactly ["mfdb"].
  Fields include entity_name and file_path.
  No record has null entity_name or null file_path.
  entity_name values are unique across all records.
  file_path values are unique across all records.
  Every file_path resolves to an existing file on disk.

Level 2 — Entity file validation (per entity):
  File is valid BEJSON 104.
  Parent_Hierarchy key is present.
  Parent_Hierarchy resolves to an existing manifest file.
  Records_Type contains exactly one string.
  That string matches the entity_name in the manifest record for this file.
  Manifest file path to this entity matches this entity's actual path
    (bidirectional check — manifest → entity and entity → manifest agree).

Level 3 — Database-level validation:
  All Level 1 and Level 2 checks pass for all entities.
  record_count mismatch between manifest and actual file row count: warning only.
  FK fields with no resolvable primary_key target: warning only (strict mode).

Errors are hard failures. Warnings are advisory and do not invalidate the database.

---

Error Code Ranges (standard)

  1–15    BEJSON Validator errors (BEJSONValidationError)
  20–27   BEJSON Core errors (BEJSONCoreError)
  30–49   MFDB Validator errors (MFDBValidationError)
  50–69   MFDB Core errors (MFDBCoreError)

MFDB Validator error codes (30–49):
  30  Not a manifest
  31  Not an entity file
  32  Manifest Records_Type invalid
  33  Entity file not found (path resolution)
  34  Entity name mismatch (Records_Type vs manifest)
  35  Duplicate entry (entity_name or file_path)
  36  Missing Parent_Hierarchy
  37  Manifest file not found
  38  Bidirectional path check failed
  39  FK unresolved (strict mode)
  40  Missing required field in manifest (entity_name or file_path)
  41  Null in required field (entity_name or file_path)

---

---

Validation vs. Standardization (v1.31 Distinction)

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

1. Validation (Structural Correctness):
   - Scope: "Is the file a valid BEJSON/MFDB document?"
   - Enforced by: lib_mfdb_validator.py.
   - Criteria: Proper JSON syntax, mandatory BEJSON keys present, positional 
     integrity (Values match Fields length), Parent_Hierarchy resolving, and 
     bidirectional path verification between manifest and entity.
   - Failure result: Hard Error (Database is considered "Broken").

2. Standardization (Architectural Compliance):
   - Scope: "Does the database follow the official MFDB conventions?"
   - Enforced by: Standard-aware tooling and architectural audits.
   - Criteria: Naming conventions (snake_case fields, PascalCase entities), 
     Key standards (_id PKs and _fk foreign keys), and Federation Protocols 
     (Master/Slave headers and registry presence).
   - Failure result: Non-Standard Warning (Database is "Valid but Non-Standard").

---

Standardization Protocols (Architectural Conventions)

Naming Conventions:
  Manifest filename:    104a.mfdb.bejson (Invariant)
  Entity filenames:     <entity_name_lowercase>.bejson
                        Multi-word entities: snake_case (e.g. order_item.bejson)
  Entity field names:   snake_case (inherited from BEJSON best practices)
  Primary key fields:   <entity_name_lower>_id (e.g. user_id, order_id)
  Foreign key fields:   <target_pk_field>_fk (e.g. user_id_fk, product_id_fk)
  Entity names:         PascalCase string (e.g. "User", "OrderItem")
  DB_Name header:       Human-readable string, no format restriction
  Schema_Version:       Semver recommended (e.g. "1.0.0")
  MFDB_Version:         "1.31" for the current specification

Federation Protocols:
  MFDB v1.31 standardizes distributed database roles via specific markers.
  1. Network_Role Header: "Master" (Authoritative) or "Slave" (Replica).
  2. ConnectedSlave Registry: A standardized entity in Global/Master nodes to 
     track network topology (label, url, role, status, supported_entities).

---

Validation Rules (Structural Requirements)

  - Keep the manifest at the database root. Do not nest it inside subdirectories.
  - Entity files default to the data/ subdirectory. Flat root placement is allowed
    but not recommended for databases with many entities.
  - Always write files atomically (write to temp, rename). Partial writes corrupt
    the database. This is especially critical for the manifest.
  - After any write operation that changes row count, sync record_count in the
    manifest. Treat it as advisory — never rely on it for correctness in reads.
  - Add new fields only at the end of an entity's Fields array. Inserting or
    removing fields mid-array breaks positional integrity for all existing records.
  - Schema changes: appending a field is a minor (safe) change. Removing,
    retyping, or reordering fields is a breaking (major) change. Increment
    Schema_Version accordingly.
  - Use null for genuinely absent values. Do not use empty string as a null
    substitute. Do not use empty array or empty object for missing scalar data.
  - Use PK/FK naming conventions even if you do not use relational tooling.
    It costs nothing and enables future tooling.
  - Do not store sensitive data in plaintext. Encrypt at rest and in transit.
  - For large entities (thousands of records), consider splitting into multiple
    MFDB databases rather than a single entity file with unbounded growth.
  - An MFDB export package (zip) should include the manifest at the root and all
    entity files at their declared relative paths. The zip should be extractable
    and immediately valid without path adjustment.
  - Validate bidirectionally on load, not just on create. File moves break
    Parent_Hierarchy silently.
  - Do not allow two manifest files in a single database directory. One manifest
    per database is the invariant.

---

What MFDB Is Not

  - MFDB is not a new BEJSON format version. There is no Format_Version "mfdb".
  - MFDB is not a query language or a runtime database engine. It is a file
    organization and naming convention with a manifest registry.
  - MFDB does not replace BEJSON 104db. 104db puts multiple entity types in one
    file with null-padding. MFDB puts each entity type in its own file with no
    padding. Choose based on use case: 104db for small, tightly coupled datasets
    that ship as a single file; MFDB for larger, independently writable entities.
  - MFDB does not enforce referential integrity. FK conventions are advisory.

---

Validation Summary

  | Check                            | Level  | Hard/Warn |
  |----------------------------------|--------|-----------|
  | Manifest is valid BEJSON 104a    | 1      | Hard      |
  | Records_Type == ["mfdb"]         | 1      | Hard      |
  | entity_name and file_path fields | 1      | Hard      |
  | No null entity_name / file_path  | 1      | Hard      |
  | Unique entity_name and file_path | 1      | Hard      |
  | All file_paths resolve on disk   | 1      | Hard      |
  | Entity is valid BEJSON 104       | 2      | Hard      |
  | Parent_Hierarchy present         | 2      | Hard      |
  | Parent_Hierarchy resolves        | 2      | Hard      |
  | Records_Type single-entry match  | 2      | Hard      |
  | Bidirectional path check         | 2      | Hard      |
  | record_count accuracy            | 3      | Warning   |
  | FK target unresolved (strict)    | 3      | Warning   |

---

Summary

  | Feature              | MFDB                                    |
  |----------------------|-----------------------------------------|
  | Manifest format      | BEJSON 104a (104a.mfdb.bejson)          |
  | Entity format        | BEJSON 104 (one file per entity)        |
  | Back-reference key   | Parent_Hierarchy (relative path)        |
  | Records per file     | Dense (no null-padding for schema gaps) |
  | FK enforcement       | None — convention only (_fk suffix)     |
  | Custom headers       | Manifest only (104a rules apply)        |
  | Complex types        | Allowed in entity files (BEJSON 104)    |
  | Multi-entity in one  | No — use BEJSON 104db for that          |
  | Spec version         | MFDB_Version: "1.31"                     |

### 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".

**1. Node Roles & The `Network_Role` Standard**
Instead of refactoring your core libraries to look for a new key, your `104a.mfdb.bejson` manifests correctly use the **`Network_Role`** header to define their topological status as either "Master" or "Slave".
*   **Master Node (Administrative Layer):** Acts as the authoritative registry ("The Truth"). It has full visibility and polling access to all connected Slaves, handling global policy distribution and long-term data distillation.
*   **Slave Node (Context Window):** Acts as the high-performance operational workspace. It is **structurally blind**, meaning it operates without any hardcoded paths to the Master and lacks read-access to the Master's archives, keeping the active context window completely lean.

**2. Active Communication Protocols**
To keep the Slave blind while keeping the system synchronized, your architecture now relies on two unidirectional data flows:
*   **One-Way Push (Log Distillation):** Your `initialization_watcher_service` allows the Slave node to autonomously truncate its local logs and push the metrics up to the Master's polling directory.
*   **Inverse Drop-Zone Polling (Atomic Updates):** When the Master needs to enforce a new policy or configuration, it formats the update as a BEJSON 104a document and pushes it directly into the Slave's local directory (e.g., `BEJSON_Core/Data/`). It uses an OS-level atomic file swap (`os.rename`) to instantly replace the active file, preventing partial-read crashes. The blind Slave simply polls its own directory to ingest the updates.

By completing this update while keeping the `Network_Role` key, you have successfully secured the v1.3.1 strategic benefits: **Zero-Bloat Context** (administrative scaffolding is hidden from the AI), **Atomic Integrity** (hardware-level protection for updates), and **Scalable Silos** (allowing your Master to easily control multiple portable environments).