سؤالی بنویسید که قابل تعیین نتیجه باشد
از رویداد دقیقی شروع کنید که بازار قرار است اندازه‌گیری کند. پرسشی مانند «آیا شبکه امسال راه‌اندازی می‌شود؟» چند برداشت مختلف ایجاد می‌کند: تست عمومی، انتشار عملیاتی یا دسترسی بدون محدودیت. رویداد واجد شرایط، منبع شواهد نام‌برده، زمان پایان و منطقه زمانی را مشخص کنید. یک مثال کامل از نتیجه‌ای که واجد شرایط است و مثالی دیگر از نتیجه‌ای که واجد شرایط نیست ارائه دهید. از فردی خارج از پروژه بخواهید متن را تفسیر کند. اگر دو خواننده منطقی به پاسخ‌های متفاوت برسند، پیش از پذیرش موقعیت‌ها، قاعده را بهبود دهید.
موارد دشوار را پیش از وقوع تعیین تکلیف کنید
مشخصات مفید یک بازار باید به تعویق‌ها، اعلامیه‌های لغوشده، تغییر نام پروژه‌ها، وب‌سایت‌های از دسترس خارج‌شده و اصلاح داده‌های منتشرشده بپردازد. مشخص کنید آیا استفاده از منبع جایگزین مجاز است و چه کسی آن را انتخاب می‌کند. توضیح دهید نتیجه‌ای که پس از زمان پایان منتشر می‌شود چگونه بررسی می‌گردد، حتی اگر رویداد اصلی زودتر رخ داده باشد. این‌ها تصمیم‌های محصولی هستند که باید پیش از مشارکت قابل مشاهده باشند. متن توافق‌شده را تحت کنترل نسخه قرار دهید و نسخه آن را به رکورد بازار متصل کنید. تغییرات ویرایشی بعدی هرگز نباید بی‌سروصدا شروط مربوط به موقعیت‌های موجود را بازنویسی کند.
پیشنهاد نتیجه را از تسویه نهایی جدا کنید
مستندات اوراکل UMA میان پاسخ پیشنهادی، دوره چالش و مسیر اختلاف تمایز می‌گذارد. محصول هر سازوکاری را که انتخاب کند، باید مراحل آن را صریح مدل‌سازی کند. بستن معاملات نباید به‌خودی‌خود نتیجه نهایی ایجاد کند. پیشنهاد تعیین نتیجه باید شواهد و زمان ثبت خود را مشخص کند؛ نتیجه پذیرفته‌شده نیز باید قاعده تکمیل‌شده‌ای را نشان دهد که آن را نهایی کرده است. تعریف کنید چه کسی می‌تواند هر گذار را انجام دهد و کدام بررسی‌ها روی سرور انجام می‌شود. رابط‌های مشتری و ابزارهای اپراتور باید یک وضعیت پایدار مشترک را بخوانند، نه اینکه هرکدام جداگانه روند پیشرفت را حدس بزنند.
اختلاف‌ها را قابل فهم کنید
مشارکت‌کننده باید بتواند ببیند چه چیزی به چالش کشیده شده، مهلت پاسخ چه زمانی پایان می‌یابد و گام بعدی چیست. پیشنهاد اولیه، استدلال مخالف و شواهد پشتیبان هرکدام را از هم متمایز نگه دارید. از یک فیلد یادداشت قابل ویرایش که استدلال‌های قبلی را پاک می‌کند پرهیز کنید. فرایندی روشن برای گزارش لینک خراب یا قاعده مبهم ارائه دهید، بدون اینکه تصمیم خاصی را وعده دهید. مجوزهای مدیریتی نیز به همین نظم نیاز دارند: بازبینی شواهد، پیشنهاد اصلاح و مجاز کردن تسویه باید اقدام‌هایی جداگانه و قابل شناسایی با تاریخچه حسابرسی باشند.
جابجایی پول را مستقل تست کنید
تست‌های تسویه را بر اساس موقعیت‌های ثبت‌شده و نتیجه توافق‌شده بسازید. گرد کردن، موقعیت‌های جزئی، موجودی‌های رزروشده، بازپرداخت‌ها در مواردی که قواعد منتشرشده الزام می‌کند، و ارسال تکراری همان نتیجه را بررسی کنید. اگر یک ورکر در میانه تسویه دوباره راه‌اندازی شود، نباید برخی موقعیت‌ها را دوبار پرداخت کند. مجموع مبلغ‌های آزادشده، نگه‌داری‌شده و برگشت‌داده‌شده را با دفترکل اولیه تطبیق دهید. نوشتن‌های قطع‌شده در پایگاه داده و پاسخ‌های با تأخیر ارائه‌دهنده را در نمونه‌های پذیرش لحاظ کنید. وقتی حسابداری پس از نتیجه قابل بازتولید و توضیح نباشد، درست بودن تیتر نتیجه کافی نیست.
شواهد را همراه رابط ارائه کنید
صفحه نهایی بازار باید پرسش، نسخه قاعده، مهلت‌های مرتبط، نتیجه و مسیر شواهد را حفظ کند. وضعیت «در انتظار تعیین نتیجه» را صادقانه نمایش دهید و آن را از درخواست ناموفق سرویس متمایز کنید. تاریخ‌ها را در زبان‌ها و اندازه‌های صفحه مختلف تست کنید تا یک برچسب ترجمه‌شده نتواند زمان واقعی پایان را پنهان کند. پیش از راه‌اندازی، تیم‌های محصول، عملیات و مهندسی با هم یک نتیجه عادی و یک نتیجه مورد اختلاف را مرور کنند. خروجی نهایی، فرایند تصمیم‌گیری تکرارپذیر با سوابق پاسخ‌گو است که با رابطی شفاف و سیاست عملیاتی صریح پشتیبانی می‌شود.