Jiclo.

یک عامل هوش مصنوعی نمی‌تواند تنها بر اساس عنوان و قیمت محصول، تصمیم خرید قابل اتکایی بگیرد. او باید بفهمد آیا کالا با درخواست مطابقت دارد، کدام الزامات اعمال می‌شوند و فرآیند تحویل شامل چه مواردی است.

خلاصه محصول Jiclo تجارت را حول API ای سازمان‌دهی می‌کند که به عامل اجازه می‌دهد یک محصول فیزیکی را خریده و تحویل بگیرد. پیشنهاد زیربنایی بر اطلاعات عرضه نرمال‌شده تمرکز دارد، نه فهرستی از توضیحات محصولات بی‌ربط.

رکورد مفید باید کالا را در زمینه خرید درخواست‌شده توضیح دهد. تناسب، الزامات و تحویل بخشی از اطلاعاتی می‌شوند که عامل می‌تواند از آن استفاده کند، نه جزئیاتی که پس از تصمیم‌گیری برای کشف توسط انسان باقی می‌ماند.

این رویکرد سوال طراحی را از «نمایش کاتالوگ» به «بازنمایی یک وظیفه خرید» تغییر می‌دهد. رابط و API باید محدودیت‌ها و اقدام بعدی را آنقدر شفاف کنند که برای بازیگر استفاده‌کننده قابل اجرا باشد.

پروژه تحقیقات خام بازار و خلاصه محصول را به عنوان مصنوعات کاری جداگانه نگه می‌دارد. تحقیقات می‌توانند به پیشنهاد کمک کنند، در حالی که خلاصه محصول، تصمیم محصولی ناشی از آن را ثبت می‌کند.

این تمایز در توسعه تجارت اهمیت دارد: تقاضای مشاهده‌شده، قابلیت پیشنهادی و تراکنش تکمیل‌شده انواع مختلفی از شواهد هستند. نباید آن‌ها را در یک وعده روی ویترین فروشگاه ادغام کرد.

پروژه مدلی از تجارت را نشان می‌دهد که برای تصمیمات ماشین‌خوان و همچنین تجربه خرید قابل مشاهده طراحی شده است. این موضوع معماری اطلاعات محصول را با معنای عملیاتی یک خرید متصل می‌کند.

درس اجرایی این است که تعیین کنید خریدار یا عامل قبل از تعهد به چه حقایقی نیاز دارد. رکوردهای محصول، اعتبارسنجی و الزامات تحویل در کنار طراحی فرانت‌اند در محدوده پروژه قرار می‌گیرند.

این مطالعه پورتفولیو خلاصه محصول Jiclo را دنبال می‌کند: سازمان‌دهی درخواست حول تناسب، الزامات، تحویل و یک تصمیم خرید صریح. قرارداد تجارت ساختاریافته، حقایق یکسانی را برای کار خریدار و عامل فراهم می‌کند.

دسترسی تأمین‌کننده، دسته‌بندی و منطقه‌ای بودن الزاماتی هستند که برای یک انتشار خاص باید تثبیت شوند. خلاصه پروژه منبع مدل توصیف‌شده اینجا است.