{"id":"resource-fabric","title":"Infrastructure Fabric","subtitle":"The compute and storage fabric that reproduces every Lupine result.","category":"operations","tags":["meta","infrastructure"],"source":"articles/docs/resource-fabric.md","lang":"en","words":414,"readMinutes":2,"toc":[{"depth":2,"text":"Lane 1: Cloudflare as the Control Plane","id":"lane-1-cloudflare-as-the-control-plane"},{"depth":2,"text":"Lane 2: Local RTX A4500 as the First Heavy Worker","id":"lane-2-local-rtx-a4500-as-the-first-heavy-worker"},{"depth":2,"text":"Lane 3: GCP as Elastic Burst","id":"lane-3-gcp-as-elastic-burst"},{"depth":2,"text":"Routing Policy","id":"routing-policy"},{"depth":2,"text":"API Surface","id":"api-surface"},{"depth":2,"text":"When Formalization Comes Back","id":"when-formalization-comes-back"}],"html":"<h1 id=\"infrastructure-fabric\">Infrastructure Fabric</h1><p>The best rig is a three-lane system with one durable brain.</p>\n<h2 id=\"lane-1-cloudflare-as-the-control-plane\">Lane 1: Cloudflare as the Control Plane</h2><p>Cloudflare should own the always-on parts:</p>\n<ul>\n<li><code>glim-think</code> Worker routes the API and scheduled loops.</li>\n<li>Durable Objects keep specialist agent sessions alive.</li>\n<li>D1 is the ledger for tasks, resource requests, allocations, claims, and deployments.</li>\n<li>R2 stores artifacts: diaries, metrics, manifests, traces, generated reports, and result bundles.</li>\n<li>Workers AI and external model providers handle cheap reasoning, triage, summaries, and routing.</li>\n</ul>\n<p>This lane should not run expensive GPU simulations. It decides, records, verifies, and broadcasts.</p>\n<h2 id=\"lane-2-local-rtx-a4500-as-the-first-heavy-worker\">Lane 2: Local RTX A4500 as the First Heavy Worker</h2><p>The local 20 GB GPU is the default heavy lane while the workstation is awake:</p>\n<ul>\n<li>MLIP screening and batch scoring.</li>\n<li>LAMMPS experiment batches that fit in one-GPU memory.</li>\n<li>Private or messy data runs that should not leave the machine yet.</li>\n<li>Fast iteration before cloud spend.</li>\n</ul>\n<p>The worker script is:</p>\n<pre><code class=\"language-powershell\">scripts/local_gpu_worker.ps1 -ThinkUrl http://127.0.0.1:8787 -Once\nscripts/local_gpu_worker.ps1 -ThinkUrl https://&lt;glim-think-worker&gt; -Claim\n</code></pre>\n<p>Without <code>-Claim</code>, it only registers and heartbeats the GPU. With <code>-Claim</code>, it claims\nagenda tasks for a specialty lane and writes job envelopes into\n<code>.glim-runtime/gpu-queue/</code>.</p>\n<h2 id=\"lane-3-gcp-as-elastic-burst\">Lane 3: GCP as Elastic Burst</h2><p>GCP should stay mostly cold until the ledger proves pressure:</p>\n<ul>\n<li>Queue depth remains high after local GPU passes.</li>\n<li>A run needs longer wall time, bigger parallelism, or reproducible cloud artifacts.</li>\n<li>We need public deployment of a live research surface such as <code>library-site</code>\nor the LUPI viewer.</li>\n<li>We want formal release candidates built from clean containers.</li>\n</ul>\n<p>Use project <code>shed-489901</code> as the default gcloud project. Keep GCP as a burst lane,\nnot the source of truth. Results still report back into <code>glim-think</code>.</p>\n<h2 id=\"routing-policy\">Routing Policy</h2><ol>\n<li>Edge-first: all work becomes an agenda task or resource request in D1.</li>\n<li>Local-first for GPU: claim to <code>local-rtx-a4500</code> when the task can run on one GPU.</li>\n<li>GCP burst only when queue pressure, reproducibility, or scale justifies it.</li>\n<li>Formalization lane is fed by stable claims with artifacts and traces.</li>\n<li>No result counts as real until it has an artifact key, provenance, or proof obligation.</li>\n</ol>\n<h2 id=\"api-surface\">API Surface</h2><p>Resource endpoints:</p>\n<ul>\n<li><code>POST /resources/bootstrap</code></li>\n<li><code>GET /resources/status</code></li>\n<li><code>POST /resources/register</code></li>\n<li><code>POST /resources/heartbeat</code></li>\n<li><code>POST /resources/allocate</code></li>\n</ul>\n<p>Agenda endpoints:</p>\n<ul>\n<li><code>POST /agenda/seed</code></li>\n<li><code>GET /agenda/status</code></li>\n<li><code>GET /agenda/tasks?status=queued&amp;limit=50</code></li>\n<li><code>POST /agenda/claim</code></li>\n<li><code>POST /agenda/update</code></li>\n<li><code>POST /agenda/complete</code></li>\n</ul>\n<h2 id=\"when-formalization-comes-back\">When Formalization Comes Back</h2><p>The team should be ready to switch from broad execution to lean formalization by\npromoting only claims that have:</p>\n<ul>\n<li>a completed task chain,</li>\n<li>a stable artifact,</li>\n<li>clear provenance,</li>\n<li>a falsification note,</li>\n<li>and a small Lean target in <code>lean-spec</code>.</li>\n</ul>\n<p>That keeps formalization from becoming ceremonial. It becomes the release gate\nfor the strongest claims.</p>\n"}