منبع حقیقت

این صفحه مشخص می‌کند منابع رسمی BDL چگونه شناسایی، اولویت‌بندی، نگهداری و تفسیر می‌شوند.

مستندات BDL بر یک منبع واحد و بدون تفکیک متکی نیست. هر منبع رسمی، حوزه، نسخه، سطح اعتبار و نقش مشخصی در حاکمیت دانش BDL دارد.

رجیستری رسمی منابع

فهرست رسمی منابع تحت حاکمیت در فایل source-registry.json نگهداری می‌شود.

هر رکورد منبع شامل اطلاعات اصلی زیر است:

• source_id پایدار؛
• نوع منبع؛
• نسخه رسمی؛
• وضعیت حاکمیتی؛
• وضعیت نگهداری؛
• مسیر canonical در مخزن؛
• SHA-256؛
• اندازه دقیق Artifact؛
• رابطه supersession در صورت اثبات.

Baselineهای جاری

Baselineهای رسمی فعلی عبارت‌اند از:

منبع	نسخه	وضعیت
BDL Master Knowledge Pack	5.2.2	current
Native Barsa System Design Contract	2.0.0	current
BDL Runtime/Troubleshooting Knowledge Pack	2.0.0	current

منابع Historical و Superseded برای provenance، بررسی compatibility، regression investigation و conflict resolution نگهداری می‌شوند.

اولویت منابع

اولویت یک منبع بر اساس scope و authority تعیین می‌شود، نه صرفاً بر اساس جدیدتر بودن فایل یا تاریخ انتشار.

ترتیب پیش‌فرض برای ادعاهای هم‌پوشان در یک scope سازگار چنین است:

1. Native Barsa contract
2. BDL Master Knowledge Pack
3. Runtime / Troubleshooting Knowledge Pack
4. Historical source

این ترتیب نباید باعث ادغام سطوح مختلف قابلیت در یک مفهوم کلی «پشتیبانی» شود.

لایه‌های قابلیت

در BDL چهار لایه باید همیشه جدا از یکدیگر باقی بمانند:

1. Native Barsa — قابلیت و رفتار خود برسا.
2. Runtime Support — رفتاری که Runtime از آن پشتیبانی می‌کند یا در آن مشاهده شده است.
3. BDL Expressibility — آنچه زبان BDL قادر به بیان آن است.
4. BDL Authoring Availability — آنچه ابزارهای فعلی Authoring امکان ایجاد یا تنظیم آن را می‌دهند.

اثبات یک لایه به‌تنهایی اثبات لایه دیگر محسوب نمی‌شود.

وضعیت منابع

وضعیت‌های رسمی منابع عبارت‌اند از:

• current
• historical
• superseded
• deprecated
• withdrawn

وضعیت منبع با الزام نگهداری آن یک مفهوم نیست. یک منبع superseded یا historical همچنان می‌تواند preserved: true باشد.

Supersession

فیلد supersedes فقط رابطه مستقیم و اثبات‌شده جایگزینی را ثبت می‌کند.

صرف بالاتر بودن شماره نسخه یا جدیدتر بودن تاریخ، دلیل کافی برای ایجاد این رابطه نیست.

اگر Evidence صریح برای supersession مستقیم وجود نداشته باشد، مقدار supersedes باید null باقی بماند.

حل تعارض منابع

هنگام مشاهده تعارض، قبل از انتخاب یک تفسیر رسمی باید این موارد بررسی شوند:

1. یکسان بودن scope؛
2. یکسان بودن capability layer؛
3. Source Precedence؛
4. status و version؛
5. رابطه صریح supersedes؛
6. provenance و Evidence؛
7. حفظ حالت unresolved در صورت کافی نبودن Evidence.

هیچ تعارض مهمی نباید با حذف، overwrite یا پنهان‌کردن خاموش یک منبع حل شود.

قانون No-Loss

اطلاعات رسمی BDL نباید بدون تصمیم حاکمیتی مشخص حذف، overwrite، جایگزین یا غیرقابل‌دسترسی شوند.

Artifact، metadata، checksum، provenance، evidence و هویت تاریخی باید در موارد لازم قابل بازیابی باقی بمانند.

حذف یک Source از navigation یا download عمومی به معنی اجازه حذف Source اصلی نیست.

Evidence و Provenance

ادعاهای مهم و تصمیم‌های حاکمیتی باید به Evidence کافی قابل ردیابی باشند.

تا حد امکان Evidence باید reproducible، attributable، versioned و در برابر تغییر خاموش محافظت‌شده باشد.

Inference باید از statement مستقیم یک منبع authoritative قابل تشخیص باشد.

Integrity

رجیستری منابع در برابر Artifactهای واقعی با این موارد اعتبارسنجی می‌شود:

• وجود فایل؛
• اندازه دقیق فایل؛
• SHA-256؛
• یکتایی source_id.

رجیستری فعلی شامل هفت Source رسمی است که همگی در برابر Artifactهای واقعی خود اعتبارسنجی شده‌اند.

اصل حاکمیتی

Implementation without verification is incomplete.

همین اصل در Source Governance نیز برقرار است: وضعیت رسمی، حل تعارض، preservation و publication باید بر Evidence کافی متکی باشند.