Portable Content Package و Import/Export Architecture

وقتی ZIP باز می‌شود اما معنا از بین رفته است

یک دورهٔ آموزشی را تصور کنید که فقط چند فایل HTML نیست: nodeهای ساخت‌یافته، media، یک assessment مبتنی بر QTI، یک external tool link، نسخه‌های localization، و referenceهای rights/provenance دارد. شما آن را ZIP می‌کنید، LMS مقصد بدون خطا import می‌کند و پیام «Success» نشان می‌دهد. چند روز بعد معلوم می‌شود یک block اختصاصی MAKNOW به متن ساده تبدیل شده، resource IDها عوض شده‌اند، assessment بخشی از قابلیت‌هایش را از دست داده و دیگر نمی‌توان ثابت کرد محتوای re-export شده همان semantics اولیه را دارد.

پس قابل‌حمل بودن فایل با قابل‌حمل بودن معنا یکی نیست. در این درس خروجی شما MCB Portable Package Manifest, Import/Export Compatibility Matrix and Round-trip Evidence Ledger v1 است: یک قرارداد قابل‌ممیزی که canonical source را از rendering مشتق‌شده جدا می‌کند، manifest و stable resource identity می‌سازد، digest/rights/provenance را bind می‌کند، capability هدف را قبل از import می‌سنجد، unsupported semantics را به‌جای flatten شدن quarantine می‌کند و بعد از export→import→export یک semantic diff قطعی می‌سازد.

تمرین اصلی آفلاین، ساختگی و با JSON/CSV/Python است. هیچ LMS زنده یا دادهٔ واقعی تغییر نمی‌کند. زمان فعال پیشنهادی ۶۰ دقیقه است. بستهٔ تمرین را باز کنید و قبل از تصمیم، manifest، capability profile و evidence ledger را جدا نگه دارید.

برای کسی که طراحی learning-content platform، import/export یا content pipeline انجام می‌دهد و می‌خواهد portability را با evidence اثبات کند، نه با «فایل باز شد».

این درس importer production یا یک استاندارد جهانی جدید نمی‌سازد، live LMS را تغییر نمی‌دهد و موفقیت یک format خارجی را معادل authority معماری MAKNOW نمی‌گیرد.

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

پیش‌نیاز مفهومی MKN-027 است. شاهد ورود ساده است: باید بتوانید یک artifact را از authority آن جدا کنید؛ مثلاً بگویید «این HTML یک rendering است، اما source ساخت‌یافتهٔ درس می‌تواند جای دیگری باشد». اگر این مرز مبهم است، قبل از ادامه برای یک مثال سه ستون بنویسید: canonical source / derived artifact / transport package.

MKN-030 مالک معماری package و import/export قابل‌ممیزی است. مالک partial regeneration درس بعدی نیست و outcome مربوط به mentor/escalation درس قبلی را هم جذب نمی‌کند. نتیجهٔ درست این درس همیشه IMPORT نیست؛ ممکن است MIGRATE, QUARANTINED, UNKNOWN, REVIEW_REQUIRED یا HOLD باشد.

مسیر پایه: canonical boundary → manifest/identity → capability matrix → migration/quarantine → round-trip evidence → bounded acceptance. مسیر باتجربه می‌تواند تعریف‌های ابتدایی را سریع‌تر طی کند، ولی stable ID، integrity، rights/provenance، negative states و transfer را حذف نمی‌کند.

شاهد ورود: برای یک درس فرضی، یک canonical resource و یک derived rendering نام ببرید و توضیح دهید چرا موفقیت rendering، سلامت canonical package را ثابت نمی‌کند.

مدل ذهنی: portability یک round trip با قرارداد هویت است

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

canonical structured source → versioned MCB manifest → stable IDs + digests + rights/provenance → adapter/export profile → target capability check → IMPORT / MIGRATE / QUARANTINE / REJECT → isolated import → re-export → deterministic semantic diff → bounded review/acceptance

سه boundary را قاطی نکنید. Canonical boundary می‌گوید چه چیزی source of truth است. Transport boundary می‌گوید چه resourceهایی با چه manifest/profileای منتقل می‌شوند. Target capability boundary می‌گوید مقصد کدام semantics را واقعاً می‌فهمد. ZIP فقط ظرف transport است.

1EdTech Common Cartridge یک مجموعه استاندارد باز برای interoperability بین منابع یادگیری و platformهاست و برای package/exchange و import/export مواد آموزشی استفاده می‌شود. در صفحهٔ فعلی Common Cartridge، پروفایل 1.4 با LTI 1.3/LTI Advantage و QTI 3 توصیف شده است. این FACT به ما یک adapter profile می‌دهد؛ اما تعیین نمی‌کند canonical model داخلی MAKNOW چیست یا آیا هر target semantics را کامل حفظ می‌کند. Common Cartridge

MKN-030-F1 — بازیابی مرز: در یک جمله تفاوت «archive قابل‌انتقال» و «semantic portability» را بنویسید و یک non-goal درس را نام ببرید.

حداقل قرارداد داده‌ای: manifest فقط فهرست فایل نیست

Content Packaging در 1EdTech ساختارهایی برای exchange/import/export/aggregation بسته‌های محتوا تعریف می‌کند و manifest ساختار و resourceها را توصیف می‌کند. در MCB از این ایده استفاده می‌کنیم، اما schema و policy دقیق MCB authority محلی MAKNOW است. 1EdTech Content Packaging

fieldهای اصلی این درس در چهار گروه‌اند:

1. Package identity: package_id, package_format_version, manifest_version, canonical_content_ref, exporter_version.
2. Resource identity/integrity: resource_id, resource_type, resource_schema_version, resource_path, content_digest, dependency_ref.
3. Rights/provenance/capability: rights_ref, provenance_ref, source_snapshot_ref, target_capability_profile, importer_version, compatibility_state, migration_rule_ref, unsupported_feature_state, quarantine_reason.
4. Round trip/review: round_trip_baseline_digest, round_trip_result_digest, semantic_diff_ref, validation_state, review_owner, audit_event_id.

resource_id هویت منطقی resource را نگه می‌دارد؛ path فقط location در package است. اگر importer path را عوض کند، ممکن است هنوز portability قابل‌اثبات باشد؛ اما اگر ID را عوض کند و referenceهای localization/evidence دیگر resolve نشوند، identity شکسته است. content_digest نیز proof of meaning نیست، ولی حداقل ثابت می‌کند همان bytes مورد انتظار بررسی شده‌اند.

وضعیت‌های غیرموفق بخشی از قراردادند. UNSUPPORTED یعنی target capability ندارد؛ QUARANTINED یعنی payload را حفظ می‌کنیم ولی آن را به semantics دیگری جعل نمی‌کنیم؛ UNKNOWN یعنی evidence کافی نیست؛ HOLD یعنی تصمیم نهایی متوقف می‌شود. حذف این stateها معمولاً «success» ظاهری می‌سازد.

capability matrix قبل از import، semantic diff بعد از import

قبل از import برای هر resource سه سؤال بپرسید: این resource چیست؟ target چه capabilityای دارد؟ اگر مستقیم قابل‌پشتیبانی نیست، migration مجاز و traceable داریم یا باید quarantine شود؟

مثلاً baseline این درس یک QTI assessment، LTI tool link، media، localization و یک maknow_custom_block دارد. target اول Common Cartridge 1.4/QTI 3/LTI 1.3 را پشتیبانی می‌کند اما custom block را نمی‌شناسد. تصمیم درست برای آن resource «به متن ساده تبدیلش کن تا خطا ندهد» نیست. اگر migration rule تأییدشده نداریم، state باید QUARANTINED بماند و دلیل آن ثبت شود.

QTI برای exchange محتوای item/test و نتایج بین authoring tools، item banks، learning platforms و assessment systems تعریف شده است. وجود QTI در package، evidence خوبی برای profile است؛ اما import موفق QTI هنوز prove نمی‌کند که scoring/presentation semantics یا همه extensionها در target حفظ شده‌اند. QTI Specification Documents

بعد از import، round-trip evidence بسازید: resource را از محیط isolated دوباره export کنید، stable ID را bind کنید، semantic digest/normalized representation را مقایسه کنید و diff را طبقه‌بندی کنید. Path rewrite می‌تواند harmless باشد اگر identity و normalized semantics ثابت بمانند؛ silent flattening harmless نیست، حتی اگر فایل باز شود.

migration_rule_ref نیز shortcut نیست. migration باید versioned، explicit و قابل‌ردیابی باشد. اگر resource unsupported است و هیچ rule معتبر ندارید، MIGRATE انتخاب نکنید. کمبود rule → QUARANTINE/HOLD، نه حدس.

MKN-030-F2 — تشخیص منفی: اگر assessment-qti-01 از manifest حذف شود اما lesson-core هنوز به آن dependency داشته باشد، کدام evidence dimension می‌شکند و کوچک‌ترین repair چیست؟

مثال حل‌شده ۱: baseline با یک block unsupported

در fixtures/baseline.json شش resource داریم: core lesson، media، QTI assessment، LTI tool link، ترجمهٔ فارسی و یک custom block. manifest همه را با stable ID، path، digest، rights و provenance ثبت می‌کند. target قابلیت‌های core/media/QTI3/LTI1.3/localization را دارد اما custom block را ندارد.

پنج resource اول IMPORT_COMPATIBLE هستند. custom block به‌جای flatten شدن QUARANTINED می‌شود و payload آن برای review نگه داشته می‌شود. dependencyها کامل‌اند، digestها match می‌کنند و round-trip normalized semantics برای resourceهای import‌شده بدون تغییر است. چون یک semantic capability هنوز quarantine شده و review owner باید تصمیم migration/retention بگیرد، verdict بسته REVIEW_REQUIRED است؛ نه FULL_IMPORT_SUCCESS.

جدول کامل machine-readable در derived_text/tables/MKN-030-T1.csv است.

مثال حل‌شده ۲: digest قدیمی با content جدید

در stale_digest.json bytes canonical resource عوض شده‌اند اما manifest هنوز digest قبلی را حمل می‌کند. importer ممکن است فایل را باز کند؛ این هیچ اهمیتی ندارد. integrity binding شکسته و verdict HOLD است. repair حداقلی: source snapshot درست را دوباره freeze کنید، digest جدید را محاسبه کنید، manifest را version کنید و round-trip evidence را از نو بسازید؛ نه اینکه check digest را خاموش کنید.

Failure Modeهای رایج

ZIP-success fallacy. archive extract می‌شود و importer exit code صفر می‌دهد، پس «همه‌چیز portable است». Repair: capability matrix + semantic round trip.

Silent flattening. unsupported block به text/HTML تبدیل می‌شود بدون اینکه semantics loss ثبت شود. Repair: unsupported state را typed نگه دارید و بدون migration rule به QUARANTINED بروید.

Dangling dependency. resource حذف می‌شود اما manifest/reference هنوز به آن متکی است. Repair: dependency closure را قبل از import validate کنید.

Stable ID rewrite. importer ID جدید می‌سازد و evidence/localization linkها resolve نمی‌شوند. Repair: identity mapping فقط با rule صریح؛ rewrite خاموش blocker است.

Digest theater. digest روی فایل اشتباه، snapshot قدیمی یا derived rendering گرفته می‌شود. Repair: digest را به canonical_content_ref و source snapshot bind کنید.

Rights/provenance omission. technical compatibility وجود دارد ولی اجازه/منشأ resource قابل‌اثبات نیست. Repair: evidence ناقص را UNKNOWN/HOLD نگه دارید؛ compatibility مجوز حقوقی ایجاد نمی‌کند.

Round-trip byte equality as semantics. یا برعکس: path/zip timestamp فرق می‌کند و به‌اشتباه semantic drift اعلام می‌شود. Repair: normalized semantic representation را از transport noise جدا کنید.

پل برای باتجربه‌ها: package را مثل protocol boundary ببینید

اگر با API versioning، database migration یا compiler IR آشنا هستید، این درس را مثل یک protocol boundary ببینید. canonical model شبیه domain model/IR است؛ Common Cartridge/QTI adapter شبیه wire format است؛ target capability profile شبیه negotiated protocol capabilities؛ quarantine شبیه حفظ payload ناشناخته بدون pretending support.

این analogy یک محدودیت دارد: learning content فقط syntax نیست. ممکن است parser موفق باشد اما accessibility، scoring، instructional relationship یا human-authored intent تغییر کرده باشد. بنابراین semantic diff و review را نمی‌توان صرفاً با schema validation جایگزین کرد.

برای fast path تعریف‌ها را کوتاه کنید و مستقیماً از سه artifact دفاع کنید: manifest، compatibility matrix و round-trip ledger. اما باید نشان دهید چرا stable identity و explicit non-success states هزینهٔ بیشتری دارند و در عوض false confidence را کم می‌کنند.

Alternatives و trade-offها

Canonical = Common Cartridge. ساده به‌نظر می‌رسد اما model داخلی شما را به capability یک export profile محدود می‌کند. MCB در این درس canonical source را مستقل نگه می‌دارد و CC/QTI را adapter profile می‌گیرد.

Export-only interoperability. package تولید می‌کنید و validation اولیه را می‌گذرانید، ولی هیچ target round trip ندارید. هزینه کم‌تر است، اما silent loss را نمی‌بینید.

Lossy migration by default. نرخ import ظاهراً بالا می‌رود؛ auditability و learner meaning ضعیف می‌شود. Quarantine سخت‌گیرانه‌تر است اما loss را visible نگه می‌دارد.

Hash everything, review nothing. integrity قوی می‌شود ولی semantic correctness اثبات نمی‌شود. Digest، schema و review complementary هستند.

Platform-specific canonical. استفاده از مدل vendor سرعت اولیه می‌دهد اما portability و exit cost را افزایش می‌دهد. این lesson universal abstraction را اجبار نمی‌کند؛ فقط authority boundary و adapter mapping را explicit می‌کند.

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

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

1. fixtures/baseline.json را باز کنید و package_id, manifest version و canonical ref را ثبت کنید.
2. برای هر resource، digest، dependency، rights و provenance را بررسی کنید.
3. capabilityهای target را با required_capability resourceها مقایسه کنید.
4. custom block را بدون migration rule به QUARANTINED ببرید؛ آن را import-success جعل نکنید.
5. round-trip normalized semantic digest resourceهای import‌شده را بررسی کنید.
6. evidence/decision.template.json را پر کنید و اجرا کنید:

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

checker ساختار و invariantهای deterministic را بررسی می‌کند؛ کیفیت rationale را certify نمی‌کند.

تمرین مستقل

transfer/transfer_fixture.json target دیگری دارد که profile قدیمی‌تر و path rewrite دارد. verdict baseline را کپی نکنید. capability compatibility را از target جدید بسازید؛ path rewrite را از ID rewrite جدا کنید؛ resourceهای unsupported را migrate/quarantine کنید فقط اگر rule evidence دارید؛ سپس round-trip semantic evidence را دوباره محاسبه کنید.

MKN-030-F3 — Transfer: توضیح دهید چرا path rewrite لزوماً portability failure نیست، اما resource-ID rewrite بدون mapping rule می‌تواند failure باشد.

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

حداقل evidence package باید package/profile version، canonical ref، stable resource IDs، schema versions، paths، content digests، dependencies، rights/provenance، exporter/importer versions، target capability profile، compatibility/migration/quarantine states، round-trip baseline/result digest، semantic diff، validation state، review owner و audit event را نشان دهد.

Producer tests baseline و negative caseها را جدا اجرا می‌کنند: missing dependency، stale digest، silent flattening، rewritten ID، missing evidence و migration بدون rule. learner فقط rules و fixtureهای visible را دارد؛ oracle داخلی در مسیر learner publish نمی‌شود.

Fail closed: اگر evidence تعیین‌کننده missing باشد، state مثبت نسازید. UNKNOWN در dimension و HOLD در package decision بهتر از موفقیت ساختگی است. همچنین QUARANTINED شکست سیستم نیست؛ یک state صادقانه برای semantics unsupported است.

Round-trip ledger باید transport noise را از semantic change جدا کند. تغییر zip timestamp یا path به‌تنهایی کافی نیست؛ stable ID، normalized semantic digest و mapping evidence تعیین می‌کنند آیا meaning قابل‌ردیابی مانده است.

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

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

• S1 — Retrieval: مرز Portable Content Package architecture و یک non-goal را توضیح دهید.
• S2 — Application: artifact کامل baseline را از fixture بسازید.
• S3 — Diagnosis: حذف resource لازم در حالی که dependency manifest باقی است را تشخیص دهید.
• S4 — Transfer: target قدیمی‌تر با path rewrite را مستقل تحلیل و compatibility/migration/quarantine/round-trip state را دوباره بسازید.

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

آزمون independence از baseline: اگر label REVIEW_REQUIRED از مثال اول حذف شود، باید هنوز بتوانید تصمیم transfer را فقط از fixture و rules بازسازی کنید. «چون مثال قبلی همین بود» reasoning محسوب نمی‌شود.

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

سه منبع رسمی لایهٔ FACT را پشتیبانی می‌کنند:

1. 1EdTech Common Cartridge — interoperability و package/import/export؛ نه canonical authority داخلی MAKNOW یا تضمین preservation روی هر LMS.
2. 1EdTech Content Packaging — package structure و manifest/resource transport؛ نه proof of semantic equivalence.
3. QTI Specification Documents — interchange assessment item/test content/results؛ نه تضمین اینکه هر target همهٔ semantics/extensions را حفظ می‌کند.

این منابع در 2026-09-13 دوباره بررسی شدند. Common Cartridge 1.4 در صفحهٔ فعلی 1EdTech با LTI 1.3/LTI Advantage و QTI 3 بیان شده است؛ QTI page نیز QTI 3 را به‌عنوان مسیر جاری specification نشان می‌دهد. ادعاهای practice-evolving باید تا 2027-01-15 یا زودتر در صورت تغییر material در profile/spec دوباره qualify شوند. lesson پذیرفته‌شده درجا rewrite نمی‌شود؛ update باید versioned باشد.

پرسش پایانی: در pipeline فعلی شما کدام shortcut بیشترین false confidence می‌سازد—ZIP success، silent flattening، digest ضعیف، ID rewrite یا round-trip ناقص—و کدام field دقیقاً آن را آشکار می‌کند؟