Privacy Policy

Privacy policy for MO§ES™ enterprise AI operator evaluation. The platform operates on content-free token counts — no prompt text, no response text, no semantic content inspected or stored.

Last updated: August 24, 2026

1. Data minimization by design

MO§ES™ is built on the principle of data minimization. The platform operates on content-free canonical telemetry — four token counts (input, output, cache read, cache write) per operator interaction. No prompt text, no response text, no file contents, and no conversation logs are collected, stored, or transmitted. The platform cannot reconstruct what an operator said to an AI system or what the AI said back.

2. Pseudonymous operator identifiers

Operators are identified by pseudonymous IDs (e.g., op_001, op_042), not by real names. The mapping between pseudonymous IDs and actual employees is maintained by the enterprise customer in their own identity system. MO§ES™ never receives, stores, or processes real names, email addresses, or HRIS identifiers.

3. No prompt-content inspection

The platform explicitly does not inspect, log, or analyze prompt content. This is a structural constraint, not a policy preference — the ingest adapters are designed to accept only token counts and metadata, not text payloads. Enterprises cannot use MO§ES™ to surveil what their employees are asking AI systems.

4. No adverse employment decisions

MO§ES™ measurements are descriptive, not prescriptive. The platform enforces this through structural guardrails in code: no bottom-employee leaderboard, no automatic adverse actions, no punitive labels, and no automatic triggers for hiring, firing, compensation, or promotion decisions. Composite scores are labeled DEVELOPMENTAL, not PERSONNEL. Outcome joins between interventions and business metrics are labeled ASSOCIATION, never CAUSATION.

5. Data retention

Telemetry data is retained for the duration of the pilot engagement plus a 90-day post-pilot review window, after which it is deleted unless the enterprise customer requests otherwise. Aggregate, de-identified statistical summaries (cohort distributions, benchmark bands) may be retained longer for reference population calibration. No individual operator data is retained beyond the customer's request.

6. Access and audit

Access to operator data is role-based (RBAC) and tenant-isolated. Every read and write operation is logged to an immutable audit trail. Enterprises can request a full audit log of all access to their data at any time. Write operations through the MCP interface require explicit authorization.

7. Tenant isolation

Each enterprise customer's data is logically isolated at the tenant level. Cross-tenant data access is not possible through the platform's interfaces. Reference populations used for external benchmarking are aggregate, de-identified, and contain no individual operator records.

8. Your rights

Enterprise customers can request export, correction, or deletion of their data at any time by contacting burnmydays@proton.me. Operators who wish to understand how their pseudonymous data is being used should direct inquiries to their enterprise's pilot administrator, as MO§ES™ does not have access to the real-name mapping.

9. Contact

For privacy inquiries: burnmydays@proton.me