Meet the team
Overview
Leading five people through a six-week question
TokenTrust is a governance platform that measures the quality of the data people give to AI, pays them back for it, and lets that value move between platforms. I led a team of five, and my job was less about drawing screens than about deciding what we were actually asking.
We had six weeks. My first call as lead was that we would not spend them on another privacy complaint. Plenty of work already says AI companies take too much. I wanted us to answer a harder question: if data has value, what would it take to actually pay someone for it? That reframing set everything that followed, because it turned a moral argument into a measurement problem.
Five of us, drawn from industrial design and graphic design, and none of us a governance specialist. I split the work so it could run in parallel. Two of the team took the primary desk research, one on regulation and one on market and cost data, and two more came in as second researchers on the axes that needed another pass. I kept the framework and the argument, which meant I was the one who had to make the pieces agree with each other. Alexander Manu and Mahnoor Hasan advised, and I used their critiques as checkpoints rather than approvals.
Snapshot
Data is scored, contribution is paid back in tokens, and that value stays worth something when it moves to another platform.
Problem Definition
Most AI companies treat tokens as an internal meter for usage. People have almost no sense of what their data is worth, no view of where it goes, and no say in who profits from it.
Consent and control are already guaranteed in law. GDPR gives people the right to withdraw permission and to access, change, and delete what has been collected. What no law says is that the value has to come back. I decided early that this gap, not privacy in general, was where the project would sit, because it is the one part of the problem nobody had built a mechanism for.
The three questions I put in front of the team
I opened the project with these, and we kept coming back to them whenever the scope started drifting.
We use these tools daily with no view into how the companies behind them handle what we give, no idea whether it is stored or fed into the next model, and no return on the value it creates while we are still the ones paying the subscription.
Discovery
I gave the research a shape before it started. I put the regulatory side with one researcher and market and cost with another, and asked the team for evidence that would either kill the idea or force it to get specific.
Before anyone went looking for numbers, I made the team agree on what we were auditing and what we were not. I picked ChatGPT, Claude, and Gemini as the objects because they are three different corporate shapes doing the same job, a capped-profit lab, a public-benefit corporation, and a division of a trillion-dollar advertising company. Comparing them tells you what is a company choice and what is structural to the category.
The unit of analysis is where I spent the most time as lead. I fixed it at one median text prompt, then multiplied out by volume and by default distribution to reach the system-level effect. Without that ladder every statistic the team found would have been an anecdote. Chip fabrication, enterprise API workloads, and copyright licensing went outside the boundary on purpose, because auditing them properly was a different project, and saying so protected the credibility of what we did claim.
The audit framework was where we started, not what we concluded. With the boundary and the unit of analysis fixed, I had the team widen out from it and split the evidence into energy, water, carbon, labour, disclosure, and behaviour, so the read would be system-level instead of a list of complaints about one product. Every card carried a citation and the initials of whoever found it, because when a team researches in parallel it stops being clear who stands behind a number.
Synthesis was the part I kept for myself, and it is where I turned the analysis back toward the person using these tools. The system-level numbers are real, but none of them reach the user, who sees no cost, no destination, and no return for what they hand over. I defined the problem there rather than at the infrastructure layer, and that decision set the direction for everything after it: the main strategy is to solve what is broken from the user's point of view, and the service has to be composed around that rather than around the audit that led us to it.
Confirmed Direction
How might we build one AI token ecosystem that gives both platforms and people a reason to take part across boundaries? I wrote this as the working question at the end of research, and these three moves are how I answered it.
Reward turns consent into something with a price attached, so every step of the loop can be audited. The token stops being a meter for compute and starts generating a receipt. Pulling the siloed units into one framework is what lets pricing answer to demand instead of to whichever platform issued it.
Three components, one loop
The obstacle to paying people for data was never technical. It was that nobody agreed on how to measure the thing being paid for. I kept the service to three parts, because anything more and the team could not explain it in a single pass.
DQI is the exchange rate the rest of the system runs on, with privacy held outside the score as a gate that blocks output entirely when it trips. Reward Token is the refund that closes the loop. Data Credit I added last, after realising the system had no way to hold the enterprise side accountable for keeping its end.
Prototyping
A governance framework is easy to nod along to and hard to argue with, which is a problem. I built the prototype so the team had something concrete to disagree about, and so DQI, Reward Token, and Data Credit stopped being three boxes on a slide and became screens with numbers in them.
I set the direction here rather than dividing it up. With five people and six weeks, an interface designed by committee would have drifted, so I drew the flows and the component library myself and used the team's critique to correct them. Everything below traces back to a decision made in research: the privacy slider exists because consent has to be adjustable, the receipt exists because DQI has to be legible, and the data flow screens exist because traceability is the axis everything else depends on.
Low-fidelity Prototype
Three journeys, each wireframed beside the flow that drives it. I drew these myself before any visual decision was made, because what I wanted the team arguing about was branching, not colour.
Onboard and connect. I gave these four screens one job, which is to make the purpose of the service unmistakable before anything else happens. This is a data security and data tracing tool for AI use, not another dashboard, so the promise screen states it in four plain steps and the connect screen says out loud that access is read-only and counts usage rather than content. If a person cannot say what the app is for by the time they reach the privacy slider, nothing later in the product recovers it.
The diagram beside the frames is where I made the branching explicit, bank sign-in with an email fallback, and what happens when somebody finishes onboarding without connecting anything. Privacy level sits last, so the first real decision a user makes is how much to share rather than whether to join. Every region is annotated with its layout behaviour, heading hug, list vertical at gap 12, spacer fill, CTA hug, so the wireframe handed the team a layout contract instead of a picture, and the component library inherited those rules directly.
Hold and move. I treated the dashboard as one of the core interactions of the service: a live read of where AI tokens currently stand and which way the trend is moving, visible at a glance. Balance, the trend chart, the two actions, and the connected sources all sit on one surface, because that visibility is the product. If you have to dig to find out what your contribution is worth right now, the compensation argument stays theoretical.
From there the app has to be able to act as a place where value actually changes hands, so I gave conversion the interaction grammar of a financial trade. A sheet over a dimmed backdrop keeps the balance visible behind the quote, the rate is locked and time-boxed, and confirming is a deliberate hold rather than a tap. I also made the team draw the failure paths before the happy path was pretty. A rate not confirmed within thirty seconds routes to a re-quote, a failed settlement routes to a screen that has to state a reason, and both land back on review instead of dumping you out.
Get back and control. This is the core of the service, and the question I was designing against here is how a person can hold any right over the data their own AI use produces. Intellectual property is the honest name for it, so the interaction has to make the claim concrete rather than rhetorical. The receipt does that work: a line-by-line breakdown of what was scored, above a who-used-it block that names the buyers and flags the passages withheld as sensitive. Ownership you cannot itemise is not ownership.
The rest of the journey is about visualising how the data moves and how far the user is allowed to see. Data flow splits destination from usage on a segmented control, because where it went and what it was used for are two different questions people ask separately. The flow reaches a ledger row of zero twice, once when nobody bought the data and once when the score sat below threshold, and I insisted on drawing both, since a return model that cannot show you why you were paid nothing is not auditable. A change to your sharing level applies from the next session and not retroactively, because consent you can rewrite backwards is not consent.
High-fidelity Prototype
The same three journeys built out, with a component library underneath so the states we kept arguing about had one definition each.
The second screen states the promise in four steps, own, move, get back, control, because the whole proposition has to survive one screen or it will not survive a pitch. Connecting sources is read-only and says so directly, we count usage and not content, since asking people to link their AI accounts is the moment trust is either won or lost. The privacy level is a slider rather than a switch, so sharing more visibly raises the refund multiplier and consent becomes a dial the user holds.
This is where the interplatform idea stops being a diagram. The token market shows a live conversion rate per provider, the trade sheet quotes the multiplier and locks it, and the review step names the network fee and the settlement time before anything moves. I insisted on the locked-rate and hold-to-confirm pattern because a conversion people do not understand is a conversion they will not trust, and trust is the entire product.
The refund receipt is the screen I care most about. It shows session length, the DQI score, the base refund, the privacy multiplier, and the bonus, then names which providers used the data and flags the passages withheld as sensitive. That single screen is DQI, Reward Token, and the privacy gate made visible at once. The flow map beside it is how I kept the whole thing coherent, since drawing every route between the four tabs is what surfaced the gaps and let me hand the team a structure they could critique as a system instead of screen by screen.
Feature-Focused Model
One pricing model would not have covered the range of people we were describing, so I defined three. The first scopes the service deliberately: you switch off the capabilities you never open, and the spend that would have gone there comes off the blended rate for everything left. What you give up in breadth you get back in volume, and the trade is stated on screen rather than buried in a plan comparison.
Flexible Model
Priced by what you actually use rather than by a ceiling you never reach. You name a monthly figure, and whatever you do not burn comes back at the end of the period instead of expiring. I wanted the unspent amount shown as a number on the screen, because a refund nobody can see is indistinguishable from no refund, and this model is where the refund principle first has to hold up commercially.
Interplatform Activation Model
One preference from you, and a different answer for every policy. You set a single posture, open, balanced, or strict, and it resolves into the correct setting at each provider across chat history, project documents, code repositories, voice recordings, and identity. This is the interplatform axis at the level a person actually touches it, because nobody is going to maintain five sets of privacy settings by hand.
Conclusion
What leading this taught me
TokenTrust began as a question about where our data goes and ended as a framework with a measurement layer, a compensation loop, and a regulatory path someone could actually follow.
The lesson I keep from it is that the barrier to paying people for their data was definitional, not technical. As soon as DQI gave data a measurable identity, refund stopped being a promise and became something you could calculate, and compliance stopped being a cost and became the floor the whole system stands on.
Leading five people through six weeks taught me most of what I took away. Splitting research across the team only worked because I had decided in advance what would count as evidence, and the parts I had to redo were the parts where I had not. Bringing critique from Alexander Manu and Mahnoor Hasan in as checkpoints, rather than as approval at the end, is what kept the scope from drifting. I also learned to protect one person's time for synthesis, because in a six-week project nobody else has room to hold the whole argument.
If I ran it again I would spend week one on the regulatory map instead of week four. Mapping PIPEDA, FINTRAC, and CBPR against the three horizons is what turned this from a concept into something a company could build toward, and I found that out later than I should have. The work is published and continues at michaeljpark.github.io/tokentrust.
Full working documentation, including the market positioning, the component specifications, and the Canadian regulatory blueprint from Phase II, is kept in the project detail.