> For the complete documentation index, see [llms.txt](https://dataroom.mercle.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dataroom.mercle.ai/breakthrough-plan.md). # Breakthrough Plan This page will help you connect the dots between Mercle's AI/ML models and the role of mDAI (an open source camera device) ## TL;DR * **Current systems are mostly 1:1-trained models being used as 1:N systems through repeated nearest-neighbor matching** * **That works for broad separation at 10k humans scale, but fails in dense identity neighborhoods when we onboard billions of humans.** * **So billion-scale uniqueness requires a different decision mechanism: Local Discrimination.** * **Local Discrimination requires data that existing datasets do not provide.** * **So hardware is used as a controlled data-generation layer.** * **The data plan starts from world sample distribution, then regional identity targets, then device throughput, then cost.** *** ## Part 1 — Why Existing Face Models Break at Global Scale Most production grade face systems today are built from models trained for **1:1 verification**.
That means the model is trained to answer a narrow question: > Given two face inputs, are they the same person or not? This is the right objective for: * device unlock * account login * re-authenticating a known user * checking one face against one enrolled template In that setting, the model’s job is to be robust enough to match one identity across common variation. It is not required to separate one person from millions of visually nearby people. *** ### How 1:1 models are used to approximate 1:N systems **Most large-scale face systems do not actually use a model trained directly for 1:N disambiguation.** Instead, they do this: 1. train a model to produce embeddings that work well for 1:1 matching 2. store one or more embeddings per enrolled identity 3. compare a query face against many stored embeddings 4. select the nearest match, or reject if no score passes threshold
Operationally, this **looks like a 1:N system.**\ But structurally, it is **still just a large number of 1:1 comparisons.** That distinction matters. The model was trained to decide whether two inputs are similar enough to be considered the same identity. It was **not** trained to rank one face correctly against a very large population of near-neighbor identities, where the failure mode is no longer simple mismatch, but **confusion between similar identities**. So the current 1:N stack is usually: > **1:1-trained model + nearest-neighbor search** not a system designed from first principles for large-scale uniqueness. *** ### Why this fails at scale That shortcut works when the identity space is sparse. It breaks when: * many identities sit close together * the same identity moves under pose, age, lighting, or time * the model has to separate subtle structure, not just broad appearance The core pipeline is usually: **image → embedding → similarity → decision** This creates two constraints: #### 1. Identity is reduced too early A high-dimensional face is compressed into a fixed representation before the hardest comparison is made. Context becomes a joke "Colon Musk".
#### 2. The final decision is made with too little structure Once everything is reduced to vector similarity, the system can no longer ask: * which local regions disagree * whether the disagreement is identity-bearing or just noise * whether structure and appearance should be weighted differently That is why these systems weaken exactly where global-scale uniqueness gets hard: * lookalikes * twins * aging drift * side angle vs frontal comparisons * dense local identity neighborhoods The problem is not that embeddings are useless. **The problem is that embeddings are being asked to do more than they were trained to do.** *** ### The training-design difference between 1:1 and 1:N #### A 1:1 model is trained to learn: * invariance to normal variation * same/different consistency * a compact identity representation that is easy to compare That pushes the model toward broad robustness and compression. #### A 1:N uniqueness model must learn: * fine-grained separation inside dense neighborhoods * ranking under many near-neighbor identities * local evidence for why one candidate is closer than another * stronger hard-negative discrimination than standard 1:1 systems require So the design target changes. #### In 1:1 training: the model is rewarded for saying\ **“these two belong together despite nuisance variation.”** #### In 1:N training: the model must also be rewarded for saying\ **“these two are different even though they are visually very close.”** That is a different problem. It requires a different training signal, different data composition, and a different comparison mechanism. *** ### Why this leads to Local Discrimination If a 1:1-trained embedding model is the wrong abstraction for billion-scale uniqueness, then the answer is not “just use a larger embedding.” The answer is to change **how the decision is made**. **That is where Local Discrimination comes from.**
Instead of treating identity as a static vector and making a final decision from global similarity alone, we treat identity as a **comparison process**. The model must be able to ask: * where do two faces align * where do they differ * which differences matter * which differences are pose, lighting, texture, or capture noise That is the purpose of the **Local Discriminator Layer.** It is not a replacement for the encoder.\ The encoder still provides the coarse representation. But for 1:N uniqueness, coarse representation is not enough. The Local Discriminator is the mechanism that resolves ambiguity when broad similarity is no longer sufficient, the same way transformers scaled NLP, by having no compressing and ability to look back at the input parallely.
*** ### What changes in the model structure #### Standard 1:1-style stack * encode face A * encode face B * compare final embeddings * make same/not-same decision #### Local Discrimination stack * encode face A * encode face B * preserve richer intermediate structure * compare local evidence across the two inputs * produce similarity, confidence, and ambiguity-aware decision The difference is not cosmetic. #### Standard embedding systems ask: > Are these two compressed identities similar? #### Local Discrimination asks: > Where are they similar, where are they different, and is the difference identity-bearing? That is the transition from **verification logic** to **disambiguation logic**. *** ## Part 2 — Why Hardware Is Required ### The constraint is no longer only model design **Once the model is designed for local disambiguation** rather than simple 1:1 verification, the bottleneck shifts. The **limiting factor becomes the quality of the training data**. Existing datasets are usually sufficient for: * classification * 1:1 matching * broad embedding learning * 2D face recognition under loose capture conditions They are not sufficient for training a system whose core job is: * distinguishing visually similar but distinct people * learning identity across multiple structured viewpoints * separating geometry from appearance * learning from hard negatives at meaningful density That is why our hardware mDai enters the picture. *** ### What the Local Discriminator needs from data For the Local Discriminator to be useful, the data has to teach it four things: #### 1. Identity persistence across views The same person must be captured across: * frontal * partial profile * side angles * variable distance and framing #### 2. Hard-negative separation The dataset must contain enough cases of: * similar-looking but distinct individuals * near-neighbor identities * ambiguous identity pairs #### 3. Structure versus appearance The model must be able to distinguish: * geometry and facial structure\ from * lighting, surface texture, and temporary artifacts #### 4. Real signal, not fake signal The data must be resistant to: * spoof contamination * weak capture quality * inconsistent alignment * uncontrolled framing A weak dataset can still train a decent 1:1 model.\ It will not train a good local discriminator.
*** ### Why existing data is not enough Public and commodity datasets are mostly built around one of two goals: * broad 2D face recognition * benchmark-friendly verification tasks That means they tend to underdeliver on exactly the things we need: * multi-view structure * consistent alignment * depth-aware geometry * hard-negative density * controlled capture quality The result is simple: > the architecture we want cannot be trained correctly on the data that already exists. *** ### Why we use hardware The role of the hardware is not to turn us into a hardware first/dependent company, but the role of the hardware is to generate the data conditions required for the model we are building for mobile-first use. That means the hardware is designed to give us: * controlled alignment * multi-angle capture * RGB + IR + depth * high-resolution detail * anti-spoofed, clean samples Those are not nice-to-haves.\ They are the minimum conditions required to train a system whose job is local identity disambiguation. So the logic is: 1. 1:1 models are the wrong base abstraction for billion-scale uniqueness 2. 1:N uniqueness requires local discrimination 3. local discrimination requires a different data stack 4. hardware is the controlled data-generation layer for that stack That is the real connection between Part 1 and Part 2. *** ## Part 3 — Hardware Deployment and Cost Strategy For us the first question was: **What global sample distribution is required to train a uniqueness model that has to work across populations, environments, and dense identity neighborhoods?** Hence the planning sequence is became clear: 1. define the world sample we need exposure to 2. break that sample into regional collection targets 3. convert those targets into unique identities and captures per identity 4. translate that into devices, months, and cost *** ### Step 1 — World sampling plan Over all, We are trying to build a training set that is useful for: * broad phenotype coverage * multi-region robustness * hard-negative density * operational throughput #### Proposed training sample distribution | Region | Share of dataset | Why it is included | | -------------------------- | ---------------: | ------------------------------------------------------------------------------ | | South Asia | 22% | very large population base, dense urban throughput, strong scale economics | | Southeast Asia | 14% | high-throughput urban capture, good environmental variation | | East Asia | 12% | important for regional robustness and dense urban capture | | Sub-Saharan Africa | 16% | major underrepresented coverage, broad phenotype variation | | Middle East & North Africa | 10% | regional robustness, lighting/environment variation | | Latin America | 12% | mixed population structures, strong generalization value | | Europe | 8% | robustness across lighter-skinned cohorts and different aging/capture patterns | | North America | 6% | operational relevance, robustness for deployment markets | This is a **coverage-weighted training plan**, not a claim about demographic quotas. We got this breakdown on the basis of population differences and variations as demography changes. In India for example South Indians look absolutely different from North Indians. Similar case happens in Africa (North v/s South). *** ### Step 2 — Convert world sampling into identity targets We need enough unique identities inside each region for the model to see: * intra-person variation * inter-person similarity * region-specific nuisance variation * enough hard negatives to matter #### Working target: 3-4M unique identities Using the regional weights above: | Region | Share | Unique identities | | -------------------------- | -------: | -----------------: | | South Asia | 22% | **\~**700,000 | | Southeast Asia | 14% | **\~**500,000 | | East Asia | 12% | **\~**300,000 | | Sub-Saharan Africa | 16% | **\~**500,000 | | Middle East & North Africa | 10% | **\~**300,000 | | Latin America | 12% | **\~**400,000 | | Europe | 8% | **\~**250,000 | | North America | 6% | **\~**200,000 | | **Total** | **100%** | **\~3-4M** | *** ### Step 3 — Captures per identity A uniqueness model does not need one image per identity.\ It needs structured variation per identity. #### Working capture plan * **60-100 captures per identity in 1 scan session. (10-20 second footage, chopped and filtered)** * mix of frontal, partial-profile, profile, distance, and illumination variation * RGB + IR + depth * liveness-passed only #### Total sample count **3M identities × 60 captures = 180M samples** That is the sample count the hardware network is actually being designed to generate, it will be the biggest dataset ever collected for face recognition on foot. *** ### Step 4 — Initial milestone before full-scale target The full 3M-identity dataset is not the first milestone. #### Phase 1 milestone * **1.0M unique identities** * **60M samples** * enough to train and evaluate the first production-grade Local Discriminator Using the same regional weighting: | Region | Share | Phase 1 unique identities | | -------------------------- | -------: | ------------------------: | | South Asia | 22% | 220,000 | | Southeast Asia | 14% | 140,000 | | East Asia | 12% | 120,000 | | Sub-Saharan Africa | 16% | 160,000 | | Middle East & North Africa | 10% | 100,000 | | Latin America | 12% | 120,000 | | Europe | 8% | 80,000 | | North America | 6% | 60,000 | | **Total** | **100%** | **1,000,000** | *** ### Step 5 — Throughput model One valid identity output means: * completed session * alignment passed * full capture set completed * liveness passed * stored as usable training identity #### Monthly identities per device formula **sessions/hour × hours/day × utilization × completion rate × days/month** #### Base operating assumption * 12 sessions/hour * 10 active hours/day * 50% utilization * 85% valid completion * 26 active days/month #### Calculation **12 × 10 × 0.50 × 0.85 × 26 = 1,326 identities/device/month** That is the planning number. *** ### Step 6 — Device requirement for the first 1M identities #### If we deploy 160 devices **1,326 identities/device/month × 160 devices = 212,160 identities/month** #### Time to 1M unique identities **1,000,000 / 212,160 ≈ 4.7 months** This sits inside the 4–6 month target window. #### If we deploy 180 devices **1,326 × 180 = 238,680 identities/month** **1,000,000 / 238,680 ≈ 4.2 months** That gives buffer for ramp-up and uneven site performance. So the practical deployment range is: * **160–180 devices** * **4–6 months** * **1M unique identities** * **\~60M samples** That is the first milestone. *** ### Step 7 — Hardware cost for Phase 1 #### Device cost If each device costs **$350**: * **160 devices = $56,000** * **180 devices = $63,000** That is not the dominant cost.\ Operations are. *** ### Step 8 — Operating cost model You should break operating cost into three buckets. #### A. Site operations Per active device per month: * site fee / partner economics * power / connectivity * local monitoring or support * cleaning / replacement / logistics You need to insert your real internal estimate here.\ For modeling, use a placeholder variable: **monthly site ops cost per device = O** Then: * **160 devices for 5 months = 800 device-months** * **180 devices for 5 months = 900 device-months** So site operations cost is: * **800 × O** for 160-device plan * **900 × O** for 180-device plan #### B. Central program operations * deployment team * QA * device maintenance * field troubleshooting * data operations #### C. Model + infrastructure * storage * training compute * engineering salaries * data quality workflows That is the correct structure for the cost section: * hardware capex first * site opex second * central program cost third * model/infrastructure fourth ***