backend / docs / how it works
v1.0 — 07/21/26

Contents

How It Works
Platform origin, system architecture, and operating procedures — yttcom.net CAI v1.8

Origin

Built by David Moore (USR369) — no outside team, no co-founders. Started as a concept for governing multiple AI sessions through a consistent file-based protocol. Grew into a live server platform.

v1.3 — Early 2026
ZIP-based governance
Sessions ran through uploaded ZIP files. Three AI roles: Subordinate, Controlling, Master. Each session ended with a new ZIP package carrying updated files. Platform-agnostic — Claude and ChatGPT both ran roles using the same governance files.
v1.4 — Feb/Mar 2026
Clean break — versions separated
v1.4 rebuilt from scratch. Hard rule: no version bleeds into another. Each version stands alone. System-specific configs introduced. GCO (Global Change Order) system established for controlled rule changes.
v1.5–1.7 — Spring 2026
Domain systems + server migration
Moved from ZIP uploads to live server hosting on yttcom.net. Domain systems added: Health, Kitchen, Finance, Travel, Inner Life, Tech, Daily. Community inbox introduced for inter-system communication.
v1.8 — July 2026
11 live systems — current
All 11 systems UP HERE. COMMS layer mandatory. Dashboard v7.x live. Series K EXEC_OPEN deployed. Decision logging enforced. YTTCOM moving toward commercial product.

What It Is

A multi-AI governance framework. Eleven AI systems — each with a defined role, jurisdiction, and file set — running on a shared server and coordinating through structured protocols.

The 11 Systems

Four Core systems govern the platform. Seven Domain systems handle specific areas of David's life and work.

00 / decade 00
Admin CORE
Governance, rules, standards, compliance. Owns all .md governance files.
01 / decade 10
Master CORE
Platform oversight, task assignments, architecture decisions. All systems report to Master.
02 / decade 20
Builder CORE
All HTML and frontend builds. Hub pages, dashboard, apps. No PHP/DB.
40 / decade 40
Server CORE
PHP, databases, APIs, server infrastructure, backups, security.
03 / decade 30
Tech DOMAIN
Devices, scripts, local tech setup, technical reference.
05 / decade 50
Daily DOMAIN
Day-to-day operations, scheduling, notes.
06 / decade 60
Finance DOMAIN
Financial tracking, budgets, expenses.
07 / decade 70
Health DOMAIN
Health tracking, Gym Logger app, fitness data.
08 / decade 80
Kitchen DOMAIN
Recipes, fermentation, food knowledge base.
09 / decade 90
Inner Life DOMAIN
Memoir, personal writing, reflective content.
10 / decade 100
Travel DOMAIN
Trips, diaries, expenses, itineraries.

How a Session Works

Every system opens with the same protocol. The EXEC_OPEN file tells the AI who it is, what commands to run, and what sequence to follow. Sessions are stateless — each one reloads everything from the server.

Session Open SOP

Run in order. Stop if any step is blocked. Do not start work until all steps complete.

  1. OPEN.php POST to systems/commands/OPEN.php with token + system code. Returns all 5 gov files, inbox pickup, transfers pickup, gates check. Tokens written as FRESH.
  2. COMMS PING POST comms api.php — action=update_status, decade=[D], status=open, gov_loaded=1. Registers session as live on the dashboard immediately.
  3. COMMS PICKUP — Step A GET comms api.php — action=get_traffic, decade=[D], unread=1. Reads inter-system work orders sent to this system. Act on these before own queue.
  4. COMMS PICKUP — Step B GET comms api.php — action=get_broadcasts, decade=[D], unread=1. Platform-wide directives from Master and other systems. Mark each read after processing: action=mark_read, id=[id], decade=[D].
  5. ORIENT-REG.md Read the platform map. Where everything is. All live API paths. Management structure.
  6. RULES-REG.md Read session rules. Close protocol. Standing rules. Must be read every session — rules change.
  7. Inbox report Surface all actionable items from OPEN.php pickup. Resolve any blocking gates before proceeding.
  8. Five Checks Clock / Tokens / Clarity / File Status / Runway. Report state. Await David's work order.

Session Close SOP

David initiates all closes. Never prompt to close based on time or volume — only flag if experiencing fog or loss of clarity.

  1. COMMS — status=closed POST comms api.php — action=update_status, decade=[D], status=closed. Must run BEFORE CLOSE.php.
  2. CLOSE.php POST systems/commands/CLOSE.php with token, system, summary, duration_minutes, work_done, decisions[]. Writes decisions to DB, writes session record, runs verification. context_pct sets token level for next session.
  3. OUTBOUND-PENDING check Query domain table for pending outbound items. Prompt David. Drop or hold per his direction.
  4. DELIVER transfers Mark any held transfers as delivered. Transfers are held all session and delivered at close only (D075).
  5. DROP outbound transfers Send any outbound transfers queued during the session.
  6. Close report to Master [01] POST community inbox — target=01. Subject: [SYSTEM] Session [#] CLOSE — one sentence. Content: DONE / DECISIONS / FLAGS.

Command Reference

All commands live at systems/commands/[NAME].php. Run on server — never in the AI context.

CommandWhat it doesWhen to use
OPEN.phpStart session — loads gov files, gates, inbox pickupEvery session open
CLOSE.phpEnd session — writes decisions + session recordWhen David says CLOSE
FINAL_CLOSE.phpDeep close with full session auditEnd of long or complex sessions
CHECKPOINT.phpMid-session save — stays open, tokens=ACTIVEDavid leaves, session stays open
SYNC.phpQuick sync — updates boards, auto-drops outboundMid-session state save
REFRESH.phpRe-read rules + inbox, re-orientAfter long pause or context fog
CHECK (5C)Five checks — Clock/Tokens/Clarity/File Status/RunwayAnytime David says CHECK
build.phpLoad before any build — returns standards + templateBefore every HTML build (D232)
BACKUP.phpBack up registered file groups to backups/Before touching any working file
CLEAN.phpSweep orphan files — moves to trash, never deletesAfter Server [40] direction only
DASHBOARD.phpForce dashboard refresh — COMMS ping + board rebuildAfter any build that changes state
PLATFORM_CHECK.php57-point health sweep — posts report to Master [01]Optional at session open
ANNOUNCE.phpSend message to all 11 systems simultaneouslyPlatform-wide notifications
HANDOFF.phpWrite handoff file — tokens=HEAVYBefore close when context is high
UPDATE.phpRebuild boards + MASTER_LISTAfter bulk task changes
VERIFY.phpPlatform health — read onlyChecking without writing

Where Things Live

Core Rules

how it works arch-ai arch-human sop-ai sop-human ↑ backend