# Recipient Contract Protocol — FULL RESEARCH CORPUS Abbreviation: rcp Version: v0.1.0 | Generated: unspecified | Files: 3 | Lines: 559 | Payload: 22.9 KiB Source path: /Users/zachshallbetter/Projects/_protocols/recipient-contract-protocol Bundle name: llm-full-docs-rcp Corpus Payload SHA-256: 67c336606ea587f1d9517083a298e4f93b44ca407f4f11768c0b55df1c7f315a TABLE OF CONTENTS: - EDP.md (156 lines, 5.8 KiB) - RCP.md (196 lines, 7.6 KiB) - README.md (207 lines, 9.5 KiB) ======================================================================== ======================================================================== ## FILE: EDP.md (156 lines, 5.8 KiB) ======================================================================== # EDP — Engagement Dependency Protocol **v0.1.0 · draft · 2026-08-25 · Zach Shallbetter** A record of what an engagement has received and what it has given, and a trigger that puts the pair in front of the author before more is delivered. Companion to `RCP.md` (which asks whether work terminates) and `record.json` (which asks whether claims are supported). This one asks a question neither can: **what is my position.** --- ## 1. What it measures, and what it refuses to The subject is not a proposition. Every other instrument in this system takes a claim and asks whether the world backs it; the author's own position is a state, so it never reaches a gate and never fails one. That is the gap this closes. **Not hourly.** Hours price time, and time is not what was given. **Not market rate.** The same number in a suit. **Not equity percentage.** Unpriceable where the counterparty's own audit says the platform does not run. **Operational dependency.** What stops if the author leaves. It is the only quantity that tracks the thing that actually moved — work that is hard to claw back, that raises the author's switching cost and the counterparty's leverage. --- ## 2. The artifact record One entry per delivered artifact. Four booleans, all mechanically derivable. ```json { "artifact": "", "in_their_production": true, "sole_operator": true, "infrastructure": "ours | theirs | shared", "covered_by_instrument": false } ``` - `in_their_production` — running and depended on, not merely committed. - `sole_operator` — no one else has committed to it, or no one else can run it. Derive the floor from `git shortlog -sn`; a repo with one author proves the negative cheaply. - `infrastructure` — whose account holds it. Per artifact, not in aggregate. - `covered_by_instrument` — is there a signed document that names this work. `in_their_production && sole_operator` is the pair that matters. The other two state exposure rather than leverage. --- ## 3. The engagement record ```json { "engagement": "", "counterparty": "", "instrument": null, "terms_raised": ["2026-08-03"], "terms_deferred": ["2026-08-03", "2026-08-10"], "consideration_received": null, "first_delivery": "" } ``` `terms_deferred` is the load-bearing field and the expensive one. A deferral does not arrive labeled. It arrives as *sure, after the 12th*, from someone the author likes, about work the author wants to do. Logging it costs one honest keystroke made against the author's own optimism, which is the most expensive kind of keystroke there is. The counter is free; the logging is the whole dependency. **Record the event before knowing whether it was a stall or a sequencing.** That judgment is what the trigger is for. Making it at write time defeats the record. --- ## 4. Derived Two lines, both computed, neither editable. > **Their dependency:** N artifacts in their production with no other operator, > M of them uncovered by any instrument. > > **Your exposure:** K artifacts on infrastructure they control; consideration > received to date; days since first delivery. Both directions, always. An instrument that computes only the first half is a comfort object. Computed together, the pair reads as drift in a direction. --- ## 5. The trigger **`terms_deferred.length >= 2` → the pair goes in front of you, and continuing requires an explicit yes.** The output is a forced look, not a forced exit. A rule that stops automatically has relocated the passivity rather than removed it — from continuing-by-default to stopping-by-default — and the tell is that you would argue with it. You do not argue with instruments; you read them. Exit is one available response, next to: get it in writing, narrow the scope, attach a dated consequence, continue deliberately. --- ## 6. What this does not claim - **That the counterparty acted badly.** The record contains no such field. Three deferrals from three people are a fact about the author's instrumentation before they are a fact about anyone's character. - **That the number is what the author is owed.** Operational dependency is a position, not a valuation. What is owed is a separate question with separate evidence. - **That merged-PR volume measures value.** It counts effort. Kept only as a tripwire, because the sentence *N merged PRs against an unsigned instrument* is one that would have read as absurd in week two and did not exist to be read. It must not drift into a denominator. - **That the pattern is architectural.** See §7. --- ## 7. The generalization is unproven The claim that this is a structural gap rather than one extractive arrangement rests on three engagements, two of them recalled rather than measured. One counterparty deferring is a fact about them. Three independent counterparties producing the same imbalance is a fact about the missing instrument. **Required before the architectural reading is adopted:** run the §3 event definition retrospectively across all three. If it holds three times, the self-instrument is the correct fix. If it holds only once, the honest conclusion is that one arrangement was extractive — and that wants an exit, not a counter. Those purchases are different and the author should know which one is being made. --- ## 8. Status of the central claim The instrument buys exactly one thing: it converts a default into a decision. You could see `deferrals: 2` and continue for reasons that are all true — the work is yours, the platform is yours, the income is real — and none of that would be wrong. The instrument does not make continuing wrong. It makes it yours. It does not reduce the cost of noticing late. It moves the noticing to the front, where the work in between has not happened yet, which is the only place the number is worth anything. Zero conformance history. No engagement has yet been recorded under it. ======================================================================== ## FILE: RCP.md (196 lines, 7.6 KiB) ======================================================================== # RCP — Recipient Contract Protocol **v0.1.0 · draft · 2026-08-25 · Zach Shallbetter** A required record binding every project to a named person and a stated obligation, and a derived status that cannot report progress in that record's absence. Companion instruments: claim lanes (what backs a sentence), `/claims.json` (what backs an assertion), `/measurements.json` (what a number may not mean), `/projections.json` (what a projection alters). Those twelve govern whether a claim is supported. This one governs whether work terminates. --- ## 1. The problem it addresses Every existing instrument in this system answers a version of *is this claim backed*. None answers *against what does this end*. The gap is not incidental; it is the shape the failure takes when the completion signal is internal. The evidence is a count and a contrast. Roughly two hundred fifty directories resolve into a handful of problems re-attempted at rising rigor — each pass better instrumented, none finished in the sense the market means. Against that: four projects built for one person who could be named, all four terminated, none re-entered at higher rigor. The distinguishing property is not payment, difficulty, or domain. It is that the recipient was specific. Stated as a specification problem rather than a discipline problem: an abstraction cannot signal completion; a person can. --- ## 2. What this protocol does not claim The falsification lines, kept deliberately. None of the following is asserted: - **That a named recipient makes the work valuable.** A recipient is a termination condition, not a validation of merit. - **That a project without a recipient is waste.** Primitives compound; several runtimes in current use began as unrecipiented attempts. The record types such work, it does not condemn it. - **That the recipient is a customer.** Payment is a separate field and a separate question. The operative property is specificity, not money. - **That conformance causes completion.** The protocol makes an absence visible and blocks a status. It does not perform the work. - **That this generalizes.** Derived from one portfolio, one owner, one observed recipient. See §8. --- ## 3. Definitions **Recipient** — a single natural person, identified by name, reachable by the owner without an introduction, who has stated or demonstrated need for the deliverable. A recipient is not a role, an organization, a segment, an ICP, a persona, a hypothetical buyer, or a future user. **Obligation** — the deliverable owed to the recipient, and the date it is owed by. Both are required; a deliverable without a date is a wish. **Self-recipiency** — the owner naming himself. Prohibited (§5). The mechanism under test is externality; a recipient who cannot be disappointed supplies no signal. **Primitive** — the derived type of any project holding no valid recipient record. A state, not a fault. --- ## 4. The record Every project carries exactly one `recipient` record. ```json { "project": "", "recipient": { "name": "", "relation": "", "need": "", "obligation": { "deliverable": "", "due": "" }, "stated_on": "" } } ``` `recipient: null` is valid and expected. It is the honest value for most of the portfolio and carries no penalty beyond §6. `need` MUST be written in the recipient's framing. "She is studying for the CAPM and failing the practice tests" conforms. "Exam-prep market underserved by existing tools" does not, and is the exact substitution this protocol exists to catch. --- ## 5. Conformance 1. A project MUST hold a `recipient` record, valued or null. 2. A `recipient.name` MUST identify one natural person. Plural, collective, and role-based values are non-conforming. 3. The owner MUST NOT appear as recipient. 4. An `obligation` MUST carry both a deliverable and a date. 5. A recipient record MUST NOT be created retroactively to justify existing work. `stated_on` is the recipient's date, not the record's. 6. A lapsed recipient MUST be retained, not deleted — status moves to `lapsed`, the record stays. Consistent with permanent retention of negative results: the abandoned recipient is the one most likely to be re-proposed. --- ## 6. Derived status Status is computed from the record, never assigned. | Recipient record | Permitted status | |---|---| | Valid, obligation open | `active` | | Valid, obligation met | `delivered` | | Present, obligation expired unmet | `lapsed` | | Null | `primitive` — and only `primitive` | **The load-bearing rule:** `active` is unreachable without a valid recipient. A project whose recipient is a hypothesis cannot be described as in progress — to itself, on the site, or in a status report. This fails closed without the owner's judgment in the loop, which is the property that makes it an instrument rather than a resolution. --- ## 7. Engagement profile The same record applied to work performed for others. Fields: named counterparty, specified obligation, date, and the instrument it is written in. **Rule:** no written instrument, no work. Not reduced scope, not provisional delivery, not work continued while terms are "coming this week." The case evidence supporting this profile is three engagements in which terms were discussed and never written, and in which the absence was visible early — in one instance the request was raised on a specific date and deferred twice while delivery continued. That evidence is retained privately (`READ.md`); it is not published here, and the counterparties are not named. The engagement profile is the half of this protocol with a known failure history and no conformance history at all. --- ## 8. Instrumentation `/recipients.json` publishes, per project: the derived status, whether a recipient exists, and — for conforming projects — the obligation date. Recipient names, relations, and needs are private and MUST NOT be published; the count is public, the person is not. Consistent with *prove it, keep nothing*. The site MUST publish the aggregate: > *N projects have a named recipient. M do not.* On a portfolio of this size that ratio is the most unflattering fact available and the strongest line on the page, per the one-unflattering-fact-per-section rule. Publishing it is the point; a private count is an intention. --- ## 9. Status of the central claim Graded by the same standard the site applies to itself. The claim — *naming a specific recipient causes work to terminate* — is **undemonstrated**. Its support is four projects and one recipient, observed retrospectively, with no control for difficulty, scope, or novelty. Those four were also the smallest and least architecturally ambitious work in the portfolio, and that confound is not addressed. What is established is a correlation on n=1 and a plausible mechanism; what is not established is causation, generality, or effect size. The protocol is adopted on that basis and should be described that way. It has zero conformance history at the time of writing. **First falsification available:** if the ratio published under §8 does not move within ninety days, the constraint was never binding and this document is decoration — which is itself the finding, and is retained under §5.6. --- *Evidence: `READ.md` (2026-08-18, three passes; rebuilt definition 2026-08-25); `CONTENT.md` Appendix B; `/methodology`; the portfolio directory count verified 2026-08-18. Shipped-for-a-named-person set: Ascent (App Store, ascent.guide), CanDo, CAPMPrep, Draft Smarter.* ======================================================================== ## FILE: README.md (207 lines, 9.5 KiB) ======================================================================== # RCP — README Companion to `RCP.md` (v0.1.0). The spec states the rule; this states what it is for, what it buys beyond the obvious, how to adopt it, and where it fails. --- ## What it is, plainly One required field on every project: a named person and what they are owed, by when. If that field is empty the project is typed `primitive` and cannot be called active — not on the site, not in a status report, not privately. That is the entire mechanism. It is small on purpose. An instrument that needs enforcing is not an instrument. --- ## Why it exists Twelve instruments are already in force across the repos and the site: claim lanes, `/claims.json`, `/measurements.json`, `/projections.json`, `/methodology`, permanently retained negative results, gates proven still capable of failing, the no-inflation posture, the stranger test, the state-what-you-do rule, prove-it-keep-nothing, and evidence-required-for-done. Every one of them answers the same question in a different register: **is this claim backed?** That is a complete apparatus against overstatement, and it is why the work is trustworthy. None of them answers: **against what does this end?** The result is legible in the directory count. Roughly two hundred fifty directories resolve into a handful of problems re-attempted at rising rigor, each pass better instrumented than the last. Against that, four projects built for one person who could be named — Ascent, CanDo, CAPMPrep, Draft Smarter — all four terminated, none re-entered. The difference was not difficulty, funding, or domain. It was that someone specific would notice if the thing never arrived. --- ## What it buys beyond finishing The termination effect is the stated purpose. Five other things fall out of it, and two of them are worth more. **A non-arbitrary sort of the portfolio.** Two hundred fifty directories have never had an ordering that wasn't recency or interest. Run the field once and they partition themselves: obligations on one side, primitives on the other. That is the first sort key that isn't taste. **Copy the site cannot currently write.** `CONTENT.md` asks the Experiments section for spans and outcomes — "5, none shipped" earns more than any adjective. RCP produces that data as a byproduct. The instrument feeds the page. **A test of whether business development is doing anything.** The design-partner conclusion in `READ.md` was one named person at one company, not fifteen to twenty-five conversations optimized for market size. RCP makes that checkable: a conversation either produces a recipient record or it does not. Fifteen conversations and zero records is not a pipeline, and the instrument says so without anyone having to be honest in the moment. **A first-week test of a counterparty.** Under the engagement profile the first artifact of any new working relationship is a written obligation. Someone who will not name a deliverable and a date is telling you something in week one rather than week five. The protocol protects you and screens them in the same move, and it costs nothing to apply — asking for it is normal, and the reaction is the data. **A reason to say no that isn't willpower.** Right now a new idea competes on interest and interest always wins. Under RCP a new unrecipiented project enters explicitly as `primitive`, which makes starting it a declared choice rather than a drift. The decision still gets made; it stops getting made invisibly. --- ## Adoption — one sitting Do not retrofit recipients. Rule 5.5 exists because a record created to justify existing work is a lie with a date on it. 1. **Sweep.** For each project, ask one question: *is there a specific person who would notice if this never arrived?* Not "would benefit." Notice. 2. **Record or null.** Most will be null. That is the expected result and the honest one. 3. **Count.** Produce `N have a named recipient · M do not`. 4. **Publish the count** (§8). Names stay private; the ratio goes on the site. 5. **Do not act on it yet.** The first pass is measurement. Changing behavior in the same sitting contaminates the baseline you will grade the ninety days against. Budget an afternoon. The sweep is fast because the honest answer is usually immediate — hesitating about whether someone counts is itself a null. --- ## Day to day **New project intake.** Name the recipient before the repository. If you cannot, create it as `primitive` deliberately and move on. This is not a prohibition; it is a label applied at the moment it is cheapest. **Weekly review.** Read only the `active` set. Everything else is out of scope by definition, which is the point — the review stops being a walk past 250 open tabs. **Monthly.** Check `lapsed`. An obligation that expired unmet is the most useful record in the system, and it is the only instrument you have that points outward at behavior rather than inward at claims. **Engagement intake.** Named counterparty, deliverable, date, written instrument. No instrument, no work. At minimum the instrument names: who the parties are, what is delivered, by when, what it pays or grants, who owns what is produced, who holds decision authority over technical production, and how it ends. Seven lines. An email that states them and is replied to affirmatively is an instrument; a huddle is not. **Writing.** Same field. A draft with a named recipient is finishable; a draft addressed to an audience is a primitive with prose in it. This is the reason the backlog is a hundred and forty two and not zero — the published ones found their readers afterward, which is discovery, not termination. The usable move is not a publishing cadence. It is picking one draft, naming the person who needs it, and finishing that one. --- ## Edge cases, answered **Specifications nobody asked for.** ICP, FCI, SES, IEPE all type as `primitive`. That is correct and it should be uncomfortable. The site already says the quiet part — *four of these are specifications for problems most people solve with convention; none of them were requested* — and calls it either the most valuable habit here or the most expensive one. RCP does not resolve that question. It stops the answer from being assumed. **Infrastructure other projects depend on.** Fundamental Engine types `primitive`: four dependents, all of them yours. A dependency is not a recipient, and self-recipiency is prohibited. The honest reading is that it is excellent unrecipiented work, which is exactly what the type says. **A recipient who is also a customer.** Fine. Payment is a separate field and a separate question. Specificity is the operative property; money is a confirmation of it, not a substitute. **Two recipients.** Pick one. A protocol that permits plural recipients permits segments, and segments are the failure this exists to catch. **The recipient goes quiet.** Status becomes `lapsed` at the obligation date, not before, and the record is retained. Do not delete and do not extend silently — an extension is a new obligation with a new date and the recipient's acknowledgement. **You genuinely want to build something for nobody.** Build it. Type it `primitive` and enjoy it. The protocol has no penalty for primitives and the runtimes prove they compound. What it forbids is calling that work active. --- ## What it costs, and how it fails **It will type most of your best work as primitive.** The engine, the protocols, the research program, most of the two hundred fifty. If that reading is intolerable the rule gets weakened, and a weakened rule is decoration. The protocol only survives if `primitive` is genuinely neutral to you — and that is a claim about your temperament that no instrument can enforce. **It is trivially gameable.** Name someone who would politely say yes and every project conforms by Friday. The only defenses are structural and thin: `stated_on` is the recipient's date, and `need` must be in their words. Both are honor-system. This is the weakest joint in the design. **It can become a guilt engine.** If the published ratio starts reading as an indictment rather than a measurement, the instrument has inverted into the thing it was built to prevent — a mechanism that points inward and produces feeling instead of information. The countermeasure is §8's framing: it is a count, and counts do not accuse. **The central claim is undemonstrated.** Four projects, one recipient, observed retrospectively — and those four were also the smallest and least architecturally ambitious work in the portfolio. That confound is unaddressed. Correlation on n=1 with a plausible mechanism, adopted on that basis, graded accordingly in `RCP.md` §9. **Falsification.** If the ratio has not moved in ninety days the constraint was never binding and this is decoration. That result is retained, not deleted. --- ## Relation to the other instruments The twelve are inward-facing and claim-shaped. They ask whether a sentence is supported. RCP is outward-facing and obligation-shaped: it asks whether anyone is waiting. It is also the first instrument in the set with a subject who is not you. Every other one can be satisfied alone, at a desk, honestly. This one requires a second person to exist and to have said something. That is the property that makes it work and the reason it took twenty years to write down — a formalist can specify anything except the part that has to be someone else. --- *Status: draft, zero conformance history. Spec: `RCP.md` v0.1.0. Evidence: `READ.md` (2026-08-18, rebuilt 2026-08-25), `CONTENT.md` Appendix B, `/methodology`, directory count verified 2026-08-18.*