The core of Cirdia’s Private Intelligence Engine (PIE) was just published in the Technical Disclosure Commons and it runs on commodity cloud infrastructure. This is about how everyday businesses could be ensuring privacy… even when apps need AI-scale compute that isn’t possible on a device.
Quick note for those not familiar with the saying ‘pie in the sky’. This is a common saying that came from a song written by a labour organiser in the US, and it generally means impossible to achieve or a dream that can never become reality.
Most people who build software assume you get one or the other. Either you keep people’s data on their own device, where it’s safe and where you can’t do very much with it, or you bring it into your cloud, where you can actually compute on it and where you now hold the most personal thing your customers have. Pick a lane. Privacy or capability.
I don’t think that’s true, and when I started building Cirdia and wellness tech, I decided to demonstrate it. This week I put the whole design into the commons, under a Creative Commons license, so anyone can check my work or take it and build their own.
What it does at a high level
Here it is stated simply - in the way my company and our customers use it today. Your wellness data lives on your phone. Not on our servers. Not in a cloud database. On the device you control. When it’s time for an AI analysis, the app encrypts that data and sends it to a temporary, private computer that was created for that one person, for that one job. It runs the analysis, sends encrypted results back to your phone, and then that computer is destroyed. Not shut down. Not wiped. Destroyed.
The part that surprises people is the middle. There’s a thing in there I call the mailbox, and its whole job is to be too stupid to matter. It holds encrypted blobs and public keys. It runs no cryptography of its own. It can’t decrypt anything, and it isn’t asked to. Your phone drops something off, a worker picks it up, and the two of them never speak to each other directly, not once, in the entire process.
The worker is the other half of it, and the important thing about the worker is how short its life is. It comes into existence for one job. It generates its own keys the moment it starts, in memory, from scratch, receiving nothing from us. It does one person’s analysis. Then it’s destroyed, and the keys are destroyed with it, which means anything still sitting in the mailbox afterward is encrypted to keys that no longer exist anywhere in the world. The only place the information can be used is the one mobile phone that started the process.
Why not just keep it all on the phone?
That’s the obvious question, and for a long time the answer was that we did. We started building hardware, a wearable.
We were doing on-device processing with Rust algorithms, and it was working. The chips are standardised now, and they pre-process most of the sensor data before it ever reaches the app. The sensor side is largely handled.
What we couldn’t do on the device was lived context. Lived context is what I have been saying wearables miss, and I have been saying it for a long time. Here is an example. How do you actually experience your sleep - not just the sensor data of how much or of what type, no, how do you feel when you wake up? Refreshed and rested, or still tired? Another example of lived context is when you describe your walking as dog walking. Someone I know was told by their device that they had balance problems. Their reality is that they walked their dog and they were pulled off balance by the dog. When you are analysing your health and wellbeing, these kinds of details matter, and they get missed by wearables - which is why Cirdia was always going to build apps as well.
Anyway, earlier this year, we pivoted away (temporarily) from our device work, and built Tapestry as our first app. Tapestry is precisely a journal for lived context. It lets you log how you feel, what you do, and anything you think might be related. The goal of the app is to help people discover what is connected to what, personally and privately. For this app, the data was never going to be a fixed list of things the way sensors on a device work. We have no idea what a person may choose to track, be it a symptom, a habit, an activity, a feeling or mood. Anything goes. Whatever their life actually is.
To be able to analyse this sort of data we knew we couldn’t do it on the device. Phones can run small models, and they do useful work. What they can’t do is look across months of somebody’s arbitrary, self-named trackables and find what connects to what, and keep getting better at it without shipping a new app to everybody. We simply had to have cloud based AI processing. That’s the fork in the road, and almost everyone takes the same path: centralise the data in our company databases where we can see all of it. I did not want that, so the question I needed to address in a design was whether you could have the compute without the custody.
Now that you can see what it is and what started me down this path - let’s get into why this matters, and then how it works.
The distinction everything sits on
Every app collects two kinds of personal data and treats them as one thing.
Contact data is who you are and how to reach you. Name, email, account and billing identifiers. Every app holds this legitimately; it’s how the relationship runs.
Confided data is what you reveal about yourself. Your body, your mind, your behaviour, what you track.
Conventional systems store both in the same place, and that’s the original sin. That’s the exact move that turns a login table into a dossier of somebody’s private life. And policy can’t fix it. Policy is only as durable as the people holding it, and a promise made by today’s operator binds nobody. Not the acquirer, not the new board, not the successor with different incentives. If the data persists, the promise is temporary and the data is not.
So the fix has to be structural.
I’m going to pause here for a moment and share a bit about the stakes. Many people might see what I’ve written above and say ‘yeah, whatever, I don’t really care about someone knowing my mood, I already share it on…’ and then they mention one or more of the most popular social media apps used around the world: Facebook, Instagram, TikTok, Line, WhatsApp or Discord groups.
But what’s missed here is that there are things we don’t share - things we intend to keep more confidential. Maybe those things have to do with your financial situation, your sex life, drugs or alcohol, issues with mental health, legal issues, or just symptoms and habits that you are working to understand. Those things are what apps capture every day. And I’ll make a stronger point about this because it’s real and it’s only getting worse. Those confided details are the bread and butter for fraud. When someone threatens us with information we thought was private, we trust that they know it for a good reason. They can impersonate company representatives, doctors or medical establishments, financial institutions, and we are more likely to believe them. This is why privacy in apps matters.
Now back to the privacy engine itself.
What we actually built
This part gets a bit wonky so skim it if you don’t love the tech.
The dumb thing in the middle
Let’s start in the middle of the flow (see my diagram above). I knew before we wrote a line of this that I wanted the two sides never to talk to each other. The user’s device and the worker that processes their data never connect directly. Both poll a deliberately dumb mailbox that holds ciphertext, public keys, and status codes, and nothing else. It runs no cryptography. It can decrypt nothing. When a worker takes a job, it writes its claim once, and nothing can overwrite it. First one there wins. That matters because otherwise a second worker could come along later, swap in its own key, and get handed data meant for somebody else.
Now notice what isn’t in that picture. Nothing is sitting above all of this directing traffic and deciding who gets what job. The worker picks its own. And nothing keeps a record of which jobs ran or what came back from them. Both of those are missing on purpose. A traffic controller would have to know who was doing what, and a ledger of jobs and results would be a pile of exactly the thing I don’t want to be holding. Yes, this misses important details about how to make that work at scale. But let’s continue.
Keys that are born and die with the job
Keys are born per job and die with it. Each job runs a bidirectional hybrid key agreement, X25519 plus ML-KEM-768 (the NIST post-quantum KEM), combined into one symmetric key. The worker generates its keypair in process memory after startup, from local entropy, and receives nothing from our storage. Nothing. The device and the worker each derive the identical secret independently, so the key never crosses any wire, and the input and response directions use two independent agreements, so compromising one direction tells you nothing about the other. When the worker is destroyed, the keys are gone, and whatever ciphertext is still sitting in the mailbox is encrypted to keys that no longer exist anywhere. I want to be precise about what that means: retrospective decryption isn’t something we forbid ourselves from doing. It’s something that cannot be done.
One job, one person, never shared
One job is one user’s single payload. One person’s data, one analysis, one encrypted result, then destruction. No instance that touches plaintext is ever shared between users. Not at the same time, not one after another. Never.
The part I can’t design away
And yes, while a job runs, that one user’s decrypted data exists in that one worker’s memory for a few minutes. Every system that actually computes on plaintext data has that moment, and anyone claiming otherwise is selling something. If you want to close even that small loop, you can run this on hardware that encrypts memory itself. The disclosure says exactly where that moment lives, because I’d rather show you the boundary than pretend I built something that doesn’t have one. Purists might say this defeats the purpose. I say a pragmatic approach is exactly what privacy and security are all about - and I’ll be writing more about how this connects to real and imagined risk in future posts.
Keeping the model in its lane
Now, let’s talk about the design of the processing workflow that runs in the cloud. The inference pipeline is deterministic in the middle. A model proposes findings, using a server-enforced schema. In our case the findings are about statistical relationships between trackables or about patterns of individual items tracked. Patterns and relationships are the output. After that, ordinary, boring, testable code validates each finding with a registered statistical procedure and recalculates from the actual data, and we apply a measurement-level gate so we can avoid stupid mistakes like averaging ordinal level data. Finally, a second model call writes prose around the validated findings, pinned to exactly this run’s finding ids, ensuring it can’t merge them, invent new ones, or add entries. Two model calls. Every computed value is deterministic.
The takeaway from what I’m describing in the processing workflow is that designs need to account for the various failure modes of AI. Our product choice, for now, is to surface patterns and stay out of diagnostics altogether. But even for workflows that might incorporate diagnostics one day, what matters is how workflows are designed with layered steps that have deterministic gates between them, creating a safety mechanism. So you’re not relying on the model to behave.
Bias is one of those failure modes. In Cirdia’s example, all of our apps are dealing with health, wellness, and adjacent information. AI models have been trained on medical research which predominantly studied male bodies and published results as if they described everyone, thereby creating deep bias. In some areas of women’s health it’s far worse than bias: perimenopause and menopause affect every system in the body, and the research has barely scratched the surface. So a model asked about a woman’s body is working from a half-empty knowledge base, and it answers with exactly the same confidence as if the knowledge were whole.
Precision is the other one. We have our data schemas interacting with prompts precisely to prevent diagnostic or even normalised assessment. Most apps adding AI are adding chat. Someone asks a question, the model interprets. That pulls the worst out of the model, because interpretation is where the bias comes through, along with the opinionated normalising that decades of bad algorithms have been doing all along, assessing somebody against what the system thinks normal is. It’s not that you can’t have a model do this. It’s that chat models by themselves are not precise enough for the answer to mean anything about you, because unlike a purpose-built algorithm they have no bounded dataset behind them, just whatever they absorbed. Yes, people do want to know what they can do with their data. But when you can’t be precise enough to have it make a difference, don’t pretend.
When something breaks
Errors are the part people expect to be complicated, but this design keeps it simple. No error subsystem at all. An error is one more record in the mailbox, a category code from a closed set, riding the same path a result would. No free text, which means a worker that has seen your plaintext has no channel to leak it through. Not even by accident. Not even in a stack trace.
What this means in plain terms is that most errors just go to the device and the device will reprocess the data. This borrows from distributed designs and is a form of self-healing. Some error codes received by the mobile device are forwarded to the company API so that we can get aggregate information to see if there are patterns of failures in the system. That’s it.
Don’t take my word for any of it
And all of it is checkable. The disclosure specifies the design as compartments with testable invariants: plaintext locality, numeric authorship, single-user-per-instance, content non-persistence, operator non-custody. Auditors who don’t trust us can inspect persistent storage for prohibited key material, audit logging and retention configuration, run cross-invocation isolation tests, and trace any output number back to its computation. It runs in production today on ordinary commodity cloud. No special silicon. No attestation-gated key release. The disclosure marks what’s built, what’s designed-in, and what’s forward-looking, and it even flags an improvement we recommend over our own reference construction. I’d rather be checkable than impressive.
Any one of these choices is worth its own piece, and I’ll write them: the mailbox, the key lifecycle, what ‘one job’ actually means, why nothing leaks even in a failure mode. The disclosure has the complete version in the meantime, at the level of detail an engineer would need.
Why publish it
There are three reasons why we are publishing this instead of patenting, and they stack.
The thesis demands it. I’ve spent thirty years working on ethical business and ethical tech which has evolved to one fundamental question: how do we build organisations and systems that return capacity to people instead of extracting it? What I’ve learned through my journey is that architecture encodes values. Enclosure is a choice, the same way collecting everything is a choice. If I patented this method, I’d be fencing off the one design I most want to become ordinary. Publishing it makes the argument with the asset itself.
Trust should be checkable. A privacy promise you take on faith is policy wearing engineering’s clothes. A published method with testable invariants is different in kind. Users, integrators, regulators, auditors: they need easy ways to distinguish what is safe and what is not. That’s what ‘privacy by architecture, not policy’ means when you follow it all the way down.
Quick aside. For the last decade I worked in spaces and with teams that wanted perfect solutions. I want them too. But where I always find myself is in the pragmatic middle… I want architectures that can be adopted and used. I want architectures that don’t have an extreme cost of conversion. I want architectures that already align with many standards and with existing tooling. I fundamentally want the most people to get the promised value. And I think data-privacy is a value and promise we are still struggling to define and to deliver to people using apps all over the world.
And it’s shrewd, not sacrificial. When you disclose the core of the technology into the commons, you still leave patentable edges. If demand shows up there is territory for new patents that work adjacent to this. What we have in my company is the running fabric, the applications, the operational maturity of doing this in production. A competitor who copies the method still has to build all of that. Meanwhile every builder who adopts it moves the market toward assuming this design should exist, that privacy can exist along with a business model. That is exactly what I want. That’s not a concession. That’s the strategy.
How I want this taken on
I published this so it will be used. I want more privacy in apps. So let me be specific about who I mean.
If you build products where people confide anything (health, mood, journals, coaching, money), the design is yours. The disclosure carries the trust model, the key lifecycle, the pipeline, and the deployment variations. It was written to be buildable, not admired. And if you need more, message me. I’m happy to share more.
If you break systems for a living, the invariants are your target list. Public disclosure means people can build their own and test the invariants. We want this tested by many people. I’d love to hear from you rather than from an incident. So, reach out.
If you write the rules, meaning policy and compliance, this is what I think it looks like when a privacy claim is checkable rather than asserted. Do you agree? I think it’s fair to start expecting these kinds of architectures. Schedule a meeting, maybe there is a working group to create.
The end state I actually want is for this design to become ordinary. Boring, even. The day ‘we hold the contact and never the confided’ reads like a standard line on a privacy page instead of a differentiator, this document has done its job.
Credit
David Braden contributed the cryptographic design of the key agreement (each side derives the identical secret independently; no key material ever crosses the wire) and part of the coordination-server invariant.
The mailbox runs on Void Merge, David’s company. Their platform is free and open source, and it runs the same whether you self-host it, run it on a laptop, or pay them to host it.
Read it, build on it
If you’re building anything where people confide in your product, the design is yours now.
Hold the contact. Never hold the confided.
Find the full disclosure on the Technical Disclosure Commons.
Continue reading
- Start hereA Different Kind of VesselWhat if there were a privacy-first federated AI model for women's wellness? And what if we, collectively in femtech, were the ones who owned it?
- Who Wants Neurological Data on Midlife Women?Recent research has moved midlife symptom data from the wellness category into the neurological one. Almost no one is talking about what that means for the data women have already generated, or for where they generate it next.
- Privacy-Led UX Is the SurfaceA reaction to MIT Technology Review and Usercentrics's Privacy-Led UX in the AI Era. The report draws the surface beautifully. The architecture is the thing the surface is reflecting back.
