Help build a digital twin
that never leaves the phone.
DailyVox is a free voice journal that learns a private model of one person, on their own phone, from what they say each day. Two questions decide whether that model is worth building. This page explains them in plain language and shows how you can help answer them. Most roles need no research experience.
Academic or supervisor? The formal version is the research statement (or the printable two-page brief), and the full programme starts at §01 below.
The idea in 60 seconds.
A model of one person, on their own phone
Built only from their own journal. It runs where the data is made, belongs to them, and sends nothing to a server. It is a mirror of what they have said, not an oracle that pretends to be them.
Private means you cannot watch it
Because nothing leaves the phone, there is no dashboard and no way to check the model in use. If we cannot measure whether it is any good, every claim about it is marketing. So the measuring has to be designed first.
Does the phone matter? Does it learn you?
Do iPhone and Android hear people differently enough to change what the twin learns? And does a model trained on your own entries understand your feelings better than one trained on strangers?
Choose how you want to help.
Pick one. Each card says how long it takes, what you need, and what it leads to. Everyone who takes part also journals for two months: you cannot run a study well that you have not been through.
Study 1: Does the phone change the twin?
Read short scripted diary entries into DailyVox on three to five phones, iPhone and Android, and score what each one heard: wrong words, missed names, names not capitalised.
- You need
- A phone, a spreadsheet, patience
- Leads to
- The cross-platform section of a methods paper
Study 2: Does a model of you beat the generic one?
Test the analysis tool, then, after ethics approval, help 15 to 20 volunteers through two months of journaling and two short analysis runs on their own laptops.
- You need
- Basic Python, a laptop, care with people
- Leads to
- A registered report, published whatever the result
Volunteer participant
Journal on iPhone or Android, tap how each day felt, then run one tool on your own laptop. Only numbers leave your machine, never your words.
- You need
- A phone and a laptop
- When
- After ethics approval. Register interest now
Review or supervise
Attack the study design before it is frozen, offer an ethics route, or supervise a student. If the method has a hole, finding it is the most valuable contribution there is.
- You need
- Research methods or stats background
- Leads to
- Co-authorship, agreed in writing
Build the tools
The app (Swift and Kotlin) and the analysis tool (Python) are open source. Improve the tool, add tests, or make the export and the study flow easier for participants.
- You need
- Python, Swift or Kotlin
- Leads to
- Credit under the Software role
Start in three steps.
Use the app
Install DailyVox from the App Store or Google Play. Record an entry, or type one with "I can't talk right now", and tap how the day felt.
Run the tool once
Install the study kit and run its self-check on made-up data. Nothing personal is involved yet.
pipx install "git+https://github.com/intrepidkarthi/dailyvox#subdirectory=research/study-kit" dailyvox-study selfcheck
Say hello
Pick a role and email one paragraph on what you think could go wrong with it to hello@getdailyvox.com. A good objection is the best introduction.
Where things stand.
Ready
- The app, live on iPhone and Android
- Self-labelling of how each day felt, on both
- The analysis tool: runs on your own laptop, writes numbers only
- A full study design with power analysis and pre-written outcomes
Next
- The shared research export reaches both apps in their next updates
- Study 1 can start now, with team members only
- Academic review of the study design before it is frozen
Waiting on
- Ethics approval through a university partner
- The new consent form, which says only numbers are shared
- No volunteers are recruited until both are in place
How your work becomes research.
Do the work
Record and score scripts, test the tool, support volunteers, or review the design.
Get a clean answer
One analysis, run once, after the data is frozen. No peeking, no tuning.
Publish it
A registered report and a methods paper. Your name on it if you meet the authorship criteria.
Decide what to build
Whether the twin works on Android, and whether personal on-device models are worth building at all.
Common questions.
Do I need research experience?
No, for Study 1 and for volunteering. Study 2 needs basic Python. Reviewing the design needs a methods or statistics background.
Will anyone read my journal?
No. The tool runs on your own laptop and writes only numbers: results and your personal model's weights. No one in the study ever sees anyone's entries.
Is this paid?
No. There is no funding. What there is: a real app as a testbed, open questions, and a path to publication.
Will my name be on a paper?
Every contribution is recorded with the standard CRediT roles. Anyone who meets the journal's authorship criteria is eligible for co-authorship, agreed in writing before work starts.
What if the result is negative?
It still gets published. The main study is a registered report: the journal accepts the design before any data exists, so "it did not help" or "we could not tell" are results too.
iPhone or Android?
Either. Both apps export the same file, and one open-source tool analyses both the same way, so results can be compared across phones.
Go deeper.
The full programme below is written for researchers. Here is what each part covers.
- §01What a personal digital twin is, and what stands in the way
- §02The paper: measuring a model of one
- §03What the measurement found against its own model
- §04Open problems you could take on now
- §05Problems further out
- §06What data exists
- §07The study, designed and powered
- §08Working together: terms and ethics
What this is all for.
the destinationEverything below is instrumentation, and instruments are only interesting because of what they are pointed at. So it is worth stating the destination plainly before the methodology starts.
The goal is a model of a single person that lives on that person’s own device, is built from their own longitudinal record, and belongs to them. Not a general model with a profile attached. Not a service that rents your history back to you. A model whose subject is you, which runs where your data is made, and which you could delete tomorrow without asking anyone’s permission. We call it a personal digital twin, and that page is the plain-language explanation of what it is and how it differs from the industrial sense of the term.
What it is not
The claim is deliberately narrower than the phrase usually implies, and the narrowness is the honest part. A personal digital twin here is a mirror of what you have actually written, not an oracle that claims to be you. It does not pretend to hold opinions you have never expressed, and when it is asked something your record cannot answer, the correct behaviour is to say so rather than to improvise. A model of a person that confabulates about that person is worse than no model at all, which is why abstention is treated as a feature to be measured rather than a failure to be engineered away.
Five properties, each a constraint rather than a feature
- Of one. The training set is one life and the prediction target is one person’s next state — not a population average conditioned on a profile. The unit of optimisation is the individual.
- Private by architecture. The data has no path off the device. This is the load-bearing property, because most privacy is a promise — a policy to read, an audit to trust, a setting to toggle. A wiring fact is stronger than a promise, and it is the one a user can verify independently.
- On-device. A small model travels to the data rather than the data travelling to a large model.
- Longitudinal. Assembled from years, not from one session. A questionnaire captures who someone says they are on a single afternoon; a model of one is built from thousands of ordinary days, which is where most of a life actually happens.
- Owned. The weights sit on the person’s side of the trust boundary. The model is their asset, not a subscription.
Why now, and not five years ago
The substrate stopped being hypothetical. A 2026 phone ships a multi-billion-parameter language model with constrained decoding and tool calling, small trainable adapters, on-device speech recognition, sentence embeddings, and a neural accelerator measured in tens of trillions of operations per second. Assembling a genuinely complete personal model on the device itself is beginning to look less like a research fantasy and more like an engineering schedule.
Which relocates the hard problem. The open question is moving from “can it run on the phone?” to “how would anyone know it is any good?” — and the second has no settled answer, because a system built so that nothing leaves the device cannot be watched in production. There is no dashboard, no population A/B test, no held-out set to inspect after the fact, and the only witness is the person being modelled, who cannot audit a model of themselves. That is the gap this programme occupies, and it is the reason the evaluation work comes before the capability work rather than after it.
What stands between here and there
Four problems look structural rather than incremental, and none of them is solved by a larger model:
- Evaluation without observation. Fidelity claims have to be falsifiable on the device that makes them, or they are marketing. This is the whole of the methodology work in §02.
- Memory with a middle. The system currently goes from raw entries to a statistical persona with nothing in between — no layer of atoms, no layer of episodes — so every question re-derives everything at query time. What the right granularity is for a memory of a person, and how you would know you had it, is an open architecture and evaluation question at once.
- Drift. A twenty-year diary is not one person. Someone at 22 and the same person at 42 are different subjects, and a model averaged over both describes neither. Whether a personal model should track the current self or remember the former one is unsolved, and probably the most interesting question here.
- A mirror that can disagree. The obvious failure mode of a personal model is agreeing with you. Measuring sycophancy in a system whose ground truth is the user’s own words — where the user is both subject and judge — is genuinely hard, and it matters most in exactly this domain.
The rest of this page is the work done so far against that destination: the methodology and what it measured (§02–§03), the problems that are open now (§04) and further out (§05), and the one study that is designed, powered and waiting on a cohort (§07). If you want the shipped-versus-unshipped state of the product instead, the roadmap is honest about it, and the architecture describes how the current model is actually built.
The paper.
methodologyMeasuring a Model of One: A Falsifiable, On-Device Evaluation Methodology for Private Personal Models
Karthikeyan NG · independent researcher
The problem it addresses
Privacy and observability are in direct tension, and almost nobody states it. The moment a model is built so that nothing leaves the device, every ordinary method of knowing whether it works stops being available: no server-side logs, no population A/B test, no held-out set you can inspect after the fact. The user is the only witness, and the user cannot audit a model of themselves — they are the thing being modelled.
The usual answer is to give up the privacy. This paper's answer is to move the evaluation: run it on the device, before shipping, against baselines strict enough that the result can come back negative.
What the method actually requires
- Every metric is lift over an explicit baseline. Not accuracy — accuracy on a skewed personal corpus flatters everything. Lift over the do-nothing answer, stated with the baseline next to it.
- A permutation null and five negative controls. Destroy the link between label and text and the metric must collapse to chance. If it does not, the metric was measuring the corpus, not the model.
- Staged legs. Synthetic pipeline checks gate what is worth testing on humans; population-scale human corpora come next; a full-protocol single subject last. Each leg can stop the next.
- The instrument ships with the claim. A fidelity claim that cannot be re-run by the person it is about is a marketing number.
How it is laid out
- 1 Introduction
- 2 The Personal Model — what is being claimed, and what would falsify it
- 3 The substrate, and its drift
- 4 DailyVox: an existence proof — the shipping testbed
- 5 What is not yet shown — the limits, stated before the results
- 6 The instrument, and what it measured
- 7 Discussion and limitations
- 8 Ethics and privacy
- 9 Conclusion
A preprint, not yet peer-reviewed, and hosted here rather than on a repository — so treat it as a working document. Corrections are welcome and will be credited; if you think the method is wrong, that is the most useful email this page could produce.
Karthikeyan NG. "Measuring a Model of One: A Falsifiable,
On-Device Evaluation Methodology for Private Personal Models."
Preprint, July 2026.
https://getdailyvox.com/paper/measuring-a-model-of-one.pdfWhat it found.
including the failuresLeading with the losses, because an instrument that cannot catch its own maker's model is not an instrument.
- The deployed Twin failed first contact with a real diary. On the author's own journal, keyword-derived traits scored below a do-nothing baseline — lift −25.2%. The cause was a written-versus-spoken register shift that synthetic validation could not have exposed. The app was shipping; the harness said it should not have been trusted.
- Some layers carry signal, others do not. Across 1,473 writer-self-labelled entries and 15,809 held-out utterances: OS valence reads people at r = +0.59. The keyword emotion layer scores 43.5% against an 85.0% majority baseline — worse than always guessing the common answer.
- The repair is named and not yet takeable. A learned emotion probe beats the keyword layer on transfer to real diaries (50.1% vs 43.8%), but trains on research-licence-only data. The first licence-clean retrain fails the deployment gate by over-firing on neutral text.
- An honest null. A 105 KB openness head reads 1,307 writers' self-reported openness at r = +0.13 — statistically real, practically worthless, and bounded by how much text a person writes rather than by the head.
Three of those four are the product losing. That is the result.
Open problems.
pick oneStated as problems rather than plans, with what a good contribution to each would actually look like. None of them require access to anyone's diary.
A licence-clean emotion head that survives the gate
ML · tractableThe probe that beats the shipped keyword layer trains on data whose licence forbids commercial use. The first clean retrain over-fires on neutral text, which on a journal is the majority class and the one that matters — a model that calls an ordinary Tuesday "sad" is worse than no model.
A contribution looks like: a head trained only on permissively-licensed corpora that beats 43.8% transfer accuracy and holds its neutral precision, under about 200 KB, running on the phone's own embeddings.
Long-horizon memory that can be scored
eval · openRetrieval over a week is not memory. The hard question is whether a model connected two entries months apart because the connection is there, or because it confabulated one — and existing long-context benchmarks are built for documents, not for one person's decade.
A contribution looks like: a benchmark over a personal longitudinal corpus that distinguishes a real connection from a plausible one, with a null that collapses when the timeline is shuffled.
Code-mixed, non-Anglo on-device NLP
NLP · regionalThe app's name recogniser is model-free — a heuristic over capitalisation evidence — and it finds 100% of the non-Anglo person names in the test corpus where a learned model finds 97.7%, precisely because it has no prior about what a name looks like. That result points at a gap: sentiment and entity work for code-mixed diaries, on-device, without a cloud translation hop.
A contribution looks like: a Tamil-English (or any code-mixed pair) evaluation set of journal-register text, and a sentiment or entity approach that runs in a phone's memory budget.
Aggregating evidence without egress
systems · openIf a product's whole claim is that nothing leaves the device, how do you ever learn anything across devices? Federated approaches assume a coordinating server this architecture refuses to have. There may be no good answer; saying so rigorously would also be a result.
A contribution looks like: a protocol where a participant can contribute an aggregate measurement without a server ever holding their text — or a clear argument that the trade cannot be made.
The consented cohort
blocked · needs peopleEvery number above comes from one author's diary plus public corpora. A cohort is the gate between "it works for me" and a finding. The protocol is written, the consent form exists, the harness is ready — and it is stopped, because one person cannot recruit, review and consent a cohort in evenings.
A contribution looks like: an institution with an ethics process, or a supervised group willing to run the protocol. This is the one that cannot be solved by writing code. The protocol itself is no longer hand-waving: the first cohort study is fully designed and power-analysed — it is §07 below.
Where it goes after that.
longer horizonThe five above are close enough to attempt. These are the directions behind them — further out, less defined, and the ones I would most want to argue about with someone who reads this literature properly. Several may turn out to be bad ideas, which is itself worth establishing.
Memory that has a middle
The Twin currently goes from raw entries to a statistical persona with nothing between. There is no layer of atoms ("she started therapy in March") and no layer of scenarios ("the year of the move"), so every question re-derives everything at query time. Building that middle is an architecture question and an evaluation question at once: what is the right granularity for a memory of a person, and how would you know you had it?
Personality depth without fine-tuning
Weight-level personalisation on a phone is not practical yet. Persona conditioning — steering a shared model with a measured profile and the person's own phrasings — might get most of the way. The open question is whether a conditioned model is meaningfully more that person than a well-retrieved one, or whether retrieval is doing all the work and the conditioning is theatre.
Drift: a person changes, does the model?
A twenty-year diary is not one person. Someone at 22 and the same person at 42 are different subjects, and a model averaged over both describes neither. Detecting the boundaries, and deciding whether a Personal Model should track the current self or remember the former one, is unsolved and probably the most interesting thing on this page.
A mirror that can disagree
Personal models have an obvious failure mode: agreeing with you. A Twin that reflects a distorted self-image back approvingly is worse than no Twin, particularly in this domain. Measuring sycophancy in a system whose ground truth is the user's own words — where the user is both subject and judge — is a genuinely hard evaluation problem.
Ambient signals, and their ethics
Photos, music, movement and sleep are on the phone already, and each carries mood signal. Every one of them also widens what the model knows past what the person chose to say. The research question and the ethics question are the same question, and the current answer — a review-and-discard queue, nothing learned without being seen — is a design choice that has never been tested against alternatives.
Cross-lingual personal models
Most people who journal in more than one language switch within a thought, not between entries. A personal model that treats the switch as noise loses the part where the switch is the signal. This runs alongside the code-mixed work in §03 but is the deeper version of it.
What data exists.
and what does not- Public corpora, licence-clean. The population-scale numbers — 1,473 self-labelled entries, 15,809 held-out utterances, 1,307 writers' openness self-reports — come from published datasets. Reproducible.
- Research-licence-only corpora. The emotion probe's training data. Usable for a paper, not for a shipped model. This constraint is the whole of open problem 01.
- One author's diary. Twenty years, and the only longitudinal personal corpus in the programme. Not shareable, and its non-shareability is the point of the product.
- No user data. At all. The app has no telemetry and no server. There is no dataset of DailyVox users' journals, there never has been, and building one would require every participant to individually choose to send an export.
One study, ready to run.
pre-registered draft · needs a cohortEverything before this point is programme. This is the study — the concrete thing an academic partner can read, attack, and put a student behind. It exists today as a full pre-registration draft: hypotheses, power analysis, analysis code, and a pre-written sentence for every possible outcome, so that no wording is left to choose after the result is known.
Does personalisation actually help?
the questionDoes a small emotion model adapted on a person's own labelled diary entries predict that person's later self-reported feelings better than a generic model — and how many entries does it take? The app already ships the labelling instrument: users can self-label entries on a seven-class scale, on the device, under consent. The study fits a per-person head at K ∈ {0, 5, 10, 25} adaptation entries, primary claim at K = 25, and grades on that person's later entries.
- The test, fixed in advance. Exact sign-flip permutation on per-participant Δaccuracy, win-rate binomial second in a fixed sequence. A "win" is strictly positive lift; ties count as losses. The analysis runs exactly once, after the data freezes — enforced by the harness refusing a second run, not by a promise.
- Power, stated honestly. Each participant contributes ~60 self-labelled entries; 35 are held out for test. The headline test has power 0.59 at eight participants and 0.75 at fifteen; the companion test reaches 0.92 at ten. Below eight, the single most likely outcome is "inconclusive" — and that sentence is pre-written like every other.
- The anti-fabrication gate. A donor arm — adapt on other participants, test on this one — is pre-registered as an interpretive gate. If donor adaptation matches personalised adaptation, the personalisation claim is withdrawn and the result is published as spoken-register domain adaptation instead. The study is publishable on either branch; a null is a finding, not a failure.
- Prior art it must answer. MoodScope (MobiSys 2013) drew a personalisation curve for mood thirteen years ago from phone sensors; LEIA (2023) and Meta-PerSER (Interspeech 2025) are the nearest modern lines. The claim here is the conjunction — on-device, diary-register speech, self-labelled ground truth, consent-first, falsifiable by design — and the pre-registration engages each of those papers by name.
What is deliberately not done
Three things are open on purpose, because they are the parts a collaborator should co-own rather than inherit. The pre-registration is a draft — unamendable once frozen, so it stays unfrozen until someone qualified has attacked it. Consent is being rewritten for the design below, and no one outside the core team is enrolled until it lands. And the ethics route is an open decision — a university process is the credible answer, and it is exactly the piece one person without an institution cannot supply.
No one reads anyone's journal
The study now runs where the data lives. Each participant, on iPhone or Android, exports their own entries and runs an open-source tool, dailyvox-study, on their own laptop. It writes two small files of numbers, the results and their personal model's weights, and those are all that leave. A second round sends each person a model built from everyone else's weights, which they score on their own entries: that is what keeps the donor arm, and with it the claim that the model learned you, without any text moving. One open embedding model and one generic head for everyone makes iPhone and Android results comparable.
The shape of the collaboration
- The partner brings: an ethics process, adversarial review of the protocol before it freezes, and recruitment of eight to fifteen participants who journal ~60 self-labelled entries over about two months.
- The partner gets: co-authorship agreed in writing up front, a shipping instrument and harness rather than an empty repository, and a study sized for a master's or final-year student to run end to end — with a publishable result on every branch of the outcome tree.
- The engineering stays mine: the harness patch, the app, the export tooling, and the plumbing are not the collaborator's problem.
The full pre-registration draft — power tables, split rule, outcome sentences, consent draft, and the decision log — is available on request, and the right first response to it is suspicion: if your instinct is that the design is wrong somewhere, that instinct is the collaboration. The formal write-up of all of this, including venues and dates, is the research statement. hello@getdailyvox.com
Let's do it together.
open invitationEverything above is one person's work, and that is the honest limitation of all of it. A single author with a single diary can build an instrument and can catch his own model failing — but cannot produce a finding, cannot peer-review himself, and cannot see the parts of the literature he has not read. I would genuinely rather do this with other people.
There is no funding, no institutional sponsor and nothing to pay anyone, so this is not a job offer. What there is:
- A shipping testbed. A real app, on the App Store and Google Play, with real users — not a notebook and a Kaggle set.
- An instrument that already exists. TwinEval runs, with baselines, nulls and negative controls in place. You would not be starting from an empty repository.
- Problems that are actually open. Not homework with a known answer at the back.
- Authorship, stated up front. If your work is in a paper, your name is on it. That gets agreed in writing before anyone starts, not after.
- An engineer who will do the engineering. If the interesting part for you is the method, the shipping and the plumbing are mine.
Shapes this could take
Any of §04 or §05 is a paper with two names on it. The methodology work in particular needs someone who will attack it.
Several of these are the right size for a final-year or master's project, with a shipping app as the testbed and a real result at the end.
The one thing that cannot be solved by code. An institution with an ethics process unblocks the entire bottom of the ladder.
If the method has a hole in it, that is worth more than a collaboration and takes one email. Corrections get credited.
Reasonable next steps: read the paper, look at the architecture, take the source and research kit — then write and say which part you would want.
On ethics, so it is settled before anyone asks: work involving participants runs on informed consent, no compensation, data kept local to the participant's own machine, deletion honoured immediately, withdrawal honoured any time before publication, and aggregate numerics only in anything published. Those terms predate anyone asking and are not negotiable.