Law Enforcement Guidelines
How Kemet receives, evaluates, and responds to legal process and emergency requests.
Publication details
The Kemet Network
On this page
2. TECHNICAL ARCHITECTURE AND INHERENT LIMITATIONS
3. WHAT DATA WE POSSESS AND CAN DISCLOSE
4. WHAT DATA WE DO NOT POSSESS AND CANNOT DISCLOSE
6. REQUEST VALIDATION AND AUTHENTICATION
7. EMERGENCY DISCLOSURE PROCEDURES
8. INTERNATIONAL REQUESTS AND MLAT PROCEDURES
10. USER NOTIFICATION AND TRANSPARENCY
11. REJECTION OF OVERBROAD OR INVALID REQUESTS
13. RECORD KEEPING AND TRANSPARENCY REPORTING
1. INTRODUCTION AND SCOPE
1.1 Purpose and Philosophy
Kemet ("The Network," "we," "us," "our") publishes these Law Enforcement Guidelines ("Guidelines") to provide transparency regarding our policies and procedures for responding to legal requests from law enforcement agencies, government authorities, and other entities exercising investigative or regulatory powers (collectively, "Requesting Parties").
These Guidelines serve three fundamental purposes:
(a) Transparency: To inform Requesting Parties, users, and the public about our technical capabilities, legal standards, and operational procedures; (b) Efficiency: To streamline the process for valid legal requests while minimizing unnecessary friction for legitimate investigations; (c) Protection: To safeguard user privacy and cryptographic sovereignty by ensuring requests are narrowly tailored, legally valid, and technically feasible.
1.2 The Zero-Knowledge Constraint
Requesting Parties must understand a foundational technical reality: Kemet operates a zero-knowledge architecture with respect to user communications. We have engineered The Network such that we mathematically cannot access the content of encrypted communications, even if compelled by legal process. This is not a policy choice or act of resistance; it is a cryptographic certainty.
Consequently, these Guidelines emphasize what we cannot provide as much as what we can. We will not accept requests for data that our architecture renders impossible to produce, nor will we create backdoors, master keys, or decryption capabilities that would compromise the security of all users.
1.3 Scope of Application
These Guidelines apply to:
(a) All law enforcement agencies, including federal, state, local, tribal, and territorial authorities; (b) Government intelligence and security services; (c) Regulatory and administrative agencies with investigative authority; (d) International law enforcement agencies and INTERPOL; (e) Military authorities, where authorized to exercise law enforcement functions; (f) Private entities acting under color of law or statutory authority (e.g., court-appointed receivers, bankruptcy trustees).
These Guidelines do not apply to:
(a) Civil litigation between private parties (see Section 5.6); (b) Requests from individuals not acting under legal authority; (c) Requests from foreign governments without appropriate international process.
1.4 Legal Hierarchy
These Guidelines are subordinate to and must be read in conjunction with:
(a) The Terms of Service (KEM-LEG-001), particularly Section 8.4 (Law Enforcement and Legal Process); (b) The Privacy Policy (KEM-LEG-002), particularly Section 6.3 (Law Enforcement and Legal Requests); (c) The Community Covenant (KEM-LEG-003), particularly Article VI (Enforcement and Evidence Preservation); (d) Applicable law, including the Electronic Communications Privacy Act (ECPA), Stored Communications Act (SCA), and foreign equivalents.
In the event of conflict between these Guidelines and binding legal process, we will comply with the legal process while seeking to minimize disclosure to the extent technically and legally possible.
1.5 No Waiver of Rights
Publication of these Guidelines does not constitute a waiver of any legal rights or defenses available to Kemet or our users. We reserve the right to challenge any legal request on any available ground, including constitutional, statutory, or common law bases.
2. TECHNICAL ARCHITECTURE AND INHERENT LIMITATIONS
2.1 Zero-Knowledge Design Principles
Kemet was designed with three cryptographic principles that fundamentally constrain our ability to respond to legal requests:
(a) End-to-End Encryption (E2EE): All Direct Messages and private Group communications use the Kemet Secure Messaging Protocol (KSMP) with XChaCha20-Poly1305 encryption. Content is encrypted on the sender's device and can only be decrypted by the recipient's device. We do not possess decryption keys.
(b) Non-Custodial Identity: Users generate and control their own cryptographic identity (Vault Key, Identity Key, PreKeys). We do not possess users' private keys, recovery phrases, or Vault Keys. We cannot reset passwords, recover accounts, or transfer identities between devices.
(c) Client-Side Processing: All cryptographic operations (encryption, decryption, key generation, signing) occur on user devices. Our servers process only encrypted binary data (ciphertext) and routing metadata.
2.2 Technical Impossibilities
Requesting Parties should not submit requests for the following categories of data, as our architecture renders production impossible:
(a) Content of Direct Messages or encrypted Group communications (cannot decrypt); (b) Users' Vault Keys, recovery phrases, or private cryptographic material (we do not possess); (c) Decrypted social graph or contact lists (stored encrypted, keys held by users); (d) Real-time interception of communications (no capability to intercept and decrypt); (e) Decryption of historical encrypted data (no backdoors or master keys exist); (f) Geolocation data beyond optional self-reported location (no GPS tracking, no cell tower data); (g) Browsing history or search queries within The Network (not logged); (h) Content deleted by users (irretrievably destroyed per retention schedules).
2.3 Metadata Limitations
While we process certain metadata necessary for network operation, this data is minimized, hashed, and rotated:
(a) IP Hashes: We store only salted, hashed representations of IP addresses, rotated every 3-7 days. We cannot provide raw IP addresses or historical IP data beyond the current rotation period.
(b) Device Fingerprints: We store hashed representations of device characteristics for abuse prevention. These cannot be reverse-engineered to identify specific device models or hardware configurations outside our system.
(c) Behavioral Entropy: We process real-time pattern analysis for abuse detection, but this data is not retained beyond 3-7 days and is not linked to persistent identifiers.
2.4 Architectural Integrity Policy
We will not:
(a) Modify our architecture to create decryption capabilities; (b) Retain data beyond specified retention periods to accommodate future legal requests; (c) Implement key escrow or lawful interception capabilities; (d) Bypass or weaken encryption for any purpose; (e) Provide "exceptional access" mechanisms for law enforcement.
Any request requiring such modifications will be rejected as technically impossible and contrary to our security architecture.
3. WHAT DATA WE POSSESS AND CAN DISCLOSE
3.1 Categories of Available Data
Subject to valid legal process and authentication, we can provide the following categories of data:
3.1.1 Account Metadata
(a) Node ID (public key identifier); (b) Account creation timestamp; (c) Account status (active, suspended, terminated); (d) Trust Score (algorithmic reputation metric); (e) Subscription tier (Kemet, Kemet+, Kemet++); (f) Last activity timestamp (not precise location or IP).
3.1.2 Public Content
(a) Public Posts (text, media URLs, engagement metrics); (b) Public profile information (display name, username, bio, avatar, self-reported location, website URL); (c) Public Group memberships and public Group content; (d) External share settings and public engagement data.
Note: Public Content is, by definition, publicly visible on The Network. Requesting Parties can access this data without legal process by creating a Node and viewing public feeds.
3.1.3 Security and Abuse Prevention Data
(a) Current IP Hash (salted, hashed representation of IP address); (b) Device Fingerprint Hash (hashed device characteristics); (c) Rate limiting records and temporary blocks (3-7 day retention); (d) Report history (aggregated counts, not reporter identities); (e) Audit logs of administrative actions (hashed, tamper-evident).
3.1.4 Encrypted Data (Without Decryption Capability)
(a) Encrypted message payloads (binary blobs, mathematically indecipherable without recipient keys); (b) Encrypted social graph data (binary blobs); (c) Encrypted private profile settings (binary blobs).
We can provide encrypted data in response to legal process, but we cannot decrypt it. The requesting party must obtain decryption keys from the user or through device seizure.
3.2 Data Retention Periods
All available data is subject to the retention periods specified in KEM-LEG-002, Section 7.2. Key limitations:
(a) IP Hashes: 3-7 days (rotating); (b) Behavioral signals: 3-7 days; (c) Undelivered encrypted messages: 7 days; (d) Rate limiting data: 3-7 days; (e) Public Content: Until user deletion or account termination; (f) Audit logs: Indefinite (hashed, anonymized).
Data not retained cannot be produced, regardless of legal process.
3.3 Preservation of Data
Upon receipt of a valid preservation request (see Section 9), we will suspend routine deletion of specified data categories for 90 days, renewable for additional 90-day periods. Preservation does not include data already deleted or data outside specified retention periods.
4. WHAT DATA WE DO NOT POSSESS AND CANNOT DISCLOSE
4.1 Absolute Technical Impossibilities
The following categories of data are categorically unavailable due to our architecture:
4.1.1 Decrypted Communications
(a) Content of Direct Messages; (b) Content of encrypted Group communications; (c) Voice messages (when implemented); (d) Video calls (when implemented); (e) File attachments in encrypted form.
4.1.2 Cryptographic Key Material
(a) Users' Vault Keys or recovery phrases; (b) Users' private Identity Keys; (c) Users' private PreKeys; (d) Any master key or backdoor capable of decrypting user communications.
4.1.3 Precise Identity and Location
(a) Real names (unless voluntarily provided in public profile); (b) Email addresses (not collected); (c) Phone numbers (not collected); (d) Government-issued identification (not collected); (e) Physical addresses (not collected); (f) Precise geolocation (GPS coordinates, cell tower data); (g) Raw IP addresses (only salted hashes retained).
4.1.4 Behavioral and Content Data
(a) Browsing history on or off The Network; (b) Search query history (search vectors generated client-side); (c) Content consumption patterns (what users read or view); (d) Private social connections (encrypted, unreadable to us); (e) Deleted content (irretrievably destroyed per retention policy).
4.2 Requests We Will Reject
We will reject or seek to narrow the following types of requests:
(a) "All data" or "complete account history" requests (overbroad); (b) Requests for decrypted content (technically impossible); (c) Requests for real-time interception (no capability); (d) Requests for prospective data beyond preservation periods; (e) Requests requiring architectural modifications; (f) Requests for data outside applicable retention periods; (g) Gag orders of indefinite duration or excessive scope.
4.3 Standard Response to Unavailable Data
When served with legal process seeking unavailable data, we will:
(a) Provide this Guidelines document as explanation; (b) Specify which requested categories are technically impossible; (c) Offer available data categories responsive to the request; (d) Suggest alternative methods (e.g., device seizure, user consent); (e) Move to quash or modify overbroad requests where appropriate.
5. LEGAL PROCESS REQUIREMENTS
5.1 United States Legal Process
For requests from U.S. law enforcement, we require the following legal process depending on the category of data sought:
5.1.1 Basic Subscriber Information
Includes: Node ID, account creation date, account status, subscription tier.
Required Process: Subpoena (state or federal), 18 U.S.C. § 2703(c)(2).
5.1.2 Content and Communications
Includes: Public Posts, public profile information, encrypted message payloads (undecryptable).
Required Process: Search warrant, 18 U.S.C. § 2703(a), based on probable cause.
Note: While Public Posts are publicly visible, we require a warrant for production to ensure proper authentication and chain of custody for evidentiary purposes.
5.1.3 Transactional and Security Data
Includes: IP Hashes, Device Fingerprints, rate limiting records, metadata regarding account access.
Required Process: Search warrant or 18 U.S.C. § 2703(d) court order (specific and articulable facts showing reasonable grounds to believe data relevant and material to investigation).
5.1.4 Real-Time or Prospective Surveillance
Includes: Any form of ongoing surveillance, interception, or prospective data collection.
Required Process: Not applicable. We have no capability to conduct real-time surveillance or interception. Such requests will be rejected as technically impossible.
5.2 State and Local Law Enforcement
State and local agencies must provide legal process issued under the laws of their jurisdiction, consistent with federal constitutional requirements. We will evaluate state-level subpoenas, warrants, and court orders on a case-by-case basis for validity and enforceability.
5.3 International Law Enforcement
For requests from non-U.S. law enforcement, see Section 8 (International Requests and MLAT Procedures). We generally require Mutual Legal Assistance Treaty (MLAT) process or letters rogatory for international requests.
5.4 Emergency Requests
In emergencies involving imminent death or serious physical injury, see Section 7 (Emergency Disclosure Procedures). Emergency disclosures are voluntary and limited to specific, articulable threats.
5.5 National Security Requests
We may receive requests under the Foreign Intelligence Surveillance Act (FISA), National Security Letters (NSLs), or other national security authorities. We will comply with valid, legally binding national security requests subject to the following:
(a) We will challenge requests we believe are unlawful or overbroad; (b) We will seek to narrow requests to the extent technically and legally possible; (c) We will publish aggregate statistics on national security requests to the extent permitted by law; (d) We will notify affected users of national security requests after any gag order expires, unless prohibited indefinitely.
5.6 Civil Requests and Private Litigation
We generally do not provide data in response to civil subpoenas or discovery requests from private litigants. Exceptions:
(a) When accompanied by a court order directing production; (b) When the requesting party demonstrates that the data is not available through other means; (c) When the user has provided consent to disclosure.
Private litigants seeking user data should obtain the user's consent or seek discovery directly from the user.
5.7 Required Content of Legal Process
All legal process must include:
(a) Identifying information: Name and jurisdiction of the issuing authority; (b) Case reference: Case number, docket number, or investigation identifier; (c) Specificity: Specific categories of data requested, date ranges, and identifying information (Node ID, username, or other account identifiers); (d) Legal basis: Statutory or other legal authority for the request; (e) Authentication: Signature of issuing judge or authorized official; (f) Contact information: Name, title, and contact details of the requesting officer or attorney.
Vague, overbroad, or boilerplate requests will be rejected or returned for clarification.
6. REQUEST VALIDATION AND AUTHENTICATION
6.1 Submission Procedures
Legal requests must be submitted to:
Email: legal@kemet.network (preferred for preservation requests and inquiries) Postal Mail: [To be updated upon Delaware C-Corp formation and registered agent designation]
For time-sensitive matters, email is strongly preferred. Email submissions should include "LEGAL REQUEST" or "URGENT LEGAL REQUEST" in the subject line.
6.2 Authentication of Requesting Party
Before processing any legal request, we will authenticate the requesting party's identity and authority:
(a) Verify that the request originates from a legitimate law enforcement agency or government authority; (b) Confirm that the requesting individual is authorized to make requests on behalf of that agency; (c) Validate signatures and seals on warrants, orders, and subpoenas; (d) Contact the issuing authority through independently verified contact information (not contact details provided in the request) to confirm authenticity if doubts exist.
We will not process requests from unverified sources or where authentication cannot be completed.
6.3 Review for Validity and Scope
Upon authentication, we will review the request for:
(a) Facial validity of the legal process (proper form, authorized signature, applicable legal basis); (b) Scope limitations (specificity of data requested, date ranges, account identifiers); (c) Compliance with applicable law (ECPA, SCA, state law, international treaties); (d) Technical feasibility (whether requested data exists and can be produced); (e) Overbreadth (whether request seeks more data than necessary).
Requests failing any of these criteria will be rejected, returned for clarification, or challenged through appropriate legal channels.
6.4 Production Timeline
Our standard timeline for responding to legal requests:
(a) Acknowledgment: Within 2 business days of receipt; (b) Authentication and review: 5-10 business days; (c) Production or response: 10-15 business days from acknowledgment for routine requests; (d) Complex requests: 30 days or longer, depending on scope and volume.
Emergency requests (imminent danger) will be expedited. Preservation requests will be acknowledged within 1 business day.
6.5 Format of Production
Data will be produced in electronic format (encrypted files, PDFs, or structured data formats) via secure transfer. We do not provide oral testimony or expert witness services in response to legal requests. Physical production of hard copies will be provided only when specifically required by legal process.
7. EMERGENCY DISCLOSURE PROCEDURES
7.1 Emergency Exception
We may disclose information without legal process if we have a good faith belief, based on specific and articulable facts, that such disclosure is necessary to prevent:
(a) Imminent death or serious physical injury to any person; (b) Terrorism or violent extremism involving imminent threat to life; (c) Child sexual exploitation involving imminent threat to a minor; (d) Severe harm to The Network infrastructure affecting user safety.
7.2 Emergency Request Requirements
Emergency requests must include:
(a) Specific threat: Detailed description of the imminent harm; (b) Factual basis: Specific facts supporting the belief that harm is imminent; (c) Data sought: Specific categories of data believed necessary to prevent harm; (d) Temporal urgency: Explanation of why legal process cannot be obtained in time; (e) Requesting party: Identity, agency, and contact information of the requesting officer; (f) Certification: Statement that the request is made in good faith and based on reasonable belief.
7.3 Review and Decision
Emergency requests will be reviewed by:
(a) Initial review: Trained legal or trust and safety personnel; (b) Escalation: Senior management or legal counsel for high-stakes decisions; (c) Documentation: All emergency disclosures will be documented in our audit trail.
We will not disclose data based solely on law enforcement assertion of emergency; we require specific, articulable facts demonstrating imminent harm.
7.4 Limitations on Emergency Disclosure
Even in emergencies, we will not:
(a) Decrypt encrypted communications (technically impossible); (b) Provide data outside applicable retention periods; (c) Create new surveillance or interception capabilities; (d) Disclose data where the threat is not imminent or specific; (e) Disclose data for investigations of non-violent crimes or property crimes.
7.5 Post-Emergency Process
Following an emergency disclosure:
(a) We will preserve all relevant data and documentation; (b) We will require the requesting party to obtain formal legal process within 48 hours retroactively; (c) We will notify the affected user unless prohibited by law or if notification would jeopardize an ongoing investigation; (d) We will include the disclosure in our transparency reporting.
8. INTERNATIONAL REQUESTS AND MLAT PROCEDURES
8.1 General Policy
Kemet operates globally but is headquartered in the United States. We generally require U.S. legal process for all data production. International law enforcement agencies should use Mutual Legal Assistance Treaty (MLAT) procedures, letters rogatory, or other international legal cooperation mechanisms to obtain U.S. legal process.
8.2 Mutual Legal Assistance Treaty (MLAT) Process
For countries with MLAT agreements with the United States:
(a) Submit request through your central authority to the U.S. Department of Justice Office of International Affairs; (b) The U.S. DOJ will review and, if appropriate, obtain U.S. legal process (subpoena, court order, or warrant); (c) We will respond to the U.S. legal process as described in Section 5.
MLAT requests provide dual-layer review (requesting country and U.S.) ensuring compliance with both jurisdictions' laws.
8.3 Countries Without MLAT
For countries without MLAT agreements:
(a) Submit request via letters rogatory through diplomatic channels; (b) The request must be endorsed by a U.S. court to be enforceable; (c) We will respond to U.S. court-endorsed process.
Direct requests from non-MLAT countries without U.S. court endorsement will generally not be honored.
8.4 Emergency International Requests
In emergencies involving imminent threat to life, international agencies may submit emergency requests directly to legal@kemet.network. We will evaluate such requests under the standards in Section 7, with additional scrutiny due to the absence of U.S. legal process.
8.5 Data Localization Requirements
Some jurisdictions require data to remain within their borders or prohibit transfer to other countries. We do not currently offer data localization. By using The Network, users consent to data transfer to and processing in the United States. We will comply with valid U.S. legal process regardless of data localization requirements in other jurisdictions.
8.6 Conflict of Laws
Where foreign law conflicts with U.S. law or our contractual obligations to users, we will generally prioritize:
(a) U.S. legal process and court orders; (b) Our Terms of Service and Privacy Policy; (c) User privacy and cryptographic security.
We may challenge foreign orders that conflict with U.S. law or fundamental rights.
9. PRESERVATION REQUESTS
9.1 Purpose and Scope
Law enforcement may request preservation of data pending the issuance of legal process. Preservation ensures that routinely deleted data (IP Hashes, behavioral signals, undelivered messages) is retained beyond standard retention periods.
9.2 Preservation Request Requirements
Preservation requests must include:
(a) Identifying information: Node ID, username, or other account identifiers; (b) Data categories: Specific categories of data to be preserved; (c) Time period: Date range of data to be preserved; (d) Basis: Statement that legal process will be sought; (e) Contact information: Requesting officer name, agency, and contact details.
9.3 Preservation Period
Upon receipt of a valid preservation request:
(a) We will suspend routine deletion of specified data categories for 90 days; (b) The preservation period may be extended for additional 90-day periods upon request; (c) Maximum preservation period: 180 days without formal legal process; (d) If legal process is not received within the preservation period, preserved data will be deleted according to standard retention schedules.
9.4 Limitations on Preservation
(a) We cannot preserve data already deleted at the time of the request; (b) We cannot preserve data outside applicable retention periods retroactively; (c) Preservation does not include creation of new data or logging of future activity; (d) We will not preserve data indefinitely without legal process.
9.5 Confirmation of Preservation
We will confirm receipt of preservation requests within 1 business day, specifying:
(a) Which data categories are being preserved; (b) The preservation expiration date; (c) Any limitations or data categories unavailable.
10. USER NOTIFICATION AND TRANSPARENCY
10.1 General Notification Policy
We believe users have a right to know when their data is sought by law enforcement. Our default policy is to notify users of legal requests seeking their data, unless:
(a) Prohibited by law (gag order, statutory prohibition); (b) Notification would create imminent danger of death or serious physical injury; (c) Notification would compromise an ongoing investigation (temporary delay); (d) The request seeks only publicly available data (notification not meaningful).
10.2 Delayed Notification
Where notification is delayed due to ongoing investigation concerns:
(a) We will notify the user as soon as the investigation concludes or the danger passes; (b) We will challenge indefinite gag orders to the extent legally permissible; (c) We will include delayed notifications in transparency reporting.
10.3 Emergency Disclosure Notification
For emergency disclosures under Section 7:
(a) We will notify the user as soon as the emergency has passed and notification would not jeopardize safety; (b) If law enforcement requests continued confidentiality, we will require legal process (gag order) to justify delay beyond the emergency period.
10.4 Transparency Reporting
We will publish periodic transparency reports (semi-annually or annually) including:
(a) Total number of legal requests received, by type (subpoena, warrant, court order, emergency, international); (b) Number of requests resulting in data disclosure; (c) Number of requests rejected or narrowed; (d) Number of users affected by legal requests; (e) Number of emergency disclosures; (f) Number of preservation requests.
Reports will be published on legal.kemet.network.
10.5 Individual User Access
Users may request records of legal process seeking their data by contacting legal@kemet.network. We will provide available records subject to authentication of Node ownership and legal constraints.
11. REJECTION OF OVERBROAD OR INVALID REQUESTS
11.1 Overbreadth Challenges
We will reject or seek to narrow requests that are overbroad, including:
(a) Requests for "all data" or "complete account history" without specificity; (b) Requests for data of multiple users without individual justification; (c) Requests for data outside applicable retention periods; (d) Requests seeking categories of data we do not possess; (e) Requests with no temporal limitation.
11.2 Invalid Process
We will reject requests that:
(a) Lack proper authentication or authorization; (b) Are issued by courts without jurisdiction; (c) Seek data in violation of applicable law; (d) Are facially invalid or defective; (e) Constitute abuse of legal process.
11.3 Challenging Requests
We may challenge legal requests through:
(a) Motion to quash or modify; (b) Request for clarification or narrowing; (c) Objection on grounds of overbreadth, vagueness, or technical impossibility; (d) Appeal of orders requiring disclosure we believe unlawful.
We will notify the requesting party of our intent to challenge and provide opportunity to narrow the request before initiating formal legal challenges.
11.4 User Notification of Challenges
When we challenge a legal request, we will:
(a) Notify the user unless prohibited by law; (b) Provide the user with opportunity to intervene or challenge independently; (c) Cooperate with user's legal counsel to the extent permissible.
12. COST REIMBURSEMENT
12.1 General Policy
We may seek reimbursement for costs associated with responding to legal requests, particularly for:
(a) Extensive or voluminous requests requiring significant technical resources; (b) Requests requiring custom data extraction or format conversion; (c) Requests requiring legal review or consultation with counsel; (d) International requests requiring additional authentication or translation.
12.2 Cost Schedule
Standard costs (indicative, subject to actual costs incurred):
(a) Basic subscriber information: No charge; (b) Content production (warrant): $50-$200 per account; (c) Extensive historical data: $200-$500 per account; (d) Emergency requests: No charge (public safety priority); (e) Preservation requests: No charge.
12.3 Fee Waiver
We may waive fees for:
(a) Emergency requests involving imminent threat to life; (b) Requests from agencies with limited resources (small departments, international agencies from developing countries); (c) Requests where costs would impede investigation of serious crimes.
13. RECORD KEEPING AND TRANSPARENCY REPORTING
13.1 Audit Trail
All legal requests and responses are logged in our immutable, hash-chained audit trail (Blockchain), including:
(a) Timestamp of request receipt; (b) Requesting agency and officer; (c) Type of legal process; (d) Data categories requested; (e) Data categories produced or rejected; (f) Timeline of response; (g) Emergency disclosure justifications; (h) Challenges or modifications to requests.
13.2 Data Retention for Legal Matters
Data related to legal requests will be retained:
(a) For the duration of any applicable legal hold or litigation hold; (b) For the statute of limitations period for related claims; (c) Indefinitely for audit trail entries (hashed, tamper-evident).
13.3 Transparency Report Contents
Transparency reports will include:
(a) Aggregate statistics on request volume and types; (b) Percentage of requests resulting in disclosure; (c) Breakdown by requesting jurisdiction; (d) Number of emergency disclosures; (e) Number of users affected; (f) Number of requests challenged or rejected; (g) Policy updates or significant legal developments.
13.4 Report Frequency
Transparency reports will be published:
(a) Semi-annually (every six months) once operational; (b) Annually during initial launch phase; (c) Ad hoc for significant events or policy changes.
14. TRAINING AND OVERSIGHT
14.1 Personnel Training
Personnel handling legal requests receive training on:
(a) Technical architecture and data availability; (b) Legal standards for different categories of requests; (c) Authentication and fraud prevention; (d) User privacy and constitutional protections; (e) Emergency procedures and escalation protocols; (f) Documentation and audit trail requirements.
14.2 Oversight and Review
Legal request handling is subject to:
(a) Regular audit of compliance with these Guidelines; (b) Review of emergency disclosures for proper justification; (c) Legal counsel oversight for complex or novel requests; (d) Periodic policy review and updates.
14.3 Accountability
Violations of these Guidelines by personnel will result in disciplinary action, up to and including termination. Users may report concerns about legal request handling to legal@kemet.network.
15. CONTACT INFORMATION
15.1 Law Enforcement Contact
For legal requests, preservation requests, and inquiries:
Email: legal@kemet.network Subject Line: "LEGAL REQUEST" or "URGENT LEGAL REQUEST" for emergencies
Postal Mail: [To be updated upon Delaware C-Corp formation and registered agent designation]
15.2 Emergency Contact
For emergencies involving imminent death or serious physical injury:
Email: legal@kemet.network Subject Line: "URGENT EMERGENCY REQUEST"
Include "EMERGENCY" in subject line and provide: - Requesting officer name and direct contact number; - Nature of emergency; - Specific data sought; - Factual basis for emergency.
15.3 Response Timeframes
(a) Emergency requests: Immediate review, response within 2 hours during business hours, 4 hours outside business hours; (b) Preservation requests: Acknowledgment within 1 business day; (c) Routine legal requests: Acknowledgment within 2 business days, production within 10-15 business days.
15.4 Questions About Guidelines
For questions about these Guidelines, our technical capabilities, or legal process requirements:
Email: legal@kemet.network
We do not provide legal advice to law enforcement or users regarding specific investigations or legal strategies.
APPENDIX A: REQUEST TEMPLATES AND CHECKLISTS
A.1 Preservation Request Template
To: legal@kemet.network Subject: PRESERVATION REQUEST - [Case Number]
I, [Name], [Title], of [Agency], hereby request preservation of data pursuant to 18 U.S.C. § 2703(f).
Case Identifier: [Case number] Investigation: [Brief description of investigation]
Account Information: - Node ID: [If known] - Username: [If known] - Other identifiers: [Email, phone, etc. if known]
Data Categories to Preserve: [ ] Account metadata [ ] IP Hashes [ ] Device Fingerprints [ ] Public Posts [ ] Encrypted message metadata (timestamps, routing) [ ] Other: [Specify]
Date Range: [Start date] to [End date]
Certification: I certify that this request is made in good faith and that legal process will be sought within 90 days.
Contact Information: Name: [Full name] Title: [Rank/Title] Agency: [Full agency name] Phone: [Direct number] Email: [Official email]
Signature: [Electronic signature acceptable] Date: [Date]
A.2 Emergency Request Template
To: legal@kemet.network Subject: URGENT EMERGENCY REQUEST - [Nature of Emergency]
EMERGENCY DISCLOSURE REQUEST
Requesting Officer: [Name, Title, Agency] Direct Phone: [Number] Emergency Contact: [Number]
Nature of Emergency: [Detailed description of imminent threat to life or serious physical injury]
Factual Basis: [Specific facts supporting imminent threat]
Data Sought: [Specific categories of data believed necessary to prevent harm]
Why Legal Process Cannot Be Obtained: [Explanation of temporal urgency]
Certification: I certify under penalty of perjury that: 1. The above facts are true and correct to the best of my knowledge; 2. This request is made in good faith; 3. Disclosure is necessary to prevent imminent death or serious physical injury; 4. Legal process will be sought within 48 hours.
Signature: [Electronic signature] Date/Time: [Date and time]
A.3 International Request Template
To: legal@kemet.network Subject: INTERNATIONAL LEGAL ASSISTANCE REQUEST - [Country] - [Case Number]
Requesting Authority: [Agency name, Country] MLAT Reference: [MLAT case number, if applicable] U.S. DOJ Reference: [If available]
Nature of Request: [Description of investigation and data sought]
Legal Basis: [Statutory authority in requesting country]
U.S. Legal Process: [ ] MLAT request submitted to U.S. DOJ [ ] Letter rogatory issued [ ] Other: [Specify]
Account Information: [Node ID, username, or other identifiers]
Data Categories: [Specific data requested]
Certification: I certify that this request is made in accordance with [treaty/law] and is subject to dual criminality principles.
Contact Information: [Name, title, agency, email, phone]
Signature: [Electronic signature] Date: [Date]
APPENDIX B: DATA AVAILABILITY QUICK REFERENCE
B.1 Available with Subpoena - Node ID - Account creation date - Account status - Subscription tier - Public profile information (self-reported)
B.2 Available with Search Warrant or 2703(d) Order - Public Posts - Public engagement data - IP Hashes (current rotation period only) - Device Fingerprint Hashes - Rate limiting records
B.3 Available Encrypted (Undecryptable by Kemet) - Direct Message payloads - Group message payloads - Social graph data - Private profile settings
B.4 Unavailable (Not Retained or Never Collected) - Raw IP addresses - Real names - Email addresses - Phone numbers - Physical addresses - Precise geolocation - Browsing history - Search queries - Decrypted communications - Deleted content
APPENDIX C: JURISDICTIONAL CONTACT INFORMATION
C.1 United States Federal Authorities
Federal Bureau of Investigation (FBI): [Contact information to be added]
Department of Justice, Office of International Affairs (MLAT): [Contact information to be added]
C.2 State and Local Authorities
[To be populated with relevant state and local contact information as operational needs arise]
C.3 International Authorities
INTERPOL: [Contact information to be added]
[Additional jurisdictions to be added as operational needs arise]
APPENDIX D: GLOSSARY OF TERMS
"Device Fingerprint" - A hashed, salted representation of device characteristics used for abuse prevention.
"E2EE" - End-to-end encryption.
"IP Hash" - A salted, hashed representation of an IP address, rotated every 3-7 days.
"KSMP" - Kemet Secure Messaging Protocol.
"MLAT" - Mutual Legal Assistance Treaty.
"Node" - A user account and cryptographic identity on The Network.
"Node ID" - The unique public key identifier for a Node.
"Public Content" - Content posted with "public" visibility, accessible to all users.
"Trust Score" - An algorithmic reputation metric assigned to each Node.
"Vault Key" - The master cryptographic key from which a user's Identity Key is derived.
"Zero-Knowledge" - An architecture where the service provider cannot access user content or keys.