Platform assurance

Security & Trust

Perfect Aptitude combines role boundaries, institution scoping, private storage, signed releases, public-form protection, operational verification, and human review. Effective security still depends on correct deployment and institution operating practices.

1. Role and institution boundaries

Authenticated actions are designed around role capabilities and institution ownership. Teacher, student, Guardian, and institution administrator access is scoped to the relationships and resources the platform recognises for that account.

2. Public authentication and bot protection

Signup, verification resend, password reset, contact, and demo workflows use signed form context, freshness checks, honeypot or rate controls, and deployment-dependent Cloudflare Turnstile. Certified launch mode requires a complete Turnstile configuration for public authentication.

3. Private files and secrets

Sensitive platform files are designed for private storage rather than direct public exposure. Production deployments should use the encrypted secret vault or protected server configuration for credentials and should keep the vault key outside ordinary WordPress content.

4. Signed release integrity

Certified plugin and theme packages include SHA-256 manifests and detached RSA signatures. Package integrity and publisher trust are evaluated separately so a valid signature alone does not automatically make an unknown publisher trusted.

5. Hosting, proxy, and network boundaries

Selecting a hosting provider does not automatically trust forwarded network headers. Proxy or CDN trust must be configured independently and should be limited to the infrastructure that actually terminates or forwards production traffic.

6. Operational verification

Production Readiness and Runtime Acceptance are designed to verify release integrity, schema state, routes, role capabilities, tenant relationships, background scheduling, private storage, email delivery evidence, provider readiness, and other deployment-dependent controls. A feature being visible does not prove its runtime dependency is healthy.

7. Logging and telemetry

Operational logging and optional telemetry are intended for reliability and incident diagnosis. Sensitive context keys are redacted and REST telemetry records request paths without query strings. Deployments should still configure external observability providers according to their own privacy and retention requirements.

8. Human review remains part of the control model

Transcripts, translations, summaries, MCQs, OCR output, generated content, and other automated results can be inaccurate. Institutions and teachers remain responsible for review, approval, teaching decisions, and the suitability of published learning material.

9. Shared responsibility

No software package can guarantee security by itself. Secure operation also depends on supported WordPress and PHP versions, restrictive administrator access, timely updates, protected backups, correct DNS and TLS, trusted provider configuration, malware scanning where required, monitored background jobs, and tested recovery procedures.

For data-use details, read the Privacy Policy. To report a security or trust concern, use the contact page.