Bring your brand, target market and wearer task. SmartXY helps established brands, channel partners and enterprise teams assess a current platform for OEM branding or define an ODM/JDM development scope. Start with a non-confidential brief; agree feasibility, deliverables, validation and commercial terms before committing to development or production.
At concept stage, define the wearer task, market and business owner. During platform evaluation, identify the sample configuration and the decision it must support. Before custom development or a pilot build, agree technical owners, budget, acceptance criteria and unresolved dependencies. An initial inquiry may leave inputs unknown; it is not a feasibility or delivery commitment.
Review K900 and C100 for camera-and-audio project requirements, or Audio 01 for audio-only ODM. These routes do not provide an in-lens visual display. Identify what must be captured or heard, and confirm the selected app, SDK, phone and network dependencies. A camera specification does not establish a standard live-streaming interface.
Review AR99 and AR99 MY for camera-free, phone-tethered display requirements. Define the text or visual cues, viewing conditions and interaction needed. Display hardware does not establish every requested SDK function; combined camera-and-display requirements need a separate platform and engineering review.
Standard-model OEM starts with an agreed product configuration, brand and packaging. Platform-based ODM adds specified changes such as ID/CMF, mechanics, firmware or app integration. Identify retained components, requested changes, interface access and rights separately; public platform features are not blanket customization promises.
A new architecture, optical system or combined feature set requires a separate feasibility and development scope. Agree design inputs, hardware/software ownership, tooling, validation and commercial terms before approving work. Full custom development is not included in a branding order or established by a reference-platform demonstration. Review the dedicated development programme.
Plan the next decision: requirements review → prototype/EVT → DVT → pilot/PVT → production release. Each agreed stage needs identified outputs, evidence, open issues and an acceptance owner. Review the delivery checklist before committing to the next phase.
Buyer questions: What to send · Customization boundaries · What samples validate · MOQ, NRE and timing · Stage readiness.
GLOBAL AI EYEWEAR DEVELOPMENT PARTNER
Explore three eyewear platforms, the engineering and reliability workflow, four SDK integration layers and the Premium ODM Development Program for highly customized products.
Explore Custom AI Eyewear DevelopmentStandard-platform OEM purchasing and existing SDK policies retain their own project scope.
Choose standard-model OEM for an agreed product with your branding, or ODM for a defined customization project. JDM and technology transfer add deeper engineering or capability handover when the business requires it.
Select a current SmartXY model and agree your logo, packaging, product configuration and purchase plan. Any requested software or hardware changes are reviewed separately.
Start from an agreed SmartXY platform, then scope POC, PRD, ID/CMF, CNC Function Prototype, UI, firmware protocol/app, regional certification, and packaging.
Co-engineer a differentiated product on a SmartXY base platform — hardware options, chips, optics, firmware/app scope and regional compliance defined per project.
For qualified partners investing in an engineering team or local manufacturing. Scope authorized source, design, process and test documentation with training and staged acceptance.
When the customer controls the design, begin with authorized drawings, BOM, revision history, manufacturing rights and acceptance requirements. Review manufacturability, supply responsibility, test fixtures and change control before agreeing a build-to-print scope. A standard-platform branding request does not automatically include customer-design manufacturing, engineering changes or source rights.
A sample evaluates a named hardware, firmware and software configuration against your workflow. It does not establish production readiness or include every interface, source right or customization.
Choose the platform and required task. Confirm sample availability, build versions, included SDK/App, accessories and known limitations. For a current standard configuration, a business owner can lead the request; engineering ownership is needed for changes.
Record the sample quantity, separate hardware and software charges, delivery contents, support scope and test plan before ordering. Confirm any loan, return or replacement terms in the quotation; no common policy is assumed.
Record test conditions, results and open issues. Both teams decide whether to use the standard configuration, commission defined engineering work or stop the evaluation. Pilot and production commitments require their own agreement.
| Cost category | Confirm in the proposal | Responsibility to agree |
|---|---|---|
| Hardware samples | Build, quantity, accessories, included tests and sample terms | Buyer approves the evaluation configuration; supplier identifies what ships. |
| Engineering / NRE | Specific hardware, firmware, SDK or App changes, milestones and acceptance | Named technical owners approve the statement of work and change requests. |
| Molds, tooling and fixtures | Design, ownership, maintenance, validation and any reuse limits | Agree funding, custody and release conditions by item. |
| Certification and testing | Model, version, market, test scope and retest assumptions | Confirm applicant, laboratory coordination and who funds changes. |
| Third-party licenses | Component, SDK, codec or service rights and recurring charges | Identify license holder, permitted use and renewal owner. |
| App and cloud services | App delivery, accounts, model/API usage, hosting, updates and support | Customer-operated services and separately commissioned supplier work are listed distinctly. |
| Production units | Approved configuration, order volume, packaging, inspection and spare parts | Agree order acceptance, quality release and after-sales responsibilities. |
| Logistics and taxes | Shipping basis, insurance, import duties, taxes and local handling | Confirm importer, carrier arrangement and payer in the commercial terms. |
The C100 standard Android SDK policy remains separate from sample hardware and paid SDK modifications. Any published minimum development fee applies only to its named service and scope, not every SDK request or hardware purchase. A previous customer budget is not a universal fee schedule.
Request C100 standard SDK · Evaluate a K900 sample · Discuss AR99 branding · Scope custom development
SmartXY has undertaken customer ODM projects using K900 and EG01 as starting platforms. This experience can help your team reduce repeated exploration, trial and error, and the hidden costs of bringing a new smart-glasses product to life.
K900-based brain–computer interface (BCI) integration for a customer ODM project.
EG01-based audio glasses developed through ODM for people with hearing loss.
K900-based ODM work adding a temperature sensor alongside blood-oxygen and heart-rate monitoring.
Build on prior integration experience to identify requirements earlier and focus engineering effort on what is specific to your product. The aim is less repeated work and a clearer development plan.
Customer project features are scoped separately from standard platform specifications. Reuse, software rights, validation, NRE and timelines are agreed for each new project.
Find the project-fit notes and RFQ requirements for your product category, branding model or target channel.
To compare practical changes, responsibilities and delivery boundaries, read Vanda’s personal OEM, ODM and JDM guide.
Agree SmartXY's deliverables, the customer's inputs and the acceptance owner for each stage of the customization project. The stages below help define that statement of work. Standard-model OEM follows its branding, configuration, validation and order plan without requiring a new product-development project.
Market scope, specs, ID/CMF, certification, budget and launch schedule.
Chipset, OS, power, camera/audio, optics, SDK/API and OTA plan.
ID, mechanics, electronics, firmware, app and algorithm interfaces.
CNC, 3D print, PCB/FPC samples, dev boards and interaction validation.
Functional, DFM, optical, electronic, acoustic, thermal and reliability validation.
Trial build, process validation, yield metrics, reliability reports and certification.
Yield ramp, agreed traceability records, QC plan, packaging, logistics and lifecycle responsibilities.
Use these gates in a SmartXY supplier review to agree decisions, identified builds and an acceptance owner before committing the next project phase. This is a planning framework, not a statement that a platform has passed every gate. Standard-platform procurement follows the agreed configuration and order plan; it does not require a new development programme from the beginning.
| Stage | Main objective | Customer input to agree | Validation output to review | Condition for the next stage |
|---|---|---|---|---|
| Requirements | Define the product and evaluation scope. | User task, target market, budget status, target quantity and timing; identify unknowns and decision owners. | Agreed configuration, responsibilities, acceptance targets and evaluation plan | Both teams agree scope, responsibilities and the evaluation plan. |
| Engineering validation (EVT) | Show that the chosen architecture performs the key task. | Priority use cases, app/service interfaces, intended conditions and functional acceptance criteria. | Identified prototype, interface results and unresolved risks | The key task is demonstrated on the named build; open risks have owners and an agreed disposition. |
| Design validation (DVT) | Verify the intended design against agreed conditions. | Design and configuration decisions, market/compliance scope, reliability criteria and EVT issue decisions. | Configuration-specific test and reliability evidence | The intended design meets the agreed criteria or documented exceptions are accepted by the responsible authority. |
| Production validation (PVT) | Verify that the process repeats the accepted result. | Pilot quantity, inspection criteria, packaging/label requirements and traceability needs. | Pilot-build records, inspection methods and traceability | The agreed production process and inspection evidence support the planned build. |
| Mass-production release (MP) | Authorize the identified configuration for agreed delivery. | Order and shipment scope, acceptance authority, approved exceptions and support responsibilities. | Release criteria, change control and support arrangements | The designated acceptance owners authorize the identified configuration and delivery scope. |
Record the result, open issues, evidence location and acceptance owner in the blank delivery checklist. Timing, test limits and commercial commitments are agreed per project. Use the ODM manufacturing guide to prepare your brief.
A failed check or design change may require rework and another review of an earlier gate. Component availability, tooling readiness, supplier changes, applicable testing and customer decisions can change the plan; confirm their owners and dependencies before committing a schedule. These are planning requirements, not completed project results or a fixed delivery timeline.
Use this blank checklist to agree the delivery scope for your SmartXY project phase. Every item starts unfilled; it is not a completed quality record, a certification or evidence of customer acceptance. Scope, owners and acceptance limits must be agreed before a gate review.
Project / platform: ______ Stage (EVT / DVT / PVT): ______ Review date: ______
Hardware / firmware / SDK / App versions: ______
Supplier owner / customer owner / acceptance authority: ______
| Deliverable | Artifact / revision | Owner / due date | Acceptance condition |
|---|---|---|---|
| Version baseline, drawings / CAD and BOM | To fill: ______ | To fill: ______ | To agree: ______ |
| Change log and implementation evidence | To fill: ______ | To fill: ______ | To agree: ______ |
| Test plan, conditions and result summary | To fill: ______ | To fill: ______ | To agree: ______ |
| Defect list, closure evidence and open exceptions | To fill: ______ | To fill: ______ | To agree: ______ |
| Gate decision and customer acceptance record | To fill: ______ | To fill: ______ | To agree: ______ |
| Packaging, labels, accessories and shipping configuration | To fill: ______ | To fill: ______ | To agree: ______ |
Record pending, complete or not applicable with evidence and an owner; record test outcomes explicitly. Receiving CAD does not show implementation; implementation does not show a passed test; a passed test does not show customer acceptance.
EVT: agree functional and interface evidence on the named prototype. DVT: agree design and reliability evidence for the intended conditions. PVT: agree process, inspection and shipment-configuration evidence on the pilot build.
For every phase, fill measurable pass criteria, open defects, approved exceptions and next-step owners. Only the authorized customer representative can complete the customer-acceptance state. This public template contains no customer files or test results.
For Embodied AI Data Capture Glasses, the XY-DC Reference Architecture defines a display-free ODM evaluation direction. Begin with the dataset workflow and engineering acceptance criteria, then agree feasibility, prototypes and validation milestones. Tooling, calibration-station design and production-line integration are scoped per project.
Evaluate rigidly mounted forward stereo cameras, sensor-level trigger alignment and the ISP/MIPI integration path. Define how frame timestamps and inertial samples relate to the capture clock. Document the sensor and host interfaces, then measure synchronization error and timestamp behavior on the agreed prototype.
Define intrinsics, extrinsics, distortion and rectification outputs, serial-number association and machine-readable delivery. Scope the calibration station, tooling and line integration as project work. Agree calibration procedures, output formats, acceptance criteria and repeatability checks before committing production delivery.
Evaluate wrist, body-worn or tool-mounted companion capture modules as separate development items. Define the relationship between head-unit and companion clocks, reconnection behavior and cumulative drift. Measure alignment and drift across the intended recording duration and wireless conditions; no synchronization accuracy is published.
Model concurrent camera capture, encoding, storage and periodic upload against the requested working-shift duty cycle. Review battery architecture, heat paths, fit and the resulting weight budget together. Validate recording duration and thermal behavior under the agreed workload and environment before confirming device specifications.
Evaluate an externally visible mechanical camera shutter and a mechanical microphone mute. Define how each control changes capture state and how the wearer and people nearby can verify that state. Review the physical controls and capture-state behavior alongside the project owner's consent, retention and intended-use requirements; hardware alone does not establish deployment compliance.
Evaluate secure-element signing at capture, key ownership, controlled provisioning and verification by the receiving system. Include relevant cryptographic and intended-use review in project definition. Agree the threat model and recording-integrity checks, then validate the signing and verification path on the selected hardware and software.
The XY-DC Reference Architecture is separate from existing camera and display products. Component selection, sample scope, quantities, commercial terms, development schedule and acceptance evidence are agreed per project. No fixed runtime, calibration accuracy or standard secure-element capability is published.
SmartXY uses an IPD-inspired lifecycle adapted for lightweight, high-speed smart-eyewear projects. Each phase has entry/exit criteria — when criteria are not met, the project does not move forward blindly.
Cross-domain co-initiation across acoustics, optics, electronics, software, hardware, structure and supply chain.
High-frequency prototype iteration with DFM embedded before design lock.
EVT, DVT and PVT gates establish KCP controls to pre-identify and mitigate risks.
Trial-production review, yield ramp-up, test-tooling finalization and MP execution.
For strategic projects, the most important deliverable is a traceable decision system that lets both teams see risks early and close issues fast.
Requirement intake, solution design, key-device selection, development and testing validation are fully visible.
Customer participation in architecture, interface definition, BOM decisions and optical/HW/SW routing.
Drawings, documentation templates, code specs, material control, version management and test standards.
A dedicated PM and technical lead per project to reduce cross-department communication overhead.
Progress visibility, risk controllability, clear accountability and traceable milestones.
Decisions, risks and versions visible end-to-end — the core of low-risk co-development.
Daily development plans, weekly project sync, technical review, monthly retrospective, code review, release review and version change logs with impact scope, timing and rollback strategy.
Requirements → proposal → design → test → MP review with full-process documentation and version control.
NDA, software copyright and IP-ownership agreements define cooperation boundaries before deep development.
Role-based access control, permission hierarchy and immediate revocation upon personnel departure.
Dedicated code repository per client project with strict isolation from other projects.
Independent development, testing and delivery/release environments.
Agree the delivery format for each component: documented API, binary, authorized source or a continuity arrangement. Third-party rights and signing-key ownership remain explicit.
Logging of code access, download, commit and artifact transfer for a complete audit trail.
Define data minimization, least-privilege access and the processing location for sensitive data according to the selected platform and application.
Define cost, order, procurement, inventory and quality records required for the agreed project.
Agree the BOM revision, material records, inspection evidence, warehousing records and reporting owners.
Define serial or lot identifiers, required process parameters and error-proofing evidence; confirm implementation on the selected line.
If system integration is required, agree the data fields, access, owner and validation. Availability and deployment status need project-specific confirmation.
Timeline depends on optical complexity, certification scope, tooling, firmware/app/cloud integration and requirement-change discipline. The earlier requirements are frozen, the lower the downstream cost and schedule risk.
| Stage | Key output |
|---|---|
| ID design | Concept, 3D, CMF and wearing experience |
| Mechanical structure | Stack-up, hinge, IP-rating strategy and ergonomics |
| HW + SW development | Schematic, drivers, app, SDK/API and OTA |
| Prototype & validation | CNC, 3D print, tooling validation and reliability tests |
| Manufacturing release | SMT, assembly, QC, PVT, yield ramp-up and MP release |
Bring one task and name the decision your next sample needs to support. Start with what is known; mark the rest Unknown. You do not need a video, a purchase order or a completed test program to begin an inquiry.
Who does the work, in what conditions, and where does the task start and end? Describe the operator's role and the result they need.
List the tools and actual steps used today. Note the main difficulty, interruptions, corrections and rework. Separate observed events from reported experience and assumptions.
State what must be captured, heard or displayed, and how the glasses, phone and other systems need to exchange data. Include interface, network and permission constraints; do not assume an SDK function is available.
Name the decision a sample should inform and the comparison that matters. A demonstration can guide the next check; it is not evidence of adoption or a production acceptance result.
Name who evaluates the task, who accepts the agreed work and who makes the commercial decision. Keep these roles separate when different people hold them.
Include budget status, volume forecast, timing aims, data-use limits and unavailable information. Identify which inputs are confirmed and which need review.
Send a non-confidential summary through the existing inquiry route. Do not include private recordings, personal data or third-party material without permission. SmartXY handles formal quotations, sample orders, ODM contracts and delivery through its existing business process.
Method contribution: Vanda Zhao / VandaGeek. Read Vanda's prototype-readiness method and workflow checklist for the reasoning behind the brief. This is proposed evaluation guidance, not a formal industry standard or a report of a customer trial. Updated .
Discuss your pilot brief with SmartXYCompare the same task and configuration. Review runtime conditions, feature data paths, SDK behavior and acceptance evidence before agreeing a project commitment.
These questions are evaluation guidance, not verified specifications. Editorial guidance only. No author-run device test or product performance result is reported. See the battery and thermal evaluation guide and SDK integration checklist.
Tell us who will use the glasses, the main task, target market and project stage. Detailed specifications can be agreed during evaluation.
Share your channel or deployment plan, purchasing or project budget, expected volume and business owner. Choose standard-model OEM or ODM customization; technical ownership is needed for a development scope. Personal purchases, price-only one-off sourcing and development without a budget are outside this enterprise service.