{
  "txid": "1b553d6fb42524d3d8a31707e9c1884e35a372214a145d5c687e07353cad65c2",
  "block_height": 956350,
  "time": null,
  "app": "treechat",
  "type": "reply",
  "map_content": "awesome questions! \r\n\r\nFirstly: in my case, it\u2019s not a fan-out.\r\nThere\u2019s only one machine-to-machine 'x402' hop: from Intellegio to John Calhoun\u2019s x-research service.\r\n\r\nBoth sides are using AuthFetch on BSV rails: BRC-103/104 for mutual auth, and BRC-29 for the sats.   so .. one hop means just one place to gate.\r\n\r\nOn the recourse question, you\u2019re right that x402 doesn\u2019t give me chargeback abilities. Once BSV settles, it\u2019s settled. So the quality promise has to sit with whoever collected the $9, not with the automated payment itself. In my case that's my service. \r\n\r\nFour gates sit around the paid hop:\r\n\r\nA free deterministic topic check that blocks obvious garbage before any LLM cost.\r\nA Haiku readiness gate that either produces a refined X query or asks a clarification question. It\u2019s iterative: Haiku can ask, the user answers, Haiku evaluates again, and that repeats until the topic is specific enough to search on.\r\nOn top of that, I have a linter that grades every query Haiku produces. If it finds structural problems, like too many OR groups intersected or unquoted multi-word entities, it retries the call once with the findings as feedback.\r\n\r\nPost-hop, a quick count of what came back in the corpus. If it\u2019s clearly unusable, I skip Opus entirely and go straight to a rerun email.\r\nOpus itself makes a structured call on whether the brief it just wrote should actually ship: send it standard, send it with a limited-signal disclosure, or don\u2019t send.\r\nThe pipeline branches on Opus\u2019s own answer.\r\n\r\nAnd, to be extra-over-the-top I do a pattern check on the finished brief catches the case where Opus said \u201cship,\u201d but the text it wrote is really an apology for the corpus not matching the topic.\r\n\r\nIn that case, the pipeline overrides Opus and routes to the rerun path.\r\n\r\nSo there are three outcomes:\r\n\r\n-Ship a standard brief.\r\n-Ship one with a limited-signal disclosure baked in.\r\n-Or don\u2019t ship, and offer a free rerun on a sharper angle.\r\n\r\nThe customer\u2019s $9 buys either a good brief or another attempt, not a refund. I say this on the website - clarity was a goal. \r\n\r\nEvery path preserves the raw corpus at a viewable URL, so the customer always sees the receipt.\r\n\r\nSo I guess you'd say I do full transparency instead of dispute rights. \ud83e\udd37\ud83c\udffb\u200d\u2640\ufe0f\r\n\r\nThis might also be interesting to you and goes to I think a point you made about the x402 part: the BSV-native 'x402' flow does not have a refund capability (to my knowledge anyway). John\u2019s server can return a signed refund transaction in the response body if his side determined the call didn\u2019t deliver, and my client internalizes it back into the wallet.\r\n\r\nSo there\u2019s a small amount of built-in recourse on the machine hop itself.\r\n\r\nNot fire-and-forget in the way you\u2019d expect, though nothing like the disputes fiat gives you. Great stuff to think about tthank you Sunnie!",
  "media_type": "text/markdown",
  "filename": "|",
  "author": "14aqJ2hMtENYJVCJaekcrqi12fiZJzoWGK",
  "display_name": "bridget",
  "channel": null,
  "parent_txid": "1ff22670d5f63bc654d74bd5be2a6c6b3516353d623a720f18689ded316a5e38",
  "ref_txid": null,
  "tags": null,
  "reply_count": 2,
  "like_count": 0,
  "timestamp": "2026-07-04T06:02:44.000Z",
  "media_url": null,
  "aip_verified": false,
  "thread_root_tx": null,
  "engagement_score": 0,
  "token_ref": null,
  "token_type": null,
  "kind": null,
  "lat": null,
  "lng": null,
  "category": null,
  "locked_sats": "0",
  "pow_bits": 0,
  "attachments": [],
  "ui_name": "bridget",
  "ui_display_name": "bridget",
  "ui_handle": "bridget",
  "ui_display_raw": "bridget",
  "ui_signer": "14aqJ2\u2026oWGK",
  "ref_ui_name": "unknown",
  "ref_ui_signer": "unknown"
}