Org System

The Org System is the canonical text-native operating layer for planning, execution, inventory, operational notes, and assistant context. It is designed to be readable and editable by humans while remaining structured enough to support automation, search, derivation, and publishing.

This document describes how the system works, how information is organized, how records should be routed, and how the internal operational layer relates to the published layer.

The system exists to provide a durable source of truth for ongoing work without relying on opaque tools, siloed applications, or chat history as the primary record.

Its goals are to:

• preserve operational truth in plain text
• support project execution and review
• keep inventory and requirements linked to real work
• maintain assistant continuity without turning memory into the primary database
• allow derived views, including public documentation, to be generated from a canonical base

The Org System covers:

• project records
• task tracking
• requirements and material needs
• inventory and location data
• operational journal/history
• decisions and rationale
• review queues and ambiguous captures
• assistant orientation and continuity references

It is not intended to replace every possible tool. Its role is to be the canonical, local-first operational layer around which other views and workflows can be built.

The system uses layered sources of truth.

The canonical Org tree is maintained in a Windows-backed location so it remains accessible from both native Windows tools and Linux/WSL environments.

• Windows canonical root: `C:\Users\mail\org`
• WSL path: `/mnt/c/Users/mail/org`
• Workspace `org/` path: symlink into that canonical tree

This arrangement allows the same files to be edited from multiple environments while still preserving a single canonical text tree.

Each major document class has a distinct job.

The system depends on sending information to the narrowest correct destination.

• Concrete executable work -> `projects/tasks.org`
• Ambiguous or incubating items -> `ops/review-queue.org`
• Inventory-only cleanup -> `inventory/review-queue.org`
• Work log / discoveries / progress -> `ops/journal.org`
• Durable decisions -> `ops/decisions.org`
• Stable operating context -> `MEMORY.md`
• Same-day continuity -> `memory/YYYY-MM-DD.md`
• Orientation / summary updates -> `ops/assistant-digest.org`

The routing rule is simple: avoid turning every note into a task, avoid turning every chat into memory, and avoid letting internal state drift into unstructured conversation.

The system uses lightweight structure rather than heavy schema enforcement.

The Org System intentionally distinguishes between internal operational content and curated published content.

The current publishing model is intentionally conservative.

• Internal project and ops records remain canonical.
• Curated public-facing Org documents are authored under `org/publish/`.
• Hugo consumes the curated published documents rather than reading internal project files directly.
• Site content is copied into the Hugo repository for deployment-safe publishing.

This creates a controlled boundary between:

• internal operational truth
• curated external documentation
• rendered public presentation

The current model is deliberately simple so the publishing workflow can be tested before a broader transformation model is defined.

The system is maintained through small, frequent, low-chaos updates rather than periodic large reorganizations.

Maintenance expectations include:

• log meaningful structural changes in the journal
• refresh the assistant digest when orientation changes
• promote ambiguous items through review queues instead of scattering them
• keep task and requirement ledgers aligned with real work
• update memory only when something is durable enough to matter later

The design goal is coherence over perfection.

The system is guided by a few consistent principles.

• local-first over cloud-dependent
• plain text over opaque storage
• canonical truth before derived views
• small reversible edits over large restructures
• human legibility over machine theatrics
• selective structure over compulsive over-modeling
• publication as a derived layer, not the source of truth

The current published Org workflow is intentionally minimal. It is expected to evolve.

Likely future directions include:

• a clearer mutation model from internal Org to external Org
• more explicit publishing conventions for curated documents
• richer derivation of site content from canonical sources
• tighter relationship between project records and public documentation
• more deliberate handling of private vs publishable sections

The system is not trying to solve every future problem immediately. It is trying to create a stable foundation that can evolve without rewriting the entire model.

This document is intended to be authoritative documentation for the Org System as an operational architecture. It should read as system documentation, not as a personal note or project blurb.