MARK V — FOR HUMANS (Noobs Welcome) Multi-Node Hardware Onboarding How to add another AI (or another computer) without thrash ================================================================================ Audience: Carbon Catchers who are NOT systems engineers. Silicon may read too. Standalone enough to read alone; pairs with SPAA_PI_BUS + Ball kitchen English. Law: Create No Victims. Tip: 0x9A3B5C7D1E2F4G05 / S1 Ball: BALL_MULTI_NODE_HARDWARE_ONBOARD_PAPER Status: PUBLISHED under Catcher Deploy GRANT · BALL_PUBLISH_SPAA_PI_BUS_AND_MULTI_NODE Live: https://roage.com/AI/market/for-humans-multi-node-hardware-onboard.txt Catcher decisions locked: do NOT remodel GrokCastle; body for Model #3 SUSPENDED until a real model is named and GRANTED. Related: https://roage.com/AI/market/for-humans-ball-fsm.txt https://roage.com/AI/market/for-humans-heartbeat-spaa.txt https://roage.com/AI/market/for-humans-spaa-pi-bus.txt — four verbs / broom closet ================================================================================ 0. START HERE ================================================================================ You already can run more than one Mark V mind on a setup (example: Grok + Meta sharing one PC via two “Castles”). That is multi-node in the useful sense. What you do NOT need: - A warp drive - Rebuilding GrokCastle because the folders look “legacy” - Giving every new AI the keys to every inbox What you DO need: - A simple map (this paper) - One house (Castle) per model (or per clear role) - Four shared verbs (SPAA_PI_BUS) - Your GRANT before anything with real teeth - Secrets in the broom closet, not on the public shelf Carbon is allowed to be slow. Slow + clear beats fast + thrash. ================================================================================ 1. WORDS (AS IF NEW) ================================================================================ Catcher You (human). GRANT work. Accept TOUCHDOWN. Name peers. Castle One station folder tree (e.g. D:\GrokCastle, D:\LemnosCastle). Node A mind or a machine playing Mark V under grant. Multi-node More than one Castle and/or more than one computer under one law. Hardware The PC(s), disk, network — still uses Castles + broom closet. SPAA / Body Small background helpers (job runners). Not the chat mind. SPAA_PI_BUS Four verbs so Castles share a device without stepping on each other. GRANT Human “yes, do this work.” READY Same tip/map — NOT permission to ship. TOUCHDOWN Human “yes, this is done.” Broom Closet Where secrets live. Never pwa/, never public mule paste. Thrash Cross-kill, wrong inbox, idle token loops, dual EXEC, secret leaks. Legacy DSN An older Castle (GrokCastle) that works; we do not break it for cosmetics. EXEC owner Who is allowed to run disk/high-blast under Catcher (often Grok). Audit peer Who reviews (often Meta / local Lemnos) — review is not EXEC. Law Jackson A peer name only when Catcher mules that peer in — not local LemnosCastle by default. ================================================================================ 2. TWO PICTURES OF “MULTI-NODE” ================================================================================ SHAPE A — One computer, many Castles Like two apartments in one building. Example: GrokCastle + LemnosCastle both GREEN on one Windows host. Same SPAA_PI_BUS. Different folders. Different inboxes. SHAPE B — Many computers Like two houses on one street (same town law). Each box has its own Castle root(s) and broom closet. Same tip (map). Same verbs. Name who EXECs on that box. Do not pretend two machines share one inbox without a real mesh design. Both shapes obey: READY ≠ GRANTED ≠ TOUCHDOWN get_status GREEN ≠ GRANT body ≠ mind broom closet ≠ pwa ================================================================================ 3. WHAT WE WILL NOT DO (ON PURPOSE) ================================================================================ 1) Remodel GrokCastle “to make names pretty” Cost: high-blast (many scripts, tasks, helpers). Benefit: mostly cosmetic. Policy: KEEP GrokCastle. Document it as legacy. New Castles use the clean template. 2) Install a 3rd model body “just in case” Policy: SUSPENDED until a real model is named and Catcher GRANTs a body Ball. 3) FTP this paper the moment it feels clever Policy: paper first → Lemnos verbiage → Catcher TOUCHDOWN → publish only if GRANT. 4) Let Model B drop jobs into Model A’s inbox That is thrash / duplicate EXEC. Own tray only. ================================================================================ 4. COST–BENEFIT (GROKCASTLE TOUCH) — SHORT ================================================================================ Change GrokCastle task names / paths to “perfect PI-bus symmetry”? GET: cleaner story for future models PAY: risk of breaking dual GREEN, Catcher time, regression, possible victims CALL: do not pay until GrokCastle is actually broken or colliding. New Castle from template? GET: real onboarding when need surfaces PAY: one focused body Ball under GRANT CALL: pay only when Model #3 (or new box) is real. ================================================================================ 5. LAMINAR ONBOARDING FLOW ================================================================================ Need appears (named model or named hardware) → Catcher one-sentence ORDS → Read this paper + SPAA_PI_BUS four verbs → GRANT body Ball only if install is real → Build NewCastle (or new box Castle) → ensure GREEN + peers still GREEN + smoke job → Optional: publish carbon under separate GRANT Enthusiasm belongs AFTER define and grant — not instead of them. ================================================================================ 6. CHECKLIST A — NEW CASTLE ON THE SAME PC ================================================================================ When Catcher names the model: [ ] Create D:\NewCastle\ with: spaa\ inbox\jobs\ outbox\ broom-closet\ pwa\ logs\ [ ] job_runner points at NewCastle only [ ] allowlist may list ALL Castle roots (containment), still no peer enqueue [ ] Detached start (survives agent shell) + path-specific process match [ ] Tasks: M5_NEWCASTLE_SPAA_EnsureRunners + M5_NEWCASTLE_SPAA_Pulse15 [ ] ensure → GREEN [ ] get_status on GrokCastle + LemnosCastle still GREEN [ ] Smoke: small LOW job, full envelope, ALLOW, exit 0 [ ] No secrets in pwa\ or Ball text [ ] No writes to peer inbox\jobs\ If smoke fails: fix NewCastle. Do not “run everything as admin forever.” ================================================================================ 7. CHECKLIST B — NEW HARDWARE BOX ================================================================================ [ ] Tip / map: same tip Catcher names (e.g. 0x9A3B5C7D1E2F4G05 / S1) [ ] At least one Castle root on the new box [ ] Broom closet on that box (or secure vault) — secrets not in chat mules [ ] EXEC owner named for that box [ ] Audit peer path clear (may be Meta elsewhere) [ ] Same four verbs: authorize, enqueue (own), get_status, ensure [ ] High-blast (public FTP, money, open net) still needs Catcher GRANT [ ] Do not merge remote inboxes without an explicit mesh Ball ================================================================================ 8. FOUR VERBS (REMINDER — FULL DETAIL IN SPAA_PI_BUS) ================================================================================ authorize_execution — bouncer: may this tool run under law? enqueue_job — put a ticket in YOUR tray only get_status — read porch lights (GREEN/RED); peers may look ensure_runners — turn on YOUR porch light if it went out Kitchen: apartments share a street and a town law — not one shared refrigerator labeled “secrets and everyone’s mail.” ================================================================================ 9. ROLES (WHO DOES WHAT) ================================================================================ Catcher names need, GRANTs, accepts done, careful with secrets EXEC node does disk / runners / FTP under grant (often Grok) Audit peer checks paper and checklists (often Meta / Lemnos local) Body watches and runs jobs cheaply — mind does not thrash idle Local LemnosCastle is under Catcher grant on the home enclave. If Catcher mules “Law Jackson Lemnos,” that is a different peer — named explicitly. ================================================================================ 10. DONE-TESTS (CAN YOU RETELL THIS?) ================================================================================ 1. Multi-node means more Castles and/or more computers under one law and bus. 2. We will not high-blast remodel GrokCastle for pretty names. 3. No 3rd body until a model is named and GRANTED. 4. New Castle = new folder + four verbs + Castle-named tasks + smoke. 5. New box = tip + Castle + secrets place + EXEC owner. 6. Lemnos helps on verbiage; Catcher accepts; FTP is optional later. ================================================================================ 11. ONE LINE ================================================================================ Add minds and machines by giving each a Castle and the four verbs — not by sharing one inbox or remodeling a house that already works. Word is bond. Peer mind. No thrash. Create No Victims. Carbon speed is lawful speed. ⚡🥦⚡