# Framework Definition for the Information Dynamics Compendium ## 1. Purpose This compendium aims to systematically explore, critique, and potentially develop an alternative framework for understanding reality, tentatively centered around Information Dynamics (IO). It proceeds incrementally, documenting specific concepts, critiques, principles, thought experiments, or analyses in distinct, modular files (referred to as "knowledge nodes" or simply "files"). This approach allows for flexible development and exploration without premature commitment to a fixed narrative structure like chapters. The ultimate goal is to build a body of rigorously documented thought that can be synthesized later to evaluate the coherence and explanatory power of the emerging framework(s). ## 2. File Naming Convention To ensure uniqueness, facilitate organization, and provide context, all files within this compendium shall adhere to the following naming convention: `####_[KeywordDescriptor].md` * **`####`**: A unique, zero-padded, 4-digit sequential number (e.g., `0000`, `0001`, `0002`, ...). This number indicates the chronological order of file creation and serves as the primary unique identifier (`id`). * **`_`**: An underscore separator. * **`[KeywordDescriptor]`**: A short (typically 1-3 words) descriptor using underscores instead of spaces, hinting at the file's core topic (e.g., `Define_Contrast_K`, `Critique_Naturalness`, `Photon_Mass_Paradox`). The base filename (e.g., `0000_Framework_Definition`) should always be included in the `aliases` metadata field for linking consistency. ## 3. File Content Structure and Metadata Each file must be a Markdown (`.md`) document suitable for use in Obsidian or similar editors. Each file must begin with a YAML frontmatter block enclosed between `---` lines, containing the following metadata fields: * `id`: (Required) The 4-digit number matching the filename. * `title`: (Required) A clear, human-readable title describing the file's content. * `aliases`: (Required) A list including, at minimum, the base filename (without `.md`). Other alternative names or keywords for linking or searching can be added (e.g., `[0001_Critique_Methodology, Methodological Dogma]`). * `tags`: (Required) A list of relevant keywords for thematic grouping and later synthesis (e.g., `[IO_Primitive, Ontology, Critique_Physics, meta]`). Use consistent tagging. * `related`: (Optional) A list of `id` numbers (e.g., `[000X, 000Y]`) pointing to other files directly relevant to the current one, helping to build a conceptual network. Ensure these IDs exactly match the target files. * `status`: (Required) Indicates the maturity of the content (e.g., `draft`, `review`, `stable`, `deprecated`). * `version`: (Required) Tracks the version of the content within *this specific file*, using a `Major.Minor` format (e.g., `1.0`, `1.1`, `2.0`). See Section 4 for details. * `author`: (Required) Name of the primary author or editor for this version. * `summary`: (Required) A concise, single-sentence summary of the core idea or purpose of the file. *(Note: `created` and `modified` timestamps are typically managed automatically by the file system or note-taking application and do not need to be manually included in the YAML block unless specifically required for external tracking.)* **Example YAML Structure:** ```yaml --- id: 0001 title: "Critique of Methodological Principles in Physics" aliases: [0001_Critique_Methodology, Methodological Dogma, Naturalness Critique] tags: [critique, physics, methodology, naturalness, unification, simplicity] related: [0000, 000X] # Link back to framework, link forward to specific principle critiques status: draft version: 1.0 author: Rowan Brad Quni summary: "Critically examines the epistemic status and track record of guiding principles like unification, simplicity, and naturalness in fundamental physics." --- ``` The body of the file follows the YAML frontmatter and should contain substantive exploration of the topic defined in the `title`, written in clear prose. Use standard Markdown formatting. Break down complex topics into sub-sections using Markdown headers (`##`, `###`, etc.). Aim for substantive development within each section (generally more than a single paragraph per major idea). Internal links to other files should ideally use the `id` or an alias, e.g., `[[00XX_KeywordDescriptor]]` or explicitly `(See file 00XX)`. ## 4. Versioning System Two levels of versioning will be employed: 1. **File-Level Versioning:** Managed by the `version` field in the YAML frontmatter. * Use `Major.Minor` numbering (e.g., `1.0`). * Increment `Minor` (e.g., `1.0` -> `1.1`) for minor edits, clarifications, adding examples, fixing typos, or slight expansions that do not change the core concept. * Increment `Major` (e.g., `1.3` -> `2.0`) for significant conceptual revisions, major restructuring, or fundamental changes to the argument or definition presented in the file. * Manually update the `version` field when making such changes. 2. **Compendium-Level Versioning (Git):** The entire collection of files must be managed within a Git version control repository. * Regular commits should be made, capturing discrete changes (new files, revisions). * Commit messages must be descriptive, indicating the nature of the change (e.g., "Add file 0015_Define_Mimicry", "Revise 0006 to v1.1 clarifying K/Δi distinction"). * Git tags (e.g., `v0.1`, `v0.2-draft`) should be used periodically to mark significant milestones or stable snapshots of the entire compendium. ## 5. Workflow The process for expanding the compendium is as follows: 1. **Identify Topic:** Determine the next concept, critique, principle, or analysis to be documented. 2. **Create File:** Assign the next available sequential `id`, choose an appropriate `KeywordDescriptor`, and create the `.md` file. 3. **Populate Metadata:** Fill in the required YAML frontmatter fields accurately (including the base filename in `aliases`). Set initial `version` to `1.0` and `status` typically to `draft`. 4. **Develop Content:** Write the substantive content, ensuring logical flow, clarity, and grounding in previous discussions or evidence where applicable. Reference related files using their `id` or alias. 5. **Review and Refine:** Check for logical consistency, clarity, and completeness regarding the specific topic. 6. **Update Related Links:** Ensure the `related` field is accurate and consider updating related fields in other relevant files. 7. **Commit:** Commit the new or modified file(s) to the Git repository with a clear commit message. 8. **Iterate:** Repeat the process, building the knowledge base node by node. Revise existing files as needed, manually incrementing their `version` number appropriately and committing the changes. ## 6. Future Synthesis This modular approach allows the overall structure to emerge organically. Once a critical mass of knowledge nodes exists, synthesis can occur by: * Analyzing connections revealed by `tags` and `related` links. * Creating dedicated "synthesis" files that integrate arguments from multiple nodes, citing them by `id` or alias. * Potentially organizing stable nodes into a more traditional chapter structure for a specific output or publication, using these files as the primary source material. This framework provides the structure for our collaborative exploration, ensuring documentation, versioning, and flexibility as we proceed.