K-4.7 The Personal Data a Pool Holds

The Field Manual's baseline for privacy is "to collect less, say what you do, do what you say, secure what you keep, and know whether you've entered a regulated sector." Kindling starts further along that road than most software. The profile stays on the owner's page. Photos are never copied. Nothing enters a Pool without a yes. A Pool still holds personal data, and so does a parser, a client or a host.

Spec references are to v0.1.1, as of October 4, 2026. This is not legal advice.

What the spec already does for you

Three sections of the spec are privacy rules in their own right:

• §2.5, photos. "Photos MUST be referenced by URL only. Kindling and Pools MUST NOT store photo bytes." The most sensitive file most profiles carry never reaches your storage.
• §2.7, noindex. "Compliant Pools and crawlers MUST NOT include such a Profile in any Pool, registry, or discovery surface," and "Parsers MUST still record the field when they find the directive, so that a Pool can detect it and refuse the submission."
• §2.3, what was guessed. "Implementations MUST record which fields were h-card-derived and which were inferred." Your records then show which parts of each person's record came from their own markup and which came from your parser.

Build to all three before anything else. They are also the sections a parser's conformance claim rests on (§11.3).

The data map, for a Pool

The Field Manual's privacy program starts with "Data map: what personal data you collect, why, where it lives, which vendors touch it, how long you keep it." K.4 lists what a curator holds. Here it is as a map, with the section that puts each item there.

Figures checked October 2026.

A parser adds extraction_source (§2.3) for every profile it reads. A client that shows Pools adds whatever it logs about the people looking. That last row is where most privacy trouble starts, and the spec says nothing about it.

Decline records and deletion requests: flag, then decide

Two obligations can meet. §5.2 requires that a decline "MUST be recorded as declined for that Pool and MUST NOT be re-submitted by the same Curator without owner permission." A person who declined may later ask you to delete everything you hold about them. Delete the record and you lose the means of honoring their no.

The spec does not resolve this, and the state laws answer it differently. Virginia's says a controller that got personal data "from a source other than the consumer" complies with a deletion request by "retaining a record of the deletion request and the minimum data necessary for the purpose of ensuring the consumer's personal data remains deleted" (Va. Code § 59.1-577). California's right to delete has exceptions, among them "solely internal uses that are reasonably aligned with the expectations of the consumer" (Civil Code § 1798.105(d)(7)), and none of them names a refusal record. Washington's right to delete health data (RCW 19.373.040) lists no exceptions of that kind. Whether a decline record fits a given state's law is a question for counsel in each state you are exposed to. Until you have an answer, keep the smallest record that does the job: the profile URL, the Pool, the date of the decline. Tell the person what you kept and why. Write the procedure down before the first request arrives.

The FTC, which reaches every Pool

The Field Manual: "The FTC's Section 5 authority (Ch 4.6) is the federal privacy law that reaches everyone." Its cases establish that "a privacy policy is a promise, and breaking it is deception." On Kindling, the charter is a promise too. K.4's invented example charter ends with "The list is never sold, shared outside this Pool, or ranked." If your charter says that, your systems must make it true. The Field Manual's further warnings apply to any Pool UI or host: "quietly applying new uses to old data, such as training AI on existing customer data, can be unfair or deceptive," and "sharing health, location or children's data with advertisers without consent draws enforcement."

Sector laws, narrowed to the Kindling library

Children. COPPA applies if a service is "directed to children under 13," or if you have "actual knowledge" you're collecting personal information from a child under 13. None of the library's Pools is directed to children. The invented Midspan's Pool page is marked "Adults only" and says "Everyone here is 18 or older," and the invented Hearthhold "introduces adults." If yours could reach children, read the COPPA section of the full Chapter 4.7, on solo.joshwolf.net, before you open it. Otherwise follow the Field Manual's short rule: "If your product isn't for children, say so in your terms, don't knowingly collect children's data, and delete it when you discover it."

Health. The library includes peer-support Pools. The invented Scattered Light is "a peer network" for "Harrow–Vance syndrome, invented for this example," and its page notes "Names are visible only to members." HIPAA "applies to covered entities (health plans, healthcare clearinghouses, and healthcare providers that bill electronically) and their business associates." A curator keeping a peer Pool for people who chose to be found is not on that list as the Field Manual defines it. The Field Manual also notes that consumer health apps fall under the FTC's Health Breach Notification Rule and state laws such as Washington's My Health My Data Act. Washington's law has no size threshold. It reaches "any legal entity" that does business in Washington or targets consumers there and decides how consumer health data is collected or shared, and small businesses must comply too (RCW 19.373.010, .030). Consumer health data is personal information that "identifies the consumer's past, present, or future physical or mental health status." Collecting it takes consent "for a specified purpose," and sharing it takes a second consent, "separate and distinct" from the first (RCW 19.373.030). Connecticut applies its consumer-health-data rules regardless of size, and to nonprofits (Connecticut Attorney General). The FTC rule is narrower: it covers vendors of a "personal health record," an electronic record on one person that "has the technical capacity to draw information from multiple sources and that is managed, shared, and controlled by or primarily for the individual" (16 CFR 318.2). Whether a place in a Pool for one condition is consumer health data, and whether a given Pool UI falls under any of these, is a question for counsel. Until you know, treat every field in such a Pool as sensitive. Never send it to an advertising pixel. Name it in your charter.

Pixels and session replay, for anyone building a Pool UI. "Session-replay tools and chat widgets have drawn wiretap suits," and "Health-related sites sharing data through ad pixels have faced HHS and FTC action." The Field Manual's instruction is one line: "Audit every third-party script on your site."

GLBA, FERPA and the Video Privacy Protection Act reach none of the library's shapes. They are in the full chapter.

The state patchwork

"Most real obligations live at the state level." About twenty states have comprehensive privacy laws. "Most apply above a threshold, commonly 100,000 residents' data (or 25,000 plus revenue from selling data); California's is revenue-based. Texas and Nebraska have no volume threshold, but exempt SBA-defined small businesses except for requiring consent before selling sensitive data."

A small Pool sits far below the common volume thresholds, but not every law works on volume. Connecticut's, as amended from July 1, 2026, also reaches anyone who controls or processes sensitive data, at any volume; nonprofits are exempt except for consumer health data (Vol 13; Connecticut Attorney General). K.3 says "Nobody sells the list," so the selling triggers do not apply. That leaves four things to check against Volume 13 for each state your people are in: California's revenue test, the Texas and Nebraska rules, sensitive-data triggers like Connecticut's, and the definitions of sensitive data. The Field Manual names "health, precise location, biometrics, children's data" as examples. Several definitions also reach what profile pages say about people. Virginia's covers personal data "revealing racial or ethnic origin, religious beliefs, mental or physical health diagnosis, sexual orientation" (Va. Code § 59.1-575). Colorado's and Connecticut's name the same kinds. California's "sensitive personal information" includes "religious or philosophical beliefs" and information "concerning a consumer's health" or "sex life or sexual orientation" (Civil Code § 1798.140(ae)).

Abroad. Pools are often open to anyone online. The Field Manual's test for GDPR is whether you "offer goods or services to people in the EU" or "monitor their behavior"; "a website EU visitors can merely reach doesn't trigger it." Chapter 11.6 on solo.joshwolf.net covers the rest.

AI over Pools

The reference tools include a discovery agent that asks Pools questions in plain language. Two rules bind any agent you build. It reads only people who said yes: §5.1 holds for every entry it sees. And if it calls a model vendor, Pool content leaves your systems. Keep the Field Manual's AI register: "which models see customer data, whether they train on it, and what you've told customers."

The Field Manual lists chatbot-disclosure laws in several states. It also notes the EU AI Act's transparency duties from August 2, 2026, which include telling people when they are dealing with AI. An agent that answers questions about the people in a Pool should say it is an agent, every time.

A privacy program sized for one curator

The Field Manual's eight steps, applied:

1. Data map: the table above, filled in for your Pool.
2. Privacy policy that agrees with the map and with your charter.
3. Vendor agreements with your email and hosting providers.
4. Retention schedule, with the decline-record decision written in.
5. Security basics, in Chapter K-8.5.
6. Rights-request process: your curator_contact address and a checklist.
7. One-page incident plan: who to call (Chapter K-4.8), and which state breach-notification deadlines apply ("all 50 states have them").
8. AI register, if any model sees Pool data.

Field exercises

1. Fill in the data map for one invented Pool. Done when every row has a location, a reason by section and a retention decision.
2. Write the procedure for a deletion request that meets a decline record. Done when it says what you keep, what you delete, what you tell the person, and which question you have put to counsel.
3. Test your parser against an invented profile page that carries the noindex directive and a photo. Done when the submission is refused, the directive is recorded, and no photo bytes exist anywhere in your storage.
4. Audit every third-party script on your Pool UI. Done when each one is listed with what it receives, and none receives anything from a peer-support Pool.
5. List the states your Pool's people are in and read each one's privacy entry in Volume 13. Done when each state has a yes or no for whether its law reaches you, with the threshold that decided it.

---

Rewritten for the Kindling edition from Chapter 4.7 of The Solo Operator's Field Manual. The full chapter is on solo.joshwolf.net. © 2026 Josh Wolf, licensed under CC BY 4.0. Quotations from the Kindling Protocol Specification v0.1.1: © 2026 TranquilTech and Kindling spec contributors, CC BY 4.0, marked where shortened.