Custom Device and ODM Readiness
Architecture, product identity, evidence, commercial package, contracts, and prototype stages required before a future ODM or contract-manufactured device.
Custom Device and ODM Readiness
Architecture, product identity, evidence, commercial package, contracts, and prototype stages required before a future ODM or contract-manufactured device.
Table of Contents
- Contract Device Role
- Product Identity
- Readiness Prerequisites
- Platform Options
- Vendor Request Package
- Contract Controls
- Prototype Stages
- Community-Compatible Strategy
- Acceptance Evidence
- Planning Reference Anchors
Contract Device Role
A contract-manufactured device is a future packaging and supply-chain target for the portable Agent OS architecture. It is not used to avoid learning the hardware contracts: the project first proves them on public development targets so that an ODM engagement purchases integration and productization rather than an opaque replacement OS.
Product Identity
The future Agent OS phone is provisionally branded Shark.
- Product name: Shark
- Slogan: Safe ocean
- Primary mark: a shark fin
The fin must remain recognizable as a compact silhouette at system-icon, boot-mark, enclosure-badge, packaging, and monochrome manufacturing-mark sizes. Final artwork, geometry, trademark clearance, regional screening, and usage rules remain subject to the legal and industrial-design gates; however, ODM briefs and concept work must use this identity consistently unless a later recorded naming decision supersedes it.
The product meaning is safety and freedom inside a large, navigable digital environment: the system protects the user without turning the device into a closed or restrictive appliance. Marketing claims derived from Safe ocean must remain evidence-backed and must not imply absolute security, waterproofing, or safety certification unless the corresponding requirements and tests have passed.
Readiness Prerequisites
Before requesting quotations, Agent OS must have:
- accepted kernel and hardware-service ABI versions;
- at least two native board ports;
- a reference display/touch, camera, audio, modem, power, and update implementation;
- measurable performance, battery, thermal, and camera requirements;
- security root, key ceremony, manufacturing, update, and recovery specifications;
- source, firmware, redistribution, vulnerability, and support contract requirements;
- initial industrial-design, repairability, waterproofing, RF, antenna, and certification requirements;
- a Shark identity package covering the fin mark, enclosure placement, boot presentation, packaging, accessibility, monochrome reproduction, and manufacturing tolerances;
- realistic volume, region, schedule, target BOM, and NRE range.
Platform Options
Candidate directions include a Qualcomm QCM/QCS mobile or IoT platform with vendor support, a MediaTek platform through an IDH/ODM, an NXP/TI application processor plus external certified modem, or a Rockchip-class application processor for a Wi-Fi-first device. The best production path may accept proprietary firmware and NDA documentation while requiring native Agent OS drivers, reproducible interfaces, update rights, long-term vulnerability support, and escrow or continuity protections.
Vendor Request Package
The request for information contains target markets, volume bands, form factor, display/camera/battery/radio requirements, OS architecture, boot and security model, driver ownership, source-license expectations, firmware redistribution, update support period, vulnerability SLA, certification responsibilities, manufacturing test, calibration, repair parts, tooling ownership, NRE, per-unit cost, lead time, exit/transition rights, and the Shark product-identity package with the Safe ocean slogan and fin-mark reproduction constraints.
Contract Controls
Key controls include deliverable source and build environments, reproducible firmware packages, interface documentation, engineering escalation, defect and security SLAs, support horizon, component-change notification, substitute approval, calibration data ownership, factory key custody, audit rights, regulatory responsibility matrix, export restrictions, data processing, confidentiality boundaries, IP indemnities, and continued support if the supplier exits.
Prototype Stages
- Evaluation kit and module proof.
- Vendor reference board with native Agent OS services.
- Custom carrier board or smartphone development kit.
- EVT electrical/mechanical prototypes.
- DVT design validation and certification units.
- PVT manufacturing validation.
- Controlled pilot with field update/recovery.
- Production only after security, quality, supply, and compliance gates.
Community-Compatible Strategy
The project should negotiate a publishable community board subset, redacted interface specifications, redistributable firmware packages, and upstreamable native drivers even when full phone schematics or RF data remain confidential. A community edition and a certified product may share source above the board package while differing in confidential manufacturing material.
Acceptance Evidence
- An RFI can be sent without changing the architecture.
- Requirements distinguish mandatory, preferred, and negotiable openness.
- At least three vendor routes are commercially compared.
- Contract terms cover source, firmware, updates, vulnerabilities, supply, and exit.
- Factory provisioning and certification responsibility are unambiguous.
- Shark, Safe ocean, and the fin mark appear consistently in the product brief, industrial-design brief, boot-branding specification, and vendor package, with unresolved legal status visibly recorded.
Planning Reference Anchors
These fine-grained anchors give the execution plan stable links into this specification. They are normative pointers: the linked canonical section remains the full requirement source.
Architecture Envelope
For planning, conformance, and task cross-references, Architecture Envelope denotes the part of this specification governed primarily by Readiness Prerequisites. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Architecture Readiness
For planning, conformance, and task cross-references, Architecture Readiness denotes the part of this specification governed primarily by Acceptance Evidence. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Camera Manufacturing
For planning, conformance, and task cross-references, Camera Manufacturing denotes the part of this specification governed primarily by Vendor Request Package. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Carrier Board Stage
For planning, conformance, and task cross-references, Carrier Board Stage denotes the part of this specification governed primarily by Prototype Stages. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Certification Readiness
For planning, conformance, and task cross-references, Certification Readiness denotes the part of this specification governed primarily by Readiness Prerequisites. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Commercial Readiness
For planning, conformance, and task cross-references, Commercial Readiness denotes the part of this specification governed primarily by Readiness Prerequisites. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Community Reference Kit
For planning, conformance, and task cross-references, Community Reference Kit denotes the part of this specification governed primarily by Community-Compatible Strategy. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Contract Requirements
For planning, conformance, and task cross-references, Contract Requirements denotes the part of this specification governed primarily by Contract Controls. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Design Now
For planning, conformance, and task cross-references, Design Now denotes the part of this specification governed primarily by Readiness Prerequisites. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
EVT DVT PVT
For planning, conformance, and task cross-references, EVT DVT PVT denotes the part of this specification governed primarily by Prototype Stages. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Manufacturing Readiness
For planning, conformance, and task cross-references, Manufacturing Readiness denotes the part of this specification governed primarily by Readiness Prerequisites. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Manufacturing Test
For planning, conformance, and task cross-references, Manufacturing Test denotes the part of this specification governed primarily by Vendor Request Package. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Mechanical And Power
For planning, conformance, and task cross-references, Mechanical And Power denotes the part of this specification governed primarily by Prototype Stages. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
ODM Rfi
For planning, conformance, and task cross-references, ODM Rfi denotes the part of this specification governed primarily by Vendor Request Package. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Partner Scorecard
For planning, conformance, and task cross-references, Partner Scorecard denotes the part of this specification governed primarily by Contract Controls. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Replaceability
For planning, conformance, and task cross-references, Replaceability denotes the part of this specification governed primarily by Platform Options. Implementations using this label MUST apply the requirements, failure behavior, evidence obligations, and portability or security boundaries of that section together with any narrower task acceptance criteria.
Shark Product Identity
For planning, conformance, and task cross-references, Shark Product Identity denotes the part of this specification governed primarily by Product Identity. Implementations using this label MUST preserve the provisional product name, slogan, mark, legal qualifiers, and evidence boundaries defined there until a superseding recorded decision is accepted.