منبع حقیقت، محتوا، انتشار و رسانه · فصل ۵ — Vault، Transfer و Provenance Round-trip · 171
Local Artifact Vault و Durability Classes
محتوا یا media تولید می‌کند اما provenance، rights، version، approval و release boundary را یک سیستم واحد نمی‌بیند. موضوع جاری: «Local Artifact Vault و Durability Classes». می‌تواند «Local Artifact Vault و Durability Classes» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.
خلاصهٔ درس
محتوا یا media تولید می‌کند اما provenance، rights، version، approval و release boundary را یک سیستم واحد نمی‌بیند. موضوع جاری: «Local Artifact Vault و Durability Classes».
می‌تواند «Local Artifact Vault و Durability Classes» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.
خروجی این درس
می‌تواند «Local Artifact Vault و Durability Classes» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.
پیش‌نیازها
1. مسئله: وجود فایل مساوی ماندگاری نیست
فرض کنید release-final.zip روی پوشه پروژه وجود دارد، یک نسخه هم روی درایو دیگری sync شده و یک checksum قدیمی کنار آن است. اگر bytes فایل بعداً عوض شده باشند، هر دو مسیر روی همان لپ‌تاپ باشند و هیچ verify تازه‌ای انجام نشده باشد، عبارت «دو کپی داریم» هیچ تضمین قابل ممیزی درباره دوام نمی‌دهد. CON-019 این ابهام را به یک ledger صریح تبدیل می‌کند.
2. مرز مالکیت CON-019
این درس مالک Local Artifact Vault Ledger & Durability Policy v1 است: هویت دقیق محتوا، محل‌های نگهداری، کلاس دوام، retention، replica و failure domain، verification، corruption، eviction و restore. انتقال presigned متعلق به CON-020 است و بسته‌شدن handoff انسانی با provenance متعلق به CON-021؛ این دو outcome را اینجا جذب نمی‌کنیم.
3. Logical artifact را از pathname جدا کن
artifact_id نام منطقی چیزی است که workflow درباره‌اش حرف می‌زند؛ vault_path فقط محل فعلی یک کپی است. جابه‌جایی یک فایل با bytes ثابت نباید artifact تازه بسازد. برعکس، عوض‌شدن bytes زیر همان filename باید state محتوایی جدید بسازد. بنابراین تصمیم‌های Vault را روی artifact_id + digest + byte_size می‌بندیم، نه روی اسم فایل یا path.
4. الگوی content-addressable و چیزی که واقعاً ثابت می‌کند
OCI Image Layout یک الگوی استاندارد برای blobهای content-addressable ارائه می‌کند: path شامل الگوریتم و digest رمزگذاری‌شده است و محتوای blob باید با همان digest منطبق باشد. MAKNOW از این ایده فقط به‌عنوان الگوی هویت byte-level استفاده می‌کند؛ Vault این درس ادعا نمی‌کند OCI Image Layout است. Digest نیز retention، rights، approval یا موفقیت backup را ثابت نمی‌کند.
5. Durability Class یک policy است، نه ویژگی path
در این درس کلاس‌های نمونه EPHEMERAL، CACHE، WORKING، RETAINED و ARCHIVE هستند. این taxonomy طراحی MAKNOW است، نه الزام OCI یا BagIt. هر کلاس باید صریحاً بگوید چه مدت باید نگهداری شود، چند replica سالم لازم است، failure domainها چگونه باید مستقل باشند، verification هر چند وقت یک‌بار لازم است و آیا restore test اجباری است.
6. Retention را به کلاس و policy version ببند
retention_policy_id و retention_until باید کنار artifact ثبت شوند. کوتاه‌شدن retention برای مشتق‌های cache نباید به‌صورت ضمنی retention artifact اصلی RETAINED را تغییر دهد. وقتی policy عوض می‌شود، تاریخچه تصمیم قبلی را بازنویسی نکن؛ event جدید ثبت کن تا ممیز بداند در هر زمان چه قاعده‌ای حاکم بوده است.
7. Replica بدون Failure Domain مستقل کافی نیست
دو pathname روی یک دیسک، دو directory روی یک host یا mirrorی که همان failure domain را شریک است لزوماً دو replica مستقل نیستند. برای کلاس‌هایی که چند failure domain می‌خواهند، ledger باید replica_id و replica_failure_domain را جدا ثبت کند. شمارش ساده فایل‌ها می‌تواند اعتماد کاذب ایجاد کند.
8. Verification باید تازه و قابل نسبت‌دادن باشد
last_verify و verify_result نشان می‌دهند کدام replica، در چه زمان و نسبت به کدام digest بررسی شده است. checksum قدیمی بعد از تغییر bytes دیگر evidence جاری نیست. اگر verification stale یا ناشناخته است، وضعیت را UNVERIFIED یا DEFER نگه دار؛ سبزکردن خودکار state به‌خاطر وجود فایل، evidence gap را پنهان می‌کند.
9. Promotion به کلاس قوی‌تر
Promotion از WORKING به RETAINED یا ARCHIVE فقط با تغییر یک label انجام نمی‌شود. ابتدا binding دقیق artifact، retention policy، تعداد replica سالم، استقلال failure domain، verification جاری و در صورت نیاز restore evidence را بررسی کن. Promotion event باید timestamp، policy version و reason داشته باشد تا بعداً قابل audit باشد.
10. Corruption تاریخچه را پاک نمی‌کند
اگر یکی از replicaها corrupt شد، آن replica باید state صریح CORRUPT بگیرد و دیگر برای obligation دوام شمرده نشود. اما provenance تاریخی artifact، مسیرهای قبلی و verificationهای گذشته پاک نمی‌شوند. فساد storage یک event جدید است، نه مجوز بازنویسی گذشته.
11. Eviction یک تصمیم policy-aware است
یک فایل cache ممکن است از نظر retention منقضی شده باشد اما هنوز downstream reference فعال داشته باشد. در این حالت eviction باید BLOCK شود تا reference/policy حل شود. برای artifactهای retained نیز «کمبود فضا» به‌تنهایی دلیل حذف نیست؛ eligibility باید از policy و dependencies بیاید و event حذف باید قابل ممیزی بماند.
12. Restore Test برای کلاس‌های آرشیوی
وجود backup بدون restore evidence می‌تواند false confidence ایجاد کند. اگر کلاس ARCHIVE، restore test می‌خواهد، نتیجه PASS باید به نسخه artifact، replica و زمان آزمون بسته شود. نتیجه FAIL یا UNKNOWN باید promotion/اعتماد را محدود کند تا repair انجام شود؛ report سبز بدون restore واقعی کافی نیست.
13. BagIt چه چیزی را پوشش می‌دهد
RFC 8493 برای BagIt، payload manifest را فهرست کامل مسیرهای payload همراه checksum تعریف می‌کند و valid bag را complete bagی می‌داند که checksumهای manifest آن با محتوا با موفقیت verify شده‌اند. این الگو برای package completeness/integrity مفید است؛ اما durability class، topology نسخه‌های پشتیبان، rights یا approval پروژه را تعیین نمی‌کند.
14. Lab: ساخت Vault Ledger از fixture قطعی
در lab://CON-019/CON019-LAB1 هشت fixture مصنوعی داریم: baseline سالم، تغییر bytes زیر همان filename، دو کپی در یک failure domain، corruption یک replica، جابه‌جایی path بدون تغییر محتوا، eviction با downstream reference، restore ناموفق و سناریوی transfer. باید هشت state خروجی را فقط از شواهد fixture بسازید؛ پاسخ مرجع در سطح learner قرار نگرفته است.
15. Transfer و چک‌لیست تصمیم
در سناریوی انتقال، artifact_id همان می‌ماند، یک replica corrupt می‌شود، کپی سالم به path جدید می‌رود و retention مشتق‌های cache کوتاه می‌شود. اگر class اصلی هنوز دو failure domain سالم می‌خواهد، path جدید یا policy cache نمی‌تواند کمبود replica را جبران کند. تصمیم نهایی باید دقیقاً بگوید چه چیزی ثابت شده، چه چیزی نشده، چه repairی لازم است و چه triggerی باعث recheck می‌شود.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
CON-019-AS1 application
CON-019-AS2 diagnosis
CON-019-AS3 decision
CON-019-AS4 transfer
CON-019-AS5 reflection
ملاک‌های ارزیابی (rubric)
- Identity and scope: logical artifact identity is separated from path and adjacent CON-020/021 outcomes remain out of scope.
- Exact evidence binding: digest, byte size, replica, failure domain, policy version and verification state are traceable.
- Negative/unknown states: corruption, stale verification, insufficient replica state and blocked eviction remain typed.
- Bounded decision: the decision is no stronger than current evidence and names a recheck/repair trigger.
- Transfer: changed context is recomputed; the prior decision is not copied.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
Use the eight local JSON fixtures to derive eight output fields for each case:
artifact_binding_state, identity_state, replica_state, durability_state, retention_state, eviction_state, restore_state, decision.
Keep path movement separate from content identity, reject corrupt replicas from durability counts, and preserve blocked/deferred states. Do not use network services or real project data.