Systems

Overview

กรอบ axiom สำหรับการสร้างระบบซอฟต์แวร์ — สิ่งที่จริงไม่ว่าจะสร้าง product ตัวไหน ตั้งต้นจากความจริงพื้นฐานข้อเดียว: ความแตกต่างมีอยู่จริง ปฏิเสธไม่ได้ เพราะแม้แต่การปฏิเสธก็ต้องต่างจากความจริงที่ถูกปฏิเสธ

ชุดนี้ derive ระหว่างสร้าง nectarserve — ซอฟต์แวร์ตัวแรกของสตูดิโอ — แต่ตัว axiom เองไม่ผูกกับ nectarserve มันใช้กับทุกระบบที่ต้อง ตัดสินใจแล้วลงมือกับโลกจริง ส่วนที่เป็นของ nectarserve โดยเฉพาะอยู่ที่ Continuum ซึ่ง derive ลงมาจากชุดนี้

ขอบเขต: AX1–AX5 · T1–T9 · C6–C11 — axiom ที่พกพาได้กับทุกระบบที่ตัดสินใจแล้วลงมือกับโลกจริง

Axioms

ปฏิเสธไม่ได้ หรือ derive ได้โดยไม่มีขั้นที่ข้าม

AX1 · ทุก representation สูญเสียข้อมูลบางส่วนเสมอ

การบันทึกสิ่งใดลงในรูปแบบใด ย่อมเสียข้อมูลในมิติที่ไม่ได้บันทึก — คานเสียรูปเมื่อรับน้ำหนัก นั่นคือธรรมชาติ ไม่ใช่ความบกพร่อง · representation ที่ดีไม่ใช่อันที่สมบูรณ์ แต่คืออันที่ loss เล็กกว่า threshold ของ decision ที่ต้องทำ

เกณฑ์ — “ผิดแล้ว decision เปลี่ยนไหม?” · ไม่เปลี่ยน = พอแล้ว · เปลี่ยน = ต้องปรับ รองรับ — T1 · T3 · T4 · C11

AX2 · ณ เวลาหนึ่ง ทรัพยากรมีจำกัด

ไม่ว่า moment ใดของการตัดสินใจ ทรัพยากรที่ใช้ได้จริง ณ ขณะนั้นไม่มี infinity

รองรับ — T1 · T5 · C10

AX3 · โลกภายนอกเปลี่ยนได้โดยไม่ขึ้นกับระบบ

“ส่งงานสำเร็จ” ≠ “ผลสำเร็จ” — พนักงานวางพัสดุหน้าบ้าน ถ่ายรูป กลับไป = ส่งแล้ว · แต่ถ้าลมพัดพัสดุหาย ผู้รับยังไม่กลับบ้าน = ไม่รู้ผล · state ที่ถูกคือ pending ไม่ใช่ delivered

รองรับ — T7 · T8 · C6

AX4 · ความหมายเชิงปฏิบัติของ message ขึ้นกับ context ที่สะสมมาก่อน

“โอนเงินไปแล้วครับ” — รู้ว่าเป็นการแจ้งโอนเงิน (semantic) แต่ไม่รู้โอนให้ใคร เพื่ออะไร (pragmatic) → ระบบที่ต้อง act on ทำอะไรไม่ได้ · หน่วยที่ระบบ act on ได้คือ thread ไม่ใช่ message เดี่ยว

รองรับ — T11 · T14 · C8 (ที่ Continuum)

AX5 · ข้อมูลไม่พอ แก้ปัญหาไม่ได้ — ไม่ว่า resolver จะแรงแค่ไหน

clarity ≥ threshold → แก้ได้ · clarity < threshold → ต้องถามหรือ drop ไม่ใช่เดา · threshold ไม่ใช่ตัวเลขสากล ขึ้นกับ decision: “ไม่รู้ field นี้ → resolver ตัดสินใจผิดในแบบที่รับไม่ได้ไหม?”

รองรับ — T9 · C7 · C11

Theorems

T1 · ต้นทุนเกิดที่การทำ ไม่ใช่ที่การมีอยู่

จาก AX1 + AX2

∴ lazy execution คือ default ที่ถูก ไม่ใช่ optimization — งานที่ยังไม่ทำยังไม่กินต้นทุน จนกว่าจะถึงเวลาที่ commit cost คุ้มกว่า idle cost

T3 · งานต่างชนิดมีขอบเขตที่ทำได้ต่างกัน

จาก AX1

เลือก resolver ผิด = ทำงานนอกขอบเขต = fail หรือจ่ายต้นทุนสูงโดยไม่จำเป็น — งานภาษาให้ LLM · งานตัวเลขให้ code

T4 · คุณค่าที่วัดได้เกิดจาก action ที่เกิดขึ้นแล้ว

จาก AX1

“ระบบที่ทำได้ 10 อย่างแต่ยังไม่ได้ทำ” มีคุณค่าน้อยกว่า “ระบบที่ทำได้ 1 อย่างและทำไปแล้ว”

T5 · ระบบที่ดีรู้ขอบเขตของตัวเอง และเข้าใกล้ได้อย่างตั้งใจ

จาก T1 + T3 + AX2

จุด optimal มักอยู่ที่ขอบของ feasible region พอดี · ∴ ขอบเขตคือสิ่งที่ต้องรู้จักและเข้าถึงได้แม่นยำ ไม่ใช่สิ่งที่ต้องหลีกเลี่ยง

T7 · External action มีสอง completion ที่ต่างกัน

จาก AX3

action_complete ≠ outcome_complete · “ส่งแล้ว” ≠ “ได้รับแล้ว” — สอง state นี้แยกจากกันเสมอ

รองรับ — T8 · C6

T8 · Blast radius กำหนด authority ที่ต้องการ

จาก AX3 + T7

internal (ผิดแล้วแก้เองได้) → authority ต่ำ · external (ผิดแล้วกระทบคนอื่น) → authority สูง · external + irreversible (ย้อนกลับไม่ได้) → ต้องให้คนยืนยันก่อน

รองรับ — C6

T9 · Clarity ต่ำกว่า threshold → ไม่ควร execute

จาก AX5

clarity check มาก่อน constraint check เสมอ — ไม่มีประโยชน์ที่จะเช็คว่า “ทำได้ไหม” ถ้ายังไม่รู้ว่า “จะทำอะไร”

รองรับ — C7

Corollaries

C6 · Internal fail fast, external fail never

จาก T8 + AX3

internal: ผิดแล้วแก้ได้ → fail fast = learn fast · external: ผิดแล้วกระทบคนอื่น → ต้องไม่ผิดตั้งแต่แรก

C7 · เพิ่ม clarity ก่อน execute ดีกว่า execute แล้ว retry

จาก AX5 + T9

retry มีต้นทุนสองชั้น: ครั้งแรก + ครั้งใหม่ · external + irreversible อาจ retry ไม่ได้เลย · “ถามก่อน” ไม่ใช่ความล่าช้า — มันคือการ optimize ที่ถูกต้อง

C10 · เงียบคือ default, สื่อสารคือ exception

จาก AX2

ทุก message ที่ส่งออกมีต้นทุน — ทั้ง resource และ attention ของผู้รับ · ไม่มีอะไรต้องบอก → ไม่บอก

C11 · Sufficient fidelity ไม่ใช่ perfect fidelity

จาก AX1 + AX5

คานที่ดีไม่ใช่คานที่ไม่เสียรูป แต่คือคานที่เสียรูปน้อยกว่าที่โครงสร้างจะพัง · เป้าหมายของ representation คือ gap เล็กกว่า threshold ของ decision ไม่ใช่ความสมบูรณ์