Law-Enforcement Request Policy

DRAFT — counsel sign-off required before public launch. ⚠️ This document must be reviewed by a qualified lawyer before it is published. The description of what LCS holds is engineering-verified against the live schema; the legal sufficiency of the commitments below is not yet.

Version: 2026-08-31.1 Effective: 2026-08-31 (draft)

This policy explains how Little Collie Shepherd ("LCS", "we") handles requests from law enforcement, regulators, and other authorities for data held in the Service.

We publish it for a simple reason: a process written down before a request arrives is a process that treats everyone the same. One written after the first request arrives is a process shaped by that request.

1. Our position, stated plainly

LCS is a comment-moderation tool. It exists so a creator can keep a comment section usable. It does not surveil, report, or build cases, and it is not designed to. Where a legal duty to preserve or report attaches, we comply with that duty and nothing beyond it.

That is a boundary, not resistance. We are not promising to fight lawful process on your behalf, and you should not read this policy as saying we will. We are promising that we will not volunteer, that we will not read a request more broadly than it is written, and that we will tell you when we are permitted to.

2. What we require

Valid legal process, appropriate to what is being asked for. We do not act on an informal request — an email, a phone call, a letter on headed paper asking us to "look into" an account or a commenter. If you are an authority and you need data, you need process a court or a competent authority has issued.

We check that a request is genuine before we act on it, using contact details we establish independently rather than the ones on the request itself.

We produce the minimum responsive to the request and nothing more. If a request covers one commenter, we do not produce the workspace. If it covers a date range, we do not produce what falls outside it. Where a request is broader than the law permits, or so broad we cannot tell what it covers, we say so and ask for it to be narrowed.

Emergencies. Where a request asserts a risk of death or serious physical injury, we may disclose what is necessary to address that specific risk without waiting for process. We treat this as a narrow exception, we record every use of it, and we notify the affected customer afterwards on the same terms as everything else.

3. We will tell the affected customer

Where we are legally permitted to, we notify the customer whose workspace a request concerns, before we produce anything, and with enough time for them to respond.

Sometimes we will not be permitted to. In practice that means:

a court order or statute prohibits us from disclosing the request (a "gag" order);
the request is sealed;
an emergency of the kind in §2 makes prior notice impracticable.

Where notice is prohibited, we do not simply stay silent forever: we ask for the prohibition to be time-limited where we can, and we notify the customer once it lapses.

If the request concerns a commenter rather than a customer, the customer is still the person we notify — they are the controller of that data, and it is their decision how to respond to their own user.

4. What we actually hold

Written from the schema, not in the abstract, because a policy that overstates or understates the data is worse than none.

Most of what LCS holds is about people who never signed up for it — commenters on a customer's connected YouTube channel or WordPress site. If a request concerns a person, it is far more likely to concern a commenter than a customer.

About a commenter, we hold:

The comment text they wrote, and a normalised form of it used for matching.
Their display name and the platform-issued identifier their platform assigns them (a YouTube channel id; for WordPress, a hashed form of their email address).
For WordPress comments only: the author's email address, stored encrypted, and their website URL. Their IP address is truncated to a /24 network at the moment it arrives — we never store a full IP address for a commenter.
The moderation record: what LCS or a moderator decided, when, under which rule, and a short reason for it.
Any entry the customer has made about them on their own allow, watch, or deny list, including any note the customer wrote.
Counts of how many comments they have left and how many were removed.

About a customer, we hold: account and workspace details, the email addresses and password hashes or passkeys of the people who log in, billing records held by our payment processor, sign-in and audit logs, and the credentials that connect their platform accounts — which are encrypted and are not readable by us in ordinary operation.

What we do not hold, and cannot produce:

Any of it indefinitely. Records about commenters are automatically redacted after a defined period — see Privacy Policy §4. Once redacted, the content and the person's name are gone and cannot be recovered from LCS. We cannot produce what has aged out, and we do not retain data because a request might one day arrive.

One exception, and it is likely to be the relevant one. Comments assessed as credible threats are kept for 6 years from the moderation decision, so that someone who was targeted still has the evidence if they need it. If your request concerns a threat, the content may well still be here when everything around it has gone. - Any record at our AI provider linking a comment to the person who wrote it. During automated moderation, comment text is sent to a third-party model provider (Anthropic PBC, United States) to be classified — see Privacy Policy §6. What is sent carries no commenter identity: no name, no channel or user id, no email address, no IP address. Our software refuses to send a request containing any of those fields. So a third-party transcript of the comment text may exist, but nothing at the provider connects it to a person, and the provider cannot answer "who wrote this" — only we can, from the records described above, and only for as long as we hold them. - Full IP addresses for commenters, browsing history, location data, device fingerprints, or any advertising or tracking profile. LCS builds none of these.

If you are considering a request, please read this section first. It will often show that what you are looking for is not held here.

5. Preservation

We will honour a valid preservation request for a defined scope and a defined period, which suspends the automatic redaction described above for the data it covers. A preservation request is not a disclosure request: preserving data does not produce it, and we still require process before anything is produced.

6. Transparency reporting

Not yet, and here is when. We are not publishing request counts today, and the reason is arithmetic rather than reluctance: with a very small number of customers, a count is close to naming them. "One request this quarter" is a different disclosure when there are five customers than when there are five thousand.

Our commitment: we will begin publishing an annual transparency report — request counts by type and jurisdiction, and how many were refused or narrowed — from the first full year in which we serve more than 100 customers. Until then, any customer may ask us whether their own workspace has ever been the subject of a request, and we will answer honestly where we are legally permitted to.

7. Where to send a request

Requests must be in writing and sent to:

legal@littlecollie.com

(Registered entity name and address for service to be inserted before launch, alongside the entity details owed in the Privacy Policy.)

Please include the legal authority you are relying on, the specific data sought, the time period, and a contact we can verify you by independently. We acknowledge receipt; we do not commit to a response time, because the right answer depends on what is asked.

8. Related documents

This policy explains our process. It is not legal advice to anyone, and it does not create rights beyond those the law already provides.