DekEn

อ้างอิง

Sealed approval & record immutability

freeze-on-seal · write-lock

Defines who must seal each study and what each seal means, records each seal with a password re-authentication step, and — the moment the first required person seals — freezes the study content read-only and hard-locks every write endpoint (409 on further edits), so a sealed record can never be silently altered underneath its own approval. A seal is tamper-evidence, not a legal electronic signature.

เมื่อไรจึงใช้
  • A completed hazard study needs a formal, auditable approval before it governs a design.
  • You need to guarantee a sealed study genuinely cannot change afterward — not just discourage it.
ค่าที่ต้องกรอก
ค่าคำอธิบาย
Required seals & rolesWho must seal before the study is considered issued.
Content hashA SHA-256 hash stamped at sealing; downstream reviewers can verify the exact content that was sealed.
คำนวณอย่างไร

The first qualifying seal flips the study read-only study-wide; every content-write API call thereafter returns a hard 409, enforced server-side so it can't be bypassed from the UI. The sealed PDF/Word export carries a Seal Records appendix (who sealed, stated meaning, timestamp, hash-prefix) that travels with the document.

ข้อควรระวัง
noteThe write-lock is enforced at the API, not just hidden in the UI — there is no client-side path around it once a study is issued.
ที่เกี่ยวข้อง

DekEnอ้างอิงคู่มืออ้างอิง (Manual)อัปเดต 2026-09-07