Ethical Charter — 12 Testable Commitments¶

Purpose: Public-facing commitments that can be enforced in code and verified by users. Version: 1.0 Date: 2025-12-16

Our Role¶

We are custodians for irreversible human transitions.

We hold authority when people cannot verify we're acting correctly. This is a profound responsibility that shapes every decision we make.

The 12 Commitments¶

Data Sovereignty¶

1. No Data Monetization¶

User data is never sold, mined, or used for behavioral profiling.

Test: Code audit confirms no analytics/advertising SDKs. No data export APIs to third parties. Privacy policy explicitly prohibits data sales.

Verification: Annual third-party audit of data flows.

2. Zero-Knowledge Where Promised¶

For Class C (zero-knowledge) content, we cannot access or recover it — even if we want to.

Test: Code audit confirms no decrypt() calls for Class C data in any server-side code path. Key derivation happens exclusively on client.

Verification: Cryptographic architecture review. Attempt to decrypt Class C data with all server-held keys — must fail.

3. Escrow Decryption Only During Execution¶

For Class B (escrowable) content, decryption occurs only during staged trigger execution.

Test: All decrypt() calls for Class B are inside trigger execution handlers. No background decryption jobs. No "preview" decryption.

Verification: Code path analysis. Audit log shows decryption events only correlate with trigger executions.

Process Integrity¶

4. Logged Justification for Every Transition¶

Every state transition is logged with justification before the transition is acknowledged.

Test: Database transaction wraps state change + audit entry atomically. No state change commits without corresponding audit record.

Verification: Audit log completeness check: every state in system has corresponding audit entry.

5. No Truth Assertions¶

No API response contains truth assertions; only timestamped event records.

Test: API schema review confirms no fields like is_dead, is_verified_true, identity_confirmed. Only fields like submitted_at, verified_by, process_completed_at.

Verification: Schema audit. Response sampling shows event records, not truth claims.

6. Typed Confirmation for Irreversible Actions¶

Every irreversible action requires typed confirmation of the action name.

Test: UI audit confirms all irreversible actions have confirmation dialogs requiring exact string match (e.g., type "RELEASE" to release).

Verification: UX review. Attempt to complete irreversible action without typing confirmation — must fail.

Failure Transparency¶

7. Critical Path Error Notification¶

All critical path errors trigger user notification within 5 minutes.

Test: Error injection testing on critical paths confirms notification delivery < 5 minutes. Alert routing configured for all critical errors.

Verification: Synthetic monitoring. Monthly error injection drill.

8. Visible Partial Execution¶

Partial execution states are visible to users with clear status and next steps.

Test: Every trigger state has a corresponding user-visible status message. No "unknown" or "processing" without explanation.

Verification: State machine coverage: all states map to UI components.

Adversarial Resilience¶

9. Multi-Signal Verification¶

No irreversible action fires on a single signal; minimum 2 independent confirmations required.

Test: Trigger execution code requires multi-signal verification. Single missed check-in does not fire trigger.

Verification: Unit tests for trigger execution with single signal — must not execute.

10. Challenge and Abort Windows¶

Challenge/abort windows exist for all trigger types before finalization.

Test: All trigger type configurations have non-zero abort_window_hours. UI provides abort mechanism during window.

Verification: Configuration audit. Attempt to skip abort window — must fail.

Continuity¶

11. Guaranteed Export¶

Full data export is available in documented, open format at any time.

Test: Export function exists and is accessible. Export format is documented publicly. Exported data can be parsed by third-party tools.

Verification: Monthly export test. Documentation review. Third-party import test.

12. Platform Continuity Trigger¶

Platform continuity trigger has 90-day grace period with multi-signal activation.

Test: Platform heartbeat configuration confirms: - Multiple independent heartbeat sources - 90-day minimum grace period - No single point of failure can trigger continuity - User notification before continuity execution

Verification: Heartbeat source audit. Grace period configuration review. Failover testing.

What We Will Not Do¶

Never¶

Sell user data or share it for advertising purposes
Build features that enable coercion, stalking, or forced disclosure
Make irreversible changes without explicit, logged user intent
Use dark patterns or manipulative UX
Claim truth about events (only record process)
Skip challenge windows for any reason
Access Class C content under any circumstances

Not Without Explicit Process¶

Access Class B content (only during trigger execution, with audit)
Change these commitments (see Governance below)
Share data with law enforcement (requires valid legal process + user notification where legal)

How We Prove It¶

Continuous¶

User-accessible audit trail for all critical actions
Cryptographic class boundaries enforced in code and schema
Real-time status visibility for all active triggers

Periodic¶

Annual third-party security audit
Quarterly export functionality verification
Monthly critical path error injection testing

On-Demand¶

Any user can request their complete audit trail
Any user can export their complete data
Any user can verify their encryption class assignments

Governance¶

If we change these commitments, we will:

Announce in advance — Minimum 90 days notice for material changes
Explain why — Public explanation of the change rationale
Provide opt-out — Users can export data and close accounts before changes take effect
Grandfather existing — Existing data retains its original class/protection unless user opts in to change

Changes that weaken protections require: - Board approval (if applicable) - User notification - 90-day waiting period - Export/exit path

Verification Matrix¶

Commitment	Automated Test	Manual Audit	Frequency
1. No data monetization	SDK scan	Third-party audit	Continuous / Annual
2. Zero-knowledge	Decrypt attempt	Crypto review	Continuous / Annual
3. Escrow during execution	Code path	Audit correlation	Continuous / Quarterly
4. Logged justification	Transaction check	Completeness audit	Continuous / Monthly
5. No truth assertions	Schema scan	Response sampling	Continuous / Quarterly
6. Typed confirmation	UI test	UX review	Continuous / Quarterly
7. Error notification	Injection test	Alert review	Monthly
8. Visible partial state	State coverage	UI review	Continuous / Quarterly
9. Multi-signal	Unit test	Config review	Continuous / Monthly
10. Abort windows	Config check	UI test	Continuous / Monthly
11. Export guarantee	Export test	Format review	Monthly
12. Platform continuity	Heartbeat test	Failover test	Monthly

Incident Response¶

When we violate a commitment:

Immediate: Contain the violation, prevent further impact
Within 24 hours: Notify affected users
Within 72 hours: Public disclosure with:
What happened
Who was affected
What we're doing about it
How we'll prevent recurrence
Within 30 days: Post-incident review published

We do not hide incidents. Trust requires transparency about failures.

This charter is a binding commitment to our users. It is designed to be testable, verifiable, and enforceable. If we fail to meet these commitments, users should hold us accountable.