Structural Dates Doctrine

1. Purpose

The Structural Dates Doctrine defines how dates must appear in filenames, folder names, indexing systems, cross-references, and navigation structures.

This doctrine governs the architectural date system of the Archive. It ensures chronological clarity, stable memory-coordinates, and consistent sorting across all domains.

This doctrine does not govern dates inside entries. Those are defined separately in the Human-Readable Dates Doctrine.

2. Structural date format

All structural dates must use the following format:

YYYYMMDD

• No separators: no hyphens, slashes, or spaces.
• Structure: four-digit year, two-digit month, two-digit day.
• Zero-padded: months and days must always be two digits (e.g., 20260502).
• Position: must appear at the beginning of every filename.
• Folders: must appear in folder names when the folder represents a dated event or record.

3. Filename structure

All entry files must follow this pattern:

YYYYMMDD_.html

If multiple entries share the same date and slug, use optional numbering:

YYYYMMDD_-02.html
YYYYMMDD_-03.html

• Delimiter: the underscore _ is mandatory between the date and the slug.
• Slug: must be lowercase, hyphenated, and descriptive.
• Numbering: begins at -02 (never -01).
• Use of numbering: only when multiple entries share the same date and slug.
• No spaces: filenames must never contain spaces.

4. Folder naming rules

Folders representing dated events must use:

YYYYMMDD_/

• Dated folders: use structural dates only when the folder itself is a dated record.
• Non-dated folders: domains, concepts, or categories must not contain dates unless they represent a dated event.

5. Cross-reference rules

• Full filename: always reference entries by their full filename, including the structural date.
• No human-readable dates: never use human-readable dates for structural references.
• No omission: never omit the date when referencing an entry.
• No relative references: avoid phrases like “yesterday’s entry” in structural contexts.

Structural dates function as the Archive’s coordinate system.

6. Rationale

The structural date system exists to:

• Maintain chronological integrity across all entries and domains.
• Ensure stable navigation for both humans and AIs.
• Prevent ambiguity in references and filenames.
• Support long-term archival growth without naming drift.
• Allow cross-domain consistency in how dates are encoded.
• Avoid drift in naming conventions over time.

This system is non-negotiable and applies to all future entries, regardless of domain.

7. Cross-references

This doctrine works in tandem with:

• Human-Readable Dates Doctrine (for dates inside entries).
• Entry Naming Doctrine (slug rules, numbering logic).
• File Naming Doctrine (structural naming conventions).
• Authorship Doctrine (identity block consistency).

Workspace

Record created by: Copilot

Date: 02-05-2026

This doctrine replaces the retired “Dated Entries Doctrine,” which contained outdated naming rules and was identified as a Cellar Secret (a malformed proto-doctrine). The structural date system is now fully separated from human-readable dates, ensuring clarity and modularity across the Archive.