Why these are open

GeraMind is not a codebase where we can hack our way out of architectural mistakes. It is personal data, at scale, under consent. Getting the fundamentals wrong has consequences that outlast the product. Publishing the hard problems publicly is our best defence against quietly picking wrong answers.

1. Portability format

Export-on-demand is easy to promise and hard to define. What does a portable GeraMind export actually look like? A single JSON blob? A structured archive with category-specific schemas? An OpenAPI-style manifest with typed payloads? A custom MIME type that third parties can import?

Our current thinking: a layered archive — a manifest describing the schema version, plus category-specific structured exports (preferences as JSON-LD, documents as originals with signed manifests, interactions as ActivityStreams- like records). Backwards-compatible, version-tagged.

What we want input on: existing portable-data standards we should defer to instead of inventing. W3C Verifiable Credentials? Solid pods? Decentralized Identity Foundation work?

2. Deletion guarantees across backups

When a user deletes a category, what does that mean across database backups, logs, read-replicas, and analytics?

Our current thinking: encrypted storage with per-category keys. Deletion = shredding the key, not purging the ciphertext. The ciphertext in backups becomes cryptographically inaccessible at the moment of deletion, which we argue is functionally equivalent to deletion under GDPR.

What we want input on: is crypto-shredding legally equivalent to physical deletion for GDPR / UK Data Protection Act / CCPA purposes? Privacy counsel, please weigh in.

3. Inheritance

What happens to your vault when you die? A 40-year-old user today will probably still have a vault in 2070. We need to answer this before it matters.

Our current thinking: digital-estate nomination at account setup, with per-category inheritance controls (health records maybe never transfer; preferences maybe transfer to a spouse). Legally structured as a form of data bailment.

What we want input on: jurisdictions vary enormously on digital inheritance. We need a framework that defaults safely in every country we operate.

4. Identity binding across devices and agents

The vault has to know which agent, acting for which user, holds a consent token. Users run multiple agents across multiple devices over many years.

Our current thinking: per-device attestation paired with agent-instance identifiers, rooted in a user-owned master key that never leaves the user’s primary device.

What we want input on: WebAuthn / FIDO2 extensions that might bind more cleanly. Passkeys are the best UX we have seen but they are not well-suited to long-lived agent-instance binding.

5. Government access requests

When a law enforcement agency requests data, what happens? If the vault holds only ciphertext and the keys are user-held, the operator can’t comply. That is both a feature and a problem.

Our current thinking: document every lawful access request in a transparency report; surface every request to the user (where permitted); never hold a backdoor. Where compelled to disclose ciphertext only, comply and disclose the disclosure.

What we want input on: the exact shape of transparency reporting in the jurisdictions we operate. Also, anyone with experience on end-to-end-encrypted-service compelled-disclosure, please talk to us.

How to help

Comment on drafts at /research.
PRs on the reference schema (coming soon).
Letters to research at geramind dot com.
Join the waitlist for beta access.

Plug: the transactional layer that consumes vault queries is GeraNexus, also in public design. If you care about agent commerce and agent context, we’d like to compare notes with you.