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

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)

• GeniusVentures/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 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)