How does it work?
Kind fit 1.0.0
This is the current contract for how we rate. Catalog criteria and scoring use the same version.
Kind fit, catalog 1.0.0
This is the scoring model vendors can be shown. It is the contract for how we rate, not a ranking of every pair of glasses against each other. The machine-readable source of truth is assessment/scoring/1.0.0.json plus assessment/criteria/1.0.0.json. We do not bump those files without a deliberate catalog change.
Kind fit is how well a product does the job of its own kind in a chosen market. An in-eye display is not scored against a sound-only pair.
Empty cells mean we have no accepted evidence yet. Unknown is not false.
Nothing a supplier or an AI crawl writes goes into Kind fit until a curator accepts it.
Readers can open this document at /assessment/methodology (Documentation → How does it work?). Older catalog versions stay at /assessment/methodology/{version}. The page is not indexed.
Versioning this contract
The methodology version matches the criteria and scoring catalogs (1.0.0 today).
- Do not edit a frozen file after a newer version exists.
1.0.0.mdstays the contract that was in force for catalog 1.0.0. - Scoring or criterion changes (weights, mappings, freshness, dispute rules, what a questionnaire maps to): copy this file to the new version, bump
assessment/criteriaandassessment/scoringtogether, and publish the new file. Keep the old file so vendors can see what applied when they answered. - Clarifications that do not change scores can stay on the current version.
Git already versions every change. The version number is what we show vendors.
How technical facts are replaced
Factual observations do not fade. Performance uses a 365-day half-life; compliance and experiential use 540 days; factual rows keep their vote weight for life. A new firmware that adds on-device AI does not quietly retire last year’s accepted “cloud only” row.
That does not mean a fact can never be overridden. Override is supersession of evidence, not time decay.
| What happened | What we do today |
|---|---|
| Same secret questionnaire link, supplier sends an update | Pending and accepted vendor votes from that link for that product are marked superseded. New rows wait in Curate. |
| Withdraw the questionnaire | Same supersession of vendor votes from that link, plus the URL stops working. Raw answers stay as a CSV record. |
| New maker docs or an AI crawl contradict an accepted fact | Curate flags the row as a conflict. You can add it as another vote, or replace the old conflicting facts (they become superseded). Adding without replace still averages both. |
| Vendor votes and empirical votes (wearer, expert, lab) on the same criterion sit 25 points or more apart | The criterion is DISPUTED. We do not silently pick a winner. That is simultaneous disagreement, not a product change. |
Replacement is a curator choice at intake. We do not auto-retire an old fact because a crawl arrived. Agreeing accepted rows (same mapped score) are left in place.
New functionality becomes evident the same way every other fact does: a cited URL, a questionnaire resubmit, a directed crawl, or a wear test → Curate accept → Kind fit. We do not invent a value because a press release used the word “new”.
Directed crawls (URL)
A URL is the right way to point us at extra technical data. File upload is not required.
The public Cloud Run request cannot run a long AI crawl (request timeout). The working pattern is the same as daily research: queue product + URL, let scripts/daily-research.mjs (or the Cloud Run Job) fetch and extract pending observations, then Curate accept or reject.
That queue is not shipped in 1.0.0. Until it is, send the URL in the questionnaire docs field, in notes to hello@aivisionexpert.com, or ask staff to run a targeted research job. Extracted claims still wait in Curate. A crawl never outvotes a cited spec sheet.
Alignment with the product’s claim (what it does)
Kind fit is fit to kind, not a feature popularity contest. We first name the job the product claims, then we only score the parts of the catalogue that belong to that job.
The five kinds and their claims live in assessment/scoring/1.0.0.json under capability_profiles. We assign the kind in our product catalogue. The supplier questionnaire does not set the kind and does not ask “how well does this work?”.
| Kind | Claim we score against |
|---|---|
| Screen replacement | Replace a conventional computer monitor with an in-eye display. |
| Display, no camera | An on-glasses display for text and cues, with no camera on the glasses. |
| Camera and display | An on-glasses display plus a camera, for seeing information and sharing what you see. |
| Camera, no display | Everyday capture, calls, and AI, with no in-eye or on-glasses display. |
| No camera, no display | Private audio help and calls. No camera, no in-eye or on-glasses display. |
Each kind has claimed domains (eyewear, hardware, software, mobile, AI, data, support). Criteria outside those domains, or listed as not applicable (for example vision AI on sound-only glasses), are ignored, not marked down.
Does the product actually do that job? That is a different evidence path from procurement facts:
| Question type | Examples | Who should answer |
|---|---|---|
| Procurement / architecture (factual) | Where AI runs, BYOK, EU processing, repair path, warranty | Supplier questionnaire |
| Capability facts from docs | SDK lock-in, camera API, offline use, third-party apps | Maker docs, or a crawl that reads those pages |
| Lived function (experiential / performance) | Comfort, outdoor mic, voice quality, call quality, real-world battery, vision usefulness | Wearer, expert, workshop — focused review |
Signed-in focused review is /products/{id}/review. Workshop wear is a stronger vote than an ordinary user. A daily crawl may extract the same criterion keys from public pages, but that vote is weak until a curator accepts it.
If a supplier wants to send product information (what the model does, SDK, camera, offline, AI features), do not add that to the procurement form. Take a docs URL or a short brief, extract pending observations the same way the crawl does, and let Curate accept or reject. Do not let a supplier self-score comfort or voice quality.
The full criterion list and weights are in the table below. Machine-readable source: assessment/criteria/1.0.0.json.
What a score is made of
- Each accepted observation is mapped onto a 0–100 scale for one criterion (for example on-device AI = 100 if true, 0 if false).
- That observation is given a vote weight:
authority × evidence quality × confidence × freshness × market applicability
- The criterion score is the weighted mean of those votes.
- Domain scores are weighted means of their criteria (criterion weights below).
- Kind fit is a weighted mean of the domains that belong to that product’s kind, then mixed with market overlays.
If vendor votes and empirical votes (wearer, expert, lab) on the same criterion sit 25 points or more apart, that criterion is marked DISPUTED. We do not silently pick a winner.
Known is the share of that kind’s job we have observations for, not agreement. Spread is one weighted standard deviation on the 0–100 scale.
Vote weight: who said it
| Source | Authority | Typical evidence grade | Typical vote weight (confidence 1.0) |
|---|---|---|---|
| Independent test / regulatory | 1.00 | A (1.00) | 1.00 |
| Expert wear / workshop | 0.95 | B (0.85) | 0.81 |
| Verified user | 0.80 | C (0.65) | 0.52 |
| Maker docs (cited URL) | 0.75 | B (0.85) | 0.64 |
| Ordinary user | 0.55 | C (0.65) | 0.36 |
| Maker self-report, no cited docs | 0.35 | D (0.40) | 0.14 |
| AI web crawl | 0.20 | D (0.40) | 0.08 |
Supplier questionnaire answers are VENDOR. If they cite a policy or docs URL they are treated as maker docs; otherwise as marketing self-report. A crawl never outvotes a cited spec sheet.
Evidence grades: A 1.00, B 0.85, C 0.65, D 0.40, E 0.20.
Performance observations fade with a 365-day half-life. Compliance and experiential use 540 days. Factual rows do not fade.
Market-specific rows (EU processing, local repair, warranty, spare parts, RMA, stock, availability) count fully in the tagged market and are not copied to other markets.
How a market headline is mixed
On a named market (Netherlands, EU, South Africa, and so on):
- 60% the kind’s claimed domains (eyewear, hardware, software, mobile, AI, data, support)
- 25% accessibility (market + support)
- 15% jurisdiction (compliance + data)
Global view uses only the claimed domains. Market availability is an overlay, not the whole score.
Domain weights
| Domain | Weight |
|---|---|
| Market accessibility | 1.2 |
| Hardware | 1.1 |
| AI | 1.1 |
| Eyewear | 1.0 |
| Software | 1.0 |
| Data | 1.0 |
| Support | 1.0 |
| Compliance | 1.0 |
| Mobile | 0.8 |
Criterion weights (what moves Kind fit)
Higher means that fact pulls the domain (and then Kind fit) more, once we have evidence. Weight does not invent a value when the cell is empty.
| Criterion | Weight | What a high score means |
|---|---|---|
| Market availability | 1.3 | Sold into this market |
| Local repair path | 1.2 | A local / authorised repair intake exists here |
| Real-world battery | 1.2 | Longer mixed-use hours |
| Comfort | 1.1 | Ordinary wear is comfortable |
| Outdoor microphone | 1.1 | Voice holds up outdoors |
| Local API | 1.1 | Other software can talk to the glasses without the vendor cloud |
| AI provider choice | 1.1 | Wearer can choose the AI provider |
| EU processing option | 1.1 | Processing can stay in the EU/EEA |
| Firmware still maintained | 1.1 | Software is still shipping |
| Local stock | 1.1 | Stocked for sale here |
| SDK portability | 1.0 | Software is not locked to this maker’s hardware |
| Core features offline | 1.0 | Ordinary use without a network |
| Third-party software | 1.0 | Other apps can run (sideload / store) |
| Sensor access | 1.0 | Other software can read camera / mic / motion |
| Custom AI endpoint | 1.0 | Private or self-hosted AI can be used |
| Bring your own AI key | 1.0 | Wearer can plug in their own API key |
| Voice assistant quality | 1.0 | Spoken AI is usable |
| Vision AI usefulness | 1.0 | Can describe or act on what is in view |
| Local storage option | 1.0 | Recordings / notes can stay on device |
| GDPR notice completeness | 1.0 | A usable EU privacy notice exists |
| Spare parts path | 1.0 | Parts can be obtained |
| Call quality | 0.9 | Calls sound usable |
| Can act, not only answer | 0.9 | Assistant can send, remind, or call an API |
| Cloud required | 0.9 | Higher when ordinary use does not need vendor cloud |
| Prescription compatible | 0.8 | Lenses or inserts supported |
| Bluetooth profiles | 0.8 | Ordinary Bluetooth other phones can use |
| Programmable camera | 0.8 | Software can capture, not only a maker app |
| On-device AI | 0.8 | Useful AI without a cloud round-trip |
| Data export | 0.8 | Wearer can take data out |
| Telemetry opt-out | 0.8 | Analytics can be switched off |
| RMA path clarity | 0.8 | Return / replacement steps are clear here |
| Weight (grams) | 0.7 | Lighter is better (30 g best, 180 g worst on the 0–100 map) |
| Who controls OS updates | 0.7 | Wearer can choose when to update |
| Usable without a maker account | 0.7 | Core features without a vendor login |
| Technical documentation | 0.7 | Docs are complete enough to work from |
| iOS support | 0.6 | Official iPhone support |
| Android support | 0.6 | Official Android support |
| Warranty length | 0.6 | Longer standard warranty (24 months maps to 100) |
| Companion app required | 0.5 | Higher when a phone app is not required |
| Claimed battery life | 0.4 | Maker-stated hours; weaker than measured hours |
Some criteria are not applicable to a kind (camera API and vision AI on sound-only or in-eye headline). Those rows are ignored, not marked down.
What the supplier form can fill today
The questionnaire is supplier and product input, not a functionality review. It maps into ten of forty-one criteria: on-device AI, cloud required (only when processing is vendor-cloud-only), AI provider choice, bring-your-own key, custom endpoint, EU processing, local repair, spare parts, warranty months, RMA clarity.
AI processing location is tick-all-that-apply, because a product can run on the glasses and in a cloud. Own AI/LLM is the same: vendor-approved models, bring-your-own key, and a custom or self-hosted endpoint can all be true together. In the catalog those are three cells (ai.provider_choice, ai.bring_your_own_key, ai.endpoint_custom). “Custom endpoint” and “private/self-hosted LLM” are the same scored fact (ai.endpoint_custom). No and unknown stay exclusive.
The rest of the catalog still needs maker docs, a wear test, or the daily research crawl. Training-data use, SSO/MDM, support-desk location, promised support years, firmware-year promises, post-warranty repair, and EOL policy are stored as a record and are not scored until we add criteria for them.