# Darkoza Verified Work Fabric (DVWF) ## فرصت راهبردی برتر برای محصول و کل اکوسیستم — ارزیابی، نمونهٔ فنی، اقتصاد و نقشهٔ ارتقا **نسخه:** 1.0 **تاریخ:** ۳ نوامبر ۲۰۲۶ **وضعیت:** ارزیابی و نمونهٔ مرجع تحقیقاتی تکمیل‌شده؛ انتشار عمومی؛ ادغام با محصول تولیدی انجام نشده است. **دامنه:** Darkoza / OERSI و darkoza.com فقط. --- ## ۱) حکم اجرایی **باارزش‌ترین فرصت قابل‌پیشبرد برای Darkoza در وضعیت فعلی، ساخت «پارچهٔ اجرای کارِ قابل‌اعتماد و قابل‌اثبات» است: Darkoza Verified Work Fabric (DVWF).** این فرصت، نه ساخت مدل پایهٔ جدید، نه افزودن تعداد زیادی عامل، نه ساخت بازار توکن و نه یک کشف فیزیکی منفرد است. DVWF باید درخواست کاربر را به یک چرخهٔ منسجم تبدیل کند: **درخواست → هویت و اختیار → برنامه → مجوز محدود → اجرای کنترل‌شده → راستی‌آزمایی نتیجه → اثر/گزارش قابل‌ردیابی → سنجش هزینه و ارزش → تسویهٔ مجاز.** نوآوری راهبردی پیشنهادی در این است که «هوش» به‌تنهایی اختیار اجرا نداشته باشد. مدل پیشنهاد می‌دهد؛ هویت معتبر، مجوز صریح، سیاست قطعی و کاربر مجاز تعیین می‌کنند چه کاری، روی کدام داده و با کدام ابزار انجام شود. نتیجه نیز فقط زمانی «تکمیل‌شده» تلقی شود که شاهد قابل‌بررسی وجود داشته باشد. **این یک انتخاب استراتژیک و فرضیهٔ مهندسیِ پرارزش است، نه ادعای کشف علمیِ نو یا امنیت اثبات‌شده.** پژوهش در حوزهٔ اختیار عامل‌ها و امنیت ابزارها در حال گسترش است؛ مزیت Darkoza باید از اجرای یکپارچه، حریم خصوصی، کیفیت، سنجش نتیجه و اقتصاد واقعی ساخته شود، نه از نام‌گذاری یک پروتکل به‌عنوان اختراع بی‌سابقه. ### سه تصمیم 1. **برنامهٔ اصلی محصول:** DVWF؛ هویت/اختیار، اثر دقیق، تأیید مرحله‌ای، اجرای محدود، مدرک نتیجه و ثبت هزینه در یک چرخه. 2. **اهرم اقتصادی نزدیک‌مدت:** اثبات اولین پایلوت پرداخت‌شده و حاشیهٔ مشارکت؛ نه ساخت بازار عامل‌به‌عامل یا اتکا به Darkoza Coin. 3. **اهرم فنی مکمل:** مسیریابی کیفیت‌محور مدل و زمان‌بندی آگاه از هزینه/ظرفیت، پس از جمع‌آوری سنجه‌های واقعی. GridFlex به‌عنوان خط پژوهشی و قابلیت تخصصی باقی می‌ماند، نه ادعای برتری محصول. --- ## ۲) چرا این فرصت از گزینه‌های دیگر جلوتر است؟ معیار ارزیابی، ارزش مشتری، تمایز، درآمد بالقوه، زمان رسیدن به ارزش، هزینهٔ پیاده‌سازی، ریسک امنیت/حقوقی، و توان واقعی تیم است. | فرصت | ارزش و قابلیت اجرا | تصمیم | |---|---|---| | اجرای عامل با هویت، اختیار محدود و مدرک نتیجه | مسئلهٔ بنیادی برای تمام ابزارها و جریان‌کارها؛ تمایز با کیفیت پیاده‌سازی و دادهٔ عملیاتی ایجاد می‌شود | **برنامهٔ اصلی** | | مسیریابی مدل با سنجش کیفیت/هزینه/تأخیر | قابلیت مکملِ سریع‌تر؛ کاهش هزینه بدون افت کیفیت باید روی مجموعه‌دادهٔ خود Darkoza اثبات شود | **اولویت دوم** | | فضای خصوصی و حافظهٔ مستقل هر کاربر | شرط اعتماد، تداوم و همکاری؛ سرمایه‌گذاری لازم اما به‌تنهایی مدل درآمدی نیست | **بنیاد معماری** | | اجرای ابری پایدار و بازگشت از قطع مرورگر | برای کارهای واقعی ضروری؛ باید صف، وضعیت، checkpoint و بازیابی آزمون شوند | **اولویت زیرساختی** | | فایل و دانش چندقالبی | ارزش روشن برای پژوهش، کار و اتوماسیون؛ مرز فایل/دادهٔ نامطمئن باید حفظ شود | **مسیر محصولی نزدیک** | | بازار اتصال‌دهنده‌ها و عامل‌های شخص ثالث | دروازهٔ گسترش اکوسیستم، اما قبل از کنترل مجوز و عرضهٔ قابل‌اعتماد ریسک زیادی دارد | **پس از DVWF** | | تسویهٔ عامل‌به‌عامل و Coin | نیازمند هویت طرفین، مسئولیت، اختلاف، بازپرداخت، مالیات و مجوز؛ ارزش فرضی کافی نیست | **فعلاً متوقف** | | مدل پایهٔ اختصاصی یا GPU بزرگ | هزینه و رقابت سنگین؛ شواهد فعلی مزیت پایدار را نشان نمی‌دهد | **فعلاً نساز** | | شبکهٔ انرژی/مراکز داده و GridFlex | منفعت اجتماعی و فرصت پژوهشی مهم؛ برای درآمد نزدیک‌مدت محصول، مسیر طولانی و نیازمند داده/مشارکت بیرونی است | **پژوهش مکمل** | ### شواهد مستقل - NIST در ۵ فوریهٔ ۲۰۲۶ یک مقالهٔ مفهومی دربارهٔ هویت و مجوزدهی عامل‌های نرم‌افزاری منتشر کرد و بر نیاز به کنترل‌های شناسایی و مجوزدهی برای دسترسی عامل‌ها به داده، ابزار و برنامه‌ها تأکید کرد. این مقالهٔ مفهومی است، نه استاندارد الزام‌آور. [NIST — Agent Identity and Authorization](https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents) - مشخصات رسمی MCP برای مسیرهای HTTP، سازوکار OAuth 2.1، Protected Resource Metadata و Resource Indicators را به‌کار می‌گیرد و اعتبارسنجی audience توکن برای همان سرور را الزامی می‌کند؛ توکن صادرشده برای یک منبع نباید به منبع دیگری عبور داده شود. [MCP Authorization Specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) - OWASP در Top 10 عامل‌محور ۲۰۲۶ ریسک‌های برنامه‌های عامل‌محور را دسته‌بندی کرده است؛ نسخهٔ ۲۰۲۶ LLM Top 10 نیز در سپتامبر ۲۰۲۶ ویرایش تازه و Agent Control Standard را معرفی کرد. این‌ها راهنمای جامعهٔ امنیتی‌اند و جایگزین آزمون مستقل محصول نیستند. [OWASP Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) · [OWASP 2026 LLM Top 10 and Agent Control Standard](https://genai.owasp.org/2026/09/01/owasp-genai-security-project-unveils-2026-top-10-for-llm-applications-new-agent-control-standard-and-sponsors-as-community-tops-30000-members/) - OWASP در جمع‌بندی Q3 2026 مواردی از سوءاستفادهٔ ابزار، سرقت اطلاعات، هویت/مجوز بیش‌ازحد و آلودگی حافظه/زمینه را توصیف کرد؛ گزارش انتخابی و غیرجامع است. [OWASP Q3 2026 exploit roundup](https://genai.owasp.org/2026/10/08/genai-and-agentic-ai-exploit-roundup-q3-2026/) پیش‌چاپ‌ها و benchmarkهای تحقیقاتی، از جمله Bounded Agents و InjecAgent، برای ساخت مجموعهٔ آزمون مفیدند؛ نتایج آن‌ها تضمین عمومیِ امنیت یا عملکرد Darkoza نیستند. [Bounded Agents, arXiv:2608.15888](https://arxiv.org/abs/2608.15888) · [InjecAgent, arXiv:2403.02691](https://arxiv.org/abs/2403.02691) --- ## ۳) خط مبنای واقعی محصول در ممیزی ۳ نوامبر ۲۰۲۶ این بخش، وضعیت مشاهده‌شده را از الزامات و برنامه‌ها جدا می‌کند. ### آنچه کار می‌کند یا در نقطهٔ مشاهده تأیید شد - صفحات عمومی darkoza.com، /asi/، /marketplace/ و کاتالوگ عمومی علم با HTTPS و HTTP 200 پاسخ دادند. - هستهٔ Cognitive، درگاه ASI، Caddy و چرخهٔ Autonomy در فهرست سرویس‌های فعال دیده شدند؛ این وضعیت به معنی اثبات کیفیت هوش یا خودمختاری نیست. - در release manifest نسخهٔ ASI، سقفِ تعداد درخواست برای کاربر، IP یا کل ساعت تعریف نشده است؛ فشار ظرفیتِ inference با 503 موقت و Retry-After مدیریت می‌شود. هم‌زمانی inference در manifest روی ۲ تنظیم شده است. بنابراین «بدون سقف تعداد درخواست» به معنی «منابع نامحدود یا زمان پاسخ تضمین‌شده» نیست. - ماژول ورودی فایلِ بررسی‌شده، استخراج متن PDF/DOCX و صوت را در مسیرهای کنترل‌شده پشتیبانی می‌کند؛ اما حد دقیق فایل و سازگاری manifest باید قبل از release بعدی یکپارچه شوند. - موتور تصمیم Cognitive از قبل trace و مدل انتخابی کیفیت/هزینه دارد؛ اما انتخاب مدل بر سنجه‌هایی تکیه می‌کند که فراخواننده ارائه می‌کند. این سرویس کشف provider یا تطبیق خودکار با صورتحساب واقعی نیست. ### شکاف‌های تأییدشده یا ناسازگاری‌هایی که باید پیش از توسعهٔ بعدی حل شوند 1. **هویت/مستأجر:** در public ASI adapter بررسی‌شده، درخواست /chat به یک principal و tenant احرازشده متصل نمی‌شود؛ handler ورودی Origin را کنترل می‌کند، اما Origin به‌تنهایی اثبات هویت نیست. بنابراین این adapter فعلی را نباید یک اجرای چندمستأجریِ عامل‌محور با مجوزهای مستقل معرفی کرد. 2. **حافظهٔ خصوصی:** حافظهٔ خصوصیِ قابل‌مشاهده در این release در مرورگر و localStorage نگهداری می‌شود؛ کتابخانهٔ محلی معادل حافظهٔ ابریِ همگام، رمزگذاری‌شده و مستقل برای هر کاربر نیست. در manifest، public memory غیرفعال است. 3. **تداوم کار:** وجود چرخهٔ Autonomy یا worker به‌تنهایی اثبات نمی‌کند که کار پذیرفته‌شده پس از قطع کلاینت، restart worker و failover بدون ازدست‌دادن وضعیت ادامه می‌یابد. آزمون مستقل بازیابی هنوز gate باز است. 4. **Drag & Drop تمام‌صفحه:** در فایل‌های فعالِ ASI که برای این ممیزی بررسی شدند، handlerهای dragenter/dragover/dragleave/drop پیدا نشدند. این نتیجه نیازمند E2E روی کل صفحه است؛ تا آن زمان الزام «رهاکردن فایل از هر نقطهٔ صفحه» تأییدشده محسوب نمی‌شود. 5. **نسخهٔ release:** HTML صفحهٔ ASI از app-v0.2.21.js استفاده می‌کند، درحالی‌که release manifest و نشانگر نسخه 0.2.20 را اعلام می‌کنند. این اختلاف باید پیش از release بعدی رفع و hashها دوباره بررسی شوند. 6. **اقتصاد API:** کاتالوگ عمومی علوم، یک preview فقط‌خواندنی و رایگان است؛ خودش فروش API یا پرداختِ مصرف را فعال نمی‌کند. وضعیت فروش تجاری API در کاتالوگ «not yet on sale» ثبت شده است. این را باید از سیاست تجاری آینده تفکیک کرد. 7. **درآمد:** اولویت اقتصادی فوری همچنان اثبات اولین مشتری پرداخت‌کننده، تسویهٔ تأییدشده، تحویل نتیجه و محاسبهٔ حاشیهٔ مشارکت است. دو ایمیل discovery قبلی صرفاً اقدام جذب مکالمه‌اند؛ نه سند نیاز، نه lead qualified، نه قرارداد و نه پرداخت. 8. **ظرفیت:** ممیزی عملیاتی آخر، فشار قابل‌توجه روی ذخیره‌سازی و swap گرهٔ اصلی را نشان می‌دهد. اجرای مدل سنگین یا release پرریسک پیش از رفع ظرفیت و آزمون recovery توجیه ندارد. ### یک اصل مهم ثبت یک قابلیت در منشور v1.1، صفحهٔ عمومی، کاتالوگ یا نقشهٔ راه به معنی پیاده‌سازی آن نیست. تمام موارد آینده در این سند «هدف»، «طرح» یا «gate» باقی می‌مانند مگر با آزمون و وضعیت اجرایی مستقل تأیید شوند. --- ## ۴) معماری پیشنهادی DVWF ### چرخهٔ کنترلی 1. **هویت:** کاربر، عامل، سرویس و connector شناسهٔ معتبر و مستقل داشته باشند. 2. **نمایندگی/تفویض:** مشخص باشد عامل دقیقاً از طرف چه کاربری و در چه وظیفه‌ای عمل می‌کند. 3. **قصد (Intent):** درخواست به یک عمل ساختاریافته با ابزار، عملیات، منبع، اثر، مخاطب، هزینهٔ تخمینی و برگشت‌پذیری تبدیل شود. 4. **سیاست:** ریسک در کد و سیاست سمت سرور محاسبه شود؛ مدل اجازه ندارد سطح ریسک یا مجوز خود را اعلام کند. 5. **اختیار:** grant کوتاه‌عمر، audience-bound و محدود به tenant، principal، task، capability، tool، action و resource صادر شود. 6. **پیش‌بررسی:** اثر دقیق canonicalize شود؛ هش effect در مجوز و تأیید کاربر ثبت شود. 7. **تأیید:** read و draft محدود می‌توانند با مجوز صریح اجرا شوند؛ ارسال خارجی، حذف، پرداخت، تغییر credential، تغییر شبکه و سایر آثار برگشت‌ناپذیر، مرحلهٔ تأیید معتبر و مستقل نیاز دارند. 8. **اجرا:** ابزار جدا از مدل، در sandbox و با token کوتاه‌عمر، audience صحیح، scope حداقلی و دسترسی شبکهٔ محدود اجرا شود. 9. **راستی‌آزمایی:** خروجی خام، وضعیت اثر، معیار موفقیت و هر خطا ذخیره شود؛ مدل به‌تنهایی تکمیل را اعلام نکند. 10. **اقتصاد و ممیزی:** زمان CPU/GPU، token، storage، egress، هزینهٔ ابزار، نتیجه و رضایت/تأیید کاربر ثبت و به usage ledger متصل شوند. ### قرارداد نمونهٔ مرجع نمونهٔ تحقیقاتی فعلی این فیلدها را در مدل داده دارد: - tenant_id، principal_id، task_id و audience - tool_id و capability - action و resource_id - effect_digest برای اثر دقیق - grant issue/expiry و revoked - idempotency_key برای عمل تغییردهنده - approval assertion متصل به همان intent تأیید پرخطر نباید صرفاً «دکمهٔ تأیید» باشد؛ باید همان عمل، همان ابزار، همان منبع، payload/اثر، گیرنده، هزینه و برگشت‌پذیری را نشان دهد. تغییر هرکدام پس از تأیید باید نیازمند تأیید تازه باشد. ### ماشین حالت کار accepted → authorized → planned → executing → verifying → completed حالت‌های failed، blocked، awaiting_approval و cancelled جدا هستند. «completed» فقط بعد از وجود نتیجهٔ قابل‌راستی‌آزمایی مجاز است. هر job باید شناسهٔ پایدار، مالک/tenant، زمان، رخداد ممیزی، وضعیت لغو، idempotency و سیاست نگهداری داشته باشد. --- ## ۵) نمونهٔ فنی اجراشده برای تبدیل تصمیم به آزمون واقعی، یک نمونهٔ CPU-only و مستقل در محیط تحقیقاتیِ گرهٔ اصلی ساخته شد؛ شناسه‌های داخلی زیرساخت و مسیرهای فایل در نسخهٔ عمومی افشا نمی‌شوند. نسخهٔ سیاست: darkoza-intent-authority-v0.2 ### قابلیت‌های اجراشده در نمونه - تطبیق tenant، principal، task و audience؛ - مجوز دقیق tool، capability، action و resource؛ - منع wildcard و scope تکراری؛ - انقضای grant و حداکثر TTL؛ - تعیین سطح ریسک از policy سمت سرور؛ - اتصال مجوز و تأیید به digest اثر دقیق؛ - idempotency برای عملیات تغییردهنده؛ - تأیید خارجی برای عملیات پرخطر/بحرانی؛ - fail-closed در نبود verifier، خطای verifier و تأیید منقضی؛ - جلوگیری درون‌فرایندی از استفادهٔ مجدد از approval؛ - رسید دارای checksum برای تشخیص دست‌کاری. ### نتایج آزمایش | معیار | نتیجه | |---|---:| | آزمون واحد | ۳۷ از ۳۷ موفق | | آزمون replay موازی | از ۲۴ استفادهٔ هم‌زمان از یک approval، فقط ۱ مجاز و ۲۳ رد شدند | | آزمون idempotency | استفادهٔ اول مجاز، تکرار همان کلید رد شد | | کامپایل Python | موفق | | microbenchmark | ۵۰٬۰۰۰ ارزیابی مجوز read درون‌حافظه‌ای | | median | ۳۲٫۳۸۹ میکروثانیه | | p95 | ۴۸٫۷۶۳ میکروثانیه | | p99 | ۷۷٫۷۱۱ میکروثانیه | این benchmark فقط evaluator پایتون و ساخت checksum را می‌سنجد؛ نه شبکه، پایگاه داده، امضای رمزنگاری، اجرای ابزار، sandbox یا تأخیر سرتاسری. ### آنچه نمونه هنوز انجام نمی‌دهد - احراز هویت واقعی کاربر/عامل یا اتصال به IdP؛ - صدور و اعتبارسنجی OAuth/OIDC token؛ - امضای رمزنگاری‌شدهٔ approval؛ callback فعلی فقط قرارداد قابل‌جایگزینی است؛ - ذخیرهٔ durable و توزیع‌شدهٔ grant، revocation، approval و idempotency؛ restart وضعیت درون‌حافظه‌ای را پاک می‌کند؛ - اجرای هیچ ابزار یا اتصال به ابزار تولیدی؛ - sandbox، network egress controls یا credential broker؛ - ثبت audit امضاشده و append-only؛ - بررسی مستقل امنیت، red-team بیرونی یا آزمون AgentDojo/InjecAgent. بنابراین این **نمونهٔ تحقیقاتیِ آزموده‌شده** است و به هیچ سرویس تولیدی متصل نشده است. checksum رسید امضای رمزنگاری‌شده، مدرک هویت یا non-repudiation نیست. کد و نتایج عمومی‌شده در ضمیمهٔ همین انتشار قرار دارند. --- ## ۶) ارتقای هر بُعد محصول و اکوسیستم ### A. تجربهٔ کاربر - یک ورودی واحد در darkoza.com، با حالت متن/فایل/وظیفه و بدون پراکندگی غیرضروری. - تمام سطح workspace باید drag-and-drop پذیر باشد؛ فایل‌ها قبل از ارسال به درخواست جاری متصل، نام و نوع و وضعیتشان دیده شود، و ذخیره‌سازی دائمی تنها با رضایت جداگانه انجام شود. - کار طولانی باید وضعیت زنده، توقف، ادامه، خروجی و تاریخچهٔ خطا داشته باشد. - برای اقدام حساس، قبل از اجرا پیش‌نمایش روشنِ «چه چیزی، با کدام ابزار، روی کدام منبع، با چه اثری و با چه هزینه‌ای» نمایش داده شود. - نتیجه باید لینک به مدرک یا گزارش را همراه داشته باشد، نه صرفاً پاسخ متنی. ### B. هویت، حریم خصوصی و حافظه - دادهٔ هر tenant در سطح API، پایگاه داده، index/embedding، cache، log، file store و backup جدا بماند. - context user از هویت عامل و هویت connector تفکیک شود؛ هیچ token یا session یک کاربر برای کاربر یا ابزار دیگر استفاده نشود. - حافظهٔ مشترک فقط شامل دادهٔ عمومیِ مجاز و منبع‌دار باشد؛ دادهٔ خصوصی به‌صورت پیش‌فرض وارد آن نشود. - export، delete، revoke، retention و account-exit باید به‌طور مستقل آزمون شوند. - حافظهٔ cloud-side پیش از ایجاد هویت واقعی، سیاست نگهداری، encryption، audit و تست عدم نشت cross-tenant ساخته نشود. ### C. عامل‌ها و ابزارها - هر connector با manifest نسخه‌دار، فهرست ابزار، scope، data class، اثر، برگشت‌پذیری، upstream provenance، license و risk class معرفی شود. - connector به‌ازای هر کاربر credential مستقل و کوتاه‌عمر بگیرد؛ token عبوری یا عمومی ممنوع. - «جست‌وجوی ابزار» فقط ابزارهای سازگار با policy و مجاز برای همان principal را نشان دهد. - عملیات write ابتدا draft، سپس preview، سپس confirmation، سپس execution باشد. - ابزارهای دارای کد شخص ثالث در sandbox، با filesystem و network محدود و dependency provenance بررسی شوند. ### D. مدل، کیفیت و هزینه - router فقط بر مبنای معیارهای ثبت‌شدهٔ کیفیت، هزینهٔ واقعی، latency، availability و نوع وظیفه تصمیم بگیرد. - مدل کوچک/محلی برای وظایف سبک و کم‌ریسک؛ مدل قوی‌تر برای وظایف دشوار؛ fallback فقط با حفظ همان policy و data boundary. - پیش از تعمیم router، مجموعهٔ ارزیابی چندزبانه، واقعیت‌سنجی، امنیت و تکمیل وظیفه ساخته شود. - سنجهٔ تخمینی هزینه با مصرف واقعی provider و قبض reconcile شود؛ تخمین router صورتحساب قطعی نیست. - هدف آزمایش: دست‌کم ۳۰٪ کاهش هزینه با افت کیفیت حداکثر ۱ واحد درصد روی مجموعهٔ hold-out. این هدف است، نه نتیجهٔ فعلی. ### E. کارهای طولانی و زیرساخت - پذیرش job، اجرای worker، صف پایدار، checkpoint، lease، retry کنترل‌شده، idempotency، لغو و بازیابی بعد از restart لازم است. - failure domain گرهٔ اصلی و relay جدا بماند؛ relay باید بتواند مسیر سالم/جایگزین را بیازماید و وضعیت failover ثبت شود. - ظرفیت بر مبنای هزینه و ارزش کار تخصیص یابد؛ افزایش تعداد worker به‌تنهایی معیار پیشرفت نیست. - فشار فعلی ذخیره‌سازی و swap باید پیش از inference سنگین یا release جدید رفع شود؛ هیچ داده یا cache حذف نمی‌شود مگر با دستور و سیاست صریح کاربر. ### F. اقتصاد و فروش **مدل پیشنهادی:** «خروجی و کار قابل‌اعتماد» را بفروش، نه صرفاً تعداد پیام. - رابط عمومی و دانش عمومیِ معتبر می‌توانند دسترسی آزاد داشته باشند. - اجرای خصوصی، connector، storage، jobهای طولانی، منابع محاسباتی ویژه و SLAهای واقعی می‌توانند خدمات پولی باشند. - API تجاری باید usage-based باشد؛ معیار هزینه: token، CPU/GPU، مدت job، storage، egress و هزینهٔ connector. - سقف تعداد پیام یا درخواست برای هر کاربر وضع نشود؛ مدیریت ظرفیت از طریق concurrency، صف عادلانه، backpressure، service class و user-defined spend controls باشد. - هیچ هزینه‌ای قبل از نمایش و رضایت لازم مخفی نماند. - API key رایگان دائمی یا API تجاریِ بدون metering ایجاد نشود؛ کاتالوگ علمی read-only رایگان از محصول API فروشی تفکیک شود. - اولین هدف اقتصادی، **یک مشتری واقعی با یک workflow مشخص، baseline قبل از اجرا، نتیجهٔ پس از اجرا، پرداخت تسویه‌شده، هزینهٔ ثبت‌شده و contribution margin قابل‌محاسبه** است. - پیشنهاد پایلوت فعلی، یک workflow و حداکثر سه کاربر را هدف می‌گیرد؛ قیمت و درگاه پرداخت فقط پس از تأیید قانونی/تجاری و تأیید کاربر فعال می‌شود. - Darkoza Coin فقط در صورت کاربرد واقعی، دفترکل قابل‌ممیزی، تسویه و بررسی حقوقی معنا دارد؛ در این مرحله نباید محور محصول یا درآمد باشد. ### G. بازار و اکوسیستم - Marketplace فعلی به لایهٔ distribution متصل می‌شود؛ اما نصب connector تا قبل از manifest، provenance، license، security scan، scope review و قابلیت لغو مجوز خودکار نشود. - برای توسعه‌دهنده‌ها، SDK و sandbox و تست‌محیط رایگان می‌تواند ابزار جذب باشد؛ production-use با meter و billing انجام شود. - کارمزد marketplace تنها پس از فروش واقعی، تحویل، refund و dispute process تعریف شود. - بازار agent-to-agent و تسویهٔ خودکار بین عامل‌ها فعلاً ساخته نشود؛ accountability، مسئولیت حقوقی و اختلاف مالی هنوز حل نشده‌اند. ### H. علم و منفعت عمومی - GridFlex/انرژی و امکان زمان‌بندی محاسبات بر اساس قیمت/شدت کربن/انعطاف شبکه، خط پژوهشی تخصصی بماند. - مطالعات عمومیِ SMARD و آزمایش مصنوعی ۳۳‌باس قبلی همچنان با برچسب counterfactual/synthetic منتشر شوند؛ هیچ قابلیت کنترل شبکه یا صرفه‌جویی واقعی از آن‌ها استنباط نشود. - AMR و آب–غذا–انرژی در مسیر دادهٔ عمومی و تحلیل محاسباتی دنبال شوند. - همهٔ نتایج دارای منشأ، مجوز، روش، baseline، معیار ابطال، محدودیت و بازتولید باشند. --- ## ۷) اقتصاد و مسیر رسیدن به اولین ارزش واقعی ### تشخیص در وضعیت عملیاتی ثبت‌شده، اولین پرداختِ تأییدشده و contribution margin همچنان باز است. فروش API تجاری فعال نشده و کاتالوگ علوم فقط read-only preview است. دو تماس discovery قبلی صرفاً اقدام جذب مکالمه‌اند؛ نه سند نیاز، نه lead qualified، نه پرداخت. ### تصمیم به‌جای ساخت چند محصول جدید، یک مسئلهٔ محدود با مشتری واقعی انتخاب شود. گزینهٔ آزمایشی مناسب، یک workflow تکرارشوندهٔ اسناد/دانش/اتوماسیون با تأیید انسانی و گزارش نتیجه است؛ اما انتخاب نهایی باید از مکالمهٔ مشتری بیاید، نه حدس ما. ### gate تجاری 1. مکالمهٔ discovery و تعریف درد قابل‌اندازه‌گیری. 2. baseline زمان/خطا/هزینه پیش از استفاده. 3. دامنهٔ پایلوت، داده‌های مجاز، مسئولیت و معیار پذیرش. 4. تأیید merchant/KYC و درگاه مناسب برای نهاد/حوزهٔ قضایی. 5. پرداخت و تسویهٔ قابل‌اثبات. 6. تحویل workflow با گزارش قبل/بعد. 7. ثبت همهٔ هزینه‌های مستقیم و ثابت. 8. محاسبهٔ حاشیهٔ مشارکت و تصمیم ادامه/توقف. هیچ تنظیم پرداخت، wallet، credential، merchant یا checkout در این مأموریت تغییر نکرده است. --- ## ۸) نقشهٔ راه ۹۰روزه با gateهای تصمیم ### روز ۱–۱۴: اثبات نیاز و ایمنی پایه - سه مکالمهٔ qualified در یک یا دو vertical محدود؛ معیار درد، willingness-to-pay و دسترسی داده. - تعیین pilot scope و baseline؛ بدون تقاضای واقعی، توسعهٔ feature جدید متوقف بماند. - تکمیل threat model: prompt injection، tool misuse، cross-tenant leakage، confused deputy، credential leakage، SSRF، sandbox breakout، supply chain، billing abuse و memory poisoning. - رفع تناقض نسخهٔ ASI manifest/asset و اجرای E2E روی drag-drop تمام‌صفحه؛ این دو مسئلهٔ موجود را پیش از اضافه‌کردن قابلیت جدید حل کن. ### روز ۱۵–۳۰: طراحی هویت و اجرای کنترل‌شده - انتخاب IdP/OAuth/OIDC architecture؛ audience/resource-bound tokens مطابق استاندارد ابزار. - پیوند user identity، delegated agent identity و tenant. - تبدیل نمونهٔ محلی به طرح API؛ امضای approval، canonicalization اثر و grant کوتاه‌عمر. - شروع test harness؛ تمام سناریوهای cross-tenant و escalation باید fail closed باشند. - پایلوت تجاری فقط پس از تأیید merchant و توافق کتبی آغاز شود. ### روز ۳۱–۶۰: sandbox، job state و مدل هزینه - executor جدا با token broker، sandbox و allowlist شبکه. - state machine پایدار و تست قطع مرورگر، restart worker، duplicate delivery و recovery. - audit log قابل‌ممیزی و usage ledger با دادهٔ واقعی. - مدل router روی trace و benchmark واقعی Darkoza؛ no hard request caps. - فقط یک workflow customer-approved در pilot؛ با draft-first و review انسانی. ### روز ۶۱–۹۰: بازتولید و تصمیم محصول - red-team داخلی و سپس بازبینی مستقل؛ مجموعهٔ آزمون و threat coverage عمومی شود. - اندازه‌گیری کاهش هزینه، زمان، خطا و کیفیت با baseline از پیش ثبت‌شده. - یک مشتری پرداخت‌کننده و گزارش حاشیهٔ مشارکت؛ اگر حاصل نشد، بخش فروش/کانال/بسته را اصلاح کن، نه اینکه بی‌دلیل feature اضافه کنی. - connectorهای Marketplace تنها بعد از پاس‌کردن acceptance profile. - GridFlex و compute-energy scheduling در یک مسیر علمی مستقل ادامه یابد. ### معیارهای پذیرش - **۰** دسترسی cross-tenant در کل مجموعهٔ آزمون. - **۱۰۰٪** عملیات high/critical دارای approval معتبرِ همان effect. - **۰** اجرای ابزار در صورت نبود یا ابهام هویت/مجوز. - تمام mutating actions idempotent؛ duplicate side-effect = صفر در آزمون. - وضعیت completed در **۱۰۰٪** نمونه‌های آزمون دارای شاهد نتیجه باشد. - recovery پس از restart/browser disconnect در تمام سناریوهای acceptance ازپیش‌تعریف‌شده موفق باشد. - router حداقل ۳۰٪ هزینهٔ کمتر با افت کیفیت حداکثر ۱ واحد درصد را روی hold-out نشان دهد؛ در غیر این صورت عرضه نشود. - حداقل یک paid pilot تأییدشده برای عبور از gate اقتصادی؛ اگر نه، ارزش تجاری نامعلوم باقی می‌ماند. - هزینهٔ هر workflow و contribution margin قابل‌بازتولید باشد. --- ## ۹) قانون‌مندی و اعتماد طبق راهنمای رسمی کمیسیون اروپا، شفافیت Article 50 قانون AI از ۲ اوت ۲۰۲۶ اعمال می‌شود؛ دورهٔ انتقالِ محدود تا ۲ دسامبر ۲۰۲۶ فقط برای برخی سامانه‌های از قبل عرضه‌شده و بعضی الزامات marking/detection در Article 50(2) توضیح داده شده است. دامنهٔ حقوقی دقیق به نقش ارائه‌دهنده/استفاده‌کننده و نوع سیستم بستگی دارد؛ این سند نظر حقوقی یا احراز انطباق Darkoza نیست. - کاربر باید در موارد لازم بداند با سامانهٔ هوش مصنوعی تعامل می‌کند. - منشأ و نحوهٔ تولید/دستکاری محتوا باید با الزامات مربوط تطبیق داده شود. - license، upstream creator و provenance نباید با white-label مخفی یا جعل شوند. - دادهٔ خصوصی/اسرار/credential در گزارش عمومی قرار نمی‌گیرد. - اقدامات مالی، حذف، دسترسی، تغییر credential یا زیرساخت نیازمند رضایت و اختیار متناسب‌اند. منابع رسمی: - [EU AI Act — Article 50 transparency FAQs](https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act) - [EU AI Act — enforcement timeline](https://digital-strategy.ec.europa.eu/en/policies/enforcement-ai-act) - [NIST agent identity and authorization concept paper](https://www.nccoe.nist.gov/sites/default/files/2026-02/accelerating-the-adoption-of-software-and-ai-agent-identity-and-authorization-concept-paper.pdf) - [MCP Authorization specification](https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization) - [OWASP Top 10 for Agentic Applications 2026](https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) - [OWASP Top 10 for LLM Applications 2026](https://genai.owasp.org/resource/owasp-genai-llm-top-10-2026/) --- ## ۱۰) آنچه در این مأموریت واقعاً اجرا یا منتشر شد **اجراشده و آزموده‌شده** - ممیزی کد/منشور/manifest و مسیرهای عمومی ASI، Marketplace، science catalog و وضعیت gate اقتصادی نخستین مشتری. - ذخیرهٔ مرور فرصت راهبردی و محصول در ops. - نمونهٔ مرجع مستقل Authority Gate v0.2 با ۳۷ آزمون موفق. - microbenchmark محلی ۵۰٬۰۰۰ ارزیابی و ثبت نتایج. - ثبت README، test output، experiment JSON و SHA-256 manifest. **منتشرشده در این نسخه** - یک اثر جامع برای راهبرد محصول و اکوسیستم، با تحلیل شکاف‌های جاری، معماری، نمونهٔ کد، طرح کسب‌وکار، حاکمیت و نقشهٔ ۹۰روزه. - فایل‌های نمونه و آزمون به‌عنوان ضمیمهٔ کدِ تحقیقاتی، همراه با محدودیت‌های روشن. **هنوز انجام‌نشده** - ادغام Authority Gate با ASI Gateway یا Cognitive. - احراز هویت چندمستأجری، OAuth/OIDC و approval cryptographic در تولید. - اجرای ابزار sandboxed، persistence، audit ledger و metering واقعی. - رفع تناقض version marker/manifest و افزودن drag/drop تمام‌صفحه. - فروش API، merchant onboarding، پرداخت، تسویه و اولین مشتری. - آزمون مستقل امنیت، failover و cloud-memory isolation. هیچ تغییر در database/schema، سرویس‌های تولیدی، API behavior، احراز هویت، پرداخت، wallet، DNS، firewall، credential یا node membership انجام نشد. هیچ backup خودکاری اجرا نشد. انتشار، مستند و نمونهٔ تحقیقاتی است؛ نه انتشار نسخهٔ جدید برنامهٔ ASI. --- ## حکم نهایی **Darkoza باید از «چت هوشمند» به «محیط اجرای کارِ مجاز، قابل‌ردیابی و قابل‌اثبات» تکامل یابد؛ اما این تکامل باید با یک مشتری و یک نتیجهٔ واقعی آغاز شود.** DVWF می‌تواند بنیاد واحدی باشد که ASI، OERSI، ابزارها، Marketplace، حافظهٔ خصوصی، کارهای طولانی، API و اقتصاد را به یک سیستم منسجم تبدیل می‌کند. ارزش واقعی این راهبرد زمانی ثابت خواهد شد که کاربر یک کار مهم را با رضایت و حریم خصوصی انجام دهد، خروجی قابل‌اثبات بگیرد، خطر سوءاستفاده مهار شود و هزینه و منفعت برای هر دو طرف روشن باشد. این سند ادعای نوآوریِ انحصاری، امنیت کامل، فروش محقق‌شده یا خودمختاری کامل ندارد. معیار ادامهٔ سرمایه‌گذاری: شواهد فنی مستقل، رضایت مشتری، پرداخت واقعی و حاشیهٔ مشارکت قابل‌محاسبه است.