Single-source Content Model

1) چرا کپی‌کردن یک claim در چند کانال، «single source» نیست؟

فرض کنید جمله‌ی ضمانت یک محصول در صفحه‌ی محصول، PDF فروش، اپ، ایمیل و قالب شبکه‌ی اجتماعی کپی شده است. وقتی سیاست ضمانت عوض می‌شود، بعضی کپی‌ها اصلاح می‌شوند و بعضی نه. مشکل فقط «به‌روزرسانی ناقص» نیست؛ دیگر معلوم نیست کدام متن canonical است، هر نسخه از کجا آمده و اگر یک حقیقت مرکزی تغییر کند کدام مصرف‌کننده‌ها باید دوباره بررسی شوند.

در این درس Single-source Content Graph Contract v1 را می‌سازیم: مدلی که حقیقت canonical را از presentation کانال جدا می‌کند، reuse را با reference انجام می‌دهد، context را قبل از reuse می‌سنجد و impact تغییر canonical را قبل از promotion ثبت می‌کند.

قانون مرکزی: Single-source یعنی یک منبع authoritative برای حقیقت؛ نه اینکه همه‌ی کانال‌ها مجبور باشند دقیقاً یک متن یکسان نمایش دهند.

2) مرز درس: چه چیزی در اختیار COM-015 است و چه چیزی نیست؟

COM-015 مالک مدل canonical entity، fragment، reference، consumer context، render rule، override policy و impact set است. COM-014 مالک Performance Feedback Loop است و COM-016 مالک Asset Provenance؛ این دو outcome را جذب نمی‌کنیم.

هیچ migration زنده، publish واقعی، تغییر billing یا mutation روی tenant انجام نمی‌شود. آزمایشگاه synthetic و آفلاین است و خروجی یک bounded decision قابل بازتولید است.

3) مدل ذهنی: Canonical Entity → Fragment → Reference → Context → Render → Consumer

هر حقیقت reusable یک canonical_entity_id و canonical_version دارد. بخش reusable با content_fragment_id شناخته می‌شود. مصرف‌کننده به‌جای کپی، با reference_id به همان fragment اشاره می‌کند. سپس consumer_context و constraintها بررسی می‌شوند و render_rule فقط presentation مجاز را تولید می‌کند.

اگر reference، context، override policy یا impact evidence معتبر نیست، promotion موفق مجاز نیست.

4) Content Model و Reference در Contentful چه چیزی را ثابت می‌کنند؟

Contentful content model را مجموعه‌ای از content typeها و fieldها معرفی می‌کند و content typeها می‌توانند با reference field به هم متصل شوند. در راهنمای References نیز صریحاً reuse را جایگزین copy/paste می‌کند و توضیح می‌دهد تغییر referenced entry در مصرف‌کننده‌هایی که به آن reference دارند قابل انتشار است.

این FACT فقط نشان می‌دهد یک CMS مدرن reference-based reuse را پشتیبانی می‌کند؛ به معنی این نیست که MAKNOW باید همان API، permission model یا lifecycle Contentful را کپی کند.

5) DITA conref چه درس مهمی درباره‌ی context می‌دهد؟

OASIS DITA برای reuse از conref استفاده می‌کند و هنگام processing محدودیت‌های context مبدأ و مقصد را مقایسه می‌کند تا reuse بعد از resolution همچنان معتبر باشد. این نکته مهم است: «reference وجود دارد» با «reference در این context درست است» یکی نیست.

در MAKNOW از این ایده به‌صورت عمومی‌تر استفاده می‌کنیم: reusable fragment باید برای context مصرف‌کننده validate شود؛ خود DITA معماری تجاری ما را تعیین نمی‌کند.

6) Canonical identity و version: منبع حقیقت باید آدرس دقیق داشته باشد

canonical_entity_id هویت منطقی است و canonical_version نسخه‌ی دقیق همان حقیقت. filename، slug یا location کانال نباید جای هویت canonical را بگیرد. اگر متن ضمانت از v4 به v5 تغییر کرده، reference و impact analysis باید بدانند کدام مصرف‌کننده هنوز v4 را render می‌کند یا نیازمند revalidation است.

field_schema نیز مشخص می‌کند کدام بخش canonical fact، regulated text، marketing copy یا structured value است؛ چون آزادی render برای همه‌ی fieldها یکسان نیست.

7) Reference به‌جای Copy: تفاوت اصلی همین‌جاست

اگر consumer متن canonical را در field محلی کپی کند، یک source of truth دوم ساخته شده است—even اگر امروز متن‌ها یکسان باشند. reference_id باید مصرف‌کننده را به content_fragment_id و version مورد نظر متصل کند.

اگر تیم واقعاً به یک variant نیاز دارد، آن variant باید با render rule یا override policy صریح مدل شود، نه با fork خاموش.

8) Render Rule: presentation می‌تواند فرق کند، meaning نباید بی‌صدا fork شود

یک کانال موبایل ممکن است متن کوتاه‌تر بخواهد و PDF حقوقی متن کامل. این تفاوت با single-source تناقض ندارد. render_rule می‌تواند طول، format، ترتیب fieldها یا layout را تغییر دهد، به شرط اینکه constraintهای semantic و regulated text رعایت شوند.

مثلاً «ارسال رایگان برای سفارش‌های بالای ۲ میلیون تومان» را نمی‌توان برای banner کوتاه به «ارسال رایگان» تبدیل کرد؛ چون meaning عوض می‌شود. اینجا BLOCKED_RENDER_DRIFT درست‌تر از پذیرش است.

9) Override Policy: استثنا بدون قرارداد، drift سازمان‌یافته است

گاهی consumer باید استثنائاً wording متفاوتی داشته باشد. اگر override_policy صریح نیست، تیم نباید یک override محلی ایجاد کند و بعد آن را single-source بنامد. Policy باید بگوید چه کسی override می‌کند، scope آن چیست، چه مدت معتبر است و آیا canonical update آن را invalidate می‌کند.

Override مجاز هم یک source of truth جدید نیست؛ یک exception governed و traceable است.

10) Impact Set: قبل از تغییر canonical بدانیم چه چیزی می‌شکند

وقتی canonical field تغییر می‌کند، impact_set باید consumerهای متأثر را فهرست کند. impact فقط «کجا reference شده» نیست؛ باید نشان دهد کدام context و render rule نیاز به revalidation دارند.

اگر canonical change انجام شده ولی impact set ناقص است، BLOCKED_IMPACT_GAP از promotion ظاهراً موفق امن‌تر است.

11) مثال baseline و failure modeهای اصلی

Baseline: entity و version مشخص‌اند، fragment و reference معتبرند، context سازگار است، render meaning را حفظ می‌کند، override لازم نیست و impact set برای تغییرات قبلی کامل است. state می‌تواند REFERENCE_SAFE باشد.

Failure 1: consumer متن claim را copy کرده و reference ندارد → BLOCKED_DUPLICATED_SOURCE.

Failure 2: override درخواست شده ولی policy تعریف نشده → BLOCKED_OVERRIDE_POLICY.

Failure 3: canonical version تغییر کرده اما impact set کامل نیست → BLOCKED_IMPACT_GAP.

Failure 4: fragment در context نامعتبر reuse شده → BLOCKED_CONTEXT.

12) Lab و transfer: کانال جدید، متن کوتاه‌تر می‌خواهد

در COM-015-LAB1 هشت fixture آفلاین داریم. learner باید state را از شواهد visible بسازد، نه اینکه baseline را حفظ کند.

Transfer: یک کانال جدید presentation کوتاه‌تری از یک product fact می‌خواهد. راه درست این نیست که claim را کپی و کوتاه کنیم. باید همان canonical fragment را reference کنیم، context و constraint را validate کنیم، render rule کوتاه‌سازی بسازیم، meaning preservation را تست کنیم و consumer جدید را در impact graph نگه داریم.

13) تصمیم bounded، freshness و چیزی که اثبات نکردیم

این درس اثبات نمی‌کند یک vendor خاص «بهترین CMS» است و هیچ publish زنده‌ای انجام نمی‌دهد. خروجی فقط می‌گوید آیا یک consumer در evidence package فعلی می‌تواند به شکل traceable از canonical source استفاده کند یا باید HOLD/BLOCKED بماند.

راهنمای Contentful چون vendor-current است تا 2026-12-31 یا بعد از تغییر material در semantics مدل/reference دوباره بررسی می‌شود. OASIS DITA 1.3 conref یک مرجع foundational است. identity، override policy، impact gate و state vocabulary DESIGN خود MAKNOW هستند، نه الزام Contentful یا OASIS.