elch.liveeDiscovery production preflight

Data Processing

Last updated: 16 August 2026

Why this page exists

elch is used on material that is often confidential, commercially sensitive, or privileged. This page states precisely what happens to that material, so a firm's information security review can be answered from a document rather than an assurance.

1. The processing boundary

What runs locally

• Reading the selected folder or ZIP
• SHA-256 hashing and package fingerprinting
• Parsing DAT, OPT, LFP, and DII load files
• Reference resolution across the package
• Image structure inspection and frame counting
• Repair, re-scan, conversion, and export
• Report and manifest generation

What is sent to our servers

• An authenticated request asking whether your subscription is active
• Requests to begin a checkout or open the billing portal

These carry your account identifier only. They contain no filenames, no paths, no field values, no hashes, and no file content.

2. Roles

Data	Our role	Basis
Production evidence	None — never received	Not applicable
Account data (email, identifiers)	Controller	Contract
Billing data	Controller; Paddle is an independent controller as merchant of record	Contract, legal obligation
Server logs	Controller	Legitimate interests (security)

3. Sub-processors

Provider	Purpose	Receives evidence?
Clerk	Authentication and account records	No
Paddle.com Market Ltd	Payments, invoicing, tax	No
Vercel	Hosting, delivery, server logs	No

We will update this page before adding a sub-processor that changes this picture.

4. Security measures

• All traffic served over HTTPS.
• A strict Content Security Policy restricting where the page may load code from or connect to.
• Billing endpoints authenticated, rate-limited, and marked no-store.
• Bounded archive extraction with CRC checking, path-traversal protection, compression-ratio limits, and collision detection.
• Originals are never modified; a repaired production is written as a separate copy.
• Every repair is anchored to the SHA-256 of its source file and recorded in a manifest.

5. Integrity and auditability

Each repaired export includes a JSON manifest recording the source and output hash of every file, every operation applied, and an operation identifier recomputable from its inputs. An independent verifier can re-check that manifest without trusting the interface that produced it. This is intended to support a defensible record of what changed between the source package and the delivered one.

6. Honest limitations

These are stated so that a security review is not misled:

• Signed-in pages execute authentication code supplied by Clerk. Treat your browser and Clerk as part of the trust boundary for local processing.
• Because processing is local, we cannot recover your work if you close the tab or lose the device.
• Because we never receive evidence, we cannot assist by inspecting it, and we cannot produce it in response to any legal request.
• "Verified" means zero blocking findings under elch's supported rules. It is not a legal conclusion and not a guarantee of acceptance by a destination platform.
• Image checks read structure and do not decompress every page, so they cannot confirm visual legibility.

7. Data subject requests

For access, correction, deletion, portability, or restriction of your personal data, email privacy@elch.live. Requests concerning evidence you processed cannot be actioned by us, because that material was never in our possession.

8. Retention

• Evidence: never retained.
• Account data: deleted within 30 days of account closure.
• Billing and tax records: retained as required by law.

9. Incident notification

If a personal data breach affecting your account data occurs, we will notify you and any relevant supervisory authority within the timeframes the applicable law requires. A breach of our systems cannot expose your production evidence, because it is not held there.

10. Contact

Data protection enquiries: privacy@elch.live. Security reports: security@elch.live.