Media Factory Recipes و Deterministic Transforms

1. یک preset ثابت، recipe ثابت نیست

نامی مثل web-final فقط یک label است. اگر ورودی، نسخه ابزار، encoder، پارامتر یا metadata تغییر کند، همان label نمی‌تواند reproducibility را ثابت کند. در این درس هر transform باید یک recipe_id و recipe_version قابل ممیزی داشته باشد.

2. مرز مالکیت CON-015

CON-015 قرارداد recipe و شواهد reproducibility را می‌بندد. رکورد authoritative رسانه و rights در CON-014 است؛ جزئیات command در CON-016؛ lineage شاخه‌های خلاقه در CON-017؛ و مجوز انتشار در CON-018/CON-022. خروجی این درس فقط درباره transform قابل بازسازی ادعا می‌کند.

3. exact input را با digest ببند

Filename، path یا thumbnail هویت byte-level نیستند. recipe باید input_asset_ref و input_digest را ثبت کند. اگر digest ورودی عوض شود، lineage خروجی جدید است؛ overwrite کردن derivative قدیمی trace را از بین می‌برد.

4. tool build و environment را بخشی از recipe بدان

tool_id، tool_version، container image یا environment fingerprint باید ثبت شوند. یک command یکسان روی build یا hardware path متفاوت می‌تواند خروجی متفاوت بدهد؛ تفاوت باید typed شود، نه اینکه پشت همان preset مخفی بماند.

5. operation sequence ترتیب دارد

Resize→crop با crop→resize یک recipe نیست. عملیات باید به‌ترتیب و با parameter set دقیق ثبت شوند. تغییر حتی یک parameter باید یا recipe version جدید بسازد یا به‌صورت drift رد شود.

6. randomness باید policy داشته باشد

اگر transform شامل seed، sampling یا encoder behavior وابسته به randomness است، seed_or_randomness_policy باید NONE، FIXED یا صریحاً UNDECLARED باشد. حالت نامعلوم اجازه ادعای determinism نمی‌دهد.

7. metadata و clock می‌توانند byteها را تغییر دهند

Creation time، encoder tag یا metadata متغیر می‌تواند digest خروجی را عوض کند، حتی وقتی تصویر/صدا از نظر فنی مشابه است. recipe باید مشخص کند metadata volatile حذف، ثابت یا در equivalence policy نادیده گرفته می‌شود.

8. output spec قبل از اجرا تعریف می‌شود

ابعاد، container، codec family، sample rate یا سایر propertyهای موردنیاز باید پیش از run در output_spec ثبت شوند. بعد از اجرا، observed output با این contract مقایسه می‌شود؛ «فایل باز شد» معیار کافی نیست.

9. byte determinism یک ادعای اثباتی است

فقط وقتی repeat run با bindings یکسان و policy کنترل‌شده digest یکسان می‌دهد، می‌توان byte_deterministic=true را ثبت کرد. استفاده از -bitexact یا command تکراری به‌تنهایی جای evidence run را نمی‌گیرد.

10. bounded equivalence با byte identity فرق دارد

گاهی خروجی‌های byte-different از نظر technical و semantic در محدوده قابل قبول‌اند. در این حالت decision باید BOUNDED_EQUIVALENCE_ONLY باشد و policy دقیق بگوید چه تفاوت‌هایی مجازند؛ نباید آن را byte determinism نامید.

11. derivation را به run متصل کن

هر derivative جدید باید به input entity، recipe version و reproducibility_run_id متصل شود. PROV می‌تواند lineage entity/activity را بیان کند؛ اما deterministic بودن را خود شواهد recipe/run باید نشان دهند.

12. drift را تایپ کن

INPUT_DRIFT، TOOL_DRIFT، ENVIRONMENT_DRIFT، RECIPE_DRIFT، RANDOMNESS_UNBOUND و METADATA_TIME_DRIFT کمک می‌کنند failure قابل اقدام باشد. یک PASS/FAIL مبهم برای factory کافی نیست.

13. Matrix شواهد: declared در برابر observed

برای هر run، bindingهای declared و observed را کنار هم بگذار: input digest، tool/environment، operations/parameters، randomness، metadata policy، output digest و equivalence result. decision فقط از همین evidence ساخته می‌شود.

14. Lab: هشت fixture و 64 assertion

Lab هشت سناریوی synthetic دارد: baseline byte-identical، parameter drift بدون version bump، build/hardware جدید، metadata timestamp، input digest تغییرکرده، randomness نامعلوم، bounded equivalence و transfer نسخه جدید. evaluator برای هر case هشت خروجی مستقل می‌سنجد.

15. Transfer: digest جدید، build جدید، timestamp جدید

در transfer، یک input digest عوض می‌شود، tool build جدید pin می‌شود و metadata timestamp وارد می‌شود. شما باید نشان دهید کدام تغییر recipe version جدید می‌خواهد، کدام فقط bounded equivalence است و کجا باید BLOCK یا DEFER شود. خروجی قبلی هرگز مرجع تصمیم جدید نیست.