# Ocean6 Technical Reference v0.1 Technical design proposal v0.1 · Pending engineering review. The reference verification example is runnable today. Architecture, onboarding and interface contracts describe a proposed design, not a live production network. Reference implementation v0.1 · An offline example, not a node client, available API or network performance proof. Receipts are unsigned; checks demonstrate consistency of this example only. ## 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 directoryRequirements / capability descriptions Specify inputs, output format, budget, data region and acceptance criteria. Register service capabilities by version.02 ### Coordination & schedulingTask states / matching / retry policy Filter providers by region, permissions, resources and budget before comparing availability. Retries retain task_id and create a new attempt_id.03 ### Execution adaptersModel APIs / compute / external systems Use adapters for distinct execution environments. Software, compute and physical instructions require different permissions and operating limits.04 ### Delivery & evidenceContent digests / versions / receipts Link inputs, outputs, execution context and acceptance decisions. Digests detect changed bytes; service quality needs separate acceptance rules.05 ### Metering & settlementUsage / acceptance / reconciliation Separate 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. submitted ### Submit Freeze the task version, input digest and acceptance profile. accepted ### Accept Confirm capabilities, cost limits and execution deadline. running ### Execute Record the execution attempt and runtime context. delivered ### Deliver Return the result location, digest and usage record. validated ### Evaluate Accept delivery against previously agreed criteria. settled ### Settle 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. ## 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. ## 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.Run the reference example ## 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. ## 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. ### Reference materials v0.1Inspectable Bilingual architecture, data structures, fixtures and verification code. ### Receipt verification exampleReproducible Browser and Python checks for fixed fixture digests, record correlation and state transitions. ### Node runtime / public APIEngineering evidence required Versioned download, installation guide, endpoint, authentication and integration tests. ### Network & smart contractsEngineering evidence required Network identifiers, addresses, verified source, permissions and upgrade policy. ### Performance / security reportsEngineering evidence required Raw measurements, reproducible environments and a scoped independent audit. 2026-09-19 · v0.1: technical design proposal, reference data contract, fixed fixtures, Python and browser verifiers. This release covers documentation and a reference implementation, not completion of the core network. ## 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 ## Reproduce the example Use Python 3.9+ with no third-party dependencies. Extract the reference bundle and run the commands below from its directory. Change result.txt and rerun: the digest check should fail. python3 verify_receipt.py example.json result.txt input.txt # PASS: offline fixture integrity, correlation and lifecycle checksDownload reference bundle ## Verify the fixture in your browser Calculate SHA-256 over the original UTF-8 bytes of result.txt, then check transitions, record correlation and timestamp order. The tamper demonstration changes an in-memory copy only.Verify original fixtureTest tamper detectionReady to verify. No wallet connection or transaction will occur. Download the Python example to verify without JavaScript. ## Proposed data contract These fields support integration design discussions. They are not an available API. Submission endpoints, authentication, limits and signing protocols require a separate engineering release. Scroll horizontally to view all columns. | Field | Definition | task_id / attempt_id | Stable task and independent attempt identifiers. Retries preserve history. | input_sha256 | Digest of the input file's original bytes, not arbitrary reserialized JSON. | acceptance_profile | A versioned acceptance method fixed before execution. | output_sha256 | Digest of the delivered file's original bytes. | provider_id / runtime_version | Declared provider and environment; this example does not authenticate either. | events | Ordered states and UTC timestamps for this attempt. | settlement | Proposed payment record; null in this example. No real payment.example.json · receiptUNSIGNED FIXTURE { "task_id": "example-task-001", "attempt_id": "example-task-001-a1", "provider_id": "example-provider", "runtime_version": "offline-fixture/0.1", "output_sha256": "a84ccddc948c4d9400b7f3bf22ff5a0e6cf02b3e9b5b1a657d1922871de0df2a", "delivered_at": "2026-09-19T00:00:03Z", "status": "delivered", "settlement": null } ### What does the verifier establish? It checks required reference fields, identifier correlation, supported transitions, UTC time ordering, delivery time and the output digest. It is not a general JSON Schema engine. It does not validate provider signatures, model execution or payment. If an attacker replaces both receipt and output, a digest alone cannot detect fabrication; a production system needs trusted signatures or another independent trust source. ## Versioned downloads Download individual files or the complete reference bundle. SHA256SUMS.txt checks download integrity; it does not independently authenticate the publisher.Ocean6-Technical-Reference-v0.1.zip ↓Technical-Design-CN.md ↓Technical-Design-EN.md ↓example.json ↓fixture.schema.json ↓input.txt ↓result.txt ↓verify_receipt.py ↓technical-verify.mjs ↓SHA256SUMS.txt ↓RELEASE.md ↓ 2026-09-19 · v0.1: technical design proposal, reference data contract, fixed fixtures, Python and browser verifiers. This release covers documentation and a reference implementation, not completion of the core network. ## 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