Founder bottleneck से owner delegate तक: AI-native company को owner के attention से आगे scale करना

15 Concepts और दो lab tracks. Title में "half-day" simulated track है: लगभग 2 से 3 घंटे की conceptual reading और 2 से 3 घंटे का simulated lab, mock endpoints के साथ। Full-implementation track अलग 1-day sprint से 2-day workshop है: लगभग 3 घंटे reading और 6 से 10 घंटे hands-on lab. Full track Paperclip के codebase को modify नहीं करता; यह आपकी Identic AI को Paperclip agent के रूप में register करता है, आपकी अपनी integration skill में signing-and-verification layer बनाता है, और real Paperclip approval routes के against पूरा cryptographic round-trip exercise करता है। Decision 1 से पहले track चुनें; details के लिए Part 4 देखें।

यह continuation crash course है। यह agentic-coding track के नौ courses में Course Eight है, और यह Agent Factory thesis के Invariant 2: हर human को delegate चाहिए का deep operationalization है। Courses Five, Six, और Seven ने आपको AI-native company के hired Workers को build, govern, और grow करना सिखाया। उन तीन courses ने एक बात unresolved छोड़ी: जब workforce इतनी बड़ी हो जाती है कि human owner हर approval thread पढ़ नहीं सकता, तब क्या होता है। Course Eight इसे architecture का last bottleneck नाम देता है और वह trust-delegation pattern सिखाता है जो इसे हटाता है। Owner का delegate, यानी उसकी Identic AI (Don Tapscott का term ऐसे personal AI के लिए जो अपने user की identity, preferences, और authority carry करता है), उसकी ओर से routine governance traffic लेता है, उसका judgment apply करता है, और सिर्फ वे decisions surface करता है जिन्हें सच में owner की ज़रूरत है।

वह single insight जिससे बाकी सब click करता है: AI-native company hiring API पर नहीं, owner के attention पर scale होना बंद करती है; Owner Identic AI वह primitive है जो owner को control से हटाए बिना bottleneck से हटाता है। Courses Five से Seven आपको एक हज़ार Workers hire करने देते हैं। उन courses में कुछ भी owner को approval threads में डूबने से नहीं बचाता। Course Eight का हर Concept या तो यह expand करता है कि delegate autonomously क्या decide करता है, या उस seam को sharpen करता है जहाँ decision human के पास लौटना चाहिए। दोनों ही architecture हैं।

Agent Factory के लिए यह क्यों मायने रखता है: Invariant 2 पूरा

Agent Factory thesis सात structural rules बताती है जिन्हें AI-native company को follow करना चाहिए। Invariant 2 कहता है कि हर human को एक personal AI agent, एक "delegate", चाहिए जो उसकी ओर से उसका context, judgment, और authority hold करे। यह architect की framing sentence है, जिसके around यह पूरा course बना है:

"Founder दस Workers hire कर सकता है और हर approval पढ़ सकता है; founder एक हज़ार Workers hire करके हर approval नहीं पढ़ सकता। अगर कोई Identic AI owner की ओर से act नहीं करती, owner के known judgment को routine decisions पर apply नहीं करती, और सिर्फ non-routine decisions surface नहीं करती, तो AI-native company का हर पिछला invariant owner के attention पर cap हो जाता है। Owner की Identic AI productivity tool नहीं है। यह इस सवाल का अकेला architectural answer है कि AI-native company अपने founder से आगे कैसे scale करती है।"

Thesis OpenClaw को shipped delegate के रूप में specify करती है। यह course delegate के एक specific use के लिए OpenClaw configure करना सिखाता है: company owner का governance delegate, वह agent जो owner का authority envelope hold करता है और उसकी ओर से approval traffic broker करता है। Course thesis को contradict किए बिना extend करता है: thesis delegate define करती है; course सिखाता है कि workforce जितने approval traffic को safely absorb करने के लिए delegate को cryptographically और operationally क्या करना होगा।

Courses Three से Seven ने बाकी invariants को depth में operationalize किया:

• Three ने Invariant 4 cover किया (engine choice, वह runtime जिस पर हर agent चलता है)
• Four ने Invariant 5 cover किया (MCP के through system of record)
• Five ने Invariant 7 cover किया (Inngest के साथ nervous system)
• Six ने Invariant 3 cover किया (Paperclip के साथ management layer)
• Seven ने Invariant 6 cover किया (callable capability के रूप में hiring) Course Eight उसी depth के साथ Invariant 2 complete करता है। Course Nine फिर cross-cutting discipline, eval-driven development, add करता है जो हर Worker, हर hire, और हर delegated decision को production में measurably trustworthy बनाता है।

Platform choice के बारे में

Courses Five से Seven ने आपको Paperclip को management layer, Inngest को operational envelope, और Claude Managed Agents को hired Workers के worked-example runtime के रूप में use करना सिखाया। Course Eight owner के delegate के runtime के रूप में OpenClaw (openclaw.ai, github.com/openclaw/openclaw, docs.openclaw.ai) introduce करता है, वही OpenClaw जिसे Agent Factory thesis Invariant 2 में name करती है।

OpenClaw एक open-source personal AI assistant है जो user की local machine (Mac, Windows, या Linux) पर चलता है, उन chat apps के through reachable है जिन्हें user पहले से use करता है, और persistent memory, user data sovereignty, और skill extensibility के around बना है। यह 50+ integrations expose करता है, जिनमें 15+ chat channels शामिल हैं (WhatsApp, Telegram, Discord, Slack, Signal, iMessage, और more)। Concept 4 बताता है कि OpenClaw असल में क्या है, thesis इसे delegate के रूप में क्यों ship करती है, और अगर आप runtime swap करना चाहें तो alternatives कैसे दिखेंगे।

Course Eight जो delegated governance primitive सिखाता है, यानी owner की Identic AI company की Paperclip workforce को requests कैसे sign करती है, वह OpenClaw और Paperclip के बीच shipped integration नहीं है। यह architectural pattern है जिसे Course Eight आपको OpenClaw के skills system और Paperclip के verified-identity primitives से assemble करना सिखाता है। दोनों products building blocks ship करते हैं; course उन्हें wire करता है।

May 2026 तक known rough edges (इनसे टकराएँ तो हैरान न हों)

• OpenClaw तेज़ी से move कर रहा है। Project MIT license के तहत open source है, जो real continuity guarantee है, लेकिन यह अभी भी weekly skills, integrations, और primitives add कर रहा है, और पहले छह महीनों में इसकी institutional position एक से ज़्यादा बार shift हुई है। Course May 2026 तक openclaw.ai और docs.openclaw.ai की stable surface के against सिखाता है; specific dates, version numbers, और integration counts को authoritative मानने से पहले official site से verify करना चाहिए। उन URLs पर जो नहीं है, उसे in motion मानें।
• Owner का judgment-learning loop, यानी Identic AI owner के past approval decisions से owner की values कैसे सीखती है, आज shipped चीज़ों के frontier पर है। Course Eight May 2026 में काम करने वाली architectural commitments और practical patterns सिखाता है, और साफ़ नाम देता है कि कौन से हिस्से open research हैं (Concepts 13 से 15)।

TL;DR (अगर आपके पास 60 seconds हैं तो इसे पहले पढ़ें)

चार claims क्रम में:

1. AI-native company hiring API पर नहीं, owner के attention पर scale होना बंद करती है। Courses Five से Seven आपको एक हज़ार Workers hire करने देते हैं; उन courses में कुछ भी owner को approval threads में डूबने से नहीं बचाता।
2. Architectural answer है owner को एक Identic AI देना: ऐसा personal AI delegate जो owner के hardware पर रहता है, उसके judgment patterns जानता है, और routine decisions के लिए उसकी ओर से act करता है जबकि consequential decisions surface करता है।
3. OpenClaw May 2026 में इसके लिए credible shipped runtime है। यह open source है, user-owned है, owner की existing chat apps से reachable है, और user की persistent memory के around बना है। Course सिखाता है कि इसे general-purpose assistant नहीं, governance delegate के रूप में कैसे configure करें।
4. Trust-delegation primitive, यानी वह architectural pattern जो human owner और owner की Identic AI दोनों को authority के साथ act करने देता है लेकिन audit log में अलग पहचान बनाए रखता है, Course Eight का central technical move है। यही delegated governance को reckless नहीं, safe बनाता है।

Plain-English version, अगर ऊपर की बातों में कुछ छूट गया

Course Seven में, हमने एक छोटी AI company बनाई थी जो human owner की approval के तहत चौथा AI Worker (Legal Specialist) hire कर सकती थी। यह तब काम करता है जब company में चार Workers हों। जब company में चार सौ Workers होते हैं, human owner हर approval नहीं पढ़ सकती; वह पूरा दिन approvals ही पढ़ती रहेगी। यह course owner को अपना personal AI assistant रखना सिखाता है, OpenClaw नाम के open-source tool से, जो उसके laptop पर चलता है। वह assistant owner की ओर से approvals पढ़ता है, उसके past decisions से सीखे हुए patterns use करके easy decisions खुद करता है, और उसे सिर्फ तब जगाता है जब सच में उसके judgment की ज़रूरत हो। Course company के management system को यह भी सिखाता है कि owner ने खुद "approve" click किया या owner की personal AI ने उसकी ओर से "approve" click किया, इन दोनों में फर्क कैसे करें, क्योंकि दोनों authorized हैं, लेकिन audit trail को उन्हें अलग दिखाना होगा।

Architectural payoff: owner का attention अब सिर्फ उन decisions पर खर्च होता है जिन्हें सच में human judgment से benefit मिलता है।

Courses Five से Seven recap: चीज़ें कहाँ छोड़ी गई थीं (expand करने के लिए click करें)

अगर आपने अभी Course Seven finish किया है, तो skim करें और आगे बढ़ें। अगर आप इसे cold शुरू कर रहे हैं या कुछ समय हो गया है, तो नीचे के चार context pieces Course Eight के बाकी हिस्से के लिए load-bearing हैं।

Course Five से (operational envelope): company के Workers Inngest के durable-execution wrapper के अंदर चलते हैं, जो उन्हें crash-safe runs, retry-on-failure, दो specific tables (activity_log और cost_events) में structured logging, और step.wait_for_event durable-pause primitive देता है। यह Inngest primitive किसी Worker को wait के दौरान compute consume किए बिना घंटों या दिनों तक pause करने देता है। Paperclip approvals, जो Course Six में introduce हुए, separate mechanism हैं: approval एक decision record है, paused Worker नहीं। किसी approval को approve करने से कुछ भी auto-resume नहीं होता; काम continue करना explicit next step है। Course Eight जो change करता है वह governance decision है: routine approval जो पहले owner के attention का wait करता था, अब पहले owner की Identic AI field करती है, और सिर्फ consequential approvals owner तक पहुँचते हैं।

Course Six से (management plane): company Paperclip पर चलती है, एक open-source management layer (docs.paperclip.ing). यह workforce को org chart, authority envelopes (वे rules जो bound करते हैं कि हर Worker क्या कर सकता है), approval gates ($500 से ऊपर refunds के लिए human approval चाहिए), और shared system of record देता है। Worked example में Workers Tier-1 Support, Tier-2 Specialist, और Manager-Agent हैं। Course Eight Paperclip को एक बार और extend करता है, delegated-approval recognition path add करके।

Course Seven से (hiring API): Paperclip hiring को callable capability के रूप में expose करता है। Manager-Agent capability gap detect करके new hire propose कर सकता है, जो उसी approval gate से route होता है। Course Seven talent ledger भी introduce करता है (हर hire, eval, और retirement का SQL-queryable audit stream) और auto-approval policy primitive, जो envelope, budget, और eval-pack thresholds meet करने वाली routine hires को auto-approve करता है। Company ने चौथा Worker hire किया, Legal Specialist, जो Paperclip के http adapter के through Claude Managed Agents पर run कर रहा है।

Course Seven के बाद human owner के keyboard पर क्या बचा है: हर approval जो auto-approval thresholds meet नहीं करता। हर envelope-extension hire. हर refund जो auto-approval ceiling से ऊपर है। हर termination. हर CMA migration. हर standing-policy edit. यही bottleneck Course Eight हटाता है। Course में तीन terms बार-बार आते हैं: Worker (company ने hire किया AI agent), envelope (किसी Worker को क्या करने की अनुमति है उसकी bounds), और Claude Managed Agents / CMA (hosted-agent runtime जिसे Course Seven ने worked example के लिए use किया)।

अगर इन चार में से कोई भी shaky लगे, तो linked Course Five, Six, और Seven docs first principles तक वापस जाते हैं।

यह कहाँ fit होता है: cheat sheet

Course Eight के 15 Concepts और 7 Decisions, एक नज़र में:

#	Concept	Part	One-line description
1	AI-native company owner के attention पर scale होना बंद करती है	Why	Course Seven का math: 10 Workers पर रोज़ लगभग 5 से 10 approvals; 1,000 पर hundreds. अगर owner की ओर से कुछ act नहीं करता, owner bottleneck बन जाती है।
2	Identic AI का मतलब: Tapscott की framing concrete हुई	Why	पाँच properties: personalized, value-reflecting, extension-of-self, self-sovereign, persistent memory. Identic AI को किसी भी दूसरे "AI assistant" से अलग करती हैं।
3	Owner ही क्यों: workforce नहीं, customer नहीं	Why	दूसरे Identic AI use cases exist करते हैं (customer-side, employee-side), लेकिन AI-native company के लिए load-bearing case owner का है। Course एक चीज़ अच्छे से सिखाता है, तीन चीज़ें खराब तरह नहीं।
4	OpenClaw: यह असल में क्या है	Architecture	openclaw.ai से verified. Local machine runtime, chat-app reachability, persistent memory, open source, user-owned data.
5	Persistent memory और owner का local context	Architecture	Owner का accumulated judgment उसके filesystem पर कहाँ रहता है। docs.openclaw.ai का session primitive. क्या persist करता है, क्या नहीं।
6	Interface layer के रूप में chat apps	Architecture	OpenClaw owner तक web app के बजाय WhatsApp, Telegram, और Discord से क्यों पहुँचता है। Owner पहले से chat में है; Identic AI वहीं रहती है जहाँ owner है।
7	Trust-delegation problem	Governance	दो authorized principals (owner-human और owner की Identic-AI). Manager-Agent को verify करना है कि कौन act कर रहा है और उसके पास कौन सी authority है।
8	Local credentials से signed delegation	Governance	OpenClaw locally किससे sign कर सकता है। Paperclip management layer क्या verify करती है। Passkeys, hardware-backed keys, और owner की machine चोरी होने पर failure modes.
9	Two-envelope intersection	Governance	Owner का authority envelope ("मैं कुछ भी approve कर सकती हूँ") Identic AI के delegated envelope ("मैं routine decisions इन ceilings तक approve कर सकती हूँ") से मिलता है। उनका intersection execute होता है।
Part 4	7 lab Decisions	Lab	OpenClaw install करें, owner के context से onboard करें, Paperclip-integration skill बनाएँ, delegated approvals wire करें, end-to-end demonstrate करें, owner-overrides case handle करें, device-switch और stolen-laptop cases test करें।
10	Identic AI छह महीनों में क्या सीखती है	Audit	Owner के accumulated decision patterns. Judgment-learning loop. OpenClaw का session system इसे कैसे store करता है। कौन सा pattern teachable है और क्या owner के level पर रहता है।
11	Governance ledger: Identic AI का audit stream	Audit	Identic AI ने owner की ओर से क्या decide किया उसका parallel audit log. Owner इसे weekly वैसे ही पढ़ती है जैसे board Course Seven का talent ledger पढ़ता है।
12	जब Identic AI का judgment और owner diverge करते हैं	Audit	जब Identic AI कुछ ऐसा auto-approve करती है जिसे owner decline करती। Recalibration loop. यह healthy signal क्यों है, failure क्यों नहीं।
13	Self-sovereign memory: accumulated judgment long-term कहाँ रहता है	Open	तीन architectural options. May 2026 में क्या ships है। Tapscott जिसे "reinventing the AI stack" कहते हैं। जो solved नहीं है, उसके बारे में honest.
14	Pattern-matching से आगे value alignment	Open	Frontier: Identic AI owner की values (patterns के नीचे के rules) कैसे सीखती है, सिर्फ patterns themselves नहीं। Research preview, curriculum-ready नहीं।
15	आगे क्या है: Identic AI economy और eval discipline	Forward	Course Eight के end पर architectural completion; Course Nine eval discipline add करता है जो architecture को measurably trustworthy बनाता है।

क्या आप इस course के लिए ready हैं?

Prereq checklist

पाँच-item checklist. अगर कोई item shaky लगे, तो नीचे के linked refreshers आपको वहाँ पहुँचा देंगे।

1. आपने Courses Five से Seven complete किए हैं, या equivalent बनाया है: Inngest-wrapped Worker, approval primitive वाला Paperclip management layer, और working hiring API. Course Eight assume करता है कि company-side architecture मौजूद है। अगर नहीं है, पहले उसे build करें।
2. आप TypeScript और shell scripts पढ़ सकते हैं, भले ही fluent तरीके से लिख न पाते हों। Lab Paperclip-integration skill के लिए TypeScript और OpenClaw setup के लिए shell use करता है। आपका AI assistant (Claude Code या OpenCode) दोनों type करता है; आप brief, review, और approve करते हैं। Courses Three से Seven का briefing pattern unchanged जारी रहता है।
3. आपके पास Mac, Linux, या Windows machine है जिस पर आप OpenClaw install कर सकते हैं। OpenClaw का one-line installer (curl -fsSL https://openclaw.ai/install.sh | bash) पहली run पर macOS में Homebrew के लिए admin rights चाहता है। Lab real running OpenClaw instance पर depend करता है; Course Eight के लिए cloud-only shortcut नहीं है।
4. आपके पास कम से कम एक chat app है जिसे lab के लिए use कर सकते हैं: WhatsApp, Telegram, Discord, Slack, Signal, या iMessage. Course examples में Telegram default करता है क्योंकि OpenClaw docs ऐसा करते हैं, लेकिन choice आपकी है।
5. आप इस idea से comfortable हैं कि AI आपकी ओर से decisions ले, भले ही आप skeptical हों कि उसे कितनी दूर जाना चाहिए। Course का central technical move delegated authority है; अगर आप "AI मेरे नाम पर चीज़ें approve कर रही है" से आगे नहीं बढ़ सकते, lab land नहीं करेगा। Concept 12 failure cases को directly address करता है; decide करने से पहले उसे skim करें।

अगर पाँच में से कोई भी shaky लगे, continue करने से पहले linked refreshers से शुरू करें। Course dense है; prereqs इसे light feel कराते हैं।

यहाँ नए हैं? Course Eight नौ में आठवाँ है: on-ramp यह है

Course Eight Agent Factory track की architectural side close करता है; Course Nine eval-driven development की discipline add करता है जो architecture को measurably trustworthy production behavior में बदलती है। अगर ऊपर की पाँच prerequisites unfamiliar लगती हैं, तो backwards work करें: Course Seven: From Fixed to Dynamic Workforce direct prerequisite है (hiring API और management plane जिसे Course Eight extend करता है)। उससे पहले, इनसे होकर वापस आएँ:

• Course Six: From One Worker to a Workforce (Paperclip plus management plane)
• Course Five: From Digital FTE to Production Worker (Inngest plus operational envelope)
• Course Three: Build AI Agents (agent loop)
• अगर आप AI-assisted coding में बिल्कुल नए हैं, तो PRIMM-AI+ chapter. Course Eight हर page या दो पर Course Six और Seven concepts reference करता है; cold आना on-ramp complete करने से harder है।

अगर आप अभी on-ramp नहीं कर सकते लेकिन concepts follow करना चाहते हैं, तो full stack से कम में prerequisites fake कर सकते हैं:

• Paperclip Quickstart और Approvals page पढ़ें
• OpenClaw Getting Started पढ़ें
• Course हर Concept में जो prediction-then-run rhythm use करता है, उसके लिए PRIMM-AI+ Lesson 1 skim करें। इन substitutes के साथ, आप Parts 1 से 3 और Parts 5 से 6 conceptually follow कर सकते हैं। Part 4 lab के लिए working Paperclip install (Course Seven से) और working OpenClaw install (इस course से) दोनों चाहिए; shortcuts नहीं हैं।

Glossary: beginner के reference के लिए 26 terms (expand करने के लिए click करें)

Course Eight Agent Factory track के across vocabulary और Identic AI architecture के कई नए terms use करता है। Terms grouped हैं कि वे क्या describe करते हैं।

People और roles

• Owner / Founder / CEO: human principal जो AI-native company own करता है। Courses Six और Seven ने इसे "the board" कहा था जब decision governance-level था; Course Eight "owner" use करता है ताकि साफ़ रहे कि हम multi-person board नहीं, Identic AI वाले individual human की बात कर रहे हैं।
• Identic AI: Don Tapscott का term (HBR IdeaCast Ep. 1066, Feb 17, 2026, और उनकी book You to the Power of Two) ऐसे personalized AI के लिए जो अपने user की values reflect करती है, उसका context persist करती है, और उसका extension बनकर act करती है। पाँच properties: personalized, value-reflecting, extension-of-self, self-sovereign, persistent memory.
• Maya: Course Eight की worked-example owner. Courses Five से Seven में बनी customer-support company की founder और CEO. Course lab में उसके साथ चलता है।

OpenClaw primitives

• OpenClaw: open-source personal AI assistant (openclaw.ai). User की local machine पर चलता है; chat apps के through reachable; persistent memory; full system access; skills और plugins. Maya की Identic AI के लिए Course Eight का worked-example runtime.
• Skill: OpenClaw का extensibility primitive. Skill capability की unit है (Gmail पढ़ना, Spotify control करना, Paperclip से बात करना)। Skills user लिख सकता है, community contribute कर सकती है (ClawHub), या OpenClaw खुद लिख सकता है। Note: same word Paperclip के skill primitive जैसा है लेकिन concept अलग है; Paperclip skills Workers पर install होती हैं, OpenClaw skills user के local OpenClaw पर install होती हैं।
• Session: OpenClaw का persistent-memory primitive (docs.openclaw.ai/concepts/session). User के लिए time, devices, और chat apps के across accumulated context की unit. यही OpenClaw को stateless assistant नहीं, Identic AI बनाता है।
• Onboard: OpenClaw का setup process. openclaw onboard user को persona setup, model selection, chat-app integration, और initial skill installation से walk कराता है।
• Companion App: OpenClaw का macOS menubar app (May 2026 तक beta). Chat-app interaction का alternative; useful जब owner phone के बजाय desk पर हो।

Course Eight के architectural concepts

• Owner Identic AI: Identic AI की specific configuration जो AI-native company owner के governance delegate के रूप में act करती है। Course का central technical artifact. Maya का OpenClaw, Course Eight के pattern के अनुसार configured, उसकी Owner Identic AI है।
• Delegated governance: Course Eight का load-bearing primitive. वह pattern जिसके through Maya की Owner Identic AI Paperclip management layer से approval requests receive करती है, routine ones पर Maya का known judgment apply करती है, और सिर्फ consequential ones Maya के सामने surface करती है।
• Trust delegation: verification mechanism जो Paperclip management layer को Maya-the-human और Maya's-Identic-AI में फर्क करने देता है जब approval click आता है। दोनों authorized हैं; audit trail record करता है कि किसने act किया।
• Owner-authority envelope: Maya का personal authority envelope (Course Six के authority envelope concept जैसा). Maya खुद क्या approve कर सकती है। Identic AI's delegated envelope से अलग।
• Identic AI's delegated envelope: Maya की authority का वह subset जिसे उसकी Identic AI उसकी ओर से exercise कर सकती है। Maya set करती है, governance ledger में record होता है, और design से Maya की full authority से narrower होता है।
• Governance ledger: Course Seven के talent ledger का Course Eight parallel. Maya की Identic AI ने उसकी ओर से जो भी decision लिया उसका append-only audit stream. Maya इसे weekly पढ़ती है।
• Judgment-learning loop: Maya की Identic AI time के साथ उसके decisions का model कैसे accumulate करती है। Concept 10 mechanics cover करता है; Concept 14 value alignment का frontier cover करता है (patterns से values तक जाने की open research problem).
• Recalibration: वह loop जिसके through Maya अपनी Identic AI को correct करती है जब उसका judgment Maya से diverge करता है। Concept 12 इसे cover करता है। Recalibration events खुद governance ledger में record होते हैं।

Courses Three से Seven से (referenced, वहाँ ज़्यादा पूरी तरह defined)

• Worker: company के लिए काम कर रहा single AI agent. Course Six ने इसे define किया; Course Eight इसे throughout use करता है।
• Manager-Agent: वह Worker जो दूसरे Workers orchestrate करता है। Courses Six और Seven का protagonist; Course Eight में Maya की Identic AI का interlocutor.
• Paperclip: management layer जिसे Course Six ने introduce किया और Course Seven ने extend किया। Course Eight इसे एक बार और extend करता है, delegated-approval recognition path add करके।
• Authority envelope: Course Six का mechanism जो bound करता है कि Worker क्या कर सकता है। Course Eight analog owner-authority envelope plus delegated envelope split है।
• Activity log: हर workforce action का append-only audit stream. Course Eight के governance ledger से अलग (जो Identic AI का audit stream है)।
• Approval: Courses Six और Seven का governance gate. Paperclip में approval एक decision record है, paused process नहीं: board member या registered agent उस पर decision record करता है। (step.wait_for_event Course Five का Inngest durable-pause primitive है, separate mechanism; Paperclip approvals इससे wired नहीं हैं।) Course Eight बदलता है कि routine ones कौन field करता है: Maya से पहले Maya की Identic AI.

Thesis-level

• AI-native company: Courses Six और Seven का thesis-level term ऐसी company के लिए जिसका काम primarily AI Workers human governance के under करते हैं। Course Eight argue करता है कि इस definition का human governance part scale पर Owner Identic AI के बिना incoherent है।
• Invariant 2 / the delegate: Agent Factory thesis का Invariant 2: हर human को delegate चाहिए। ऐसा personal agent जो user की identity, context, और authority envelope hold करता है, और user की ओर से सारे downstream work broker करता है। Thesis OpenClaw को delegate के रूप में name करती है; Course Eight सिखाता है कि उस delegate को AI-native company owner के governance delegate के रूप में कैसे configure करें।
• Self-sovereign: Tapscott की commitment कि Identic AI user की owned होनी चाहिए, platform की नहीं। Course Eight यह commitment inherit करता है; OpenClaw shipped product है जो इसे operationalize करता है।

---

Part 1: owner bottleneck क्यों है

Courses Five से Seven की thesis थी कि AI-native company अपनी workforce को indefinitely scale कर सकती है। Hiring API callable है। Approval primitive reusable है। Talent ledger queryable है। Architecture में कुछ भी company को अपना दसवाँ Worker, सौवाँ Worker, या हज़ारवाँ Worker hire करने से नहीं रोकता।

लेकिन कुछ architecture को cap करता है, और Course Seven ने इसे implicit छोड़ा। हर consequential decision अभी भी human owner के attention तक route होता है। जो company 1,000 Workers hire कर सकती है लेकिन एक human से उम्मीद करती है कि वह 1,000 Workers जितने approval threads पढ़े, वह scale नहीं कर रही। वह bottleneck को "recruiting" से "owner attention" पर shift कर रही है। Part 1 इस argument को concrete बनाता है, फिर architectural response introduce करता है: owner की Identic AI. तीन Concepts.

Concept 1: AI-native company hiring API पर नहीं, owner के attention पर scale होना बंद करती है

यह course का सबसे heavy concept है क्योंकि बाकी सब इसी पर rest करता है। अगर यहाँ का argument land नहीं करता, तो Course Eight का बाकी हिस्सा personal AI के बारे में forward-looking speculation जैसा पढ़ता है। अगर argument land करता है, तो Course Eight का बाकी हिस्सा उस concrete problem को solve करता हुआ पढ़ता है जिसे पिछले तीन courses ने create किया।

Argument structural है, लेकिन इसे देखने का सबसे आसान तरीका numbers लगाना है। हम Course Seven का actual worked example use करेंगे: Courses Five से Seven में बनी customer-support company, जिसके पास Course Seven के end तक चार Workers हैं (Tier-1 Support, Tier-2 Specialist, Manager-Agent, और Course Seven के Decision 4 में अभी hire हुआ Legal Specialist)। Maya, company की founder और CEO, human owner है। Course Seven के end तक हर consequential approval अभी भी Maya के phone को ping करता है।

चार Workers पर math. Course Seven workforce के साथ typical week में Maya के phone पर क्या आता है, यह Courses Six और Seven के operational examples से realistic rates use करके count करें।

Approval source	Per Worker per week	At 4 Workers
Envelope ceiling से ऊपर refund (Course Six का refund_max=$500)	~2	~8
Envelope-extension hire (Course Seven का Concept 8: auto-approval bypass नहीं कर सकता)	~0.1	~0.4
Termination decision	~0.05	~0.2
Budget override (Worker ने अपना monthly ceiling hit किया)	~0.25	~1
CMA migration या substrate change	~0.05	~0.2
Standing-policy edit (new auto-approval rule)	~0.5	~2
Total per week		~12

हफ़्ते में बारह approval events. Business day में लगभग दो। Maya meetings के बीच अपने phone पर इसे handle कर सकती है। Owner-attention cost real है लेकिन manageable है। यही वह regime है जिसके लिए Course Seven की architecture design की गई थी।

चालीस Workers पर math. अब मान लें कि Maya की company छह महीनों में grow हो गई है। Manager-Agent ने आठ और capability gaps detect किए और हर एक के लिए Workers hire किए: Billing Specialist, Refund Analyst, Onboarding Worker, Churn-Risk Worker, अलग product lines के लिए तीन और Tier-2 Specialists, और Senior Legal Reviewer. Course Seven के Concept 9 की auto-approval policy ज़्यादातर Tier-1 burst hires cover करती है। अब तक ठीक है। लेकिन हर Worker consequential approvals की अपनी stream generate करता है।

At 40 Workers	Per week
Envelope ceiling से ऊपर refunds	~80
Envelope-extension hires	~4
Termination decisions	~2
Budget overrides	~10
CMA migrations / substrate changes	~2
Standing-policy edits	~20
Total per week	~118

Business day में लगभग 17. Maya अब रोज़ तीन से चार घंटे approval threads पढ़ने में खर्च कर रही है। यही वह regime है जहाँ Maya पूछना शुरू करती है कि queue triage करने के लिए human chief-of-staff hire करना चाहिए या नहीं। यह tell है। Architecture original thesis fail करना शुरू कर रही है: Maya से workforce scale करने के लिए humans add करने को कहा जा रहा है।

चार सौ Workers पर math. मान लें Maya grow करती रहती है। Month 18 तक company 400 Workers चलाती है, जो AI-native company के लिए अभी भी छोटी है, लेकिन Course 5-7 architecture जहाँ stress-tested थी उससे काफी आगे है।

At 400 Workers	Per week
Envelope ceiling से ऊपर refunds	~800
Envelope-extension hires	~40
Termination decisions	~20
Budget overrides	~100
CMA migrations / substrate changes	~20
Standing-policy edits	~200
Total per week	~1,180

Business day में लगभग 170 approval events. Maya चाहे जितनी तेज़ scroll करे, वह रोज़ 170 approval threads नहीं पढ़ सकती। Architecture काम करना बंद कर चुकी है। Hiring loop अब owner जितना process कर सकती है, उससे ज़्यादा approval traffic generate कर रहा है। Maya owner-attention bottleneck से टकरा चुकी है।

Scaling math bottleneck को number देता है: AI-native company किसी दूसरे scaling constraint से बहुत पहले, 10 और 40 Workers के बीच कहीं अपना owner-attention ceiling hit करती है।

उसके पास architectural responses क्या हैं? ठीक तीन। Course को चाहिए कि third one (Identic AI) novelty के बजाय answer की तरह पढ़े, इससे पहले आप यह internalize करें कि उनमें से दो wrong हैं।

Wrong response A: ज़्यादा aggressively auto-approve करना। Maya Course Seven के Concept 9 की auto-approval policy को expand करके और categories cover कर सकती है। अभी policy $250/month envelope के under Tier-1 burst hires auto-approve करती है; वह ceiling $1,000/month तक raise कर सकती है, या refund decisions को $2,000 तक include कर सकती है। इससे queue कम होगी। यह उस safety property को abandon भी करेगा जिस पर पूरी seven-invariant thesis बनी है। Course Seven ने envelope-extension check को auto-approval surface से बाहर इसलिए रखा था (Concept 8) क्योंकि Worker के पास ऐसी कोई भी authority जो पहले किसी Worker के पास नहीं थी वह decision है जिसे human को consciously लेना होगा। ज़्यादा aggressively auto-approve करना उस commitment को उलट देता है। यह कहता है: हम scale पर govern करने की मेहनत नहीं करेंगे, इसलिए declare करेंगे कि scale को governance चाहिए ही नहीं। यह AI-native version है unreviewed pull-request culture का। यह तब तक काम करता है जब तक नहीं करता।

Wrong response B: approval pool में humans add करना। Maya approvals triage करने के लिए human chief-of-staff hire कर सकती है, या दो co-founders को additional approvers बना सकती है। इससे per-person queue कम होगी। यह वही org-chart hierarchy reintroduce भी करेगा जिसे AI-native companies को flatten करना था। Course Six का पूरा architectural argument था कि Manager-Agent middle-management coordination layer absorb करता है; अगर Maya अब approvals handle करने के लिए Manager-Agent के ऊपर human management layer add करती है, तो उसने वही company shape rebuild कर दी जिसे Courses 5-7 ने तीन courses में remove किया था। Worse: वह जितने humans add करती है, हर एक का वही scaling ceiling है जो उसका है। दो co-founders business day में 17 के बजाय लगभग 30 approvals process करते हैं। तीन लगभग 50 handle करते हैं। Architecture अभी भी per human workforce के लगभग 10 गुना पर cap होती है; बस थोड़ा higher number पर cap होती है। AI-native company को humans governance loop में add करके scale नहीं किया जा सकता। अगर किया जा सकता, तो वह AI-native नहीं होती।

Right response: owner की Identic AI. Maya के hardware पर running personal AI delegate, जिसने Maya के past 200 decisions से उसके approval patterns सीखे हैं। जब new approval request आती है, Identic AI या तो उसे autonomously resolve करती है (जब Maya का अपना pattern clear हो और request routine हो) या उसे Maya के सामने surface करती है (जब request novel, consequential, या उन patterns के बाहर हो जिन्हें Identic AI ने confidently सीखा है)। Maya का attention अब सिर्फ उन decisions पर खर्च होता है जिन्हें सच में human judgment से benefit मिलता है, और workforce bottleneck recreate किए बिना grow कर सकती है।

ध्यान दें यह response क्या नहीं करता। यह उस policy के under auto-approve नहीं करता जिसे Maya ने एक बार लिखा और भूल गई। यह Maya का judgment apply करता है, जिसे Identic AI ने Maya को decisions लेते देखकर accumulate किया है। यह authority delegate नहीं करता: Maya principal रहती है; Identic AI उसकी explicit consent के साथ उसकी ओर से act करती है, और हर action audit stream में record होता है जिसे Maya review करती है। Owner loop में रहती है; routine traffic पर owner का attention loop में नहीं रहता।

यही architectural primitive thesis के Invariant 2 में name है: delegate. Thesis इसे abstractly कहती है ("हर human को delegate चाहिए जो उनका context hold करे, उनका judgment represent करे, उनका authority envelope carry करे, और उनकी ओर से सारे downstream work broker करे")। Course Eight इसे AI-native company के owner के लिए concretely operationalize करता है। इसके बिना, पिछले छह operationalized invariants (engines, system of record, nervous system, management layer, hiring API) कुछ dozen की workforce पर cap हो जाते हैं। इसके साथ, architecture owner के calendar के size पर नहीं, workforce के size पर scale करती है।

PRIMM: Predict

आप Maya हैं। Month nine में आपकी company के पास 80 Workers हैं। Course Seven के Concept 9 की auto-approval policy Tier-1 burst hires cover करती है। Manager-Agent के gap-detection signals new pattern पर fire करते हैं: तीन हफ़्तों तक Spanish-language customer questions का unexpected volume. Manager-Agent Spanish-Language Tier-2 Specialist के लिए hire proposal draft करता है। Proposed authority envelope existing English-language Tier-2 जैसा ही है (envelope-extension check needed नहीं)। Proposed budget $800/month है, Course Seven के auto-approval ceiling के अंदर। Eval pack pass है।

दो predictions, आगे पढ़ने से पहले paper पर अलग-अलग लिखें:

1. Course Seven की auto-approval policy के under (Course Seven का Concept 9, जो सिर्फ envelope, budget, और eval-pack thresholds check करता है): क्या यह hire Maya को involve किए बिना auto-approved होगा? Yes या no predict करें।
2. Course Eight जो सिखाएगा उसके under (Owner Identic AI Maya का accumulated judgment apply कर रही है): क्या Maya की Identic AI इसे auto-approve करती है, या Maya के सामने surface करती है? Surface या auto-approve predict करें।

अगर आपकी दोनों predictions same हैं, तो आपने अभी वह distinction नहीं देखा जिस पर Course Eight बना है। अगर वे अलग हैं, तो आपने देख लिया है। दोनों ठीक हैं; आगे पढ़ें।

उत्तर:

1. Yes, Course Seven की auto-approval policy fire करती है। Hire policy के stated criteria fit करता है: known envelope, eval pack pass, budget ceiling के अंदर। Policy के पास यह जानने का तरीका नहीं है कि यह hire routine burst-capacity hire से अलग है।
2. Owner Identic AI इसे Maya के सामने surface करती है, इसलिए नहीं कि Course Seven की policy wrong है, बल्कि इसलिए कि Identic AI judgment की ऐसी class encode करती है जिसे Course Seven की policy नहीं कर सकती। Spanish-language support Maya के market का strategic expansion है, सिर्फ additional capacity नहीं। Maya शायद सोचना चाहे कि क्या company bilingual support को contractually commit करने के लिए ready है, क्या privacy policy और terms of service को Spanish translations चाहिए, क्या यह hire broader product direction signal करता है।

Distinction rule vs. judgment है। Rule एक बार encode होकर uniformly apply हो सकता है। Judgment owner के past decisions से सीखा जाता है और per-situation apply होता है। Course Seven की policy rule है; Owner Identic AI judgment-applier है। दोनों valuable हैं: rule 90% routine cases को zero owner-attention cost पर handle करता है, judgment remaining 10% को handle करता है जिन्हें सच में human-trained pattern से benefit मिलता है। Course आपको यही build करना सिखाएगा।

निचोड़: Concept 1 का math workforce-vs-attention bottleneck को number देता है। AI-native company किसी दूसरे scaling constraint से काफी पहले, 10 और 40 Workers के बीच कहीं owner-attention ceiling hit करती है। Invariant 2 जिस delegate primitive को name करता है, वही cap हटाता है; decisions की संख्या घटाकर नहीं, बल्कि routine ones को owner के actual attention के बजाय owner के known judgment से route करके। दो architectural responses wrong हैं (ज़्यादा aggressively auto-approve करना; loop में humans add करना) और सिर्फ एक right है (delegate). Math ही case है कि क्यों।

Concept 2: Identic AI का मतलब क्या है: Tapscott की framing concrete बनाना

Bottleneck solve करने वाला architectural primitive Identic AI है, जैसा Don Tapscott ने अपने HBR IdeaCast interview (Episode 1066, February 17, 2026) और अपनी book You to the Power of Two: Redefining Human Potential in the Age of Identic AI में define किया। Course Eight Tapscott की vocabulary inherit करता है क्योंकि हम जो build कर रहे हैं उसके लिए यह सबसे clean available framing है, और क्योंकि इसे adopt करने से course एक current management-discourse conversation से जुड़ता है, नया term coin करने से नहीं।

Tapscott की definition, transcript से verbatim:

"the rise of intelligent companions that really learn who we are, and they reflect our values and ultimately operate as extensions of ourselves... a subset of agentic AI, we call them identic AI"

वह पाँच properties name करते हैं, जिन पर Course Eight बार-बार लौटेगा:

1. Personalized: single individual का agent, workforce agent नहीं। Maya की Identic AI Maya की है। Shared instance नहीं, team account नहीं, organizational tier नहीं। Unit है one human, one Identic AI.
2. User की values और judgment reflect करती है: user के documents, decisions, communications, accumulated context पर trained. Identic AI user के name से configured generic AI assistant नहीं है; यह AI है जिसने time के साथ user को सीखा है।
3. Extension of self: user जिस tool को invoke करता है, वैसा नहीं; extended cognition जैसा feel होना चाहिए। Tapscott की framing में: "it's becoming a part of the human experience." Maya के case में: वह Paperclip की तरह "अपनी Identic AI में log in" नहीं करती। Identic AI उसकी chat apps में, उसके phone पर, उसके menu bar में reachable है; वह तब act करती है जब Maya act करती है; वह जानती है कि Maya किस पर काम कर रही है।
4. Self-sovereign: user-owned, platform-owned नहीं। Transcript में Tapscott का emphasis: "identic AI needs to be self-sovereign. We need to own our own superintelligence." Accumulated context, learned patterns, judgment model: ये user के हैं। Platform इन्हें hostage नहीं रखता। User devices बदलता है, employers बदलता है, chat-app preferences बदलता है, फिर भी ये survive करते हैं।
5. Persistent memory: user का knowledge continuously accumulate करती है। Transcript से Tapscott का example: "For digital Don, for example, I've input about 500 documents, everything I could find that I've written my speeches, my PowerPoints, my books and articles and interviews and all kinds of stuff like that. And it's learning about me and how I view things and how I think about things."

सभी पाँच properties साथ मौजूद होनी चाहिए; पाँचवीं, self-sovereign, सबसे आसानी से abandon होती है और वही Concept 4 में runtime choice determine करती है।

ये पाँच properties discriminating definition हैं। वे Identic AI को इनसे अलग करती हैं:

• General-purpose AI assistants (जिनमें persistent memory नहीं होती और user का specific judgment reflect नहीं होता)
• Workforce agents (जो company के owned होते हैं, individual के नहीं; Course 5-7 के Workers workforce agents हैं)
• Customer-side AI agents (जो user serve करते हैं लेकिन आम तौर पर platform-owned और platform-hosted होते हैं; वे self-sovereign property fail करते हैं)
• Learning के बिना personal assistants (meetings schedule करने वाला chat-app bot helpful है लेकिन user का judgment time के साथ accumulate नहीं करता)

जिस discriminator को most readers under-weight करते हैं, वह self-sovereignty है। Tapscott उस पर repeatedly लौटते हैं क्योंकि उनके view में AI industry की default trajectory platform-owned Identic AI की तरफ और user-owned Identic AI के against है। Transcript से: "The biggest question for me is who's going to own digital Adi? Mark Zuckerberg? Google? This is an extension of you and your intelligence. And if they own it, that's a big problem." अगर Maya की Identic AI ऐसे platform पर hosted है जो उसके judgment patterns पढ़ सकता है, modify कर सकता है, downrank कर सकता है, या उसका access revoke कर सकता है, तो उसकी Identic AI असल में उसकी ओर से act नहीं कर रही। वह Maya के data के साथ platform की ओर से act कर रही है। Course Eight self-sovereign property को non-negotiable architectural property मानता है। यही commitment Concept 4 में runtime choice determine करता है (OpenClaw, क्योंकि यह Maya के hardware पर चलता है और उसका context उसके filesystem पर store करता है, opt-in के रूप में नहीं, default architecture के रूप में)।

Identic AI Course Eight के specific use case पर कैसे map होती है। Course Eight general-purpose Identic AI नहीं सिखा रहा। यह एक specific configuration सिखा रहा है: Owner Identic AI, ऐसी Identic AI जो AI-native company के owner के governance delegate के रूप में act करने के लिए configured है। दूसरे valid Identic AI configurations exist करते हैं (personal Identic AI जो आपका household चलाती है, calendar manage करती है, email draft करती है; Tapscott का "digital Don" example इसी में fit होता है) और Course Eight Concept 15 में broader Identic AI economy के रूप में उन पर briefly लौटेगा जिसे यह architecture enable करती है। लेकिन course का load-bearing example Maya की Identic AI है, उसकी governance delegate capacity में। यही capacity AI-native company के लिए Invariant 2 operationalize करती है, और Course Eight यही capacity सिखाता है।

चार lower-numbered properties (personalized, value-reflecting, extension-of-self, persistent memory) operational requirements हैं; पाँचवीं (self-sovereign) architectural commitment है। पाँचवीं के बिना, बाकी चार फिर भी काम करती हैं, लेकिन वे owner के लिए नहीं, owner के against काम करती हैं। Course Eight पाँचों सिखाता है, और पाँचवीं को load-bearing मानता है।

निचोड़: Don Tapscott की framing में Identic AI personalized AI है जो user की values reflect करती है, time के across उनका context persist करती है, उनका extension बनकर act करती है, और platform नहीं, user के owned रहती है। पाँच properties; पाँचवीं (self-sovereign) सबसे आसानी से abandon होती है और course उस पर compromise नहीं करता। Owner Identic AI वह specific configuration है जिसे Course Eight सिखाता है: AI-native company owner के governance delegate के रूप में configured Identic AI.

Concept 3: owner ही क्यों: workforce नहीं, customer नहीं

इस point पर reasonable reader पूछ सकता है: अगर Identic AI इतनी important है, तो course सिर्फ owner की क्यों सिखा रहा है? Customer-side Identic AI, employee-side Identic AI, peer-to-peer Identic AI interactions, या broader Identic AI economy क्यों नहीं? जवाब है कि Course Eight deliberate scope choice करता है, और reasoning मायने रखती है।

AI-native company से relevant Identic AI use case की कम से कम चार categories हैं:

Use case	किसकी Identic AI	क्या करती है	May 2026 में maturity
Owner / governance delegate	AI-native company का owner	Approval traffic pre-filter करती है, owner का judgment apply करती है, consequential decisions surface करती है	Shipped (OpenClaw plus वह pattern जो Course Eight सिखाता है)
Customer-side personal AI	Individual customer	Customer की ओर से companies से interact करती है, customer का context hold करती है, purchases करती है	Partially shipped (OpenClaw exists; companies अभी signed customer-Identic-AI requests को normal interaction channel के रूप में accept नहीं करतीं)
Employee-side delegate	AI-native company का employee	Emails draft करती है, meetings के लिए prepare करती है, workforce द्वारा delegated employee का अपना work manage करती है	Partially shipped (OpenClaw यह कर सकता है; company workflows के साथ integration vary करता है)
Peer-to-peer / Identic AI economy	दो individuals की Identic AIs directly interact कर रही हैं	Deals negotiate करना, schedule करना, humans को loop में रखे बिना coordinate करना	Speculative; Tapscott का "infinite number of vice presidents" end-state

Course Eight पहला one (owner's) सिखाता है और बाकी नहीं सिखाता। तीन reasons:

First, Concept 1 का load-bearing argument specifically owner के बारे में है। Scaling-impossibility math customers या employees पर उसी तरह apply नहीं होता। Customer के पास Identic AI न हो तो उसे mild inconvenience है; company workforce अभी भी traditional channels से उसे serve कर सकती है। Employee के पास Identic AI न हो तो employees जैसे हमेशा काम करते आए हैं वैसे ही काम करता है; productivity कम हो सकती है लेकिन company function करती है। सिर्फ owner का bottleneck company को scale होने से रोकता है। Course का claim, कि Owner Identic AI AI-native company के लिए Invariant 2 operationalize करती है, specifically इसलिए true है क्योंकि owner का case वह है जिसके बिना architecture incoherent हो जाती है। बाकी cases valuable हैं लेकिन load-bearing नहीं।

Second, customer-side Identic AI use case अभी fully shipped नहीं है, और architecture में open gaps हैं जिन्हें Course Eight honestly close नहीं कर सकता। Tapscott का transcript customer-side use case की ओर gesture करता है ("a doctor that's been to every medical school in the world, your tutor that's literally a know-it-all"). लेकिन stranger की Identic AI और company की workforce के बीच trust-delegation owner के case से कठिन open problem है। Maya के साथ, owner-authority envelope और Identic AI का delegated envelope दोनों Maya खुद configure करती है; trust model one-party है। Arbitrary customer के साथ, company को untrusted boundary के across identity, authority, और authorization verify करना होता है; trust model multi-party है और कोई shared root नहीं। Courses 5-7 ने cross-party trust का वह level भी नहीं सिखाया; Course Eight में उसे सिखाने के लिए ऐसे primitives introduce करने पड़ेंगे जिन पर बाकी track depend नहीं करता। Honest pedagogy: load-bearing case अच्छे से सिखाएँ; broader case को open frontier के रूप में gesture करें।

Third, जो course चारों cases सिखाने की कोशिश करता है, वह कोई भी अच्छे से नहीं सिखाता। Courses 3-7 के across track का pattern है एक चीज़ deeply सिखाना, complete worked example के साथ, और adjacent cases पर sidebars और forward-look section में gesture करना। Course Six ने workforce सिखाई, broader AI-native organization नहीं। Course Seven ने hiring API सिखाई, full lifecycle including outside counsel offboarding नहीं। Course Eight Owner Identic AI सिखाता है, broader Identic AI economy नहीं। Concept 15 closing forward-look के रूप में broader picture पर लौटता है, customer-side, employee-side, और peer-to-peer cases को next architectural frontiers के रूप में name करता है। लेकिन lab, worked example, 15 teaching Concepts: सब Maya के case के बारे में हैं।

Course Eight ने right scope choice की या नहीं, इसका useful test: अगर reader Course Eight finish करके अपनी AI-native company में Maya की Owner Identic AI successfully set up करता है, तो architecture scale पर काम करती है। Owner का attention अब bottleneck नहीं है। Courses 3-7 के seven invariants अब complete हैं। अगर वही reader Owner Identic AI patterns को दूसरे use cases तक extend करना चाहता है (अपने product में customer-side Identic AI, अपनी team के लिए employee-side delegate), तो उसके पास architectural tools हैं। Course Eight name करता है कि हर extension कहाँ shipped है और कहाँ open. Course load-bearing case पूरी तरह deliver करता है और बाकी को honestly name करता है। यही pedagogical commitment है।

PRIMM: Predict

Course Eight Owner Identic AI सिखाता है, बाकी तीन use cases नहीं। नीचे हर option एक real argument है जो कोई इस scope choice के लिए दे सकता है। आगे पढ़ने से पहले predict करें कि course की actual reasoning कौन सी है। Prediction का point यह है कि इनमें से एक से ज़्यादा defensible हैं; आपको वह चुनना है जो specifically course के central argument से match करता है।

(a) Owner का case ही ship होने के लिए mature है: customer-side और peer-to-peer Identic AI को cross-party trust primitives चाहिए जो May 2026 में exist नहीं करते, इसलिए course आज buildable चीज़ सिखाता है। (b) Owner का case load-bearing है: Concept 1 का scaling math दिखाता है कि Owner Identic AI के बिना Courses 5-7 की architecture खुद कुछ dozen Workers के बाद incoherent हो जाती है। बाकी cases valuable हैं लेकिन company उनके बिना भी function करती है। (c) Owner का case pedagogically simplest है: यह one-party trust model है (Maya दोनों envelopes खुद configure करती है), इसलिए harder cases से पहले trust-delegation primitive सिखाने की cleanest जगह है। (d) Owner का case सबसे clear commercial demand रखता है: AI-native company owners वे buyers हैं जो governance delegate के लिए पहले pay करेंगे, इसलिए course market को सिखाता है।

उत्तर: (b). चारों में कुछ true है, इसलिए यह real prediction है, reading check नहीं। (a) true है (Concept 3 customer-side maturity के बारे में यही कहता है) लेकिन यह scope choice का consequence है, reason नहीं। (c) true है (Concept 3 one-party trust model को teaching advantage name करता है) लेकिन फिर भी यह benefit है, load-bearing reason नहीं। (d) शायद true हो लेकिन course commercial-demand argument नहीं करता। Course की actual reasoning (b) है: owner का bottleneck वह है जिसकी absence architecture को break करती है। Concept 1 का math case है। Customer-side, employee-side, और peer-to-peer cases valid Identic AI configurations हैं, लेकिन company उनके बिना function करती है; सिर्फ owner का case Courses 5-7 को scale पर incoherent बनाता है। Course Eight load-bearing case पूरी तरह सिखाता है; Concept 15 बाकी को open frontier के रूप में name करता है।

निचोड़: Course Eight एक specific Identic AI configuration, Owner Identic AI, सिखाता है क्योंकि वही use case है जिसकी absence Courses 5-7 की architecture को scale पर incoherent बनाती है। दूसरे Identic AI cases (customer-side, employee-side, peer-to-peer) valuable हैं लेकिन AI-native company के scaling argument के लिए load-bearing नहीं। Course load-bearing case पूरी तरह deliver करता है और बाकी को Concept 15 में honestly name करता है।

---

Part 2: OpenClaw runtime

Part 1 ने problem name की और scope commit किया। Part 2 runtime, OpenClaw, introduce करता है, और walk through करता है कि यह असल में क्या है, कहाँ रहता है, और Maya इससे कैसे बात करती है। तीन Concepts: OpenClaw क्या है, official source से verified (Concept 4); Maya का accumulated context उसके filesystem पर कहाँ रहता है (Concept 5); और OpenClaw ने interface layer के रूप में web app के बजाय chat apps क्यों चुनीं (Concept 6)।

Concept 4: OpenClaw, यह असल में क्या है

OpenClaw वह runtime है जिसके against Course Eight सिखाता है। Concepts 7 से 15 के architectural patterns समझ आने से पहले, आपको OpenClaw का clean mental model चाहिए कि यह असल में क्या है, openclaw.ai और docs.openclaw.ai से verified, earlier personal-AI products पर pattern-match करके नहीं।

Verified facts, directly official site और docs से:

• User की local machine पर चलता है। Mac, Windows, या Linux. Installer है curl -fsSL https://openclaw.ai/install.sh | bash या npm i -g openclaw. Install के बाद, openclaw onboard setup walk करता है।
• Open source. github.com/openclaw/openclaw. MIT-licensed. User पढ़ सकता है, fork कर सकता है, modify कर सकता है, और self-host कर सकता है।
• उन chat apps से reachable है जिन्हें user पहले से use करता है। OpenClaw openclaw.ai/integrations पर 50+ integrations list करता है, जिनमें 15+ chat channels शामिल हैं (WhatsApp, Telegram, Discord, Slack, Signal, iMessage, और more)। User new app install नहीं करता; वह अपनी existing chat app में OpenClaw को message करता है।
• Persistent memory. Site की headline phrase: "Remembers you and becomes uniquely yours. Your preferences, your context, your AI." session primitive (docs.openclaw.ai/concepts/session) accumulated context की unit है।
• User की machine पर full system access. Files read और write करना, shell commands run करना, scripts execute करना (docs.openclaw.ai/bash). Full access या sandboxed: user की choice.
• Browser control. Web browse कर सकता है, forms fill कर सकता है, किसी भी site से data extract कर सकता है (docs.openclaw.ai/browser).
• Skills और plugins. Community skills (clawhub.ai) या user-built skills (docs.openclaw.ai/skills) से extensible. OpenClaw अपनी skills भी लिख सकता है।
• Model-agnostic. Anthropic, OpenAI, या local models. User onboarding के दौरान pick करता है।
• Companion app. Chat-app interface के alongside desktop access के लिए macOS menubar app (May 2026 में beta).

Institutional signals जिन्हें note करना worth है। OpenClaw का सबसे load-bearing signal reputational नहीं, structural है: project MIT license के under open source है। वह license continuity guarantee है, क्योंकि github.com/openclaw/openclaw पर codebase को कोई भी fork और self-host कर सकता है, चाहे project stewards के साथ कुछ भी हो। License के अलावा, project की बहुत बड़ी GitHub following है (hundreds of thousands of stars), और major-vendor sponsorship है। May 2026 तक sponsor list में OpenAI, GitHub, NVIDIA, Vercel, और Convex शामिल हैं। Sponsor list shift होने वाला fact है, इसलिए इसे load-bearing claim के बजाय as-of-May-2026 example मानें। Founder, Peter Steinberger, early 2026 में OpenAI join कर चुके हैं जबकि project open-source effort के रूप में continue करता है। Specific counts और sponsor details को authoritative quote करने से पहले openclaw.ai और project GitHub पर verify करना चाहिए।

Course Eight के लिए ये signals क्यों matter करते हैं। Course Eight की central architectural commitment self-sovereignty है: Maya का accumulated judgment उसका है, platform का नहीं। किसी भी open-source personal-AI project का risk है कि वह shut down हो जाए, closed-source product में acquire हो जाए, या अपना data-ownership model pivot कर दे। उस risk के against सबसे strong signal MIT license itself है। Institutional backing (major sponsor list, founder का OpenAI hire) दिखाता है कि project के पास resources और industry stake हैं, लेकिन sponsorship और hiring दोनों change हो सकते हैं। Open source durability guarantee है जो stewards change होने पर भी survive करती है: project direction shift हो जाए तब भी codebase fork और self-host हो सकता है, और Maya का runtime continue कर सकता है। इन signals में से कोई long-term durability का proof नहीं है। साथ में, MIT license को anchor बनाकर, वे OpenClaw को May 2026 में curriculum build करने के लिए सबसे credible self-sovereign Identic AI runtime बनाते हैं।

Mental model: OpenClaw chatbot से कैसे अलग है। ChatGPT या Claude.ai से OpenClaw पर आने वाले reader का mental model होता है "chat window में AI जिसे मैं कुछ पूछना चाहूँ तो open करता हूँ।" Identic AI के लिए यह model तीन specific तरीकों से wrong है:

Mental model	Chatbot	Owner Identic AI (OpenClaw)
AI कब act करता है?	सिर्फ जब user explicitly app open करके type करता है	Continuously, background में; standing instructions होने पर proactively; heartbeat checks के through
AI कहाँ रहता है?	उस tab में जिसे user open करता है	User की existing chat apps (WhatsApp, Telegram) और user के filesystem में
AI क्या remember करता है?	Within-conversation context जो sessions के बीच discard हो जाता है	सभी interactions, devices, और time के across persistent session
कौन initiate करता है?	हर बार user	दोनों parties: user ask कर सकता है, और AI भी proactively चीज़ें surface कर सकती है

Fourth row सबसे important और miss करना सबसे आसान है। Chatbot में, user हमेशा initiator होता है। Identic AI में, AI भी initiator है। Claudia किसी भी समय Maya को Telegram message भेज सकती है ("customer की refund request अभी आई है; हमारे patterns के आधार पर, यह वह है जिसे मैं auto-approve करती। Proceed करने के लिए OK?"). यही bidirectional initiation governance delegation के लिए Identic AI को useful बनाता है। ऐसा chatbot जिसे Maya को open करके consult करना पड़े, approval threads pre-filter नहीं कर सकता; ऐसी Identic AI जो जरूरत पड़ने पर Maya को message करती है, कर सकती है।

Concretely, पहली session कैसी दिखती है। User जो curl -fsSL https://openclaw.ai/install.sh | bash और फिर openclaw onboard run करता है, docs.openclaw.ai/getting-started के अनुसार लगभग इस sequence से गुजरता है:

1. Model pick करें। Anthropic Claude, OpenAI GPT, या local model. (Course Eight के लिए, हम Claude opus-4-7 को default use करेंगे।)
2. अपने OpenClaw को नाम दें। Users अपनी Identic AI को "Claudia," "Jarvis," "Brosef," जैसा नाम देते हैं और persona tone pick करते हैं। Naming Identic AI को service के बजाय entity जैसा feel कराती है: एक बार नाम मिल जाए तो users conversation में अपने OpenClaw को नाम से refer करते हैं।
3. Primary chat app pick करें। Telegram (सबसे common, easiest bot setup), WhatsApp, Discord, Signal, iMessage, या Slack. User अपनी chat app में bot create करता है (उदाहरण के लिए Telegram पर @BotFather से) और token OpenClaw में paste करता है।
4. Initial skill installation. OpenClaw पूछता है कि user अपनी Identic AI को किसमें अच्छा बनाना चाहता है: calendar management, email, code, governance, all of the above. Selected skills clawhub.ai (community skills marketplace) से install होती हैं। Course Eight के purpose के लिए, default skills में कोई Paperclip integration handle नहीं करती; हम Decision 3 में वह लिखेंगे।
5. First conversation. User अपनी chat app open करता है, अपना OpenClaw bot find करता है, "hello" type करता है। OpenClaw chosen persona में respond करता है, और उस moment से Identic AI user के normal communication flow में reachable है। अलग app open करने की ज़रूरत नहीं।

पूरा onboard 5 से 10 minutes लेता है। Course Eight जिन architectural commitments पर depend करता है, local filesystem storage, persistent session, chat-app reachability, वे install में baked हैं, per-user configure नहीं होते।

Maya के runtime के रूप में OpenClaw क्यों, alternative क्यों नहीं:

Alternative	Course Eight के लिए क्यों नहीं
Claude Agent SDK + custom Identic AI	आप build कर सकते हैं, लेकिन persistence, chat-app integration, skill management, और onboarding खुद assemble करते हैं। OpenClaw ये सभी ship करता है।
OpenAI Agents SDK + custom Identic AI	वही problem, plus architecture personal-AI shape से ज़्यादा cloud-workforce shape के करीब है।
Hosted SaaS personal AI (उदाहरण के लिए hypothetical "Claude for Personal")	Self-sovereign property fail करता है। Maya का accumulated judgment ऐसे platform पर रहता है जो उसे read, modify, या revoke कर सकता है। Tapscott की central commitment violate होती है।
Inngest + custom front-end से roll-your-own	Possible, लेकिन course Identic AI सिखाने के बजाय plumbing सिखाने में खर्च हो जाएगा। Course की value architectural patterns में है, runtime mechanics में नहीं।

OpenClaw हर axis पर requirements fit करता है: यह ships करता है, open source है, user का context default रूप से user के filesystem पर store करता है, और user तक उन chat apps से पहुँचता है जिनमें वह पहले से है। Course Eight के worked example के लिए, यह वही runtime है जिसे thesis name करती है। आपके real deployment के लिए, architectural patterns दूसरे runtimes तक transfer करते हैं; OpenClaw example है, requirement नहीं।

अगर आप OpenClaw use नहीं कर सकते: transfer guidance. Compliance constraints, model-provider restrictions, या build-vs-buy preferences OpenClaw को reach से बाहर कर सकते हैं। Course Eight के architectural patterns फिर भी apply होते हैं; आप उन्हें बस अलग runtime पर operationalize करेंगे। Load-bearing OpenClaw primitives ऐसे map होते हैं जिन्हें आपको खुद build करना होगा:

OpenClaw primitive	आपको क्या provide करना होगा	Suggested substrate
Agent loop (Concept 4)	Tool execution वाला model-calling loop	Claude Agent SDK या OpenAI Agents SDK with a long-running daemon process
Local-machine runtime (Concept 4)	Owner के hardware पर reboot survive करके running रहने वाली process	Linux पर systemd, macOS पर launchd, Windows service, या owner द्वारा locally run किया गया छोटा Docker container
session primitive (Concept 5)	Owner के filesystem पर persistent context storage	Directory जिसे daemon read और write करता है; structured JSON या SQLite काफी है; जो schema आप pick करते हैं वह आपका है
Chat-app reachability (Concept 6)	Owner agent को message कर सके और responses पा सके	Single chat-app bot (Telegram bots simplest हैं; BotFather flow लगभग 5 minutes लेता है)। 50+ integrations OpenClaw का value-add हैं, architecture की requirement नहीं
Skills और plugins system	"Paperclip से बात करो" जैसी capabilities के लिए extension mechanism	आपके Agent SDK में tools के रूप में registered hand-written Python या TypeScript functions
Signing key (Concept 8)	Owner के filesystem पर stored ed25519 key pair	Standard library code: browser में crypto.subtle, Node में crypto, Python में cryptography

Course Eight as written की तुलना में क्या change होता है: आप ज़्यादा glue code लिखते हैं (skill manifests, daemon supervision, chat-app integration)। क्या same रहता है: trust-delegation primitive (Concepts 7 से 9), governance ledger schema (Concept 11), two-envelope intersection, recalibration loop. Claude Agent SDK पर Course-Eight-equivalent assemble करने का build effort: experienced engineer के लिए roughly एक weekend. Discipline patterns में है, runtime में नहीं।

निचोड़: OpenClaw open-source, user-owned personal AI runtime है जिसके against Course Eight सिखाता है। यह owner की local machine पर चलता है, owner के filesystem पर context store करता है, और owner की already-used chat apps से reachable है। May 2026 तक, यह Tapscott की self-sovereign Identic AI commitment का credible shipped operationalization है: MIT license के under open source, बड़ी GitHub following और major-vendor sponsorship के साथ। Course के patterns दूसरे runtimes तक transfer करते हैं, लेकिन OpenClaw worked example है।

Concept 5: Persistent memory और owner का local context

OpenClaw को "another AI chatbot" से "Maya की Identic AI" बनाने वाली single property persistent memory है। इसके बिना, Maya को हर interaction पर OpenClaw को अपना judgment फिर से explain करना पड़ता; Identic AI की value ठीक यही है कि वह भूलती नहीं। Concept 5 walk through करता है कि OpenClaw की persistent memory कैसे काम करती है, Maya का accumulated context असल में कहाँ रहता है, और architecture Course Eight के central use case के लिए क्या imply करती है।

session primitive. OpenClaw persistent context को उसके docs के session के around organize करता है: time, devices, और chat apps के across user के accumulated context की unit. Session model के बारे में तीन बातें जाननी हैं:

1. Storage local है। Maya की session Maya के hardware पर, उसके filesystem में, उसके home directory में OpenClaw config path के under रहती है। Default रूप से cloud account में synced नहीं। कोई "OpenClaw Cloud" नहीं है जो Maya का context store करे। (Maya multi-device use के लिए sync opt in कर सकती है; Concept 13 tradeoffs walk करता है।)
2. Storage human-readable है। Session Maya के disk पर structured data है जिसे वह inspect, edit, git से version, encrypt, back up, या अपने discretion पर destroy कर सकती है। Tapscott की self-sovereignty commitment यहाँ filesystem property के रूप में operationalize होती है: Maya files own करती है; files Maya का context हैं।
3. Storage accumulate करता है। हर interaction session में add होता है। Maya Telegram पर refund decision के बारे में OpenClaw को message करती है; वह decision session में join करता है। वह coffee के दौरान menubar app से hire approve करती है; वह approval session में join करता है। छह महीने बाद, session में Maya के recorded decisions, preferences, communication patterns, और explicit instructions के hundreds हैं।

Concretely, क्या persist होता है। OpenClaw की session सिर्फ chat transcript से ज़्यादा capture करती है। Docs से:

Persisted	यह क्या है	Owner Identic AI के लिए क्यों matter करता है
Conversation history	Chat apps के across Maya और OpenClaw के बीच literal message exchange	Raw record. Maya फिर से पढ़ सकती है कि उसने क्या कहा और OpenClaw ने क्या किया।
User preferences	Maya के explicit statements ("मुझे morning meetings पसंद हैं"; "$5,000 से ऊपर कुछ भी मेरे बिना approve मत करना")	Standing instructions जिन्हें Identic AI उसके बाद apply करती है
Skills installed and configured	Maya ने कौन सी OpenClaw skills install की हैं; उनकी configurations	Identic AI की capability surface, जिसमें Course Eight की Paperclip-integration skill शामिल है
Persona	OpenClaw के लिए Maya की named identity (उदाहरण, "Maya's Lobster" या "Claudia") और OpenClaw जो persona project करता है	Chats और devices के across identity की continuity
Activity log	OpenClaw ने क्या किया और कब: हर skill invocation, हर external API call, हर decision	Audit trail जो Course Eight का governance ledger बनता है (Concept 11)
Derived patterns	Maya के judgment का Identic AI का accumulated model, time के साथ सीखा हुआ	Judgment-learning loop जिसके बारे में course centrally है

Default रूप से क्या persist नहीं होता: ephemeral environmental state (Maya ने किसी message के लिए कौन सी chat app use की, millisecond resolution पर precise timestamp, और similar). ये record होते हैं लेकिन identity-relevant session के हिस्से के रूप में surface नहीं होते। Distinction इसलिए matter करता है क्योंकि Concept 13 का सवाल, Maya के साथ devices और employers के across क्या travel करता है, exactly यह सवाल है कि session का कौन सा subset identity-relevant है।

Filesystem-local storage load-bearing architectural commitment क्यों है। OpenClaw architecture का यह हिस्सा सबसे आसानी से miss होता है। कई AI products "persistent memory" advertise करते हैं जबकि चुपचाप मतलब रखते हैं "हम आपकी memory अपने cloud में store करते हैं, और आप उस पर हमें trust करते हैं।" OpenClaw की choice, default रूप से Maya का filesystem, qualitatively अलग है। इसका मतलब:

• Maya अपना context cat ~/.openclaw/session/*.json से read कर सकती है (या writing के समय path जो भी हो; canonical layout के लिए docs.openclaw.ai/concepts/session consult करें)।
• Maya अपने context को उन्हीं tools से back up कर सकती है जिन्हें वह बाकी files के लिए use करती है (Time Machine, rsync, Git, encrypted external drives).
• Maya files move करके अपना context new device पर ले जा सकती है।
• Maya files delete करके अपना context destroy कर सकती है। Vendor के पास file करने के लिए कोई "delete request" नहीं।
• Maya अपने existing disk-encryption tools से अपने context को at rest encrypt कर सकती है।
• Maya का context किसी platform द्वारा hostage नहीं held है। अगर OpenClaw project कल shut down हो जाए, Maya का accumulated context अभी भी उसके disk पर रहेगा; वह उसे read, parse, और different runtime में load कर सकेगी।

यही property Tapscott की self-sovereignty commitment satisfy करती है। यही property Maya की Identic AI को chat app, model provider, यहाँ तक कि effort के साथ runtime बदलने पर भी survive कराती है। Session Maya की है; runtime configurable है।

PRIMM: Predict

Maya छह महीनों से OpenClaw use कर रही है। उसके Mac पर session directory लगभग 240 MB है। वह employers switch करती है: अपनी current AI-native company बेचती है और नई company शुरू करती है। उसकी session के नीचे दिए गए कौन से parts नई company तक carry forward होने चाहिए, और कौन से नहीं?

Items:

• (a) उसका communication style और tone preferences
• (b) old company के Workers पर उसके past approval decisions
• (c) Paperclip-integration skill की configuration जो old company's API endpoint की ओर point करती है
• (d) उसकी standing instruction "always escalate envelope-extension hires"
• (e) old company में OpenClaw ने जो हर action लिया उसका activity log

हर एक के लिए predict करें: Maya के साथ travel करता है / old company के साथ रहता है / it's complicated. फिर आगे पढ़ें।

---

उत्तर: (a) travels. Communication style personal pattern है, company property नहीं। (b) it's complicated. उन decisions से derived patterns travel करते हैं ("Maya envelope extensions वाली hires को X होने पर approve करती है लेकिन Y होने पर नहीं"); decisions themselves (जो old company के specific Workers और specific issues के बारे में थे) confidentiality के मामले में stay करते हैं। (c) stays. उस skill की configuration old company's endpoint पर pointed है; new company के endpoints अलग हैं, auth भी शायद अलग हो। (Skill itself recipe के रूप में travel कर सकती है और reconfigure हो सकती है।) (d) travels. वह standing personal instruction है; कहीं भी apply होती है। (e) stays. Activity log old company's systems के against लिए गए actions record करता है; यह audit data है जिस पर old company के rights हैं, Maya का owned data नहीं।

यह Course Seven के Concept 13 का Harper Carroll seam है, Maya की session पर applied: patterns travel करते हैं, specific records नहीं। OpenClaw session का filesystem layout इस distinction को enforceable बनाता है। Maya personal-patterns subset package और migrate कर सकती है और company-records subset पीछे छोड़ सकती है।

निचोड़: Maya की Identic AI Maya की session है, यानी उसकी conversation history, preferences, skills, persona, activity log, और derived patterns का structured local store. यह उसके filesystem पर, human-readable files में रहता है जिन्हें वह own करती है। यही architecture को self-sovereign बनाता है और Maya के accumulated judgment को हर device, employer, या chat app change के बाद survive कराता है। Session Maya की है; बाकी सब configuration है।

Concept 6: Interface layer के रूप में chat apps

OpenClaw का non-obvious architectural choice यह है कि user-to-AI conversation के लिए इसका अपना user interface नहीं है। OpenClaw web app नहीं, chatting के लिए OpenClaw mobile app नहीं। User OpenClaw से उन्हीं chat apps के through बात करता है जिन्हें वह पहले से use करता है: WhatsApp, Telegram, Discord, Slack, Signal, iMessage. Concept 6 walk through करता है कि Identic AI के लिए यह सही architectural choice क्यों है और Course Eight worked example के लिए इसका क्या मतलब है।

Dedicated app क्यों नहीं। AI product के लिए default move अपनी chat UI ship करना है: web app, mobile app, या दोनों। OpenClaw deliberately ऐसा नहीं करता। Project के design choices से drawn reasoning यह है कि Identic AI को वहाँ रहना चाहिए जहाँ user पहले से रहता है, वहाँ नहीं जहाँ product चाहता है कि user रहे। User पहले से अपनी chat apps में पूरा दिन रहता है: team के group threads, family के DMs, partner के साथ WhatsApp. Identic AI को उन apps में रखने का मतलब:

• User उससे बात करने के लिए context-switch नहीं करता।
• User Identic AI को दूसरे humans के साथ group chats में include कर सकता है (Maya अपने OpenClaw को board-discussion Slack channel में add कर सकती है; उसकी Identic AI peer की तरह participate करती है)।
• User का existing notification system attention routing handle करता है (Maya का phone OpenClaw के लिए वैसे ही buzz करता है जैसे उसकी team के messages के लिए)।
• User को अलग app open करना याद रखने की ज़रूरत नहीं।
• Identic AI chat apps की सारी conveniences inherit करती है: voice messages, file attachments, group threads, search history.

Chat-channel integrations feature list नहीं, architectural commitment हैं। OpenClaw openclaw.ai/integrations पर 50+ integrations list करता है, जिनमें 15+ chat channels शामिल हैं (WhatsApp, Telegram, Discord, Slack, Signal, iMessage, और more)। यहाँ chat-channel set matter करता है। User openclaw onboard के दौरान अपनी preferred chat app या apps pick करता है; OpenClaw उनके साथ integrate होता है; user messaging शुरू करता है। Chat interface की learning curve नहीं क्योंकि user पहले से जानता है कि उसकी chat app कैसे काम करती है।

Maya के लिए इसका मतलब। Course Eight worked example में, Maya OpenClaw को Telegram के through reachable configure करती है। (हम Telegram इसलिए pick करते हैं क्योंकि OpenClaw docs इसे default example के रूप में use करते हैं, और Telegram के bot semantics clean हैं। Maya उतनी ही आसानी से WhatsApp या Signal use कर सकती है।) Onboarding के दौरान Maya अपने OpenClaw का नाम "Claudia" रखती है। उसके बाद:

• जब Maya अपनी Identic AI को message करना चाहती है, वह Telegram खोलती है, Claudia वाला chat find करती है, और type करती है। Teammate को message करने जैसा same gesture.
• जब उसकी Identic AI उसे कुछ surface करना चाहती है (approval जिसे Maya के judgment की ज़रूरत है, weekly governance-ledger summary), तो वह Maya को Telegram message भेजती है। Same notification flow as any other message.
• जब Maya desk पर होती है, वह Telegram switch करने के बजाय OpenClaw का macOS menubar app use कर सकती है। Session shared है।
• जब Maya travel करती है और phone use करती है, वही Claudia वहाँ है। Session उसके devices के across sync होती है (Concept 13 के architectural caveats के साथ कि sync कैसे काम करता है)।

Trust-delegation problem के लिए implication. यह subtle है और Part 3 में जाने से पहले note करने लायक है। क्योंकि OpenClaw उन chat apps में रहता है जिन्हें user पहले से trust करता है, user-to-OpenClaw trust chat app के अपने auth से inherit होता है। Maya पहले से Telegram में Maya के रूप में logged in है; वह पहले से अपने Telegram account पर भेजे गए messages की recipient है; OpenClaw को user-to-AI boundary पर उसे re-authenticate करने की ज़रूरत नहीं। इसलिए Course Eight में trust-delegation problem "OpenClaw को कैसे पता कि यह Maya है" नहीं है, जिसे Telegram का अपना auth solve करता है। Problem है "Paperclip management layer को कैसे पता कि Maya के OpenClaw से originating approval request genuinely Maya-authorized है।" यही Concept 7 की problem है।

AI के साथ try करें

इसे अपने AI coding assistant में paste करें:

"OpenClaw reaches the user through chat apps as its primary interface: WhatsApp, Telegram, Discord, Slack, Signal, iMessage, and more. The architectural commitment is that the Identic AI lives where the user already lives, not in a separate app. From the user's perspective, this is a clear win: zero context switching, existing notifications, group chats. From a security perspective, list three things the user should verify about their chosen chat app before treating their OpenClaw conversation as trustworthy for governance decisions. For example: is the chat encrypted end-to-end? What happens if the chat-app provider is compelled to hand over messages? What is the recovery story if the user's chat-app account is compromised?"

आप क्या सीख रहे हैं: chat-app interface chat app से trust inherit करता है, और उस trust की real properties हैं जिन्हें Maya को verify करना चाहिए। Telegram की end-to-end encryption opt-in है (सिर्फ "Secret Chats" के लिए); WhatsApp default रूप से end-to-end है; iMessage Apple ecosystem के अंदर end-to-end है। हर choice के implications हैं कि Paperclip integration chat-app messages को Maya के intent का cryptographic evidence मान रही है या convenience channel (उसे convenience channel ही मानना चाहिए)। Concept 8 का signed-delegation primitive governance decisions को cryptographically grounded बनाता है, चाहे उन्हें कौन सी chat app route करे।

निचोड़: OpenClaw की chat-app-first interface architecture deliberate choice है: Identic AI owner की already-lived जगह में रहती है, separate app में नहीं। Maya के लिए, इसका मतलब Telegram (या WhatsApp, या supported chat channels में कोई भी) उसकी Owner Identic AI का interface बनता है। Trust delegation के लिए architectural implication यह है कि user-to-OpenClaw auth chat app से inherit होता है; load-bearing trust problem OpenClaw-to-Paperclip boundary पर है, जिसे Concept 7 उठाता है।

---

Part 3: Trust delegation और governance

Parts 1-2 ने problem name की (Maya scale पर approvals नहीं पढ़ सकती), architectural primitive जो इसे solve करता है (Identic AI), और runtime जो इसे operationalize करता है (OpenClaw)। Part 3 Course Eight का load-bearing technical move उठाता है: company की Paperclip management layer Maya की Identic AI से approval decisions safely कैसे accept कर सकती है बिना उस safety property को abandon किए जिस पर पूरी seven-invariant thesis depend करती है। तीन Concepts.

Concept 7: Trust-delegation problem

जब Maya Paperclip में log in करके hire proposal पर "approve" click करती है, Manager-Agent record करता है कि human owner ने approve किया। जब Maya की Identic AI ("Claudia") रात 3 AM पर routine hire proposal पर "approve" click करती है जबकि Maya सो रही है, Manager-Agent record करता है कि कुछ approve हुआ। Concept 7 जिस सवाल को उठाता है वह है कि इन दोनों cases में क्या different होना चाहिए और क्या same होना चाहिए।

Naive answers दोनों wrong हैं:

Naive answer A: उन्हें same treat करना। "Claudia authorized है; उसका click Maya का click है; इसे Maya-approved record करो।" यह distinction collapse करता है और झूठ बोलने वाला audit trail बनाता है। छह महीने बाद जब Maya review कर रही है कि particular decision कैसे बना, तो activity log से वह नहीं बता सकती कि उसने खुद decision लिया या उसकी Identic AI ने उसकी ओर से। Recalibration के लिए needed information (Concept 12), यानी क्या मेरी Identic AI ने इसे अच्छे से handle किया, या मुझे इसे correct करना चाहिए?, गायब है। Truthful auditing के लिए दोनों principals को distinguish करना ज़रूरी है।

Naive answer B: हमेशा human require करना। "Claudia कुछ approve नहीं कर सकती; वह सिर्फ Maya को approval requests message कर सकती है, और Maya खुद 'approve' click करती है।" यह architecture Identic AI के बिना है; हमने progress नहीं की। Part 1 के argument का पूरा point है कि Maya हर routine approval पर loop में नहीं रह सकती। Identic AI जो सिर्फ messages relay कर सकती है, scaling problem solve नहीं कर रही।

Correct answer structurally तीन-part move है:

1. Identic AI की system में अपनी identity होती है। Maya का OpenClaw, Claudia के रूप में configured, distinct identity रखता है जिसे Paperclip recognize करता है: Claudia Paperclip agent के रूप में registered है, अपनी key के साथ। Claudia user account नहीं; वह Maya की delegated agent है। यह new principal type है जिसकी previous courses को ज़रूरत नहीं थी।
2. Identic AI की authority Maya की authority का subset है, Maya द्वारा set, clear limits के साथ। Maya owner-authority envelope में कुछ भी approve कर सकती है; Claudia configured subset approve कर सकती है (Concept 9 intersection walk करता है)। Subset recorded है: Maya जानती है Claudia को क्या करने की अनुमति है; Claudia जानती है; Paperclip इसे store करता है।
3. Audit trail record करता है कि किस principal ने act किया, और आपको honest होना होगा कि वह record कहाँ रहता है। यह हिस्सा easy to get wrong है, इसलिए course इसे upfront साफ़ कहता है। Real Paperclip 2026.513.0 के against, approval routes board-scoped हैं: approve, reject, या request-revision call board action के रूप में recorded होता है, इसलिए Paperclip का अपना activity_log actor_type='user' लिखता है चाहे Maya ने click किया या Claudia ने drive किया। Paperclip natively approval पर owner-human को owner-identic-ai से distinguish नहीं करता। इसलिए two-principal distinction course की अपनी governance_ledger table में रहती है: Claudia का हर decision principal='owner_identic_ai', उसकी attestation, और उसका reasoning carry करने वाली governance_ledger row लिखता है। Maya-resolved approval में ऐसी row नहीं होती। Approval id पर दोनों tables join करें और distinction fully recoverable है। (Simulated-track mock shortcut लेता है: वह native actor: owner_identic_ai attribution directly implement करता है, सिर्फ teaching simplification के रूप में। Real Paperclip ऐसा नहीं करता, और full-implementation track Part 4 में throughout इस बारे में honest है।)

यही three-part move delegated governance को safe बनाता है, reckless नहीं। Principle दोनों tracks में hold करता है: दो principals, one human, distinct audit truth. Mechanism differ करता है: mock में native attribution, real Paperclip के against governance_ledger. Maya delegate करती है, लेकिन disappear नहीं होती: audit record उसे हमेशा recoverable बनाता है।

Two principals, one human: real Paperclip के against distinction course की अपनी governance_ledger में रहता है, approval id पर Paperclip के activity_log से joined, ताकि हर delegated decision recoverable रहे। Mock इसे teaching simplification के रूप में natively implement करता है।

यह genuinely hard कहाँ है। Naive answers obvious तरीकों से fail करते हैं। लेकिन correct answer में एक genuinely hard implementation question छिपा है: Paperclip management layer कैसे verify करती है कि "Maya's Identic AI" से होने का claim करने वाली request सच में Maya की Identic AI से है, कोई दूसरी process pretend नहीं कर रही? अगर कोई भी approval API पर actor: owner_identic_ai, principal: maya post करके accepted हो सकता है, तो पूरी architecture broken है। Verification mechanism, local credentials से signed delegation, Concept 8 उठाता है।

निचोड़: trust-delegation problem Course Eight का load-bearing technical move है। दो principals authorized हैं, human owner और owner की Identic AI, और architecture को audit truth में उन्हें distinguish करना है, Identic AI की authority owner के subset के रूप में bound करनी है, और Identic AI की identity cryptographically verify करनी है। "उन्हें same treat करो" और "हमेशा human require करो" दोनों काम नहीं करते। Three-part move है distinct identity, bounded authority, और truthful audit. Honest detail: real Paperclip के against approval routes board-scoped हैं, इसलिए two-principal distinction Paperclip के activity_log से carry नहीं होती; यह course की अपनी governance_ledger में रहती है। Simulated mock native attribution को teaching simplification के रूप में implement करता है। Principle दोनों tracks में identical है; mechanism differ करता है।

Concept 8: Local credentials से signed delegation

Public-key cryptography में नए readers के लिए primer

अगले दो Concepts और Decisions 4-5 signed-delegation primitives use करते हैं। अगर "ed25519" और "signature verification" आपके toolkit में पहले से नहीं हैं, तो 90-second version यह है। ed25519 key pair दो related files की pair है: private key (secret जिसे आपकी machine hold करती है, लगभग 32 bytes) और public key (non-secret जो उससे derived है, लगभग 32 bytes)। जब आपकी machine payload sign करती है, तो वह short string (signature) produce करती है। आपका public key रखने वाला कोई भी उस signature को mathematically verify कर सकता है, जिससे prove होता है कि payload उसी ने भेजा जिसके पास private key है, बिना private key reveal किए। ed25519 modern default है: small keys, fast operations, इतना secure कि web की पूरी TLS infrastructure इसकी ओर move कर रही है। Canonical JSON encoding matter करता है क्योंकि sign-and-verify operation exact bytes पर होता है, "same data" पर नहीं: अगर signer और verifier JSON को differently serialize करें (for example, key ordering), signature verify नहीं होगा भले ही data logically identical हो। Standard practice है keys sort करना और sign करने से पहले extra whitespace strip करना। तीनों primitives, ed25519, signature verification, और canonical JSON, standard Node और browser libraries में ship होते हैं। Claude Code या OpenCode Decisions 4-5 में implementation details handle करता है; यह primer इसलिए है कि briefings engineering की तरह पढ़ें, magic की तरह नहीं।

Verification mechanism May 2026 में shipped primitives use करता है: filesystem-stored signing keys, optionally platform keystores (macOS Keychain, Windows Credential Manager, Linux libsecret) से hardware-backed, Paperclip side पर passkey/WebAuthn-style cryptographic challenges के साथ combined. यह Course Eight के उन हिस्सों में से एक है जो single shipped integration use करने के बजाय दोनों products के shipped building blocks wire करता है; building blocks stable हैं, wiring वही है जो course आपको assemble करना सिखाता है।

Maya की machine पर signing key. Course Eight lab (Decision 1) के दौरान, Maya का OpenClaw fresh cryptographic key pair से configured होता है। Private key Maya के home directory में रहती है (या optionally, उसके platform keystore में)। Public key Paperclip management layer के साथ "Maya's Identic AI" के रूप में registered होता है। उसके बाद:

• जब Maya का OpenClaw Maya की ओर से Paperclip की approval API को request करता है, OpenClaw private key से decision payload sign करता है।
• Course की अपनी delegation layer (Decision 5) registered public key से signature verify करती है। (Paperclip itself approval routes पर signature field नहीं रखता; ed25519 attestation course की अपनी layer है, Paperclip जो check करता है वह नहीं। Signature फिर भी real work करता है: यह prove करता है कि decision Claudia की key से आया और delegation layer real Paperclip route drive करने से पहले tamper नहीं हुआ।)
• Signature valid हो तो delegation layer जानती है कि request genuinely Maya की registered Identic AI से है।
• Request bounded-authority check (Concept 9) से process होती है; delegation layer फिर real board-scoped approval route call करती है, और principal: owner_identic_ai record करने वाली governance_ledger row लिखती है। (Paperclip का अपना activity_log approval को board action, actor_type='user', के रूप में record करता है; owner-human vs owner-identic-ai distinction governance_ledger में है। Concept 7 और Part 4 इसे full में cover करते हैं।)

Filesystem (या platform keystore) क्यों, "cloud" क्यों नहीं। Signing key Maya की है; उसे वहीं रहना चाहिए जहाँ Maya उसे control कर सके। Filesystem storage का मतलब Maya इसे back up, new device पर copy, या destroy कर सकती है, उसी तरह जैसे वह अपनी OpenClaw session के बाकी हिस्से control करती है। Platform-keystore storage (macOS Keychain और similar) hardware backing add करता है: key Maya के OS authentication के बिना export नहीं हो सकती, जिससे filesystem access पाने वाले लेकिन user-session access न पाने वाले attacker के लिए bar raise होता है। दोनों local-by-default हैं; कोई भी Maya की identity third party को leak नहीं करता।

Stolen-laptop failure mode. अगर Maya का Mac चोरी हो जाए तो क्या होता है? तीन failure scenarios, severity के order में:

1. Laptop चोरी, Maya logged in नहीं, FileVault encrypted. Attacker के पास device है लेकिन filesystem read नहीं कर सकता। Private key unreadable है। Attack surface नहीं; Maya laptop replace करती है और नए one पर re-onboard करती है।
2. Laptop चोरी, Maya logged in है लेकिन screen locked है। Attacker के पास device है, disk decrypted है, लेकिन screen unlock नहीं कर सकता। Private key disk पर है लेकिन attacker OpenClaw को use कराने के लिए trigger नहीं कर सकता। कुछ risk है अगर attacker के पास filesystem-level access हो (for example, external drive से boot करना); platform keystore approach यह bar raise करता है।
3. Laptop चोरी, attacker के पास Maya की session active है। Attacker Maya के OpenClaw से बात कर सकता है, Maya की Identic AI के रूप में requests sign कर सकता है, Claudia की delegated authority तक Paperclip में चीज़ें approve कर सकता है। यह worst case है। Mitigation Paperclip side पर revocation है: Maya, different device से, नया public key register करती है और stolen one revoke करती है। Course lab (Decision 7) यह revocation flow walk करता है।

Recovery story load-bearing detail है। Signed-delegation architecture जिसके पास stolen device के लिए recovery path नहीं है, fragile है। Course Decision 7 के हिस्से के रूप में revocation flow सिखाता है क्योंकि वहीं architectural commitment operational बनती है। Maya हमेशा, किसी भी device से जिसे वह अभी भी control करती है, Paperclip में log in कर सकती है (अपनी owner-human credentials से, अपनी Identic AI की credentials से नहीं) और compromised Identic AI key revoke कर सकती है।

Passkeys से relationship. Paperclip में Maya की owner-human credentials खुद passkeys / WebAuthn से protected हैं, वही primitive जिसकी ओर broader web 2026 में move कर रहा है। Maya अपनी passkey से Paperclip में sign in करती है (जो उसके control वाले device से bound है, जहाँ possible हो hardware-backed)। Identic AI signing key separate credential है: यह Claudia को represent करता है, Maya को नहीं, और Maya इसे अपनी passkey-authenticated session से revoke कर सकती है। दो credentials, दो principals, one human; architecture उन्हें cleanly distinguish करती है।

PRIMM: Predict

Maya की company का published API https://maya-co.com/api पर है। Company के बाहर कोई Maya की Identic AI होने का claim करते हुए approval-acceptance request भेजने की कोशिश करता है। Request में signature field है। Registered public key on file के बिना request verify करना impossible होगा। Predict करें: आपकी delegation layer की verification logic जिस order में चलती है (Decision 5 के three gates), कौन सा check पहले fail होता है? (a) signature cryptographic validity, (b) signer-key-is-registered, (c) bounded-authority-check (Concept 9), (d) governance-ledger write. फिर आगे पढ़ें।

---

उत्तर: (b). आपकी delegation layer सबसे पहले check करती है कि जिस public key से signature बना है वह known owner के लिए registered Identic AI key है या नहीं। अगर signer key file पर नहीं है, layer request को cryptographic verification से पहले reject करती है। (आप signature cryptographically verify कर सकते हैं, लेकिन अगर यह unknown key से signed है, verification का result help नहीं करता: unknown key से valid signature फिर भी unknown principal है।) First gate identity registration है; cryptographic validity second gate है। यह ordering matter करती है क्योंकि यह attackers को arbitrary inbound requests पर signature verification में CPU spend कराने से रोकती है; सिर्फ registered principals की requests ही उस तक पहुँचती हैं। (ध्यान दें यह verification course की अपनी delegation layer है, Paperclip नहीं: Paperclip approval routes पर signature field नहीं रखता। Concept 7 और Decision 5 cover करते हैं कि क्यों।)

निचोड़: signed delegation Maya की Identic AI को Paperclip में उसकी ओर से act करने देता है, इस ambiguity के बिना कि किस principal ने act किया। Signing key Maya की machine पर रहती है (filesystem या platform keystore); public key registered होता है ताकि course की अपनी delegation layer Claudia की attestations verify कर सके; वह layer delegated principal को governance_ledger में लिखती है। Stolen-laptop case revocation से handle होता है: Maya किसी भी device से जिसे वह अभी भी control करती है, अपनी Identic AI की credentials invalidate कर सकती है। Architecture उस failure mode में robust है जो matter करता है।

Concept 9: Two-envelope intersection

Paperclip के model में Maya का authority envelope वह है जिसे वह approve कर सकती है: company के authority surface में कुछ भी, envelope-extension hires, terminations, और unlimited refunds तक। यह Claudia के लिए सही envelope नहीं है। Claudia का delegated envelope Maya का deliberately narrower subset है, Maya द्वारा set, और registered Identic AI के metadata के हिस्से के रूप में Paperclip पर recorded. Concept 9 intersection logic walk करता है: Claudia act करती है तो जो execute होता है वह न तो Claudia जो authority claim करती है है, और न ही जो Maya कर सकती है; यह दोनों का intersection है।

दो envelopes, concretely. Course Seven customer-support company के लिए Maya के envelopes कुछ ऐसे दिखते हैं:

Maya's owner-authority envelope (Maya खुद क्या approve कर सकती है)	Claudia's delegated envelope (Maya की Identic AI उसकी ओर से क्या approve कर सकती है)
Refunds: unlimited	Refunds: $2,000 तक
Existing envelope के अंदर hires: yes	Existing envelope के अंदर hires: yes
Company envelope extend करने वाली hires: yes	Company envelope extend करने वाली hires: no, Maya को surface करें
Terminations: yes	Terminations: no, Maya को surface करें
Budget overrides: unlimited	Budget overrides: monthly cap से 20% over तक
Standing-policy edits: yes	Standing-policy edits: no, Maya को surface करें
CMA migrations: yes	CMA migrations: per quarter एक तक, सिर्फ $1,000/mo से कम budget वाले Workers के लिए

Pattern: Claudia routine, bounded decisions पर autonomously act कर सकती है; वह strategic, irreversible, या category-changing decisions Maya को defer करती है। Maya Course Eight lab (Decision 4) के दौरान ये thresholds set करती है और quarterly revisit करती है।

Action तभी execute होता है जब वह एक साथ दोनों envelopes के अंदर बैठता है: strict intersection, union कभी नहीं।

Intersection logic. जब Claudia act करने की कोशिश करती है, Paperclip compute करता है:

1. क्या यह action owner-authority envelope में है? (यानी, क्या Maya खुद इसे approve कर सकती होती?) इस example में हर चीज़ के लिए yes, क्योंकि Maya company own करती है; लेकिन ऐसा request जो company के overall budget cap को exceed करता है, जिसे Maya भी unilaterally approve नहीं कर सकती, no होगा।
2. क्या यह action Identic AI के delegated envelope में है? (यानी, क्या Claudia को इस पर act करने की अनुमति है?) $2,000 तक refunds के लिए yes; envelope-extension hires के लिए no.
3. Action तभी proceed करता है जब दोनों yes हों। अगर सिर्फ (1) yes है और (2) no है, तो action Maya को approval request के रूप में surface होता है जिसे वह खुद handle करती है।

Intersection सही model क्यों है, union नहीं। Maya की authority ceiling है, transferable bundle नहीं। Claudia Maya की authority exceed नहीं कर सकती; अगर Maya $X तक approve कर सकती है, Claudia उससे ज़्यादा approve नहीं कर सकती। लेकिन Claudia Maya के ceiling से नीचे भी Maya की deliberate choice से bounded है: Maya कह सकती है "मैं refunds में Claudia को $2,000 तक trust करती हूँ, लेकिन $5,000 refunds मैं खुद देखना चाहती हूँ।" Architecture को दोनों bounds encode करने होंगे, और intersection ही वह logic है जो ऐसा करता है।

Standing-instructions surface. Maya Claudia को standing instructions देकर Claudia के delegated envelope को extend या contract कर सकती है। छह महीनों में Maya ऐसे examples दे सकती है:

• "अगर customer का account दो साल से पुराना है और prior refunds नहीं हैं, तो $2,000 तक कोई भी refund approve करें।"
• "Envelope-extension hires हमेशा मुझे surface करें, भले ही new authority कुछ ऐसी हो जो हमने पहले grant की है।"
• "अगले महीने के लिए, जब तक हम new product line test कर रहे हैं, उस product line की कोई भी hire मुझे surface करें।"
• "अगर Worker का budget overrun activity log में known incident से correlated है, तो आप override को 50% तक approve कर सकती हैं, लेकिन weekly governance-ledger summary में इसे flag करें।"

ये instructions Maya की session में persistent memory के हिस्से के रूप में accumulate होती हैं (Concept 5)। Identic AI इन्हें delegated-envelope ceiling के साथ conjunction में apply करती है। Result यह है कि Maya की policy plain language में learned and updated होती है, static config file में एक बार encoded नहीं। यह Concept 1 का rule और judgment distinction है, operationalized.

निचोड़: Claudia जो action execute करती है वह Maya के owner-authority envelope (ceiling) और Claudia के delegated envelope (Maya का chosen subset) का intersection है। Intersection ही वह logic है जो Identic AI की authority को correctly bound करता है: यह owner से exceed नहीं कर सकती, और owner ने जो delegate करना चुना है उससे भी exceed नहीं कर सकती। Maya plain language में Claudia को standing instructions देकर delegated envelope extend और contract करती है, जिससे policy वह judgment बनती है जिसे Maya time के साथ update करती है, एक बार encoded rule नहीं।

---

Part 4: Worked example: Maya की Identic AI wire करना

Parts 1-3 ने architecture explain की। Part 4 इसे concretely assemble करने का walkthrough है। सात Decisions, हर एक आपके Claude Code या OpenCode session के लिए briefing, हाथ से type या edit कभी नहीं। Part 4 के end तक आपकी Owner Identic AI Mac पर installed, Telegram के through reachable, और delegated envelope के साथ configured होगी। "Demonstrably handling routine approvals" का मतलब आपके track पर depend करता है: full-implementation track पर, Maya की Identic AI उसके real Course Seven Paperclip deployment से wired होती है और live approval routes के against full cryptographic round-trip exercise करती है। Simulated track पर, आप same architectural patterns को local Paperclip mock के against exercise करते हैं: आप working demo और sound mental model के साथ finish करते हैं, लेकिन real Paperclip की production wiring simulated lab का हिस्सा नहीं। दोनों tracks routine approvals के flood को handle करने और consequential ones को surface करने वाली Identic AI के साथ end होते हैं; फर्क यह है कि दूसरे end पर Paperclip real है या नहीं।

Decision 1 से पहले अपना track चुनें: choice हर briefing बदलती है

Course Eight का lab दो तरीकों से चलता है। Decision 1 से पहले चुनें: choice affect करती है कि आप हर briefing कैसे पढ़ते हैं, कितना time commit करते हैं, और end में आपके पास क्या होता है। Mid-lab switch न करें; wiring consistent नहीं रहेगी।

1. Full implementation (actual Paperclip-running AI-native company के owners के लिए)। आप Paperclip के codebase को modify नहीं करते। आप real Paperclip board API key (board_api_keys से) mint करते हैं और अपनी Identic AI को देते हैं: वही board credential real approval routes (POST /api/approvals/{id}/approve और friends) को उसके calls authenticate करता है। आप उसे real Paperclip agent के रूप में agent_api_keys entry के साथ register भी करते हैं, जो उसे Paperclip identity और revocation surface देता है (approve call authenticate करने वाली चीज़ नहीं)। आप OpenClaw integration skill के अंदर अपनी signing, signature-verification, और delegated-envelope layer बनाते हैं, plus अपनी additive governance_ledger table, और live Paperclip deployment के against full cryptographic round-trip exercise करते हैं। Time: 3 hours reading के ऊपर 6 से 10 hours lab; realistically 1-day sprint, या thinking room के साथ 2 days. Output: आपकी real company के लिए production-grade Owner Identic AI.
2. Simulated (बाकी सभी के लिए: learners, students, deployed Paperclip के बिना लोग)। आप mock Paperclip endpoint run करते हैं जो simplified API shape accept करता है, canned responses return करता है, और local governance_ledger.json में write करता है। Architectural patterns exercise होते हैं; production wiring नहीं। Time: 2 hours reading के ऊपर 2 से 3 hours lab; comfortable half-day. Output: Owner Identic AI की working understanding plus local demo.

Most Decisions दोनों tracks के लिए same briefing से काम करते हैं। Decisions 3, 5, 6, और 7 genuinely diverge करते हैं: उनमें labeled Simulated track block और Full-implementation track block हैं। Simulated mock simplified routes रखता है (single /resolve route सहित); full track real Paperclip surface use करता है।

Track choice conceptually एक चीज़ बदलती है: two-principal distinction कहाँ रहता है। Concepts 7-9 यह already सिखा चुके हैं, इसलिए यह cross-reference है, new material नहीं। Real Paperclip 2026.513.0 के against, approval routes board-scoped हैं: हर activity_log row जो वे write करते हैं actor_type='user' है, इसलिए Paperclip Claudia-resolved approval को Maya-resolved one से नहीं बता सकता। Distinction course की अपनी governance_ledger में रहती है। Simulated mock native owner_identic_ai attribution directly implement करता है, teaching simplification के रूप में। नीचे full-implementation track इस बारे में throughout honest है।

Lab Setup: Decision 1 से पहले

नीचे के Decisions Claude Code या OpenCode (आपका agentic coding tool; अगर कोई unfamiliar है तो Agentic Coding Crash Course देखें) के through execute होने के लिए लिखे गए हैं। इस lab में आप कहीं भी code manually type या edit नहीं करते। हर Decision आपके agentic coding tool को brief किया जाता है, जो plan produce करता है, आप plan review और approve करते हैं, और फिर tool implement करता है। यही discipline Courses Three से Seven ने use की थी।

अगर आप यह setup skip करके generic chat AI से lab drive करने की कोशिश करते हैं, तो तीन specific failure modes आपको काटेंगे:

1. chat AI आपका filesystem read या edit नहीं कर सकता, इसलिए हर code artifact को chat में copy-paste करके बाहर-भीतर करना होगा, जिससे lab time double हो जाएगा;
2. Plan Mode equivalent नहीं है, इसलिए AI approach review होने से पहले code लिखना शुरू कर देगा, और आप wrong directions undo करने में hours खर्च करेंगे;
3. ऐसा project-rules file नहीं है जिसे AI हर session में पढ़े, इसलिए हर session constraints फिर से सीखेगा (production governance_ledger को touch न करें; commit करने से पहले हमेशा tests run करें; course-seven-export/ कभी edit न करें क्योंकि यह read-only है), और आपको खुद को constantly repeat करना होगा।

Setup दो moves है: अपना coding agent install करें, फिर starter project download करें। Total लगभग 10 minutes.

1. Claude Code या OpenCode install करें

एक चुनें। दोनों पूरे lab के लिए काम करते हैं; अपनी model preference और config control की ज़रूरत के आधार पर चुनें। (अगर आपके पास already one installed है, step 2 पर skip करें, लेकिन upgrade command run करके confirm करें कि आप latest version पर हैं।)

# macOS / Linux / WSL: recommended (auto-updates)
curl -fsSL https://claude.ai/install.sh | bash

# Or via Homebrew (no auto-update)
brew install --cask claude-code

# Verify and update
claude update
claude --version

पूरा installation reference: docs.claude.com/claude-code.

2. Starter project download करें

Lab को जो बाकी चाहिए वह starter project में pre-wired है। इसे download करें, unzip करें, और आपके पास real git init-able course-eight-lab/ folder होगा जिसमें project rules file, permissions और guardrails, reusable verification commands, simulated-track mock, और Maya की read-only approval history already मौजूद होगी।

Download: identic-ai-crash-course.zip

इस course के earlier draft में आपसे छह setup steps में लगभग 350 lines config hand-type करवाया गया था। वह config अब zip में ship होता है, इसलिए आप उसे transcribe करने के बजाय read और run करते हैं। Layout यह है, और हर piece क्यों matter करता है:

identic-ai-crash-course/
├── README.md                      # human entry: what this is, pick a track, next step
├── CLAUDE.md                      # the project rules file (Claude Code)
├── AGENTS.md                      # the project rules file (OpenCode)
├── opencode.json                  # OpenCode: instruction files + permissions + plugin wiring
├── .claude/
│   ├── settings.json              # permissions allow/deny + 3 PreToolUse guardrail hooks
│   └── commands/                  # /verify-audit-trail and /verify-envelope slash commands
├── .opencode/
│   ├── plugins/course-eight-guardrails.js   # the same 3 guardrails as an OpenCode plugin
│   └── commands/                  # the two slash commands for OpenCode
├── mocks/
│   └── paperclip-mock.ts          # the simulated-track Paperclip stand-in
├── course-seven-export/
│   ├── README.md                  # read-only input, do not edit
│   └── approvals.json             # a sample of Maya's past approval decisions
└── docs/
    ├── course-eight-architecture.md      # architectural background the rules file @-references
    ├── governance-ledger-schema.sql      # the schema Decisions 5 and 11 build against
    └── openclaw-skills-reference.md      # OpenClaw skills system pointer notes

हर piece किसके लिए है:

• CLAUDE.md / AGENTS.md (project rules file). यह load-bearing context है: आपका coding agent इसे हर session के start पर पढ़ता है, इसलिए उसे stack, दो lab tracks, critical rules (कभी course-seven-export/ edit न करें, private signing key print न करें, Paperclip-side changes के बाद npm test run करें, Decision 7 में daemon-stop step mandatory है), और on-demand reference docs कहाँ रहते हैं पता रहता है। नीचे हर Decision assume करता है कि ये rules in place हैं। opencode.json OpenCode के लिए same instruction-file wiring carry करता है।
• Permissions block (.claude/settings.json allow/deny, opencode.json permission) plus hooks/plugin. साथ में ये deny-and-refuse safety layer हैं। Permissions block कहता है "dangerous things से पहले पूछो।" Hooks (.claude/settings.json PreToolUse) और OpenCode plugin (.opencode/plugins/course-eight-guardrails.js) कहते हैं "असल में, इन चीज़ों को सिर्फ refuse करो, कभी पूछो भी मत।" तीन guardrails agent-judgment के बजाय deterministic हैं: production DB pointer carry करने वाली governance_ledger.json commit करने से refuse, read-only course-seven-export/ edits से refuse, और .pem private signing key commit करने से refuse. Combination सही safety property है: सबसे catastrophic possible mistake (Maya की private signing key public repo में leak करना) structurally blocked है।
• Slash commands (.claude/commands/, .opencode/commands/). /verify-audit-trail और /verify-envelope reusable verification workflows हैं जो एक बार save हैं ताकि आपको instructions फिर से type न करनी पड़ें। Decision 6 के बाद और फिर Decision 7 के बाद audit-trail check run करेंगे; local envelope अभी भी Paperclip registered envelope से match करता है या नहीं confirm करने के लिए envelope check run करेंगे।
• mocks/paperclip-mock.ts. Simulated-track Paperclip stand-in. यह read side working के साथ ship होता है: healthcheck, pending-approval queue, basic human-resolve path, workload inject करने वाला test helper, और governance_ledger.json writer. Signed-delegation gating और identity-registration endpoints deliberately marked stubs के रूप में छोड़े गए हैं, क्योंकि उन्हें build करना ही Decisions 4 और 5 है। इन्हें pre-fill न करें; lab आपको इसके through walk करता है।
• course-seven-export/approvals.json. Maya के past approval decisions: read-only judgment input जिसे Decision 2 import करता है ताकि Claudia zero से सीखने के बजाय Maya के judgment के model से शुरू करे। Guardrails यहाँ edits actively refuse करते हैं; इसे modify करने का मतलब Claudia के seeded patterns अब real history reflect नहीं करते।
• docs/. Background जिसे rules file demand पर @-reference करती है: architecture context, governance-ledger schema जिसके against Decisions 5 और 11 build करते हैं, और OpenClaw skills system पर orientation notes. Agent इन्हें preemptively नहीं, सिर्फ Decision को जरूरत होने पर load करता है।

आपका काम: project unzip करें, फिर terminal में:

cd identic-ai-crash-course
git init

git init OpenCode users के लिए non-negotiable है (इसकी /undo feature को git चाहिए)। Claude Code users के लिए भी strongly recommended है: commits Decisions के बीच progress save करने का तरीका हैं, और Decision 7 में daemon-stop fix assume करता है कि lab git-tracked है।

फिर folder को अपने coding agent से open करें:

• Claude Code: claude
• OpenCode: opencode

Setup verify करना

Decision 1 शुरू करने से पहले, Claude Code या OpenCode के अंदर quick sanity check run करें ताकि confirm हो कि rules load हुए हैं।

Claude Code prompt में type करें:

What rules are you following for this session? List any instructions
from my project's CLAUDE.md file, and confirm the hooks block in
.claude/settings.json loaded.

आपको Claude Code से CLAUDE.md के lab rules list होते और तीन PreToolUse hooks active confirm होते दिखना चाहिए। अगर यह कहे कि उसके पास कोई special instructions नहीं या hooks loaded नहीं हैं, तो recheck करें कि आपने claude को identic-ai-crash-course/ directory के अंदर से open किया।

Plan-then-Execute discipline

नीचे हर Decision की दो phases हैं: Plan (read-only investigation; written plan produce करना; आप review करते हैं) और Execute (आप plan approve करते हैं, फिर tool implement करता है)। यह तीन reasons से non-negotiable है:

1. Review किया हुआ plan 30 seconds लेता है; wrong implementation revert करना बहुत ज़्यादा time लेता है।
2. docs/plans/decision-N.md में saved plans /clear survive करते हैं और sessions के across resume हो सकते हैं।
3. Plan-then-execute split आपको frontier model पर planning और cheap one पर execution करके tokens (और money) save करने देता है (agentic-coding crash course का Plan/Execute composition pattern देखें)।

हर Decision के लिए: Plan Mode (read-only) में जाने के लिए Shift+Tab दो बार press करें। Requirements brief करें। Claude Code जो plan produce करता है उसे review करें। Plan को docs/plans/decision-N.md में save करने को कहें। फिर Plan Mode से exit करने और execution authorize करने के लिए Shift+Tab press करें।

नीचे Decisions उस brief को describe करते हैं जो आप tool को देते हैं: क्या plan और execute करना है। वे हर बार Plan-then-Execute workflow repeat नहीं करते; वह अब lab के लिए आपका standing operating procedure है।

---

Decision 1: Maya के Mac पर OpenClaw install करें

एक line में: clean Mac पर OpenClaw install करें, openclaw onboard run करें, persona/model/chat-app setup walk करें, और Telegram के through Claudia को "hello" message करके verify करें कि install काम करता है।

Downstream सब clean OpenClaw install पर depend करता है। Decisions 2-7 में lab failures लगभग 80% time partially-completed Decision 1 तक trace होते हैं। यहाँ जो persona name आप pick करते हैं वही Claudia आपकी governance ledger में forever use करेगी; model choice novel cases पर Claudia की reasoning quality affect करती है; chat-app integration उसका आपका only interface है। इसे foundation decision treat करें, setup step नहीं।

Brief. अपने agentic coding tool में plan mode पर switch करें, नीचे brief paste करें, tool से written plan produce करके docs/plans/decision-1.md में save करने को कहें, review करें, फिर plan mode से बाहर switch करके execute करें।

मुझे fresh Mac पर OpenClaw install करना है और onboarding flow पूरा करना है। Official site openclaw.ai और docs docs.openclaw.ai/getting-started के अनुसार। Requirements:

1. OpenClaw install करें। curl -fsSL https://openclaw.ai/install.sh | bash run करें (Node.js और dependencies auto-installs), या अगर Node.js already set up है तो npm i -g openclaw.
2. openclaw onboard --install-daemon run करें और prompts walk करें। --install-daemon flag gateway को managed background service के रूप में register करता है, ताकि Decision 7 में use होने वाले openclaw gateway stop और openclaw gateway start controls के पास actual service हो जिस पर act किया जा सके।
3. Persona configuration: OpenClaw का नाम Claudia रखें।
4. Model selection: model के रूप में claude-opus-4-7 pick करें।
5. Chat-app integration: primary chat app के रूप में Telegram configure करें। इसके लिए @BotFather के through Telegram bot create करना और onboard flow में bot token paste करना होगा।
6. Verification round-trip: Telegram में Claudia को hello message भेजें और confirm करें कि वह configured persona greeting से respond करती है।
7. Report back: OpenClaw config directory का path (typically ~/.openclaw/), Telegram bot username, और कोई भी onboard prompts जिन्होंने ऊपर specified choices से अलग choices माँगीं (ताकि मुझे पता रहे कौन से defaults pick हुए)।

क्या expect करें। आपका assistant install + onboard flow produce करता है, Telegram round-trip verify करता है, और configured state report करता है। Output में शामिल होना चाहिए:

• Maya के Mac पर OpenClaw config directory का path (typically ~/.openclaw/)
• Bot username जिससे Maya Telegram में Claudia तक पहुँचेगी
• Model और persona configuration confirmed
• Successful round-trip: Maya "hello" message करती है, Claudia persona में respond करती है

Troubleshooting:

• Homebrew first run पर admin password prompt करता है। Expected: system dependencies के लिए required. Approve करें और continue करें।
• Telegram BotFather setup fail होता है। Most common cause: Maya के पास Telegram account नहीं है। पहले one create करें (free, 2-minute setup), फिर openclaw onboard re-run करें।
• Claudia respond करती है लेकिन persona wrong है। Onboard flow की persona configuration save नहीं हुई। Config scope reset के साथ onboarding re-run करें: openclaw onboard --reset --reset-scope config.
• Install "downloading dependencies" पर hang होता है। Network या DNS issue. curl -fsSL https://openclaw.ai/health से verify करें और अगर वह fail करे तो Node.js install separately check करें।

Decision 1 का निचोड़। Working OpenClaw install जहाँ Maya Telegram में Claudia को message कर सकती है और persona-aware response पा सकती है। Config directory disk पर exist करती है; bot Telegram के साथ registered है; model set है। Downstream सब इसी foundation पर wire होता है।

अगर Decisions 2-7 में कुछ break हो, पहले ये तीन चीज़ें check करें

इस order में; OpenClaw + Paperclip integration के दौरान roughly 80% lab failures ये explain करते हैं।

1. OpenClaw cleanly installed नहीं या onboarding incomplete. Verify करने के लिए openclaw status run करें; अगर कुछ off लगे तो openclaw onboard re-run करें। Decisions 2-7 में mysterious failures का most common cause Decision 1 का partially-completed onboard है।
2. Paperclip running नहीं, या Maya की machine से reachable नहीं। Maya के Mac पर running OpenClaw को Paperclip के API endpoint तक reach कर पाना चाहिए। अगर Paperclip different machine या private network पर है, तो integration skill broken assume करने से पहले curl $PAPERCLIP_API_URL/api/health से connectivity verify करें।
3. Identic AI की board API key in place नहीं, या delegation layer incomplete. Full track में, Claudia real approval routes को Paperclip board API key से drive करती है (Decision 4): approval routes assertBoard() call करते हैं, इसलिए board-level credential वही है जिसे वे accept करते हैं। अगर वह board key missing या wrong है, Paperclip उसके calls को आपकी delegation layer run होने से पहले reject कर देता है। Separately, वह agent_api_keys entry वाले Paperclip agent के रूप में भी registered है, जो उसे identity और revocation surface देता है लेकिन approve call authenticate करने वाली चीज़ नहीं है। आपकी अपनी verification layer (Decision 5) ed25519 attestation और delegated envelope check करती है; अगर वह layer incomplete है, Claudia के decisions कभी POST /api/approvals/{id}/approve तक नहीं पहुँचते।

अगर तीनों में से कोई failure explain न करे, तो course-eight-issues GitHub label check करें।

Decision 2: Maya की persona onboard करें और उसका judgment context import करें

एक line में: Claudia को Maya की persona, role context (वह AI-native customer-support company की CEO है), और उसके past approval decisions की available history से configure करें ताकि Claudia के पास Maya के judgment का starting model हो।

Concept 10 context की तीन layers name करता है जिन्हें Claudia time के साथ accumulate करती है: standing instructions, per-decision feedback, derived patterns. Decision 2 historical record से तीनों layers seed करता है। इस seed के बिना, Claudia zero से शुरू करती है और Maya को overrides के through पहले महीने Claudia को scratch से सिखाना पड़ता है। इस seed के साथ, Claudia month one की शुरुआत लगभग 200 imported decisions जितनी pattern-matching से करती है; Maya के first-month overrides already-credible starting model refine करते हैं।

PRIMM: Predict

मान लें Maya के पास past approvals का clean JSON export नहीं है: वह नौ महीनों से Paperclip पर run कर रही है लेकिन उसने कभी अपनी decision history extract नहीं की। Claudia seed करने के तीन options: (a) import skip करें; Claudia को अगले roughly 30 days scratch से सीखने दें, (b) partial history export करें (last 30 days, Paperclip activity log से compile करना easy), या (c) Saturday spend करके full export script लिखें। Predict करें Course Eight कौन सा option recommend करता है, फिर briefing पढ़ें।

---

उत्तर: (b), last 30 days की partial history. Option (a) पहला month waste करता है; Maya Claudia को सिखाने का काम करती है लेकिन Claudia होने का benefit नहीं मिलता। Option (c) सही answer है अगर Maya के पास time है, लेकिन realistically most owners के पास नहीं होगा। Option (b) pragmatic middle है: 30 days की imported history high-volume decision types (refunds, budget overrides) पर Claudia को defensible starting model देती है, जबकि low-volume decisions (envelope-extension hires, terminations) Decision 4 की standing instructions के अनुसार explicit रहते हैं। Course की briefing assume करती है कि (c) achievable है; अगर नहीं, तो (b) पर fallback करें।

Brief. अपने agentic coding tool में plan mode पर switch करें, नीचे brief paste करें, tool से written plan produce करके docs/plans/decision-2.md में save करने को कहें, review करें, फिर plan mode से बाहर switch करके execute करें।

Claudia installed है; अब उसे Maya के specific role के लिए configure करें। Maya Courses Five-Seven में बनी AI-native customer-support company की founder/CEO है। Company के पास चार Workers हैं: Tier-1 Support, Tier-2 Specialist, Manager-Agent, और Legal Specialist, Paperclip के through managed. Requirements:

1. OpenClaw के agent workspace (~/.openclaw/workspace/) में persona document build करें। OpenClaw workspace में USER.md को अपने user के durable context के रूप में read करता है, इसलिए Maya की persona को ~/.openclaw/workspace/USER.md (या उससे referenced context/ file) में लिखें, capturing:
   • Maya का role (AI-native customer-support company की founder/CEO)
   • Company का current Worker roster और हर Worker क्या करता है
   • Maya का communication style (terse, direct, comma-spliced)
   • Courses Five-Seven से Maya के known policy thresholds (refund ceiling $500, monthly budget cap default $1,000, Course Seven Concept 9 से auto-approval policy active)
2. Maya की past approval history import करें। ./course-seven-export/approvals.json पर JSON export है जिसमें historical approval decisions हैं। OpenClaw की persistent memory workspace है, separate import store नहीं, इसलिए file को workspace में रखें (for example ~/.openclaw/workspace/context/approvals.json) और USER.md या MEMORY.md से reference करें ताकि OpenClaw इसे durable context के रूप में index करे। docs.openclaw.ai/concepts/session देखें।
3. Verification round-trip: Telegram के through Claudia से पूछें "what do you know about how I approve refunds?" और confirm करें कि वह imported history से drawn plausible answer return करती है (generic AI-assistant patter नहीं; response को imported decisions से specific patterns reference करने चाहिए)।
4. Report back: import skill का name, loaded session data की on-disk location, और verification round-trip का transcript.

क्या expect करें। आपका assistant produce करता है:

• Maya की persona ~/.openclaw/workspace/USER.md में लिखी हुई (human-readable; Maya review और edit कर सकती है)
• approvals.json workspace में durable context file के रूप में placed, USER.md या MEMORY.md से referenced ताकि Claudia उस पर draw करे
• Verification round-trip: Maya message करती है "what do you know about how I approve refunds?" और Claudia summary से respond करती है जैसे "Based on your past decisions, you approve about 94% of refunds under $500 without comment, about 70% in the $500 to $1,500 range with occasional surfacing, and surface nearly all over $1,500..." Exact phrasing vary करती है; matter यह करता है कि Claudia imported data पर draw करे, generic AI-assistant patter पर नहीं।

Troubleshooting:

• approvals.json export available नहीं। PRIMM-predicted fallback (b) use करें: Paperclip की activity_log table से last 30 days pull करने के लिए छोटा script लिखें, actor_type = 'user' और action in (approval.approved, approval.rejected, approval.revision_requested) पर filtering करके; per-decision detail details jsonb column में है।
• Claudia का verification response generic है ("I don't know your approval history yet"). Context file workspace में नहीं है या USER.md/MEMORY.md से referenced नहीं है। Confirm करें कि approvals.json ~/.openclaw/workspace/ के under है, कोई workspace file उसे point करती है, और JSON parsed हुआ (common failure malformed timestamp field है)। Gateway restart करें या fresh session start करें ताकि OpenClaw workspace re-index करे।
• Persona file में कुछ wrong है। maya.md directly edit करें। Claudia next interaction पर इसे re-read करती है।

Decision 2 का निचोड़। Claudia जानती है कि Maya कौन है, company कैसी दिखती है, और उसके पास Maya के past approval decisions का seeded model है। Layer 1 (standing instructions) Decision 4 में set होगा; Layer 2 (feedback) Maya operate करते हुए accumulate करेगा; Layer 3 (derived patterns) historical seed और आगे के decisions से accumulate करेगा।

Decision 3: Paperclip-integration skill build करें

एक line में: ऐसी OpenClaw skill लिखें जो Claudia को Paperclip approval queue read करने, Maya की Identic AI key से approval decisions sign करने, और उन्हें Paperclip API पर post करने दे।

यह load-bearing skill है: वही जो Claudia को "personal AI जिससे Maya chat कर सकती है" से "governance के लिए configured Maya की Identic AI" बनाती है। Skill OpenClaw की session-and-skill architecture (Concepts 5-6) और Paperclip की approval API (Course Six) के बीच bridge है। यही skill आपका सबसे ज़्यादा integration code carry करती है, OpenClaw skill plumbing और Paperclip API को wrap करने वाली signing-and-verification layer दोनों। इसे सही करने में time लगाएँ; Decisions 4-7 इसी पर build करते हैं।

Skill की तीन responsibilities, cleanly separated:

1. Pending approvals poll करना। हर 60 seconds (cron-style) या on demand जब Maya Claudia को message करती है। Polling cadence tradeoff है: faster का मतलब routine approvals पर lower latency; slower का मतलब Paperclip पर lower API load. 60 seconds defensible default है।
2. हर approval के बारे में reason करना। हर pending item के लिए, Claudia अपनी persona (Decision 2) plus standing instructions (Decision 4) plus accumulated patterns (time के साथ, Concept 10) use करके decide करती है: approve, request revision, या Maya को surface करना।
3. Decision sign और post करना। जब Claudia approve करने का decision लेती है, skill Maya की Identic AI signing key (Decision 4 में generated) से decision payload sign करती है। Decision आगे कहाँ जाता है यह एक हिस्सा track के हिसाब से diverge करता है, नीचे split देखें।

Simulated track

Responsibility 3 mock के single resolve route पर post करती है। mocks/paperclip-mock.ts में mock simplified shape रखता है: एक POST .../approvals/{id}/resolve route पूरे decision flow का stand-in है। Stand-in के लिए यह fine है; real-route logic सिर्फ full track में build करते हैं।

Full-implementation track

Responsibility 3 real Paperclip route पर post करती है। Paperclip 2026.513.0 में resolve verb नहीं है: decision verbs approve, reject, और request-revision हैं, हर एक अपनी POST sub-route. जब Claudia approve करने का decide करती है, skill POST /api/approvals/{approvalId}/approve call करती है (optional decisionNote के साथ)। ये routes assertBoard() call करते हैं: वे Paperclip board API key accept करते हैं, agent key नहीं। इसलिए skill जिस credential से post करती है वह board API key है जिसे Maya ने Decision 4 में Claudia के लिए mint किया। (Agent key इन routes पर 403 "Board access required" देता है; इसी वजह से delegation credential board-scoped है।) ed25519 signature आपकी अपनी attestation layer है, Paperclip जो check करता है वह नहीं। आपकी verification layer (Decision 5) signature verify करती है और delegated envelope check करती है before skill real route call करती है।

Brief. अपने agentic coding tool में plan mode पर switch करें, नीचे brief paste करें, tool से written plan produce करके docs/plans/decision-3.md में save करने को कहें, review करें, फिर plan mode से बाहर switch करके execute करें।

Claudia को Paperclip से बात करने देने वाली load-bearing skill build करें। docs.openclaw.ai/skills के अनुसार OpenClaw skills system से installable. तीन responsibilities, cleanly separated. Requirements:

1. Pending approvals poll करें। Pending-approvals queue को हर 60 seconds (configurable) hit करें, या जब Maya Claudia को message करे तो on demand invokable हो। Full track: GET /api/companies/{companyId}/approvals?status=pending. Simulated track: mock का equivalent queue route.
2. हर pending approval पर reason करें। हर item के लिए, Claudia से पूछें (OpenClaw के reasoning interface का use करके) कि approve करना है, revision request करनी है, या Maya को surface करना है। Claudia की persona context, Maya की standing instructions (Layer 1), और उसकी session से per-decision feedback patterns (Layer 2) use करें।
3. Decision sign और post करें। जब Claudia approve करने का decide करे, Maya की Identic AI signing key से decision payload sign करें (अभी placeholder path; real key Decision 4 में generate होगी)। फिर post करें: full track में optional decisionNote के साथ POST /api/approvals/{approvalId}/approve (call Claudia की Paperclip board API key से authenticated है, जो Decision 4 में mint होगी; approval routes board access require करते हैं, agent key नहीं); simulated track में mock का single POST .../approvals/{id}/resolve stub route. Signature आपकी अपनी attestation layer है; full-track verification Decision 5 में land करेगी।
4. Skill metadata. Skill का name paperclip-governance-delegate रखें। Configuration file ये parameters expose करे:
   • PAPERCLIP_API_URL
   • PAPERCLIP_COMPANY_ID
   • polling_interval_seconds (default 60)
   • signing_key_path (default ~/.openclaw/keys/identic-ai.pem)
5. Installation: locally-authored skill workspace skills directory में रहती है, ~/.openclaw/workspace/skills/paperclip-governance-delegate/SKILL.md पर (YAML frontmatter plus markdown body; folder name skill name से match करना चाहिए)। OpenClaw इसे next fresh session पर या openclaw gateway restart के बाद discover करता है। (openclaw skills install ClawHub से name द्वारा skills pull करने के लिए है, local skills के लिए नहीं।) openclaw skills list से confirm करें।
6. Dry-run mode (critical). --dry-run flag include करें जो Paperclip की real approval queue के against poll और reason करता है लेकिन decisions actually post किए बिना सिर्फ logs करता है कि Claudia क्या करती। Maya इसे live जाने से पहले confidence-building period के रूप में पहले week use करती है।
7. Report back: skill directory structure, manifest path, confirmation कि openclaw skills list skill दिखाता है, और sample dry-run log.

क्या expect करें। आपका assistant produce करता है:

• Skill directory ./paperclip-governance-delegate/ जिसमें skill manifest, polling loop, per-approval reasoning prompt template, और signing-and-posting logic शामिल हैं (placeholder के साथ जहाँ Decision 4 की real key plug in होगी)
• Configuration file (for example, config.yaml) exposed parameters के साथ
• --dry-run mode जो stdout/file में log करता है लेकिन post नहीं करता: first-week confidence period के लिए critical
• Skill locally installed और openclaw skills list में visible

Troubleshooting:

• Skill install होती है लेकिन run नहीं करती। OpenClaw skills को skill root पर SKILL.md manifest (YAML frontmatter plus markdown body) चाहिए; ~/.openclaw/workspace/skills/paperclip-governance-delegate/SKILL.md check करें, confirm करें frontmatter में name folder name से match करता है, और gateway restart करें ताकि OpenClaw workspace re-index करे।
• Polling succeeds लेकिन approvals नहीं लौटते जबकि pending ones होने चाहिए। Verify करें कि PAPERCLIP_COMPANY_ID वही company है जिसे आपने Course Seven में set up किया; verify करें API URL Claudia की machine से reachable है।
• Claudia का reasoning prompt similar approvals पर inconsistent results produce करता है। Reasoning template को ज़्यादा structure चाहिए; persona-driven judgment invoke करने से पहले standing instructions के explicit checks add करें।

Decision 3 की bottom line. Skill installed, configured, और dry-run mode में operational है। Claudia approval queue read कर सकती है और हर item के लिए reasoned decisions produce कर सकती है; वह अभी उन्हें post नहीं कर सकती क्योंकि signing key अभी exist नहीं करती। Decision 4 posting को real बनाता है।

Decision 4: Maya की Identic AI signing key generate करें और delegated envelope configure करें

एक line में: Claudia के लिए cryptographic key pair generate करें, Paperclip board API key mint करें जिससे वह approval routes drive करेगी, identity और revocation के लिए उसे Paperclip agent के रूप में register करें, और Claudia का delegated envelope configure करें (thresholds जिन पर वह autonomously act कर सकती है बनाम Maya को surface करेगी)।

इस Decision में दो architectural primitives ship होते हैं: cryptographic identity (Concept 8) और delegated envelope (Concept 9). दोनों एक बार set होते हैं और periodically revisit होते हैं; दोनों Claudia के हर downstream decision को shape करते हैं। Delegated envelope especially sensitive है: बहुत wide हुआ तो Claudia वे actions लेती है जिन्हें Maya देखना चाहती; बहुत narrow हुआ तो eighth-invariant scaling property kick in नहीं करती।

PRIMM: Predict

Maya पहली बार Claudia का delegated envelope configure कर रही है। उसका instinct conservatively start करना है: low refund ceiling, almost everything surface. Colleague (उसका co-founder) उल्टा argue करता है: wide start करें और Maya के overrides time के साथ Claudia को narrow कर दें। Predict करें Course Eight कौन सा approach recommend करता है, और first month का operational consequence क्या है।

---

उत्तर: Course Eight conservatively start करने की recommendation करता है, लेकिन deliberate widening plan के साथ। Reasons: (a) overrides Maya के लिए expensive हैं: हर override context-switch और feedback message है; अगर Claudia का envelope बहुत wide है, first month overrides का flood बन जाता है जो purpose defeat करता है। (b) Conservative starts Maya को ज़्यादा decisions trust करने से पहले Claudia की reasoning observe करने देते हैं। (c) Operationally widening tightening से आसान है: Maya Layer 1 instruction add करती है "you can now auto-approve refunds up to $X" और Claudia तुरंत adjust करती है; tightening ज़्यादा nuanced standing-instruction edits मांगता है। First month का operational consequence: surface rate लगभग 20 से 25% (high but bounded), override rate लगभग 3 से 5%, और month 2 तक दोनों numbers drop होते हैं जब Maya deliberately envelope widen करती है। Concept 10 का six-month walkthrough यही conservative start assume करता है।

Brief. अपने agentic coding tool में plan mode पर switch करें, नीचे brief paste करें, tool से written plan produce करके docs/plans/decision-4.md में save करने को कहें, review करें, फिर plan mode से बाहर switch करके execute करें।

Claudia की cryptographic identity generate करें और उसका delegated envelope configure करें। इस Decision में दो architectural primitives ship होते हैं: signing key (Concept 8) और delegated envelope (Concept 9). Requirements:

1. Fresh ed25519 key pair generate करें। Private key को strict permissions (chmod 600) के साथ ~/.openclaw/keys/identic-ai.pem पर store करें। Public key separately store करें; आपकी अपनी verification layer (Decision 5) इसे Claudia की attestations verify करने के लिए use करती है।

2. Optional hardware-backed storage (macOS only). अगर Maya macOS पर है और hardware-backed protection चाहती है, तो private key को filesystem के बजाय Keychain में store करने के लिए Security framework use करें; path Keychain reference बन जाता है।

3. Board API key mint करें, फिर Claudia को agent के रूप में register करें। Full track, दो distinct credentials:

   • Board API key delegation credential है। Paperclip के पास real board_api_keys table है, और approval routes assertBoard() call करते हैं, इसलिए board-level credential वही है जिसे वे accept करते हैं। इसे mint करना single CLI verb नहीं है: यह Paperclip का CLI auth-challenge flow है। {"requestedAccess": "board"} के साथ POST /api/cli-auth/challenges एक boardApiToken (pcp_board_... value) plus approvalUrl return करता है; Maya challenge approve करने के लिए उस URL को Paperclip dashboard में open करती है, और token तब live होता है। (local_trusted dev deployment पर token immediately issued होता है; real deployment पर dashboard-approval step human gate है।) Claudia वही boardApiToken hold करती है और उसी से post करती है। Conceptually यह board key delegation है: Maya अपनी Identic AI को board-level credential देती है, जिसे Paperclip नहीं बल्कि आपकी अपनी delegation layer (Decision 5) deliberately scope down करती है।
   • Agent registration identity plus revocation surface है। Claudia को real Paperclip agent के रूप में register करें (agents में row) और उसके लिए agent_api_keys entry issue करें। यह उसे Paperclip identity और Decision 7 में Maya द्वारा revoke करने योग्य surface देता है। यह approve call authenticate करने वाली चीज़ नहीं है। Respect करने योग्य real constraints: agents.role server-validated enum है जिसमें identic_ai value नहीं, general use करें; adapterType enum-validated है (claude_local, acpx_local, codex_local, ...), claude_code नहीं; और कोई paperclipai agent create CLI verb नहीं है, agent creation API-only है POST /api/companies/{companyId}/agents के through (paperclipai agent local-cli <ref> verb सिर्फ already existing agent के लिए key mint करता है)।
   • Delegated envelope को principal_permission_grants row के रूप में record करें जिसकी scope jsonb envelope thresholds hold करती है। Paperclip इसे store करता है; approve route पर enforce नहीं करता (आपकी Decision 5 layer करती है)।

   Simulated track: mock का stub registration endpoint call करें, जो principal id return करता है और आपके लिए envelope store करता है। Either way, public key alongside registered है ताकि आपकी verification layer Claudia के signatures check कर सके।

4. Conservative initial delegated envelope. Maya इसे बाद में standing instructions से widen कर सकती है। ये thresholds encode करें:

   • Refunds: $2,000 तक auto-approve; ऊपर कुछ भी surface
   • Existing envelope के अंदर hires: auto-approve
   • Company envelope extend करने वाली hires: हमेशा Maya को surface
   • Terminations: हमेशा Maya को surface
   • Budget overrides: monthly cap से 20% over तक auto-approve; ऊपर कुछ भी surface
   • CMA migrations: first quarter के लिए surface; बाद में सिर्फ $1,000/mo budget से कम Workers के लिए auto-approve
   • Standing-policy edits: हमेशा Maya को surface

5. Maya confirmation step (submit करने से पहले required). Claudia के through Maya को Telegram message भेजें: "Here's the proposed delegated envelope: [JSON summary]. Reply CONFIRM to register, or send edits." Registration सिर्फ Maya के CONFIRM response पर submit करें।

6. Credentials और ids persist करें। Successful registration पर, Claudia की session में store करें: board API key जिससे वह approval decisions post करती है, उसका registered agent id (full track) या mock का principal id (simulated track), और envelope के लिए principal_permission_grants id. Decision 3 skill posting करते समय board key use करती है; Decision 7 revoke करते समय agent id और agent_api_keys id use करता है।

7. Envelope को disk पर write करें। Final envelope JSON को ~/.openclaw/governance/delegated-envelope.json में save करें ताकि Maya बाद में Claudia की authority widen या narrow करते समय इसे directly edit कर सके।

8. Report back: key fingerprint (private key itself नहीं), Keychain reference अगर use हुई, board API key id, registered agent id और agent_api_keys id, और Maya के CONFIRM round-trip का transcript.

क्या expect करें। आपका assistant produce करता है:

• Fresh ed25519 key pair, configured path पर 600 permissions के साथ private key (या Keychain में अगर Maya ने वह option चुना)
• Optional macOS Keychain integration अगर Maya Mac पर है और hardware-backed storage चुना
• Telegram round-trip जिसमें Maya proposed envelope देखती है और CONFIRM करती है
• Full track: minted Paperclip board API key (delegation credential), agent_api_keys entry के साथ Paperclip agent के रूप में registered Claudia (identity plus revocation surface), और principal_permission_grants row के रूप में stored delegated envelope. Simulated track: mock का stub registration.
• Direct editing के लिए ~/.openclaw/governance/delegated-envelope.json में persisted envelope

Troubleshooting:

• Call करने के लिए identity-registration endpoint नहीं। Full track: यहाँ invent करने के लिए custom Paperclip endpoint नहीं है। आप board_api_keys से board API key mint करते हैं, Paperclip के real agent primitive (POST /api/companies/{companyId}/agents, फिर agent_api_keys entry issue) से Claudia register करते हैं, और delegated envelope को principal_permission_grants row के रूप में record करते हैं। कोई paperclipai agent create CLI verb नहीं है; agent creation API-only है। Decision 5 आपकी अपनी verification layer build करता है जो इन्हें read करती है, new Paperclip route नहीं। Simulated track: mock stub registration endpoint ship करता है; अगर 404 return करे, वही stub आप implement करते हैं (यह simulated-track work का हिस्सा है, full track का नहीं)।
• _Agent registration role या adapterType पर rejected. _ दोनों server-validated enums हैं। role में identic_ai value नहीं, general use करें। adapterType claude_local, acpx_local, codex_local, और similar में से है, claude_code नहीं। Claudia का "Identic AI" character आपके governance_ledger में रहता है, Paperclip के agent enums में नहीं।
• Maya CONFIRM नहीं करती; envelope edit करना चाहती है। Expected और fine. Conservative defaults starting points हैं; Maya के operations से specific values हो सकती हैं। उसके edits के साथ proposed envelope re-send करें और CONFIRM फिर request करें।
• Key permissions error (chmod 600 fails). Filesystem-level issue; check करें कि ~/.openclaw/keys/ directory Maya के user की owned है।

Decision 4 की bottom line. Maya की Identic AI अब Paperclip board API key hold करती है (वह credential जिससे वह approval routes drive करती है) और Paperclip agent के रूप में registered है (उसकी identity और revocation surface), configured delegated envelope carry करती है जो Paperclip पर recorded है लेकिन आपकी अपनी Decision 5 layer द्वारा enforced है। Conservative initial envelope का मतलब first month "surface-heavy" लगेगा: यही point है। Widening deliberately standing-instruction edits के through होती है, initial over-permissioning से नहीं।

Decision 5: Delegation-and-verification layer build करें

एक line में: वह layer build करें जो Claudia की credentials को meaningful बनाती है, gates जो Paperclip तक कोई decision पहुँचने से पहले उसकी ed25519 attestation verify करते हैं और delegated envelope check करते हैं, plus आपकी अपनी governance_ledger table. Full track में यह layer आपकी integration skill में रहती है और Paperclip के real approval routes wrap करती है; simulated track में यह mock में रहती है।

Decisions 1-4 ने Claudia set up की और उसे credentials दिए; Decision 5 उन credentials को meaningful बनाता है। यहीं trust-delegation primitive (Concept 7), signed-delegation verification (Concept 8), और two-envelope intersection (Concept 9) सब live code बनते हैं। Decision 5 के बिना, Claudia जितने decisions sign करना चाहे कर सकती है: कोई signature verify नहीं करता या envelope check नहीं करता, इसलिए signed decision सिर्फ unchecked API call है।

PRIMM: Predict

Verification layer build करने से पहले, इसके बारे में single most counterintuitive fact का answer predict करें। Decision 4 में आपने Claudia के लिए दो Paperclip credentials mint किए: board API key और agent API key। उनमें से एक वह credential है जिसे वह real approval routes (POST /api/approvals/{id}/approve और friends) drive करने के लिए actually use करती है। दूसरा सिर्फ उसकी identity और revocation surface है।

Predict करें: approval routes कौन drive करता है, board API key या agent API key? और यह वही क्यों होगा, जबकि Claudia agent है, board member नहीं?

---

उत्तर: board API key. यही counterintuitive हिस्सा है। Paperclip के approval routes (approve, reject, request-revision) सभी assertBoard() call करते हैं: वे board-level credential accept करते हैं और कुछ नहीं। Agent API key, even Claudia की अपनी, इन routes पर 403 "Board access required" पाती है। इसलिए Claudia को approval decision drive करने वाला credential board-scoped होना चाहिए। इसी वजह से Decision 4 में Maya ने Claudia के लिए board API key mint किया: board key, आपकी अपनी delegation layer द्वारा deliberately scoped down, delegation है। Agent registration Claudia को Paperclip identity और Decision 7 में Maya द्वारा revoke करने योग्य चीज़ देता है, लेकिन approve call authenticate करने वाली चीज़ नहीं है। अगर आप verification layer इस expectation से build करेंगे कि agent key approval routes पर काम करेगी, तो Claudia का हर decision आपके gates run होने से पहले 403 होगा। (Simulated track: mock का single /resolve route यह distinction enforce नहीं करता; यह full-track reality है। Simulated track फिर भी इसे सिखाता है ताकि बाद में full पर जाने पर आपका mental model correct रहे।)

Rules से पहले concrete anchor. इस पूरी layer का behavior समझाने का clearest single explanation एक routine refund है जो end-to-end Claudia की reasoning, three gates, real Paperclip call, और दोनों audit rows से होकर गुजरता है। पहले यह trace पढ़ें; फिर नीचे three gates और route reference lookup की तरह पढ़ेंगे, cold absorb करने वाली चीज़ की तरह नहीं। Trace अपनी full-implementation-track shape में दिखाया गया है: real Paperclip routes, real activity_log columns. Entries illustrative हैं: data की shape दिखाने के लिए synthesized, running implementation से exported नहीं। (Simulated track में steps spirit में same हैं, लेकिन mock का single /resolve route और simplified row shapes real Paperclip surface के stand-in हैं।)

Routine refund लगभग 40 seconds में pending से recorded decision तक जाता है, fully autonomous और fully audited, दो joinable audit rows और zero human interruption के साथ।

1. Approval Paperclip पर आता है। Envelope ceiling से ऊपर refund request_board_approval approval के रूप में modeled है, refund detail payload jsonb के अंदर है (Paperclip का approval type enum hire_agent, approve_ceo_strategy, budget_override_required, request_board_approval है; कोई refund type नहीं)। ध्यान दें approvals पर top-level issueIds column नहीं है: issue links separate issue_approvals join table में रहते हैं, और row लिखते समय service details.linkedIssueIds populate करता है।

{
  "id": "apr_01HZ4Q...",
  "companyId": "co_maya...",
  "type": "request_board_approval",
  "status": "pending",
  "requestedByAgentId": "worker_tier1_support",
  "payload": {
    "kind": "refund",
    "amountCents": 89000,
    "currency": "USD",
    "customerId": "C-3421",
    "accountAgeDays": 1167,
    "priorRefunds6mo": 0,
    "reason": "billing-error-duplicate-charge"
  },
  "createdAt": "2026-05-12T09:14:03.117Z"
}

2. Claudia की polling skill इसे pick करती है (Decision 3 से; polling cadence लगभग 60s है):

[2026-05-12T09:14:42] claudia.skill.paperclip-governance-delegate:
  poll GET /api/companies/co_maya/approvals?status=pending → found 1 pending (apr_01HZ4Q...)
  routing to per-approval reasoning prompt

3. Claudia reason करती है (per-approval reasoning prompt template से, Decision 3):

[2026-05-12T09:14:42] claudia.reasoning:
  input: approval=apr_01HZ4Q..., payload.kind=refund, amount=$890, customer_age=3.2yr, prior_refunds=0
  layer-1 check (standing instructions):
    - "auto-approve refunds under $2,000 with no prior refunds and account >2yr" → MATCH
  layer-3 pattern (derived):
    - "Maya tends to approve fast in this band; ~91% historical match" → REINFORCES
  decision: approve
  confidence: 0.91
  reasoning_summary: "Long-tenure customer (3.2yr), no prior refunds, amount within
                     delegated envelope ($2,000 ceiling), pattern reinforces standing rule."

4. Claudia की delegation layer decision sign और gate करती है (Decision 5 के three gates, Paperclip को कोई call करने से पहले run):

[2026-05-12T09:14:43] delegation-layer.gate-check:
  signed decision payload with ed25519 (signature ed25519:k7n2m...8q3w)
  gate 1: signer's credentials recognized and unrevoked (board API key bk_claudia_maya;
          agent ag_claudia_maya registered) → PASS
  gate 2: ed25519 signature verifies against Claudia's registered public key → PASS
  gate 3: delegated envelope (principal_permission_grants.scope):
    payload.kind=refund, amount=$890, ceiling=$2,000 → IN ENVELOPE → PASS
  all gates passed → calling the real Paperclip route

5. Delegation layer real Paperclip approve route call करती है (POST /api/approvals/{approvalId}/approve, Claudia की board API key से authenticated, क्योंकि approve route board access require करता है):

[2026-05-12T09:14:43] delegation-layer.post:
  POST /api/approvals/apr_01HZ4Q.../approve
  auth: Claudia's board API key
  body: { "decisionNote": "auto-approved by Owner Identic AI; attestation ed25519:k7n2m...8q3w" }
  → 200 OK  (the approval's status is now 'approved'; this is a recorded decision,
             it does not move issue iss_3421 or resume a Worker)

6. Paperclip activity_log row write करता है (real columns; approve route board action है, इसलिए row actor_type='user' है, actor_type='agent' नहीं):

{
  "id": "act_8z2k...",
  "company_id": "co_maya...",
  "actor_type": "user",
  "actor_id": "local-board",
  "agent_id": null,
  "action": "approval.approved",
  "entity_type": "approval",
  "entity_id": "apr_01HZ4Q...",
  "details": {
    "type": "request_board_approval",
    "linkedIssueIds": ["iss_3421"],
    "decisionNote": "auto-approved by Owner Identic AI; attestation ed25519:k7n2m...8q3w"
  },
  "created_at": "2026-05-12T09:14:43.298Z",
  "run_id": null
}

यह row बिल्कुल वैसी दिखती है जैसी Maya खुद approval resolve करती तो लिखती। Paperclip उन्हें अलग नहीं बता सकता; आपकी अपनी governance_ledger में अगली row distinction carry करती है।

7. आपकी governance_ledger Claudia की parallel row write करती है (आपकी अपनी additive table, schema docs/governance-ledger-schema.sql में):

{
  "ledger_id": "gov_2k8z...",
  "approval_id": "apr_01HZ4Q...",
  "principal": "owner_identic_ai",
  "acting_on_behalf_of": "owner_human_maya",
  "signer_agent_id": "ag_claudia_maya",
  "action_taken": "approve",
  "confidence": 0.91,
  "layer_source": "standing_instruction",
  "layer_reference": "si_refund_under_2000_long_tenure_no_priors",
  "reasoning_summary": "Long-tenure customer (3.2yr), no prior refunds, amount within delegated envelope, pattern reinforces standing rule.",
  "attestation": "ed25519:k7n2m...8q3w",
  "override_status": null,
  "timestamp": "2026-05-12T09:14:43.298Z"
}

Total elapsed: pending approval से recorded decision तक लगभग 40 seconds (mostly Claudia की reasoning latency plus signature crypto). Maya interrupt नहीं हुई। दोनों rows, Paperclip की activity_log row (board action, actor_type='user') plus आपकी governance_ledger row with principal='owner_identic_ai', later decision recoverable बनाते हैं: Maya SQL-query से दोनों tables (approval id पर joined) query करके reconstruct कर सकती है कि Claudia ने exactly क्या किया और क्यों। Paperclip की row alone उसे नहीं बता सकती कि उसने resolve किया या Claudia ने; governance_ledger row यही answer देती है। ध्यान दें step 5 ने क्या नहीं किया: decision record किया; issue iss_3421 move नहीं किया या Worker resume नहीं किया। उस issue को आगे drive करना separate explicit step है (PATCH /api/issues/iss_3421 उसका status set करने के लिए, या Worker assign करना ताकि वह इसे pick up करे), exactly जैसा Course Six और Seven ने सिखाया।

यही पूरी layer एक trace में है। Steps 4, 5, और 7 exactly वही हैं जो Decision 5 build करता है: three gates, real Paperclip call, और governance_ledger write. Decision 5 का बाकी हिस्सा उस trace के पीछे के rules हैं: पहले three gates detail में, फिर route reference lookup table के रूप में जिसे आप जरूरत पड़ने पर scan करते हैं, linearly पढ़ने की चीज़ नहीं।

दो tracks यहाँ sharply diverge करते हैं। अपने track का block पढ़ें।

Simulated track

आप local mock mocks/paperclip-mock.ts में gating और identity endpoints implement करते हैं, जहाँ signed-delegation gating और stub registration endpoint पहले से stubs के रूप में marked हैं जिन्हें भरना है। Mock simplified shape रखता है: single POST .../approvals/{id}/resolve route पूरे decision flow का stand-in है, और mock खुद resolve करने से पहले three gates run करता है। यही working content simulated track के लिए build और test किया गया था; इसे exactly mock के stubs के layout के अनुसार build करें।

नीचे brief, simulated form में: mock के /resolve stub को signature और signer_principal_id accept करने के लिए modify करें, three gates run करें (signer registered, signature verifies, action stored envelope के अंदर), और success पर mock activity_log entry और governance_ledger.json row दोनों write करें। Mock के stub registration और revocation endpoints implement करें। फिर नीचे shared "what to expect" notes पर jump करें।

Full-implementation track

ऊपर worked trace ने layer running दिखाई। यह block उसके पीछे के rules है, तीन parts में: (A) आप क्या build करते हैं, (B) three gates detail में, (C) route reference lookup table के रूप में। A और B पढ़ें; C skim करें और actual calls wire करते समय लौटें।

Part A: आप क्या build करते हैं (और क्या नहीं)। Build करने के लिए कोई new Paperclip endpoints नहीं हैं। Paperclip 2026.513.0 approval routes, board_api_keys table, agents registry, agent_api_keys, principal_permission_grants, और activity_log already own करता है। Decision 5 में आप paperclip-governance-delegate skill के अंदर अपनी delegation layer build करते हैं, plus अपनी additive governance_ledger table. Paperclip कभी signature verify नहीं करता और approve route पर delegated envelope enforce नहीं करता; आपकी layer दोनों करती है, और तभी Claudia की board API key से real Paperclip route call करती है।

Part B: हर decision के लिए three gates, order में। यह worked trace के steps 4 और 5 हैं, detail में।

1. Gate 1, signer recognized principal है। Confirm करें Claudia की credentials अभी भी good हैं: उसकी board API key (जिससे वह post करती है) present और not revoked है, और उसकी registered agents row plus agent_api_keys entry अभी भी exist करती है (Decision 7 यहाँ revoke करता है)। Revoked board key approval routes पर 403 पाती है; revoked agent key agent-only routes fail करती है। यह gate fast fail करता है और आपकी governance_ledger में auditable है।
2. Gate 2, signature verification. Claudia की ed25519 signature को canonical-JSON decision payload पर उसके registered public key के against verify करें। यह आपकी अपनी attestation layer है; यही prove करती है कि decision Claudia की key से आया और tamper नहीं हुआ। Paperclip के पास signature field नहीं, इसलिए यह gate सिर्फ आपकी layer में exist करता है।
3. Gate 3, delegated envelope. Claudia के principal_permission_grants.scope jsonb से delegated envelope read करें और test करें कि claimed action (type, amount) इसके अंदर है। Paperclip यह row store करता है लेकिन approve route पर enforce नहीं करता, इसलिए यह gate आपकी layer की discipline है, Paperclip-enforced boundary नहीं। Enforced authority owner के envelope और delegated subset का intersection है (Concept 9).

Then: तीनों gates pass होने पर, real Paperclip route (Part C) call करें, Claudia की board API key से authenticated, optional decisionNote के साथ (audit के लिए आप वहाँ ed25519 signature echo कर सकते हैं)। और governance_ledger row write करें (आपकी अपनी table, schema docs/governance-ledger-schema.sql में), approval id द्वारा Paperclip के activity_log से joinable. वह row owner-human vs owner-identic-ai distinction carry करती है; Paperclip का activity_log नहीं (नीचे honesty correction देखें)।

Part C: real Paperclip routes जिन्हें आपकी layer call करती है (2026.513.0 के against verified; lookup table, calls wire करते समय scan करें, memorize करने की ज़रूरत नहीं):

• POST /api/approvals/{approvalId}/approve (board caller के लिए 200), body {decisionNote?}. Body decidedByUserId भी carry कर सकता है, लेकिन Paperclip इसे ignore करता है: route decision को authenticated actor से attribute करता है, उस field से नहीं। इसे meaningful input न मानें।
• POST /api/approvals/{approvalId}/reject (200), POST /api/approvals/{approvalId}/request-revision (200). तीनों assertBoard() call करते हैं: agent-API-key caller को 403 "Board access required" मिलता है।
• Poll के लिए GET /api/companies/{companyId}/approvals?status=pending (200), one read करने के लिए GET /api/approvals/{approvalId} (200)
• Audit trail read back करने के लिए GET /api/companies/{companyId}/activity (200)

ध्यान दें action routes flat हैं (/api/approvals/{id}/approve), company-scoped नहीं। कोई resolve verb और कोई PATCH /api/approvals/{id} नहीं: decision verbs approve, reject, और request-revision हैं, हर एक POST sub-route.

Paperclip का activity_log approvals के लिए क्या record करता है, इस पर honest रहें। यह load-bearing correction है। Approval routes board actions हैं: हर activity_log row जो वे write करते हैं actor_type='user', actor_id='local-board' (board user id), agent_id=null है। Claudia द्वारा resolved approval और Maya द्वारा खुद resolved approval दोनों actor_type='user' के रूप में land करते हैं; Paperclip उन्हें अलग नहीं बता सकता, क्योंकि Paperclip के लिए दोनों board callers हैं। activity_log में actor_type='agent' real है, लेकिन issue, heartbeat, और run activity के लिए, approval decision के लिए कभी नहीं। इसलिए two-principal distinction approvals के लिए Paperclip से inherit नहीं होती। यह आपकी governance_ledger में रहती है: Claudia जो row लिखती है वह principal='owner_identic_ai' उसकी attestation और reasoning के साथ carry करती है, और यही Claudia-resolved approval को Maya-resolved one से अलग बताती है। Course exactly इसलिए governance_ledger build करता है: यह वह audit truth है जो Paperclip approvals के लिए natively provide नहीं करता। Architecture as designed काम कर रही है, falling short नहीं।

Approving decision record है, state machine नहीं। यह earlier draft का single most important correction है। Paperclip में approval approve करना decision record करता है। यह linked issue का status change नहीं करता, payload action execute नहीं करता, और कोई Worker resume नहीं करता। कोई step.wait_for_event Worker-resume Paperclip approvals से wired नहीं है (वह primitive Inngest, Course Five का है)। Approval के बाद काम continue करना separate, explicit step है: PATCH /api/issues/{id} से issue का status move करना, या Worker assign करना ताकि उसका next heartbeat issue pick करे, या agent_wakeup_request enqueue करना। आपकी delegation layer का job "decision recorded है और governance_ledger row written है" पर end होता है; follow-on work drive करना अपनी अलग step है, exactly जैसा Course Six और Seven ने सिखाया।

Brief. अपने agentic coding tool में plan mode पर switch करें, नीचे brief paste करें, tool से written plan produce करके docs/plans/decision-5.md में save करने को कहें, review करें, फिर plan mode से बाहर switch करके execute करें।

Delegation-and-verification layer build करें। Full track: यह layer paperclip-governance-delegate skill में रहती है और Paperclip के real approval routes wrap करती है; आप कोई Paperclip endpoints add नहीं करते। Simulated track: equivalent gating और stub endpoints mocks/paperclip-mock.ts में implement करें। Requirements:

1. Three gates, किसी भी decision post होने से पहले run. Claudia जो हर decision reach करती है:
   • Gate 1, signer recognized principal है। Full track: confirm करें Claudia की board API key (जिससे वह post करती है) present और not revoked है, और उसकी agents row plus agent_api_keys entry still exist. Simulated track: mock के registration store में signer_principal_id look up करें। Recognized या unrevoked न हो तो refuse करें और refused attempt record करती governance_ledger row write करें (forgery और stale-key attempts auditable होने चाहिए)।
   • Gate 2, signature verification. Claudia की ed25519 signature को canonical-JSON decision payload पर उसके registered public key के against verify करें। Invalid हो तो refuse और record करें। Paperclip के पास signature field नहीं; यह gate सिर्फ आपकी layer में रहता है।
   • Gate 3, delegated envelope. Full track: Claudia के principal_permission_grants.scope jsonb से envelope read करें। Simulated track: mock ने registration पर जो envelope store किया उससे read करें। Claimed action (type, amount) को उसके against test करें; outside हो तो refuse और record करें। Paperclip approve route पर इसे enforce नहीं करता; आपकी layer करती है।
2. तीनों gates pass होने पर, decision post करें। Full track: real Paperclip route call करें, POST /api/approvals/{approvalId}/approve (या /reject, या /request-revision), Claudia की board API key से authenticated (approval routes board access require करते हैं), optional decisionNote के साथ (audit के लिए signature echo कर सकते हैं)। Simulated track: mock के single /resolve stub route से resolve करें।
3. Paperclip attribution के बारे में honest रहें; fake न करें। Paperclip की row पर actor field invent न करें। Full track में, approve route board action है: Paperclip खुद activity_log row write करता है with actor_type='user', actor_id='local-board' (board user id), agent_id=null, entity_type='approval', entity_id=<approval id>, action='approval.approved'. Claudia-resolved approval और Maya-resolved approval activity_log में identical दिखते हैं। Owner-human vs owner-identic-ai distinction आपकी governance_ledger row carry करती है, Paperclip नहीं। Simulated track में, mock teaching clarity के लिए native principal attribution implement करता है; real Paperclip से यह expect न करें।
4. Worker resume न करें। Approving decision record है। यह linked issue change नहीं करता या कुछ resume नहीं करता। Work continue करना separate explicit step है (PATCH /api/issues/{id} status set करने के लिए, या Worker assign करना, या agent_wakeup_request enqueue करना); यह layer के scope से बाहर है।
5. governance_ledger table create करें schema के साथ जो docs/governance-ledger-schema.sql में है। यह आपकी अपनी additive table है; Paperclip schema touch नहीं करती। Claudia जो हर decision करती है (posted या refused), उसके लिए one row write करें, approval id से activity_log से joinable.
6. Revocation, Decision 7 के लिए। Full track: Claudia की credentials revoke करना board-credentialed operation है। DELETE /api/agents/{id}/keys/{keyId} agent_api_keys entry revoke करने का real route है (यह revoked_at set करता है); Claudia की held board API key revoke करना parallel move है। दोनों को owner-human की board credentials चाहिए; आपके build करने के लिए कोई endpoint नहीं। Simulated track: mock का stub revocation endpoint implement करें, और उसे mock की owner-human auth require कराएँ, Identic-AI signature कभी नहीं।
7. Library suggestions: TypeScript में ed25519 के लिए @noble/ed25519 use करें; Node में built-in crypto module; signing के लिए canonical JSON keys sort करे और whitespace strip करे ताकि signer और verifier byte-match करें।
8. Report back: gate implementation, हर gate का successful test (refusal paths सहित), real Paperclip route call (full track) या mock resolve (simulated track), और sample governance_ledger row.

क्या expect करें। आपका assistant produce करता है:

• Three-gate verification layer: signer-is-registered-agent, signature verifies, action delegated envelope के अंदर
• Standard ed25519 library से signature verification (TypeScript में @noble/ed25519 typical choice है; Node में built-in crypto module काम करता है)
• Envelope intersection logic जो delegated envelope read करता है (full track में principal_permission_grants.scope, simulated track में mock store) और claimed action को उसके against test करता है
• Full track: Claudia की board API key के साथ POST /api/approvals/{id}/approve और friends को real calls, Paperclip द्वारा actor_type='user' carry करने वाली activity_log rows written (approve route board action है)। Simulated track: equivalent करता mock का /resolve route, mock की native principal attribution के साथ।
• आपकी अपनी governance_ledger table created और Claudia के हर decision के लिए row written: owner-human vs owner-identic-ai distinction यहीं रहती है

Troubleshooting:

• Signature verification tests में काम करता है लेकिन real key के against fail होता है। Most common: payload encoding mismatch. Verify करें signer और verifier दोनों signing/verifying से पहले same canonical JSON encoding (sorted keys, no extra whitespace) use करते हैं।
• Envelope check उन actions के लिए pass होता है जो outside envelope होने चाहिए। scope में envelope (या mock store) intended से ज़्यादा permissive है। Edge cases explicitly test करें: $2,000 envelope के against $2,000.01 refund fail होना चाहिए; exactly $2,000 refund inclusive vs exclusive semantics पर depend करता है (एक pick करें, document करें)।
• Approving ने issue move नहीं किया या Worker resume नहीं किया। यह correct behavior है, bug नहीं। Paperclip approval decision record है। Work continue करना separate explicit step है; decision record होने के बाद उस step को अपने आप wire करें।
• governance_ledger rows written हैं लेकिन Maya की weekly summary (Concept 11) उन्हें include नहीं करती। Different concern; यह Decision 6+ wiring issue है, Decision 5 नहीं। पहले verify करें ledger में rows हैं।

Decision 5 की bottom line. आपकी delegation layer Claudia की attestation verify करती है, delegated envelope enforce करती है, और तभी real Paperclip approval routes को उसकी board API key से drive करती है (full track) या mock को (simulated track)। Real Paperclip के against approve route board action है, इसलिए activity_log किसी भी way actor_type='user' record करता है; owner-human vs owner-identic-ai distinction आपकी अपनी governance_ledger में रहती है, जो exactly audit truth है जिसे provide करने के लिए course इसे build करता है। यहाँ से Claudia जो भी करती है इसी verification path से flow करता है।

Decision 6: Routine approvals के flood plus one consequential के साथ end-to-end demonstration

एक line में: Course Seven workforce के against realistic week जितनी approval requests generate करें, ज्यादातर routine, एक consequential, और देखें Claudia routines autonomously handle करती है जबकि consequential one Maya को Telegram पर correctly surface करती है।

यही वह moment है जहाँ eighth-invariant promise operationally observable बनता है। Decisions 1-5 setup हैं; Decision 6 proof है। अगर demonstration scaling property नहीं दिखाता (Claudia routine fast handle करती है, consequential Maya को surface करती है, हर decision के लिए governance_ledger row), तो earlier कुछ wrong है। Demonstration को prior Decisions की verification और architecture का honest stress-test दोनों treat करें।

PRIMM: Predict

आप Paperclip में 30 synthetic approval requests inject करने वाले हैं और Claudia को handle करते देखेंगे। Mix: $500 से $1,500 range में 22 refunds, $1,500 से $2,000 range में 4 refunds, cap से 10 से 15% over पर 2 budget overrides, 1 new-language Tier-2 hire (no envelope extension), 1 envelope-extension hire.

एक standing instruction इस prediction के लिए matter करती है, यहाँ restated ताकि आपको ढूँढना न पड़े। Maya की standing instruction है कि new language में first hire strategic moment है और उसे surface करना ज़रूरी है, भले ही hire को envelope extension न चाहिए। (यह instruction Concept 1 PRIMM ने establish किया था।)

दो predictions:

1. Decision 4 के conservative envelope के under, 30 में से कितने Claudia autonomously handle करेगी (auto-approve) और कितने Maya को surface करेगी?
2. उन सभी autonomous-decision processing में end-to-end roughly कितना time लगना चाहिए (60-second poll cycle assume करके)?

---

उत्तर:

1. 28 autonomous, 2 surfaced. $500 से $1,500 वाले 22 refunds सभी delegated envelope में हैं, इसलिए सभी autonomous (22). $1,500 से $2,000 वाले 4 refunds अभी भी $2,000 ceiling के under हैं, इसलिए autonomous (4 और, total 26). 10 से 15% वाले 2 budget overrides 20% ceiling के under हैं, इसलिए autonomous (2 और, total 28). New-language hire Maya की Concept 1 PRIMM Predict से standing instruction के अनुसार delegated envelope के बाहर है (Spanish-language first hire strategic moment है), इसलिए surfaced. Envelope-extension hire definition से delegated envelope के बाहर है, इसलिए surfaced. 2 surfaced, 28 autonomous.
2. Total 2 से 3 minutes. 60-second poll cycle के साथ, Claudia injection के बाद first poll cycle पर 30 requests pick करती है। Routine cases के लिए हर एक पर reasoning roughly 3 से 5 seconds लेती है (prompt template short है, decisions clear हैं)। सभी 28 autonomous decisions roughly 2 minutes में resolve होते हैं। 2 surfaced Maya के Telegram पर जाते हैं और उसके response का wait करते हैं, जो Claudia के processing time में count नहीं होता।

अगर आपकी prediction बहुत off है, तो envelope या polling architecture की understanding में कुछ wrong है। Demonstration को recalibrate करने के लिए use करें।

Brief. अपने agentic coding tool में plan mode पर switch करें, नीचे brief paste करें, tool से written plan produce करके docs/plans/decision-6.md में save करने को कहें, review करें, फिर plan mode से बाहर switch करके execute करें।

Full pipeline end-to-end demonstrate करें। Realistic distribution के साथ 30 approval requests का synthetic workload generate करें, उन्हें Paperclip पर post करें, और verify करें कि Claudia routine items autonomously handle करती है जबकि consequential ones surface करती है। Requirements:

1. 30 synthetic approval requests generate करें इस distribution के साथ:
   • $500-$1,500 range में 22 refunds (Claudia should auto-approve)
   • $1,500-$2,000 range में 4 refunds (Claudia auto-approves but flags in weekly summary)
   • Cap से 10-15% over पर 2 budget overrides (Claudia auto-approves)
   • Spanish-Language Tier-2 Specialist के लिए 1 hire proposal with no envelope extension (Concept 1's PRIMM Predict की standing instruction के अनुसार Claudia Maya को surface करती है: "first hire in a new language is a strategic moment")
   • 1 envelope-extension hire proposal (Claudia surfaces; by definition delegated envelope से बाहर)
2. सभी 30 Paperclip की approval queue में inject करें (full track: POST /api/companies/{companyId}/approvals से create करें; simulated track: mock का queue-injection helper). Claudia की polling skill trigger करें (या next 60-second poll cycle का wait करें)।
3. Precise timing capture करें। हम इसे ऊपर PRIMM Predict की prediction से compare करेंगे।
4. Audit trail के against verify करें:
   • 28 approvals अब status: approved होने चाहिए। Full track: हर एक के पास matching Paperclip activity_log row है, और क्योंकि approve route board action है वह row actor_type='user', actor_id='local-board', agent_id=null carry करती है। Fact कि Claudia (Maya नहीं) ने इसे drive किया आपकी governance_ledger में recorded है, activity_log में नहीं। Simulated track: mock की equivalent rows.
   • 28 में से हर एक के पास principal='owner_identic_ai' वाली governance_ledger row भी है: वही row decision को Claudia से attribute करती है
   • 2 approvals अभी भी status: pending होने चाहिए, Maya का wait करते हुए
5. Verify करें Maya को Telegram messages मिले। उसे Claudia से 2 messages मिलने चाहिए जो 2 surfaced approvals summarize करते हैं, हर एक में Claudia की reasoning कि उसने auto-approve करने के बजाय surface क्यों किया।
6. Verify करें timing prediction से match करता है (order of magnitude के अंदर; actual numbers model latency पर depend करते हैं)।
7. Governance_ledger verify करें। Concept 11 के schema fields के साथ 28 rows written होनी चाहिए: action_taken, confidence, layer_source, reasoning_summary, attestation.
8. Maya-response round-trip. Maya से 2 surfaced approvals में से एक खुद resolve करवाएँ (Spanish-language hire approve करें) as owner-human: full track, Paperclip dashboard के through; simulated track, mock का human-resolve path. Verify करें decision recorded है और Paperclip नई activity_log row with actor_type='user' write करता है, entity_id से surfaced approval के साथ joinable. (Decision record करना linked issue को खुद move नहीं करता; follow-on step separate है।)
9. Maya override exercise करे (Concept 12 mechanic, mandatory). Claudia ने जिन 28 approvals को auto-approved किया, उनमें से एक pick करें, band के top के पास refund अच्छा choice है, और Maya से reverse करवाएँ: review पर वह decide करती है कि इसे auto-approved नहीं होना चाहिए था। उस approval की row पर governance_ledger.override_status field को overridden_by_owner write करके override record करें, override_reason के साथ (for example, "this customer has a pattern I want to see myself"). यह real Concept 12 recalibration mechanic है: override training data है, सिर्फ correction नहीं। Verify करें row अब override_status='overridden_by_owner' दिखाती है और reason captured है।
10. Audit-trail JOIN खुद run करें (spine observable बनी)। Starter zip से /verify-audit-trail slash command run करें (यह approval id पर activity_log JOIN governance_ledger perform करता है)। Directly observe करें: Claudia-resolved approval और Maya-resolved Spanish-language hire activity_log alone में indistinguishable हैं, दोनों actor_type='user'; सिर्फ governance_ledger row, Claudia वाले के लिए present और Maya वाले के लिए absent, reveal करती है कि कौन Identic AI का था। यह two-principal distinction है, पढ़ा नहीं बल्कि observed.
11. Claudia से weekly governance summary generate करवाएँ (Concept 11 digest, सिर्फ पढ़ी नहीं, built). Telegram के through Claudia से कहें कि इस demonstration ने जो governance_ledger rows अभी write की हैं उनसे weekly governance digest produce करे: totals, category breakdown, Maya ने अभी जो one override किया, और confidence flags. इसकी shape Concept 11 के sample summary से compare करें। यही digest Maya weekly consume करती है; यहाँ आप इसे real ledger rows से एक बार generate करते हैं ताकि form factor concrete हो, सिर्फ described नहीं।
12. Report back: timing breakdown, audit-row counts (activity_log + governance_ledger), Maya को मिले two Telegram messages, Maya-response flow, override row, JOIN-query output, और generated weekly summary.

क्या expect करें। आपका assistant workload generate करता है, demonstration run करता है, और report back करता है:

• Roughly 2 से 3 minutes में 28 autonomous approvals resolved
• Claudia की reasoning attached के साथ Telegram में Maya का wait करते 2 surfaced approvals
• Activity_log board-action rows दिखाता है; governance_ledger 28 rows reasoning summaries और confidence scores के साथ दिखाता है
• Maya का response एक surfaced approval पर resolution तक flow करता है
• Maya द्वारा one auto-approval overridden, override_status और override_reason governance_ledger row पर written
• /verify-audit-trail JOIN output, दिखाता है कि Claudia-resolved और Maya-resolved approvals activity_log में identical हैं और सिर्फ governance_ledger से distinguished हैं
• Demonstration की real ledger rows से built Claudia-generated weekly governance summary

Troubleshooting:

• Demonstration run होता है लेकिन Maya को Telegram messages नहीं पहुँचते। Decision 1 का chat-app integration skill की surfacing logic में wired नहीं है। Skill का notification handler check करें।
• Claudia कुछ ऐसा approve करती है जो surface करना चाहिए था। Decision 5 का envelope check too permissive है। Specific approval को Concept 9 के intersection logic से हाथ से walk करें कि कौन सा check miss हुआ।
• Timing predicted से बहुत slow है (10x या more). Model latency usual culprit है। Prompt template length check करें; अगर हर decision के लिए verbose context include करता है, latency multiply होती है। Prompt को essentials तक trim करें।

Worked trace Decision 5 में है। Decision 6 क्या produce करता है इसका clearest single explanation Decision 5 की शुरुआत का seven-step worked approval thread है: one routine refund end-to-end, Claudia की reasoning, three gates, real Paperclip call, और दोनों audit rows से होकर। Decision 6 वही trace है, 28 times parallel में run, 2 surfaced के साथ। अगर आपने skip किया, अभी पढ़ें: वह single autonomous approval की concrete picture है, और यहाँ demonstration वही picture volume पर है।

2 surfaced approvals 28 autonomous ones से अलग दिखते हैं। Surfaced approval के लिए, Claudia action_taken: "surface_to_owner" वाली governance_ledger row write करती है और Paperclip approve route call करने के बजाय Maya को Telegram message भेजती है। जब Maya बाद में surfaced approval खुद resolve करती है (full track: Paperclip dashboard; simulated track: mock का human-resolve path), उसका action Paperclip activity_log row with actor_type='user' और actor_id set to her board user id write करता है। वह row वही shape रखती है जो Claudia की delegation layer ने 28 autonomous approvals के लिए produce की: दोनों board actions हैं। Two-principal distinction approval id पर activity_log को governance_ledger से join करके observable है: Claudia-resolved approval में principal='owner_identic_ai' वाली governance_ledger row है; Maya direct resolve करे तो ऐसी row नहीं। Distinction आपके ledger में रहती है, activity_log में नहीं।

Decision 6 की bottom line. End-to-end pipeline काम करता है, और आपने अब spine कर लिया है, सिर्फ पढ़ा नहीं। Delegate primitive का promise (Claudia routine fast handle करती है, consequential surface करती है, उसका हर decision governance_ledger में recorded) operationally observable है: आपने activity_log JOIN governance_ledger query खुद run की और देखा कि two-principal distinction आपके ledger में रहती है, Paperclip के audit trail में नहीं। आपने Claudia के auto-approvals में से एक को override_status field में reverse करके Concept 12 override mechanic exercise किया। और आपने Claudia से real ledger rows से Concept 11 weekly digest generate करवाया। यही वह moment है जहाँ course का central architectural claim code में verified होता है, और यही reason है कि course governance_ledger build करता है।

Decision 7: Stolen-laptop recovery और device-switch continuity

एक line में: दो operational scenarios simulate करें, Maya का laptop चोरी हो जाता है (different device से Claudia की Paperclip credentials revoke करें) और Maya नया Mac लेती है (उसकी OpenClaw session उस पर migrate करें), और verify करें दोनों flows correctly काम करते हैं।

Concept 8 ने stolen-laptop case को load-bearing failure mode नाम दिया। जिस architecture के पास इसका recovery story नहीं, वह fragile है। Decision 7 verify करता है कि recovery story काम करती है, उसे scratch से लिखकर नहीं, बल्कि दो realistic scenarios में revocation flow exercise करके। Successful Decision 7 proof है कि Maya की Identic AI recoverable है, सिर्फ deployable नहीं।

Revocation को काम कराने वाला mechanism: Claudia दो Paperclip credentials hold करती है, board API key (जिससे वह approval routes drive करती है) और agent_api_keys entry (उसकी agent identity). Claudia revoke करने का मतलब दोनों revoke करना है: board API key, और DELETE /api/agents/{id}/keys/{keyId} के through agent key (जो revoked_at set करता है)। Board key revoke होते ही "stolen" OpenClaw session approval routes पर 403 पाता है; agent key revoke होते ही agent-only routes भी fail होते हैं। Full track में, दोनों revocations owner-human की board credentials से लिए गए Paperclip-side actions हैं; किसी भी के लिए Identic-AI signature path नहीं। Simulated track में, mock का stub revocation endpoint equivalent करता है।

Dev में revoked key test करने पर note. local_trusted dev mode में, board route पर revoked या invalid bearer token silently ignored होता है और request local-board actor पर fallback कर जाती है, इसलिए "revoked key से approve route पर post करो" revocation cleanly demonstrate नहीं करता। इसके बजाय agent-only route पर test करें (for example GET /api/agents/me, जो revoked agent key के लिए 401 return करता है), या direct revoked_at column check करें। नीचे brief agent-only route use करता है।

दो scenarios different failure modes cover करते हैं:

Scenario	Failure mode	हम क्या test कर रहे हैं
Stolen laptop	Adversarial: किसी के पास Maya की signing key + दोनों API keys हैं	Revocation काम करता है; new agent + board-key registration काम करता है; old keys dead
Planned device switch	Operational: Maya new machine पर move करना चाहती है	Session migration काम करती है; new device की Claudia old के साथ consistent है

Brief. अपने agentic coding tool में plan mode पर switch करें, नीचे brief paste करें, tool से written plan produce करके docs/plans/decision-7.md में save करने को कहें, review करें, फिर plan mode से बाहर switch करके execute करें।

Sequence में दो scenarios test करने हैं: stolen-laptop revocation, फिर planned device switch. Requirements:

Scenario 1, stolen-laptop revocation:

1. Loss simulate करें। Maya के primary Mac को compromised treat करें: attacker के पास Claudia की ed25519 signing key और उसकी दोनों Paperclip credentials हैं (board API key और agent API key).
2. Claudia की Paperclip credentials revoke करें। Different device से (Maya अपने board credentials से second device पर Paperclip में log in करती है), दोनों revoke करें: Claudia की board API key, और उसकी agent_api_keys entry via DELETE /api/agents/{id}/keys/{keyId} (full track; simulated track: mock का stub revocation endpoint call करें)। यह Maya की owner-human board credentials से होना चाहिए, Identic-AI signature से कभी नहीं: compromised Identic AI खुद को revoke या re-register करने में सक्षम नहीं होनी चाहिए।
3. Human-auth requirement verify करें। Board credentials के बजाय Identic-AI-signed request से revocation attempt करें और confirm करें कि यह rejected है। (यह safety property verify करता है: compromised Identic AI खुद को revoke नहीं कर सकती।)
4. Verify करें old keys dead हैं। "Stolen" OpenClaw session से, Claudia की now-revoked agent API key के साथ agent-only route, GET /api/agents/me, call करें; Paperclip को 401 return करना चाहिए। (Approve route से test न करें: local_trusted dev mode में board route पर revoked bearer silently ignored होता है और local-board पर fallback होता है, इसलिए approve route revocation नहीं दिखाएगा। Agent-only route clean test है। DB में directly revoked_at check करना भी काम करता है।)
5. Fresh device पर re-register करें। Different machine पर, new ed25519 key pair generate करें, fresh board API key mint करें, और Claudia को Paperclip agent के रूप में fresh agent_api_keys entry के साथ फिर register करें, सब Maya की board-credentialed session के through, same persona, same delegated envelope (principal_permission_grants.scope) as before.
6. Verify करें Claudia fully operational है new device पर।

Scenario 2, planned device switch:

7. पहले DAEMON STOP करें (critical step). Old device पर openclaw gateway stop run करें और openclaw status से confirm करें कि process अब running नहीं। Daemon running रहते हुए live session directory copy करने से embedded SQLite database corrupt हो सकता है या new device silently recent decisions drop कर सकता है जो Claudia ने लिए थे। Clean stop non-negotiable है।
8. Session copy करें। Old device से ~/.openclaw/ new one पर move करें, signing keys directory को छोड़कर, जो regenerate होगी।
9. New device पर new key pair generate करें। Fresh board API key mint करें और Claudia को fresh agent API key के साथ Paperclip agent के रूप में register करें, सब Maya की board-credentialed session के through, old credentials के replacement के रूप में (governance ledger में Claudia identity continuous रहती है; सिर्फ credentials change होती हैं)। फिर old board API key और old agent_api_keys entry revoke करें।
10. New device पर daemon start करें। openclaw gateway start run करें और openclaw status से verify करें।
11. Session continuity verify करें। New device पर Claudia से पूछें "what was the last approval you handled?"; उसे old device की session से actual last approval reference करना चाहिए। Persona, standing instructions, learned patterns: सब present.
12. Verification approval run करें। Fresh approval request भेजें; confirm करें Claudia उसे correctly handle करती है, audit entries old device जैसे consistent हैं।

हर scenario के लिए documentation: transition के across क्या preserved था, क्या not preserved था और क्यों, और Maya को manually क्या करना पड़ा vs क्या automatic था।

क्या expect करें। आपका assistant दोनों scenarios run करता है और report करता है:

• Stolen-laptop scenario: owner-human की board credentials से revocation succeeds, Identic-AI-signed request से fails (correctly). "Stolen" session की revoked agent key GET /api/agents/me पर 401 return करती है, और उसकी board key approval routes पर 403 return करती है। Fresh device पर new board API key plus agent registration, Maya की board-credentialed session से done, fully operational है। Claudia की persona, standing instructions, और accumulated patterns survived (क्योंकि वे Maya के filesystem पर session में रहते हैं, जिसे stolen laptop ने लिया, इसलिए practically Maya अपनी backup से session restore करती है; architectural test verify करता है कि patterns themselves उस backup से recoverable हैं)।
• Device-switch scenario: session filesystem copy से intact migrate होती है। New device की Claudia same persona, history, और patterns रखती है। Fresh board API key plus agent re-registration ही credential-level change है। Governance ledger intact और continuous रहता है।

Troubleshooting:

• Revocation path Identic-AI-signed request accept करता है। Auth requirement wrong है; revocation को owner-human की board credentials require करनी चाहिए। इसे fix करें (full track: revocation by construction board-credentialed Paperclip action है, इसलिए check करें कि आप इसे Claudia की agent auth के through route नहीं कर रहे; simulated track: mock का stub revocation endpoint fix करें)। Compromised Identic AI खुद को revoke करने में सक्षम नहीं होनी चाहिए।
• New device की Claudia के पास old session नहीं। Filesystem copy से session migration simplest case है; अगर fail करे, check करें कि पूरी ~/.openclaw/ copy हुई (skills, persona, history), सिर्फ configuration files नहीं।
• Transition के दौरान governance ledger में gap है। Expected अगर transition meaningful time लेता है; gap document करें और confirm करें Maya ने switch के दौरान कोई in-flight approvals lose नहीं किए।

Decision 7 की bottom line. दोनों failure modes covered हैं। Maya stolen laptop से recover कर सकती है; Maya cleanly new device पर migrate कर सकती है। Architecture की recovery story verified है, सिर्फ declared नहीं। Lab यहीं conclude होता है।

---

Part 5: Operational realism: Identic AI क्या सीखती है और audit कैसे काम करता है

Part 4 का lab working Owner Identic AI produce करता है। Part 5 इस बारे में है कि time के साथ क्या होता है: Claudia Maya के छह महीनों के decisions से क्या सीखती है, Maya parallel ledger के through Claudia के behavior को कैसे audit करती है, और जब Claudia और Maya disagree करें तो क्या करना है। तीन Concepts, Course Seven के Part 5 जैसी same shape.

Concept 10: Identic AI छह महीनों में क्या सीखती है

Decision 6 की demonstration में, Claudia पहले से 200 imported historical approval decisions (Decision 2) और standing-instructions document (Decision 4) से configured थी। वही starting state है। Six months operation में, Claudia बहुत ज़्यादा accumulate करती है, और Concept 10 walk through करता है कि किस kind का accumulation उसे Maya की Identic AI बनने में सच में help करता है, Maya की life का सिर्फ chat log नहीं।

Accumulated context की तीन layers.

Layer 1: explicit standing instructions. Maya Telegram में Claudia को चीज़ें बताती है। Instructions first-class हैं: Claudia उन्हें record, index, और reliably apply करती है। वे वे rules हैं जिन्हें Maya consciously लिखती है। Month three तक Maya ने शायद ऐसे concrete examples दिए हों:

• "Envelope-extension hires हमेशा मुझे surface करें, no exceptions."
• "Customer-account-age two years से ऊपर हो तो $300 से कम refunds auto-approve करें."
• "पिछले छह महीनों में तीन से ज़्यादा prior refunds वाले customers के refunds हमेशा मुझे surface करें, amount चाहे जो हो."
• "Operation के पहले 30 days में Workers के budget overrides हमेशा मुझे surface करें."
• "Legal Specialist के authority envelope को touch करने वाली कोई भी चीज़ कभी auto-approve न करें."

ये company policy जैसे पढ़ते हैं क्योंकि वही हैं: Maya की policy, plain language में expressed, incrementally accumulated जब वह discover करती है कि वह actual में कौन से rules चाहती है।

Layer 2: per-decision feedback. हर बार Maya Claudia को override करती है, Maya feedback देती है। ये patterns की corrections हैं, explicit rules के ऊपर layered. Concrete examples:

• (Claudia ने $1,400 refund auto-approved किया। Maya override करती है।) "आपको यह surface करना चाहिए था। यह customer हमारे साथ 6 weeks से है, यह long-tenure pattern नहीं है जिस पर मैं trust करती हूँ."
• (Claudia ने routine Tier-1 hire Maya को surface की। Maya approve करती है और add करती है:) "आप इन्हें मेरे बिना approve कर सकती हैं। $300/month से कम Tier-1 hires, established envelope, यही exactly auto-approve case है."
• (Claudia ने 4-month-old Worker पर 18% budget override approve किया। Maya override नहीं करती लेकिन comment करती है:) "इस बार fine, लेकिन आगे note करें कि इस Worker के दो overrides लगातार हुए हैं; third मेरे पास आना चाहिए."

ये feedbacks Claudia की session में join करते हैं और future behavior refine करते हैं। Critically, वे सिर्फ corrections नहीं हैं; वे Maya की reasoning include करते हैं। Reasoning ही Claudia को बाद में similar-but-not-identical cases पर lesson apply करने देती है।

Layer 3: derived patterns. Time के साथ Maya के decisions देखकर, Claudia ऐसे models build करती है जिन्हें Maya ने rules के रूप में कभी state नहीं किया। Concrete examples जो month five तक emerge हो सकते हैं:

• "Maya Mondays पर Fridays से ज़्यादा fast refunds approve करती है। Possible inference: Friday refunds ज़्यादा scrutinized होते हैं, शायद weekend customer-service load की वजह से."
• "अगर Worker की recent activity log single large-cost incident दिखाती है, तो Maya auto-approve envelope के अंदर भी budget-override requests surface करती है."
• "Maya ने पिछले 40 days में Tier-1 product line की हर hire approve की है; new EU product line की हर hire surface की है। Pattern suggest करता है कि EU line different trust phase में है."

हर derived pattern confidence level के साथ आता है। कुछ 50 decisions के बाद strong होते हैं; कुछ 500 के बाद भी wrong. Identic AI का honest होना कि decision किस layer से आ रहा है, वही Maya को recalibrate करने देता है जब उसे करना चाहिए।

Six-month walkthrough. Maya अपने पहले छह महीनों में Claudia के साथ rough order में यह experience कर सकती है:

Month	क्या हो रहा है	Claudia क्या कर रही है
0 (Decisions 1-4)	OpenClaw installed; 200 historical approvals imported; 8 standing instructions configured	Imported history pattern-match करती है; standing instructions reliably apply करती है; ~20% decisions surface करती है क्योंकि patterns अभी thin हैं
1	Maya Claudia को ~12 times override करती है; हर बार feedback देती है	Layer 2 feedback session में join करता है; similar cases पर behavior month के अंदर visibly improve होता है
2	Maya recurring surface patterns के response में 3 और standing instructions add करती है	Surfacing rate ~12% तक drop होता है; auto-approval reliability hold करती है
3	पहला emerging Layer 3 pattern: Claudia note करती है कि Maya first-month Workers पर budget overrides surface करती है; proactively surface शुरू करती है	Maya confirm करती है कि pattern right है; अगली बार Maya edit करती है तो यह explicit rules in Layer 1 join करता है
4-5	Surfacing rate लगभग 8-10% पर stabilize होता है; override rate ~3% तक drop होता है; weekly governance-ledger reviews ~10 minutes लेते हैं	Steady state; Layer 3 patterns accumulate हो रहे हैं लेकिन slowly
6	Novel case आता है: Manager-Agent regulatory-compliance task के लिए Worker hire करने का propose करता है, ऐसा task जो किसी Worker ने पहले hold नहीं किया	Claudia recognizes "no pattern, surface" and routes to Maya; Maya fresh judgment करती है, reasoning comment करती है, new pattern के रूप में join करता है

Trajectory notice करें: early months feedback (Layer 2) और explicit rules (Layer 1) में heavy हैं, क्योंकि Maya actively Claudia को teach कर रही है। Month 4-5 तक corrections की rate sharply drop होती है, इसलिए नहीं कि Claudia ने हर case memorize कर लिया, बल्कि इसलिए कि Maya की decision-making style reasonably captured है। Month 6 तक, Maya का attention novel cases, recalibrations, और weekly summaries पर खर्च होता है। Eighth-invariant promise, कि Maya का attention उन चीज़ों के लिए free है जिन्हें सच में उसके judgment की ज़रूरत है, इस trajectory में operationally observable है।

Teachable और not teachable की boundary. Maya की session में सब कुछ teachable pattern नहीं है। Lower layers (explicit instructions, per-decision feedback) reliably applied हैं; third layer (derived patterns) probabilistic है और quality vary करती है। Good Identic AI difference बताती है और honest रहती है कि वह किस layer से draw कर रही है। Claudia अपनी weekly governance summary में कह सकती है: "इस week मैंने आपके explicit instruction के आधार पर 47 refunds auto-approved किए; मैंने learned patterns के आधार पर 3 आपके पास defer किए लेकिन मैं उनके बारे में सिर्फ moderately confident हूँ." वही honesty Maya को recalibrate करने देती है जब उसे करना चाहिए (Concept 12).

AI के साथ try करें

इसे अपने AI coding assistant में paste करें: "Concept 10 describes three layers of context an Owner Identic AI accumulates: explicit standing instructions, per-decision feedback, and derived patterns. Given the three layers, design a one-paragraph instruction Claudia could include in her weekly governance summary that makes it clear to Maya which decisions came from which layer, so Maya knows where to focus her recalibration attention. The instruction should be concrete enough that Maya can act on it; vague enough that it doesn't require Claudia to re-explain her reasoning in detail every week. Show me three different drafts of this instruction, varying how prominent the layer-attribution is."

आप क्या सीख रहे हैं: layer-attribution problem honest Identic AI design के लिए central है। अगर Claudia hide करती है कि वह किस layer से draw कर रही है, Maya अच्छी तरह recalibrate नहीं कर सकती। अगर Claudia बहुत explain करती है, weekly summary unreadable हो जाती है। Right balance design choice है; exercise आपसे वही choice करवाता है और tradeoff दिखाता है।

निचोड़: छह महीनों में, Claudia context की तीन layers accumulate करती है: Maya द्वारा लिखी explicit standing instructions (Layer 1, reliable), Maya द्वारा Claudia के wrong होने पर दिया per-decision feedback (Layer 2, reliable, Maya की reasoning include करता है), और Maya को decide करते देखकर Claudia द्वारा learned derived patterns (Layer 3, probabilistic, confidence vary करता है)। Months के across trajectory heavy active-teaching (months 1-3) से occasional novel-case recalibration वाले steady-state (months 4-6+) तक है। Good Identic AI किसी भी given decision में honest रहती है कि वह किस layer से draw कर रही है; वही honesty Maya के recalibration loop को काम कराती है।

Concept 11: Governance ledger: Identic AI का audit stream

Course Seven में talent ledger company का audit stream था: workforce history के across हर hire, eval, retirement, और rehire event, SQL से queryable. Course Eight parallel audit stream add करता है: governance ledger, जो Maya की ओर से Claudia द्वारा लिए गए हर decision को record करता है।

दो parallel ledgers, हर एक के लिए one source of truth. Talent ledger record करता है कि workforce ने क्या किया। Governance ledger record करता है कि Maya की Identic AI ने Maya की ओर से क्या किया। वे join key share करते हैं (approval ID, source issue ID, Worker ID), ताकि analyst correlate कर सके (time के साथ Worker X को affect करने वाले कौन से decisions Maya ने खुद लिए vs Claudia ने उसकी ओर से?), लेकिन वे separately maintained distinct sources of truth हैं। Maya governance ledger own करती है; company talent ledger own करती है।

Schema, concretely. Governance ledger में हर row capture करती है:

governance_ledger
├── ledger_id                  -- primary key for this governance row
├── timestamp                  -- ISO 8601, millisecond resolution
├── approval_id                -- joins to talent_ledger / activity_log
├── source_issue_id            -- joins to the originating issue (refund request, hire proposal, etc.)
├── principal                  -- "owner_identic_ai" (always: this ledger is Identic-AI-only)
├── acting_on_behalf_of        -- the human owner's ID (Maya's ID)
├── action_taken               -- approve / request_revision / surface_to_owner / decline
├── confidence                 -- 0.0 to 1.0: Claudia's self-rated confidence
├── layer_source               -- "standing_instruction" / "per_decision_feedback" / "derived_pattern"
├── layer_reference            -- the specific instruction or pattern that triggered (FK)
├── reasoning_summary          -- 1-2 sentences explaining why
├── override_status            -- null initially; "overridden_by_owner" if Maya later corrected
└── override_reason            -- if overridden, Maya's stated reason (joins back as Layer 2 feedback)

Field names Part 4 के Decision 6 के worked example से match करते हैं: ledger_id, approval_id, principal, acting_on_behalf_of, action_taken, confidence, layer_source, layer_reference, reasoning_summary, override_status, timestamp.

Sample week की entries. Maya के governance ledger की four rows plain English में कैसी दिख सकती हैं:

Time	Action	Why	Layer	Confidence
Mon 09:14	Customer C-3421 को $890 refund approve किया	Customer account-age 3.2 years है, prior refunds नहीं, मेरे "long-tenure, low-prior" pattern (Layer 3) से match करता है	derived_pattern	0.91
Mon 11:02	Maya को surfaced: customer C-7755 को $1,400 refund	Customer के last 4 months में 2 prior refunds हैं; आपकी standing instruction (Layer 1: "more than 3 prior refunds, always surface") almost trigger करती है; मैंने 2 पर conservatively surface किया	standing_instruction	0.78
Tue 03:11	Worker W-tier1-eu-3 के लिए 12% budget override approve किया	Worker month 4 में है, override activity log से documented incident handle करने के लिए है, delegated envelope के अनुसार auto-approve	standing_instruction	0.96
Wed 16:48	Maya को surfaced: Compliance Specialist के लिए hire proposal	Talent ledger में इस type की prior hire नहीं; कोई learned pattern नहीं; defaulting to surface	derived_pattern (absence)	0.45

हर row queryable, joinable, exportable है। Maya raw नहीं पढ़ती; उसकी weekly summary इससे generated होती है।

Weekly review pattern. Maya governance ledger weekly उसी तरह पढ़ती है जैसे Course Seven board talent ledger पढ़ता है: row by row नहीं, summary के रूप में। Claudia Maya के Telegram पर weekly digest भेजती है। Realistic example:

Weekly Governance Summary, Week of May 6-12

Totals: 142 decisions handled. 134 auto-approved (94%). 8 surfaced to you (6%). You overrode 1 of my auto-approvals (0.7%).

Category breakdown:

• Refunds: 97 (94 approved, 3 surfaced)
• Budget overrides: 28 (27 approved, 1 surfaced)
• Substrate migrations: 12 (12 approved)
• Policy-edit confirmations: 5 (2 approved, 3 surfaced)

इस week आपका override: customer C-4429 को $1,847 refund (Tuesday). आपका comment: "this customer has multiple prior refunds, should have surfaced." मैंने pattern update किया है: last 6 months में 2+ prior refunds वाले customers के लिए, मैं अब amount चाहे जो हो surface करूँगी। (Layer 2 feedback joined.)

Confidence flags जिन्हें मैं चाहती हूँ आप glance करें:

• मैंने confidence 0.62-0.68 पर दो refunds approve किए (मेरे usual 0.85+ threshold से lower). दोनों unusual patterns involve करते थे जो मैंने अक्सर नहीं देखे। अगर आप spot-check करना चाहें, वे ledger में rows G-2204 और G-2241 पर हैं।
• One derived pattern emerge होना शुरू हो रहा है: आपके decisions में refund timing day of week से vary होती दिखती है। मैं अभी इस पर act नहीं कर रही, too early.

Next week का expected load: workforce के current size और पिछले 4 weeks के आधार पर, ~150 decisions expect करें। कोई major projects मेरा expected workload change नहीं कर रहे।

यही form factor Maya actual में consume करती है। Row-by-row review नहीं, raw logs नहीं, structured weekly summary जिसमें patterns, exceptions, और confidence flags surfaced हैं।

Weekly review Maya को loop में right scale पर रखता है। वह हर decision नहीं पढ़ती; वह decision patterns और exceptions पढ़ती है। Governance ledger Claudia के छह महीनों के actions को queryable, summarizable audit में बदलता है जिस पर Maya act कर सकती है, history के blob में नहीं।

Example SQL query जो Maya run कर सकती है। मान लें customer-success team member Maya से single customer पर refund decisions की series के बारे में पूछता है। Maya अपनी ledger query कर सकती है:

SELECT timestamp, action_taken, reasoning_summary, layer_source, override_status
FROM governance_ledger
WHERE source_issue_id IN (
  SELECT issue_id FROM activity_log
  WHERE customer_id = 'C-4429'
)
ORDER BY timestamp;

Result उस customer को touch करने वाले issues पर Claudia द्वारा लिए गए हर governance decision का full audit है। Maya verify कर सकती है कि Claudia ने customer सही handle किया, identify कर सकती है कि कोई decisions उसके पास आने चाहिए थे या नहीं, और learnings वापस feed कर सकती है। Governance ledger delegated governance को सिर्फ operational नहीं, auditable बनाता है।

AI के साथ try करें

इसे अपने AI coding assistant में paste करें: "I'm designing the governance ledger schema for an Owner Identic AI. The schema from Concept 11 of Course Eight is a reasonable starting point. Given the schema, design three additional queries Maya might want to run beyond the customer-issue example. For each query, write the SQL and explain what operational question Maya is answering. The queries should be the kind of thing Maya would actually want to ask during a weekly review or when investigating a specific concern, not synthetic exercises."

आप क्या सीख रहे हैं: governance ledger सिर्फ decisions log करने की वजह से valuable नहीं है; valuable इसलिए है कि Maya इसे interrogate कर सकती है। Queries जिन्हें आप चाहेंगे, spectrum पर exist करती हैं: "Claudia ने इस week क्या किया" (weekly review) से "क्या Claudia ने यह specific situation सही handle की" (investigation) से "क्या Claudia के learned patterns drift हो रहे हैं" (calibration check) तक। आप कौन सी queries लिखेंगे, यह बताता है कि आप ledger को actual में किस लिए use करने की उम्मीद करते हैं।

निचोड़: governance ledger Maya की ओर से Claudia द्वारा लिए गए हर decision का audit stream है, append-only, queryable, weekly Maya के लिए summarized. यह Course Seven के talent ledger का parallel है: दो audit streams, हर एक के लिए one source of truth, approval और issue IDs से joined. Weekly summary architecture को owner के scale पर self-monitoring बनाती है; Maya individual rows नहीं, patterns और exceptions पढ़ती है। SQL queryability investigation को tractable बनाता है जब Maya को इसकी ज़रूरत हो।

Concept 12: जब Identic AI का judgment और owner diverge करते हैं

Part 5 का सबसे important operational concept यह है कि जब Maya Claudia से disagree करे तो कैसे handle करें। Concept 11 के बाद reader का instinct हो सकता है कि यह failure mode है: Claudia ने कुछ wrong किया, Maya correct करती है, ideally यह दोबारा नहीं होता। यह instinct wrong है। Maya और Claudia के बीच disagreement healthy signal है, और architecture इसे punishing के बजाय productive बनाने के लिए design की गई है।

Disagreement healthy क्यों है। तीन reasons:

First, कोई derived pattern first attempt पर right नहीं होता। Claudia के Layer 3 patterns (Concept 10) learned approximations हैं। कुछ 50 decisions के बाद good होंगे; कुछ 500 के बाद भी wrong. कौन सा कौन है, यह discover करने का only way है देखना कि वे कहाँ fail होते हैं। अगर Claudia और Maya कभी disagree नहीं करते, Claudia अभी novel territory में pushed नहीं हुई; patterns stress-tested नहीं हुए। Disagreement signal है कि Claudia के reliable judgment की boundary touch हुई है।

Second, Maya का judgment evolve होता है। Month one की Maya और month six की Maya same person नहीं हैं: उसने अपने business के बारे में चीज़ें सीखी हैं, market change हुआ है, workforce grow हुई है। Month one में Claudia ने जो patterns सीखे, वे धीरे-धीरे out of date होंगे। Disagreement signal है कि Maya का judgment move हुआ है और Claudia को catch up करना है।

Third, recalibration loop खुद teaching moment है। जब Maya Claudia को override करती है, वह usually one-sentence reason देती है ("this customer has prior refunds, should have surfaced"). वह reason per-decision feedback layer (Concept 10 की Layer 2) में join करता है। अगली बार similar pattern उठे, Claudia new feedback को old pattern के against weigh करती है। Override सिर्फ correction नहीं; यह training data है जिसे Claudia future behavior refine करने के लिए use करती है।

Escape valve. Architecturally, Maya हमेशा Claudia को override कर सकती है। जब Maya Claudia के decision को reverse करती है, उसका override fresh board action है: वह new activity_log row write करता है (board action, exactly any owner-human decision जैसा) और Claudia की original governance_ledger row पर override_status को overridden_by_owner set करता है, Maya के reason के साथ। Original Identic AI decision और Maya की correction दोनों preserved रहते हैं, और governance_ledger full story बताती है, क्योंकि Paperclip का अपना activity_log Claudia के decision और Maya के override दोनों को board actions के रूप में identically record करता है। ऐसा कोई failure mode नहीं है जहाँ Maya अपनी ही company से अपनी Identic AI द्वारा lock out हो जाए। Architecture की commitment है कि human always recoverable है।

Unhealthy patterns. तीन patterns warning signs हैं:

1. Sustained, high-frequency divergence. अगर Maya Claudia को 20%+ time override कर रही है, configuration wrong है। Either delegated envelope too broad है (Claudia उन decisions पर act कर रही है जिन पर नहीं करना चाहिए), या Claudia के learned patterns systematically miscalibrated हैं। Decision 4 revisit करने का time.
2. Maya governance ledger पढ़ना बंद कर देती है। अगर Maya weekly summary पढ़ने के लिए too busy है, audit trail dead weight बन जाता है। Architecture तभी काम करती है जब Maya right scale पर loop में रहे; अगर वह entirely opt out करती है, तो वह Concept 1 के wrong response A, de facto auto-approval, पर लौट रही है।
3. Claudia बहुत ज़्यादा surface करती है। Mirror failure: अगर Claudia 30%+ decisions Maya को surface करती है, scaling property break होती है। Claudia too conservative है; delegated envelope या confidence thresholds relax करने होंगे।

Rough heuristic के रूप में, और numbers को optimize करने वाले benchmark के बजाय starting orientation मानना चाहिए, healthy operational state कुछ ऐसा दिखता है: 90-95% decisions Claudia द्वारा autonomously handled, 5-10% Maya को surfaced, under 5% overrides. Exact numbers company, Maya की risk tolerance, और workforce के work type से vary करते हैं। ऊपर numerical ranges illustrative हैं, published dataset से measured नहीं। Specific percentages hit करने से ज़्यादा matter shape करता है: most decisions autonomous, meaningful लेकिन small fraction surfaced, overrides इतने rare कि हर one closely read हो।

PRIMM: Predict

नीचे हर scenario को healthy, unhealthy: configuration, unhealthy: disengagement, या unhealthy: over-conservative classify करें:

1. Six months के बाद, Claudia 92% decisions auto-approve करती है; Maya 2% override करती है; Maya हर Friday weekly summary पढ़ती है।
2. Three months के बाद, Claudia 35% decisions Maya को surface करती है; Maya उन्हें hours के अंदर process करती है।
3. Eight months के बाद, Claudia 98% decisions auto-approve करती है; Maya ने एक month से weekly summary नहीं पढ़ी।
4. Two months के बाद, Claudia 88% decisions auto-approve करती है; Maya उनमें से 22% override करती है।
5. Four months के बाद, Claudia 91% decisions auto-approve करती है; Maya 4% override करती है; Maya occasionally override patterns के response में Layer 1 instruction add करती है।

उत्तर: (1) healthy: target ranges में, owner engaged. (2) unhealthy: over-conservative: surfacing rate too high है; Claudia की confidence thresholds या delegated envelope loosen करने की ज़रूरत है। (3) unhealthy: disengagement: Maya ने effectively everything delegate कर दिया; यह de facto auto-approval है, Concept 1 का Wrong Response A. (4) unhealthy: configuration: 22% override rate का मतलब delegated envelope wrong है या Claudia के patterns systematically miscalibrated हैं; Decision 4 revisit करने का time. (5) healthy: standing-instruction edits के through active recalibration exactly वही loop है जो Concept 12 advocate करता है।

निचोड़: जब Maya और Claudia disagree करते हैं, architecture इसे failure नहीं, healthy signal treat करती है। Override Claudia के per-decision feedback को update करता है; patterns time के साथ refine होते हैं; Maya control में रहती है क्योंकि escape valve हमेशा available है। Watch करने वाले unhealthy patterns हैं sustained high-frequency divergence (configuration wrong), Maya का governance ledger से disengage होना (architecture defeated), और Claudia का over-surfacing (scaling property broken). Healthy state ~90-95% autonomous, ~5-10% surfaced, under 5% overridden है।

---

Part 6: ईमानदार frontier

Course throughout honest रहा है कि architecture के कौन से parts shipped हैं और कौन से open research. Part 6 open frontier का explicit treatment है: तीन Concepts कि May 2026 में क्या fully solved नहीं है, path forward कैसा दिखता है, और Course Eight का eighth-invariant claim genuinely कहाँ land करता है vs कहाँ gesture करता है।

Concept 13: Self-sovereign memory, owner का accumulated judgment long-term कहाँ रहता है

Concept 5 ने establish किया कि Maya की OpenClaw session design से उसके local filesystem पर रहती है, opt-in के रूप में नहीं। वह property single device के लिए Tapscott की self-sovereignty commitment satisfy करती है। यह multi-device case को fully satisfy नहीं करती।

Continue करने से पहले one clarification: interface reachability session location नहीं है। OpenClaw की 50+ integrations (including 15+ chat channels: WhatsApp, Telegram, Discord, Slack, Signal, iMessage) का मतलब Maya अपनी Identic AI तक कहीं से भी reach कर सकती है जहाँ उसके पास phone या laptop और chat apps हों। उसके phone पर Telegram, laptop पर Telegram, coworker's office में Discord: सब same Identic AI के interfaces हैं। लेकिन interface reachability और session itself कहाँ रहती है अलग सवाल हैं। Chat apps stateless proxies हैं; session (Maya का accumulated context, learned patterns, signing keys) उस device पर रहती है जो OpenClaw daemon run कर रहा है। Default रूप से यह one device है। नीचे multi-device case यह है कि session second device तक कैसे पहुँचती है, न कि Maya उसे कैसे reach करती है।

आज के तीन architectural options. जब Maya चाहती है कि उसकी Identic AI उसके laptop, phone, work machine, home Mac के across follow करे, तो May 2026 में तीन patterns shipped हैं:

1. Single-device sovereignty (default). Session one device पर रहती है। Maya OpenClaw सिर्फ उसी device से use करती है। Strict sense में self-sovereign; practical sense में constrained.
2. User-hosted sync. Maya अपनी sync layer run करती है: private server जिसे वह control करती है (घर पर Raspberry Pi, छोटा VPS), open-source sync protocol run करते हुए। हर device पर उसका OpenClaw sync server से push और pull करता है। Strict sense में still self-sovereign (Maya server own करती है); higher operational burden.
3. Encrypted-with-user-key cloud sync. Maya third-party sync service use करती है, लेकिन session client-side encrypted है ऐसे key से जो सिर्फ Maya hold करती है। Cloud provider ciphertext store करता है; keys कभी Maya के devices से बाहर नहीं जातीं। Encryption correctly implemented हो तो practice में self-sovereign, लेकिन Maya encryption implementation और side-channel leaks की absence पर trust कर रही है।

OpenClaw first option out of the box support करता है और second तथा third पर gesture करता है, लेकिन May 2026 में multi-device case के लिए तीनों में से कोई clean, no-tradeoff solution नहीं। Tapscott इसे "reinventing the AI stack" कहते हैं। वे सही हैं।

असल open research क्या है। तीन questions के shipped answers अभी नहीं हैं:

1. User का accumulated context runtime obsolescence survive कैसे करता है? अगर OpenClaw project 2030 में shut down हो जाए और user के पास 4 years का accumulated session data हो, क्या वह different runtime पर migrate कर सकता है? Today: principle में yes (data filesystem पर है, human-readable); practice में next runtime को OpenClaw session format import करना होगा, जो assume करता है कि format stable है। यह long-term sovereignty question है।
2. Cryptographic identity का क्या? Maya की signing key Claudia को represent करती है। अगर Maya ऐसे different runtime पर move करना चाहती है जो different identity protocol use करता है, तो Paperclip पर Claudia की continuity का क्या होता है? Runtime की Identic AI identity की notion और wider ecosystem की delegated identity की notion के बीच relationship standardized नहीं है।
3. Backups और recovery का क्या? अगर Maya अपने devices, backups, और primary credentials simultaneously lose कर दे, तो वह अपनी Identic AI खो देती है। May 2026 में shipped pattern है Maya अपनी backups के लिए responsible है। Architecture को stronger recovery story (Shamir-split keys, social recovery) support करनी चाहिए या नहीं, यह active design question है।

Course Eight architectural commitments (filesystem-local by default, user-owned keys, no platform lock-in) सिखाता है और name करता है कि operationalization कहाँ partial है। Course pretend नहीं करता कि multi-device, multi-runtime, long-term-sovereignty story fully solved है।

निचोड़: single-device self-sovereignty story OpenClaw के filesystem-local session design से solved है। Multi-device case में तीन patterns हैं, हर एक tradeoffs के साथ। Long-term sovereignty case (runtime obsolescence, identity continuity, recovery) May 2026 तक genuinely open research है। Course Eight architectural commitments सिखाता है और name करता है कि क्या अभी shipped नहीं है।

Concept 14: Pattern-matching से आगे value alignment

Concept 10 ने Claudia के accumulated context की तीन layers distinguish कीं: explicit standing instructions, per-decision feedback, और derived patterns. Third layer वह हिस्सा है जिसे Course Eight सिखाने को लेकर least confident है। Pattern-matching value alignment नहीं है, और distinction matter करता है।

Patterns surface हैं; values structure हैं। Claudia सीख सकती है कि "Maya $500-$2,000 range में refunds approve करती है जब customer का account दो साल से ज़्यादा पुराना हो।" यह pattern है। Underlying value जिस पर Maya act कर रही है वह हो सकती है "long-tenure customers low fraud risk और high churn risk represent करते हैं, इसलिए मैं उनकी satisfaction prioritize करती हूँ": customer-business dynamics के बारे में structural belief. Same pattern दो different policies produce कर सकती हैं: एक Maya की customer-relationship values पर based, दूसरी, कहें तो, arbitrary heuristic जो Maya ने podcast से pick की। Routine decisions के लिए Claudia का pattern सीखना genuinely helpful है; pattern break होने पर Claudia का pattern को value समझ लेना dangerous है (long-tenure customer fraudulent refund attempt करता है; pattern कहता है "approve"; value कहती है "पहले verify करो")।

Operationally यह कहाँ matter करता है। Pattern-matching तब अच्छा काम करता है जब world stable हो। यह उन cases में fail होता है जिन्हें architecture को सबसे सही handle करना है: novel situations, edge cases, वे moments जहाँ Maya का judgment सबसे valuable है। ऐसी Identic AI जो उसके past decisions pattern-match करती है routine में अच्छी है; ऐसी Identic AI जिसने उसकी values model की हैं novel में अच्छी है। Latter वही है जिसकी ओर Tapscott का transcript gesture करता है जब वह "reflecting your values" की बात करते हैं। यह May 2026 में shipped नहीं है।

Research preview की स्थिति. Anthropic और दूसरे labs के पास research previews हैं जो आगे जाते हैं: value-elicitation interviews, past decisions से principle-extraction, explicit "what would you do if..." dialogues जो underlying structure surface करते हैं। ये exist करते हैं; May 2026 में इनमें से कोई curriculum-ready नहीं है इस sense में कि Course Eight उन्हें stable pattern के रूप में सिखा सके। Course Eight की commitment pattern-matching layer को अच्छे से सिखाना है (Concepts 10-12) और value-alignment layer को open frontier के रूप में name करना है।

Delegate primitive के लिए इसका implication. Course Eight का claim है कि Owner Identic AI owner-attention bottleneck हटाती है। Claim pattern-matching layer पर true है: Claudia routine decisions enough correctness से handle करती है ताकि Maya की workforce 10-40 Worker ceiling से काफी आगे scale कर सके। Claim value-alignment layer पर fully true नहीं है: Claudia कभी-कभी novel decision ऐसे लेगी जिसे Maya differently लेती, और architecture को यह assume करके recalibration के लिए design करना होगा (Concept 12). Delegate primitive AI-native company को order of magnitude से scale करता है, infinitely नहीं। किसी scale के बाद (hundreds of Workers, thousands?), residual novel-decision rate इतनी बड़ी हो जाती है कि pure pattern-matching delegation keep up नहीं करता, और architecture को further scale करने के लिए value-alignment research ship होना होगा। वह ceiling exactly कहाँ है, हम नहीं जानते; course honest है कि वह बाहर मौजूद है।

निचोड़: Claudia की pattern-matching layer (Concept 10) routine अच्छी तरह handle करती है; उसकी value-alignment layer (open frontier) novel poorly handle करती है। Course Eight का eighth-invariant claim pattern-matching layer पर true है: Maya अपनी workforce को previous attention ceiling से आगे scale कर सकती है। Claim value-alignment layer पर partial है; कहीं एक ceiling है जिसके beyond pure pattern-matching delegation scale होना बंद करती है। वह ceiling कहाँ बैठती है, यह value-alignment research पर depend करता है जो अभी shipped नहीं है। Course इस partial के बारे में honest है।

Concept 15: आगे क्या है, Identic AI economy, eval discipline, और architectural primitives का close

Course Eight Agent Factory track की architectural sequence का last course है। Course Nine, जो eval-driven development की cross-cutting discipline सिखाता है, track itself close करता है। Concept 15 Course Eight close करता है और दो scales पर next point करता है: track के अंदर (Course Nine और eval discipline) और उससे आगे (Identic AI economy के open frontiers). तीन चीज़ें name करनी हैं:

• Owner Identic AI architecture आगे कहाँ lead करती है
• Field mature होने पर दूसरे Identic AI use cases (customer-side, employee-side, peer-to-peer) actual में कैसे दिखते हैं
• Course Nine की eval discipline wrap होने के बाद seven-invariant architecture क्या बनती है

Identic AI economy जैसा Tapscott describe करते हैं। HBR transcript से: "I think that we will spend a lot less time in execution related activities. ... AI agents can handle coordination analysis, scheduling, flow through all the other stuff about execution, they can do that at machine speed. Execution increasingly becomes commoditized. And so as a manager and executive, what differentiates a firm is no longer your ability to execute, but your ability to think big picture, to choose the right goals, to define purpose, to make high quality strategic judgments." Tapscott जिस architectural shape को describe कर रहे हैं वह Identic AIs का network है: हर AI-native company पर owner-side, हर workforce पर employee-side, हर individual पर customer-side, signed credentials के under interacting, और humans सिर्फ consequential या strategic पर intervene करते हुए। Course Eight उस network का one node completely build करता है; network itself वही है जिसकी ओर Course Eight point करता है।

Customer-side Identic AI sidebar use case के रूप में। Customer Sarah, 2027 या 2028 या 2030 में, अपने laptop पर अपना OpenClaw चला रही है। वह Maya की company से contract clause interpret करना चाहती है। वह Sarah-OpenClaw (customer की Identic AI, Maya की नहीं) को WhatsApp से message करती है: "can you talk to ContractCo about clause 7.3 of my contract?" Sarah-OpenClaw Sarah की credentials से request sign करता है और Maya की company के Manager-Agent पर post करता है। Manager-Agent Sarah की identity verify करता है (passkey plus signature, वही primitives जो Course Eight Maya के case के लिए सिखाता है लेकिन untrusted boundary के across), Legal Specialist को route करता है, answer return करता है। Sarah की Identic AI और Maya की workforce network में peers की तरह मिलती हैं, signed credentials से mediated, neither side पूरा interaction own करती है। Course Eight यह architecture enable करता है लेकिन deliver नहीं करता। Concepts 7-9 के trust-delegation primitives transfer करते हैं; missing piece cross-party trust model है।

Employee-side Identic AI. Maya की company में Worker, hired AI Worker नहीं बल्कि employee, अपनी Identic AI रखता है जो emails draft करने, meetings prepare करने, tasks manage करने में मदद करती है। Employee Identic AI company की Workforce और employee की अपनी Identic AI peers से बात करती है। यह use case OpenClaw already individual users के लिए well serve करता है: one person's machine पर रहने वाली personal AI, उनकी chat apps से reachable, exactly वह single-node configuration है जो OpenClaw ship करता है। Course Eight ने इसे नहीं सिखाया क्योंकि load-bearing case owner का था; लेकिन architecture naturally extend करती है।

Peer-to-peer Identic AI. दो individuals की Identic AIs directly interact करती हैं: Maya की Identic AI meeting coordinate करने के लिए उसकी co-founder's Identic AI से बात करती है; Sarah की Identic AI Maya की Identic AI से directly refund negotiate करती है। Tapscott का end-state है humans loop में सिर्फ strategic पर; routine interaction AIs के बीच होता है। यह दूसरों से ज़्यादा speculative है; peer-to-peer layer पर trust-delegation problem के open subproblems हैं।

Seven-invariant thesis, operationalized. Course Three open होने पर जो speculative था, Course Eight close होने के बाद concrete है। Canonical thesis ordering और naming use करते हुए:

Invariant	यह क्या require करता है	कौन सा course इसे depth में operationalize करता है
1. Human principal है	Human intent, budget, authority envelope, accountability	Track के across foundational
2. हर human को delegate चाहिए	Context, judgment, और authority envelope hold करने वाला personal agent	Course Eight
3. Workforce को management layer चाहिए	Hire, assign, govern, observe, retire: workforce OS	Course Six (Paperclip)
4. हर Worker अपना engine pick करता है	Job से matched per-Worker runtime	Course Three (engine choice introduce करता है)
5. हर Worker system of record के against run करता है	MCP से reachable authoritative store	Course Four
6. Workforce policy के under expandable है	Callable capability के रूप में hiring	Course Seven (Claude Managed Agents)
7. Workforce nervous system पर run करती है	Events, durability, envelope के under flow control	Course Five (Inngest)

सात invariants, उन्हें depth में operationalize करने वाले छह courses (Three, Four, Five, Six, Seven, Eight; Invariant 1 human principal की foundational commitment के रूप में सबमें चलता है)। Architecture operationalized है। ऐसी AI-native company जिसके पास सातों हैं scalable, auditable, governable है, और ऐसे primitives के around बनी है जो next runtime release से obsolete नहीं होंगे, क्योंकि architecture patterns पर commit करती है, vendors पर नहीं। Course Nine फिर eval-driven discipline add करता है जो "built and running" को "measurably trustworthy" में बदलती है। Architecture Course Eight के बाद complete है; curriculum Course Nine के बाद complete है।

Track के अंदर और उससे आगे, आगे क्या। Course Eight ने तीन open research areas पर gesture किया: runtimes के across self-sovereign memory (Concept 13), pattern-matching से आगे value alignment (Concept 14), और customer-side तथा peer-to-peer Identic AI के लिए cross-party trust model (Concept 15). ये अभी curriculum नहीं हैं; ये active research frontier हैं। Course Eight finish करने वाले reader के पास इन problems के solutions ship होने पर evaluate करने का framework है: value-alignment proposal credible किससे होता है, cross-party trust architecture self-sovereign किससे बनती है, long-term sovereignty story honest किससे होती है।

Course Eight के बाद architectural primitives operationalized हैं; track Course Nine में continue करता है। Course Nine वह सिखाता है जिसे architectural sequence के across deliberately deferred किया गया: eval-driven development की cross-cutting discipline. Courses 3-7 में बना हर Worker, Course Seven में authorized हर hire, और Course Eight में Claudia द्वारा किया हर delegated decision same property रखता है: उनमें से कोई भी measurably trustworthy नहीं है जब तक उसका behavior evaluated, traced, graded, और improved नहीं हुआ। Course Nine layered eval stack (agent behavior के लिए trace grading, development workflow के लिए repo-level evals, knowledge layer के लिए RAG evals, production observability) से वह discipline उठाता है। Analogy: test-driven development किसी भी SaaS engineering curriculum की closing discipline थी; eval-driven development किसी भी agentic-AI curriculum की closing discipline है। Architecture (Courses 3-8) plus discipline (Course 9) full Agent Factory track के बराबर है।

निचोड़: Course Eight Agent Factory thesis के Invariant 2, delegate, को उस specific configuration में operationalize करता है जो AI-native company को founder के attention से आगे scale करने देता है। सात architectural invariants सभी Courses 3-8 के across depth में operationalized हैं; Course Nine eval-driven development की cross-cutting discipline add करता है जो architecture को production में measurably trustworthy बनाती है। Concepts 13-15 में named open research frontiers (self-sovereign memory, value alignment, cross-party trust) architecture और discipline दोनों से beyond हैं; वे अगले decade का work हैं।

---

इसमें सच में अच्छा कैसे बनें

Course Eight पढ़ने से आप Owner Identic AI build करने में अच्छे नहीं बनते। इसे use करने से बनते हैं, और path ऐसा दिखता है: कुछ weeks में चार phases, order में।

Phase 1: Low stakes में Identic AI के साथ live करें (week 1). OpenClaw अपनी machine पर install करें, अपनी real machine पर, sandbox नहीं। Real persona onboard करें: अपनी, Maya की नहीं। अपनी real chat app के through अपने real day के बारे में message करें। उसे कुछ standing instructions दें कि वह आपकी real email, real calendar, या real task list कैसे handle करे। यह phase governance के बारे में नहीं है। यह intuition build करने के बारे में है कि Identic AI actual में आपके साथ रहती है तो कैसा feel होता है, जब इसकी memory accumulate होती है, जब यह proactive nudge से आपको surprise करती है। इस phase के land होने के बाद ही आप governance use case के लिए ready होंगे; personal-AI intuition के बिना सीधे delegated governance पर jump करने से calibration mistakes होती हैं।

Phase 2: देखें यह आपको कहाँ wrong get करती है (week 2). उन moments पर attention दें जब आपकी Identic AI ऐसी चीज़ surface करती है जिसे आप ignore करते, या ऐसी चीज़ पर auto-act करती है जिसे आप देखना चाहते। इनमें से हर one signal है: या standing instructions off हैं, या learning patterns misfire कर रहे हैं। Plain language में correct करें; next similar case देखें कि correction stuck हुआ या नहीं। अपनी Identic AI पर कब trust करना है और कब नहीं, यह sense Maya के बारे में पढ़ने से नहीं, इसे अपने real decisions पर act करते देखने से build होता है।

Phase 3: Architecture को governance पर apply करें (week 3+). अगर आप AI-native-company owner हैं, अपनी Identic AI को अपनी real Paperclip workforce के against governance delegate के रूप में configure करें। Decision 4 के conservative envelope को starting point use करें। पहले तीन days के लिए dry-run mode (Decision 3 का --dry-run flag) set करें; पढ़ें Claudia ने क्या किया होता; real signing enable करने से पहले calibration confidence build करें। फिर एक week real signing के साथ live जाएँ; governance ledger देखें; actively standing instructions refine करने की expectation रखें। Invariant 2, delegate, आपके operation की property बनता है, course का concept नहीं। तभी Course Eight अपना work कर चुका है।

Phase 4: Steady state और active calibration (month 2+). Roughly 4 weeks operation के बाद rhythm invisible feel होना चाहिए: surfaced approvals पर आप अपनी Identic AI से दिन में कुछ times check in करते हैं, weekly governance summary 10 minutes में पढ़ते हैं, occasionally standing instruction edit करते हैं। Course Eight के architectural patterns अभी भी work कर रहे हैं, लेकिन आप उन्हें ऐसे experience करते हैं: "my AI handles routine, I handle consequential, I review weekly." यही point है।

अपने use में watch करने वाला failure mode. Readers Course Eight का most common misuse weekly review से opt out करना है। Architecture की safety property, कि Maya full audit recovery के साथ principal रहती है, तभी hold करती है जब Maya right scale पर loop में रहे। अगर आप खुद को two weeks running governance summary ignore करते पाते हैं, तो आप Concept 1 के Wrong Response A (de facto auto-approval) में drift कर चुके हैं। कुछ और change करने से पहले weekly review से re-engage करके recover करें।

अगर आप AI-native-company owner नहीं हैं: patterns smaller scales पर फिर भी apply करते हैं। आपकी personal email approvals, calendar conflicts, या information triage handle करती Identic AI same three-layer learning model और same recalibration loop use करती है। Course Eight architecture सिखाता है; आप इसे किस surface पर apply करते हैं, वह आपकी choice है।

---

त्वरित reference

15 Concepts, हर एक one line में

1. AI-native company owner के attention पर scale होना बंद करती है। Hiring API callable है; owner नहीं। 10 और 40 Workers के बीच कहीं owner bottleneck बन जाती है।
2. Identic AI architectural answer है, Tapscott की HBR framing के अनुसार: personalized + value-reflecting + extension-of-self + self-sovereign + persistent memory.
3. Owner Identic AI load-bearing case है। Course Eight एक configuration अच्छे से सिखाता है; Concept 15 बाकी (customer-side, employee-side, peer-to-peer) को frontier के रूप में name करता है।
4. OpenClaw runtime है। Open source, user-owned, local-machine, chat-app-reachable. openclaw.ai से verified.
5. Session Maya की है। उसका accumulated context human-readable files में उसके filesystem पर रहता है। Self-sovereignty operationalized.
6. Chat apps interface layer हैं। Identic AI वहीं रहती है जहाँ owner पहले से रहता है: 50+ integrations, including 15+ chat channels (WhatsApp, Telegram, Discord, Slack, Signal, iMessage), separate app नहीं।
7. दो principals, distinct identities. Paperclip का activity_log हर approval को board action के रूप में record करता है; course की अपनी governance_ledger owner-human vs owner-identic-ai distinction carry करती है। Truthful auditing के लिए distinguish करना ज़रूरी है।
8. Local credentials से signed delegation. Maya की Identic AI Maya-owned key से sign करती है; Paperclip verify करता है; Maya जिस भी device को अभी control करती है उससे revocable.
9. Two-envelope intersection. Maya का owner-authority envelope (ceiling) Claudia के delegated envelope (Maya का chosen subset) से intersect होकर actual execution बनाता है।
10. Accumulated context की तीन layers: explicit standing instructions, per-decision feedback, derived patterns. Third probabilistic है; honest Identic AIs ऐसा कहती हैं।
11. Governance ledger. Owner की ओर से Identic AI द्वारा लिए गए हर decision का append-only audit. Maya को weekly summary.
12. Disagreement healthy signal है। Maya Claudia को override करती है और pattern update होता है। Sustained 20%+ override rate का मतलब configuration wrong है।
13. Multi-device और long-term layer पर self-sovereign memory open research है। Course Eight commitments सिखाता है और partial को name करता है।
14. Patterns values नहीं हैं। Claudia routine अच्छी तरह handle करती है; novel poorly. Delegate primitive workforce को order of magnitude से scale करता है, infinitely नहीं।
15. Architectural sequence Course Eight के बाद close होती है; track Course Nine के बाद close होता है। Seven architectural invariants Courses 3-8 के across depth में operationalized; eval-driven development (Course Nine) cross-cutting discipline है जो architecture को measurably trustworthy behavior में बदलती है। Customer-side और peer-to-peer Identic AI दोनों से beyond open research frontier हैं।

Command quick-ref

आप क्या करना चाहते हैं...	OpenClaw command
New machine पर install	curl -fsSL https://openclaw.ai/install.sh | bash या npm i -g openclaw
First time onboard	openclaw onboard
Install check	openclaw status
Installed skills list	openclaw skills list
New skill install	openclaw skills install <name> (from ClawHub)
Latest पर update	openclaw update --channel stable

File location quick-ref

क्या	कहाँ
Session और accumulated context	~/.openclaw/workspace/ (agent workspace OpenClaw की persistent memory है)
Persona और durable context	~/.openclaw/workspace/USER.md, MEMORY.md, और workspace context/ files
Identic AI signing key	~/.openclaw/keys/identic-ai.pem (या platform keystore)
Locally-authored skills	~/.openclaw/workspace/skills/<name>/SKILL.md
Logs	openclaw logs के through (on-disk log locations के लिए OpenClaw docs consult करें)

Extension type decision tree

Need the owner's Identic AI to handle a routine decision class autonomously?
    → Configure the delegated envelope (Decision 4 / Concept 9) and a standing instruction.

Need to teach the Identic AI a new pattern from a recent override?
    → That's automatic: per-decision feedback joins Layer 2. Concept 10.

Need the company workforce to recognize a new Identic AI principal?
    → Identity registration at Paperclip (Decision 4 / Concept 8).

Need to revoke a compromised Identic AI?
    → Revocation flow (Decision 7 / Concept 8). From any device Maya still controls.

जब कुछ wrong लगे

The owner is reading too many approvals → delegated envelope is too narrow.
    Concept 9. Expand the envelope conservatively, watch for new failure modes.

The Identic AI is auto-approving things the owner would have surfaced → patterns
    are miscalibrated. Concept 12. Use the override; the next pattern update incorporates it.

The Identic AI is unreachable → check chat-app integration first (Decision 1),
    then OpenClaw daemon status (`openclaw status`), then the Paperclip-integration
    skill's config (Decision 3).

The audit trail is incomplete → governance ledger writes are silently failing.
    Concept 11. Check Paperclip's activity_log for the missing rows; the Identic AI's
    side of the write may have succeeded while Paperclip's side failed.

---

References और आगे पढ़ने के लिए

• Tapscott, Don. (2026). You to the Power of Two: Redefining Human Potential in the Age of Identic AI. Course Eight जिस "Identic AI" framing को inherit करता है, उसका source.
• HBR IdeaCast Episode 1066, "With Rise of Agents, We Are Entering the World of Identic AI" (February 17, 2026). Don Tapscott interviewed by Adi Ignatius. hbr.org/podcast/2026/02/with-rise-of-agents-we-are-entering-the-world-of-identic-ai
• OpenClaw official site: openclaw.ai
• OpenClaw documentation: docs.openclaw.ai
• OpenClaw GitHub: github.com/openclaw/openclaw
• Paperclip documentation: docs.paperclip.ing
• Course Seven (direct prerequisite): From Fixed to Dynamic Workforce
• Course Six (management plane): From One Worker to a Workforce
• Course Five (operational envelope): From Digital FTE to Production Worker
• Course Nine (next course): Eval-Driven Development for Agentic AI, cross-cutting discipline जो Courses 3-8 architecture को measurably trustworthy production behavior में बदलती है

---

Course Eight Agent Factory thesis के Invariant 2 का deep operationalization है: वह delegate जो human का context, judgment, और authority envelope hold करता है। Course Nine फिर eval-driven development की cross-cutting discipline add करता है जो हर Worker, हर hire, और हर delegated decision को measurably trustworthy बनाती है। दोनों के साथ आप जो build करते हैं, Courses 3-8 की architecture और Course 9 की discipline, वही आगे आने वाली चीज़ है।