# Ocean6 Engineering Reference v0.2 2026-09-19 · v0.2: executable local task, independent Python replay, task schema, negative tests, admission / failure-handling proposals, threat model and release evidence gates. The v0.1 authored receipt fixture remains available. Execution scope: deterministic line retrieval in this browser. No LLM, GPU, Ocean6 remote node or payment service is called. The lab code does not upload your document. ## Start with inspectable evidence Follow a task from its definition to executable code and independent replay. Each artifact states exactly what it demonstrates. ### Runnable · Local workload Edit documents and search terms, execute line retrieval, then replay independently in Python. Inspect the source, contract and negative tests./en/developers/#lab Open the task lab ↗ ### Reviewable · Engineering proposal Inspect admission, role separation, retry semantics, trust boundaries and release gates. Network behavior awaits engineering review and measurements.#admission Read the engineering details ↗ ### Traceable · Versioned files The v0.2 bundle includes implementations, a schema, documentation and checksums. The original v0.1 fixture remains available./en/developers/#source Browse release files ↗ ## Node admission & scheduling Network design proposal. Start with controlled providers and separate resource declarations, admission checks and scheduling. Reachability, eligibility and delivery require different evidence. Scroll horizontally to view all columns. | Stage | Required evidence | If a check fails | Identity & version | Provider identifier, accountable operator, runtime version, artifact digest and key registration / revocation records. | Do not admit new work until identity and artifact checks pass. | Resources & compatibility | CPU / GPU, VRAM, drivers, OS, region, connectivity and isolation settings; raw workload test logs. | Keep the node at declared status; self-reported hardware is not scheduling eligibility. | Availability & capacity | Timestamped heartbeats, remaining capacity, service probes and missing observations. | Stop new assignments on stale probes or insufficient capacity; apply deadlines to active work. | Delivery & quality | Task / attempt identifiers, artifact version, output digest, error category and a separate acceptance decision. | Record failures and require investigation before readmission. Preserve the original failed record. ### Executor Runs accepted work and submits outputs and usage claims. A provider claim alone must not mark a task accepted. ### Checker Evaluates against criteria fixed before submission, recording check version, decision and limitations. Disclose project control during any initial pilot. ### Coordinator Filters permissions, data region, resources and budget before comparing health and performance. No public scheduler or decentralized implementation is supplied here. Minimum hardware, health-check intervals, latency percentiles and prices require measured workloads. This proposal neither copies another network’s thresholds nor certifies device compatibility. ## Retries, idempotency & failure handling Proposed protocol requirements. The v0.2 local implementation covers input validation, one execution and replay. It does not implement network queues, billing or these distributed semantics. Scroll horizontally to view all columns. | Situation | Proposed behavior | Acceptance case | Duplicate submission | Bind each caller’s idempotency key to a request digest; reject the same key with different content. | Repeated requests return the original task; changed content causes a conflict. | Failure & retry | Automatically retry only explicitly safe workloads. Retain task_id and create a fresh attempt_id. | Retain both timed-out and retried attempts; do not accept the same delivery twice. | Expired lease & late output | Track active attempts and leases. Archive late receipts without automatically accepting or settling them. | A recovered old worker cannot overwrite a newer attempt. | Cancellation & physical actions | Separate cancellation request from confirmation. Device control systems constrain actions; make no global exactly-once claim. | Preserve event order for cancellation / delivery races; independently test emergency stops. | Fees & disputes | Separate usage, acceptance and payment confirmation. Agree failed-task charges and dispute rules before acceptance. | Duplicate payment notices are recorded once; no settled status without payment evidence. ## Threat model & evidence limits Local replay establishes conformance to this published algorithm. Network identity, remote execution and model quality each require their own trust source and verification method. Scroll horizontally to view all columns. | Risk | Required mechanism | This release | Modified output | Bind original input / output bytes to digests and replay deterministic work. | Python checks byte digests and replay. The browser compares algorithm results only. | Impersonation or stale receipt replay | Trusted identity registration, signatures, task / attempt binding, challenges, expiry and revocation. | Not implemented. Local receipts are unsigned and use self-reported timestamps. | Input and receipt replaced together | Pin the original task and release through a trusted channel; use signatures or an independent trust root. | The checksum manifest detects changes relative to itself, not publisher impersonation. | Nondeterministic model output | Record model, prompt and sampling settings plus evaluation data; separate semantic acceptance from byte replay. | The example uses no LLM. Matching output is not evidence of verified model inference. | Remote host sees sensitive data | Data classification, least privilege, location and retention controls; consider confidential execution under a defined threat model. | Lab code does not upload your input. No production confidential computing / TEE implementation. | Executor / checker collusion | Disclose control relationships, independent sampling, traceable disputes and scoped external audits. | No completed independent verification network or third-party audit is claimed. ## From reference code to a network service Treat launch status as an engineering claim supported by evidence. Source inspection and local execution are available now. Publish the following as real integrations mature. ### Integration pilot Versioned runtime, authentication, real test endpoints, supported workloads and provider responsibilities; passing timeout, retry and authorization tests. ### Performance report Hardware, code digest, model / dataset, sample size, concurrency, warm-up and per-run raw observations, including failed samples. ### Paid service Service terms, billing units, refunds / disputes, data retention, support and incident handling, backed by inspectable service records. ### On-chain or open network Publish network identifiers, verified contracts, privileges, upgrade policy, audit scope, admission and governance control when those functions exist./technical/v0.2/benchmark-template.csv Benchmark template (blank)/technical/v0.2/capability-template.json Capability template (proposal) ## Design references & sources Reviewed 2026-09-19. These official documents inform our engineering documentation. Listing them does not imply partnership, integration or adoption of their protocols. We have not independently verified their full implementations. io.net ### Device checks & troubleshooting Documents hardware challenges, VRAM checks and failure logs. We adapt the documentation pattern: explicit admission evidence and failure categories.https://io.net/docs/guides/workers/proof-of-work Official documentation ↗ Aethir ### Supply, checking & matching Separates Container, Checker and Indexer roles, and capacity from delivery. Our proposal makes roles and evidence categories explicit.https://docs.aethir.com/aethir-network/the-checker Official documentation ↗ Nosana ### Executable job definitions JSON describes images, commands, environment and resources, with execution and validation guides. We begin with a strictly specified local workload.https://learn.nosana.com/deployments/jobs/job-definition/intro.html Official documentation ↗ Ritual ### Execution & verification trust model Current documentation explains delegated execution, TEE attestation and nondeterministic work. We adopt explicit proof scope and assumptions, without treating a hash as proof of computation.https://docs.ritualfoundation.org/ Official documentation ↗ ## A bounded workload contract operation = literal-line-search, version 0.2. This is a retrieval baseline. It does not generate answers, measure semantic similarity or establish the truth of input content. Scroll horizontally to view all columns. | Field / rule | v0.2 behavior | Input | Accept only version, operation, document, terms and top_k; reject additional fields. | document | Unicode text, 1–20,000 UTF-8 bytes; reject lone surrogates. Normalize CRLF / CR to LF. One-based line numbers include empty lines. | terms | 1–16 strings of 1–80 Unicode code points, without newlines. Trim leading / trailing spaces and tabs, lowercase ASCII A–Z and deduplicate; normalized terms must be nonempty. | Matching | Literal substring matching per line. Only ASCII case folding; Chinese is matched literally without segmentation. Score counts distinct matched terms. | Ranking / top_k | Descending score, then ascending source line. top_k is an integer from 1–10. No matches returns an empty list. | Output | total_matches counts matching lines before truncation. matches contains line, score, text and matched_terms. Text comes from the input, not a model.