Immutable Approval و Revocable Validity

هدف: approval تاریخی را immutable نگه داریم و اعتبار فعلی را در زمان تصمیم از subject/policy/time/status دوباره محاسبه کنیم.

1. مسئله واقعی: approval تاریخی با اعتبار فعلی یکی نیست

فرض کنید رویداد APR-42 ثبت کرده است که بازبین R7 در زمان T0، دقیقاً sha256:A را تحت policy نسخه PUB-3 برای انتشار وب تأیید کرده است. این رویداد باید به‌عنوان یک واقعیت تاریخی تغییرناپذیر بماند. اما چند روز بعد ممکن است policy جدیدی فعال شود، approval تعلیق یا revoke شود، بازهٔ اعتبار تمام شود، یا محتوای مورد درخواست دیگر همان digest قبلی نباشد. بنابراین سؤال درست این نیست که «آیا جایی approved=true داریم؟»؛ سؤال درست این است که «آیا این approval تاریخی، برای subject، scope، policy و timestamp همین تصمیم هنوز قابل اتکاست؟»

2. دو لایه را جدا کن: Approval Event و Current Validity

لایه اول، Approval Event است: چه کسی، چه subject دقیقی، تحت کدام policy و scope، در چه زمانی و با چه evidenceای را تأیید کرد. این رکورد append-only است. لایه دوم، Current Validity است: نتیجه‌ای مشتق‌شده در زمان تصمیم که status eventها، expiry، supersession، subject applicability و policy مؤثر را دوباره بررسی می‌کند. اعتبار فعلی یک property دائمیِ event نیست؛ یک محاسبهٔ زمان‌مند است.

3. Schema حداقلی Approval Event

برای هر approval حداقل این فیلدها را ثبت کن: approval_event_id، approved_subject_ref، subject_digest، reviewer_id، reviewer_role، policy_id، policy_version، approval_scope، approval_timestamp، approval_evidence_ref و در صورت وجود signature/evidence binding. اگر subject یا policy دقیق bind نشده باشد، downstream نباید آن را به‌عنوان مجوز عمومی تفسیر کند.

4. Status Eventها را append کن، history را rewrite نکن

Revocation، suspension، supersession یا status change نباید APR-42 را پاک یا ویرایش کند. یک status_event_id جدید با status_purpose، effective_at، reason و provenance اضافه کن. این الگو اجازه می‌دهد بعداً بفهمیم «در T0 چه چیزی تأیید شد» و «در T3 چه چیزی باعث شد دیگر قابل اتکا نباشد». بازنویسی event تاریخی forensic reconstruction را خراب می‌کند.

5. Subject binding: approval برای exact subject است

اگر approval برای sha256:A صادر شده ولی release gate با sha256:B آمده است، نتیجه SUBJECT_MISMATCH است—even اگر filename، URL، Content ID یا approval ID همان قبلی باشد. subject applicability باید قبل از statusهای دیگر بررسی شود، چون یک approval معتبر برای شیء A هیچ چیز درباره شیء B ثابت نمی‌کند.

6. Policy binding و supersession

Approval باید به policy ID/version مشخص bind شود. اگر policy مؤثر اکنون PUB-4 است ولی approval فقط PUB-3 را پوشش می‌دهد، سیستم باید رابطهٔ compatibility یا supersession را صریح بررسی کند. در fixture این درس، تغییر policy بدون evidence سازگاری نتیجه POLICY_SUPERSEDED می‌دهد. event قدیمی باقی می‌ماند؛ فقط قابلیت اتکا برای تصمیم جدید تغییر می‌کند.

7. Scope و reviewer context را مستقل نگه دار

reviewer_role و approval_scope بخشی از معنای event هستند. تأیید برای «public web / image A / campaign X» نباید خودکار به «paid ads / derivative B / campaign Y» گسترش یابد. اگر درخواست خارج از scope باشد، باید state محدود یا نیازمند re-approval تولید شود، نه اینکه صرفاً به وجود signature تکیه شود.

8. Validity window: valid_from و valid_until

یک approval می‌تواند بدون revocation هم منقضی شود. اگر decision_time بعد از valid_until باشد، نتیجه EXPIRED است. این نکته عمداً با cryptographic integrity جداست: ممکن است signature روی event هنوز کاملاً verify شود، اما approval دیگر از نظر زمان قابل اتکا نباشد.

9. Revocation و Suspension یک چیز نیستند

REVOKED یعنی وضعیت فعلی اجازهٔ اتکا نمی‌دهد و در مدل fixture، بازگشت خودکار ندارد. SUSPENDED یعنی اتکا موقتاً متوقف است و ممکن است با status event بعدی تغییر کند. هر دو باید از event تاریخی جدا ثبت شوند. این تمایز از ایدهٔ status در استانداردهای VC الهام می‌گیرد، اما semantics دقیق approval در این درس یک rule طراحی MAKNOW است.

10. ترتیب تصمیم‌گیری fail-closed

برای یک request: 1) subject را bind کن؛ 2) policy مؤثر را بررسی کن؛ 3) window زمانی را بسنج؛ 4) status eventهای مؤثر تا decision_time را مرتب کن؛ 5) scope/reviewer constraints را اعمال کن؛ 6) CURRENT_VALIDITY و validity_reason را تولید کن. اگر evidence لازم UNKNOWN یا stale است، موفقیت نساز. release gate باید فقط state مشتق‌شدهٔ فعلی را مصرف کند.

11. Cached approved=true چرا خطرناک است؟

Cache کردن approved=true بدون status epoch یا recheck trigger باعث می‌شود revocation یا policy change دیده نشود. هر downstream cache باید حداقل به approval ID، subject digest، policy version، effective status epoch و زمان تصمیم bind باشد؛ در غیر این صورت stale است. ساده‌ترین راه امن این درس این است که release gate اعتبار را در زمان تصمیم دوباره محاسبه کند.

12. رابطه با Release Gate

این درس release manifest نمی‌سازد؛ فقط یک Approval Event & Current Validity Ledger v1 تحویل می‌دهد. CON-005 می‌تواند approval_validity_ref را از این ledger مصرف کند. بنابراین خروجی این درس باید typed باشد: VALID یا یکی از stateهای دقیق مثل SUBJECT_MISMATCH، POLICY_SUPERSEDED، SUSPENDED، REVOKED یا EXPIRED همراه با reason و recheck trigger.

13. Audit trail و provenance

برای هر تصمیم، eventهای مؤثر، ترتیب زمانی، decision timestamp، subject digest، effective policy و reason را نگه دار. audit record باید بتواند بدون reasoning پنهان توضیح دهد چرا در T1 state VALID بود ولی در T4 REVOKED شد. تاریخچهٔ append-only به این معنی نیست که همهٔ eventها همیشه مجوز فعلی‌اند؛ فقط یعنی شواهد تاریخی حذف نمی‌شوند.

14. Transfer: یک بعد را عوض کن و دوباره محاسبه کن

تمرین انتقال را با APR-42 ثابت انجام بده. ابتدا فقط subject را از sha256:A به sha256:B تغییر بده و SUBJECT_MISMATCH بگیر. سپس subject را برگردان و policy را از PUB-3 به PUB-4 تغییر بده و POLICY_SUPERSEDED بگیر. سپس policy را برگردان و یک revocation مؤثر اضافه کن و REVOKED بگیر. در هیچ مرحله‌ای APR-42 را rewrite یا delete نکن.

15. چک‌لیست خروجی و non-claimها

خروجی نهایی باید event immutable، status chronology، subject/policy/scope bindings، validity window، CURRENT_VALIDITY، validity_reason و recheck_trigger داشته باشد. این درس source authority را تعیین نمی‌کند، confidence claim را نمی‌سنجد، rights/embargo را تصمیم نمی‌گیرد و release asset set را نمی‌سازد. همچنین یک approval امضاشده یا cryptographically valid به‌تنهایی ثابت نمی‌کند که approval در context فعلی معتبر است.