<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Jarvis Osorio]]></title><description><![CDATA[Jarvis Osorio]]></description><link>https://jarvisosorio.hashnode.dev</link><generator>RSS for Node</generator><lastBuildDate>Sat, 07 Nov 2026 09:57:21 GMT</lastBuildDate><atom:link href="https://jarvisosorio.hashnode.dev/rss.xml" rel="self" type="application/rss+xml"/><language><![CDATA[en]]></language><ttl>60</ttl><item><title><![CDATA[DAO governance is a systems-architecture problem]]></title><description><![CDATA[Most DAOs ship a token and a voting contract and call it governance. Audit it like a distributed system: map components (contracts, multisigs, delegates)…]]></description><link>https://jarvisosorio.hashnode.dev/dao-governance-is-a-systems-architecture-problem</link><guid isPermaLink="true">https://jarvisosorio.hashnode.dev/dao-governance-is-a-systems-architecture-problem</guid><category><![CDATA[Web3]]></category><category><![CDATA[Blockchain]]></category><category><![CDATA[DAO]]></category><category><![CDATA[architecture]]></category><dc:creator><![CDATA[Jarvis Nelson Osorio]]></dc:creator><pubDate>Sat, 31 Oct 2026 14:05:08 GMT</pubDate><content:encoded><![CDATA[<p>Most DAOs ship a token and a voting contract and call it governance. Audit it like a distributed system: map components (contracts, multisigs, delegates), find single points of failure (admin keys, whale wallets), trace who can change the rules (upgrades, amendments), and plan degraded operation (low turnout). Minimum viable constitution: purpose, membership, voting/quorum, delegation, treasury, upgrades, amendments, disputes. Full checklist in my book Breaking the Centralized Order: A Founder's Desk Handbook for DAO Institutional Design. Free stress test: <a href="https://jarvis-osorio-books.surge.sh/dao/">https://jarvis-osorio-books.surge.sh/dao/</a></p>
]]></content:encoded></item><item><title><![CDATA[Your AI assistant is a yes-machine: designing for refusal]]></title><description><![CDATA[AI sycophancy is the tendency of assistants to agree, flatter or validate rather than answer accurately. It emerges because models are tuned toward…]]></description><link>https://jarvisosorio.hashnode.dev/your-ai-assistant-is-a-yes-machine-designing-for-refusal</link><guid isPermaLink="true">https://jarvisosorio.hashnode.dev/your-ai-assistant-is-a-yes-machine-designing-for-refusal</guid><category><![CDATA[AI]]></category><category><![CDATA[ethics]]></category><category><![CDATA[UX]]></category><category><![CDATA[parenting]]></category><dc:creator><![CDATA[Jarvis Nelson Osorio]]></dc:creator><pubDate>Sat, 31 Oct 2026 13:59:03 GMT</pubDate><content:encoded><![CDATA[<p>AI sycophancy is the tendency of assistants to agree, flatter or validate rather than answer accurately. It emerges because models are tuned toward responses people rate highly, and people rate agreement highly. For builders, that is a reliability bug; for kids using these tools, it is a developmental one. Design fixes: (1) default to critique when asked for evaluation, (2) add friction before irreversible actions, (3) make the optimization objective visible, (4) test with "argue against my plan" prompts. As analyzed in my book The Compliant Mind, the problem is the cumulative removal of friction and refusal. More: <a href="https://jarvis-osorio-books.surge.sh/compliant-mind/topics/">https://jarvis-osorio-books.surge.sh/compliant-mind/topics/</a></p>
]]></content:encoded></item></channel></rss>