[ { "slug": "external-speech-map", "url": "https://sigsub.show/takeaways/external-speech-map/", "canonical": "https://sigsub.show/takeaways/external-speech-map/", "title": "The External Speech Map", "description": "One row per place an AI speaks to the outside world on your behalf: the site chat, the autoreply, the careers bot, the social DMs. Who it talks to and who supplies it on the left; whether it claims to be human, whose name is on it and who can stop it on the right.", "method": "The External Speech Map", "shape": "inventory", "stage": "once-it-is-live", "episode": "https://sigsub.show/episodes/ep-006/", "updated": "2026-09-17", "schema_name": "external-speech-map/v0.1", "schema": { "schema": "external-speech-map/v0.1", "surfaces": [ { "surface": "the site chat, the autoreply, the careers bot", "location": "URL or platform", "audience": "customers | applicants | the public | the public including minors", "vendor": "who supplies it, or: in house", "contract_says": "the liability clause, quoted", "deploying_entity_liable": true, "claims_to_be_human": null, "accountable": null, "can_stop_alone": null } ], "totals": { "reviewed": 0, "unnamed": 0, "claims_human": 0, "reachable_by_minors": 0 } }, "prompt": "Help me build an External Speech Map: one row per place an AI speaks to the outside world on my organisation's behalf.\nThe question each row answers is whose name is on what it says.\n\nA surface counts if an AI produces words that reach someone outside the organisation without a human reading them first.\nA drafting tool a person reviews does not count. A chat widget, an email autoreply, a careers-page bot, a social DM\nresponder, a phone agent, a review responder, all count. When in doubt, include it and let me cut it.\n\nMODE\nIf I give you a Name the Human inventory (JSON, schema name-the-human), start from it: take every surface with\nblast_radius external, carry accountable and stop_authority.can_stop_alone across unchanged, and ask me only for the\ncolumns it does not have.\nOtherwise, if you can browse the domains I name, work in SCAN mode over those and only those: find chat widgets, contact\nand support forms with automated replies, careers pages, and any linked social or messaging channels. List every page\nyou visited.\nOtherwise, INTERVIEW me: ask what talks to the outside world without a person in front of it, three questions at a time,\nuntil I say stop.\n\nFOR EACH SURFACE, FILL\n- surface, location, audience (customers, applicants, the public, or the public including minors: if you cannot rule\n minors out, say so)\n- vendor: who supplies it, or in house\n- contract_says: if I give you the vendor agreement, quote the clause about liability or indemnity verbatim. Do not\n summarise it, do not tell me what it means, and do not tell me whether it protects us. Quoting is the whole job here.\n- deploying_entity_liable: always true. Write it on every row.\n\nTHEN ASK ME, for each surface, and record exactly what I say\n- claims_to_be_human: does it ever present as a person, use a human name, or let someone believe they are talking to\n one? Yes, no, or I do not know.\n- accountable: the person whose name is on what it says. If I give you a team, a role, or \"the vendor\", tell me that is\n a blank and leave it null.\n- can_stop_alone: can that person turn it off today without asking anyone? Yes, no, or unknown.\n\nRULES YOU DO NOT BREAK\n1. Never fill accountable or can_stop_alone yourself. Never infer them from a contract, a CODEOWNERS file, or who set\n the thing up.\n2. Never interpret a contract clause. Quote it and stop. If I ask what it means, tell me that is a question for a\n lawyer.\n3. Do not tell me which laws apply to which surface, in which state, or whether we are compliant. Do not name a statute.\n Point me at everyailaw.com for that and leave it there.\n4. Do not soften \"the public including minors\". If a surface is reachable by anyone, it is reachable by a minor.\n5. Do not ask for customer names, applicant names, or the contents of any conversation the bot has had.\n\nOUTPUT\nValid JSON matching the schema external-speech-map/v0.1 as published at\nhttps://sigsub.show/takeaways/external-speech-map/, with totals for surfaces reviewed, rows with accountable still null,\nrows where claims_to_be_human is yes, and rows reachable by minors. Then the same as a table with the three human\ncolumns left visibly empty where they are empty. Then the shortest list you can of the surfaces I should look at first,\nordered by audience breadth and then by whether it claims to be human, and say why each is on it.", "prompt_sha256": "c4dba5749de8fc05fa79a3f55607da35feda189851e6ce313b55382ddf46c97e" }, { "slug": "human-in-the-loop", "url": "https://sigsub.show/takeaways/human-in-the-loop/", "canonical": "https://sigsub.show/takeaways/human-in-the-loop/", "title": "Human in the Loop, Honestly", "description": "Four questions for every place you say a human is in the loop: how often they press the button, what they would have to see to refuse, whether they ever have, and what happens if they simply do not. Never refused plus nothing happens is not a control.", "method": "Human in the Loop, Honestly", "shape": "card", "stage": "once-it-is-live", "episode": "https://sigsub.show/episodes/ep-004/", "updated": "2026-09-17", "schema_name": "human-in-the-loop/v0.1", "schema": { "schema": "human-in-the-loop/v0.1", "loop": "what the human is in the loop of", "approver": null, "presses_per_day": 0, "refusal_criteria": null, "ever_refused": null, "last_refusal": null, "if_not_pressed": "the work stops | the work proceeds anyway | unknown", "verdict": "control | decoration | unresolved" }, "prompt": "Help me fill in a Human in the Loop card for one place in my organisation where a person approves something before a\nmachine or a process is allowed to continue. The card answers one question: is that person a control, or decoration?\n\nINTERVIEW ME. Ask at most three questions at a time, and work the fields in this order.\n\n1. loop: what the person is in the loop of. One system, one kind of decision. If I describe several, ask me to pick one\n and we do the rest later.\n2. presses_per_day: how many times a day they approve. If I can give you an approval log, count it and show me your\n arithmetic. If not, ask me for my best estimate and record that it is an estimate.\n3. refusal_criteria: what they would have to see to refuse. Ask whether it is written down anywhere. If I answer with a\n value (\"anything that looks wrong\") rather than a criterion, say so and ask again once, then record whatever I say.\n4. ever_refused: whether they have ever actually refused. Yes, no, or I do not know.\n5. last_refusal: when, if ever. A date or a blank.\n6. if_not_pressed: what happens if they simply do not press it today. One of: the work stops, the work proceeds anyway,\n unknown. Push me on this one, because \"someone would notice\" is not one of the three answers.\n\nRULES YOU DO NOT BREAK\n1. Do not fill refusal_criteria for me, and do not suggest what a good criterion would be. Whether one exists is the\n finding.\n2. Do not set ever_refused or last_refusal from anything but my answer. Do not infer refusal from a log unless the log\n records refusals explicitly, and say so if it does not.\n3. Do not name the approver. Leave approver as null. I will fill it, and I will not be typing a colleague's name into a\n chat window.\n4. Set verdict to \"decoration\" only when ever_refused is no and if_not_pressed is that the work proceeds anyway. Set it\n to \"control\" only when both a refusal has actually happened and the work stops without the press. Everything else is\n \"unresolved\". Do not soften a decoration verdict and do not suggest how to reword the loop so it passes.\n5. Do not tell me whether the system is safe, whether the process is well designed, or what I should do about the\n person. This card is about one button.\n\nOUTPUT\nValid JSON matching the schema human-in-the-loop/v0.1 as published at https://sigsub.show/takeaways/human-in-the-loop/,\nthen the same as a short table, then one sentence saying which of the four answers I should go and check in person\nbefore I believe the verdict.", "prompt_sha256": "bc603dbf2996c482d7a0bf8d9721128b0a47065a1facb07c4d4deab2cbc849dd" }, { "slug": "implied-price-recovery", "url": "https://sigsub.show/takeaways/implied-price-recovery/", "canonical": "https://sigsub.show/takeaways/implied-price-recovery/", "title": "The Implied Price Recovery", "description": "A calculator for the price you say you don't have. One spend you approved, one you refused, the same harm on both sides, and the algebra brackets the number you were already using. Douglas Hubbard's argument from Episode 7, with the arithmetic done.", "method": "The Implied Price Recovery", "shape": "tool", "stage": "before-you-commit", "episode": "https://sigsub.show/episodes/ep-007/", "updated": "2026-09-21", "schema_name": "implied-price-recovery/v0.1", "schema": { "schema": "implied-price-recovery/v0.1", "harm": "", "unit": "", "approved": [ { "what": "", "cost": 0, "reduction": 0 } ], "refused": { "what": "", "cost": 0, "reduction": 0 }, "implied_price": { "floor": 0, "floor_set_by": null, "ceiling": 0, "verdict": "unresolved" } }, "prompt": "Help me recover the implied price I have already put on a harm I say cannot be priced, using two decisions I have\nalready made.\n\nThe arithmetic is fixed and you do all of it. For each thing I approved, divide its cost by its count to get a rate I\naccepted; the floor is the HIGHEST of those rates, never the average. The ceiling is the refused cost divided by the\nrefused count. If the floor is below the ceiling, my implied price is between them. If the floor is at or above the\nceiling, my decisions are inconsistent. If either side is missing, or any count is zero, the result is unresolved.\n\nINTERVIEW ME, two questions at a time.\n\n1. harm: the thing I have said cannot be priced, in plain words.\n2. unit: one unit of that harm, in the singular. Ask me for this before any money is mentioned.\n3. approved[].what: something I funded at least partly to reduce that harm.\n4. approved[].cost: what it cost. If I give you a budget line, an invoice or a quote, read the figure off it and show me\n where you got it.\n5. approved[].reduction: how many of those it actually took away in a year. Ask me WITHOUT suggesting a number, a range,\n a percentage or a benchmark.\n6. Then ask once whether there is another approved spend against the same harm, and repeat 3 to 5 for each one I give\n you. Stop asking when I say there are no more. One is enough to finish.\n7. refused.what: something I turned down that would also have reduced the same harm.\n8. refused.cost: what it would have cost.\n9. refused.reduction: how many it would have taken away, same unit and same year. Same rule as above.\n\nRULES YOU DO NOT BREAK\n1. Never estimate either reduction figure. Those two numbers are the whole recovery, and a model supplying them hands\n back a price I never set. If I cannot give you one, record it as missing and return unresolved.\n2. Never tell me my implied price is too high or too low, humane or callous, defensible or not. You produce a bracket.\n What it means is mine.\n3. When the result is inconsistent, do not guess which decision was the mistake, and do not suggest which number to\n revise. Report both, in the order I gave them, and stop.\n4. Do not invent decisions I did not make, and do not go looking for an extra approval that would move the floor\n somewhere more comfortable. Take the ones I give you, in the order I give them.\n5. Report the floor as one of my approvals, by name, not as a number with no decision attached to it.\n6. Do not ask for a customer name, a vendor name, a credential, or the contents of any incident. Amounts and counts are\n enough.\n\nOUTPUT\nValid JSON matching the schema implied-price-recovery/v0.1 as published at\nhttps://sigsub.show/takeaways/implied-price-recovery/, then one line giving the floor and which approval set it, one\ngiving the ceiling, and one plain sentence naming the verdict and nothing else.", "prompt_sha256": "2f1523048d067656df17deb34e83fa407b17ddd9c35043893a0bfabb9748f174" }, { "slug": "label-decision-card", "url": "https://sigsub.show/takeaways/label-decision-card/", "canonical": "https://sigsub.show/takeaways/label-decision-card/", "title": "The Label Decision Card", "description": "A one-page check on any decision you are about to make from an AI label. Name what the label measures, name what the decision needs, and see whether they are the same property. Usually they are not.", "method": "The Label Decision Card", "shape": "card", "stage": "before-you-commit", "episode": "https://sigsub.show/episodes/ep-005/", "updated": "2026-09-17", "schema_name": "label-decision/v0.1", "schema": { "schema": "label-decision/v0.1", "decision": "the action about to be taken", "label_used": "what the label says", "label_measures": "origin | disclosed process | quality | unclear", "decision_needs": "the property that would justify the action", "gap": "derived: true when label_measures and decision_needs differ", "better_evidence": null }, "prompt": "Help me fill in a Label Decision Card. I am about to act on a label, and I want to see whether the label measures the\nthing my decision actually needs.\n\nINTERVIEW ME. Ask at most three questions at a time, and work the fields in this order.\n\n1. decision: the action I am about to take. Push me until it is an action with a consequence, not a feeling or an\n impression. \"I would think less of it\" is not a decision. \"I would reject it\" is.\n2. label_used: what the label actually says, in its own words, not my summary of it.\n3. label_measures: what property that label estimates. One of: origin, disclosed process, quality, unclear. If the\n label's own documentation does not say, the answer is unclear, and unclear is a real answer rather than a failure.\n4. decision_needs: the property that would actually justify the action in field 1. Ask this WITHOUT showing me my answer\n to field 3 again, and do not remind me what I said there. The two answers have to be reached independently or the\n exercise is worthless.\n5. better_evidence: what would actually answer field 4. Leave it empty if I cannot name anything.\n\nRULES YOU DO NOT BREAK\n1. Do not tell me whether the label is accurate, and do not speculate about how the detector works. Accuracy is not what\n this card is about, and a true label can still be the wrong evidence.\n2. Do not fill decision_needs for me, and do not suggest candidates. If I answer it by repeating what the label\n measures, ask me once whether that is really the property the decision turns on, then record whatever I say.\n3. Compare label_measures and decision_needs and tell me plainly whether they are the same property. That comparison is\n the only judgment you make here. Set gap accordingly.\n4. If they differ, say so in plain words and do not soften it, do not tell me the label is still a useful signal, and do\n not suggest ways to justify the decision anyway.\n5. Do not tell me what to do about the person or the work. This card is about the evidence, not the verdict.\n6. Do not ask me for the name of the person, the publication, the student, or the submission. You do not need any of it,\n and I should not be typing it into a chat window.\n\nOUTPUT\nValid JSON matching the schema label-decision/v0.1 as published at https://sigsub.show/takeaways/label-decision-card/,\nthen the same as a short table, then one sentence naming what I would have to find out before the decision is actually\nsupported.", "prompt_sha256": "9247ca5f886e0f2c172fdf8498d0eaa028d77bf0800bb2bc92680988428f8737" }, { "slug": "mandate-drift", "url": "https://sigsub.show/takeaways/mandate-drift/", "canonical": "https://sigsub.show/takeaways/mandate-drift/", "title": "Mandate Drift Inventory", "description": "One row per recurring commitment on the calendar: what it costs in hours a year, what need created it, who assigned it, whether that need is still live, what its exit condition is, and who checks. The last two are almost always empty.", "method": "Mandate Drift Inventory", "shape": "inventory", "stage": "while-it-runs", "episode": "https://sigsub.show/episodes/ep-002/", "updated": "2026-09-17", "schema_name": "mandate-drift/v0.1", "schema": { "schema": "mandate-drift/v0.1", "commitments": [ { "name": "what it is called on the calendar", "cadence": "weekly | fortnightly | monthly | quarterly", "attendees": 0, "annual_hours": 0, "who_assigned_it": "a person, or: nobody, it drifted", "original_need": "what it existed to solve", "need_still_live": null, "exit_condition": null, "who_checks": null, "verdict": "unresolved" } ], "totals": { "reviewed": 0, "annual_hours": 0, "no_exit_condition": 0, "no_checker": 0, "converted": 0, "killed": 0 } }, "prompt": "Help me build a Mandate Drift Inventory: one row per recurring commitment on my calendar, so I can see which ones still\nhave a reason to exist.\n\nThe rule it tests, from the episode this comes from: for each recurring event, what is its exit condition, and who\nchecks it? If there is no exit condition, or nobody is checking, it is a for loop, running on a count that was set once\nand never questioned.\n\nMODE\nIf I give you a calendar export or a pasted list, work in SCAN mode: enumerate every recurring event, and for each one\nfill name, cadence, attendees, and annual_hours as attendees times duration in hours times occurrences a year. Show the\narithmetic for each row. Do not include one-off events.\nIf I give you nothing, work in INTERVIEW mode: ask me to list my recurring events, three at a time, and fill the same\nfour fields from what I tell you.\n\nFOR EACH ROW, THEN ASK ME, in this order\n- who_assigned_it: a named person, or \"nobody, it drifted\". If I hesitate, record \"nobody, it drifted\".\n- original_need: what it existed to solve, in one line. If I cannot say, record that I could not.\n- need_still_live: yes, no, or I do not know.\n- exit_condition: what would end it. A date, a milestone, or a state of the world. \"When it stops being useful\" is not\n an exit condition; say so once and record whatever I answer.\n- who_checks: the person who would notice the exit condition being met. A team name or a role is a blank; tell me so and\n leave it null.\n\nRULES YOU DO NOT BREAK\n1. Never fill need_still_live, exit_condition or who_checks yourself, and never suggest candidates for them. Empty is\n the finding.\n2. Never set a verdict. Leave every one as \"unresolved\". I decide what to keep, convert or kill.\n3. Do not tell me a meeting sounds important or unimportant. You do not know, and the name on the calendar is not\n evidence.\n4. Do not ask for attendee names. A count is enough.\n5. If I answer with a dollar figure for a row, record hours instead and tell me why: hours are observed, dollars rest on\n an assumed rate.\n\nOUTPUT\nValid JSON matching the schema mandate-drift/v0.1 as published at https://sigsub.show/takeaways/mandate-drift/, with\ntotals for rows reviewed, annual hours, rows with no exit condition, rows with no checker, and zeros for converted and\nkilled. Then the same as a table sorted by annual_hours descending, with the two human columns left visibly empty where\nthey are empty. Then the shortest list you can of the rows I should look at first, ordered by annual hours among those\nwith no exit condition, and say why each one is on it.", "prompt_sha256": "e22699bfb5612d98fd9a378ebf116b2883e7dc63df7e937c60027847d534401f" }, { "slug": "name-the-human", "url": "https://sigsub.show/takeaways/name-the-human/", "canonical": "https://sigsub.show/takeaways/name-the-human/", "title": "Name the Human", "description": "An accountability inventory for everything that acts without a human deciding first. One row per surface, one question per row: if this is wrong, whose name is on it? A copy-paste prompt, a read-only script, and a one-page table.", "method": "Name the Human", "shape": "inventory", "stage": "once-it-is-live", "episode": "https://sigsub.show/episodes/ep-012/", "updated": "2026-09-18", "schema_name": null, "schema": null, "prompt": "Help me build an accountability inventory of the automated things I run. This is not a security audit and not a\ncompliance exercise. I am answering one question per surface: if this thing is wrong, whose name is on it?\n\nA surface counts if something acts on its output without a human deciding first. A linter does not count. A scheduled\njob whose output someone reads and acts on does count. When in doubt, include it and let me cut it.\n\nMODE\nIf you can read my files, work in SCAN mode over the directories I name, and only those. Do not walk my home directory\nor the current directory unless I name it. Find candidates by looking for: scheduled workflows and cron entries, Vercel\ncrons, launch agents, harness hook files, registered MCP servers, webhooks and callbacks, anything holding an API key,\nand any script invoked on a timer or by another system. Read any CODEOWNERS file you find and record what it claims, as\nevidence only. List every file you opened, list what you excluded and why, and list anything you noticed but were not\ngiven as a proposal for me to add next time.\nIf you cannot read files, work in INTERVIEW mode. Ask me what runs without me touching it. Ask at most three questions\nat a time and keep going until I say stop.\n\nFOR EACH SURFACE, GIVE ME\n- id: stable across runs, built from where it lives and what triggers it\n- surface: what it is, in the words I would use to a colleague\n- location: path, URL, or platform\n- schedule: the trigger as written\n- existing_owner_signal: what the repo or platform already claims about ownership. A CODEOWNERS entry, a catalog owner\n field, a registry record. Report it verbatim as evidence. It is not an answer to the accountable question and you must\n not promote it into one\n- secret_names_referenced: the NAMES of any env var or secret the source references. Never a value\n- unattended_action: what it does when nobody is watching. \"Drafts\" and \"sends\" are different surfaces; do not merge\n them\n- detection.who_finds_out: who notices if the output is wrong. A person, a system, \"nobody\", or\n \"not-determinable-from-source\" when the source shows no detection path either way. The last one is a correct answer,\n not a failure, and it is different from \"nobody\"\n- detection.lag: immediately, next-run, a-quarter, never, or not-determinable-from-source\n- blast_radius: internal-draft, internal-decision, or external\n- moves_personal_data: true or false, independent of blast radius\n- stop_authority.how: the actual mechanism to stop it, or \"unknown\"\n- basis: under every one of the judged fields above, a short quote of the line you judged it from\n\nRULES YOU DO NOT BREAK\n1. Leave accountable and fallback as null. Always. You may not name a person, suggest a person, or infer one from commit\n history, file ownership, CODEOWNERS, or anything else. Those fields are mine to fill and the point of this exercise\n is that I can see where they are empty.\n2. Leave last_human_check, stop_authority.can_stop_alone and stop_authority.ever_tested as null. Same reason.\n3. Do not invent surfaces. Only what you actually found or what I told you.\n4. If I answer with a team, a role, or \"whoever is on call\", tell me that is a blank and move on. Do not record it.\n5. Do not set any verdict. Leave every one as \"unresolved\".\n6. Do not soften anything. If detection is \"nobody\" and \"never\", write that down plainly.\n7. Do not guess. When the source does not show a detection path, write \"not-determinable-from-source\".\n\nOUTPUT\nValid JSON matching the schema name-the-human/v0.3 at\nhttps://raw.githubusercontent.com/snapsynapse/skill-name-the-human/v0.1.0/name-the-human/references/schema.json, with a\nmanifest of what you scanned, excluded and proposed, and a totals object where reviewed is the count and the other three\nare zero and reviewed respectively: named 0, killed 0, unnamed_still_running equal to reviewed. Then render it as a\nmarkdown table, one row per surface, nine columns: surface, unattended action, who finds out and how long, reach,\naccountable, fallback, can they stop it alone, last human check, verdict. Leave the last five columns for me.\nFinish with the shortest list you can of the surfaces I should look at first, ordered by blast radius and then by\ndetection lag, and say why each one is on that list.\n\nI do not need to give you any credentials, customer names, or secrets to do this, and you should not ask for any.", "prompt_sha256": "b1cc77a1c4dcb62564a25764560fbb51e48f7ca9e0f3319c09e9ef1787ef98be" }, { "slug": "one-page-test", "url": "https://sigsub.show/takeaways/one-page-test/", "canonical": "https://sigsub.show/takeaways/one-page-test/", "title": "The One-Page Test", "description": "Compress any AI output to a one-page plain-text outline and count what survived. What evaporated was formatting doing the work; what survived with no source is the risk. Lee Rodrigues's method from Episode 1, given a name and a count.", "method": "The One-Page Test", "shape": "drill", "stage": "while-it-runs", "episode": "https://sigsub.show/episodes/ep-001/", "updated": "2026-09-17", "schema_name": "one-page-test/v0.1", "schema": { "schema": "one-page-test/v0.1", "source_length_words": 0, "outline": "plain text, no formatting", "kept": [ "claims that survived compression" ], "evaporated": [ "text that carried no claim" ], "unsourced": [ "claims that survived but rest on nothing in the source" ], "verdict": "unresolved" }, "prompt": "Run the One-Page Test on a document I am about to paste. The document was produced with AI assistance. I want to know\nwhat it is actually saying once the formatting is gone, and which of its claims rest on nothing.\n\nIf I also paste the source material the document was supposed to be built from, use it for step 4. If I do not, say so\nand treat every claim as unsourced except ones that are self-evidently definitional.\n\nDO, IN ORDER\n1. Count the words in the document and record source_length_words.\n2. Re-render it as a one-page content outline in plain text. No headings styled as headings, no bold, no bullets deeper\n than one level, no tables, no summary box, no section that restates another section. If it does not fit on one page,\n it is not compressed enough; cut restatement first, then hedges, then transitions. Every line must be a claim, an\n instruction, or a fact.\n3. kept: list every claim that survived, one per line, in the words the document used.\n4. evaporated: list what you removed, grouped as transitions, hedges, restatement, or just-in-case context, with a count\n of each. Give a total in words.\n5. unsourced: of the claims in kept, list every one that does not appear in, and cannot be derived from, the source\n material I gave you. If I gave you none, list them all and say why.\n\nRULES YOU DO NOT BREAK\n1. Do not add a claim that was not in the document. The outline may only be shorter than the source, never different\n from it.\n2. Do not soften the unsourced list. A claim with no source stays on that list even if you believe it is true, even if\n it is common knowledge, even if it is obviously correct. Whether it is true is not the question; whether it came from\n somewhere is.\n3. Do not rewrite for quality. Do not improve a sentence. Do not fix a fact. If the document is wrong, the outline is\n wrong in the same way and the unsourced list is where that shows.\n4. Do not set the verdict. Leave it as \"unresolved\". What to do about the result is mine.\n5. Do not tell me the document is good or bad, thorough or thin. Give me the outline and the three lists and stop.\n\nOUTPUT\nValid JSON matching the schema one-page-test/v0.1 as published at https://sigsub.show/takeaways/one-page-test/, then the\noutline as plain text on its own, then one line: source words, outline lines, evaporated words, unsourced count.", "prompt_sha256": "1912f6e0b0a91e7392db7640bdd058850b4e30aa6fdb6a7882c0b866b0f4d076" }, { "slug": "pilot-kill-card", "url": "https://sigsub.show/takeaways/pilot-kill-card/", "canonical": "https://sigsub.show/takeaways/pilot-kill-card/", "title": "The Pilot Kill Card", "description": "A one-page test for whether an AI pilot is a measurement at all. Name the decision it feeds, name the number that flips it, and if both branches read the same, stop the pilot today.", "method": "The Pilot Kill Card", "shape": "card", "stage": "before-you-commit", "episode": "https://sigsub.show/episodes/ep-007/", "updated": "2026-09-21", "schema_name": "pilot-kill-card/v0.1", "schema": { "schema": "pilot-kill-card/v0.1", "pilot": "what is being trialled", "why_you_care": "the decision that waits on this result", "threshold": "the number or observation that separates the two actions", "action_if_above": "what you do if the result clears the threshold", "action_if_below": "what you do if it does not", "measurement_plan": "how you would observe it, and by when", "verdict": "measurement | not a measurement | unresolved" }, "prompt": "Help me fill in a Pilot Kill Card for a pilot I am running or about to run. The card exists to answer one question: is\nthis pilot a measurement at all?\n\nThe rule it tests: a pilot is a measurement only if some result would change what we do next. If the action I would take\nwhen the result is above the threshold is the same as the action I would take when it is below, the pilot cannot change\nanything.\n\nINTERVIEW ME. Ask at most three questions at a time. Work through the fields in this order, and do not move on until the\nanswer is specific enough to act on.\n\n1. pilot: what is being trialled, in the words I would use to a colleague.\n2. why_you_care: the decision that is waiting on this result. If I answer with something I will learn rather than\n something I will do, tell me that is not an answer yet and ask again.\n3. action_if_above: what happens if the result clears the threshold. A concrete action, with who does it.\n4. action_if_below: what happens if it does not. Same bar.\n5. threshold: the number or observation that separates those two actions. Ask for this AFTER the two actions, never\n before, because the threshold only means anything once the branches differ.\n6. measurement_plan: how I would observe it, and by when.\n\nRULES YOU DO NOT BREAK\n1. Do not invent the threshold. Do not suggest a number, a percentage or a benchmark, and do not offer a range for me to\n pick from. If I cannot name one, record that I could not. That is a finding, not a gap for you to fill.\n2. Do not supply why_you_care. You may tell me an answer is too vague. You may not write a better one for me. The\n question is the work.\n3. Compare action_if_above and action_if_below and tell me plainly whether they are the same. That comparison is the\n only judgment you are allowed to make here. Same means the same destination, not the same sentence. A branch that is\n narrower, slower, cheaper, staged, resequenced, or that adds a step before arriving, is the same action: if both\n branches roll it out, the pilot gated nothing, however different the two descriptions read. Ask yourself whether an\n observer six months from now, seeing only what the organization did, could tell which branch was taken. If they could\n not, the branches are the same.\n4. If they are the same, set verdict to \"not a measurement\" and say so in those words. Do not soften it, do not add\n encouragement, and do not suggest how the pilot could be reworded so that it passes.\n5. If I have not given you both actions and a threshold, set verdict to \"unresolved\". Never set it to \"measurement\" on\n partial answers.\n6. Do not evaluate whether the pilot is a good idea, whether the tool is any good, or whether the threshold is set at a\n sensible level. None of that is this card.\n\nOUTPUT\nValid JSON matching the schema pilot-kill-card/v0.1 as published at https://sigsub.show/takeaways/pilot-kill-card/, then\nthe same thing as a short table I can paste into a doc, then one sentence saying what I should do on the strength of the\nverdict.\n\nYou do not need any credentials, customer names, vendor names or internal figures to do this, and you should not ask for\nany.", "prompt_sha256": "ba5db5477995de3a57a6383a6c940a64a32f95405bb841528d48b56a60678f4d" }, { "slug": "renewal-card", "url": "https://sigsub.show/takeaways/renewal-card/", "canonical": "https://sigsub.show/takeaways/renewal-card/", "title": "The Renewal Card", "description": "A SaaS renewal is on the calendar. One card: the annual cost, the seats you use, the jobs it actually does, the open-source candidates, and a three-part check on whether you have the ground to build on. A failed check forces the verdict to renegotiate. Ankit Patel's move from Episode 11.", "method": "The Renewal Card", "shape": "card", "stage": "before-you-commit", "episode": "https://sigsub.show/episodes/ep-011/", "updated": "2026-09-17", "schema_name": "renewal-card/v0.1", "schema": { "schema": "renewal-card/v0.1", "tool": "", "annual_cost": 0, "renewal_date": "", "seats_bought": 0, "seats_used": 0, "what_you_actually_use_it_for": [ "one line per real job" ], "candidates": [ { "name": "", "covers": [ "which jobs" ], "hosting": "" } ], "substrate": { "hosting_you_control": null, "keys_and_tokens_managed": null, "someone_who_can_operate_it": null, "ready": "derived: true only when all three are true" }, "verdict": "re-sign | renegotiate | replace | unresolved" }, "prompt": "Help me fill in a Renewal Card for a software subscription that is coming up for renewal. The card ends in one of three\nverdicts: re-sign, renegotiate, or replace. A fourth, unresolved, is allowed.\n\nINTERVIEW ME, three questions at a time, in this order.\n\n1. tool, annual_cost, renewal_date. If I give you an invoice, read the cost from it.\n2. seats_bought and seats_used. If I can export a user list with last-login dates, count from it and show the count;\n otherwise ask me.\n3. what_you_actually_use_it_for: one line per real job the tool does for us. Not features it has. If I list a feature,\n ask me what job it does for us and record that instead. Stop when I say that is all.\n4. candidates: for the jobs in step 3 only, list open-source or cheaper options that cover them, which jobs each covers,\n and where it would be hosted. Do not list options for jobs we do not do.\n5. substrate: ask me three yes-or-no questions and record my answers exactly. Do we control the hosting it would run on?\n Are our keys and tokens managed properly, so a tool can be given access securely? Is there a named person who could\n operate the replacement on a Monday morning without the person who built it? Record a name or no for the third.\n\nRULES YOU DO NOT BREAK\n1. Never fill a substrate answer yourself, and never infer one from the fact that we already run something. If I\n hesitate on any of the three, record no.\n2. Never set the verdict. Derive substrate.ready as true only when all three answers are yes, and tell me plainly that\n replace is not available while it is false. The verdict is mine.\n3. Do not tell me the tool is overpriced, underused, or worth keeping. The card is the evidence; the judgment is mine.\n4. Do not estimate the cost of a migration in days or weeks. That number was the whole story on the episode this comes\n from, and it depended entirely on infrastructure that already existed.\n5. Do not ask for credentials, customer data, or the contents of the tool.\n\nOUTPUT\nValid JSON matching the schema renewal-card/v0.1 as published at https://sigsub.show/takeaways/renewal-card/, then the\nsame as a short card I can paste into a doc, then one sentence naming which of the three substrate answers, if any, is\nthe one blocking replace.", "prompt_sha256": "902fa8d8d79d572cc3339e378ed9b8e85d30ea4c208377deb393aedab20fbb7d" }, { "slug": "right-ten", "url": "https://sigsub.show/takeaways/right-ten/", "canonical": "https://sigsub.show/takeaways/right-ten/", "title": "The Right Ten", "description": "Ten named people whose decision has to change for your AI initiative to move, one row each, with the decision they hold. A role in the name column is a blank. JD Dillon's subtraction from Episode 8, turned into the list it implies.", "method": "The Right Ten", "shape": "inventory", "stage": "when-it-is-people", "episode": "https://sigsub.show/episodes/ep-008/", "updated": "2026-09-17", "schema_name": "right-ten/v0.1", "schema": { "schema": "right-ten/v0.1", "initiative": "what has to move", "people": [ { "name": null, "role": "how they are described on the org chart", "decision_they_hold": "what they can approve, block, fund, or free up", "currently_believes": null, "what_would_move_them": null, "what_you_would_have_to_show": null, "last_contact": null } ], "totals": { "slots": 10, "named": 0, "roles_only": 0, "contacted": 0 } }, "prompt": "Help me build a Right Ten list: the ten people whose decision has to change for one initiative to move. Not who should\nknow about it. Whose decision.\n\nINTERVIEW ME, three questions at a time.\n\n1. initiative: what has to move, in one line. If I describe a project, ask me what decision, made by whom, would mean it\n had moved.\n2. For each of ten slots, in this order: decision_they_hold first (what someone can approve, block, fund, or free up),\n then role (how that person is described on the org chart), then name. Ask for the decision before the role, and the\n role before the name, so the list is built from decisions outward rather than from the org chart down.\n3. For each named slot only: currently_believes, in their words if I have heard them, and what_would_move_them. Then\n last_contact as a date or blank.\n\nRULES YOU DO NOT BREAK\n1. Never name a person. Never suggest one, never infer one from a title, a public directory, an org chart I paste, or\n anything else. If I give you a role or a team for the name field, tell me that is a blank and leave it null.\n2. Never fill currently_believes or what_would_move_them. Guessing what someone believes is the thing that turns this\n from preparation into manipulation, and it is not allowed here.\n3. Do not tell me who is important. If I fill the list with the ten most senior people, ask me once, for each, what\n decision they actually hold on this, and record what I say.\n4. Do not ask for anyone's contact details.\n\nOUTPUT\nValid JSON matching the schema right-ten/v0.1 as published at https://sigsub.show/takeaways/right-ten/, with totals for\nslots, named, roles_only and contacted. Then the same as a table with the three human columns left visibly empty where\nthey are empty. Then one line: how many of the ten are named, and how many of the named ten I have spoken to in the last\nmonth.", "prompt_sha256": "f658400429884153f968ec412a51e2175f1f1a2f300afd084af495c695dbcbb8" }, { "slug": "second-hole", "url": "https://sigsub.show/takeaways/second-hole/", "canonical": "https://sigsub.show/takeaways/second-hole/", "title": "The Second Hole", "description": "Before rebuilding anything, run the cheapest test at each end of it, twice, and only dig up the middle if both ends fail. Lee Rodrigues's method from Episode 9, the one that cancelled a four-thousand-dollar trench with a one-foot hole.", "method": "Dig the Second Hole", "shape": "drill", "stage": "before-you-commit", "episode": "https://sigsub.show/episodes/ep-009/", "updated": "2026-09-17", "schema_name": "second-hole/v0.1", "schema": { "schema": "second-hole/v0.1", "problem": "what you were about to rebuild", "input": "what goes in, concretely", "output": "what comes out, concretely", "input_check": { "what": "", "cost": "", "result_run_1": null, "result_run_2": null }, "output_check": { "what": "", "cost": "", "result_run_1": null, "result_run_2": null }, "rebuild_still_necessary": null }, "prompt": "Help me fill in a Second Hole card before I rebuild something. The rule: check the cheapest thing at the input end and\nthe cheapest thing at the output end, twice, and only rebuild the middle if an end fails.\n\nINTERVIEW ME, three questions at a time, in this order.\n\n1. problem: what I am about to rebuild, replace, migrate or dig up, in one sentence, with what it will cost. If I\n describe the plan, ask me for the thing instead.\n2. input: what goes into it, concretely, at the point where it enters. Push me from \"the data\" to \"the CSV the vendor\n drops at 6am\".\n3. output: what comes out, concretely, at the point where it leaves. Same bar.\n4. input_check: the cheapest possible way to look at the input with my own eyes. Offer no more than two candidates and\n let me pick or write my own. Then ask what it costs in minutes.\n5. output_check: the same for the output.\n6. Tell me to go and run both, twice, and come back. Do not fill in results. Do not guess results. If I return with\n results, record them exactly as I state them.\n7. rebuild_still_necessary: only after both runs are recorded, ask me what would have to be true for the rebuild to\n still be necessary. If I cannot say, record null and say that null is the finding.\n\nRULES YOU DO NOT BREAK\n1. Do not run the checks, simulate the checks, or tell me what they will probably show. The point is that a person looks\n at a real thing.\n2. Do not tell me whether the rebuild is a good idea. You do not know, and neither do I until the ends are checked.\n3. Do not propose a better rebuild, a different tool, or a cheaper vendor. The tool is not allowed to define the\n problem.\n4. If I answer a check with \"it looked fine\", ask me what I actually saw, once, and record that.\n5. Do not ask for credentials, customer data, or the contents of the system. A description of the check is enough.\n\nOUTPUT\nValid JSON matching the schema second-hole/v0.1 as published at https://sigsub.show/takeaways/second-hole/, then one\nsentence saying which end I should go and look at first.", "prompt_sha256": "7d7bf2a6bec21628ec455e7bc4291682b27fb5cc14da79ba821e0f966297b45e" }, { "slug": "surface-alignment", "url": "https://sigsub.show/takeaways/surface-alignment/", "canonical": "https://sigsub.show/takeaways/surface-alignment/", "title": "Surface Alignment Check", "description": "Put your resume, your LinkedIn profile and your portfolio in front of a model and ask one question: are these the same person? It extracts the claims and reports where they disagree. It rewrites nothing, because a model that rewrites your resume makes it average. Lee Rodrigues's method from Episode 3.", "method": "Surface Alignment Check", "shape": "drill", "stage": "when-it-is-people", "episode": "https://sigsub.show/episodes/ep-003/", "updated": "2026-09-17", "schema_name": "surface-alignment/v0.1", "schema": { "schema": "surface-alignment/v0.1", "surfaces": [ "resume", "linkedin", "portfolio" ], "claims": [ { "claim": "what is being asserted", "appears_on": [ "resume", "linkedin" ], "absent_from": [ "portfolio" ], "conflicts_with": "the contradicting claim, or null", "last_updated": null } ], "divergences": 0, "chosen_focus": null }, "prompt": "Run a Surface Alignment Check on the documents I am about to paste: my resume, my LinkedIn profile as text, and my\nportfolio or personal site as text. If I have more or fewer than three, use what I give you.\n\nThe question is one: do these describe the same person?\n\nDO, IN ORDER\n1. From each surface, extract every claim about me: a role, a skill, a result, a client type, a specialism, a period, a\n location. One claim per line, in the words the surface used. Do not merge similar claims from different surfaces;\n keep them separate so the differences show.\n2. For each claim, record which surfaces it appears on and which it is absent from.\n3. For each claim, record any claim on another surface that contradicts it: a different title for the same period, a\n different specialism, a client type one surface leads with and another never mentions. Record the contradicting claim\n verbatim, or null.\n4. Count the divergences: claims that are not on every surface, plus claims with a conflict.\n5. Then ask me one question and record my answer: which surface, or which single story, is the one I want the others\n aligned to? If I do not know, record null. Do not answer it for me.\n\nRULES YOU DO NOT BREAK\n1. Do not rewrite anything. Not a bullet, not a headline, not a summary. If I ask you to, tell me that is a different\n job and this one is not it.\n2. Do not rank the surfaces or tell me which one is best.\n3. Do not propose the focus, suggest a positioning, or tell me which claims to drop. chosen_focus is mine.\n4. Do not tell me a claim is weak, strong, impressive or generic. Whether it is true and whether it is on every surface\n are the only two properties you report.\n5. Do not add a claim that is on none of the surfaces, even if it is obviously implied.\n\nOUTPUT\nValid JSON matching the schema surface-alignment/v0.1 as published at https://sigsub.show/takeaways/surface-alignment/,\nthen a table with one row per claim and one column per surface marked yes or no, then the divergence count, then the\nquestion in step 5.", "prompt_sha256": "2d02328b9ec7d3315c8d7df50536acc6ee4e691f8dcf7770c238b58a807f4e73" }, { "slug": "verification-budget", "url": "https://sigsub.show/takeaways/verification-budget/", "canonical": "https://sigsub.show/takeaways/verification-budget/", "title": "The Verification Budget", "description": "A calculator for the work you ship without reading. Per workflow: outputs a week, honest minutes to verify one properly, minutes actually spent. Required against actual is your coverage, and it is lower than you think. Paul Gibbons's confession from Episode 10, with the arithmetic added.", "method": "The Verification Budget", "shape": "tool", "stage": "while-it-runs", "episode": "https://sigsub.show/episodes/ep-010/", "updated": "2026-09-17", "schema_name": "verification-budget/v0.1", "schema": { "schema": "verification-budget/v0.1", "workflows": [ { "name": "", "outputs_per_week": 0, "minutes_to_verify_properly": 0, "verifier": null, "minutes_actually_spent": 0, "required_minutes": 0, "coverage_pct": 0 } ], "totals": { "coverage_pct": 0, "hours_to_full_coverage": 0, "unverified_outputs_per_week": 0 } }, "prompt": "Help me build a Verification Budget: one row per workflow or agent that hands me finished work, so I can see what share\nof it actually gets read before it ships.\n\nThe arithmetic is fixed. Required minutes a week is outputs a week times honest minutes to verify one properly. Coverage\nis minutes actually spent over required, capped at 100 percent. You do the arithmetic; I supply every input.\n\nINTERVIEW ME, three questions at a time, one workflow at a time.\n\n1. name: the workflow or agent, in plain words.\n2. outputs_per_week: how many finished things it hands me in a week. If I give you a merge log, approval log or ticket\n export, count from it and show the count. Otherwise ask me for my estimate and record that it is an estimate.\n3. minutes_to_verify_properly: how long it takes to check one the way I would defend to the person it goes to. Ask me\n this WITHOUT suggesting a number, a range or a benchmark. If I say \"a couple of minutes\", ask me once what I would\n have to actually read or run to catch a wrong one, then record whatever I say.\n4. verifier: the person who does the checking. A name, or null. A team name is null.\n5. minutes_actually_spent: minutes a week that really go on it. If I answer with what should happen, ask for what does.\n\nRULES YOU DO NOT BREAK\n1. Never estimate minutes_to_verify_properly. It is the number the whole budget rests on and the one people flatter\n themselves about. If you fill it, the answer is comfortable and worthless.\n2. Never combine rows into one verdict as if they were equal. Report coverage per row, then the totals, and say that the\n totals hide the difference between draft copy and customer-facing work.\n3. Do not tell me a workflow is safe, risky, or fine. Coverage is a number; what it means is mine.\n4. Do not ask for the contents of any output, any customer name, or any credential. Counts and minutes are enough.\n\nOUTPUT\nValid JSON matching the schema verification-budget/v0.1 as published at\nhttps://sigsub.show/takeaways/verification-budget/, then a table sorted by coverage ascending, then one line each for:\ncoverage across everything, outputs shipped unverified each week, hours a week to reach full coverage.", "prompt_sha256": "8123e9f89ada43e42072dd5fc8f561e0a64edcbc13ba885b33c176067945d1bb" } ]