ELM Job Bridging (Phase 13, product-v1.0): funded multi-ELM jobs through the existing processing grid [corrected scope]

[Super-Genius]

Target branch: develop
Priority: High — product-v1.0 requirement (pre-ship)
References: https://gcs.gnus.ai/llms.txt · https://docs.gnus.ai/llms.txt · SuperGenius .planning/notes/ELM-bridging-gaps.md (source analysis)

• ipfspubsub:// URL prefix — gossip pubsub channels as FileManager source/destination (product-v1.0) AsyncIOManager#11 — ipfspubsub:// URL prefix (gossip pubsub as FileManager source/destination) (blocker)

ARCHITECTURE CORRECTED 2026-08-26 — SuperGenius is already the scheduler. The original goals/architecture below that added a scheduler/bidding layer on top have been removed. Runtime work (model manifests, cache, LM execution) split to GeniusVentures/SGProcessingManager#17 (@itsafuu). This issue now covers Phase 13: ELM Job Bridging in .planning/ROADMAP.md (v1.1 milestone, extended as product-v1.0 gate).

Corrected architecture

OpenAI-compatible client
        |
        v
Installed GCS /v1 API
        |  creates ONE funded SuperGenius job (elms[] in Task.json_data)
        v
SuperGenius processing grid  — existing queue, ownership and participation logic
        v
One or more processor nodes — fetch model if missing, cache, execute via SGProcessingManager
        v
Results (work-item-tagged) back to GCS → OpenAI-compatible response

A GCS instance creates and funds a normal SuperGenius processing job containing one or more ELM work items. Each work item specifies an ELM type and an immutable model-manifest pointer. SuperGenius's existing processing grid handles worker participation, task ownership and execution. A processor retrieves and verifies the referenced model bundle, uses a local content-addressed cache, executes the work through SGProcessingManager, and publishes the result. Model cache state is not advertised and does not affect eligibility. The existing fixed $0.0003/hour processing rate applies.

Scope (this issue, Phase 13)

1. Job model — job_type: "elm_processing" job whose elms[] (work_item_id, elm_type, model_manifest_uri/hash, input_uri, generation settings) lives entirely in the existing Task.json_data; no main-protobuf change (ProcessingCoreImpl already builds SGProcessingManager from task.json_data())
2. Task→SubTask mapping — each ELM work item becomes a subtask carrying/referencing its contract fields; grid distributes via the normal queue
3. Funding — deterministic from job JSON (funding.maximum_processing_hours, escrow_path) at the fixed rate; model download is part of the job's billable work via existing accounting/escrow; no quote/bid/negotiation protocol
4. Work-item results — results identify their originating work item (existing SubTask.subtaskid); GCS aggregates by work-item ID with no SuperGenius-side aggregation

Removed from this issue (superseded)

NodeElmCapabilities · ELM inventory advertising · cache-state advertising · ElmProcessingIntent · requester-side participant selection · per-node cost quotes · GCS-managed child-job claims · GCS-managed execution leases · price-policy negotiation · resource bidding — and the corresponding protobuf messages (capability/inventory/bidding/intent/quotes/claims/leases/worker-selection).

Split & tracking

Phase	Repo	Issue	Owner
13 — ELM Job Bridging	SuperGenius	this issue	henriqueaklein (with itsafuu)
14 — ELM Runtime (manifests, cache, LM execution)	SGProcessingManager	GeniusVentures/SGProcessingManager#17	itsafuu

Phase 15 (events/streaming proto) dropped 2026-08-26: if streaming is ever needed it rides the existing gossip-pubsub results channel (seq-numbered JSON events on Task.results_channel) — no SGElmProcessing.proto will be added.

Acceptance criteria

• A job with multiple ELM work items is published and distributed through the existing grid with no new task-ownership protocol messages
• Funding math is deterministic from the job JSON; no negotiation protocol exists in code or protobuf
• Every result identifies its ELM work item
• First implementation: complete single-node ELM job; multi-node partitioning/verifier groups out of scope

Planning documents

• ROADMAP.md — Phase 13 details (v1.1 extension, product-v1.0 gate)
• REQUIREMENTS.md — ELM-01…08
• notes/ELM-bridging-gaps.md — source architecture analysis
• INGEST-CONFLICTS.md — synthesis + resolutions (rate, placement)
• notes/private-network-identity.md — pubsub privacy = Layer 1 (gating inherits to all topics; no per-topic crypto)

[Super-Genius]

Architecture clarification: installed GCS is the OpenAI-compatible requestor gateway

An installed GCS instance should be able to expose the OpenAI-compatible /v1 API and use its configured SuperGenius account/GNUS balance to submit paid ELM work to any compatible SuperGenius processor nodes.

OpenAI SDK / application
  -> installed GCS `/v1`
  -> GCS policy, model alias, context and cost routing
  -> GCS requestor wallet / GNUS escrow
  -> SuperGenius processing task
  -> one or more compatible SuperGenius processor nodes
  -> ELM execution through SGProcessingManager
  -> token/result events back to GCS
  -> OpenAI-compatible SSE or JSON response

This means each SuperGenius worker does not need to expose an OpenAI API, and the GCS parent API-job protocol should not be copied wholesale into SGProcessing.proto. GCS owns the external request, API key, context, routing policy, GNUS budget, billing envelope and OpenAI response. SuperGenius owns the paid child-processing job, worker selection, execution transport and result delivery.

Revised minimum SuperGenius boundary

SuperGenius needs only the fields and messages required to execute and report an ELM child task:

• ELM/runtime capability advertisement or compatibility matching
• Parent GCS request/job correlation
• ELM artifact/model/tokenizer/adapter identity
• Generation settings and deadline
• Per-task stream/result channel
• Ordered progress/token events
• Cancellation
• Typed final ELM result
• Signed usage and settlement data

The following should reuse existing SuperGenius mechanisms rather than create a second GCS-specific queue inside SGProcessing.proto:

• Subtask locking and ownership
• Worker competition and queue attachment
• Retry/requeue behavior where already available
• Task payment/escrow through the requesting GCS node's GNUS account
• Task and result publication

A separate GCS claim/lease protocol remains useful for high-level GCS_API_REQUEST_JOB ownership, but it belongs to GCS. A child ELM task sent through SuperGenius should use the existing ProcessingQueue, ProcessingQueueItem, ownership requests and task lifecycle unless a concrete gap is found in those mechanisms.

Installed-GCS requirements

The installed GCS distribution should add a SuperGeniusRequestorAdapter that:

1. Opens or connects to a SuperGenius node/account.
2. Reads the available GNUS balance and configured per-request budget.
3. Maps OpenAI model aliases such as gnus-auto, gnus-code or a specific ELM ID to processing definitions.
4. Discovers compatible processors and current network prices/capacity.
5. Creates and funds the SuperGenius task/escrow.
6. Publishes the task and subscribes to its stream/result channel.
7. Converts SG token events into OpenAI SSE chunks.
8. Cancels the SG task when the API client disconnects or the deadline expires.
9. Verifies result and usage signatures.
10. Finalizes payment and returns OpenAI-compatible usage.

Routing modes

The same installed GCS endpoint should support:

• local: use only the local SuperGenius processor
• private: use an allowlisted tenant beehive
• public: use compatible public SuperGenius processors
• hybrid: prefer local/private, then use public nodes

The optional OpenAI request extension can carry max_cost_gnus, privacy mode, replication factor and verification mode. Standard OpenAI clients remain compatible without the extension.

Protobuf impact after this clarification

The proposed protobuf update should be narrowed to an ELM child-processing protocol, preferably SGElmProcessing.proto, imported by SGProcessing.proto where required. It should not define the full external API request or duplicate the GCS parent queue.

At minimum, add:

• ElmTaskRequirements
• ElmExecutionDescriptor
• ElmGenerationParameters
• ElmExecutionEvent
• ElmCancellationRequest
• ElmExecutionResult
• ElmUsageReceipt
• optional ELM linkage fields on Task, SubTask, and SubTaskResult

Capability data may be added to processing-channel discovery or kept in a separate signed capability topic. Existing wire fields must remain unchanged.

Added acceptance criteria

• An installed GCS instance can expose a local or hosted OpenAI-compatible /v1 endpoint.
• That GCS instance can use its configured GNUS account to fund ELM work.
• One API request can execute on any compatible SuperGenius processor node without that worker exposing HTTP.
• /v1/models reflects models/ELMs available through local, private or public SuperGenius capacity.
• max_cost_gnus is enforced before and during execution.
• OpenAI streaming is bridged from the SuperGenius event channel.
• Client disconnect cancels the child SuperGenius task.
• Existing SuperGenius queue ownership and locking are reused rather than duplicated.

[Super-Genius]

Scope corrected per the 2026-08-26 architecture review (SuperGenius is the scheduler; GCS only creates/funds/publishes). Runtime work split to GeniusVentures/SGProcessingManager#17 (@itsafuu). Roadmap: Phase 13 here, Phase 14 cross-repo, Phase 15 deferred — see .planning/ROADMAP.md (v1.1 extended, product-v1.0 gate).

[Super-Genius]

Phase 15 dropped — streaming (if ever needed) rides the existing gossip results channel as seq-numbered JSON events; no new protobuf. Roadmap/requirements updated (.planning commit 892c5aa).

[Super-Genius]

Added blocker: GeniusVentures/AsyncIOManager#11 (@itsafuu) — ipfspubsub:// prefix makes the gossip results channel URL-addressable through FileManager, unifying artifact + live-channel I/O for ELM results. Phase 13's results delivery depends on it.