For curators · Article I, with K.4 · Rewritten from Field Manual Ch 4.3
K-4.3 Contracts Around a Pool
Spec v0.1.1 · StableExamples invented and labeled
"A contract is an agreement a court will enforce." The Field Manual's line holds on Kindling. What changes is which promises are contracts. K.4 draws the line: "What you promise is the charter. It is not a contract. If you run Pools for an organization, the arrangement between you and the organization is one." A Kindling reader signs three kinds of contract: an arrangement to keep Pools for an organization, the terms for something sold beside a Pool, and an agreement with whoever writes code for a client. One thing no contract can stand in for comes first. Spec references are to v0.1.1, as of October 4, 2026. This is not legal advice.
Consent is never a contract term
The Field Manual teaches clickwrap: courts "consistently enforce" terms the person agrees to with a box or a button, so it tells you to "Put the agreement at signup and at checkout," and to record which version each person accepted, and when. Use that for whatever you sell. Never use it for a Pool.
Inclusion in a Pool has its own record, and the spec fixes it. "A Profile MUST NOT be added to a Pool without the owner's explicit consent. Silent inclusion is forbidden. There is no exception." (§5.1) Each entry "MUST contain" a consent_proof: a "reference to the handshake response authorizing inclusion" (§3.4). The response is recorded only on the handshake's confirmation step: "Only an explicit action on that step, such as a button that sends a POST request, records a decision." (§5.2) A clause in your terms that says joining your gym, buying a ticket or signing up for hosting adds someone to a Pool would add them without a handshake. Leave it out of every document you write.
Keeping Pools for an organization
The Field Manual's two-layer structure fits this arrangement. The master agreement holds the terms that stay the same: payment, confidentiality, liability limits, termination, disputes. The statement of work names one engagement, written so "a stranger" could check it:
- The Pools, by manifest URL, and where each manifest lives. A Pool "MUST be retrievable as a JSON document, either from a public Git repository or from a Pool API endpoint that returns the same shape" (§3.1).
- The work, in the spec's own terms. §9.1 lists the curation actions: "handshake review, manifest edit, removal response." Say which you do, how often, and who answers the address in
curator_contact, which the schema describes as "How a profile owner can reach the curator about removal, complaints, disputes." - What is out of scope, "the one sentence that prevents the most disputes." On Kindling it always includes adding anyone without a yes (§5.1), and any request to rank, boost or hide people for payment (K.3).
- Payment on dates or milestones. Chapter K-5.3 covers the terms.
The ending clause
Write the ending clause before anything else, because the Pool outlives the arrangement by design. If nobody acts for 90 days, "the Pool MUST enter dormant status. Pool members MUST see a notice." (§9.1) A transition follows, and "Co-curators listed in the manifest are first in line" (§9.3). If none succeeds, "the Pool MUST archive," and "Archived Pools remain readable" (§9.4).
So the contract decides what the spec leaves to the people involved:
| Question | What the spec settles | What the contract must say |
|---|---|---|
| Who curates next | Co-curators in the manifest are "first in line" (§9.3) | Name a co-curator from the organization in the manifest on day one |
| Where the consent proofs go | Each entry holds a consent_proof, a "reference to the handshake response" (§3.4). The reference moves with the manifest; the spec does not say where the response itself is kept |
Who holds the manifest's repository or endpoint, and the handshake responses the references point to, after the handover |
| Where the decline records go | A decline "MUST be recorded as declined for that Pool" (§5.2); the spec does not say where | Where the records live, in what form, and that they move with the Pool |
| Who answers owners in the meantime | Withdrawal "within 60 seconds of receipt" applies throughout (§5.3) | Who answers curator_contact from the notice date until the handover is done |
| What the organization keeps | Nothing about the people in the Pool belongs to either party; each entry exists because someone said yes | The manifest, its history, the decline records and the notes, handed over on a date |
Figures checked October 2026.
Key clauses
The Field Manual's table, cut to the clauses an arrangement like this needs:
| Clause | What it does | What to watch |
|---|---|---|
| Limitation of liability | Caps what either side can recover, often at fees paid in the prior 12 months, and excludes indirect or consequential damages | Make it mutual. Check what's carved out of the cap (commonly confidentiality, indemnity, data breach). Uncapped carve-outs can exceed your insurance. |
| Indemnification | One side pays the other's losses from third-party claims caused by specified events | Limit yours to what you control. Refuse to indemnify for the client's own negligence or their data. |
| Confidentiality | Protects shared information | Mutual; standard exclusions; survives termination. The data a Pool holds is covered in Chapter K-4.7. |
| Term and termination | How the contract ends | Termination for convenience with notice; payment for work done through termination; what survives. Add the handover above. |
| Governing law, disputes | Which state's law; court or arbitration | Your home state. A mediation step first is cheap; arbitration can be costly for small claims. |
Figures checked October 2026.
An invented redline email, for illustration only, for when an organization sends its own paper:
Thanks, this mostly works. Three changes: (1) make the liability cap and indemnity mutual, with the cap at fees paid in the prior 12 months; (2) clause 7 says the organization owns "the member list." The people in these Pools are in them because each said yes, and each can leave within a minute, so neither of us owns them. I've replaced it with a handover clause naming the manifest, the decline records and a co-curator; (3) payment is Net 30 from invoice. Redline attached.
Terms for what you sell beside a Pool
K.4: "If you charge for something beside the Pool (Chapter K.3), Ch 4.3's terms-of-service section applies to that thing." That means memberships, day passes, tickets, classes, hosting plans and a shared desk. Use clickwrap at checkout, record the version, and cover payment and renewal, warranty disclaimers, liability limits and how you announce changes. Chapter K-3.6 covers the renewal rules for memberships.
Two Kindling lines belong in those terms. Payment is never a condition of being listed or introduced (K.3's third question). And leaving the thing you sell changes nothing about anyone's place in a Pool.
The privacy policy has to agree with what you actually do: "A privacy policy that says 'we never share data' while your analytics vendor collects it is a deceptive practice under the FTC Act." Chapter K-4.7 maps what a Pool holds.
A service sold after an introduction, and only on request (Hearthhold's shape in K.3), is a project. Write each one as its own statement of work, with deliverables, price and an end.
Contractor agreements, for builders
"You pay a freelancer to build your app. You never sign an assignment. The freelancer may own the copyright in the code." That holds for a Kindling client as for anything else: "paying for the code does not buy the code." The Field Manual's list for every contractor agreement stands:
- Present assignment of IP. "Contractor hereby assigns" (present tense). "Agrees to assign" is only a promise and needs a second document.
- Work-made-for-hire language as belt-and-suspenders, with the assignment as the backup.
- Prior inventions carve-out, with a license to whatever is embedded in your deliverable.
- Confidentiality with the DTSA notice.
- Independent contractor status language, which documents intent but does not control classification.
- Open-source disclosure. A Kindling client may build on the reference tools, which are under Apache 2.0. The contractor tells you what they included and under what license. K.2 sets out what Apache 2.0 then asks of you, including that "You may build a closed client."
- AI tool disclosure. Whether they used generative AI to produce deliverables.
Electronic signatures
"The federal ESIGN Act (2000) and the Uniform Electronic Transactions Act, adopted in nearly every state, make electronic signatures and records legally valid for most commercial contracts." Save the completed PDF and the certificate. An e-signature on your arrangement with an organization is a contract signature. It is never a handshake response.
Founder agreements, operating agreements and NDAs are in the full Chapter 4.3, on solo.joshwolf.net.
Field exercises
- Draft the clause list for keeping one invented Pool for an invented organization, with the ending clause written first. Done when it names the manifest URL, the co-curator, where the decline records live, and what the organization holds after the handover date.
- Read your own signup and checkout flows. Done when no checkbox, clause or pre-set option adds anyone to a Pool, and the terms you sell under are stored with the version each buyer accepted.
- Audit IP ownership of your client's code. Done when every person who wrote any of it has a signed present-tense assignment, and you have a list of the open-source code included and its licenses.
- Write your redline email for an organization's paper. Done when it covers the liability cap, the handover and payment terms in under 120 words.
Rewritten for the Kindling edition from Chapter 4.3 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.