ข้อกำหนดรางวัล

วัตถุประสงค์ เอกสารนี้กำหนดโครงสร้างกองทุนรางวัล เงื่อนไขขั้นต่ำ กระบวนการเรียกร้องรางวัล และกฎระเบียบสำหรับ MT Eval Arena โดยระบุอย่างชัดเจนว่า "ความสามารถในการแปลด้วยเครื่อง" หมายความว่าอย่างไรในเชิงวัดผลได้ และภายใต้เงื่อนไขใดที่เงินรางวัลจะถูกปล่อยออก เอกสารนี้อ้างอิง SCORING_SPEC สำหรับนิยามเมตริก และ BENCHMARK_SPEC สำหรับโปรโตคอลการประเมิน — โดยไม่ซ้ำซ้อนเนื้อหาจากเอกสารเหล่านั้น

สถานะ: LIVE. รางวัล Founder's Prize (§2.1) ได้รับการสนับสนุนทุนและเปิดใช้งานแล้ว

อัปเดตล่าสุด: 2026-06-04

---

1. ปรัชญา

1.1 รางวัลมอบให้กับความก้าวหน้า ไม่ใช่การมีส่วนร่วม

เงินรางวัลจะถูกปล่อยออกก็ต่อเมื่อวิธีการหนึ่งสามารถบรรลุเกณฑ์ความสามารถที่กำหนดไว้ได้อย่างพิสูจน์ได้จริง ไม่มีรางวัลสำหรับการมีส่วนร่วม รางวัลรองชนะเลิศ หรือการจ่ายเงินปลอบใจ หากไม่มีใครผ่านเกณฑ์ ก็ไม่มีใครได้รับเงิน นี่คือการออกแบบโดยเจตนา — หมายความว่าผู้สนับสนุนจะจ่ายเงินเฉพาะสำหรับผลลัพธ์ที่ใช้งานได้จริงเท่านั้น

1.2 การตรวจสอบโดยชุมชนเป็นสิ่งที่ขาดไม่ได้

เมตริกอัตโนมัติเป็นเพียงตัวแทน (SCORING_SPEC §1.1) วิธีการหนึ่งอาจได้คะแนน chrF++ และ FST acceptance สูง ในขณะที่ผลิตผลลัพธ์ที่ผู้พูดภาษานั้นไม่ยอมรับ ทุกการเรียกร้องรางวัลต้องผ่านการตรวจสอบโดยชุมชน — ผู้พูดสองภาษาต้องยืนยันว่าผลลัพธ์นั้นใช้งานได้ นี่คือประตูการตรวจสอบโดยมนุษย์ (BENCHMARK_SPEC §7)

1.3 การโอนกรรมสิทธิ์เป็นส่วนหนึ่งของข้อตกลง

วิธีการที่เรียกร้องรางวัลจะอยู่ภายใต้ข้อกำหนดการโอนกรรมสิทธิ์ (BENCHMARK_SPEC §8.3) นักพัฒนายังคงสิทธิ์การระบุที่มาและสิทธิ์การเผยแพร่ผลงาน องค์กรกำกับดูแลได้รับสิทธิ์ในการใช้ แก้ไข เผยแพร่ และสร้างรายได้จากวิธีการดังกล่าวสำหรับภาษาของตน นี่ไม่ใช่บทลงโทษ — แต่คือจุดประสงค์หลัก เงินรางวัลสนับสนุนการสร้างเทคโนโลยีที่เป็นของชุมชนภาษา

1.4 การป้องกันการโกง

เกณฑ์รางวัลถูกกำหนดเทียบกับ การประเมินมาตรฐานทอง (ชุดทดสอบลับ ดำเนินการโดยองค์กรกำกับดูแลในสภาพแวดล้อม sandbox) นักพัฒนาไม่เคยเห็นข้อมูลทดสอบ สิ่งนี้ถูกบังคับใช้ในเชิงสถาปัตยกรรม — ไม่ใช่นโยบายที่อาศัยความซื่อสัตย์ ดู BENCHMARK_SPEC §8.2

1.5 การอนุญาตใช้งานคลังข้อมูล: คลังข้อมูลที่ไม่ใช่เชิงพาณิชย์ไม่อยู่ในเส้นทางรางวัล

คลังข้อมูลบางส่วนที่ใช้ในระหว่างการพัฒนาวิธีการมีสัญญาอนุญาตที่ไม่ใช่เชิงพาณิชย์ — ตัวอย่างเช่น คลังข้อมูล EdTeKLA Cree Language Textbook มีสัญญาอนุญาต CC BY-NC-SA 4.0 คลังข้อมูลเหล่านี้อยู่ใน เส้นทางวิจัย/พัฒนาเท่านั้น:

1. คลังข้อมูลมาตรฐานทองสำหรับรางวัลต้องไม่ฝังเนื้อหาจากคลังข้อมูลที่มีสัญญาอนุญาต NC ส่วนทดสอบมาตรฐานทองเป็นต้นฉบับที่ว่าจ้างจากชุมชน (ดู Corpus Partnership Strategy) — เขียนโดยมนุษย์เพื่อรางวัลโดยเฉพาะ โดยมีสิทธิ์ที่ได้รับการอนุมัติสำหรับการประเมินและการนำไปใช้งานเชิงพาณิชย์ตั้งแต่ต้น
2. วิธีการที่เรียกร้องรางวัลต้องไม่ฝังเนื้อหาจากคลังข้อมูลที่มีสัญญาอนุญาต NC (เช่น เป็นข้อมูลการฝึกสอน ตัวอย่างที่ฝังไว้ หรือตารางค้นหา) วิธีการที่โอนกรรมสิทธิ์มีจุดประสงค์เพื่อการนำไปใช้งานเชิงพาณิชย์โดยองค์กรกำกับดูแล (BENCHMARK_SPEC §8.3, Method Submission Agreement §6) เนื้อหาที่มีสัญญาอนุญาต NC ภายในวิธีการจะทำให้การนำไปใช้งานนั้นเป็นปัญหา
3. นักพัฒนาสามารถใช้คลังข้อมูลที่มีสัญญาอนุญาต NC ได้อย่างอิสระเพื่อพัฒนาและประเมินตนเอง — นั่นคือจุดประสงค์ของเส้นทางพัฒนา ข้อจำกัดใช้กับสิ่งที่ส่งและสิ่งที่นำไปใช้งาน ไม่ใช่กับวิธีที่นักพัฒนาเรียนรู้

1.6 ประเภทการพึ่งพาเป็นตัวกำหนดสิทธิ์รับรางวัล

การประเมินรางวัลทั้งหมดเกิดขึ้นใน sandbox (§1.4) และวิธีการที่ชนะรางวัลจะโอนไปยังองค์กรกำกับดูแล (§1.3) ทั้งสองข้อเท็จจริงกำหนดข้อจำกัดเดียวกัน: ทุกสิ่งที่วิธีการพึ่งพาต้องเป็นสิ่งที่นักพัฒนามีสิทธิ์นำเข้า sandbox และส่งมอบให้ชุมชน การส่งทุกรายการต้องประกาศประเภทการพึ่งพา — กำหนดไว้ใน ข้อกำหนด Method Interface โดยมีเงื่อนไขการรับเข้าใน Method Submission Agreement §2.6 — และสิทธิ์รับรางวัลเป็นไปตามประเภทดังนี้:

ประเภทการพึ่งพา	มีสิทธิ์รับรางวัล?	เงื่อนไข
S — พึ่งพาตนเอง	✅ ใช่	ไม่มีเงื่อนไขนอกจากเงื่อนไขขั้นต่ำใน §2
O — ภายนอกแบบเปิด (เช่น AGPL FST ที่ mirror ณ เวลาส่ง)	✅ ใช่	Artifacts ถูก pin และ vendor เข้าในการส่ง สัญญาอนุญาตอนุญาตให้โอนให้ชุมชน เงื่อนไข copyleft ได้รับการรักษาไว้ (ชุมชนได้รับสิทธิ์เดียวกับที่สัญญาอนุญาตมอบให้ทุกคน)
A1 — LLM inference ที่ทดแทนได้	⚠️ มีเงื่อนไข	โมเดลถูกประกาศ pin และทดแทนได้ (ต้องรันกับโมเดลน้ำหนักเปิดที่โฮสต์โดยชุมชน) การประเมินถูกส่งผ่าน sandbox LLM gateway (🔲 วางแผนไว้ — วิธีการ A1 ไม่สามารถสร้างคะแนนมาตรฐานทองได้จนกว่า gateway จะพร้อมใช้งาน) การโอนกรรมสิทธิ์ส่งมอบสูตรทั้งหมด (prompts, coaching, code) ไม่ใช่โมเดล
A2 — API ข้อมูล/บริการภายนอกที่ทดแทนไม่ได้	❌ ยังไม่ได้	ไม่มีสิทธิ์จนกว่าเจ้าของสิทธิ์จะอนุญาตให้รวมใน sandbox และโอนกรรมสิทธิ์ได้ อนุญาตบน leaderboard แบบเปิดพร้อมป้าย "external dependency" ที่มองเห็นได้
X — เนื้อหาที่รวมไว้โดยไม่มีสิทธิ์	❌ ไม่มีทาง	ไม่รับเข้าในทุกเส้นทาง

ประเภทของวิธีการคือประเภทที่มีข้อจำกัดมากที่สุดในบรรดาการพึ่งพาที่ประกาศไว้ การพึ่งพาที่ไม่ได้ประกาศในทุกประเภทถือเป็นเหตุตัดสิทธิ์ (§5)

---

2. กองทุนรางวัลที่เปิดใช้งาน

2.1 Founder's Prize — EN→Plains Cree (nêhiyawêwin)

ฟิลด์	ค่า
กองทุนรางวัล	$10,000 CAD
คู่ภาษา	English → Plains Cree (EN→CRK)
สนับสนุนโดย	ผู้ก่อตั้งโครงการ Champollion
สถานะ	เปิดใช้งาน — รับการส่งผลงาน
เปิดรับ	เมื่อคลังข้อมูลมาตรฐานทอง + องค์กรกำกับดูแลพร้อมแล้ว
หมดอายุ	ไม่มีวันหมดอายุ รางวัลยังคงใช้งานได้จนกว่าจะมีผู้เรียกร้องหรือถอนออกอย่างชัดเจน

เงื่อนไขขั้นต่ำ

วิธีการเรียกร้อง Founder's Prize โดยต้องปฏิบัติตาม เงื่อนไขทั้งหมด ต่อไปนี้พร้อมกัน:

#	เงื่อนไข	เมตริก	เกณฑ์	เหตุผล
1	Composite score	composite (SCORING_SPEC §4)	≥ 0.80	อยู่ระหว่าง Deployable (0.70) และ Fluent (0.85) ต้องการคุณภาพสูงในทุกมิติของเมตริก — ไม่ใช่แค่ความถูกต้องทางสัณฐานวิทยา
2	FST acceptance	fst_acceptance_rate (SCORING_SPEC §2.2)	≥ 0.99 (99%+)	คำในผลลัพธ์ทั้งหมดต้องเป็นรูปแบบที่ถูกต้องทางสัณฐานวิทยาที่ GiellaLT FST รู้จัก ค่าความคลาดเคลื่อน 1% รองรับกรณีพิเศษ (คำนามเฉพาะ คำใหม่ คำยืม) ที่ FST อาจไม่ครอบคลุมอย่างถูกต้อง นี่คือประตูคุณภาพที่กำหนดสำหรับ MT ภาษาโพลีซินเทติก — หาก FST ปฏิเสธคำมากกว่า 1% แสดงว่าวิธีการกำลังสร้างรูปแบบที่ไม่มีอยู่ในภาษา จุดประสงค์ทั้งหมดของรางวัลนี้คือการซื้อระบบที่ไม่บิดเบือนภาษา
3	chrF++	chrf_plus_plus (SCORING_SPEC §2.1)	≥ 55.0	ความทับซ้อนของ character n-gram ต้องเกิน 55 บนสเกล 0–100 เพื่อให้มั่นใจว่ามีความคล้ายคลึงในระดับพื้นผิวกับการแปลอ้างอิง ไม่ใช่แค่ความถูกต้องทางสัณฐานวิทยา
4	การตรวจสอบโดยชุมชน	การตรวจสอบโดยมนุษย์ (BENCHMARK_SPEC §7)	≥ 70% "acceptable" หรือ "excellent"	ตัวอย่างผลลัพธ์แบบแบ่งชั้น (≥30 รายการครอบคลุมระดับความยาก 2–5) ได้รับการตรวจสอบโดยผู้พูดสองภาษา CRK ≥2 คน อย่างน้อย 70% ของรายการที่ตรวจสอบต้องได้รับการให้คะแนน "acceptable" หรือ "excellent"
5	การประเมินมาตรฐานทอง	การรันใน sandbox (BENCHMARK_SPEC §8.2)	จำเป็น	เมตริกอัตโนมัติทั้งหมดต้องคำนวณเทียบกับส่วนคลังข้อมูล gold_standard โดยองค์กรกำกับดูแลในสภาพแวดล้อม sandbox คะแนนจากชุดพัฒนาไม่นับ
6	การทำซ้ำได้	การจับคู่ fingerprint (BENCHMARK_SPEC §3.8)	±2%	องค์กรกำกับดูแลต้องสามารถรันวิธีการซ้ำและได้คะแนนภายใน ±2% ของ run card ที่ส่งมา

ทำไมต้อง 99%+ FST? ปัญหาหลักในการแปลด้วยเครื่องสำหรับภาษาโพลีซินเทติกคือการสร้างข้อมูลเท็จ (hallucination) — LLM สร้างสตริงที่ ดูเหมือน ภาษาเป้าหมายแต่ไม่ถูกต้องทางสัณฐานวิทยา วิธีการที่สร้างผลลัพธ์ถูกต้อง 95% ยังคงมีคำที่สร้างขึ้นเท็จ 5% — เป็นสัญญาณรบกวนที่ยอมรับไม่ได้สำหรับการใช้งานจริง เกณฑ์ 99%+ ต้องการ hallucination ใกล้ศูนย์ในขณะที่ยังรองรับกรณีพิเศษที่หายาก (คำนามเฉพาะที่ FST ไม่รู้จัก คำใหม่ที่ถูกต้อง) หากวิธีการไม่สามารถบรรลุ FST acceptance 99%+ แสดงว่ายังไม่ได้แก้ปัญหา

ทำไมต้อง composite 0.80? ค่านี้อยู่ระหว่าง Deployable (0.70) และ Fluent (0.85) วิธีการที่ได้ 0.80 พร้อม FST 99%+ สร้างผลลัพธ์ที่แทบทุกคำเป็นคำ Cree จริง และ คุณภาพการแปลโดยรวมสูงในทุกมิติ ทั้งพื้นผิว โครงสร้าง และความหมาย ประตูการตรวจสอบโดยชุมชน (เงื่อนไข #4) ทำให้มั่นใจว่านี่ไม่ใช่แค่การเล่นกับเมตริก — ผู้พูดต้องยืนยันว่าผลลัพธ์ใช้งานได้จริง

ความหมายของเกณฑ์นี้ในทางปฏิบัติ

ที่ composite ≥ 0.80 พร้อม FST ≥ 0.99 และ chrF++ ≥ 55 ผู้พูดสองภาษาจะเห็นโดยทั่วไปว่า:

• แทบทุก คำในผลลัพธ์เป็นคำ Cree จริง (FST ตรวจสอบ 99%+ — รูปแบบที่สร้างขึ้นเท็จใกล้ศูนย์)
• หมวดหมู่ไวยากรณ์หลัก (บุคคล จำนวน กาล) ถูกต้องในรายการส่วนใหญ่
• ลำดับคำเป็นธรรมชาติโดยทั่วไป
• ความหมายได้รับการรักษาไว้อย่างน่าเชื่อถือ
• ข้อผิดพลาดที่เหลืออยู่เป็นข้อผิดพลาดในภาษาจริง (การผันคำผิด การใช้ obviation ผิด ความไม่ตรงกันของ animacy) — ไม่ใช่คำที่สร้างขึ้นเท็จ
• ผู้พูดที่คล่องแคล่วสามารถใช้ผลลัพธ์เป็นร่างคุณภาพสูงและแก้ไขได้เร็วกว่าการแปลตั้งแต่ต้นอย่างมีนัยสำคัญ

นี่คือระบบที่ ไม่บิดเบือนภาษา อาจไม่สมบูรณ์แบบ แต่ทุกคำที่สร้างขึ้นเป็นคำจริง นั่นคือเกณฑ์ขั้นต่ำสำหรับการแปลด้วยเครื่องที่ให้เกียรติภาษาโพลีซินเทติก

---

3. กระบวนการเรียกร้องรางวัล

3.1 การส่งผลงาน

1. นักพัฒนาส่งวิธีการที่สมบูรณ์และรันได้ให้กับองค์กรกำกับดูแล:

   • ซอร์สโค้ดทั้งหมด
   • การพึ่งพาทั้งหมด (ข้อมูลการฝึกสอน พจนานุกรม การตั้งค่า FST, prompts)
   • คำแนะนำการติดตั้งและการรัน
   • README ที่อธิบายแนวทางของวิธีการ
   • run card จากชุดพัฒนาที่แสดงคะแนนโดยประมาณ (สำหรับการคัดกรองเบื้องต้น)

2. นักพัฒนาลงนามในเงื่อนไขการมีส่วนร่วม ซึ่งรวมถึง:

   • ข้อกำหนดการโอนกรรมสิทธิ์ (BENCHMARK_SPEC §8.3)
   • การประกาศว่าไม่ได้ฝึกบนข้อมูลการประเมิน
   • ข้อผูกพันด้านการทำซ้ำได้

3.2 การประเมิน

1. องค์กรกำกับดูแลติดตั้งและรันวิธีการใน harness แบบ sandbox เทียบกับคลังข้อมูล gold_standard
2. คำนวณเมตริกอัตโนมัติ (composite, FST, chrF++ ฯลฯ)
3. หากผ่านเกณฑ์อัตโนมัติ (เงื่อนไข 1–3) องค์กรกำกับดูแลจะดำเนินการตรวจสอบโดยชุมชน
4. หากไม่ผ่านเกณฑ์อัตโนมัติ นักพัฒนาจะได้รับคะแนนและข้อเสนอแนะ โดยไม่มีการตรวจสอบโดยชุมชน

3.3 การตรวจสอบโดยชุมชน

1. ตัวอย่างผลลัพธ์แบบแบ่งชั้น (≥30 รายการ ครอบคลุมระดับความยาก 2–5) ถูกนำเสนอต่อผู้พูดสองภาษา
2. ผู้ตรวจสอบอิสระอย่างน้อย 2 คนให้คะแนนแต่ละรายการ
3. สเกลการให้คะแนน: reject / gist / acceptable / excellent
4. หาก ≥70% ของรายการได้รับ "acceptable" หรือ "excellent" จากผู้ตรวจสอบทั้งสองคน การตรวจสอบโดยชุมชนผ่าน

3.4 การจ่ายเงิน

1. เงื่อนไขทั้ง 6 ข้อได้รับการปฏิบัติตาม
2. องค์กรกำกับดูแลยืนยันผล
3. รางวัลจะถูกจ่ายภายใน 30 วันหลังการยืนยัน
4. กรรมสิทธิ์วิธีการโอนตาม BENCHMARK_SPEC §8.3
5. ผลลัพธ์ถูกเผยแพร่บน leaderboard พร้อมระดับการตรวจสอบ "Community Validated"

3.5 การส่งผลงานหลายครั้ง

• นักพัฒนา/ทีมเดียวกันสามารถส่งผลงานได้หลายครั้ง
• แต่ละการส่งได้รับการประเมินอย่างอิสระ
• หากวิธีการได้รับการปรับปรุงและส่งใหม่ จะนับเฉพาะ run card ล่าสุดเท่านั้น
• รางวัลมอบให้กับ วิธีการแรก ที่ผ่านเกณฑ์ทั้งหมด — ไม่มีการแบ่ง

3.6 การส่งผลงานเป็นทีม

• ทีมและคู่ผู้อาวุโส-เยาวชนมีสิทธิ์เข้าร่วม
• การแบ่งรางวัลภายในทีมเป็นความรับผิดชอบของทีม
• สมาชิกทีมทุกคนต้องลงนามในเงื่อนไขการมีส่วนร่วม
• การระบุที่มาบน leaderboard แสดงรายชื่อสมาชิกทีมทั้งหมด

---

4. กองทุนรางวัลในอนาคต

Founder's Prize คือจุดเริ่มต้น กองทุนรางวัลเพิ่มเติมได้รับการสนับสนุนทุนจากผู้สนับสนุน กองทุนรางวัลใหม่แต่ละกองทุนถูกบันทึกเป็นหัวข้อย่อยใหม่ของ §2 พร้อมด้วย:

• จำนวนเงินรางวัลและสกุลเงิน
• คู่ภาษา
• การระบุที่มาของผู้สนับสนุน
• เงื่อนไขขั้นต่ำ (ซึ่งอาจแตกต่างจาก Founder's Prize)
• วันหมดอายุ (ถ้ามี)
• เงื่อนไขพิเศษใดๆ

4.1 เทมเพลตรางวัลสำหรับผู้สนับสนุน

ผู้สนับสนุนสามารถสนับสนุนทุนกองทุนรางวัลในจำนวนใดก็ได้ ระดับที่แนะนำ:

ระดับ	จำนวนเงิน	เกณฑ์ที่แนะนำ
Seed	$5,000–$15,000	Deployable (composite ≥ 0.70) + การตรวจสอบโดยชุมชน
Breakthrough	$25,000–$50,000	Fluent (composite ≥ 0.85) + การตรวจสอบโดยชุมชน
Grand Prize	$100,000+	Fluent + ครอบคลุมหลาย register + การผสานรวมการนำไปใช้งาน

ผู้สนับสนุนยังสามารถสนับสนุนทุน:

• รางวัลการปรับปรุง — การจ่ายเงินคงที่สำหรับการปรับปรุง chrF++ ทุก 5 คะแนนเหนือคะแนนสูงสุดปัจจุบัน
• รางวัล register — รางวัลแยกสำหรับ register เฉพาะ (ทางการ พิธีกรรม การศึกษา)
• รางวัลความเร็ว — คะแนนที่ปรับตามต้นทุนดีที่สุด (SCORING_SPEC §6.3)

4.2 การฝากเงินกองทุนรางวัล

เงินรางวัลทั้งหมดถูกเก็บไว้ในบัญชีฝากทรัพย์ (จัดการโดยโครงการหรือผู้ดูแลที่ได้รับมอบหมาย) จนกว่าเงื่อนไขขั้นต่ำจะได้รับการปฏิบัติตาม หากรางวัลหมดอายุโดยไม่มีผู้เรียกร้อง เงินจะถูกคืนให้ผู้สนับสนุนหรือนำไปใช้กับกองทุนรางวัลใหม่ตามดุลยพินิจของผู้สนับสนุน

---

5. การตัดสิทธิ์

การส่งผลงานจะถูกตัดสิทธิ์หาก:

1. ฝึกบนข้อมูลการประเมิน วิธีการถูกเปิดเผยต่อรายการคลังข้อมูล gold_standard หรือ held_out (ป้องกันในเชิงสถาปัตยกรรมโดยการรันใน sandbox — แต่หากพบหลักฐานการปนเปื้อน ผลลัพธ์จะถูกยกเลิก)
2. ทำซ้ำไม่ได้ องค์กรกำกับดูแลไม่สามารถทำซ้ำคะแนนได้ภายใน ±2%
3. การพึ่งพาที่ไม่ได้ประกาศหรือไม่มีสิทธิ์ วิธีการต้องการการเข้าถึงบริการภายนอกในขณะรันที่เกินกว่าที่ manifest การพึ่งพาประกาศไว้ หรือประเภทการพึ่งพาที่แท้จริงคือ A2 หรือ X (§1.6) LLM inference ประเภท A1 ที่ประกาศไว้ซึ่งส่งผ่าน evaluation gateway ได้รับอนุญาต การพึ่งพาเครือข่ายในขณะรันอื่นๆ — และการพึ่งพาที่ไม่ได้ประกาศในทุกประเภท — ถือเป็นเหตุตัดสิทธิ์
4. ไม่ได้ลงนามในเงื่อนไขการมีส่วนร่วม สมาชิกทีมทุกคนต้องยินยอมในการโอนกรรมสิทธิ์
5. ตรวจพบการโกง ผลลัพธ์ถูกปรับให้เหมาะสมกับเมตริกมากกว่าคุณภาพการแปล (ตรวจพบโดยการตรวจสอบชุมชนและ/หรือการตรวจสอบการโกงตาม BENCHMARK_SPEC §9.3)

---

6. ความสัมพันธ์กับข้อกำหนดอื่นๆ

เอกสารนี้	อ้างอิง	สำหรับ
เงื่อนไขขั้นต่ำ §2	SCORING_SPEC §4 (composite), §2.1–2.2 (เมตริก), §5 (ระดับ)	นิยามเมตริกและสเกล
การตรวจสอบโดยชุมชน §2	BENCHMARK_SPEC §7	โปรโตคอลการตรวจสอบโดยมนุษย์
การรันใน sandbox §3	BENCHMARK_SPEC §8.2	กลไกอธิปไตย
การโอนกรรมสิทธิ์ §3	BENCHMARK_SPEC §8.3	เงื่อนไขการโอน IP
ประเภทการพึ่งพา §1.6	ข้อกำหนด Method Interface; Method Submission Agreement §2.6; BENCHMARK_SPEC §8.6	นิยามประเภท เงื่อนไขการรับเข้า นโยบายเครือข่าย sandbox
รางวัลปรับตามต้นทุน §4	SCORING_SPEC §6.3	สูตรปรับตามต้นทุน

---

7. การซิงโครไนซ์โค้ด–ข้อกำหนด

7.1 แหล่งข้อมูลหลัก

เอกสารนี้ (arena/website/docs/specifications/prize-spec.md) เป็นแหล่งข้อมูลหลักสำหรับ:

• นิยามกองทุนรางวัล (§2)
• เงื่อนไขขั้นต่ำ (§2.x)
• กระบวนการเรียกร้อง (§3)
• กฎการตัดสิทธิ์ (§5)

7.2 ข้อกำหนดการนำไปใช้งาน

เมื่อกองทุนรางวัลถูกเปิดใช้งาน:

1. UI ของ leaderboard ต้องแสดงรางวัลที่เปิดใช้งานและเงื่อนไขขั้นต่ำ
2. run card ที่ผ่านเกณฑ์อัตโนมัติ (เงื่อนไข 1–3) ต้องถูกตั้งค่าสถานะเพื่อการตรวจสอบโดยชุมชน
3. ฟิลด์ quality_tier ใน schema ของ run card รองรับระดับแล้ว ("deployable", "fluent")
4. ไม่จำเป็นต้องเปลี่ยนแปลงโค้ดใหม่ใน harness — ข้อกำหนดรางวัลเป็นชั้นนโยบายที่อยู่บนการให้คะแนนที่มีอยู่แล้ว

---

โครงสร้างรางวัลต้องเข้ากันได้กับเงื่อนไขการโอนกรรมสิทธิ์ ผู้ชนะสามารถเรียกร้องรางวัลได้ แต่วิธีการจะกลายเป็นทรัพย์สินขององค์กรกำกับดูแลหากบรรลุระดับ Deployable นี่คือการออกแบบโดยเจตนา — เงินรางวัลสนับสนุนการสร้างเทคโนโลยีที่เป็นของชุมชนภาษา