Four layers, from a typed
sentence to a resolvable
unit of meaning.

This describes properties of the architecture: what is separated from what, what is encrypted, what a given component is able to read, and what the system cannot do even if someone asked it to. Those are the parts worth trusting, and the parts that are checkable.

It does not describe deployed resources — no infrastructure identifiers, no internal endpoints, no data-store or queue names, no configuration keys. Publishing those would map an attack surface without making a single claim here more credible. If a detail would help an attacker more than it would help you evaluate us, it is not on this page.

Every claim below is a property of how the system is built, not a policy we promise to follow. The distinction matters: a policy can be changed in an afternoon.

The paper's working draft 02 describes four layers that turn a typed sentence into a resolvable unit of meaning. This is what each one does in the running system.

A signal is a declaration, not an observation: what you are actually looking for, written by you. A short guided conversation helps shape it, and then you review a plain-language summary of exactly what is about to be asked, and confirm it. Nothing leaves that you have not seen. What goes out carries no personal details — the declaration travels, the declarant does not.

The signal is mapped to a node in a public taxonomy, which is what lets it be matched without anyone reading it as prose. Classification runs on open-weights models inside our own infrastructure — your declaration is not handed to a third-party model vendor to interpret. That is an architectural choice with a cost, and it is the reason this claim can be made at all.

Country is absolute. A result from the wrong market is never re-admitted further down the pipeline, by any route. And signals under-fill on purpose: a signal that finds eight candidates and serves two is the relevance gate working, not a shortfall. The gate has two layers with deliberately opposite failure modes — a deterministic check that cannot run blocks, while a judgement call that cannot run does not. A thin feed is a design outcome here, not a defect.

A brand answering your signal receives a category, a market and a readiness. No name, no email, no IP address, no device ID, no cookie, no precise location — not withheld by permission, but absent from the payload entirely. There is nothing for a brand to store, nothing to leak, and nothing to explain to a regulator. Whether to connect, and what to share if you do, stays with you afterwards.

These are properties of how the system is built rather than rules it follows. Each one is harder to walk back than the last.

Not a separate table with stricter permissions — a separate, EU-hosted database. There is no foreign key across the boundary: the link between an account and its personal details is enforced in application code, which means the system that runs the product cannot join into personal data even in a query someone writes by mistake. Services with no business touching it are not connected to it at all.

Encryption at rest at both the platform and the application layer, so the stored bytes are not readable by anything holding only the database. The application-layer keys are versioned, which is what makes rotating them an operation rather than a migration.

Finding an account by email would normally mean decrypting emails to compare them. Instead the system searches a one-way fingerprint of the value — enough to match, not enough to reverse. It is the difference between a system that chooses not to read your email on every lookup and one that is not able to.

Ask to be erased and the personal data is purged, along with the references to it across the system, and a receipt is written. The detail that matters: a receipt is written on the failure path too. A purge that keeps failing is therefore visible rather than silent — which is the failure mode that turns a deletion guarantee into a deletion claim.

The 42-True corpus is not a stored dataset kept in sync with the live system. Every release is a full rebuild from source. That single decision is what makes erasure work after publication: a person who asks to be deleted is simply absent from the next release. There is no separate copy to chase, because there is no separate copy.

Before a release is published, regions below the k-anonymity floor of 10 are suppressed at build time rather than flagged in a report — the gate runs whether or not anyone reads its output. Releases are signed, and the verification key is served publicly, so a licensee can verify a release is what we say it is without taking our word for it.

The corpus, what it contains and why it is not yet licensable is the AI Training Data tab. The argument for why declared intent is a distinct class of training data is the 42-True paper.

Every company says it respects your privacy. The useful question is not whether they mean it — it is what would have to be rebuilt for it to stop being true. Where the answer is "a setting", the claim is a policy. Where the answer is "the data model", it is architecture.

The claims on this page are the second kind. Personal data is not in the database the product queries. The lookup path has no decryption step to remove. The corpus has no stored copy to forget to purge. None of those are things we are choosing to do carefully — they are things the system is shaped to be unable to do otherwise.

This page describes the platform as built, as of August 2026. It is deliberately quiet about infrastructure. If you are evaluating Profila and need more than this — a technical review, a DPA, a security questionnaire — that is a conversation rather than a web page: [email protected].