Some correspondence must never sit next to anyone else's, under any circumstances. For that there is a separate perimeter: your own machine, an isolated environment, keys that never leave your hands. That is the Digital DNA tier — $1 000 once per device, then $200 a month for support.
Six things that exist at no other level of access.
A separate node standing in your building, not a slice allocated to you inside someone else's. Not an account with elevated rights — hardware you can touch, unplug and carry out of the room. The $1 000 covers the machine and its preparation, not the right to log in.
Your data does not sit beside anyone else's, not even at the storage layer. The boundary is not a row in a permissions table but the hardware itself: no shared disk, no shared process, no shared job queue.
Keys are generated inside the perimeter and remain there, including during maintenance and updates. We hold no copy, which means we cannot hand one over, cannot lose one, and cannot pass one on with the company.
Not a support queue and not a first-line bot, but one specific person who knows your configuration, your access model, and the list of things you asked nobody to touch without calling first.
Conversations go into your personal folder on their own: once an hour, or immediately once a dialogue file passes 90 KB. There is deliberately no save button — memory that depends on your discipline is not memory.
The perimeter does not ask our cloud for permission to start. If we stopped answering email tomorrow, the machine would keep running where it stands, with the data and the keys already inside it.
The distance between "you have your own folder" and "you have your own machine" is the distance between a promise and a fact.
A normal cloud service is an apartment building. The same fleet of machines serves tens of thousands of customers at once. Different people's data lives on the same disks, moves through the same queues, lands in the same logs and in the same nightly backups. The separation is enforced by code — a line that checks an owner identifier on every request.
As long as that code behaves, this is enough, and we do not think it is a bad design: the overwhelming majority of workloads are cheaper, faster and more reliable inside it. The real question is what counts as enough for your particular correspondence. One mistaken line, one debug log left switched on for an hour, one search index built with the wrong scope, and your separate folder stops being separate — quietly, with no notification to anyone.
For a family archive, working notes and most conversations, that is a rational trade: isolation costs more than the mistake would. But some material inverts the arithmetic. There the price of a single leak is not measured in money, is not settled by an apology and cannot be compensated, because what was exposed was not your secret but someone else's, handed to you under an obligation.
"Only you can see it" and "only you hold it" are two different claims, and they are confused constantly. The first is about who is permitted to look. The second is about where the thing being looked at physically sits. Between them lies the whole difference between policy and geography.
The first claim cannot be verified from outside. You are shown certifications, process descriptions and the assurances of staff, but you cannot confirm that nobody ran a query last night without your knowledge, because you have no access to that side of the wall. What remains is trust — perfectly reasonable trust, right up to the point where the stakes stop allowing for error.
The second claim takes ten seconds to verify: either the machine is in your building or it is not. A closed perimeter moves privacy out of the domain of trust and into the domain of fact. That does not mean trust becomes unnecessary. It means trust stops being the only thing holding the structure up.
Separate hardware. Your own node, your own disk, your own memory. None of it is shared with another customer under load, at idle, or during a backup window.
A separate environment. The processes of your perimeter do not sit beside anyone else's: no shared cache where a stray fragment can land, no shared job queue where your request waits between two strangers, no aggregated log that collects everything in one place for convenience.
Separate keys. They are generated on site during deployment and are never exported. This is an engineering decision rather than a contract clause: even with the most sincere intention to hand over a copy, we could not, because no copy exists.
A separate person. Your configuration is known to a named engineer, not to whoever picks up the ticket. The same person agrees the maintenance window with you and the same person answers when something goes wrong.
Honestly: not only money. Isolation costs convenience, and it is better to know that before signing rather than after the first awkward evening. Updates do not arrive silently — they go into an agreed window, which means someone on your side has to agree to it.
Responsibility for physical access moves to you. The lock, the room, the list of people entitled to walk in — those are now part of the security model, not a facilities matter. The strongest cryptography in the world does nothing about a person who walked into the room and carried the machine out.
And the important one: losing the key is irreversible. There will be nobody to call and ask for a restore — not because we would refuse, but because there is nothing to restore from. That is a direct consequence of what you are paying for, and we say it out loud in the first conversation rather than in small print on page five.
Honestly: most people do not, and we say so first.
People for whom confidentiality is not a preference but a duty owed to someone else. Your patient never chose your hosting provider and never signed anything with a cloud vendor.
Privileged material should not travel through infrastructure you cannot describe with any precision. Sooner or later somebody asks where exactly it is kept, and the answer has to be short.
When the correspondence holds ownership structure, agreements between partners and succession scenarios, the circle of readers has to be closed physically rather than by a setting.
A source taking a risk is not trusting a service or a brand. They are trusting a specific chain of custody. The shorter the chain, the more honest the promise you are able to make.
When the work outlives you, how the decisions were reached matters more than the decisions themselves — and that reasoning lives in the correspondence, not in the final documents.
Not a clause you would have to enforce in three years' time, but a machine that stands in your building and keeps working with no participation from us.
The three questions that come up at the second meeting, once the first impression has worn off.
"Keys never leave the device" reads like brochure language right up to the moment you unpack the consequences. It means three things at once: the platform cannot technically read the contents; the platform cannot hand over on demand what it does not hold; and the platform cannot restore your access if access is lost.
The first two consequences are what you are buying. The third comes attached, and it cannot be detached. A spare key kept on our side just in case would cancel the entire construction: that is the same shared access, renamed and presented as care. So there is no spare key.
Key escrow is your procedure. We help design it — where the backup lives, who is cleared to reach it, what happens when the trusted person changes, and how you verify that the backup still works. What we do not do is keep a copy, and we will never ask you to send one to us for diagnostics. If a message like that ever arrives, it is not from us.
This is where the territory of promises ends and the territory of engineering begins. A promise can be broken, forgotten, reversed by a change of management or by an external demand. The absence of a copy cannot be broken, because there is nothing there to break.
Maintenance is where privacy usually leaks. Not through an intrusion, but through routine: someone opened a log to trace a failure and saw more than they intended. In a closed perimeter the engineer sees state rather than content by construction — disk usage, component versions, the fact and the code of an error, the timestamp of the last sync.
Updates go into an agreed window. That is slower than "it landed overnight and installed itself", and it is deliberate: in a perimeter where continuity is your responsibility, nothing should change at a moment you did not know about.
A named person is not a courtesy feature. It means that when you call, you do not re-explain your configuration, re-tell the history, or argue that yours is not a standard account. The engineer who deployed your perimeter remembers why it was built that way and will not suggest rolling back to the default.
Memory across the ecosystem follows the PADAM architecture and is split into three layers, because the three jobs are different. The operational layer (Redis / Vercel KV) holds the context of the current conversation and lives exactly as long as the conversation does. The semantic layer (pgvector / Neon) stores compressed meaning rather than verbatim lines, which is what makes an old situation findable. The eternal layer (Arweave plus a Solana cNFT) is an immutable record that depends on no single company.
Saving works identically at every level of access and is not a paid feature: correspondence goes automatically into a separate folder bound personally to you, once an hour or immediately once the dialogue file exceeds 90 KB. What you pay for is limits, depth of work with memory and additional perimeters — never the basic fact that what you said does not disappear.
The closed perimeter does not change how memory is built. It changes where it lives. The working copy — the thing the assistant reads every day — sits on your machine rather than in the shared environment, and the keys that seal it sit there too. Everything else is the same three layers everyone else has.
The eternal layer is built so that a record cannot be rewritten after the fact. That is the point of it: an archive you can quietly amend is no better than a folder on a desk. It is also its limitation, and we would rather state it early — immutability does not switch off on request, or it stops being immutability.
A separate question is who pays for storage thirty years from now, long after any subscription has ended. The answer sits in the economics: 65 % of the router split goes to the treasury to buy AR for the Arweave Endowment Pool, so storage is paid for up front rather than month by month. The rest is distributed as 5 % to the Founder's Fund, 5 % to burn, and 15 / 7 / 3 % to referral levels L1 / L2 / L3. Where a level has no referral, that share goes to burn instead.
The ecosystem token is $GALATIN on Solana, with a hard cap of ten billion that cannot be raised. For a closed perimeter this matters for one reason: privacy that depends on someone paying a storage invoice every month is temporary privacy. We prefer a design where the invoice was settled in advance and does not depend on whether the company is still trading in 2056.
The same questions asked of all three levels of access in a row.
| Question | Spark · $15/mo | Family Archive · $100/mo | Digital DNA · $1 000 once, then $200/mo |
|---|---|---|---|
| Where the working copy lives | Shared environment | Shared environment | On your machine |
| Proximity to other people's data | Logical separation | Logical separation | Physical: no shared disk |
| Encryption keys | Held by the platform | Held by the platform | Inside your perimeter |
| Who can technically read it | The platform | The platform | Only you |
| Conversation saving | Hourly or at 90 KB | Hourly or at 90 KB | Hourly or at 90 KB |
| Personal folder | Yes | Yes | Yes, inside the perimeter |
| Three PADAM memory layers | Yes | Yes | Yes |
| Eternal layer on Arweave | Yes | Yes | Yes |
| Who answers when you call | Shared queue | Shared queue | A named engineer |
| Physical access to hardware | None | None | Yours: your room, your lock |
| Updates | Arrive on their own | Arrive on their own | In an agreed window |
| Runs with no link to us | No | No | Yes |
| If the key is lost | Access can be restored | Access can be restored | Nobody can restore it |
| Sensible when | You want memory and continuity | You want capacity, family access and a permanent archive | You need the data to physically sit with you |
Six steps, of which the first two cost nothing and frequently end in a no.
It starts with a conversation about what you are protecting and from whom, not with a form on a website. A clinician, a litigator and a manufacturer have different threat models, and therefore different answers.
Together we list what genuinely requires a closed perimeter. Usually not everything does: part of the correspondence is perfectly happy on Spark at $15 a month, and saying so early is more honest than selling more.
The machine is assembled and configured for the job you described. The one-off $1 000 covers the hardware and the preparation, so by the time it reaches you it already matches what was agreed.
The machine goes where you say and connects to your network. Keys are generated on site, inside the perimeter, and stay there. This step is not done in advance and it is not done remotely.
You receive access; we receive nothing. From that moment no copy of the key exists anywhere but with you, and every promise that follows rests on that fact rather than on our word.
$200 a month: a named engineer, agreed update windows, incident handling, and a periodic review of the inventory — what went into the perimeter, what stayed outside, and what should change.
Family Archive gives you higher limits, personalised knowledge bases, family access and permanent memory — but the environment is still shared, and the keys still sit on the platform side.
A closed perimeter changes geography, not capacity. The working copy and the keys move to you. If your question is "I need more room and access for my family", Family Archive is the answer. If your question is "I am not comfortable that the data is not mine to hold", only a closed perimeter is.
No, and that is a matter of keys rather than policy. The content is sealed with keys generated inside your perimeter and never exported from it. We hold no copy.
The distinction matters. "We do not read it" is a rule somebody has to follow. "We cannot read it" is a property of the design that holds by itself, including on the days when our whole team is on holiday and a contractor is handling infrastructure.
The content becomes unreadable and nobody can restore it, ourselves included. That is not a footnote — it follows directly from the previous answer. If we could restore it, we could also read it.
This is why the escrow procedure is agreed during deployment and written down on your side: where the backup lives, who is cleared to reach it, and how the right of access transfers when the trusted person changes. We help design that procedure; we take no part in storing it.
We hand over what we actually hold: the fact that a contract exists and the technical parameters of the service. We do not hold the content of your correspondence in any form, so handing it over is not something we decline — it is something we cannot do.
This is not legal advice and it is not a promise about how any particular jurisdiction behaves. It is a description of what could in principle be produced by us, because it is with us. Everything else is with you, and those questions will be addressed to you.
Wherever you control the room and know the list of people who can enter it. A private practice, a server room and a home study carry different trade-offs, and that is decided in conversation rather than by default.
Physical access becomes part of the security model, and that changes habits. The strongest encryption available is useless against someone who walked in, powered the machine down and carried it away. We work through that scenario too, down to what to do in the first thirty minutes.
Because you are not paying for the right to log in. You are paying for hardware and the work of preparing it. An account is a row in someone else's database: it can be duplicated, migrated and revoked. A machine exists once and stands in one specific room.
The practical consequence follows: two independent perimeters mean two machines. The split is usually made by meaning — the practice and the family archive, live matters and the long archive that is opened once a year.
The perimeter keeps working. It does not ask our cloud for permission to boot and it does not go quiet because a subscription lapsed somewhere. The machine is in your building, the data is on it, the keys are in it.
The eternal layer sits on Arweave and does not depend on any one company continuing to exist. Storage is paid up front: 65 % of the router split goes to the treasury to buy AR for the Arweave Endowment Pool. The design is meant to outlive its authors rather than to be maintained by them.
No. The named engineer is the answer to that: deployment, updates, diagnostics and incidents are covered by the $200 a month. There is no additional hire to make.
You do need someone accountable for the key to the room and for the list of people cleared to enter, and that is not a technical role. In practice it is usually whoever is already accountable for the safe or the company seal.
Yes, and in most cases you should. Spark at $15 a month or Family Archive at $100 a month is a sensible entry point: you will see how the memory behaves, what accumulates in it, and whether any of this is worth the effort for you.
A closed perimeter makes sense once you can say in your own words what will live in it and why that cannot live in a shared environment. Until you have that answer, moving up is premature, and we will tell you so plainly.
No. We describe technical properties, not legal status. Medical and attorney-client confidentiality are governed by the law of your jurisdiction, and no machine substitutes for complying with it.
Technically, a closed perimeter removes a third party that would otherwise have to be trusted with someone else's secret. The legal conclusion is drawn by your counsel, who knows your practice. We can document the configuration in enough detail for them to assess it.
An immutable record bound to you. It cannot be removed after the fact, and that is a condition rather than an oversight: a record that can be quietly edited proves nothing thirty years later.
This is worth understanding before the first conversation with an assistant rather than after the hundredth. Immutability is a strong property precisely because it does not switch off on request — including on yours.
Write to contact@codeofdigitaleternity.com and describe the situation in your own words: what you are protecting, from whom, where you physically are, and whether you have a room for the machine. There is no twenty-field form.
The first conversation commits you to nothing and quite often ends with the conclusion that you do not need a closed perimeter and a standard tier is plenty. We treat that as a good outcome, not a lost deal.