منبع حقیقت، محتوا، انتشار و رسانه · فصل ۵ — Vault، Transfer و Provenance Round-trip · 173
Manual Handoff با Provenance Round-trip
محتوا یا media تولید می‌کند اما provenance، rights، version، approval و release boundary را یک سیستم واحد نمی‌بیند. موضوع جاری: «Manual Handoff با Provenance Round-trip». می‌تواند «Manual Handoff با Provenance Round-trip» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.
خلاصهٔ درس
محتوا یا media تولید می‌کند اما provenance، rights، version، approval و release boundary را یک سیستم واحد نمی‌بیند. موضوع جاری: «Manual Handoff با Provenance Round-trip».
می‌تواند «Manual Handoff با Provenance Round-trip» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.
خروجی این درس
می‌تواند «Manual Handoff با Provenance Round-trip» را در یک pipeline محدود با provenance، rights/version و publication gate تعریف کند.
1. مسئله: «فرستادیم برای ادیت» provenance نیست
فرض کنید یک بسته‌ی رسانه‌ای با digest مشخص برای ادیتور ارسال شده و سه روز بعد فایلی به نام final-v2.zip برمی‌گردد. اگر فقط نام فایل، پیام «انجام شد» و اسم ادیتور را داشته باشیم، هنوز نمی‌دانیم خروجی دقیقاً از کدام bytes مشتق شده، چه تغییراتی بیرون pipeline انجام شده، آیا manifest برگشتی معتبر است و چه کسی پذیرش نهایی را انجام داده است. CON-021 این شکاف را به یک round-trip قابل ممیزی تبدیل می‌کند.
2. مرز مالکیت CON-021
این درس مالک handoff دستی، lineage برگشت و تصمیم bounded برای پذیرش و خروج V06 است. نگه‌داری durable در vault متعلق به CON-019 است و semantics مربوط به presigned transfer متعلق به CON-020. اینجا URL امضا نمی‌سازیم و retention policy را بازتعریف نمی‌کنیم؛ فقط ثابت می‌کنیم چه artifactی خارج شد، به چه Agentی تحویل شد، چه artifactی برگشت و چه چیزهایی هنوز UNKNOWN یا unresolved هستند.
3. Outbound entity را قبل از خروج قفل کنید
برای خروجی اولیه حداقل outbound_artifact_id، outbound_digest، outbound_manifest_id و در صورت وجود outbound_package_digest را ثبت کنید. نام فایل به‌تنهایی کافی نیست. اگر فردا همان فایل rename شود، digest می‌تواند identity محتوایی را نگه دارد؛ اگر bytes عوض شوند، باید entity برگشتی جدا ثبت شود.
4. PROV-O چه چیزی به ما می‌دهد
W3C PROV-O مفاهیم Entity، Activity و Agent و روابطی مثل prov:used، prov:wasGeneratedBy، prov:wasDerivedFrom، prov:wasAssociatedWith و prov:wasAttributedTo را برای بیان provenance فراهم می‌کند. در handoff می‌توان outbound package را Entity، ارسال/ادیت را Activity و sender/editor را Agent مدل کرد. این واژگان مسئولیت و lineage را قابل بیان می‌کنند؛ اما صحت گفته‌ی انسان را تضمین نمی‌کنند.
5. Handoff event باید Agent و Receipt داشته باشد
یک handoff قابل ممیزی باید handoff_id، sender، recipient، timestamp، declared scope و transfer_receipt_id داشته باشد. اگر recipient نامشخص است یا Receipt وجود ندارد، سیستم نباید از روی یک پیام چت حدس بزند چه کسی custody را پذیرفته است. وضعیت درست می‌تواند DEFER باشد تا evidence تکمیل شود.
6. External work را به Activity مستقل تبدیل کنید
ادیت دستی، تبدیل فرمت، compositing یا جایگزینی asset باید یک Activity قابل اشاره باشد. اگر ابزار یا process خارجی معلوم است، در external_tool_or_process_note ثبت کنید. اگر معلوم نیست، UNKNOWN را نگه دارید. هدف این نیست که همه چیز را بیش‌ازحد ثبت کنیم؛ هدف این است که مرز کار خارج از pipeline در audit قابل تشخیص باشد.
7. Change note بخشی از evidence انسانی است
change_note باید مشخص کند چه کارهایی ادعا می‌شود انجام شده‌اند. checksum نمی‌تواند این یادداشت را جایگزین کند. یک Bag می‌تواند از نظر integrity کاملاً معتبر باشد اما هنوز معلوم نباشد چه تغییراتی انجام شده یا آیا asset جدیدی وارد شده است. اگر change note برای policy این handoff الزامی است و وجود ندارد، package validity به‌تنهایی round-trip را نمی‌بندد.
8. BagIt چه چیزی را ثابت می‌کند
RFC 8493 می‌گوید یک Bag معتبر باید کامل باشد و checksumهای manifestها با فایل‌های متناظر verify شوند. پس BagIt ابزار خوبی برای اثبات completeness و integrity بسته‌ی outbound/return است. اما valid Bag نه authorship را ثابت می‌کند، نه rights را، نه approval را و نه این‌که ادیتور واقعاً کار ادعاشده را انجام داده است.
9. Returned entity همیشه رکورد خودش را دارد
حتی اگر final-v2.zip از نظر bytes با outbound package یکسان باشد، returned_artifact_id و receipt event جدا ثبت کنید. ممکن است digest یکی باشد ولی custody history متفاوت باشد. اگر bytes تغییر کرده‌اند، returned_digest و returned_manifest_id باید به entity جدید متصل شوند و integrity آن independently verify شود.
10. Derivation را صریح و محدود ثبت کنید
اگر evidence داریم، returned entity می‌تواند was_derived_from outbound entity باشد و Activity ادیت used outbound را نشان دهد. این relation را از روی نام فایل یا گفته‌ی مبهم حدس نزنید. وقتی chain ناقص است، unresolved_provenance=true یا یک gap typed ثبت کنید؛ نبود relation بهتر از lineage ساختگی است.
11. Asset جدید یعنی lineage چندمنبعی
ممکن است ادیتور یک source asset جدید را مستقل از bundle اولیه وارد کند. در این حالت برگشت دیگر «فقط مشتق از outbound» نیست. ingredient جدید را به‌عنوان Entity مستقل با provenance خودش ثبت کنید. اگر source آن قابل trace نیست، gap را افشا کنید و تصمیم را RESTRICT یا DEFER نگه دارید؛ valid checksum این شکاف را پاک نمی‌کند.
12. Provenance کامل با Acceptance یکی نیست
حتی اگر outbound و return و derivation کامل باشند، human reviewer می‌تواند نتیجه را رد کند. acceptance_state یک تصمیم جداست. بنابراین pipeline باید بتواند «provenance verified + reviewer rejected» را بدون تناقض نگه دارد و V06 exit را BLOCK کند. provenance می‌گوید از کجا آمده؛ approval می‌گوید آیا اجازه ادامه دارد.
13. Stateهای منفی را تبدیل به success نکنید
UNVERIFIED, DEFER, RESTRICT و BLOCK stateهای واقعی هستند. missing receipt، manifest mismatch، outbound ambiguity، change note غایب، source جدید untraced یا reviewer rejection هرکدام دلیل متفاوت دارند. یک status کلی سبز نباید این تفاوت‌ها را پنهان کند.
14. Lab: Manual Handoff Round-trip Dossier & V06 Exit Record v1
در lab://CON-021/CON021-LAB1 هشت Fixture مصنوعی دارید: baseline صحیح، rename با bytes یکسان، valid package بدون change note، checksum failure، outbound مبهم، receipt/recipient ناقص، source جدید untraced و reviewer rejection. برای هر case هشت state/decision را استخراج کنید. هدف این است که integrity، provenance و acceptance را از هم جدا نگه دارید.
15. Transfer: source جدید را افشا کنید و ادعای lineage را محدود نگه دارید
در سناریوی انتقال، package برگشتی checksum-valid است و change note کامل دارد، اما یک source asset خارج از outbound bundle جایگزین شده و provenance آن قابل trace نیست. آن asset را entity مستقل اعلام کنید، was_derived_from را فقط برای بخش‌های پشتیبانی‌شده ثبت کنید، gap را باز نگه دارید و V06 exit را تا تکمیل evidence محدود کنید. هیچ filename یا checksum نباید این عدم قطعیت را به PASS تبدیل کند.
منابع رسمی و مرز ادعا
- W3C PROV-O Recommendation:
https://www.w3.org/TR/prov-o/ - RFC 8493 — The BagIt File Packaging Format (V1.0):
https://www.rfc-editor.org/rfc/rfc8493.html
K1 و K2 واقعیت‌های منبعی‌اند که در 2026-09-17 دوباره بررسی شدند. K3 (مدل round-trip digest-bound) و K4 (مسدودماندن V06 هنگام gap یا evidence ناکافی) قواعد طراحی MAKNOW هستند و به‌عنوان الزام W3C یا BagIt معرفی نمی‌شوند.
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
CON-021-Q1 boundary
Why can a valid returned Bag still be insufficient to close a manual handoff round-trip?
CON-021-Q2 application
A returned package is byte-identical but has a new filename. Which identity and custody facts stay the same, and which event must be new?
CON-021-Q3 diagnosis
The returned Bag validates but the required change note is missing. What state should the round-trip preserve and why?
CON-021-Q4 conflict
An editor discloses a new source asset that was not in the outbound manifest and cannot be traced. How should the derivation and acceptance record change?
CON-021-Q5 transfer
Build the bounded V06 exit decision for a checksum-valid return with complete change notes, one untraced external source, and an otherwise intact handoff record.
ملاک‌های ارزیابی (rubric)
A sufficient artifact:
- binds the exact outbound artifact/package to digest and manifest evidence;
- records sender, recipient, handoff activity, timestamp and transfer receipt without inventing missing human evidence;
- verifies returned package integrity separately from change-note, provenance and approval evidence;
- models returned bytes as a distinct entity/event even when content digest is identical;
- preserves missing change notes, invalid manifests, ambiguous outbound identity and missing receipts as typed non-success states;
- discloses external/new source ingredients rather than claiming the return derives only from the outbound bundle;
- separates provenance completeness from human acceptance/rejection;
- states what PROV-O/BagIt support and what remains MAKNOW design;
- issues a bounded V06 exit decision with explicit reason and repair/recheck trigger.
منابع و تازگی
مطالعهٔ موارد (case studies)
تصاویر درس
فایل‌های آزمایشگاه
This is an offline synthetic provenance/handoff lab. Implement evaluate_case in starter.py, inspect the supplied fixtures, and keep package integrity, provenance/derivation, human change-note evidence, transfer receipt, external-source disclosure, reviewer acceptance and V06 exit as distinct evidence layers.
Cases include a valid baseline, a byte-identical return under a new filename, a checksum-valid package with no change note, checksum failure, ambiguous outbound identity, missing recipient/receipt, an untraced external source, and a complete provenance chain rejected by the human reviewer.
Run python run_checks.py for learner-visible structural checks. Use only the supplied synthetic records; no production media, private customer data, credentials, external network calls or privileged changes are required.