Why this note exists
Household information deserves serious security language. It also deserves language that does not imply protection the current product, deployment, and policy have not earned.
This note sets out the technical boundary that needs current confirmation before it can become a public assurance. It is deliberately more useful than a badge and less absolute than a marketing promise.
The review boundary
Client scope to verify
Before publication, the technical review must define exactly which client versions and vault payloads are protected on device and how they reach the service.
Operational data must be distinct
The final paper must distinguish vault content from account, service, and operational metadata. That distinction should be visible rather than hidden in a footnote.
Version and deployment matter
Protection depends on the release in use, the deployed configuration, and the path a record took into the current system. Legacy and future clients cannot be assumed to have identical behavior.
What this note does not claim
- That every record, client, upload path, or deployment has identical protection.
- That a system is immune to breach, account compromise, human error, or operational failure.
- That Stemma has an independent audit, certification, or legal compliance status unless current public evidence is published for it.
What must be verified before a final paper
Engineering and security owners need to validate deployed configuration, supported client versions, legacy-data treatment, recovery paths, monitoring, and incident response. Legal owners need to approve the exact public wording and supporting policy commitments.
When those reviews are complete, this page can be expanded into a versioned technical paper with source references and a publication date.
Read the public security posture
The security page gives the concise, household-readable version of this boundary.
Security, stated plainly