Structured Content Authoring + Partial Regeneration

وقتی اصلاح یک بند، کل درس را دوباره می‌نویسد

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

در این درس خروجی شما Structured Content Node Graph, Regeneration Patch Plan and Deterministic Diff/Promotion Ledger v1 است. به‌جای «بازنویسی فایل»، یک revision مشخص را پین می‌کنید، target و protected zone را جدا می‌کنید، اثر وابستگی را پیش از تولید حساب می‌کنید، candidate patch می‌سازید و قبل از promotion بررسی می‌کنید که چه چیزی واقعاً تغییر کرده است.

تمرین اصلی کاملاً آفلاین و ساختگی است و با JSON/CSV/Python اجرا می‌شود. هیچ محتوای production، LMS زنده یا دادهٔ مشتری تغییر نمی‌کند. زمان فعال پیشنهادی ۶۰ دقیقه است. بستهٔ تمرین را باز کنید و قبل از هر تصمیم، base revision و digest را ثبت کنید.

برای کسی که با ساخت محتوای ساخت‌یافته و AI-assisted authoring آشناست و می‌خواهد regeneration را قابل‌ممیزی و محدود کند.

این درس سامانهٔ انتشار زنده، LMS importer یا مدل تولید متن عمومی نمی‌سازد و مجوز تغییر خودکار محتوای canonical نمی‌دهد.

مرز درس و شاهد ورود

پیش‌نیاز مفهومی MKN-030 است. کافی است بتوانید بین محتوای canonical، artifact مشتق‌شده و بستهٔ قابل‌انتقال فرق بگذارید. اگر این مرز مبهم است، یک مثال کوچک بسازید: «متن اصلی»، «ترجمهٔ ساخته‌شده از آن» و «فایل ارائه‌شده به مصرف‌کننده» را سه چیز جدا بنویسید؛ سپس ادامه دهید.

MKN-031 مالک regeneration محدود روی nodeهای ساخت‌یافته است، نه انتشار نهایی، نه import به LMS و نه طراحی کل خط تولید محتوا. نتیجهٔ درست ممکن است REVIEW_REQUIRED یا HOLD باشد. هدف این نیست که همیشه patch را promote کنید؛ هدف این است که بتوانید دلیل promotion یا توقف را از شواهد قابل‌مشاهده بازسازی کنید.

مسیر پایه: مدل ذهنی → قرارداد fieldها → مثال baseline → failure modes → تمرین هدایت‌شده → انتقال مستقل. مسیر باتجربه می‌تواند تعریف‌ها را کوتاه کند، اما نمی‌تواند base pin، protected zone، dependency impact، provenance یا transfer را حذف کند.

شاهد ورود: برای یک درس فرضی، یک canonical node و یک derived artifact نام ببرید و توضیح دهید چرا تغییر دومی لزوماً مجوز تغییر اولی نیست.

مدل ذهنی: regeneration یک transaction محدود است

جریان را این‌گونه ببینید:

canonical structured revision → target + protected zones → dependency impact → pinned source/evidence snapshot → candidate generation → bounded patch + preconditions → structural/semantic diff → rebuild affected derived artifacts → REVIEW / HOLD / PROMOTE → audit + rollback

سه اصل ستون فقرات این مدل‌اند. اول، identity: هر node یک node_id پایدار دارد و «همان شناسه با معنای کاملاً جدید» مجاز نیست. دوم، concurrency: candidate باید دقیقاً از base revision و digest اعلام‌شده ساخته شود؛ اگر canonical در این فاصله عوض شد، candidate قدیمی است. سوم، blast radius: target با «هر چیزی که مدل نزدیکش می‌بیند» یکی نیست. وابستگی‌ها ممکن است دامنهٔ derived rebuild را بزرگ‌تر کنند، اما canonical protected nodes را بدون مجوز وارد target نمی‌کنند.

JSON Patch در RFC 6902 یک patch را آرایه‌ای مرتب از operationها تعریف می‌کند و operation test می‌تواند پیش‌شرط را بررسی کند. در این درس از همین ایده برای fail-closed کردن base استفاده می‌کنیم؛ اما RFC تعیین نمی‌کند کدام node آموزشی حق regeneration دارد یا چه کسی promotion را تأیید می‌کند. RFC 6902

MKN-031-F1 — بازیابی مرز: سه تفاوت بین whole-document rewrite و bounded partial regeneration بنویسید و یک فعالیت خارج از محدودهٔ این درس نام ببرید.

حداقل قرارداد داده‌ای

JSON Schema Draft 2020-12 برای توصیف و اعتبارسنجی ساختار JSON، referenceها و vocabularyها یک dialect جاری فراهم می‌کند. این ابزار می‌تواند بگوید فیلد لازم وجود دارد یا نوع داده درست است؛ نمی‌تواند بگوید یک تغییر آموزشی از نظر معنایی خوب است. JSON Schema 2020-12

در قرارداد این درس، چهار گروه field دارید:

1. Identity و base: content_id, schema_version, node_id, node_type, base_revision_id, base_digest.
2. Request و scope: regeneration_request_id, target_node_ids, protected_node_ids, generation_policy_version.
3. Evidence و impact: source_snapshot_ref, evidence_snapshot_ref, dependency_graph_ref, affected_derived_artifacts, precondition_test, structural_validation_state, semantic_diff_ref, claim_diff_state, source_diff_state, localization_impact_state, assessment_impact_state, human_edit_preservation_state.
4. Decision و audit: candidate_revision_id, candidate_patch_ref, provenance_activity_ref, generator_ref, review_state, promotion_state, rollback_ref, audit_event_id.

وضعیت‌های غیرموفق را حذف نکنید. STALE_BASE یعنی candidate دیگر به revision فعلی متصل نیست؛ UNKNOWN یعنی شاهد تعیین‌کننده ندارید؛ UNSUPPORTED یعنی قرارداد این حالت را پشتیبانی نمی‌کند؛ REVIEW_REQUIRED یعنی تصمیم انسانی/مستقل لازم است؛ HOLD یعنی promotion متوقف است. PARTIAL نیز می‌تواند نشان دهد فقط بخشی از impact اثبات شده است.

شناسهٔ پایدار باید هویت منطقی block را نگه دارد. اگر node-expl-01 دیروز «توضیح caching» بوده و امروز با همان شناسه «رationale ارزیابی» شود، diff دیگر قابل‌اعتماد نیست؛ این تغییر identity است نه صرفاً edit.

چرا target، protected zone و dependency graph سه چیز متفاوت‌اند؟

target_node_ids می‌گوید کدام canonical nodeها مجازند candidate content تازه بگیرند. protected_node_ids صریحاً می‌گوید کدام canonical nodeها حتی اگر نزدیک target باشند نباید تغییر کنند. dependency graph سؤال دیگری را جواب می‌دهد: «اگر target تغییر کند، چه artifactهای مشتق‌شده‌ای دیگر قابل‌اعتماد نیستند؟»

فرض کنید explanation-01 target است و ترجمهٔ فارسی و اسلاید ۳ از آن مشتق می‌شوند. dependency analysis می‌تواند هر دو artifact را برای rebuild علامت بزند. این به معنی مجوز تغییر assessment-01 نیست. اگر assessment به‌طور معنایی به همان claim متکی است، impact state باید این ریسک را نشان دهد و دامنهٔ review یا target فقط با شواهد و rule روشن بزرگ شود.

precondition نیز صرفاً یک hash تزئینی نیست. candidate باید حداقل base_revision_id و base_digest را به‌عنوان پیش‌شرط bind کند. اگر canonical از rev-17 به rev-18 رفته باشد، patch ساخته‌شده برای rev-17 نباید روی rev-18 اعمال شود، حتی اگر pathها هنوز وجود داشته باشند. این همان جایی است که STALE_BASE → HOLD جلوی overwrite خاموش را می‌گیرد.

provenance پاسخ می‌دهد «این candidate از چه entityها و با کدام activity و generator ساخته شد؟». W3C PROV برای entity، activity و agent یک مدل عمومی می‌دهد؛ سیاست MAKNOW مشخص می‌کند چه provenanceای برای promotion کافی است. W3C PROV Overview

MKN-031-F2 — تشخیص منفی: اگر candidate به یک protected owner note دست بزند، کدام fieldها نامعتبر می‌شوند و کوچک‌ترین repair چیست؟ پاسخ باید فقط «دوباره generate کن» نباشد.

مثال حل‌شده ۱: یک توضیح قدیمی، دو artifact وابسته

در baseline.json، revision rev-17 چهار canonical node دارد. فقط node-expl-01 stale شده است. node-assess-01، node-owner-01 و node-diagram-01 protected هستند. dependency graph نشان می‌دهد ترجمهٔ derived-fa-expl-01 و اسلاید derived-slide-03 از explanation مشتق می‌شوند.

candidate یک patch محدود می‌سازد: ابتدا revision و digest را با test بررسی می‌کند، سپس فقط body همان target را replace می‌کند. candidate همان source/evidence snapshot را ثبت می‌کند و provenance activity مستقل دارد. structural validation می‌گذرد، protected digestها ثابت‌اند و affected derived set دقیقاً با dependency impact برابر است. چون claim wording تغییر کرده، claim_diff_state=CHANGED_REVIEW_REQUIRED است؛ بنابراین verdict مناسب REVIEW_REQUIRED و promotion HOLD_PENDING_REVIEW است، نه PROMOTE.

خلاصهٔ جدول کاری:

جدول کامل در derived_text/tables/MKN-031-T1.csv است و نگاشت fieldها در field_map.json آمده است.

مثال حل‌شده ۲: base بعد از generation تغییر می‌کند

در stale_base.json، candidate هنوز می‌گوید از rev-17 ساخته شده، اما canonical فعلی rev-18 است. حتی اگر محتوای تازه ظاهراً بهتر باشد، precondition شکست می‌خورد. repair حداقلی این نیست که test را حذف کنیم؛ باید candidate را روی base تازه بازسازی کنیم، dependency impact را دوباره محاسبه کنیم و provenance/diff جدید بسازیم. نتیجهٔ قبلی oracle نیست.

Failure Modeهای رایج

بازنویسی همسایه برای روانی متن: مدل target را بهانه می‌کند تا paragraph مجاور را هم تغییر دهد. درمان: changed canonical nodes باید زیرمجموعهٔ target باشند؛ protected touch مانع قطعی است.

پنهان‌کردن stale base: candidate را روی revision قدیمی نگه می‌داریم چون diff کوچک‌تر است. درمان: revision+digest precondition و fail-closed.

شناسهٔ ثابت با معنای تازه: همان node_id برای نوع/نقش دیگری استفاده می‌شود. درمان: identity invariant و migration صریح شناسه.

rebuild ناقص: target تغییر می‌کند اما ترجمه یا slide وابسته rebuild نمی‌شود. درمان: dependency set محاسبه‌شده با affected_derived_artifacts مقایسه شود؛ کمبود یعنی HOLD.

PASS ساختاری به‌جای PASS معنایی: schema معتبر است، پس تغییر را promotion می‌کنیم. درمان: structural validation فقط یک gate است؛ claim/source/assessment/localization diff جدا هستند.

provenance نمایشی: فقط نام مدل ذخیره می‌شود، اما base/source/policy snapshot معلوم نیست. درمان: activity باید ورودی‌ها و generator/policy را bind کند.

مسیر افراد باتجربه: regeneration را مثل merge کنترل‌شده ببینید

اگر با version control، optimistic concurrency یا event-sourced systems آشنا هستید، این قرارداد را با سه مفهوم مقایسه کنید: base commit، conflict detection و derived build invalidation. شباهت مفید است، اما یکی نیستند. semantic identity یک learning node و «آیا این تغییر آموزشی قابل‌قبول است؟» از Git diff به دست نمی‌آید.

برای سرعت، field dictionary را حفظ کنید ولی توضیح‌های مقدماتی را کوتاه بخوانید. سپس دو دفاع بنویسید: چرا whole-document regeneration در یک workflow review-heavy هزینهٔ ریسک دارد، و چرا over-protection نیز می‌تواند تغییر لازم را غیرممکن کند. تصمیم خوب trade-off را پنهان نمی‌کند: scope خیلی باز collateral drift را زیاد می‌کند؛ scope خیلی بسته ممکن است dependency واقعی را جا بیندازد.

در سیستم واقعی، patch engine می‌تواند JSON Patch، operationهای domain-specific یا transaction داخلی باشد. lesson به syntax خاص قفل نیست؛ invariantها قفل‌اند: base pinned، scope explicit، identity stable، impact visible، promotion gated.

جایگزین‌ها و trade-offها

Whole-document regeneration ساده‌ترین orchestration را دارد، اما preservation و audit سخت‌تر است. فقط وقتی مناسب است که کل سند واقعاً disposable و review دوبارهٔ کامل پذیرفته باشد؛ این درس چنین فرضی ندارد.

Text-range patching روی offset یا line سریع است، ولی با جابه‌جایی متن شکننده می‌شود و هویت معنایی node را ضعیف نگه می‌دارد. stable IDs هزینهٔ مدل داده را بالا می‌برند، اما diff و dependency tracking را مقاوم‌تر می‌کنند.

Manual editing only collateral drift مدل را کم می‌کند، ولی automation، provenance و تکرارپذیری را از بین نمی‌برد؛ هنوز باید base و evidence را مدیریت کنید. هدف partial regeneration حذف انسان نیست، بلکه کوچک‌کردن سطح تغییر و واضح‌کردن نقطهٔ accountability است.

Semantic similarity score می‌تواند advisory باشد، اما به‌تنهایی promotion gate نیست. یک نمرهٔ بالا نمی‌گوید protected owner edit حفظ شده یا source snapshot درست بوده است. این درس score ترکیبی مصنوعی نمی‌سازد؛ هر dimension تصمیم جدا می‌ماند.

تمرین هدایت‌شده و مستقل

تمرین هدایت‌شده

1. fixtures/baseline.json را باز کنید و base_revision_id, base_digest, target و protected set را استخراج کنید.
2. dependency graph را از target پیمایش کنید و affected derived artifacts را بنویسید.
3. patch را بخوانید و بررسی کنید testها پیش از replace آمده‌اند.
4. evidence/decision.template.json را با stateها، evidence refs، rationale و minimal repair تکمیل کنید.
5. اجرا کنید:

python run_checks.py fixtures/baseline.json evidence/submission.baseline.json

checker فقط ساختار، binding و invariantهای قابل‌محاسبه را بررسی می‌کند؛ کیفیت rationale هنوز نیاز به review دارد.

تمرین مستقل

بدون استفاده از verdict baseline، transfer/transfer_fixture.json را تحلیل کنید. این بار target یک assessment rationale است و dependency graph نشان می‌دهد ترجمه و slide مرتبط نیز invalid می‌شوند. affected set را فقط تا جایی بزرگ کنید که evidence می‌گوید. اگر protected node تغییر کرده یا base stale است، HOLD بدهید.

MKN-031-F3 — انتقال: تصمیم transfer را از صفر بسازید و توضیح دهید چرا baseline decision قابل کپی‌کردن نیست.

بستهٔ شواهد قابل‌قبول چه دارد؟

یک تصمیم قابل‌ممیزی باید حداقل این‌ها را نشان دهد: canonical identity و schema version؛ base revision/digest؛ source و evidence snapshot؛ request ID؛ target/protected set؛ dependency graph؛ candidate revision و patch reference؛ precondition result؛ structural state؛ semantic/claim/source/localization/assessment impact؛ preservation state؛ provenance activity و generator/policy؛ review/promotion state؛ rollback ref؛ audit event.

در Lab، reference_evaluator.py در پوشهٔ داخلی تولیدکننده فقط برای تست مرجع است و به learner منتشر نمی‌شود. learner باید از fixture و ruleهای آشکار خودش نتیجه را بسازد. تست‌های تولیدکننده baseline، stale base، protected change، missing evidence، reused node ID و missed dependency rebuild را بررسی می‌کنند.

قانون fail-closed: اگر evidence تعیین‌کننده missing یا malformed باشد، تصمیم به success تبدیل نمی‌شود. UNKNOWN/PARTIAL در dimension و HOLD در promotion قابل‌قبول‌تر از confidence ساختگی است.

برای rollback، فقط نوشتن «برگرد» کافی نیست. rollback_ref باید یک revision معتبر و immutable باشد و audit event باید نشان دهد چه candidateای چرا promote یا reject شده است.

ارزیابی نهایی و Transfer

چهار سؤال summative در derived_text/assessment/questions.json هستند:

• S1 — Retrieval: مرز partial regeneration و یک non-goal را توضیح دهید.
• S2 — Application: artifact کامل baseline را بسازید و تمام dimensionهای حیاتی را bind کنید.
• S3 — Diagnosis: stale-base mutation را تشخیص دهید، consequence و repair حداقلی بدهید.
• S4 — Transfer: assessment rationale تازه را با dependency جدید تحلیل کنید و affected set را مستقل بازسازی کنید.

در rubric، پنج dimension بحرانی‌اند: identity/contract، evidence binding، negative evidence، bounded decision و transfer. شکست هرکدام blocking است. یک پاسخ خوب فقط نتیجه نمی‌دهد؛ evidence pointer، state، consequence و trigger بازبینی را هم می‌نویسد.

معیار استقلال: اگر evaluator برچسب verdict مثال حل‌شده را حذف کند، باید بتوانید فقط از fixture و ruleها همان boundary را دوباره بسازید. اگر پاسخ به «چون مثال قبلی REVIEW_REQUIRED بود» متکی است، transfer انجام نشده است.

منابع، مرز ادعا و Freshness

سه منبع بیرونی مبنای factهای این درس‌اند:

1. JSON Schema Specification — برای ساختار و validation JSON. این منبع regeneration authority یا semantic correctness را تعریف نمی‌کند.
2. RFC 6902 — JSON Patch — برای operationهای partial modification و test precondition. این RFC دربارهٔ eligibility یک learning node یا promotion authority تصمیم نمی‌گیرد.
3. W3C PROV Overview — برای مدل عمومی provenance. thresholdهای review و promotion در این درس design محلی‌اند.

این منابع در 2026-09-13 دوباره بررسی شدند. Bible برای JSON Schema و inferenceهای practice-evolving بازبینی تا ابتدای 2027 را می‌خواهد و trigger محلی درس بازبینی حداکثر تا 2027-01-15 یا زودتر در صورت تغییر material specification است. نسخهٔ frozen درس با تغییر منبع silently rewrite نمی‌شود؛ requalification باید نسخه‌دار باشد.

سؤال پایانی: در workflow خودتان کدام shortcut بیشترین احتمال false confidence دارد—whole rewrite، stale base، hidden dependency یا weak provenance—و دقیقاً چه evidence fieldی آن را آشکار می‌کند؟