README_CHAIN_DRIVE.txt ======================================================================== OneCharacterCode Chain Drive Architecture Demo - reproducibility guide This is a SIMULATION demo, not a production deployment. It models Bret Fencl's Chain Drive architecture for distributed workload balancing across a multi-site ecosystem. WHAT THE CHAIN DRIVE MODEL CLAIMS ------------------------------------------------------------------------ - All websites in the ecosystem are equal links in a circular chain. - Work flows around the chain in priority order. - Idle / lower-load sites can support overloaded sites. - High-priority items always run before low-priority items. - Failed sites are absorbed by their neighbors; the chain continues. - Sales / payments wait for upstream customer / inventory data. - OneCharacterCode-style symbolic packets reduce repeat transfer bytes after a one-time dictionary install. PRIORITY STACK ORDER (highest first) ------------------------------------------------------------------------ 1. Accounts 2. Security alerts 3. Payments / sales 4. Customer updates 5. Inventory updates 6. Website content updates 7. SEO indexing 8. Backup tasks 9. Archive tasks 10. Rest / idle state WHAT'S IN THIS FOLDER ------------------------------------------------------------------------ run_chain_drive_simulation.ps1 Simulation script (PS 5.1 compatible). chain-drive-simulation.json Initial 300-node configuration. chain-drive-results.json Per-scenario + aggregate metrics. chain-drive-demo.html Public demo page. chain-drive-demo.css Page styles. chain-drive-demo.js Animated SVG ring + results renderer. README_CHAIN_DRIVE.txt This file. SHA256_MANIFEST_CHAIN_DRIVE.txt Hashes of every Chain Drive file. HOW TO RUN ------------------------------------------------------------------------ Prerequisites: - Windows PowerShell 5.1+ (already on Windows 10/11) or PS 7+. - No internet connection required. - No third-party tools required. Steps: 1. Open PowerShell. 2. Change to this folder. 3. powershell -File run_chain_drive_simulation.ps1 4. The script prints per-scenario metrics and writes: chain-drive-simulation.json (initial 300-node config) chain-drive-results.json (per-scenario + aggregate metrics) WHAT THE SIMULATION DOES ------------------------------------------------------------------------ Builds 300 deterministic synthetic website nodes (seed 11052026). Each node carries: SiteID, DomainName, PriorityLevel, CurrentLoad, AvailableCapacity, QueueType, Dependencies, SharedCustomers, Status, LastProcessed, WorkCompleted, SupportGiven, SupportReceived. Then runs 5 scenarios over 4 chain cycles each: Scenario A - Normal 300-site chain. Scenario B - One site (#47) gets an event spike +80% load. The chain finds idle / backup / SEO sites with spare capacity to absorb the excess. Scenario C - New inventory at three origin sites (15, 88, 201) is fast-indexed across related sites via their shared customer links. Each link costs one symbolic packet instead of a full content push. Scenario D - Three sites (133, 220, 270) fail simultaneously. Their ring-neighbors absorb the work; the chain does not stop. Scenario E - Four sales-priority sites (70, 130, 175, 230) have upstream dependencies and wait for those dependencies to complete before processing payments. METRICS RECORDED PER SCENARIO ------------------------------------------------------------------------ total_tasks_processed How many work units the chain executed. average_load_per_node Final average load across all 300 sites. overloaded_before_balancing Sites > 100% load before chain balanced. overloaded_after_balancing Sites > 100% load after chain balanced. idle_capacity_reused_units Capacity drawn from idle sites to help overloaded sites. support_transfers_performed Count of one-site-helping-another events. symbolic_packet_bytes Wire bytes if every transfer is an OCC symbolic packet (post-install). normal_transfer_bytes Wire bytes if every transfer is a full payload push. percent_transfer_saved (1 - symbolic/normal) * 100. failed_links_recovered Count of failed-node-absorbed-by-neighbor events. total_chain_cycles_completed Number of full chain loops. dependency_waits Count of sales tasks that paused for upstream completion (Scenario E only). HOW TO INTERPRET THE RESULTS ------------------------------------------------------------------------ Scenarios A and C run clean with no support transfers because the initial random load distribution does not push any single site over 100% capacity. This is the "ecosystem in steady state" baseline. Scenario B forces one site over 100% load and shows the chain absorbing the excess: overloaded count drops back to 0 after balancing. Scenario D demonstrates self-repair: failed_links_recovered is non-zero, and the chain continues to process tasks at near-normal throughput. Scenario E adds dependency_waits as a separate metric: payments pause until their upstream customer/inventory data is ready. The percent_transfer_saved column is the OCC-after-install savings rate, in line with the V4 benchmark Mode B numbers (roughly 79-90% on heavily-repeated structural payloads). HONEST LIMITATIONS ------------------------------------------------------------------------ 1. This is a SIMULATION. No real network traffic occurs. 2. The 300 nodes, their domains, priority assignments, and dependencies are deterministic synthetic data from a fixed seed. They do not represent any specific live website. 3. Symbolic-packet vs normal-transfer byte sizes are MODELED from priority-class defaults; they are not measured packet captures. In production these numbers would be measured against the OCC engine on the wire. 4. The animated SVG is a cosmetic visualization of the simulation state. Its per-frame colors are approximated; the authoritative numbers live in chain-drive-results.json. 5. Self-repair here absorbs work into neighbor capacity within one cycle. A real deployment would also queue retries, handle network partitions, and run health probes. 6. Priority-stack ordering is implemented as a simple greedy queue. Real production would add fairness, starvation prevention, and tenant quotas. 7. OCC dictionary install cost is not added to the wire-bytes figure in this demo. It appears in the V4 benchmark. The Chain Drive demo focuses on the runtime savings AFTER install. VERIFYING HASHES ------------------------------------------------------------------------ Every file in this folder is listed in SHA256_MANIFEST_CHAIN_DRIVE.txt with its SHA-256 hash. To re-verify after a copy or transfer: Get-ChildItem -File | ForEach-Object { $h = (Get-FileHash -Algorithm SHA256 -Path $_.FullName).Hash "$($_.Name) $h" } End of README_CHAIN_DRIVE.txt.