Buyer Guide · Obligations & Ownership
What a Buyer Must Own in a Custom Wearable Project
A development partner can design, build and document your product. It cannot carry your brand, publish your claims or stand in your place in front of a market or an end customer. This guide sets out the obligations that survive the project and stay with you — as duties with an owner, not as services to be outsourced. If you have not yet read the process these obligations attach to, start with how a private-label wearable project runs; the capability scope and the responsibility split are on the OEM & ODM overview.
This is not legal or regulatory advice, and it does not tell you which rules apply to your product in your market. It tells you which questions are yours, what each one is discharged by, and where this site will not pretend to have an answer.
The development relationship ends at handover. The brand obligations do not.
1. "Owning the Product" Is Not One Thing
Brand owners usually discover what they own by discovering what they do not. That is the most expensive way to find out, because the discovery tends to happen during a launch — when the app listing turns out to sit in somebody else’s account, or a market asks for a document nobody assembled, or an end customer asks a question nobody is staffed to answer.
Ownership decomposes into seven parts. Each one is settleable in writing before design freeze, and each one is considerably harder to acquire afterwards. The third column is the practical consequence that makes the item worth a line in the agreement rather than a paragraph in a meeting note.
| What You Own | What It Consists Of | The Practical Consequence |
|---|---|---|
| Brand identity & label | The name, the mark and the artwork that physically carries both — the one artefact where your identity and your claims meet. | Label artwork control. Printed content drifts from the approved claim set unless somebody owns the file. |
| The design & its records | The industrial and structural design direction, the platform configuration record, and the drawings that describe what the product is. | Decide in writing who holds the records and in what form, before design freeze rather than at handover. |
| The claim set | The statements you are permitted to publish about the product, in the markets you intend to serve. | Governance, not just approval: a claim set that is not re-opened when the specification changes is no longer a claim set. |
| The app listing & publisher identity | The store listing, the publisher account and the update path the end user actually interacts with. | Not confirmed — who holds the listing and the publisher identity, which languages are supported, and who pushes updates are all unresolved in the source material. |
| The end-customer relationship | Who the customer bought from, who they contact, and who is accountable to them when something does not work. | This is the obligation that most often arrives unplanned, because it is invisible during development. |
| The spares arrangement | What is stocked, by whom, and how a wear part — strap, airbag, sizing set, sensor consumable — is replaced. | No spares-availability figure, turnaround or warranty period is published on this site because none is verified. |
| Continuity terms | What happens to the product, the app, the installs and the tooling arrangement if the development relationship changes. | An unwritten continuity position is an unbounded exposure, and it is cheap to write down early. |
Two of the seven deserve their own note. The app listing is the item buyers most often assume they hold — and its ownership is Not confirmed here, which is exactly why it belongs in the agreement rather than in an assumption. The end-customer relationship is the item buyers most often plan for last, even though it is the only one that arrives with a legal obligation and a cost attached. The project guide covers the stage sequence these decisions have to fit inside.
2. The Obligation Register
Four obligations, each with an artefact that discharges it and, more usefully, an explicit statement of what it does not discharge. The fourth column is where most of the value sits: every one of these obligations is commonly mistaken for something it is not.
| Obligation | The Duty | Discharged By | The Question It Answers | The Question It Does Not Answer |
|---|---|---|---|---|
| Technical file | Be able to produce the documentation set that describes the product you are placing on a market, and to keep it describing the product that actually ships. | The categories below, each held by the brand owner, with the scope line on every document read before it is repeated. | What the product is, what configuration was built, and which records apply to which named model. | It does not authorize the product for any market, and a factory or process document is not a product authorization. |
| Claim governance | Keep the published claims, the printed claims and the product that ships describing the same thing. | An approved claim set, written before artwork is produced, and a rule about who may change it. | Who approved what may be said, and on what basis. | It does not make a claim supportable. A claim the product cannot support is not fixed by governing it better. |
| Label & branding control | Control the artwork, the printed claims and the serialisation that carry your identity. | A controlled artwork file and a stated owner for it on your side of the table. | What appears on the product, the packaging and the accompanying material. | It does not resolve the labelling and import obligations of the market the goods ship into — those follow from where you sell. |
| Change control | Ensure that any change to the configuration re-opens the technical file and the claim set rather than silently invalidating both. | A written rule naming who may request a change and what it re-opens. | Whether the documentation still describes the product that is being built. | It does not prevent a change from costing money. It prevents a change from being invisible. |
3. The Technical File — Categories, Not a Checklist of Documents
The most useful thing that can be said about a technical file is what each part of it is for. A list of documents without the questions they answer produces a folder, not a file — and a folder is what gets assembled in the last week of a project, from whatever happens to be available.
| Document Category | The Question It Answers | The Question It Does Not Answer |
|---|---|---|
| Requirement record | What the product was required to be and do. | It does not prove the shipped product meets it. |
| Design & drawing records | What the product physically is, and the interfaces between its parts. | It does not tell you which production steps are outsourced, or who is accountable at each. |
| Platform configuration record | Which hardware and firmware configuration was frozen and built. | It does not guarantee that configuration remains available for a future order. |
| Device-level declaration or conformity documentation for the named model | Which declarations apply to which named model and which directive each covers. | It does not establish authorization to place the product on any market, and it does not extend to a differently configured variant. |
| App build & release records | What software version shipped and what it presented. | It does not establish who owns the store listing, the publisher identity or the update path. |
| Packing & kit definition | What ships in the box and which configuration that kit corresponds to. | It does not resolve labelling or import obligations in the destination market. |
| Label artwork control record | That printed content is traceable to an approved version. | It does not make the content compliant with any specific market rule by itself. |
The scope rule, and why it is the whole point read this twice
The failure pattern in this category is almost never a missing document. It is a genuine document read out of scope — a real record, correctly issued, treated as covering more than it does. Read the scope line and the holder before repeating a document’s existence as reassurance.
Stated plainly: a factory or process document is not a product authorization. A production licence and a quality-management certificate describe the environment a product comes out of, within a stated scope, and a bounded scope is a limitation rather than a formality. Certificate titles with the original documents unchanged are shown on the certifications page.
4. The Market-Authorization Duty Sits With You
This is the single most consequential item in this guide, and the one buyers most often get wrong in the most expensive direction: assuming that a supplier’s certificates cover the product they are selling under their own brand. They do not.
The principle is straightforward. The party that places a product on a market under its own identity holds the market-facing authorization duty, along with the labelling and information obligations that attach to it. The development partner holds something different in kind: factory-and-process documents, within their stated scopes, and the development work itself.
| Item | Held By | What It Means in Practice |
|---|---|---|
| Placing the product on a market | The brand owner — the party that puts the product on the market under its own identity. | Whichever market you intend to serve, the duty that attaches to placing a product there follows the product you place, not the supplier you bought it from. |
| Labelling and accompanying information | The brand owner, in the form the destination market requires. | The product carries your identity; the information obligations that come with it are yours to satisfy and to keep current. |
| Design, development and production | LUROGEF, within the documented capability scope and the agreed project scope. | This is the development work itself, and it does not include a market-facing authorization duty. |
| Factory and process documentation | LUROGEF, as the holder, within the stated scope of each document. | These documents describe an environment and a scope. They are published as certificate titles with the original documents unchanged, never with a reassigned holder name. |
| Which markets, and which duty in each | The brand owner, with their own regulatory advisers. | This page states the allocation principle and deliberately does not answer it for your product. It is not legal or regulatory advice. |
What the factory documents are, and what they are not
Four document families exist on this site’s evidence base. Each is shown publicly as a certificate title with the original document unchanged — no entity narrative is added and the certificate holder name is never reassigned. The right-hand column is the boundary that matters.
| Document Family | What It Covers | What It Does Not Establish |
|---|---|---|
| Medical-device production licence | The licence scope and category under which production is carried out, and the licence validity window. | It describes a production environment within a stated scope. It is not authorization for any product, in any market, and it does not transfer to a brand owner by being referenced. |
| Quality-management system certificate (ISO 13485) | The design and production scope the certificate covers, and the certificate validity window. | It evidences a quality system within a stated scope. It is not a product certificate, not a market approval, and not evidence of clinical performance. |
| specialised-enterprise recognition | A recognition status within a stated validity window. | It is not a product claim, not a regulatory authorization, and not a statement about any device. |
| Directive declarations (red, RoHS) for named models | Which named models are covered, and which directives those declarations address. | They address the named directives for the named models only. They do not establish medical-device approval or a registration in any market. |
No product on this site is claimed certified or registered in any market. Which markets you intend to enter, and the duty that applies in each, is a question for your own advisers. This page names the allocation; it does not answer the market question for you, and it should not be used as if it did.
5. Claim Governance and Label Control — One Mechanism, Not Two
Claims and labels are usually treated as separate workstreams — marketing owns the claim, packaging owns the label — and that separation is precisely how they drift apart. They are one mechanism with three parts, and the third part is the one that is almost always missing.
- An approved claim set, written before artwork exists. What you are permitted to say, in the markets you intend to serve. Writing it after the artwork means the artwork is the source of truth, which is backwards and expensive to reverse.
- Label artwork control. A single controlled version, with a stated owner on your side. The failure this prevents is not a wrong claim — it is a right claim in the marketing copy and an old one on the printed label.
- A change-control rule. Any specification change re-opens the claim set and the label file. This is the part that is missing in most projects, and its absence is invisible: nobody makes a wrong claim on purpose, but the product moves and the claim does not.
The boundaries your claim set must respect
- No market certification or registration claim for any product. Directive declarations cover named models and named directives only.
- No diagnosis, no guaranteed accuracy, no treatment outcome.
- Watch water resistance: the IP67 rating covers short-term shallow immersion only — no swimming and no hot water. See the blood pressure watches hub for the model-level wording.
- Ring: daily use only — no swimming, no hot springs, no prolonged submersion.
- Connected glucose monitoring: the S10 is a separate single-use adhesive upper-arm sensor, and a compatible watch and the app only display synchronized data. The watch itself does not measure glucose, and no connected display may be described as doing so.
6. Spares and After-Sales — Six Links, Each Needing an Owner
After-sales is usually planned as a policy. It is more usefully planned as a chain, because a policy hides the links that have no owner — and an unowned link is where the customer experience actually breaks. No support-hours, turnaround, warranty or spares-availability figure appears below, because none is verified for this site; what appears instead is the question each link has to answer and the owner who has to answer it.
| Link in the Chain | The Question It Has to Answer | Why It Usually Fails Here |
|---|---|---|
| 1. A unit stops working | Who receives the report, and through which channel? | The end customer reports to the brand they bought from — so the first link is yours, not the supplier’s. |
| 2. Triage | Who decides whether it is a wear-part issue, a unit fault or an expected limitation? | The water-use limits are the most common false fault: the watch’s IP67 covers short-term shallow immersion only, and the ring is daily use only. |
| 3. Replacement part | What is stocked, by whom, and where? | Strap, airbag, sizing set and sensor consumable each have a different replacement logic, and no stock or turnaround figure is verified here. |
| 4. Replacement or repair decision | Who authorizes it, and against what threshold? | Without a named owner, replacements are decided case by case and costed the same way. |
| 5. What the customer is told | Who writes the message, and does it stay inside the approved claim set? | A support message is a published claim. It is bound by the same boundaries as the marketing page. |
| 6. What is learned | Who collects the pattern, and who does it reach? | A recurring fault is a specification input. If nobody owns the collection, the same fault is rediscovered each time. |
The second link is worth dwelling on, because it is where product limits get mistaken for faults. The watch’s IP67 rating covers short-term shallow immersion only, and the ring is for daily use only — both of which are stated on the product pages and both of which will generate support contacts from customers who were never told. Putting them into the onboarding material, rather than into a leaflet nobody reads, is cheaper than handling each one as an incident.
7. Continuity — What Survives the Relationship
A brand owner’s exposure is not limited to the project. It extends to everything the product depends on afterwards — records, the app, spares, tooling and support — and that exposure is entirely avoidable if it is written down while both parties still have every reason to agree.
| Item | The Question to Settle in Writing | Why It Is Worth Settling Early |
|---|---|---|
| Design records | Who holds them, in what form, and can you obtain them if the relationship ends? | A product you cannot document is a product you cannot maintain, re-order or defend. |
| App listing & publisher identity | Who holds the listing and the account, and what happens to existing installs? | Nothing is confirmed on the ownership question — settle it before design freeze, not after launch. |
| Production tooling arrangement | What the arrangement is, and what becomes of it if the relationship changes. | Raised as a question to settle in writing; no assumption is made about the answer on this page. |
| Stock & spares | What exists, where it is held, and over what period it is expected to cover demand. | No spares-availability or support-period figure is published because none is verified. |
| Support expectation | Over what period the brand owner expects to be able to support the product it sold. | The obligation to the end customer is yours regardless of what the development relationship does next. |
| Change of supplier | What a new development partner would need, and whether you would be able to give it to them. | This is the practical test of whether the continuity list was written or merely assumed. |
The last row is the practical test of the whole list. If you could not hand a new development partner a complete picture of your product tomorrow, the continuity position was assumed rather than written — and that is worth knowing before it matters, not after.
8. What This Page Deliberately Does Not Do
Three refusals, stated rather than left as gaps — because an absent answer is different from a vague one.
- It does not tell you which rules apply to your product. The allocation principle is stated; the market question is yours to settle with advisers who know your product and your destination. Nothing here should be relied on as legal or regulatory advice.
- It does not assert that any specific document exists for any specific model. Categories are named and the scope rule is stated; the per-model inventory has to be confirmed in writing. This site publishes no document as existing that it cannot produce.
- It does not publish a service level. No support period, turnaround, warranty or spares-availability figure appears because none is verified. A committed number nobody has agreed to is worse than an open question, because you would plan against it.
If your project is at the point of settling these items, the useful next step is not another document — it is the conversation where each one gets an answer in writing. The OEM & ODM overview lists the open items on our side, and the project guide shows which stage each of these decisions has to be made in.
Where to go next
Back to the OEM & ODM overview for the capability scope and the full list of what is not offered or not yet confirmed. Read how a private-label wearable project runs for the stage sequence these obligations attach to. If your interest is the commercial programme rather than the development project — line-up, packaging and distribution — that is the Health Brands & Distributors path. If your question is how a device feeds a workflow you already operate, that is the Digital Health Businesses path.
Frequently Asked Questions
Questions buyers usually need answered first
Practical answers about product selection, everyday use and planning your project.
Visit the FAQ pageWhat technical documentation must we be able to produce?
Document categories, each answering a different question: a requirement record; design and drawing records; the platform configuration record; app build and release records; device-level declaration or conformity documentation applicable to the named model and the directives it covers; the packing and kit definition; and the label artwork control record. Two rules matter more than the list. Read the scope line and the holder on every document — a genuine document read out of scope is this category’s most common false comfort. And a factory or process document is not a product authorization, however impressive it looks. This page names categories; it does not assert that any specific document exists for any specific model.
Whose job is it to place the product on a market?
The brand owner’s — the party that puts the product on the market under its own identity holds the market-facing authorization duty and the labelling obligations attached to it. What a development partner holds is different in kind: factory-and-process documents within their stated scopes — a medical-device production licence and an ISO 13485 quality-management certificate, both bounded, shown publicly as certificate titles with the original documents unchanged, never as product authorization and never with a substituted holder name. Directive declarations for red and RoHS relate to named models and named directives only. Which markets you intend to enter, and the duty that applies in each, is a question for your own advisers — this page names it rather than answering it.
Who controls the label, the claims and the changes to them?
You do — and that is exactly why it has to be built as a control rather than assumed as an outcome. Three practices hold it together: an approved claim set written down before artwork is produced; label artwork control so printed content cannot drift from that set; and a change-control rule stating that any specification change re-opens the claim set and the label file rather than silently invalidating them. Without the third one, the technical file stops describing the product that actually ships, and the claim set is no longer defensible even though nobody made a wrong claim on purpose.
Which files should we include in a project handover checklist?
List the final specification, approved drawings and artwork, software release identifiers, user instructions, test records and production-sample approval. Add the accounts, access credentials and licenses included in the contract, with a named recipient for each deliverable.
How should a brand control product changes after launch?
Use a versioned change record describing the reason, affected parts, test requirements and label or instruction updates. Approve the revised configuration before shipment, and keep the release history so support teams can identify the version used by each customer.