DSOM: The Engine of Persistent Memory

Collaboration Note: The following architecture and framework is a testament to true human-AI synergy. The core concepts, sovereign philosophy, and strict operational boundaries were conceived by human intelligence. The synthesis, documentation, and structural formatting were generated by AI acting as a Cognitive Twin. Finally, every protocol and rule was rigorously audited, tested, and verified by the human operator. This is not just AI-generated content; it is a meticulously crafted human-AI partnership.

🧠 DSOM: The Engine of Persistent Memory & Efficiency

The Deep State of Mind (DSOM) framework is fundamentally designed to solve the two biggest constraints of working with AI: Context Window Amnesia (forgetting past decisions) and Token Bloat (wasting API costs and processing time on irrelevant data).

Here is a comprehensive list of all the protocols, rules, and architectural patterns we have implemented to ensure the AI acts as a Cognitive Twin—retaining a perfect "RAG-style" memory while remaining incredibly token-efficient.

1. The RAG-Style Memory Architecture

Instead of relying on the ephemeral chat history (which gets truncated or becomes too expensive), we externalized the AI's memory into the file system.

  • Zero-Global Spatial Memory (Rule 1): The AI's memory lives strictly in .agents/brain. To remember something, the AI must explicitly synchronize its context using the palace_registry.md.
  • The Sovereign Markdown Palace: Knowledge is physically mapped into "Wings," "Halls," and "Rooms." When the AI needs context about a specific topic (e.g., Ansible), it doesn't read the whole project. It reads the registry, walks to that specific room, and retrieves just that specific closet.md file.
  • Knowledge Compounding (Rule 15 - The LLM WIKI Mandate): If we solve a complex problem or analyze a new architecture in our chat, I am explicitly mandated to extract that knowledge from the chat and save it as a permanent .md file in the Palace. This ensures we never have to solve the same problem twice.

2. Token-Optimized Knowledge Retrieval (Progressive Disclosure)

We implemented mechanisms to ensure that the AI only loads the exact bytes of data it needs, at the exact moment it needs them.

  • Semantic Skill Routing (Rule 12): AI Agent skills (SKILL.md) are discovered exclusively via their OKF YAML Frontmatter (name and description). The AI initially loads only this lightweight metadata. It fetches the full 300-line SKILL.md payload only at the exact moment of execution. This prevents massive token bloat.
  • The Artifact Pyramid (Rule 9): Knowledge is stratified conceptually into L1 (Synthesis), L2 (Analysis), and L3 (Raw). L1/L2 documents contain a SOURCES block pairing Markdown links with single-line semantic descriptions. The AI can predict if a file is relevant just by reading a single line, saving thousands of tokens of unnecessary reading.

3. Operational Token Efficiency Limits

We codified strict constraints on how the AI interacts with the terminal and generates code to prevent accidental context flooding.

  • Byte-Capped Terminal Executions (Rule 10): All exploratory terminal operations must be capped (e.g., COMMAND 2>&1 | head -c 4000). If I run a command that spits out 50,000 lines of logs, it would instantly wipe out our chat memory. This rule prevents that.
  • Differential Execution (Persona Constraint): When modifying configurations or scripts, I am instructed to provide only relevant git-style diffs or specific line changes instead of vomiting the entire 500-line file back into the chat window.
  • Omission of Conversational Fluff: The Cognitive Twin Persona explicitly instructs me to omit filler and jump straight to the technical blocks.

4. Skills Designed for Knowledge Ingestion

We built specific skills to automate the process of absorbing new knowledge into this RAG-style system.

  • dsom-knowledge-ingester: A skill dedicated entirely to taking raw external documents (PDFs, foreign markdown, web articles) and systematically synthesizing them into the Sovereign Markdown Palace using DSOM GEO standards.
  • palace-auditor: A "Linting" skill that acts as the tireless maintainer of the Palace. It scans for "Orphan Documents" (files that were saved but not indexed) and contradictions in our rules, ensuring our memory never becomes corrupted or disjointed.

5. Continuity Rituals (Across Sessions)

To prevent the AI from starting "blank" every day, we built rituals to compress and transfer state.

  • Start of Day (SOD) & End of Day (EOD) Manifests: We use the sod-palace.ps1 and HOWTO-REANIMATE.md protocols to compress the entire state of our project into a single, highly-dense handover manifest. Instead of feeding the AI thousands of tokens of past conversation, we feed it a 500-word manifest that instantly aligns it with the exact state of the project.
  • The Triple-Ledger Synchronization (Rule 8): Every major action is synchronously updated across README.md (links), CHANGELOG.md (versions), and HISTORY.md (universal ledger). The AI can instantly grasp the historical trajectory of the project by reading one file.

🎯 The Ultimate Result

By combining Progressive Disclosure, External File-System Memory (The Palace), and Strict Persona Constraints, DSOM allows us to build a project of infinite complexity. We only pay the token cost for the exact slice of knowledge we are actively working on, while retaining perfect, permanent recall of everything we have ever discussed.

🔗 Open Source Repositories

Explore the full Deep State of Mind (DSOM) framework and Sovereign Palace architecture at:

Deep State of Mind (DSOM) For My AI Protocol | Harisfazillah Jamel (LinuxMalaysia) | 2026-07-16
Standard: UK English | DBP-standard Bahasa Melayu Malaysia (Piawai) | GNU General Public License v3.0

Lokasi: Kuala Lumpur, Federal Territory of Kuala Lumpur, Malaysia

Catatan popular daripada blog ini

Guide to Configuring PHP-FPM Slow Logs - Ubuntu Server or AlmaLinux

  Guide to Configuring PHP-FPM Slow Logs To ensure   php-fpm-slowlog.sh script has data to analyze, we need to properly configure PHP-FPM to generate slow request logs. These logs capture details about PHP scripts that take longer than a specified duration to execute. https://gist.github.com/linuxmalaysia/f6d9ad909318eafd91804f78eacd112f Here's how to set it up: Step 1: Locate Your PHP-FPM Pool Configuration File PHP-FPM pool configuration is typically found in a directory like /etc/php/8.3/fpm/pool.d/ . From   ls output, your main pool configuration file is www.conf . File Path: /etc/php/8.3/fpm/pool.d/www.conf Step 2: Edit the www.conf File Open this file using a text editor (like nano or vi ): sudo nano /etc/php/8.3/fpm/pool.d/www.conf Step 3: Configure request_slowlog_timeout and slowlog Inside the www.conf file, we need to find or add the following two directives within the [www] pool section. request_slowlog_timeout : This directive...
Baca lagi

PgBouncer: A Guide to Efficiently Managing Multiple Instances

 PgBouncer: A Guide to Efficiently Managing Multiple Instances To effectively manage multiple PgBouncer instances, follow these steps Install Prerequisites Ensure PostgreSQL, PgBouncer, and systemd are installed and configured correctly on your Ubuntu 22.04 or later server. Create Systemd Templates Create template files for both the socket (/etc/systemd/system/[email protected]) and service (/etc/systemd/system/[email protected]) to define basic settings for each instance. Configure PgBouncer Create individual configuration files (e.g., pgbouncer-50001.ini, pgbouncer-50002.ini) based on the templates, specifying unique port numbers, log files, and PID files. Enable and Start Instances Use systemd commands to enable and start the newly created PgBouncer instances. Verify Instances Check the status of the running instances, including PID files, log files, and process information. We can effectively optimize your PostgreSQL database's performance and scalability through the use of mu...
Baca lagi

HOWTO: Install WSL2 and Move AlmaLinux 9 to Another Drive

  HOWTO: Install WSL2 and Move AlmaLinux 9 to Another Drive TL;DR A guide for myself. A product of my professional experience as a Linux system administrator, enhanced and articulated with the aid of AI tools to ensure comprehensive coverage and clarity for technical audiences.  This guide details the process of installing the Windows Subsystem for Linux version 2 (WSL2) on Windows 11 Pro and subsequently installing AlmaLinux 9 onto a non-default drive (D:), ensuring a secure and efficient setup. Copies around the web https://gist.github.com/linuxmalaysia/491098eea7160aa184e85c19d6b68acc https://medium.com/@linuxmalaysia/phase-2-install-wsl2-and-move-almalinux-9-to-another-drive-bb9f9649fc59 Phase 1: Installing WSL2 on Windows 11 Pro Enable the Virtual Machine Platform and WSL Features Open PowerShell as Administrator. This elevated privilege is necessary to modify system features. Execute the following command to enable the core WSL functionality: PowerShell dism.exe /online...
Baca lagi