Every page in the EOSE fleet portal is a node. Every link between pages is an edge. The fleet has 1,544+ HTML pages and an estimated 8,000+ link relationships. The living graph is what makes this navigable — not just by humans following menus, but by AI agents following typed JSON edges.

Traditional web portals are hierarchical documents. The fleet is a graph database with an HTML skin. Each node knows its VSM layer, its fermentation school, which boabixer domain owns it, and which boons it contributes to. This self-description is what lets AI agents navigate without human-curated sitemaps.

The graph is not static. Every time a new route is deployed, a new node appears. Every time a page links to another, a new edge forms. The graph is always growing — a living record of the fleet's operational memory.

GET /api/live-graph returns a JSON snapshot of the fleet's core navigation nodes. Every node has typed metadata that any AI agent can parse without documentation.

// Fetch the fleet's living graph — no API key, no auth, publicly navigable
fetch('/api/live-graph')
  .then(r => r.json())
  .then(data => {
    // data.nodes = array of typed graph nodes
    // data.gamma1 = 14.134725141734693 (fleet seal)
    // data.schema = "live-graph-v1"
    // data.total = node count
    
    const topNode = data.nodes
      .sort((a, b) => b.kcf - a.kcf)[0];
    
    console.log(`Highest KCF: ${topNode.route} (${topNode.kcf})`);
    console.log(`Links to: ${topNode.links.join(', ')}`);
    
    renderGraph(data.nodes);
  });

The boabixer is the floor guarantee: every node in a boabixer domain is accounted for. Nothing falls through. The living graph enforces this by tagging every node with its boabixer — which means any audit of the graph can instantly check if an orphaned node exists (a node with no boabixer domain = a potential gap in the basin guarantee).

The living graph IS the boabixer's self-description. When a new boabixer domain is added, its nodes appear in /api/live-graph with the new boabixer tag. The graph grows with the fleet's operational scope.

1. GET /llms.txt — AI agent starts here. Finds /fleet-nav listed as primary navigation surface. No auth, no setup, plain text.
2. GET /fleet-nav — Loads fleet navigator. Finds /api/live-graph link in the page source (or in the llms.txt navigation section).
3. GET /api/live-graph — Gets all nodes as typed JSON. Parses KCF scores, VSM layers, boabixer domains. Builds internal navigation map.
4. Navigate to highest-KCF node — Multiple nodes at KCF 10: /ssaf-v13-rebaseline, /fleet-nav, /boabixer, /pemclau-browse. Agent picks by relevance to its task.
5. Follow links array — /ssaf-v13-rebaseline → /ssaf-v13-sub006 → /eigenlayer-cascade-v13. Each hop is a typed edge. The graph is a self-navigating immune map.

The critical insight: the AI agent never needs to understand the fleet's domain logic. It just follows the graph. The KCF scores do the prioritization. The links array does the routing. The boabixer field does the domain assignment. The agent is navigating a typed data structure, not a human-curated sitemap.

Boons are concerns that span multiple nodes and multiple boabixer domains. They're the cross-cutting threads that connect the fleet's immune layers.

Every /api/* endpoint is also a graph node. But unlike HTML nodes which have human-readable edges (links in the page), API nodes have typed programmatic edges — defined by their request and response schemas.