บอตสัญญาเหตุการณ์คือโปรแกรมที่เชื่อมข้อมูลเกี่ยวกับเหตุการณ์เข้ากับขั้นตอนการซื้อขายที่มีการควบคุม คำถามสำคัญที่สุดในการออกแบบไม่ใช่ว่าส่งคำสั่งได้เร็วเพียงใด แต่คือโปรแกรมรู้ได้อย่างไรว่าเกิดอะไรขึ้น ได้รับอนุญาตให้ทำอะไร และเมื่อใดบันทึกบัญชีจึงน่าเชื่อถือพอที่จะดำเนินงานต่อ ระบบที่รวดเร็วแต่สับสนระหว่างคำถามเหล่านี้อาจเปลี่ยนการตัดสินใจขนาดเล็กให้กลายเป็นสถานะที่ไม่ได้ตั้งใจ
สถาปัตยกรรมควรรักษาสายสัมพันธ์จากหลักฐานไปสู่สถานะบัญชี ข้อสังเกตจากข้อมูลสาธารณะสนับสนุนข้อเสนอแนะ ข้อเสนอแนะอาจผ่านหรือไม่ผ่านการตัดสินใจด้านความเสี่ยง คำสั่งที่ได้รับอนุมัติอาจนำไปสู่ความพยายามส่งคำสั่งซื้อขาย ซึ่งอาจเกิดการจับคู่ รายการจับคู่เหล่านั้นต้องตรงกับสถานะและยอดคงเหลือของบัญชีในภายหลัง บทความนี้อธิบายสายสัมพันธ์ดังกล่าวผ่านตัวอย่างสมมติ โดยไม่ถือว่าทุกแพลตฟอร์มมีประเภทคำสั่งเหมือนกัน หรือโปรแกรมที่ทำงานได้พิสูจน์ว่ากลยุทธ์ทำกำไรได้
บอตสัญญาเหตุการณ์ต้องมีทะเบียนสัญญา
เริ่มจากทะเบียนที่ระบุชัดว่าสัญญาใดบ้างที่บอตอาจนำมาพิจารณา เก็บบริบทของแพลตฟอร์ม ตัวระบุตลาด ตัวระบุผลลัพธ์ หน่วยชำระบัญชี และข้อมูลอ้างอิงกฎ เพิ่มเวลาเกิดเหตุการณ์ เวลาปิดการซื้อขาย และแหล่งข้อมูลที่สัญญาระบุ ทะเบียนควรแยกการเผยแพร่ครั้งแรกออกจากค่าที่แก้ไข และเก็บเวอร์ชันการจับคู่ข้อมูลที่ใช้ในการตัดสินใจทุกครั้ง
บันทึกนี้แม่นยำกว่าผลค้นหาที่มีเพียงชื่อตลาด การค้นหาอัตโนมัติอาจพบสัญญาที่น่าสนใจ แต่การค้นพบไม่ควรอนุมัติการซื้อขายโดยปริยาย สองตลาดอาจมีพาดหัวเหมือนกันแต่ใช้เกณฑ์หรือช่วงสังเกตต่างกัน การจับคู่ที่มนุษย์ตรวจแล้ว หรือกระบวนการจับคู่กฎที่ผ่านการทดสอบ ต้องยืนยันว่าข้อมูลที่บอตได้รับตอบคำถามที่ใช้ตัดสินผลสัญญาได้จริง
ให้ถือว่าการเปลี่ยนการจับคู่เป็นเหตุการณ์สำคัญของระบบ หากฟิลด์ที่เคยรู้จักไม่พร้อมใช้งาน บอตไม่ควรเลือกฟิลด์ชื่อคล้ายกันเพียงเพื่อให้ขั้นตอนยังเดินต่อได้ หากมีคำชี้แจงสัญญา ให้เก็บการตีความเดิมไว้และบันทึกการทบทวนข้อมูลใหม่ ประวัตินี้จำเป็นต่อการเข้าใจว่าเหตุใดจึงเปิดสถานะก่อนหน้าภายใต้สมมติฐานที่อาจเปลี่ยนภายหลัง
คู่มือ API สำหรับบอตตลาดคาดการณ์ ฉบับก่อนช่วยให้ผู้อ่านเข้าใจความเชื่อมโยงระหว่างตัวระบุสัญญากับการดำเนินการในบัญชี ทะเบียนไม่ได้มีไว้เพื่อความสะดวกในการเขียนโปรแกรมเท่านั้น แต่เป็นขอบเขตที่ป้องกันไม่ให้ส่งสัญญาณของเหตุการณ์หนึ่งไปยังสถานะที่ดูคล้ายกันแต่มีลักษณะทางเศรษฐกิจต่างกัน
แยกการสังเกตออกจากการตีความ
ชั้นการสังเกตบันทึกว่าแหล่งข้อมูลรายงานอะไรและระบบได้รับเมื่อใด ไม่ควรแปลงทุกข้อมูลอัปเดตเป็นสัญญาณซื้อขายทันที เก็บเวลาของแหล่งข้อมูล เวลารับ ตัวระบุ และค่าที่เกี่ยวข้องตามจริง หากข้อความซ้ำ ให้ระบุว่าเป็นข้อสังเกตเดิม ไม่ใช่การยืนยันอิสระครั้งที่สอง หากข้อความมาถึงผิดลำดับ ให้รักษาข้อมูลลำดับนั้น แทนที่จะเขียนข้อสังเกตเก่าทับข้อสังเกตใหม่
ชั้นการตีความตัดสินว่าข้อสังเกตมีความหมายอย่างไรต่อสัญญา รายงานว่าดัชนีเท่ากับ 100.3 อาจสนับสนุนฝั่ง Yes สำหรับเกณฑ์สูงกว่า 100.2 แต่เฉพาะเมื่อรายงานนั้นเป็นการเผยแพร่ ฟิลด์ และวิธีปัดเศษที่ถูกต้อง พาดหัวว่าดัชนีสูงกว่าคาดไม่เพียงพอเมื่อสัญญาถามถึงค่าตัวเลขโดยตรง ตัวแยกวิเคราะห์ต้องดึงข้อเท็จจริงที่เกี่ยวข้องกับสัญญา แทนการอ่านอารมณ์เชิงบวกหรือลบโดยรวม
ข้อมูลบางอย่างสนับสนุนการประมาณความน่าจะเป็น แทนการชี้ขาดข้อเท็จจริงโดยตรง โปรแกรมควรระบุผลนั้นว่าเป็นการคาดการณ์และเก็บความไม่แน่นอนไว้ ค่าความมั่นใจที่โมเดลภาษาหรือตัวจำแนกส่งกลับมาไม่ได้เป็นความน่าจะเป็นที่ปรับเทียบแล้วของการที่สัญญาจะจ่ายเงินโดยอัตโนมัติ หากการตีความต้องอาศัยดุลยพินิจทางกฎหมายหรือข้อเท็จจริงแบบใหม่ ระบบอาจส่งให้ตรวจทานได้โดยไม่มอบอำนาจให้โมเดลสร้างความเสี่ยง
มุมมองวินิจฉัยที่มีประโยชน์แสดงข้อสังเกตต้นฉบับคู่กับข้อสรุปที่อนุมาน เมื่อผู้ดูแลตั้งคำถามต่อการตัดสินใจ ควรตรวจสอบความเชื่อมโยงนี้ได้โดยไม่ต้องสร้างเรื่องราวขึ้นใหม่จากกราฟราคา วิธีนี้ยังช่วยแยกปัญหาจากแหล่งข้อมูลได้ง่ายขึ้นด้วย ข้อสังเกตที่เก่า การดึงข้อมูลผิด และการคาดการณ์ที่สมเหตุสมผลแต่ไม่สำเร็จ เป็นคนละปัญหาที่ต้องแก้ต่างกัน
กำหนดอำนาจตัดสินใจของบอตสัญญาเหตุการณ์
ขั้นข้อเสนอแนะเสนอการดำเนินการพร้อมสัญญา ฝั่ง จำนวน ราคาจำกัด และเหตุผล ขั้นอนุมัติตัดสินว่าข้อเสนอนั้นสอดคล้องกับข้อจำกัดปัจจุบันของบัญชีหรือไม่ ควรแยกสองขั้นนี้แม้ในโปรแกรมเล็ก กลยุทธ์อาจแนะนำให้ซื้อขณะที่บัญชีถึงวงเงินของเหตุการณ์แล้ว มีคำสั่งอื่นยังไม่คลี่คลาย หรือข้อมูลตลาดเก่าเกินกว่าจะรองรับราคาที่เสนอ
บันทึกการอนุมัติควรระบุข้อจำกัดที่ตรวจแล้ว เช่น ต้นทุนซื้อสูงสุด ความเสี่ยงสูงสุดต่อเหตุการณ์ จำนวนคำสั่งเปิดสูงสุด และข้อกำหนดให้การจับคู่สัญญายังคงเป็นปัจจุบัน ผลลัพธ์คือสิทธิ์ที่มีขอบเขตและเวลาหมดอายุ ไม่ใช่คำสั่งถาวรให้ลองต่อจนได้จำนวนที่ต้องการ หากเงื่อนไขเปลี่ยนก่อนส่งคำสั่ง ตัวดำเนินการควรขอการตัดสินใจใหม่หรือปฏิเสธการดำเนินการ
ตัวอย่างเช่น กลยุทธ์สมมติแนะนำซื้อ Yes 100 หน่วย ที่ราคาจำกัด $0.56 และกันเพิ่ม $2 สำหรับค่าใช้จ่าย ด่านความเสี่ยงบัญชีอนุญาตภาระผูกพันสำหรับเหตุการณ์นี้ไม่เกิน $60 ภาระผูกพันสูงสุดที่เสนอคือ $58 จึงผ่านข้อจำกัดข้อนั้น แต่ยังอาจไม่ผ่านข้อจำกัดอื่น เช่น คำสั่งในตลาดเดียวกันที่ยังไม่คลี่คลาย หรือการไม่มีเวลาจากแหล่งข้อมูลทางการ
ความแตกต่างนี้สำคัญเป็นพิเศษเมื่อบอตทำหลายงาน โมดูลวิจัยอาจเพิ่มสัญญาลงรายการเฝ้าดู แต่ไม่ควรได้สิทธิ์ซื้อขายเพียงเพราะทำงานในโปรเซสเดียวกับตัวดำเนินการ โมดูลแจ้งเตือนอาจเตือนคนเรื่องส่วนต่างราคาผิดปกติ แต่คำเตือนนั้นไม่ได้อนุมัติกลยุทธ์ใหม่ การระบุสิทธิ์ชัดเจนป้องกันข้อสังเกตที่มีประโยชน์จากการกลายเป็นคำสั่งบัญชีโดยไม่ตั้งใจ
กันวงเงินความเสี่ยงก่อนส่งสิ่งใด
การกันวงเงินความเสี่ยงของบอตสัญญาเหตุการณ์ป้องกันการตัดสินใจพร้อมกันหลายรายการใช้ขีดความสามารถก้อนเดียวกัน เมื่ออนุมัติคำสั่ง ให้กันต้นทุนสูงสุดที่อนุญาตและความเสี่ยงต่อเหตุการณ์ที่เกี่ยวข้องก่อนส่ง เก็บวงเงินที่กันไว้ขณะคำสั่งยังเปิดหรือผลยังไม่แน่นอน ปลดเฉพาะส่วนที่บันทึกเชื่อถือได้ยืนยันว่าไม่สามารถจับคู่ได้อีก
สมมติคำสั่ง 100 หน่วยเริ่มจับคู่แล้ว สี่สิบหน่วยจับคู่ที่ $0.54 คิดเป็น $21.60 ก่อนค่าใช้จ่าย อีกหกสิบหน่วยยังเปิดที่ราคาจำกัด $0.56 จึงอาจมีต้นทุนซื้อเพิ่มได้ถึง $33.60 เมื่อยังคงกันค่าธรรมเนียม $2 ภาระผูกพันรวมเท่ากับ $57.20 ราคาที่ต่ำลงในส่วนที่จับคู่ลดภาระจากเดิม $58 แต่ส่วนที่ยังไม่จับคู่ยังอาจกลายเป็นสถานะในอนาคต
หากงบเงินสดที่เกี่ยวข้องของบัญชีคือ $100 การกันวงเงินแบบง่ายนี้เหลือเงินที่ยังไม่มีภาระผูกพัน $42.80 ไม่ใช่ $78.40 เพียงเพราะขณะนี้จ่ายไปแค่ $21.60 ตัวเลขที่สูงกว่านั้นละเลยคำสั่งเปิด และอาจยอมให้กลยุทธ์อื่นใช้เงินที่จำเป็นต่อการจับคู่ที่อาจเกิดขึ้นแล้ว การนำไปใช้งานจริงต้องกระทบยอดค่าธรรมเนียมจริงและพฤติกรรมการกันวงเงินเฉพาะแพลตฟอร์มด้วย
ใช้มุมมองความเสี่ยงร่วมกันสำหรับทุกกลยุทธ์ที่ซื้อขายในบัญชีเดียวกัน โปรแกรมแยกกันที่มีตัวนับอิสระอาจต่างเชื่อว่าบัญชียังมีขีดความสามารถเหลือมาก บทความเดิมเรื่อง ระบบซื้อขายตลาดคาดการณ์อัตโนมัติ ให้บริบทสำหรับประสานหน้าที่เหล่านี้ ระบบกันวงเงินควรหยุดอย่างระมัดระวังเมื่อระบุไม่ได้ว่าคำสั่งอื่นยังอาจดำเนินการได้หรือไม่
จำลองคำสั่งเป็นสถานะ ไม่ใช่ข้อความว่าสำเร็จ
คำขอส่งคำสั่งอาจอยู่ในสถานะเตรียมแล้ว ส่งแล้ว ได้รับการตอบรับ รอจับคู่ จับคู่บางส่วน เสร็จสมบูรณ์ ถูกปฏิเสธ ยกเลิก หรือไม่แน่นอน สิ่งเหล่านี้เป็นสถานะเชิงแนวคิด ไม่ได้อ้างว่า API ทุกแห่งใช้ชื่อเหล่านี้ตรงกัน ให้จับคู่คำตอบจริงของแพลตฟอร์มเข้ากับแบบจำลองภายในที่มีเอกสารกำกับ เก็บคำตอบต้นฉบับคู่กับการตีความ เพื่อให้ตรวจสอบข้อผิดพลาดของตัวเชื่อมต่อในภายหลังได้
คำตอบเครือข่ายที่สำเร็จอาจยืนยันว่ารับคำขอแล้ว โดยไม่ยืนยันว่าจับคู่ครบจำนวนที่ตั้งใจ ในทางกลับกัน เครือข่ายอาจหมดเวลาหลังแพลตฟอร์มรับคำสั่งแล้ว บอตต้องไม่ถือว่าทุกความสำเร็จเป็นสถานะที่ได้ครบแล้ว และทุกการหมดเวลาเป็นการปฏิเสธ ตัวระบุคำสั่ง บันทึกการจับคู่ และภาพสถานะบัญชีให้หลักฐานต่างประเภทกันเกี่ยวกับสิ่งที่เกิดขึ้นจริง
เอกสารวงจรชีวิตคำสั่งของ Polymarket ปัจจุบันแยกสถานะคำสั่งกับสถานะการซื้อขาย ความแตกต่างนี้แสดงว่าเหตุใดค่าบูลีนภายในเพียงตัวเดียวชื่อ completed จึงไม่พอ การนำไปใช้งานต้องติดตามสถานะของแพลตฟอร์มและผลิตภัณฑ์ที่ใช้อยู่โดยเฉพาะ รวมทั้งสถานะกลางระหว่างการดำเนินการหรือชำระบัญชีที่ยังไม่คลี่คลายหลังรายงานว่าจับคู่แล้ว
ตัวดำเนินการควรเก็บคำสั่งต้นฉบับที่ได้รับอนุมัติด้วย หากจับคู่ได้ราคาดีกว่า สถานะที่เกิดขึ้นควรยังสืบย้อนถึงสิทธิ์เดิมได้ หากจำนวนที่เหลือต้องใช้ราคาสูงขึ้น นั่นคือการตัดสินใจใหม่ซึ่งต้องได้รับอนุมัติตามกฎกลยุทธ์ การเพิ่มราคาจำกัดเงียบ ๆ เพื่อให้ครบเป้าหมายเปลี่ยนตัวดำเนินการที่มีการควบคุมให้กลายเป็นองค์ประกอบกลยุทธ์ที่ไม่ได้ตรวจทาน
สถานะกู้คืนของบอตสัญญาเหตุการณ์ป้องกันความเสี่ยงซ้ำ
พิจารณาการส่งคำสั่งที่คำตอบไม่เคยมาถึงบอต บันทึกภายในรู้ว่าส่งความพยายามไปแล้ว แต่ไม่รู้ว่ากลายเป็นคำสั่งหรือไม่ สถานะถัดไปที่ถูกต้องคือไม่แน่นอน ให้คงวงเงินความเสี่ยงที่กันไว้และตรวจสอบแพลตฟอร์มด้วยตัวระบุและบันทึกบัญชีที่รองรับซึ่งสามารถคลี่คลายความพยายามนั้นได้ อย่าสร้างคำสั่งใหม่เพียงเพราะไม่มีคำตอบแรก
สมมติคำสั่งเดิมขอ 100 หน่วย บันทึกบัญชีภายหลังพบว่าจับคู่แล้ว 40 และยังเปิด 60 บอตขอยกเลิกส่วนที่เหลือ แต่มีอีก 15 หน่วยจับคู่ก่อนการยกเลิกมีผล สถานะหลังการกระทบยอดคือ 55 หน่วย และอีก 45 หน่วยไม่เปิดอีกต่อไปเมื่อยืนยันการยกเลิก หากบอตคิดว่าความพยายามเดิมล้มเหลวและส่งคำสั่ง 100 หน่วยอีกครั้ง ก็อาจเกินความเสี่ยงที่ตั้งใจไว้อย่างมาก
การกู้คืนควรคงอยู่ข้ามการเริ่มโปรเซสใหม่ เขียนตัวระบุความพยายามและวงเงินที่กันไว้ก่อนหรือเป็นส่วนหนึ่งของขั้นตอนส่งคำสั่งที่มีการควบคุม ตามการออกแบบความสอดคล้องของระบบ เมื่อเริ่มใหม่ ให้ตรวจสอบความพยายามที่ยังไม่คลี่คลายก่อนรับข้อเสนอแนะใหม่สำหรับความเสี่ยงเดียวกัน การเริ่มโปรแกรมใหม่อย่างสะอาดไม่ได้หมายความว่าบัญชีว่างเปล่า แพลตฟอร์มอาจยังเก็บคำสั่งที่โปรเซสก่อนหน้าสร้างไว้
คู่มือ ระบบอัตโนมัติสำหรับสัญญาเหตุการณ์ ขยายความแตกต่างนี้ไปสู่ขั้นตอนวิจัยและทบทวนที่เกี่ยวข้อง การกู้คืนไม่ใช่เพียงรายละเอียดวิศวกรรมสำหรับเหตุขัดข้องที่เกิดน้อย แต่เป็นส่วนหนึ่งของการควบคุมความเสี่ยงกลยุทธ์ เพราะบัญชีอาจเปลี่ยนขณะที่ระบบภายในตัดการเชื่อมต่อ เริ่มใหม่ หรือรอคำตอบ
สร้างวงจรกระทบยอดที่เป็นอิสระจากกลยุทธ์
กระบวนการกระทบยอดเปรียบเทียบสิ่งที่ระบบภายในคาดไว้กับบันทึกบัญชีที่เชื่อถือได้ ควรทำงานแม้ไม่มีสัญญาณใหม่ เปรียบเทียบคำสั่งเปิด จำนวนที่จับคู่ สถานะ ค่าใช้จ่าย และยอดคงเหลือพร้อมใช้ โดยใช้ตัวระบุและเวลาสังเกตที่สอดคล้องกัน ความไม่ตรงกันควรสร้างข้อยกเว้นที่ชัดเจน แทนการแก้เงียบ ๆ จนลบประวัติว่าแบบจำลองภายในผิดไปได้อย่างไร
แยกความต่างด้านเวลาตามปกติออกจากความคลาดเคลื่อนที่อธิบายไม่ได้ การอัปเดตการจับคู่อาจมาถึงก่อนการอัปเดตยอดคงเหลือที่เกี่ยวข้อง ขึ้นกับช่องทางรายงานของแพลตฟอร์ม ระบบอาจยอมให้มีสถานะชั่วคราวที่ระบุในเอกสารระหว่างรอภาพสถานะที่สอดคล้องกัน แต่ความคลาดเคลื่อนที่อยู่นานเกินกระบวนการที่คาดควรปิดกั้นความเสี่ยงใหม่ในขอบเขตที่ได้รับผลจนกว่าจะอธิบายได้ ขอบเขตอาจเป็นตลาดหนึ่ง บัญชีหนึ่ง หรือตัวดำเนินการทั้งหมด
บันทึกการกระทบยอดควรระบุว่าข้อสังเกตใดรองรับสถานะปัจจุบัน ผู้ดูแลควรเห็นได้ว่า 55 หน่วยมาจากการจับคู่สองรายการจำนวน 40 และ 15 ไม่ใช่อนุมานจากส่วนต่างของยอดที่ปัดเศษ เก็บการปรับค่าธรรมเนียมแยกไว้ เพื่อไม่ให้เข้าใจเงินสดที่เปลี่ยนเป็นจำนวนสัญญาที่เปลี่ยน หลังตัดสินผล ให้เชื่อมเงินจ่ายกับสถานะที่เหลือจริงและผลสุดท้ายของสัญญา
ผู้อ่านที่สร้างระบบเชื่อมต่อบัญชีสามารถใช้บทความเดิมเรื่อง บอตซื้อขายผ่าน Kalshi API เพื่อจัดระบบบันทึกที่จำเป็น หลักการนี้ไม่ขึ้นกับภาษาที่ใช้เขียนระบบ กลยุทธ์เสนอสิ่งที่ควรเกิด ส่วนการกระทบยอดยืนยันว่าสิ่งใดเกิดขึ้นแล้ว ทั้งสองหน้าที่ไม่ควรนำความคาดหมายของตนมาแทนหลักฐานที่ขาดหาย
เพิ่มขอบเขตสำหรับระบบหลายขาและระบบเสนอราคา
บอตที่เลือกทิศทางมักแสดงความเสี่ยงผ่านสถานะเดียวได้ ระบบหลายขาต้องติดตามว่าชุดสถานะที่ตั้งใจครบหรือไม่ และเหลืออะไรหากจับคู่ได้เพียงบางคำสั่ง โอกาส อาร์บิทราจสัญญาเหตุการณ์ ที่นำมาพิจารณาขึ้นอยู่กับเงินจ่ายที่เข้ากันและการดำเนินการที่เป็นไปได้ บอตควรแสดงแต่ละขาและผลลัพธ์รวมที่เป็นไปได้ แทนการบันทึกว่าคู่ครบแล้วทันทีที่คำสั่งแรกได้รับการตอบรับ
กันขีดความสามารถสำหรับขาที่ยังไม่เสร็จ และกำหนดเวลาหรือเงื่อนไขสูงสุดที่ยอมให้อยู่โดยยังไม่ครบคู่ หากขาที่สองไม่พร้อมใช้งาน ระบบต้องมีการตอบสนองที่กำหนดล่วงหน้าและสอดคล้องกับวงเงินขาดทุนบัญชี อาจรวมถึงยกเลิกคำสั่งที่ยังไม่จับคู่ ลดสถานะแรก หรือคงความเสี่ยงภายในขอบเขตเพื่อให้ตรวจทาน ไม่ควรถือว่าการป้องกันความเสี่ยงใด ๆ ไม่ว่าราคาเท่าไรย่อมดีกว่าการตัดสินใจอย่างมีระเบียบเสมอ
ระบบเสนอราคาเผชิญความท้าทายอีกแบบ ทั้งสองฝั่งอาจยังทำงานอยู่ขณะที่การจับคู่เปลี่ยนสถานะคงค้าง ผู้ดูแลสภาพคล่องสัญญาเหตุการณ์ จึงต้องมีสิทธิ์ที่คำนึงถึงสถานะคงค้างและมุมมองราคาเสนอที่ยังเปิดอย่างเชื่อถือได้ การอัปเดตราคาเสนอที่แทนคำสั่งเดิมต้องคำนึงถึงช่วงที่ทั้งสองคำสั่งอาจยังมีผล ความเสี่ยงรวมและสุทธิที่ระบบอนุญาตควรสะท้อนความเป็นไปได้นี้
ส่วนขยายเหล่านี้แสดงว่าฟังก์ชันซื้อหรือขายทั่วไปยังไม่ใช่สถาปัตยกรรมบอตที่ครบถ้วน กลยุทธ์ต่างกันต้องใช้วิธีแสดงงานที่ยังไม่เสร็จต่างกัน รากฐานร่วมคืออำนาจที่ชัดเจน การเก็บเอกลักษณ์คำสั่ง และการกระทบยอด ส่วนชั้นเฉพาะกลยุทธ์อธิบายว่าชุดการจับคู่ใดรับได้ และต้องมีหลักฐานใดก่อนดำเนินการถัดไป
ติดตามนาฬิกาที่กำกับการตัดสินใจ
บอตควรเก็บเวลาหลายประเภทเพราะตอบคนละคำถาม เวลาของแหล่งเหตุการณ์บอกว่าข้อมูลเผยแพร่เมื่อใด เวลารับบอกว่าโปรเซสภายในได้รับเมื่อใด เวลาสมุดคำสั่งบอกสถานะตลาดที่ใช้เสนอแนะ เวลาอนุมัติบอกว่าบัญชีอนุมัติการดำเนินการเมื่อใด การรวมทั้งหมดไว้ในฟิลด์เวลาเดียวอาจซ่อนข้อสังเกตที่เก่าไว้เบื้องหลังเหตุการณ์ประมวลผลล่าสุด
สมมติข้อสังเกตเผยแพร่เวลา 9:00 ถึงตัวรวบรวมเวลา 9:01 และถูกนำมาประมวลผลซ้ำหลังเริ่มใหม่เวลา 9:10 ข้อมูลที่เล่นซ้ำเป็นข้อมูลใหม่สำหรับโปรเซสที่เริ่มใหม่ แต่หลักฐานต้นทางมีอายุสิบนาทีแล้ว กฎความสดใหม่ที่อิงเวลาเพิ่มข้อมูลภายในอย่างเดียวอาจทำให้บอตมองข้อสังเกตนี้ว่าเป็นปัจจุบัน เก็บเวลาเดิมและทำเครื่องหมายการเล่นซ้ำอย่างชัดเจน เพื่อให้กฎประเมินข้อเท็จจริงที่ออกแบบมาเพื่อจำกัด
การเปรียบเทียบเวลายังต้องมีนโยบายสำหรับค่าที่ขาดหรือไม่สอดคล้องกัน หากแหล่งข้อมูลไม่มีเวลาเผยแพร่ที่เชื่อถือได้ ระบบไม่ควรสร้างขึ้นเอง อาจใช้ทางเลือกสำรองที่บันทึกไว้พร้อมสิทธิ์ที่เข้มงวดขึ้น หรือระงับการดำเนินการที่ต้องการหลักฐานเวลาดีกว่านั้น เป้าหมายคือทำให้ความไม่แน่นอนด้านเวลาปรากฏในบันทึกการตัดสินใจ แทนการปล่อยให้เวลาที่ดูแม่นยำบ่งบอกความรู้ที่ระบบไม่มี
ทดสอบด้วยเหตุการณ์ที่เปลี่ยนบัญชี
ชุดทดสอบที่มีประโยชน์มุ่งที่การเปลี่ยนสถานะซึ่งมีผลจริง จำลองคำตอบหมดเวลาหลังรับคำสั่ง การจับคู่บางส่วนระหว่างยกเลิก ภาพสถานะตลาดที่เก่า และการเริ่มใหม่พร้อมคำสั่งที่ยังไม่คลี่คลาย ตรวจว่าบอตรักษาวงเงินที่กันไว้อย่างถูกต้องและปฏิเสธการดำเนินการที่อาจเกินข้อจำกัด การทดสอบที่เพียงยืนยันว่าฟังก์ชันคืนค่าที่กำหนดไว้ภายในให้หลักฐานน้อยมากเกี่ยวกับเส้นทางความล้มเหลวจริงเหล่านี้
ใช้เหตุการณ์จำนวนเล็กน้อยที่เล่นซ้ำได้และทราบบันทึกที่คาดไว้ สำหรับตัวอย่าง 100 หน่วย การทดสอบควรจบด้วยจับคู่ 55 และยกเลิก 45 โดยไม่มีการส่ง 100 หน่วยครั้งที่สอง แบบจำลองเงินสดควรสะท้อนราคาจับคู่และค่าใช้จ่ายจริง แทนประมาณการสูงสุดเดิม อีกการทดสอบอาจจงใจละเหตุการณ์จับคู่ และกำหนดให้การกระทบยอดกู้คืนรายการที่ขาดจากการสอบถามบัญชี
ทดสอบการไม่ทำอะไรซึ่งไม่ก่อความเสียหายด้วย เมื่อไม่มีการคาดการณ์ การจับคู่สัญญายังไม่คลี่คลาย หรือสถานะบัญชีไม่สอดคล้องกัน ผลที่ถูกต้องอาจเป็นไม่มีคำสั่ง ระบบที่ประเมินเฉพาะการส่งสำเร็จอาจให้รางวัลกับกิจกรรมโดยมองข้ามการตัดสินใจที่ป้องกันความเสี่ยงไม่พึงประสงค์ บันทึกเหตุผลที่ปฏิเสธ เพื่อให้ผู้ดูแลแยกการพักโดยตั้งใจออกจากความขัดข้องที่ไม่ถูกสังเกต
บอตพร้อมใช้งานในวงกว้างขึ้นก็ต่อเมื่อบันทึกทำให้เข้าใจการทำงานปกติและการกู้คืนได้ ผู้ดูแลควรระบุสัญญาปัจจุบัน หลักฐาน สิทธิ์ ภาระผูกพันที่ยังเปิด และสถานะที่ยืนยันแล้วได้โดยไม่ต้องเดา ความโปร่งใสนี้ไม่ได้พิสูจน์ความได้เปรียบในการซื้อขาย แต่ทำให้ตรวจทานพฤติกรรมโปรแกรมได้ และให้รากฐานที่เชื่อถือได้สำหรับประเมินกลยุทธ์