Runnable · Local workload
Edit documents and search terms, execute line retrieval, then replay independently in Python. Inspect the source, contract and negative tests.
Open the task lab ↗OCEAN6 / TECHNICAL DESIGN / 0.2
Make every delivery inspectable.
From task definition and resource admission to execution and acceptance: explore the system design, runnable reference workload and explicit technical boundaries.
Engineering reference v0.2 · Local execution, source and replay tools are published. Network architecture, node admission and settlement remain proposals awaiting engineering review and operational evidence.
Start with inspectable evidence
Follow a task from its definition to executable code and independent replay. Each artifact states exactly what it demonstrates.
Reviewable · Engineering proposal
Inspect admission, role separation, retry semantics, trust boundaries and release gates. Network behavior awaits engineering review and measurements.
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.
Browse release files ↗System architecture
Separate service coordination from execution. Model providers, compute operators and device control systems have distinct responsibilities. Each handoff should leave a correlated record.
01
Requests & service directory
Requirements / capability descriptionsSpecify inputs, output format, budget, data region and acceptance criteria. Register service capabilities by version.
02
Coordination & scheduling
Task states / matching / retry policyFilter providers by region, permissions, resources and budget before comparing availability. Retries retain task_id and create a new attempt_id.
03
Execution adapters
Model APIs / compute / external systemsUse adapters for distinct execution environments. Software, compute and physical instructions require different permissions and operating limits.
04
Delivery & evidence
Content digests / versions / receiptsLink inputs, outputs, execution context and acceptance decisions. Digests detect changed bytes; service quality needs separate acceptance rules.
05
Metering & settlement
Usage / acceptance / reconciliationSeparate resource use, task fees and network incentives. Accepted delivery becomes eligible for settlement; payment confirmation is recorded separately.
Explicit trust boundaries
Off-chain execution
This proposal keeps input data, scheduling, computation and detailed logs off-chain. On-chain registration, payment or evidence anchoring requires a defined network and contract design; no contract addresses are published here.
Physical control
Ocean6 coordinates service requests. Dedicated control systems remain responsible for robot motion, safety interlocks and emergency stops. A general-purpose agent must not bypass them.
Network admission
The initial pilot should use controlled provider admission. Open participation, decentralized scheduling, independent verification and governance each require their own implementation and test evidence.
Task lifecycle
Delivery, acceptance and payment are separate events. Each execution attempt has its own state history; a retry must not overwrite a failed attempt.
submittedSubmit
Freeze the task version, input digest and acceptance profile.
acceptedAccept
Confirm capabilities, cost limits and execution deadline.
runningExecute
Record the execution attempt and runtime context.
deliveredDeliver
Return the result location, digest and usage record.
validatedEvaluate
Accept delivery against previously agreed criteria.
settledSettle
Confirm payment separately; a matching digest does not trigger it.
Exception paths: submitted may become rejected or cancelled; accepted may become failed, cancelled or expired; running may become failed, cancelled or expired; delivered and validated may become disputed. A retry creates a new attempt_id. failed, cancelled, expired, rejected and disputed are terminal in this reference version. Dispute resolution requires a subsequent protocol.
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. |
Nodes & execution environments
A reachable node has not necessarily performed AI work. Eligibility should depend on a defined workload, compatibility and measured performance.
Scroll horizontally to view all columns.
| Role | Execution scope | Checks before admission |
|---|---|---|
| Model service adapter | Call external or self-hosted models | Declare provider, model version, request identifiers, output format and metering. Test error handling, deadlines and permissions. |
| Compute worker | Execute approved workloads | Declare CPU / GPU, VRAM, RAM, OS, drivers, available disk, connectivity, region and runtime. Validate with a fixed workload suite. |
| Device & industry gateway | Connect physical and industry systems | Document protocols, permitted actions, operational responsibility, safety conditions and human takeover. Local control systems constrain physical execution. |
No verified minimum specification, supported-device list or node installer is published in this technical centre yet. Hardware pricing, compatibility, availability measurement and incentive eligibility require separate confirmation.
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.
Verification & security
Each evidence type answers a different question. A digest, signature, acceptance decision and security audit are not interchangeable.
Scroll horizontally to view all columns.
| Mechanism | Can check | Cannot establish alone | This release |
|---|---|---|---|
| SHA-256 content digest | Downloaded bytes match the receipt's declared digest | Correct content, actual model execution or provider identity | Runnable reference example |
| Receipt & identity signature | Who claimed a delivery and which version was declared | The truth of the underlying claim | Structure proposed; no signing service supplied |
| Workload acceptance | Output meets the agreed task requirements | Correctness across all unknown conditions | Proposed acceptance approach |
| Independent checks / trusted execution | Additional assurance for specific computation or environments | Security beyond the stated threat model | Research direction; no implementation claim |
| Third-party security audit | Findings for a particular code version, scope and date | Absolute security of future versions or the entire network | No audit report supplied in this centre |
Least privilege
Keep provider credentials server-side, grant task-scoped permissions and support revocation. Do not place private keys or long-lived API secrets in the browser or task input.
Workload isolation
The proposed design uses constrained execution, resource quotas and network allowlists. Isolation must be validated against the actual runtime and escape tests.
Data & logs
Do not write raw customer inputs and results to a public chain by default. Agree on region, retention, deletion and authorized access in the service terms.
Human control
Define approval boundaries for payments, permission changes and physical actions. Task cancellation and device emergency stops need distinct responsibilities and mechanisms.
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. |
Performance & acceptance methodology
Publish the measurement method before the numbers. Every result should identify date, code revision, hardware, runtime, workload, concurrency and raw logs. No Ocean6 production performance figures are published here.
Scroll horizontally to view all columns.
| Metric | Definition | Required disclosure |
|---|---|---|
| Task success rate | Accepted tasks / eligible terminated tasks | Disclose failure, cancellation, timeout and rejection counts. In-flight tasks are excluded from completion-rate denominators. |
| End-to-end latency | Submission-to-delivery time, reported as p50 / p95 | Separate queue, execution and transfer time. Include sample size, concurrency and warm-up conditions. |
| Inference performance | Time to first token and output tokens / second | Fix model, quantization, input / output length and hardware. Do not rank unlike models as if they were identical. |
| Cost per task | Compute, model calls, bandwidth and service fees | Separate paid costs from subsidies. Record currency, quote time and failed-task costs. |
| Node availability | Valid observed online intervals / expected intervals | Disclose the observation window, sampling frequency and missing observations. Availability does not prove delivery. |
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 materials & release status
Inspectable materials are listed with the limits of what they demonstrate. Product plans, testnets, installers and production services require separate release records.
Local workload v0.2
Source and tools publishedBrowser execution, independent Python replay, task schema, boundary and tamper tests.
Network engineering specification
Design proposalAdmission, role separation, retries, idempotency, threat model and release gates; not implemented network features.
Node runtime / public API
Implementation and integration evidence pendingVersioned installer, identity and authentication, available endpoints, support matrix and integration tests.
Network & smart contracts
Network and contract evidence pendingNetwork identifiers, inspectable records, source, privileges and upgrade mechanism.
Performance / independent audit
Measurements and external reports pendingReal workload logs, reproducible environment, failed samples and a scoped third-party audit.
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.
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.
Official documentation ↗Aethir
Supply, checking & matching
Separates Container, Checker and Indexer roles, and capacity from delivery. Our proposal makes roles and evidence categories explicit.
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.
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.
Official documentation ↗Contribute a technical review
For workloads, integration requirements or existing technical evidence, include the reference version and section in your enquiry. Do not email private keys or sensitive customer data.
business@ocean6.ai