Source Authority: Source Version, Binding, Policy و Reveal

1. مسئله واقعی: canonical بودن، نسخه دقیق را ثابت نمی‌کند

یک URL، مسیر repository، رکورد CMS یا فایل Drive می‌تواند «مرجع اصلی» نامیده شود و در عین حال bytes آن زیر پای مصرف‌کننده تغییر کند. اگر consumer فقط locator را ذخیره کند، بعداً نمی‌تواند ثابت کند کدام نسخه را دیده است. هدف این درس ساختن Canonical Source Authority Record & Binding Matrix v1 است: canonical identity پایدار، snapshot/version دقیق، digest و size، lineage، policy owner/version، reveal selector و consumer binding همه جدا ثبت می‌شوند.

2. سه هویت را از هم جدا کن

canonical_source_id هویت منطقی منبع است؛ locator فقط راه resolve کردن است؛ source_version یا snapshot identity نسخه immutable مصرف‌شده را مشخص می‌کند. این سه field را در یک «current_file» ادغام نکن. تغییر locator الزاماً تغییر canonical identity نیست و تغییر bytes زیر همان locator الزاماً همان source version نیست.

3. Binding باید به bytes دقیق برسد

برای source version فقط اسم نسخه کافی نیست. content_digest و content_size را ثبت و هنگام resolve دوباره verify کن. الگوی OCI Descriptor مفید است: type، digest و size برای refer کردن به content مشخص کنار هم قرار می‌گیرند. MAKNOW مجبور نیست فرمت OCI را استفاده کند؛ فقط از اصل content binding بهره می‌گیرد.

4. Provenance lineage با PROV-O قابل مدل‌سازی است

PROV-O مفهوم‌های Entity، Activity و Agent و رابطه‌هایی مثل wasDerivedFrom را برای provenance تعریف می‌کند. در Source Authority Record از این الگو برای source_version -> derived_from -> prior_version، agent/owner و activity تولید استفاده کن. Provenance می‌گوید نسخه از کجا آمده؛ canonical selection یا reveal permission را خودش تعیین نمی‌کند.

5. Resolver history را نگه دار

اگر SRC-77 امروز به v3 resolve می‌شود، این واقعیت نباید binding تاریخی consumer به v2 را پاک کند. resolver eventها را append-only نگه دار: چه زمانی canonical ID به کدام snapshot اشاره کرده، چه کسی آن را تغییر داده و دلیل چیست. latest یک query است، نه تاریخچه.

6. Supersession با invalidation یکی نیست

نسخه v2 می‌تواند superseded باشد ولی bytes و digest آن همچنان reproducible و binding تاریخی آن معتبر بماند. superseded_by=v3 را جدا از binding_verified نگه دار. برای consumer جدید شاید v3 مرجع جاری باشد؛ برای audit تصمیم قدیمی، v2 باید قابل بازسازی بماند.

7. Authority conflict را typed کن

اگر registry می‌گوید canonical source به snapshot A اشاره می‌کند اما digest اعلام‌شده به snapshot B می‌خورد، «نزدیک‌ترین» یا «جدیدترین» را حدس نزن. نتیجه باید AUTHORITY_CONFLICT باشد و downstream fail closed کند. conflict را با overwrite کردن یکی از رکوردها پنهان نکن.

8. UNBOUND_VERSION یک state واقعی است

اگر path همان است ولی bytes عوض شده و digest جدید هنوز explicit register نشده، آن content را به‌عنوان «نسخه جدید canonical» قبول نکن. UNBOUND_VERSION یعنی منبع وجود دارد اما binding دقیق و مجاز هنوز ساخته نشده است. existence و authority دو چیز متفاوت‌اند.

9. Policy identity و version را مستقل ثبت کن

هر تصمیم source باید بداند تحت کدام policy_id و policy_version ساخته شده است. policy owner و effective period را نگه دار. تغییر policy بدون تغییر bytes می‌تواند eligibility مصرف را تغییر دهد؛ بنابراین policy را از source digest جدا نگه دار.

10. Reveal eligibility یک selector مستقل است

reveal_after, audience_scope و هر selector لازم را صریح ثبت کن. source ممکن است binding صحیح داشته باشد اما برای audience عمومی در timestamp فعلی REVEAL_BLOCKED_TIME یا REVEAL_BLOCKED_AUDIENCE باشد. این درس reveal را به‌عنوان policy state می‌سنجد؛ rights/embargo legal authority متعلق به CON-003 است.

11. Binding و reveal را در یک flag له نکن

binding_verified=true نمی‌گوید publication مجاز است؛ reveal_eligible=true هم نمی‌گوید bytes دقیقاً همان نسخه approved هستند. در matrix دو محور مستقل داشته باش: source binding state و reveal selector state. downstream باید هر دو را جدا مصرف کند.

12. Consumer binding را explicit کن

هر claim، asset یا release consumer باید consumer_ref و exact source_version_ref داشته باشد. اگر consumer فقط SRC-77 یا faq.md را نگه دارد، با حرکت resolver silently rebind می‌شود. explicit snapshot binding جلوی drift پنهان را می‌گیرد.

13. Rebinding یک تصمیم جدید است

وقتی snapshot جدید canonical می‌شود، consumer قدیمی را خودکار migrate نکن. ابتدا new version را register و digest/size را verify کن، supersession lineage را ثبت کن و سپس یک explicit rebind event بساز. این event باید actor، time، reason و old/new binding را داشته باشد.

14. Transfer: locator ثابت است، authority تغییر کرده

در تمرین انتقال، faq.md همان path باقی می‌ماند ولی bytes عوض می‌شود، سپس registry snapshot جدید را ثبت می‌کند و reveal audience هم تغییر می‌کند. ابتدا باید UNBOUND_VERSION بدهی؛ بعد از register/verify، binding جدید را explicit بسازی؛ سپس reveal selector را از نو ارزیابی کنی. هیچ state قبلی را copy نکن.

15. خروجی نهایی و مرز اتکا

Canonical Source Authority Record & Binding Matrix v1 باید Canonical Source ID، Locator، Source Version، Digest، Size، Provenance Entity/Activity/Agent، Derived From، Source Owner، Policy ID/Version، Reveal State/After/Audience، Superseded By، Binding Verified، Consumer Ref، Decision، Reason و Rebind Trigger را نگه دارد. این درس claim truth، rights، approval validity یا release composition را تعیین نمی‌کند؛ فقط ثابت می‌کند consumer دقیقاً به کدام source snapshot متصل است و آیا reveal selector فعلی اجازه انتخاب آن را می‌دهد یا نه.