สถานะสดที่เคารพความลับของงานวิจัย

สถานะสดที่ดีควรตอบเรื่องการประสานงาน โดยไม่ขอเนื้อหาที่ไม่จำเป็น

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

แนวทางของ ResearchOS คือส่งสัญญาณที่ไม่มีเนื้อหางานวิจัยผ่าน Project Room เช่น รหัสโครงการที่ใช้ตรวจสิทธิ์ ประเภทเหตุการณ์ เวลาที่เกิด และสถานะการเชื่อมต่อ ไม่ส่งหัวข้อวิจัย เนื้อหาบท ข้อค้นพบ prompt หรือข้อความจากไฟล์ผ่านช่องทางนี้ เมื่อผู้ใช้ต้องการเปิดรายละเอียด หน้าจอจึงเรียกข้อมูลจากบริการหลักของโครงการภายใต้สิทธิ์ของบัญชีนั้นอีกครั้ง หลักลดข้อมูลเช่นนี้ทำให้ช่องทางสถานะสดมีประโยชน์โดยไม่กลายเป็นคลังเงาของงานวิจัย

• ส่งเฉพาะสัญญาณที่จำเป็นต่อการประสานงาน
• ไม่ใส่หัวข้อ เอกสาร ข้อค้นพบ หรือ prompt ลงในข้อความสถานะสด
• เปิดรายละเอียดจากบันทึกหลักหลังตรวจสิทธิ์ใหม่

Presence บอกว่าใครอยู่ ไม่ได้รับรองว่าเนื้อหาบนหน้าจอเป็นฉบับล่าสุด

สถานะ online หรือ presence มีอายุสั้นและอาจหายเมื่อเครือข่ายมือถือสลับเสา เบราว์เซอร์พักแท็บ หรือเครื่องเข้าสู่โหมดประหยัดพลังงาน จึงไม่ควรใช้สัญญาณนี้ตัดสินว่าใครกำลังแก้เอกสารฉบับใด หรือใช้เป็นหลักฐานการอนุมัติ สมาชิกที่แสดงว่าออฟไลน์อาจกำลังทำงานในไฟล์ส่วนตัว และสมาชิกที่ออนไลน์อาจเพียงเปิดหน้าจอไว้ ระบบควรใช้ presence เพื่อช่วยประสานจังหวะเท่านั้น

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

บันทึกหลักของโครงการเป็นแหล่งยืนยัน ส่วนช่องทางสดเป็นเพียงตัวแจ้งเตือน

ข้อมูลสำคัญ เช่น กติกาทีม หมุดหมาย dependency คำขอตรวจ ความเห็น และคำตัดสิน ต้องถูกบันทึกผ่านเส้นทางหลักที่ตรวจรูปแบบข้อมูล สิทธิ์ และความซ้ำของคำขอ ระบบฐานข้อมูลโครงการที่ใช้เป็นหลักหรือ D1 จึงเป็นแหล่งยืนยันสถานะ ส่วนช่องทาง WebSocket ของ Project Room มีหน้าที่แจ้งสมาชิกที่เชื่อมต่ออยู่ว่าควรรีเฟรชข้อมูลใด การแยกสองหน้าที่ทำให้ความเร็วไม่ต้องแลกกับความถูกต้อง

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

• การบันทึกสำคัญต้องสำเร็จในบริการหลักก่อนส่งสัญญาณสด
• คำขอซ้ำต้องไม่สร้างผลลัพธ์หรือหักเครดิตซ้ำ
• ช่องทางสดล้มเหลวไม่ควรย้อนสถานะที่บันทึกสำเร็จแล้ว

การเชื่อมต่อใหม่ต้องกลับไปอ่านความจริง ไม่เล่นเหตุการณ์เก่าต่อแบบเดา

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

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

การแยกโครงการและตรวจบทบาทต้องเกิดฝั่งบริการ ไม่ใช่พึ่งเมนูที่ซ่อน

การซ่อนปุ่มจากผู้ใช้ที่ไม่มีสิทธิ์ช่วยลดความสับสน แต่ไม่ใช่มาตรการความปลอดภัยเพียงพอ ทุกการอ่าน การบันทึก และการเชื่อมต่อห้องสดต้องตรวจว่า session นั้นยังเป็นสมาชิกของโครงการและมีบทบาทที่อนุญาต การใช้เพียง project id ที่มาจากเบราว์เซอร์โดยไม่ตรวจสมาชิกอาจเปิดทางให้เปลี่ยนค่าแล้วเข้าถึงเหตุการณ์ของอีกโครงการได้ ระบบจึงต้องผูกห้องกับโครงการและสิทธิ์ที่ยืนยันฝั่งบริการ

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

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

ความลับของงานวิจัยครอบคลุมมากกว่าชื่อไฟล์

หัวข้อที่ยังไม่เผยแพร่ คำถามวิจัย รายชื่อพื้นที่ศึกษา ข้อค้นพบเบื้องต้น ความเห็นผู้ทรงคุณวุฒิ และ metadata บางชนิดอาจเปิดเผยทิศทางของโครงการได้ แม้ไม่มีข้อมูลผู้เข้าร่วมวิจัย ระบบจึงไม่ควรส่งข้อความเหล่านี้ผ่าน presence หรือบันทึกไว้ใน log เพื่อความสะดวกของผู้พัฒนาโดยอัตโนมัติ เหตุการณ์ปฏิบัติการควรใช้รหัสและประเภทที่เพียงพอต่อการตรวจสุขภาพระบบ แต่ไม่ทำให้ผู้ดูแลเห็นเนื้อหาวิจัย

ResearchOS ระบุในขั้นสมัครและพื้นที่ทำงานว่า จะไม่นำหัวข้อ เอกสาร หรือข้อมูลที่ผู้ใช้นำเข้าไปสร้างชุดข้อมูลสำหรับฝึกโมเดล AI ข้อความนี้ไม่ได้หมายความว่าไม่มีการประมวลผลภายนอกเลย งาน AI ที่ผู้ใช้ยืนยันอาจถูกส่งไปยังผู้ให้บริการตามขอบเขตที่ประกาศไว้ จึงต้องอ่านนโยบายความเป็นส่วนตัวและขอบเขตการประมวลผลร่วมกัน ระบบควรส่งเฉพาะข้อมูลที่จำเป็นต่อคำสั่งนั้น ไม่ใช้ Project Room เป็นทางลัดส่งเนื้อหา และไม่ขอรหัสผ่านหรือ API key ของบริการภายนอกมาเก็บถาวร

แนวปฏิบัติสำหรับทีมที่ทำงานกับข้อมูลอ่อนไหว

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

ระหว่างใช้งาน สมาชิกควรอ่านสัญญาณสดเป็นตัวช่วย ไม่ใช้เป็นหลักฐานสุดท้าย หากหน้าจอไม่อัปเดต ให้เปิดกิจกรรมล่าสุดหรือรีเฟรชจากบันทึกหลักก่อนกดทำรายการซ้ำ เมื่อเกิดข้อผิดพลาด ระบบควรแจ้งว่าการบันทึกสำเร็จหรือไม่ พร้อมคำแนะนำที่ปลอดภัย ทีมไม่ควรแก้ปัญหาด้วยการส่งเนื้อหาลับผ่านช่องทางที่ไม่ได้รับอนุมัติ เพียงเพราะสถานะสดหยุดชั่วคราว

• เชิญด้วยอีเมลที่ตรวจแล้วและให้สิทธิ์เท่าที่จำเป็น
• ไม่เก็บข้อมูลผู้เข้าร่วมวิจัยในพื้นที่ประสานงานทีม
• ตรวจบันทึกหลักก่อนทำรายการซ้ำเมื่อการเชื่อมต่อไม่แน่นอน

ขอบเขตที่ ResearchOS รับรองและสิ่งที่ทีมยังต้องรับผิดชอบ

ResearchOS ออกแบบ Project Room ให้เป็นช่องทางสัญญาณที่ไม่บรรจุเนื้อหา และให้บันทึกหลักของโครงการมีอำนาจเหนือสถานะสด แต่การรักษาความลับยังต้องอาศัยการตั้งค่าสิทธิ์ อุปกรณ์ เครือข่าย และแนวปฏิบัติของทีม ระบบไม่ได้แทนคณะกรรมการจริยธรรม นโยบายหน่วยงาน แผนจัดการข้อมูล หรือการประเมินว่าข้อมูลประเภทใดอนุญาตให้นำขึ้นบริการภายนอกได้

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