The four pillars
🔒End-to-end encryption
Every submitted document is encrypted on the student's device before it is transmitted. The plaintext of the essay never touches Solus servers.
- AES-256-GCM for the document payload
- RSA-OAEP-3072 wraps the AES key per recipient
- Only the enrolled student and their assigned teacher hold the keys that unlock it
- Storage-at-rest inside Supabase is also encrypted, but the content would remain opaque even if the storage layer were compromised
✓Tamper-evident certificates
Every submitted document carries a cryptographic certificate signed by the student's personal ECDSA-P256 key. Modifying any part of the essay, the ledger, or the certificate invalidates the signature.
- ECDSA-P256-SHA256 signatures over a canonical hash of the certificate body
- Hash-chained event ledger — each event commits to the hash of its predecessor
- Public verifier at verify.soluseditor.com confirms every signature in the browser without an account
👁Human-origin verification
Beyond who wrote the file, Solus attests how it was written — every keystroke, paste, cursor jump, and pause is recorded and cryptographically committed.
- Hardware-level injected-keystroke detection on the desktop app
- Programmatic-input rejection in the browser (untrusted events blocked)
- Six behavioral signals distinguish composition from transcription
- Composite Human Confidence Score reported to the teacher — how this works
🛡Walled-garden architecture
The .solus file format is intentionally opaque to other applications. Content, provenance, and cryptographic material travel as a single sealed container that only Solus tooling can open.
- Multi-factor key derivation binds each file to the user's account and a per-file salt
- Renderer-attestation prevents third-party UIs from spoofing Solus's verification result
- Sanctioned-export path for when a certified file needs to be shared as plaintext — with an explicit "certificate voided" marker so viewers know
Compliance status
We are transparent about what is done, what is in progress, and what is on the roadmap. Institutions evaluating for pilots can request the underlying documentation at the address above.
Live
FERPA-compliant architecture. Encryption, access controls, and role-scoped RLS policies designed against FERPA requirements. Full DPA available on request.
Live
TLS 1.3 in transit + AES-256-GCM at rest. Every network hop is encrypted; every stored artifact is encrypted with modern authenticated encryption.
Live
Sub-processor transparency. Complete list of every third-party service that touches data —
sub-processors →
Live
Behavioral-analytics disclosure. Public technical documentation for how the composed-vs-transcribed detection works —
how detection works →
Live
Rate limiting on abuse surfaces. Every user-triggered notification endpoint is rate-limited per caller and per action to prevent abuse.
Roadmap
SOC 2 Type II attestation. Planned. Institutions evaluating for enterprise-scale deployment should reach out for current progress.
Roadmap
VPAT / WCAG 2.1 AA accessibility conformance. Aspirational conformance today; formal VPAT and independent audit are on the roadmap. See our
accessibility statement.
Roadmap
SDPC National Data Privacy Agreement. We will sign the NDPA on request; standardized DPAs are being adopted across our institutional pilot cohort.
Roadmap
Verifier trust chain (CA / witness / transparency log). The next major architecture family will let any third party verify not only that a .solus file is internally consistent but also that the issuing key belongs to a real enrolled Solus user. Technical specification is published; implementation is timing-gated on the patent nonprovisional.
Incident response
X Point commits to:
- Notify institutional customers of any confirmed security incident affecting their data within 72 hours of discovery.
- Publish a public post-mortem within 30 days for any incident with material customer impact.
- Preserve forensic evidence in a manner that supports customer-side investigation.
- Provide a security-issue reporting channel at soluseditor@gmail.com with acknowledgement within 3 business days.
Data lifecycle
What Solus keeps, and for how long:
- Account data (email, hashed password, display name, role) — retained while the account is active. Deletion request → removed within 30 days.
- Class rosters and assignment metadata — retained while the class or institution is active.
- Submitted .solus files — retained per the institution's data-processing agreement (default: retained until institution end-of-contract, then deleted within 90 days).
- Draft autosaves (unsubmitted) — pruned automatically after 30 days of inactivity.
- Behavioral-analytics baseline (per-user typing rhythm histogram) — retained while the account is active; deleted with the account.
- Rate-limit and audit events — retained for 60 days for abuse-monitoring, then pruned.
Individual users can request account deletion by emailing soluseditor@gmail.com. Institutional administrators can request bulk deletion / export as part of their DPA obligations.
Independent verification
The public verifier at verify.soluseditor.com confirms the cryptographic integrity of any .solus file in your browser, without an account and without sending the file to any server. The verification code is open to inspection at the URL above (view source). This is the most direct way for a skeptical reviewer to see what Solus is claiming and confirm it themselves.