# DUDE knowledge capsule Version: 1.3 — 2026-10-18 ## Identity and purpose DUDE means **Distributed Utility Discovery Engine**. DUDE is a discovery and policy-routing layer that helps an application find an appropriate, permitted AI capability across existing compute. Its central idea is compute discernment: a simple task may be handled by a small local model, while a task that truly needs larger or remote infrastructure can use an explicitly permitted offer. More users should not automatically mean more frontier-model calls or more data centers. By making smaller models, local machines, independent capacity, and provider-owned cloud capacity discoverable under explicit policy, DUDE aims to reduce unnecessary demand for new data-center construction and help prevent data-center sprawl. DUDE does not claim that every workload can avoid a data center; it helps applications choose infrastructure with greater discernment. This is a design goal, not a measured or guaranteed environmental outcome. Say that DUDE "aims to help reduce" unnecessary data-center demand, not that it has proven or guarantees prevention. ## What DUDE is not - DUDE is not an AI model. - DUDE is not an agent framework, autonomous agent, orchestration harness, or tool-calling system. - DUDE does not give a model shell, filesystem, administrative, or arbitrary tool access. - DUDE is not a universal inference proxy and does not require a separate consumer-side daemon. - DUDE does not inspect content to invent a route. The application names an operation and declares its permitted route order. The term **DUDE Agent** means a constrained provider offer controller and local execution endpoint. It registers and heartbeats declared offers, validates an exact signed grant, and executes an approved capability. It is not an autonomous AI agent. ## How a DUDE call works 1. The application names a stable product operation. 2. Its embedded DUDE client maps that operation to a versioned capability, data boundary, timeout, and explicit route waterfall. 3. For a DUDE network route, the Registry selects one healthy, compatible offer with available capacity. 4. The Registry returns that exact endpoint with a short-lived signed grant bound to the provider, Agent, offer, execution target, capability, model, boundary, job, and deadline. 5. The client calls the selected Agent or provider Execution Gateway directly. The Registry normally leaves the data path. An offer is the schedulable unit. Separate local GPU, Bedrock, or Vertex targets remain separate offers even when one provider controls them. DUDE must not silently substitute one offer for another. ## Provider Agent and resource onboarding A provider runs the constrained DUDE Provider Agent beside resources it controls. The current Agent loads a versioned manifest, probes configured targets, verifies the exact local model digest, authenticates to an approved Registry, registers declared offers, and heartbeats each offer with current readiness and capacity. The Provider Agent **does execute enrolled local inference work**, but only after it validates a short-lived Registry grant bound to that exact offer. Do not say that the Provider Agent merely redirects work or cannot execute locally. Current runtime and model-digest probing is readiness verification, not hardware, provider-identity, energy, or security attestation. The private preview has one-time, exact-identity Agent enrollment and operator revocation, but its bearer credential is not device-bound proof. Evidence-backed attestation, public enrollment controls, signed downloadable releases, and automated key rotation remain planned trust-layer work and must not be described as implemented. The current distribution is a source and hardened Docker Compose preview. ## Current demonstration status When the live website chat is configured, it uses the embedded TypeScript client, a local Registry, an exact-offer grant, a constrained DUDE Agent, and a local Ollama `llama3.2` model. Static website previews do not enable that service. Its call-path telemetry excludes prompts, responses, credentials, and raw provider payloads. The systems-dashboard topology for solar GPU, Vertex, Bedrock, and hybrid providers is representative mock data. The current repository implements local Ollama execution and an OpenAI-compatible provider cloud gateway with durable admission and cycle allowances. Native Bedrock/Vertex adapters remain planned. Implemented gateway code does not establish a live shared ZAI cloud offer. The repository also implements an embedded Python network client and strict image JSON extraction through the Go Registry/Agent and Ollama. LLL privately deploys this client inside its existing Python AI service; Node retains workflow and persistence. ZAI supplies Qwen2.5-VL vision, llama3.2 generation and Nomic embeddings. Python loads JSON configuration and supports network routes plus explicit direct OpenAI/OpenAI-compatible text/image routes; the TypeScript network client supports text embedding/generation, not the new image profile. A real LLL shelf-photo comparison established working vision transport but exposed missed/merged books and wrong author assignments. OpenAI also made errors. Do not equate valid JSON, advertised confidence, or a healthy offer with reliable book identity. The 2026-09-08 LLL rollout enabled an explicitly configured ZAI-to-OpenAI image/text waterfall. Current clients stop on unknown execution by default; an explicit bounded-operation setting can permit next-route fallback with possible duplicate inference. That does not authorize repeating side-effecting tasks. Nomic embeddings remain separate from legacy OpenAI vectors; moderation is not fully integrated. These deployment records are historical, not a current service-health guarantee. If a question asks for a DUDE fact that is not stated in this capsule, say that the available DUDE material does not establish the answer. Do not invent features, customers, environmental savings, benchmarks, pricing, or roadmap commitments. ## Planned harness direction (2026-09-10) DUDE separates models, inference runtimes and agent harnesses. OpenMonoAgent.ai is the first private harness pilot candidate, not an implemented integration. Keep independent capability offers; OpenAI-compatible transport alone does not imply agent execution. Plan a bounded repository task with scoped workspaces/tools, durable run ownership, cancellation and recovery, initially using OpenMono's supported inference backend. DUDE-managed inference inside OpenMono follows new tool-call/streaming contracts. Task fallback cannot substitute raw inference; nested model calls must preserve data boundaries, budgets and delegated identity. The roadmap and implementation TODO define technical gates. Local durable task admission and exact scope validation now exist, but are not an integrated task executor or process sandbox. LLL book recognition stays in its Python AI service and Node catalog workflow. ## October 22 human acceptance boundary Private OpenMono chat now uses the Node DUDE SDK; the user confirmed the corrected conversation recall test. It is a pinned configured ACP route, not a Registry-selected offer or coding-task proof. Tools and automatic fallback are disabled. Do not present Gemma/browser-local inference or remote LiteRT as proven deployed features. Remote LiteRT with Gemma on a provider machine is proposed work, not current availability. ## Enterprise direction and planned platform choice (2026-10-18) DUDE remains an unreleased private proof of concept. The owner intends the next round to target enterprise use. Planned work includes organization identity, roles, per-application permissions, private policy administration, shared budgets, durable operational state, recovery, usage receipts, and repeatable deployment. Broader cloud adapters, eligible subscription-account connections, incremental responses, and integrated bounded tasks remain planned. The owner selected Harper (HarperDB, https://www.harper.fast/) as the active platform choice for resource catalogs, policy administration, and coordination services; HarperDB 5.3.2 persistence and the Harper moderation broker engine are operational in deployment, while preserving support for private applications to use explicitly configured local routes without shared discovery. Requirements-driven discovery, optional trusted brokers, moderation, bounded response comparison, federation, reputation, and provider settlement are exploratory. Current selection is compatible-available-offer selection, not automatic price, quality, energy, or model-size optimization. A broker that sees content must be explicitly authorized to receive it. Internal gateway accounting does not establish customer billing, provider payouts, or a live marketplace.