diff --git a/public_html/admin/downloads/INFRASTRUCTURE-REFERENCE.md b/public_html/admin/downloads/INFRASTRUCTURE-REFERENCE.md
index e6f4217..cdbffd0 100644
--- a/public_html/admin/downloads/INFRASTRUCTURE-REFERENCE.md
+++ b/public_html/admin/downloads/INFRASTRUCTURE-REFERENCE.md
@@ -1,5 +1,5 @@
 # INFRASTRUCTURE REFERENCE — COMPLETE SYSTEM MAP
-**Last Updated:** 2026-07-01  
+**Last Updated:** 2026-07-02  
 **Owner:** Myron Blair — myronblair@outlook.com
 
 ---
@@ -511,6 +511,25 @@ journalctl -u jarvis-arc -f
 To re-deploy Arc Reactor from source:
 Use **Workers → Daemons → SETUP** in JARVIS admin (live log popup shows progress).
 
+### Planner: Tasks / Directives / Missions
+Admin UI sections backed by real schema + live API — verified working 2026-07-02 (created/read/deleted a test row in each, end-to-end).
+
+**Tasks** — simple to-do list, stored directly in `jarvis_db`.
+- Table: `tasks` (title, notes, category, priority [urgent/high/normal/low], status [pending/in_progress/done/cancelled], due_date, due_time)
+- API: `task_list` (GET), `task_save` (POST, **form-encoded**), `task_done` (POST), `task_delete` (POST)
+
+**Directives** — OKR-style goals with key results, stored directly in `jarvis_db`.
+- Tables: `directives` (title, description, category, status, priority, target_date) + `directive_key_results` (directive_id, title, current_value, target_value, unit) + `directive_links` (directive_id, link_type, link_id — links a directive to a task/etc.)
+- API: `directive_list`, `directive_get`, `directive_save` (POST, **JSON body** via `php://input`, id passed as `?id=` query param on update), `directive_delete`
+
+**Missions** — automation workflows, NOT stored in `jarvis_db` — proxied through **Arc Reactor** (port 7474) which owns the mission state.
+- Arc Reactor endpoints used by admin: `GET/POST /missions`, `GET /missions/{id}`, `GET /missions/{id}/runs`, `PUT/POST /missions/{id}`, `DELETE /missions/{id}`, `POST /missions/{id}/run`
+- JARVIS-side mirror tables exist (`missions`, `mission_runs`, `mission_steps`) but the admin panel reads/writes live via Arc Reactor's HTTP API, not directly against these tables
+- API: `mission_list`, `mission_get`, `mission_runs`, `mission_save` (POST, **JSON body**, id as `?id=` on update), `mission_delete`, `mission_run`, `mission_toggle`
+- If Arc Reactor is down, these calls return `{"error":"Arc Reactor unreachable"}` — check `systemctl status jarvis-arc` first
+
+As of 2026-07-02: all three tables are empty (0 rows) — features are fully functional, just unused so far.
+
 ### Deploy Pipeline
 ```
 Code edit → git push → GitHub webhook → /webhook.php (HMAC verified)
@@ -645,6 +664,18 @@ fs_cli -x "reloadacl"                           # reload ACL (safe)
 - **Covers:** PostgreSQL dump (gzip, ~29MB) + FreeSWITCH configs
 - **Restore:** 10-phase wizard in `restore.sh`
 
+### MSP360 Backup Status (Dashboard Integration)
+- **Client software:** MSP360 (CloudBerry) Backup CLI installed on all 6 hosts — PVE1, JARVIS (211), NovaCPX (110), Jellyfin (33), MediaStack (35), Homebridge (18)
+- **Storage target:** `NAS-MSPBackups` destination → Synology NAS CIFS share, mounted at `/mnt/nas-backups/MSPBackups`
+- **Mount reliability:** `/usr/local/bin/msp360-mount-ensure.sh` (cron `*/15 * * * *` on hosts using the NAS mount) — bind-mounts the MSPBackups subdir onto itself since MSP360's pre-flight `mountpoint` check fails on a subdirectory of a CIFS mount otherwise
+- **Collector:** `/usr/local/bin/backup-status-collect.sh` on PVE1 (runs via key-trusted root SSH — PVE1 is the only host with passwordless SSH to all 6 targets; other hosts use password auth via `sshpass`)
+  - Queries each host's plan via `cbb plan -l` (legacy v1 CLI — outputs `State:` / `Last result:` fields directly, unlike `cbbV2`/`cbbCommandLineV2` which needs `plan list -b` and different parsing)
+  - Writes `/tmp/backup-status.json`, then `scp`s it to `root@10.48.200.110:/home/webacct/public_html/downloads/backup-status.json`
+  - **Schedule:** daily `0 6 * * *` on PVE1 (`>> /var/log/backup-status-collect.log`)
+- **Dashboard card:** `web.orbishosting.com` "BACKUP STATUS" card (`index.html`) fetches `/downloads/backup-status.json` client-side (`loadBackupStatus()`), color-codes dots by `result` (green=Success, yellow=Warning, red=Fail, cyan=Running, gray=unknown)
+- **JSON schema:** `{"updated": "<ISO8601 UTC>", "hosts": [{"name","ip","state","result"}, ...]}`
+- **Known state (2026-07-03):** 5/6 hosts report `Warning`, Homebridge reports `Fail` — plan-level result, not investigated further; worth checking each host's MSP360 GUI/log for root cause if backups need to be trusted for restore
+
 ---
 
 ## 11. SSH QUICK REFERENCE