Portfolio Control و Creator Marketplace Awareness

یک پیشنهاد رشد، اما دو تصمیم مستقل

فرض کنید یک پلتفرم آموزشی می‌تواند خروجی‌های یادگیرنده را export کند و تعدادی از سازندگان را به‌صورت دستی در صفحه‌ی معرفی نمایش دهد. اکنون یک پیشنهاد واحد روی میز است: «یک Portfolio Control بسازیم و همان را به Creator Marketplace تبدیل کنیم.» این جمله دو مسئله‌ی متفاوت را در یک feature ادغام می‌کند.

Portfolio Control مسئله‌ی provenance، version، approval و promotion governance است: این‌که یک artifact از کجا آمده، کدام revision معتبر است، چه کسی آن را تأیید کرده و کدام نسخه اجازه‌ی نمایش یا promotion دارد. Creator Marketplace یک لایه‌ی اقتصادی و عملیاتی دیگر اضافه می‌کند: آیا creator supply و buyer demand واقعاً دوطرفه‌اند؟ آیا transaction need وجود دارد؟ payment و payout را چه کسی اداره می‌کند؟ rights evidence، moderation، dispute handling، fraud/trust و support owner کجاست؟

W3C PROV provenance را اطلاعات مربوط به entity، activity و agentهای درگیر در تولید یک داده یا چیز توصیف می‌کند؛ این مدل می‌تواند origin و derivation را صریح کند. [W3CPROV] این FACT به ما اجازه نمی‌دهد سیاست promotion یا approval در MAKNOW را از W3C استخراج کنیم. در سمت دیگر، Stripe Connect جریان‌های marketplace/platform و connected account را برای پرداخت توضیح می‌دهد. [STRIPECONNECT] وجود این capability به‌تنهایی creator demand، rights readiness، moderation capacity یا viability را ثابت نمی‌کند.

خروجی عملی این درس Portfolio/Creator Marketplace Control Decision Record v1 است. این artifact باید دو decision مستقل داشته باشد: PORTFOLIO_CONTROL و CREATOR_MARKETPLACE. وضعیت‌های مجاز عبارت‌اند از USE، PILOT، NOT_NOW، UNKNOWN، EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED، HOLD، PARTIAL و DISPUTED. هیچ evidence ناقصی نباید با «احتمالاً خوب است» به USE یا PILOT تبدیل شود.

زمان فعال برنامه‌ریزی‌شده: ۴۵ دقیقه.

این درس برای کسی است که باید میان کنترل داخلی portfolio و راه‌اندازی یک marketplace تراکنشی تصمیمی قابل ممیزی بسازد، نه برای کسی که صرفاً دنبال نام یک ابزار یا vendor است.

این درس marketplace زنده launch نمی‌کند، payout واقعی انجام نمی‌دهد، قرارداد حقوقی تولید نمی‌کند، production data را تغییر نمی‌دهد و outcome درس‌های AWR-005 یا AWR-007 را جذب نمی‌کند.

پیش‌نیاز HARD — AWR-005

پیش از ادامه، در یک جمله boundary مرتبط از AWR-005 را بنویسید: «کدام capability بیرونی یا معماری مجاور، بدون evidence محلی و owner مشخص، authority برای adoption در این درس ایجاد نمی‌کند؟» سپس یک non-goal از AWR-005 را نام ببرید که نباید وارد Portfolio/Marketplace decision شود. اگر نمی‌توانید هر دو را روشن بگویید، Fast Path برای شما باز نیست.

پل محدود: فقط این قاعده را بازیابی کنید و ثبت کنید: «capability یا رشد، به‌خودی‌خود trigger adoption نیست؛ تصمیم باید به problem، measured evidence، owner، cost/risk و boundary متصل باشد.» این bridge تکمیل AWR-005 را جعل نمی‌کند و نتیجه‌ی آن درس را جایگزین نمی‌کند؛ فقط حداقل evidence لازم برای ورود به AWR-006 را فراهم می‌کند.

پیش از طراحی، تشخیص دهید چه چیزی واقعاً کم است

به چهار پرسش پاسخ دهید:

1. تعداد portfolio artifactها سه برابر شده، اما revisionها مشخص، provenance قابل ردیابی و promotion هنوز کم‌حجم است. آیا صرف volume، Portfolio Control جدید را USE می‌کند؟
2. هزار creator پروفایل دارند، اما buyer request فقط چند مورد در ماه است. آیا creator supply زیاد، marketplace تراکنشی را توجیه می‌کند؟
3. پلتفرم payment API و connected account دارد. آیا همین FACT، rights، moderation، dispute owner و fraud control را هم اثبات می‌کند؟
4. buyer demand قوی شده، اما rights evidence برای بخش مهمی از آثار ناقص است. آیا marketplace می‌تواند مستقیم USE شود؟

۴ پاسخ درست از ۴ → مسیر سریع. ۲ تا ۳ → مسیر اصلاح. ۰ تا ۱ → مسیر پایه. مسیر سریع فقط تعریف‌های مقدماتی را فشرده می‌کند؛ evidence bar، negative cases و transfer کم نمی‌شوند.

خودسنجی route: «portfolio governance» را با «marketplace economics» یکی نکنید؛ creator count را buyer demand فرض نکنید؛ payment capability را business readiness ندانید؛ و NOT_NOW را failure تلقی نکنید.

مدل ذهنی: دو محور، دو زنجیره‌ی evidence

جریان اول:

PORTFOLIO_CONTROL → provenance/version gap → approval/promotion need → owner + operational cost → simpler control → bounded state

جریان دوم:

CREATOR_MARKETPLACE → creator supply + buyer demand + transaction need → payment/payout → rights → moderation/disputes → trust/fraud → owner + cost → simpler alternative → bounded state

این ترتیب یک نکته‌ی کلیدی دارد: marketplace extension طبیعیِ portfolio نیست. ممکن است Portfolio Control USE باشد چون هزاران revision و promotion request باید کنترل شوند، در حالی که Creator Marketplace NOT_NOW بماند چون buyer demand یا transaction frequency هنوز پایین است.

سه لایه‌ی authority را جدا نگه دارید:

اگر visual flow در دسترس نبود، همین ترتیب متنی جایگزین کامل asset://AWR-006/AWR-006-ASSET-FLOW است.

پایه‌ها: برای هر محور چه evidenceای لازم است؟

PORTFOLIO_CONTROL

حداقل این فیلدها را روشن کنید:

• problem: مسئله‌ی کنترل چیست و چرا این محور باید جداگانه ارزیابی شود؟
• portfolio_object: چه چیزی کنترل می‌شود؟ پروژه، فایل، مدل، خروجی یا مجموعه؟
• revision_id: کدام revision موضوع تصمیم است؟
• provenance_ref: origin/derivation با چه referenceای قابل ردیابی است؟
• approval_state: چه وضعیتی برای review/approval ثبت شده است؟
• promotion_need: چه نیاز واقعی برای controlled promotion وجود دارد؟
• operational_owner: چه نقش مشخصی governance را اداره می‌کند؟
• operational_ownership_cost: هزینه‌ی اداره، review، metadata maintenance یا escalation چیست؟ قیمت واقعی اختراع نکنید؛ cost class و burden را صریح کنید.
• simpler_alternative: آیا metadata/versioning موجود، manual curation یا یک approval queue ساده‌تر کافی است؟
• decision_state، rationale، review_due و evidence_ref.

W3C PROV entity/activity/agent و origin/derivation را برای provenance مدل می‌کند. [W3CPROV] اما این مدل نمی‌گوید کدام artifact باید promoted شود؛ promotion rule و approval authority در این درس DESIGN هستند.

CREATOR_MARKETPLACE

حداقل این فیلدها را روشن کنید:

• problem: مسئله‌ی دوطرفه/تراکنشی چیست که قرار است با این محور سنجیده شود؟
• creator_count و کیفیت supply: چند creator واقعاً آماده‌ی عرضه‌اند؟
• buyer_demand: درخواست خریدار چقدر و با چه شواهدی است؟
• transaction_frequency: آیا تقاضا تکرارشونده است یا چند درخواست موردی؟
• marketplace_role: پلتفرم directory، referral، broker یا facilitator پرداخت است؟
• payment_flow: پول از چه مسیری عبور می‌کند؟
• payout_owner: چه roleای payout/reconciliation را اداره می‌کند؟
• platform_fee_model: اگر fee مطرح است، مدل آن چیست؟ این درس fee واقعی یا advice حسابداری تولید نمی‌کند.
• creator_onboarding: چه evidenceای برای onboarding لازم است؟
• rights_evidence: آیا حق عرضه/فروش/نمایش قابل اثبات است؟
• moderation_owner و dispute_owner: چه کسی محتوا و اختلاف را مدیریت می‌کند؟
• fraud_risk و trust_signal: چه ریسک و سیگنال اعتمادی دیده می‌شود؟
• simpler_alternative: directory، referral workflow یا invite-only pilot چه مقدار از demand را بدون transaction layer پاسخ می‌دهد؟
• operational_owner و operational_ownership_cost.
• decision_state، rationale، review_due و evidence_ref.

Stripe Connect capability جریان marketplace/platform payment را توضیح می‌دهد. [STRIPECONNECT] این fact جای demand evidence، rights evidence یا owner evidence را نمی‌گیرد.

ساخت Portfolio/Creator Marketplace Control Decision Record v1

گام ۱ — دو decision row مستقل بسازید

PORTFOLIO_CONTROL و CREATOR_MARKETPLACE را در یک maturity score ادغام نکنید. اگر یکی شواهد کافی دارد و دیگری ندارد، نتیجه‌ها باید متفاوت باشند.

گام ۲ — Portfolio gap را با provenance و version evidence ببندید

اگر artifactها revision دارند اما origin، approval یا promotion history قابل بازسازی نیست، مشکل واقعی قابل تعریف است. اگر همین اطلاعات در ابزار فعلی با هزینه‌ی کم و owner روشن موجود است، ساخت control layer جدید ممکن است NOT_NOW باشد. تعداد artifact به‌تنهایی کافی نیست.

گام ۳ — Marketplace trigger را دوطرفه بسنجید

creator supply فقط نیمه‌ی مسئله است. buyer demand و transaction need باید جداگانه ثبت شوند. «creator زیاد است» نمی‌تواند جای «buyer درخواست تکرارشونده دارد» بنشیند.

گام ۴ — capability را از responsibility جدا کنید

payment flow فقط یکی از gateهاست. قبل از وضعیت مثبت marketplace باید rights، payout ownership، moderation، dispute handling، trust/fraud و operational support قابل دفاع باشند. اگر owner گم است، OWNER_MISSING از یک success state صادقانه‌تر است.

گام ۵ — simpler alternative را واقعاً مقایسه کنید

برای Portfolio Control، یک approval queue یا metadata/version discipline ممکن است کافی باشد. برای Marketplace، directory، referral یا invite-only pilot باید قبل از full transaction layer بررسی شوند. این قاعده یک تصمیم DESIGN در MAKNOW برای جلوگیری از complexity زودرس است و نباید به‌عنوان FACT بیرونی خوانده شود.

گام ۶ — state را از evidence قوی‌تر نکنید

NOT_NOW وقتی trigger وجود ندارد تصمیم معتبر است. اگر trigger ممکن است وجود داشته باشد اما rights یا owner هنوز معلوم نیست، از EVIDENCE_INCOMPLETE، OWNER_MISSING، REVIEW_REQUIRED، HOLD، PARTIAL یا DISPUTED استفاده کنید. missing evidence را به NOT_NOW تقلیل ندهید اگر مسئله این است که هنوز نمی‌دانید.

گام ۷ — review/stop/pivot trigger را بنویسید

تصمیم باید بگوید چه چیزی آن را دوباره باز می‌کند: افزایش measurable buyer requests، تغییر transaction frequency، تکمیل rights evidence، تغییر payout ownership، افزایش dispute load، failure در provenance، یا اثبات این‌که simpler alternative دیگر core demand را پاسخ نمی‌دهد.

مثال حل‌شده: Portfolio نیاز دارد، Marketplace هنوز نه

این مثال از fixture آزمایشگاه جداست و پاسخ Lab را از پیش پر نمی‌کند.

پلتفرم مصنوعی SYNTH-CREATOR-B حدود ۲۴۰۰ artifact با revisionهای متعدد دارد. تیم editorial هر هفته چندین درخواست برای feature کردن کارهای منتخب دریافت می‌کند و در وضعیت فعلی، trace کردن این‌که کدام revision approved شده و چرا promoted شده دشوار است. یک provenance_ref منسجم، approval state و owner مشخص برای review وجود ندارد. یک workflow کنترل‌شده با metadata و approval queue می‌تواند مسئله‌ی واقعی را حل کند. اگر این control با هزینه‌ی اداره‌ی روشن و owner مشخص پیاده شود، Portfolio Control می‌تواند تا PILOT یا USE پیش برود؛ state نهایی به evidence مورد واقعی وابسته است.

در همان پلتفرم، ۳۲۰ creator فعال وجود دارد اما buyer request در سه ماه گذشته فقط ۹ مورد بوده و transaction frequency پایدار نیست. payment integration از نظر فنی ممکن است، ولی یک مجموعه‌ی معنادار از rights evidence ناقص است و moderator اختصاصی برای marketplace تعریف نشده. full marketplace در این وضعیت نباید از capability فنی نتیجه‌گیری شود. directory یا invite-only referral می‌تواند تقاضا را اندازه‌گیری کند؛ NOT_NOW یا یک PILOT غیرتراکنشی می‌تواند bounded‌تر باشد.

این جدول source spec مربوط به asset://AWR-006/AWR-006-ASSET-TABLE را به‌صورت متنی حفظ می‌کند.

shortcutهایی که false confidence می‌سازند

1. portfolio volume → marketplace: تعداد artifact یا creator، buyer demand را ثابت نمی‌کند.
2. payment capability → launch: payment flow بدون rights، moderation، disputes و owner فقط یک capability است.
3. strong demand → ignore rights: buyer demand قوی، نبود rights evidence را پاک نمی‌کند؛ state باید non-success بماند تا evidence کامل شود.
4. payment + no operations owner: اگر payout، moderation یا dispute owner مشخص نیست، success state قابل دفاع نیست.
5. one combined verdict: Portfolio Control ممکن است USE باشد در حالی که Marketplace NOT_NOW است. یک verdict مشترک این تفاوت را مخفی می‌کند.
6. NOT_NOW = شکست: اگر measurable trigger وجود ندارد، NOT_NOW دقیقاً نشان می‌دهد complexity زودرس رد شده است.
7. missing evidence = NOT_NOW: نبود trigger با ندانستن trigger فرق دارد. اگر evidence تصمیم‌ساز ناقص است، UNKNOWN، EVIDENCE_INCOMPLETE یا HOLD مناسب‌تر است.
8. vendor docs = MAKNOW policy: W3C و Stripe mechanism/capability fact می‌دهند؛ threshold و adoption state در MAKNOW DESIGN هستند.

counterexample اجباری: buyer demand را بالا ببرید اما rights_evidence را حذف کنید. اگر تصمیم marketplace همچنان USE یا PILOT ماند، evidence contract شکسته است.

Experienced bridge: دو state machine را به هم قفل نکنید

برای learner باتجربه، تعریف‌ها را کوتاه کنید و روی state transitionها تمرکز کنید.

Portfolio state machine می‌تواند از NOT_NOW به PILOT یا USE فقط وقتی حرکت کند که provenance/version/promotion problem و owner/cost آن روشن باشد. Marketplace state machine باید جداگانه two-sided demand، transaction need، payment/payout، rights، moderation/dispute، trust/fraud و owner را بررسی کند.

تمرین دفاع: فرض کنید Portfolio Control USE شده است. بدون استفاده از این status به‌عنوان shortcut، از صفر توضیح دهید چه evidenceای برای تغییر Marketplace از NOT_NOW به PILOT لازم است. سپس یک stop condition نام ببرید که pilot را دوباره به HOLD برگرداند. اگر پاسخ شما فقط «چون portfolio آماده است» باشد، دو state machine را به اشتباه coupling کرده‌اید.

trade-offها: complexity را فقط وقتی بخرید که مسئله را حل کند

برای Portfolio Control سه سطح را مقایسه کنید: discipline در metadata/versioning موجود، approval queue محدود، و control layer کامل‌تر. گزینه‌ی ساده‌تر هزینه‌ی integration و governance کمتری دارد، اما شاید searchability، audit trail یا promotion volume را در مقیاس بعدی پاسخ ندهد.

برای Creator Marketplace نیز directory/referral، invite-only pilot و full transactional marketplace سه سطح متفاوت‌اند. full marketplace flexibility و transaction capture بیشتری می‌دهد، اما payout/reconciliation، rights, moderation, disputes, fraud/trust, support و operational ownership را هم اضافه می‌کند. اگر demand هنوز کم است، این هزینه‌ها ممکن است جلوتر از مسئله باشند.

هیچ winner دائمی وجود ندارد. decision record باید بگوید کدام alternative در constraint فعلی بهتر است و چه triggerی انتخاب را تغییر می‌دهد.

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

آزمایشگاه lab://AWR-006/AWR-006-LAB1 یک fixture کاملاً synthetic و offline دارد. starter هیچ verdict نهایی را prefill نمی‌کند. شما باید evidence record را برای دو axis بسازید و checker فقط exact fixture binding و consistency ruleهای قابل‌مشاهده را بررسی می‌کند؛ hidden answer key وجود ندارد.

ترتیب کار:

1. baseline fixture را بخوانید و هر دو axis را مستقل ثبت کنید.
2. mutation «portfolio volume بالا می‌رود اما buyer demand بالا نمی‌رود» را اجرا کنید؛ فقط axis متأثر را recompute کنید.
3. mutation «buyer demand قوی می‌شود اما rights evidence حذف می‌شود» را اجرا کنید؛ success state marketplace مجاز نیست.
4. mutation «payment capability اضافه می‌شود اما moderation/dispute owner وجود ندارد» را اجرا کنید.
5. mutation «full marketplace با invite-only referral جایگزین می‌شود» را بررسی کنید و بنویسید آیا core demand هنوز پاسخ می‌گیرد.
6. missing-decisive-evidence fixture را اجرا کنید؛ checker باید HOLD/UNKNOWN/EVIDENCE_INCOMPLETE/PARTIAL یا state متناسب دیگری را بپذیرد و success state را رد کند.
7. transfer fixture را جداگانه از baseline بسازید؛ baseline verdict oracle نیست.

AI می‌تواند evidence عرضه‌شده را مرتب کند یا deterministic check را اجرا کند، اما حق ندارد owner، demand، rights، fee، trust یا approval را اختراع کند.

Verification: reviewer باید تصمیم را از evidence بازسازی کند

برای هر row این checklist را بررسی کنید:

• axis صریح و مستقل است؛
• evidence ref به fixture یا source visible برمی‌گردد؛
• Portfolio row revision/provenance/approval/promotion need را در صورت relevance نشان می‌دهد؛
• Marketplace row creator supply و buyer demand را جدا نگه می‌دارد؛
• transaction need، payment/payout، rights، moderation/disputes و trust/fraud گم نشده‌اند؛
• owner و operational/ownership cost قابل‌مشاهده‌اند؛
• simpler alternative واقعاً مقایسه شده است؛
• state از evidence قوی‌تر نیست؛
• missing evidence به success تبدیل نشده است؛
• review_due و stop/pivot trigger وجود دارد؛
• FACTها به [W3CPROV]/[STRIPECONNECT] محدودند و MAKNOW DESIGN به‌عنوان vendor fact عرضه نشده است.

اگر reviewer برای بازسازی نتیجه مجبور است «حدس بزند»، evidence package کافی نیست.

ارزیابی و transfer

Formative checkpointها:

• AWR-006-F1: boundary متعلق به درس و یک adjacent non-goal را توضیح دهید.
• AWR-006-F2: mutation افزایش portfolio volume بدون افزایش buyer demand را تشخیص دهید؛ field/state نامعتبر و repair path را بنویسید.
• AWR-006-F3: transfer case را بدون کپی baseline recompute کنید.

Summative:

• AWR-006-S1 مرز درس را می‌سنجد.
• AWR-006-S2 ساخت کامل Decision Record از baseline synthetic fixture را می‌سنجد.
• AWR-006-S3 تشخیص negative case را می‌سنجد.
• AWR-006-S4 transfer را می‌سنجد.

Transfer اجباری: یک پلتفرم دوم هزاران artifact versioned دارد و تقاضای قوی برای controlled promotion دیده می‌شود، اما فقط تعداد کمی buyer request وجود دارد. هر دو decision را از نو بسازید. Portfolio Control می‌تواند USE شود، در حالی که Marketplace با توجه به evidence واقعی NOT_NOW یا PILOT بماند. دلیل باید از changed evidence بیاید، نه از baseline verdict.

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

[W3CPROV] — W3C PROV Overview. برای مفهوم provenance، entity، activity، agent و derivation استفاده شده است. این منبع approval/promotion policy یا marketplace trigger در MAKNOW را تعیین نمی‌کند.

[STRIPECONNECT] — Stripe Connect Marketplace documentation. برای capability و responsibilityهای مربوط به platform/connected-account payment flow استفاده شده است. این منبع creator demand، rights readiness، moderation capacity یا viability را اثبات نمی‌کند.

منابع [W3CPROV] و [STRIPECONNECT] در تاریخ 2026-09-03 بازیابی شده‌اند و موعد بازبینی آن‌ها 2026-12-02 است. FACT بیرونی و MAKNOW DESIGN را در artifact جدا نگه دارید. اگر semantics مرتبط یک منبع پیش از موعد بازبینی به‌طور مادی تغییر کند، claimهای متأثر باید دوباره بررسی شوند؛ این درس فقط به claim limitهایی تکیه می‌کند که در همین بخش منابع توضیح داده شده‌اند.

عدم قطعیت‌ها را پنهان نکنید: fixtureهای synthetic رفتار production payment، payout، customer data یا live marketplace را ثابت نمی‌کنند؛ business constraints و owner policy نیز می‌توانند بدون تغییر fact بیرونی عوض شوند.