อ้างอิง
Sealed approval & record immutability
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 & roles | Who must seal before the study is considered issued. |
| Content hash | A 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.
DekEnอ้างอิงคู่มืออ้างอิง (Manual)อัปเดต 2026-09-07