<!-- GENERATED translation. Edit the English source or glossary.json, not this file. -->

## बजट जाँच मॉडल के अंदर है

क्या आप एक AI को अपना क्रेडिट कार्ड देंगे? मैंने दिया, इस एपिसोड के लिए। दिलचस्प बात यह नहीं है कि यह काम कर गया। दिलचस्प बात यह है कि प्रोटोकॉल और गवर्नेंस लेयर ने इसे बहुत अधिक खर्च करने से रोका।

यह वह समस्या है जिससे मैं बार-बार मिलता रहता हूँ। अधिकांश एजेंटिक भुगतान दृष्टिकोण LLM के भीतर बजट जाँच को जोड़ते हैं: एक सिस्टम प्रॉम्प्ट जो कहता है "X डॉलर से अधिक खर्च न करें।" यह संरचनात्मक रूप से किसी से अपनी खर्च सीमा लागू करने के लिए कहने जैसा ही है। जो मॉडल खरीदने का फैसला करता है, वही मॉडल यह जाँचता है कि उसे ऐसा करना चाहिए या नहीं। जब वे एक ही घटक होते हैं, तो आपके पास नियंत्रण नहीं होता। आपके पास एक सुझाव होता है।

अब इस समस्या के लिए एक खुला प्रोटोकॉल है: **AP2, एजेंट पेमेंट्स प्रोटोकॉल v0.2**, जिसे Google की A2A टीम ने बनाया है और FIDO Alliance को दान किया है। मुख्य बात सरल है: <dfn class="term" data-en="mandate">मैंडेट</dfn> एजेंट के बाहर रहता है। यह बाहरी है, क्रिप्टोग्राफिक रूप से हस्ताक्षरित है, और एजेंट इसे ओवरराइड नहीं कर सकता। एजेंट एक ऐसी सीमा के भीतर काम करता है जिसे उसने नहीं खींचा और न ही फिर से खींच सकता है।

AP2 एक <dfn class="term" data-en="mandate">मैंडेट</dfn> चेन को परिभाषित करता है, और चेन ही पूरी बात है: शॉपिंग एजेंट, Checkout Mandate, मर्चेंट एजेंट, Payment Mandate, क्रेडेंशियल प्रोवाइडर, पेमेंट प्रोसेसर। प्रत्येक हॉप सत्यापन योग्य है। कोई भी हॉप छोड़ा नहीं जा सकता। भुगतान तभी होता है जब पूरी चेन चेक आउट हो जाती है।

## परिदृश्य: FIFA 2026 क्वार्टर-फाइनल टिकट

अमूर्त प्रोटोकॉल को एक ठोस खरीद की आवश्यकता होती है, इसलिए यह डेमो एक उपभोक्ता शॉपिंग कंसीयज है जिसके पास एक कठोर ब्रीफ है। उपयोगकर्ता एक मैंडेट पर हस्ताक्षर करता है: FIFA 2026 क्वार्टर-फाइनल के लिए 2 कैटेगरी 3 टिकट, प्रत्येक $1,500 से कम, कुल $3,200 की कड़ी सीमा के साथ। एजेंट रात भर TicketVault, एक मॉक टिकट मार्केटप्लेस, की निगरानी करता है। कोई इंसान मौजूद नहीं है।

जब कीमत गिरती है, तो एक DMN खर्च नीति Camunda Business Rule Task में कार्ट का मूल्यांकन करती है। वह मूल्यांकन मॉडल के बाहर, Camunda में स्वाभाविक रूप से होता है, और इसका परिणाम आगे आने वाली हर चीज़ को निर्धारित करता है। मैंने एक ही गवर्नेंस लेयर के माध्यम से तीन रास्ते बनाए:

| रास्ता | ट्रिगर | DMN परिणाम | परिणाम |
|---|---|---|---|
| गोल्डन | कीमत $1,350 तक गिरती है, कार्ट $2,700 | अनुमोदित | $2,700 की रसीद, पूरी तरह से स्वायत्त |
| HITL | कीमत $1,560 तक गिरती है, कार्ट $3,120 (कैप का 97.5%) | HITL_आवश्यक | चेकआउट से पहले पेमेंट डेस्क की मंजूरी |
| मैंडेट का उल्लंघन | $3,500 की स्थायी खरीद $3,200 की सीमा से अधिक है | अस्वीकृत | प्रोसेसर तक पहुँचने से पहले स्वतः अस्वीकृत |

गोल्डन पाथ वह डेमो है जिसे हर कोई देखना चाहता है: सुबह 3 बजे कीमत गिरती है, एजेंट खरीदता है, सुबह एक रसीद इंतजार कर रही होती है। अन्य दो रास्ते उत्पाद हैं। कैप के 97.5% पर एक कार्ट तकनीकी आधार पर आगे नहीं बढ़ती; यह पेमेंट डेस्क पर एक <dfn class="term" data-en="human-in-the-loop">ह्यूमन-इन-द-लूप</dfn> को जगाती है। और कैप से अधिक की खरीद को एक चतुर प्रॉम्प्ट द्वारा कम नहीं किया जाता; इसे पेमेंट प्रोसेसर के सुनने से पहले ही एक नियम तालिका द्वारा अस्वीकृत कर दिया जाता है।

## गवर्नेंस लेयर

DMN खर्च नीति में पाँच नियम हैं, और मुझे यह पसंद है कि यह उबाऊ है: एक कैप जाँच, एक नियर-कैप ट्रिगर जो मैंडेट के 95% से ऊपर किसी भी चीज़ को मानवीय समीक्षा के लिए भेजता है, एक भुगतान साधन श्वेतसूची, एक वेग सीमा, और एक कैच-ऑल अनुमोदन। यह Camunda में एक Business Rule Task के रूप में चलता है, LLM के भीतर नहीं। एजेंट नीति को ऐसे पाठ के रूप में कभी नहीं देखता जिसके चारों ओर वह तर्क कर सके। वह एक निर्णय परिणाम देखता है।

तीसरी लेयर <dfn class="term" data-en="audit trail">ऑडिट ट्रेल</dfn> है, और यह आर्किटेक्चर के साथ मुफ्त आती है। प्रत्येक प्राधिकरण हॉप Camunda Operate में रहता है: मैंडेट जारी किया गया, कीमत पकड़ी गई, DMN का मूल्यांकन किया गया, क्रेडेंशियल जारी किए गए, रसीद संग्रहीत की गई। प्रत्येक निर्णय, स्थायी रूप से, एक प्रक्रिया इंस्टेंस के रूप में जिसे आप खोल सकते हैं और फिर से चला सकते हैं। इसे प्राप्त करने के लिए किसी ने लॉगिंग कोड नहीं लिखा।

> LLM प्रस्ताव करता है। DMN निपटान करता है। यदि आपकी खर्च नीति को एक अच्छी तरह से तैयार किए गए पैराग्राफ द्वारा बदला जा सकता है, तो वह खर्च नीति नहीं है।

## मैंडेट, विश्वास नहीं

AP2 v0.2 दो मैंडेट प्रकारों को परिभाषित करता है, और प्रत्येक में एक खुला चरण और एक बंद चरण होता है। खुले का मतलब है कि उपयोगकर्ता बाधाओं पर पहले से हस्ताक्षर करता है। बंद का मतलब है कि एजेंट उनके भीतर हुई विशिष्ट लेनदेन पर हस्ताक्षर करता है।

**Checkout Mandate।** उपयोगकर्ता आइटम स्कोप, मूल्य सीमा, एक TTL, और एक मर्चेंट अनुमति सूची पर पहले से हस्ताक्षर करता है। खरीद के समय, एजेंट इसे विशिष्ट कार्ट के साथ बंद करता है: SKU, मूल्य, चेकआउट हैश। मर्चेंट कुछ भी पूरा करने से पहले बंद मैंडेट को सत्यापित करता है।

**Payment Mandate।** उपयोगकर्ता फंडिंग इंस्ट्रूमेंट को पहले से अधिकृत करता है: स्रोत, अधिकतम राशि, श्रेणी प्रतिबंध। एजेंट इसे सटीक राशि और चेकआउट हैश के साथ बंद करता है। क्रेडेंशियल प्रोवाइडर भुगतान टोकन जारी करने से पहले दोनों मैंडेट को सत्यापित करता है।

समापन चरण वह है जहाँ क्रिप्टोग्राफी अपना महत्व साबित करती है। प्रत्येक मैंडेट एक ECDSA P-256 हस्ताक्षर के माध्यम से एक विशिष्ट लेनदेन से बंधा होता है। न तो मैंडेट का पुन: उपयोग किया जा सकता है। न ही इसे जाली बनाया जा सकता है। और चेन में कोई भी पक्ष स्वतंत्र रूप से सत्यापित कर सकता है, किसी केंद्रीय प्राधिकरण की आवश्यकता नहीं है। वह अंतिम गुण ही है जो चेन को एक प्रोटोकॉल बनाता है न कि एक प्लेटफॉर्म।

इस एपिसोड में एक साथी लेख है जो प्रोटोकॉल यांत्रिकी, खतरे के मॉडल और विफलता मोड पर बहुत गहराई से जाता है: [AP2 फील्ड गाइड](/hi/guides/ap2-field-guide/)। यदि यह लेख एपिसोड है, तो फील्ड गाइड मैनुअल है।

## जो LinkedIn पोस्ट में नहीं आया

यह एपिसोड अभी भी निर्माणाधीन है, इसलिए ईमानदार नोट्स सामान्य से अधिक मायने रखते हैं।

डेमो कई AP2 घटकों का अनुकरण करता है। क्रेडेंशियल प्रोवाइडर और पूर्ण A2A ट्रांसपोर्ट डेमो उद्देश्यों के लिए मॉक किए गए हैं; TicketVault एक नकली मार्केटप्लेस है। AP2 v0.2 के प्रति वफादार वह हिस्सा है जो प्रोटोकॉल का मूल्यांकन करने के लिए मायने रखता है: मैंडेट संरचना, हस्ताक्षर तर्क (jose के माध्यम से वास्तविक SD-JWT, वास्तविक ECDSA P-256 हस्ताक्षर), और पार्टी इंटरैक्शन। और गवर्नेंस लेयर बिल्कुल भी सिम्युलेटेड नहीं है: BPMN, DMN खर्च नीति, और HITL पेमेंट डेस्क एक लाइव SaaS क्लस्टर पर चल रहे वास्तविक Camunda 8 हैं।

मैंडेट पैटर्न भी जानबूझकर स्टैक-अज्ञेयवादी हैं। Camunda मेरा इंजन है, लेकिन वही ओपन-देन-क्लोज मैंडेट फ्लो Temporal, LangGraph, n8n, या सादे Node.js पर काम करता है। रेपो में एक MAKE_IT_REAL डॉक शामिल है जिसमें इस डेमो से उत्पादन AP2 तक 5-चरणीय अपग्रेड पाथ है, जिसमें ठीक-ठीक बताया गया है कि आप किन मॉक किए गए घटकों को बदलते हैं और किस क्रम में।

एक और ईमानदार नोट: रेपो एपिसोड के शिप होने तक निजी है। यह डेमो वीडियो के साथ, एपिसोड के साथ सार्वजनिक होगा। फील्ड गाइड पहले से ही लाइव है, क्योंकि प्रोटोकॉल विश्लेषण को मेरे उत्पादन शेड्यूल का इंतजार करने की आवश्यकता नहीं है।

## शिप लॉग

- **प्रोटोकॉल:** AP2 v0.2 (एजेंट पेमेंट्स प्रोटोकॉल, Google A2A टीम, FIDO Alliance को दान किया गया)
- **इंजन:** Camunda 8 (लाइव SaaS क्लस्टर): BPMN ऑर्केस्ट्रेशन, DMN खर्च नीति, HITL पेमेंट डेस्क
- **मॉडल:** शॉपिंग एजेंट के रूप में Claude Sonnet
- **क्रिप्टोग्राफी:** jose के माध्यम से SD-JWT, ECDSA P-256 मैंडेट हस्ताक्षर
- **नीति:** 5-नियम DMN निर्णय तालिका (कैप, 95% नियर-कैप HITL, इंस्ट्रूमेंट श्वेतसूची, वेग, कैच-ऑल)
- **फ्रंटएंड:** SSE पर AG-UI के साथ React, EP 02 से आगे बढ़ाया गया
- **बैकएंड:** Node.js
- **साथी:** [AP2 फील्ड गाइड](/hi/guides/ap2-field-guide/)
- **रेपो:** एपिसोड शिप होने पर सार्वजनिक