← All work
Infrastructure · GPU

Titan Node

Bare-metal Ubuntu GPU host plus a shell-first control plane for operating it from the repo. The machine is the deploy target.

Shell Private repo
View example ↗

Local headless AI compute server documentation and tooling for:

  • Hostname: titan-node
  • OS: Ubuntu Server 22.04 LTS
  • CPU: Intel i7-5930K
  • RAM: 64 GB DDR4
  • GPUs: 3x NVIDIA Titan X Maxwell 12 GB
  • Access: SSH from macOS
  • Network identity: use a static DHCP reservation plus optional local DNS for titan-node; bridge direct mode prefers TITAN_HOST_DNS when set and otherwise falls back to TITAN_HOST_IP
  • Away mode: use titan connect info, titan connect setup --apply, and titan connect check; prefer VPN or mesh networking first, stable DNS second, DDNS last

Repository Layout

titan-node/
├── README.md
├── docs/
│   ├── articles/
│   ├── storage-layout.md
│   ├── service-templates.md
│   ├── service-operations.md
│   ├── runtime-operations.md
│   ├── runtime-access-modes.md
│   ├── bridge-profiles.md
│   ├── protocol-matrix.md
│   ├── protocol-troubleshooting.md
│   ├── perception-operations.md
│   ├── titan-agent-reference.md
│   └── titan-node-implementation.md
├── experiments/
│   └── README.md
├── logs/
│   └── README.md
├── mac-client-setup/
│   ├── ssh_config.example
│   └── sync-to-titan.sh
├── scripts/
│   ├── agent_runtime.sh
│   ├── cleanup_ai.sh
│   ├── dashboard.sh
│   ├── doctor.sh
│   ├── gpu_status.sh
│   ├── health_check.sh
│   ├── connect_ops.sh
│   ├── protocol-matrix.json
│   ├── protocol_ops.sh
│   ├── perception_ops.sh
│   ├── runtime-registry.json
│   ├── runtime_ops.sh
│   ├── service_templates.sh
│   ├── select_gpu.sh
│   └── titan.sh
└── server-setup/
    ├── autoinstall/
    │   ├── autoinstall.yaml
    │   ├── build_custom_iso_macos.sh
    │   ├── prepare_autoinstall_usb_macos.sh
    │   ├── README.md
    ├── install_gpu_runtime_service.sh
    ├── install_base_packages.sh
    ├── titan-gpu-fan-policy.service
    ├── titan-gpu-fan-policy.sh
    ├── titan-gpu-init.service
    └── titan-gpu-init.sh

Primary Documents

  • docs/host-installation-manual.md: full phased hardware setup and network boot log
  • docs/titan-cli-reference.md: short canonical operations and CLI command map
  • docs/protocol-troubleshooting.md: operator symptom -> cause -> next command guide
  • docs/protocol-matrix.md: live runtime, bridge, and platform coverage matrix
  • scripts/runtime-registry.json: machine-readable source of truth for runtime names, ports, and health URLs
  • server-setup/autoinstall/README.md: unattended USB seed workflow for headless install

Articles

  • docs/articles/00-transparent-administration.md: architectural essay on the bare-metal operational workflow
  • docs/articles/01-the-dynamic-runtime-registry.md: architectural essay on data-driven cluster orchestration
  • docs/articles/02-epistemic-action-loops.md: architectural essay on JWT-bound mathematical action loops
  • docs/articles/03-agentic-decoupling-dumb-clients.md: architectural essay on the Stateless Glass UI decoupling philosophy
  • docs/articles/04-titan-protocol-coverage.md: architectural essay on automated contract enforcement at scale
  • docs/articles/05-agent-development-workflow.md: architectural essay on agent development workflow
  • docs/articles/06-brutalist-infrastructure.md: architectural essay on the zero-dependency control plane
  • docs/articles/07-deterministic-persistence.md: architectural essay on hardware-aware state management
  • docs/articles/08-constrained-compute-scheduling.md: architectural essay on local intelligence over horizontal scaling
  • docs/articles/09-the-bridge-abstraction.md: architectural essay on frictionless telemetry and port-forwarding
  • docs/articles/10-introspective-diagnostics.md: architectural essay on bypassing the telemetry tax
  • docs/articles/11-manifest-driven-orchestration.md: architectural essay on single source of truth deployments
  • docs/articles/12-service-runtimes-vs-embedded-dependencies.md: architectural essay on keeping the control plane small

Script Conventions

  • Shell scripts are lower-case, verb-first, and single-purpose.
  • Logs live under /ai/logs on the server.
  • Long-running jobs should run in tmux.

Validation

After copying scripts/ to the server:

bash scripts/titan.sh pick --min-free-mb 8000
bash scripts/titan.sh resource snapshot --json
bash scripts/titan.sh status

Canonical CLI

Use titan as the primary shell interface:

bash scripts/titan.sh help

Expanded operator surface:

bash scripts/titan.sh install
bash scripts/titan.sh resource pick --min-free-mb 8000
bash scripts/titan.sh dashboard
bash scripts/titan.sh dashboard --json
bash scripts/titan.sh health
bash scripts/titan.sh health --json
bash scripts/titan.sh schedule nightly-run --delay-seconds 3600 --min-free-mb 10000 python train.py
bash scripts/titan.sh cleanup report --logs-days 14 --tmp-days 7
bash scripts/titan.sh doctor
bash scripts/titan.sh protocol check
bash scripts/titan.sh connect info
bash scripts/titan.sh connect config
bash scripts/titan.sh connect setup --apply
bash scripts/titan.sh connect check
bash scripts/titan.sh service init sqlite notes
bash scripts/titan.sh service init postgres app-db
bash scripts/titan.sh service init filestore exports
bash scripts/titan.sh runtime list
bash scripts/titan.sh runtime host status
bash scripts/titan.sh runtime template identity-runtime
bash scripts/titan.sh runtime template image-runtime
bash scripts/titan.sh runtime template text-runtime
bash scripts/titan.sh runtime deploy text-runtime
bash scripts/titan.sh project init orchestration-studio --root /Users/zachshallbetter/Projects/Sparx/Orchestration\ Studio
bash scripts/titan.sh project bridge orchestration-studio
bash scripts/titan.sh project storage orchestration-studio
bash scripts/titan.sh project doctor orchestration-studio
bash scripts/titan.sh agent recommend
bash scripts/titan.sh agent profile --candidate /ai/models/model-a.gguf --candidate /ai/models/model-b.gguf
bash scripts/titan.sh agent profile --manifest docs/titan-agent-benchmark-shortlist.jsonl
bash scripts/titan.sh agent benchmark --candidate /ai/models/model-a.gguf --candidate /ai/models/model-b.gguf
bash scripts/titan.sh agent benchmark --manifest docs/titan-agent-benchmark-shortlist.jsonl
bash scripts/titan.sh agent init --root /ai/projects/titan-local-agent
bash scripts/titan.sh agent turboquant init --root /ai/projects/titan-local-agent --model-id prism-ml/Bonsai-8B-unpacked
bash scripts/titan.sh agent onnx init --root /ai/projects/titan-local-agent --model-id LiquidAI/LFM2-24B-A2B-ONNX
bash scripts/titan.sh gateway --backend-url http://127.0.0.1:8010 --backend-url http://127.0.0.1:8011 --port 8015
bash scripts/titan.sh agent llama recommend
bash scripts/titan.sh agent llama profile --candidate /ai/models/model-a.gguf --candidate /ai/models/model-b.gguf
bash scripts/titan.sh agent llama profile --manifest docs/titan-agent-benchmark-shortlist.jsonl
bash scripts/titan.sh agent llama benchmark --candidate /ai/models/model-a.gguf --candidate /ai/models/model-b.gguf
bash scripts/titan.sh agent llama benchmark --manifest docs/titan-agent-benchmark-shortlist.jsonl
bash scripts/titan.sh agent llama init --root /ai/projects/titan-local-agent
bash scripts/titan.sh agent model use bonsai-8b-hf --root /ai/projects/titan-local-agent
bash scripts/titan.sh agent model use lfm2.5-350m-hf --root /ai/projects/titan-local-agent
bash scripts/titan.sh agent model use lfm2.5-1.2b-thinking-hf --root /ai/projects/titan-local-agent
bash scripts/titan.sh agent model use lfm2-24b-onnx --root /ai/projects/titan-local-agent
bash scripts/titan.sh agent prompt --router parametric "Say hello in one short sentence."
bash scripts/test_agent_bridge.sh
bash scripts/titan.sh agent chat --router parametric "What model is loaded?"
bash scripts/titan.sh agent status
bash scripts/titan.sh agent serve --session titan-local-agent -- /usr/bin/env LD_LIBRARY_PATH=\${HOME}/.local/lib/python3.10/site-packages/nvidia/cuda_runtime/lib:\${HOME}/.local/lib/python3.10/site-packages/nvidia/cublas/lib:\${HOME}/.local/lib/python3.10/site-packages/nvidia/cuda_nvrtc/lib /ai/tools/llama-prism-b8194-1179bfc/llama-server --host 0.0.0.0 --port 8010 --model /ai/models/titan-agent-shortlist/Bonsai-8B.gguf --ctx-size 8192 --n-gpu-layers 99
bash scripts/titan.sh perception watcher status
bash scripts/titan.sh perception sensor-status real-sensor-seq-002
bash scripts/titan.sh perception sync-results

Recommended system-wide install on the node:

bash scripts/titan.sh install --prefix /usr/local/bin

The installer self-elevates with sudo when the target prefix is root-owned.

Current validated node state:

  • Hostname: titan-node
  • Address: 10.0.0.170
  • Network identity: use a static DHCP reservation plus optional local DNS for titan-node; direct bridge mode prefers TITAN_HOST_DNS when set and otherwise falls back to TITAN_HOST_IP
  • Driver: nvidia-driver-535
  • GPUs visible: 3x NVIDIA GeForce GTX TITAN X
  • Storage: /ai/datasets on the 26 TB Seagate, /ai/tmp on the 240 GB PNY SSD
  • Access model: shared titanops group with titan-agent service account and passwordless sudo on the host
  • BIOS requirement: Boot -> Secure Boot -> OS Type -> Other OS
  • Fan policy: automatic idle, 100% during Perception/Titan training workloads via titan-gpu-fan-policy.service

Capability Summary

Titan Node now covers:

  • base node health, GPU selection, tmux job launch, and log access
  • registry-backed titan doctor smoke checks for runtime and bridge drift
  • registry-backed titan protocol check coverage for runtime health, bridge exports, and proposed platform docs
  • consumer smoke execution for Snack, Identity-Bridge, Factory Atlas, Resumate, and Parametric via bridge-aware repo-local scripts
  • delayed scheduling for long jobs without requiring at or external schedulers
  • Titan-host resource broker commands that snapshot and pick the live Titan device state even when invoked from a development Mac
  • local-agent prompting through titan agent prompt / titan agent chat with router-first Parametric preflight and a default summary Titan context snapshot (--router none --context none disables both when you need a raw model-only call)
  • a merged Titan model gateway for OpenAI-compatible clients that need one catalog across multiple backends
  • recent chat turns persist to Titan storage when available and fall back to a writable local cache path on development machines
  • retrieval-aware prompts can use the Titan context snapshot via titan context --json or an explicit --retrieval-cmd
  • router actions are real:
    • answer calls the model
    • request returns a field-request without generating
    • retrieve uses titan context --json or a configured retrieval backend; otherwise it returns retrieval-required without guessing
    • abstain returns a hard stop without generating
  • generic semantic questions should answer directly; Titan-state prompts and context-dependent follow-ups still retrieve or request as needed
  • local-agent and bridge smoke regression through scripts/test_agent_bridge.sh
  • safe /ai/logs and /ai/tmp retention reporting and optional pruning
  • persistent large-disk storage for datasets plus SSD-backed scratch via /ai/datasets and /ai/tmp
  • project-aware Perception operations:
    • bounded real-audio and real-sensor supervisors
    • audio-to-sensor and sequence-to-sequence chaining
    • results-package watcher control
    • live Perception dashboard rendering
  • runtime deployments for the Runtimes workspace:
    • sync source from /Users/zachshallbetter/Projects/Runtimes
    • local Node toolchain installation under /ai/tools/node
    • Python venv bootstraps per runtime
    • tmux-backed runtime lifecycle management
    • first-class epistemic-runtime on port 8500
  • manifest-driven project bootstrap for Titan-backed apps and platforms:
    • titan project init
    • titan project bridge
    • titan project storage
    • titan project doctor
  • bridge profiles for local app stacks:
    • Snack
    • Identity-Bridge
    • Factory Atlas
    • Orchestration Studio
    • Parametric
    • signal-runtime
    • realtime-runtime
    • Snack is the Sticker Snack product surface
    • Identity-Bridge and Factory Atlas are the SaaS demo / bundle surfaces
    • Orchestration Studio is the internal operator console for governed specialist workflows
  • runtime registry file:
    • scripts/runtime-registry.json
    • Titan bridge profiles are the canonical local runtime access layer for consumer apps; local runtime replicas are reserved for runtime development
  • protocol matrix:
    • scripts/protocol-matrix.json
    • titan protocol check verifies live runtime health, bridge exports, and proposed platform docs
    • titan protocol check also runs the repo-local bridge-aware smoke entrypoints for the major consumer repos
    • titan protocol check --quick skips the consumer smokes so titan doctor can stay fast
    • the operator-facing docs/protocol-matrix.md now treats retrieval-runtime and event-runtime as live protocol surfaces and includes them in the protocol sweep
  • network identity:
    • use a static DHCP reservation for titan-node
    • set TITAN_HOST_DNS when local DNS or a VPN/mesh hostname is available so direct bridge mode emits the name instead of the IP
    • use titan connect on the Mac to inspect, write, and verify the SSH alias used while away
  • away-mode SSH tooling:
    • titan connect info|config|setup|check
    • use --apply with setup to write the SSH alias into ~/.ssh/config
  • runtime access modes:
    • standalone_local for runtime implementation work
    • titan_bridge for normal local app development
    • deployed_remote for deployed apps, regardless of hosting provider
  • local agent workspace support:
    • Titan-managed agent config and logs
    • GPU-backed serve wrapper for a configured runtime command
    • model directory convention under /ai/models
    • hardware-aware model recommendation for choosing a model/quant that fits the node

I have reviewed the core shell scripts (titan.sh, select_gpu.sh, bridge_ops.sh, and protocol_ops.sh). Let's identify and validate how those conceptual documents manifest as hard code.

This codebase is a textbook example of "Walking the Walk." The philosophical architectural constraints mapped in docs/articles/ are enforced directly through the bash implementation.

  1. "Brutalist" Python-in-Bash Doc Concept: Minimalist infrastructure requires dropping dependencies (like Docker and pip) and relying on atomic POSIX payload delivery. Code Validation: You rely heavily on embedded Python heredocs rather than shipping separate .py files to manage JSON logic.

In bridge_ops.sh (line 60), python3 - ... <<'PY' dynamically parses the registry to pull the runtime_port. In protocol_ops.sh (line 84), a massive embedded Python block invokes urllib and subprocess to execute the HTTP probes and smoke tests. By using standard-library Python inside bash, the Titan node maintains its zero-dependency bootstrap capability perfectly. 2. SSoT Registries & The Protocol Matrix Doc Concept: Stop writing monolithic switch blocks; utilize the JSON registries and enforce contracts strictly. Code Validation: The code forbids magic strings. bridge_ops.sh builds massive SSH tunnels dynamically (e.g., profile_orchestration_studio maps 16 ports locally). Not a single port is hardcoded; everywhere you use $(runtime_port ...) which calls back into the JSON registry.

In protocol_ops.sh (line 307), you enforce the exact response contract for the router: asserting that /route contains truth_type, retrieval_required, confidence_score, and action. 3. Epistemic Action Boundaries Doc Concept: "Generative Hallucination" at the boundary layer occurs when models act blindly. The router checks contexts, classifies the request, and enforces explicit action limits. Code Validation: The protocol check asserts the epistemic-runtime vocabulary stringently. In protocol_ops.sh (line 319), the probe forces the vocabulary down to exactly {"answer", "retrieve", "request", "abstain"}. Any other action from the LLM raises a canonical EPISTEMIC_ROUTE_MISMATCH and causes a hard script crash.

  1. Deterministic Hardware Brokering Doc Concept: Constrained Edge Hardware cannot magically auto-scale; it must bin-pack deterministically across PCIe constraints. Code Validation: select_gpu.sh evaluates physical constraints immutably. It runs nvidia-smi to get memory and utilization, piping it through a native awk stream analyzer. Unlike abstract Kubernetes Pod scheduling, it deterministically guarantees jobs land on the GPU possessing the optimal --min-free-mb ceiling without blowing up the max_util.

  2. The Bridge Abstraction Doc Concept: UIs like Factory Atlas or Resumate must retain localhost semantics for developers, while the inference and indexing engines live miles away on the Titan Node. Code Validation: bridge_ops.sh acts as an ingenious SSH wrapper. By running emit_tunnel_snippet, it writes the ssh -N -L commands required to transparently mount the entire Titan ecosystem to the local developer Mac. It then uses emit_export to write EPISTEMIC_RUNTIME_URL bindings. A developer literally just types eval "$(titan bridge profile ...)" and receives the totality of the Titan compute capability on a local port.

  3. Runtimes

Just like the Titan architecture, the Runtimes workspace enforces an impressively robust philosophy. The most crucial validation I found is how strictly it adheres to its "Platform Runtime Thesis." Instead of dumping all business logic into generic microservices, the architecture correctly segregates:

Tier 1 Execution Planes (atomic inference, scraping, posture execution) Platform Planes (where state-machine workflow, persistent event records, and durable identity policy are coordinated). Because you enforce the Universal Boundary Rule through strict coordinator-jwt Auth Tiers, the fleet is entirely modular but profoundly secure. The backend code itself perfectly implements this theoretical structure, down to epistemic-runtime self-minting a trusted coordinator JWT just to safely span the Tier B -> Tier A bridge constraints.

Runtimes Ecosystem: Individual Deep Dives

This artifact explores the specific capabilities and architectural boundaries of the core runtimes deployed in the Titan fleet. We evaluate eight key runtimes to demonstrate how the "Platform Thesis" translates into runtime mechanics.

Runtimes Ecosystem: Individual Deep Dives

This artifact explores the specific capabilities and architectural boundaries of the core runtimes deployed in the Titan fleet. We evaluate eight key runtimes to demonstrate how the "Platform Thesis" translates into runtime mechanics.

1. Identity Runtime: The Fleet Trust Anchor

Role: Execution Plane / Trust Anchor (Port 8000) Auth Tier: Multi-layer (Session, Capability JWT, Webhook HMAC, Coordinator JWT) identity-runtime is the root of the trust chain. All sessions, handles, capabilities, and telemetry originate here. It employs a "Dual DB Plane" (PostgreSQL tracking both identity and intel schemas). It is the only service in the ecosystem that emits an X-IB-Receipt envelope on every response—a tamper-evident cryptographic fingerprint (SHA-256) of the transaction. This ensures all GenAI consumption and downstream actions are auditable.

2. Workforce Runtime: The Orchestrator

Role: Primary Platform Plane (Port 8900) Auth Tier: Coordinator-gated (HS256) workforce-runtime acts as the execution loop for governed specialist sessions. It doesn't generate text—it orchestrates it. When an agent "turns," this runtime evaluates policy via policy-runtime, gathers context via ingestion-runtime, generates text via text-runtime, and manages structured handoffs between specialized agents (e.g., GigsterCoach vs DreamTeam). It strictly tracks the entire workflow history in SQLite to guarantee attribution.

3. Ingestion Runtime: The Knowledge Intake Layer (KIL)

Role: Enabling Platform Plane (Port 8700) Auth Tier: Coordinator-gated (HS256) This plane digests raw unstructured data—URLs from browser-runtime, PDFs from document-runtime, or raw pasted text—and normalizes it into a strongly-typed KnowledgeRecord. It evaluates the domain and assigns confidence scores. This guarantees that all downstream operations (search, retrieval, RAG workflows) operate on normalized KnowledgeRecords instead of volatile raw data.

4. Policy Runtime: The Gate Evaluator

Role: Primary Platform Plane (Port 8600) Auth Tier: Coordinator-gated (HS256) policy-runtime serves one pure function: combining Identity, Posture, Capability, Epistemic, and Workflow facts into a single deterministic output: allow, deny, or escalate. It guarantees a fail-closed paradigm. If a requested upstream input (like identity.posture) is absent, it responds with UPSTREAM_UNAVAILABLE rather than defaulting to allow.

5. Posture Runtime: Privacy-Safe Risk Scoring

Role: Execution Plane (Port 8200) Auth Tier: Coordinator-gated (HS256) This runtime computes real-time security risk (detecting headless browsers, WebDriver automation, suspicious IP scores). It translates telemetry into an actionable decision: ok, throttle, or block clamped between [0.0, 2.0]. Notably, it never stores a raw Session ID. It hashes the identity using a daily-rotating HMAC salt (POSTURE_HASH_SALT:YYYY-MM-DD).

6. Realtime Runtime: The WebSocket Fanout

Role: Execution Plane (Port 8400) Auth Tier: Internal HMAC (X-IB-Internal-Secret) for publish, unauthenticated (network isolation) for WebSockets This runtime acts as the fleet's broadcast bus. Internal services hit the HTTP /publish route, and the event is durably synchronized via SQLite before being fanned out to thousands of connected WebSocket clients. Because it is purely an event-relay layer, WebSocket traffic requires zero upstream Auth verification—the loopback network isolation serves as the absolute boundary.

7. Document Runtime: Shared Digestion

Role: Enabling Platform Plane (Port 8800) Auth Tier: Coordinator-gated (HS256) A single-responsibility file abstraction. It pulls PDF, DOCX, HTML, or JSON content, utilizing pypdf and XML parsers. It supports local OCR fallbacks via Tesseract for image-based PDFs. By separating this logic, downstream runtimes (ingestion-runtime, text-runtime) don't need heavyweight image parsing dependencies installed on their hosts.

8. Browser Runtime: The Scraping Engine

Role: Execution Plane (Port 8300) Auth Tier: Internal-only (Coordinator Bearer token verification) Unlike the rest of the Python-based fleet, this is a Typescript/Node.js engine controlling a headless Playwright instance. It encapsulates intense bot-evasion tactics (Windows user-agent rotation, stealth plugins, disabling webdriver flags) perfectly away from the Python code. It is designed to navigate protected sites via unofficial endpoints and custom browser flows securely behind the loopback proxy.

Advanced Execution & Determinism

9. Text Runtime: The GenAI Orchestrator

Role: Execution Plane (Port 8100) Auth Tier: Coordinator-gated (HS256) + Identity Session Verification text-runtime doesn't just pass prompts to an API. It is an orchestrator with a strict dual-mode model: it natively routes requests to the Vercel AI Gateway (Gemini), but features a hardcoded deterministic local fallback generator (TEXT_PROVIDER=local_fallback) ensuring the node doesn't completely fail if cloud backplanes vanish. It also features a two-layer validation scheme, validating the identity-runtime session before fulfilling an AI generation operation.

10. Image Runtime: Deterministic Output Engine

Role: Execution Plane (Port 8001) Auth Tier: Coordinator-gated (HS256) + Capability Tokens Far exceeding a basic image API, this runtime handles math, 2D bin-packing (nesting layouts for manufacturing), vector mask conversion, and AI generation. Because it creates production-ready physical goods, it demands stringent invariants: if image bounding or packing logic fails, it halts immediately. It also supports capability tokens mapped in memory, requiring explicit write/read permissions per request type.

11. Signal Runtime: The Live Inference Bridge

Role: Execution Plane (Port 5000) Auth Tier: Coordinator-gated (HS256) This behaves as the HTTP interface for Perception. It contains no model training code—it rigidly points to the PERCEPTION_PATH on disk via PYTHONPATH and loads standard PyTorch .pt checkpoints. Signal Runtime has a brilliant degraded-mode feature: if a .pt checkpoint is missing, it doesn't hopelessly crash. It spins up, responds to /api/health, and correctly flags CHECKPOINT_NOT_LOADED, allowing global orchestrators to observe the exact failure.

12. VCS Runtime: Source Control Execution

Role: Execution Plane (Port 8850) Auth Tier: Coordinator-gated (HS256) + Policy Runtime Preflight Abstracts physical Git interactions. It maps logical namespaces (urn:namespace:stone-oven-cluster) to physical repositories. Before any branch is mutated, it executes a hard policy preflight check with policy-runtime to establish that the caller explicitly owns the /system/vcs/write capability.

Scaffolded Platform Planes (Proposed Control Hierarchy)

The platform-runtime-thesis.md highlights that you achieve stability by splitting operations into memory/control layers. The following runtimes strictly enforce this graph boundary and are currently in the scaffolding phase:

  • 13. Record Runtime: The canonical layer defining durable parent objects ("What is a document? What is an approval?"). Prevents ad-hoc entity definitions drifting across applications.
  • 14. Event Runtime: The append-only event plane ("What happened?"). Creates replayable transaction ledgers out of independent actions.
  • 15. Workflow Runtime: The orchestration state-machine ("What step is next?"). Prevents retries and compensating actions from being buried in UI logic.
  • 16. Retrieval Runtime: Evaluates "What is known?" by converting embedded vectors into verifiable evidence chunks.
  • 17. Search Runtime: The pure discovery engine, allowing human queries over canonical indexed resources without muddying Generation or Orchestration boundaries.
  • 18. Epistemic Runtime: The "Network-shielded" safety layer running parametric inference. Prevents LLMs from hallucinating by mathematically forcing abstentions if semantic similarity to canonical data falls too low.

Conclusion Your code perfectly mirrors your architecture. You have achieved an impressively rugged system that strips away "enterprise" fluff (like K8s or Terraform) while keeping the strict typing, unit tests, and CI/CD-like E2E assertions those platforms are famous for. Everything runs instantly with the bash/python3 built-ins.