TITAN · JARVIS · Genius — Master Architecture, Inventory & AWS Migration

Date: 2026-05-22 · Purpose: one document to understand the whole system, the inventory, the inconsistencies, and the plan to move scheduling to AWS so it's organized & maintainable.

---

1 · What the three things are (plain English)

TITAN = the brain + engine. Lives at F:/TITAN. Holds tiered memory, plans, 246 scripts, and 53 scheduled jobs. It's what does the work (research, newsletters, backups, audits, briefings).
JARVIS = the old front-end (jarvis.livegroweveryday.com). Being retired. 58 files still reference it. Successor = Genius.
Genius = the new cockpit / hub (genius.livegroweveryday.com). One page that surfaces TITAN's output: daily brief, task queue, dashboards, and links to every project. This is the single pane of glass.

One sentence: TITAN runs the jobs → writes results to S3 + local state → Genius displays them.

---

2 · Folder inventory

| Path | Role | In git |

|---|---|---|

| F:/TITAN/scripts | 246 Python scripts (engine) | titan-os |

| F:/TITAN/scheduled-tasks | 53 job definitions (SKILL.md + cron) | titan-os |

| F:/TITAN/knowledge | memory (hot/warm/cold/staging) | titan-os |

| F:/TITAN/plans | plans, audits, reports (incl. this) | titan-os |

| F:/TITAN/state | runtime state, sentinels, task lists | titan-os |

| F:/projects | monorepo: carlyle-demo, silentinfinity-leads, meditation, genius… | titan-projects |

| F:/dev | independent repos: hmtech-one-app, cloud8data-website… | per-repo |

| brand sites | cloud8data, hmtechsolutionsllc, onlovingconsciousness, spiritualaf, harnoorminhas | per-repo |

3 · Process inventory (where work runs today)

*Local (Windows Task Scheduler, \TITAN\): 53 jobs. Of these: ~4 need a browser (newsletter player screenshots), ~3 launch Claude Code (claude_cli_launcher --skill: daily-newsletter, daily-pa-email, inbox-watch), and ~40+ are pure Python cron** (data fetch → S3 publish).
AWS (already): 5 EventBridge rules (cloud8data-reminder, innerverse-mirror keep-warm/warmup, innerverse-nightly 3am, autoscaling), 24 Lambdas (capture, leads, magic-link SSO, innerverse, titan-*), 10 HTTP APIs, ~23 DynamoDB tables, 1 toy Step Function.
Key data flows:

1. Newsletter: research-indexer (05:00) → generators (12:15, live gather()) → ledger dedup → SES → archive/player.

2. Leads: brand forms → POST /leads / /capture → DynamoDB → leads.silentinfinity.com dashboard.

3. Genius brief: build_genius_brief reads MASTER-TASKS.md + HOT.md + cost log → injects into the cockpit + 4-hr digest.

4. Backup: hourly local→S3 (backup/ prefix, versioned).

4 · Inconsistencies found (and the fix)

1. Stale Genius queue (your report). Task state is fragmented across 4 files: state/MASTER-TASKS.md (fresh 5/22), state/PENDING.md (5/22), projects/PENDING.md (5/21, duplicate), state/titan-tasks-latest.json (5/16 — stale, the TodoWrite snapshot hasn't updated in 6 days). Genius reads MASTER-TASKS.md (fresh) but the 4-hr digest repeats old items because the reconciler that folds completed/new work into the canonical list isn't capturing this session's progress. → Fix: one canonical source (MASTER-TASKS.md), retire titan-tasks-latest.json + the duplicate projects/PENDING.md, and run the reconciler + brief on every Genius refresh.

2. Newsletter staleness — covered in NEWSLETTER-MASTER-AUDIT-2026-05-22.md (watchdog loop fixed; weekly windows + freshness guard pending).

3. Script sprawl — 246 scripts, ~20 newsletter scripts, JARVIS refs — covered in TITAN-JARVIS-GENIUS-CLEANUP-PLAN-2026-05-22.md.

4. AWS sprawl — 348 buckets (303 empty), 72 CloudFront (~30 redundant) — versioning done; deletion pending dry-run.

---

5 · AWS migration architecture (the major overhaul)

Principle: nothing runs locally except what physically needs the local machine (real-browser scraping, dev/test builds, things touching the F: drive directly). Everything else is serverless on AWS.

Target design

Cron jobs → EventBridge Scheduler + Lambda. Each pure-Python job becomes a Lambda; EventBridge Scheduler fires it on its cron. (~40 jobs.) Shared code → a Lambda layer.
Multi-step pipelines → Step Functions. The newsletter pipeline becomes one state machine: indexer → [generate per slug, freshness-gated] → audio → archive → SES, with retries/catch per step (replaces 5 overlapping local crons + the watchdog loop).
Browser/scrape jobs → Lambda + headless-Chrome layer, or Fargate. The ~4 screenshot/scrape jobs. (Or keep local if cheaper — your call per job.)
Agentic jobs (claude_cli_launcher --skill) → Fargate task or Lambda running the Claude Agent SDK. These need the agent runtime + skills; containerize once, schedule via EventBridge.
Data layer — the critical decision: TITAN's brain is local files on F:. For AWS compute to run jobs, the canonical data must be reachable. Recommended: promote S3 as the canonical store (memory/state/plans synced both ways) — the backup sync already exists; invert it so AWS jobs read/write S3 and the local machine syncs down for research/editing. (Alternative: EFS mounted to Lambda/Fargate — simpler migration, higher cost.)
Stays local (by design): web scraping needing a real browser/session, local dev + test builds, anything that edits F: interactively during a session.

Phased migration (safe, reversible)

Phase A — Foundation: one IaC stack (SAM or CDK), a shared Lambda layer (boto3 + titan helpers), an artifacts bucket, and S3-as-canonical for state. Migrate 2 low-risk jobs first (e.g., daily_token_audit, build_cost_page) and run them in parallel with local for a week to confirm parity.
Phase B — Cron fleet: move the ~40 pure-Python jobs to Lambda + EventBridge Scheduler, retiring each local task only after a parallel-run parity check.
Phase C — Pipelines: rebuild the newsletter chain as a Step Function (folds in the audit fixes).
Phase D — Agentic + browser: containerize the Claude-SDK jobs (Fargate) and the browser jobs (Lambda+Chromium or Fargate).
Phase E — Decommission: remove local Windows tasks; local keeps only research/dev/scrape.

Cost & risk

Lambda + EventBridge for ~40 short daily jobs ≈ pennies/month. Fargate agentic jobs are the main cost (per-run minutes). Net likely cheaper + far more reliable than the local box (which had the silent-watchdog and stale-data failures).
Risk: the data-layer flip is the hard part; everything else is mechanical. Do Phase A as a proof before committing.

---

6 · Recommendation / sequencing

1. Now: fix the Genius queue (consolidate task sources) — done alongside this report.

2. Next: Phase A foundation + migrate 2 jobs (proof of the pattern).

3. Then Phases B–E, plus the newsletter Step Function (which also lands the audit fixes).

4. In parallel (independent): build the 3 trading MVPs; finish the cleanup-plan archiving.

This report + the cleanup plan + the newsletter audit together are the full operating picture. The overhaul is real but mechanical once Phase A proves the pattern — and the end state is exactly what you asked for: everything in AWS, scheduled and observable, with local reserved for scraping and building.