داستان‌سرایی فنی؛ از Story تا Evidence

داستان‌سرایی فنی یعنی ساختن یک View ترتیبی و قابل‌فهم از Claim و Evidence، به‌گونه‌ای که مخاطب بتواند از هر Scene به منبع، محدودیت و Unknown برگردد. داستان منبع حقیقت، اثبات علت یا ابزار گرفتن اعتماد نیست. این راهنما یک Story–Evidence Contract برای روایت باگ، Incident، معماری، داده و نتیجهٔ تست می‌سازد.

پاسخ کوتاه: Story Question را بنویسید؛ Source Snapshot را Freeze کنید؛ Start/Change/End را از Event order جدا نکنید؛ هر Scene را به Claim/Evidence وصل کنید؛ حذف، فشرده‌سازی زمان، شخصیت ترکیبی و نقل‌قول بازسازی‌شده را افشا کنید؛ تشبیه را با «کجا برقرار/کجا می‌شکند» محدود کنید؛ عدد را با مخرج/Baseline/Window نشان دهید؛ Resolution را با وضعیت واقعی و ریسک باقی‌مانده ببندید؛ و Raw Evidence/Correction route را همیشه در دسترس نگه دارید.

مالکیت این مقاله و مرز موضوع

این صفحه فقط مالک تبدیل زنجیرهٔ فنی به روایت برگشت‌پذیر است. متقاعدسازی در QA مالک اثرگذاری اخلاقی پیش از تصمیم، ارائهٔ نتایج تست مالک اجرای Presentation، و Chart Contract مالک نمودار و Visual QA است.

برای Evidence قابل‌بازتولید از گزارش باگ قابل‌بازتولید، برای پیام/Receipt از ارتباط در تست نرم‌افزار، برای تصمیم مدیریتی از Quality Decision Brief و برای Update از گزارش پیشرفت و مانع تست استفاده کنید. Story هیچ‌کدام را جایگزین نمی‌کند.

داستان View است، نه Evidence

روایت، انتخاب و ترتیب بخشی از واقعیت ثبت‌شده است. همین انتخاب می‌تواند فهم را آسان یا نتیجه را منحرف کند. هر Story باید به Snapshot منبع اشاره کند و مسیر `Scene → Claim → Evidence` داشته باشد. اگر مخاطب نتواند Narration را کنار بگذارد و دادهٔ پایه را ببیند، روایت قابل‌ممیزی نیست.

روایت خوب، پیچیدگی را لایه‌بندی می‌کند؛ حقیقت نامناسب برای قصه را حذف نمی‌کند.

پشتوانهٔ منابع و حد ادعا

راهنمای رسمی Government Analysis Function برای نوشتن دربارهٔ آمار Commentary خوب را متصل به یافتهٔ مهم، Context، دادهٔ زیربنایی و عدم‌قطعیت می‌داند و از مقایسهٔ جهت‌دار پرهیز می‌دهد. راهنمای کیفیت و عدم‌قطعیت نیز محدودیت را بخشی از پیام می‌داند، نه Footnote مزاحم.

استاندارد استفادهٔ عمومی از داده و تحلیل Cherry-pick، خارج‌کردن عدد از Context و قطعیت بیش از حد را گمراه‌کننده می‌شمارد. این منابع برای آمار/تحلیل عمومی نوشته شده‌اند، نه استاندارد اجباری Storytelling QA؛ اینجا فقط اصول Traceability، Context و عدم‌قطعیت اقتباس می‌شوند.

ادعاهای عصب‌شناختی را کنار بگذارید

این نسخه نمی‌گوید «مغز برای داستان تکامل یافته»، بوی قهوه قشر بویایی را فعال می‌کند یا هر روایت Oxytocin، عشق، اعتماد، همدلی و حافظهٔ بلندمدت می‌سازد. چنین نتیجه‌هایی به طراحی مطالعه، Population، Stimulus و Outcome وابسته‌اند و نسخهٔ عمومی برای هر Story فنی نیستند. فهم مخاطب باید مستقیماً آزمون شود.

چه زمانی Story مناسب نیست؟

برای Command دقیق، قرارداد API، جدول Truth، Proof، Runbook اضطراری یا Reproduction steps، ساختار مستقیم غالباً بهتر است. Story می‌تواند Orientation بدهد ولی Artifact اجرایی را نپوشاند. اگر ترتیب روایی باعث شود شرط، Exception یا Parallelism گم شود، از Diagram/Table/Procedure استفاده کنید.

نیاز	Artifact اصلی	نقش Story
اجرای دقیق	Procedure/Runbook	Orientation اختیاری
اثبات Claim	Evidence Pack	View قابل‌ردیابی
مقایسه	Table/Chart Contract	Context و takeaway محدود
تصمیم	Decision Brief	Sequence توضیحی
آموزش مدل ذهنی	Explanation + checks	ممکن است اصلی باشد

Story–Evidence Contract در یک نگاه

1. Story identity، Purpose، Audience و Decision را ثبت کنید.
2. Source Snapshot و Context فنی را Freeze کنید.
3. Claim، Evidence، Counterevidence، Unknown و Alternative را ببندید.
4. Story Question و Start/Change/End را از Event order استخراج کنید.
5. Scene Manifest با Claim/Evidence link بسازید.
6. Omission، Transition، Scale change و Time compression را افشا کنید.
7. Actor/Quote/Composite/Privacy و Analogy boundary را کنترل کنید.
8. عدد، Baseline، Denominator، Window و Range را حفظ کنید.
9. Resolution را با Actual status و Remaining risk محدود کنید.
10. Review، Comprehension، Raw evidence و Correction را ببندید.

Story identity و چرخه‌عمر

`StoryID`، version، status، supersedes، effective/review time را نگه دارید. وضعیت‌های نمونه: `DRAFT → EVIDENCE_REVIEW → AUDIENCE_REVIEW → PUBLISHED → CORRECTION_REQUIRED → SUPERSEDED → RETIRED`. Story قدیمی با عوض‌شدن Evidence یا Decision خودکار معتبر نمی‌ماند.

StoryID: STE-QA-021
Version: 1.2.0
Status: EVIDENCE_REVIEW
Supersedes: 1.1.0
Artifact: INCIDENT-SYN-07
EffectiveAtUTC: 2026-08-13T08:00:00Z
ReviewAtUTC: 2026-09-12T08:00:00Z

Purpose، Audience، Decision و Authority

آیا Story برای Orientation، آموزش، Explanation، Review یا Decision support است؟ Audience چه پیش‌دانشی دارد؟ کدام Decision ممکن است متاثر شود و Authority کیست؟ جذابیت روایت Authority تولید نمی‌کند. اگر Story فقط آموزش است، `decision=NONE` ثبت کنید.

Source Snapshot را Freeze کنید

Authority، Snapshot ID، `as_of`، Provenance، Population، Environment، Build، Data و Access class را ثبت کنید. Dashboard زنده یا Query متغیر مبنای Story پایدار نیست. تغییر Source باید Impact و Revision تازه بسازد.

SourceSnapshot: EP-SYN-044@3.1
AsOfUTC: 2026-08-13T07:30:00Z
Population: scenarios S01..S24
Environment: disconnected stub E-04
Build/Data: B-17 / D-09
Access: SYNTHETIC-INTERNAL
NotSource: live dashboard, memory, reconstructed quote

Claim Contract پیش از Plot

Story را با «چه قصهٔ جذابی داریم؟» شروع نکنید. Statement، type، scope، window، confidence و Not-claimed را بنویسید. Observation، association، hypothesis و causal claim قدرت متفاوت دارند. Plot نمی‌تواند Claim ضعیف را قوی کند.

Evidence، Counterevidence و Unknown

هر Claim باید Evidence refs، Fitness، Counterevidence، Unknown، Uncertainty و Alternative explanation داشته باشد. اگر یک Run با قصه سازگار و Run دیگر ناسازگار است، هر دو در Narrative boundary بیایند. Unknown را برای «پایان رضایت‌بخش» حذف نکنید.

Story Question به‌جای Moral ازپیش‌تعیین‌شده

پرسش نمونه: «چرا UI شکست را نشان داد ولی Ledger Commit ثبت کرد؟» Moral مانند «مستندسازی همیشه زمان Debug را نصف می‌کند» نتیجه را پیشاپیش تحمیل می‌کند. Story Question باید با Evidence قابل‌پیگیری باشد و امکان پاسخ «هنوز نمی‌دانیم» را حفظ کند.

Start، Change و End را دقیق تعریف کنید

Start state باید Snapshot و Context داشته باشد؛ Change رویداد/مداخلهٔ قابل‌مشاهده؛ End state وضعیت در Window محدود. «قبل بد بود، بعد خوب شد» بدون Baseline و Counterfactual Story است، Evidence اثر نیست. End ممکن است `UNKNOWN` یا `PARTIALLY_RESOLVED` باشد.

Event order و Presentation order

می‌توانید با Outcome شروع و سپس Flashback کنید، اما Event order واقعی را حفظ و Presentation order را افشا کنید. جابه‌جایی دو رخداد ممکن است علت را القا کند. Timestamp، Clock source و Zone را نگه دارید.

Scene Manifest بسازید

Scene	نقش	Claim	Evidence	Omission
S1	Start	CL-01	EV-03	other scenarios linked
S2	Change	CL-02	EV-07/08	12m compressed
S3	Interpretation	HY-01	EV-11	ALT-02 retained
S4	End	CL-04	EV-17	production unknown

Scene بدون Claim/Evidence ممکن است Transition یا Illustration باشد؛ همان‌طور برچسب بخورد. احساس، رنگ و Dialog نباید به آن Fact status بدهند.

Omission Register؛ آنچه نگفتید

روایت ناچار حذف می‌کند. موارد حذف‌شدهٔ مادی—Run ناموفق، Branch جایگزین، Warning، بازهٔ بدون داده—را با دلیل و لینک ثبت کنید. Omission غیرمادی لازم نیست Story را شلوغ کند؛ Reviewer دربارهٔ مادیت قضاوت کند، نه نویسنده به‌تنهایی.

Transition نباید علت جعل کند

واژه‌های «بنابراین»، «در نتیجه»، «باعث شد» و «به لطف» causal bridge هستند. اگر Evidence فقط ترتیب یا association نشان می‌دهد، از «پس از»، «هم‌زمان» یا «یکی از توضیح‌های ممکن» استفاده کنید. هر Transition مهم به Causal boundary وصل شود.

فشرده‌سازی زمان و تغییر Scale

«در چند لحظه» شاید ۴۵ دقیقهٔ Log review را حذف کند. Time compression، gap و montage را افشا کنید. پرش از یک Attempt به کل Release یا از Fixture به کاربران واقعی Scale change است و Claim تازه می‌خواهد.

قهرمان اجباری نیست

Process، State machine یا Evidence chain می‌تواند محور باشد. تبدیل یک مهندس به ناجی، نقش سیستم/تیم و Counterevidence را پنهان می‌کند. «API Call قهرمان» شاید برای Orientation مفید باشد، اما Agency و Intent انسانی به Packet نسبت ندهید.

Hero washing و Villain blame

موفقیت را به فرد محبوب و شکست را به «توسعه‌دهنده بی‌دقت» نسبت ندهید. Actor identity policy، نقش، انتخاب‌های قابل‌مشاهده و Context را جدا کنید. Privacy و Dignity برقرار بماند. داستان Incident ابزار ارزیابی عملکرد نیست.

شخصیت ترکیبی را افشا کنید

برای حفظ حریم خصوصی می‌توان چند نقش را Composite کرد، اما باید صریح گفت این شخصیت فرد واقعی واحد نیست و کدام جزئیات تغییر کرده‌اند. Composite برای ساختن Dialog یا Motive مطلوب مجاز نیست. اگر ترکیب، Attribution را مختل می‌کند، از نقش ناشناس استفاده کنید.

نقل‌قول واقعی، بازسازی‌شده و Fictional

نوع	برچسب	Evidence
Verbatim	نقل‌قول دقیق	منبع/رضایت/Context
Paraphrase	بازگویی	معنا + Reviewer
Reconstructed	بازسازی‌شده	نباید Quote mark واقعی بگیرد
Fictional	مثال ساختگی	هیچ ادعای رویداد واقعی

Intent را از ذهن Actor نخوانید

«او می‌دانست»، «تیم نگران شد» یا «کاربر اعتماد کرد» بدون Evidence ادعای ذهنی است. رفتار/پیام ثبت‌شده را بگویید یا آن را Interpretation محدود بنامید. Emotion برای Drama ساخته نشود.

تشبیه Model موقت است

Analogy باید Target، Mapping، بخش‌های برقرار، محل شکست، Test و Retirement داشته باشد. «Cache مثل کتابدار» در Lookup کمک می‌کند، اما TTL، invalidation، consistency، eviction، stampede و privacy را نمی‌پوشاند. مخاطب باید بداند کجا مدل را کنار بگذارد.

AnalogyID: ANA-CACHE-02
Target: read-through cache orientation
Maps: requested key → requested book; cache store → desk copy
Holds: repeated read may avoid origin lookup
Breaks: staleness, eviction, concurrency, invalidation, write path
Test: learner explains one break-case
RetireAt: implementation/configuration discussion

تشبیه را با سؤال خلاف آزمون کنید

بپرسید مخاطب بر اساس تشبیه چه پیش‌بینی غلطی ممکن است بکند. اگر «کتابدار همیشه نسخه درست دارد» برداشت شود، invalidation پنهان مانده است. Break-case را همان کنار مثال بیاورید، نه Footnote آخر.

عدد Story decoration نیست

۹۹٪ دقت بدون Dataset/Population/Class balance/Threshold/Window و Error cost معنای کافی ندارد. ۵۰٪ کاهش Debug time بدون Baseline، Sample و تغییرات همزمان علت را ثابت نمی‌کند. Denominator، Baseline، Unit، Absolute/relative، Range و Source را حفظ کنید.

Before/After دام علیت است

«بعد از کمپین منحنی رشد کرد، پس کمپین باعث رشد شد» Seasonality، Product change، Mix کاربران و Trend پایه را حذف می‌کند. Story می‌تواند ترتیب را بگوید و Alternativeها را نگه دارد؛ برای Causal claim طراحی معتبر جدا لازم است.

Resolution باید وضعیت واقعی باشد

`FIXED_IN_BUILD`، `MITIGATED`، `WORKAROUND`، `PARTIALLY_VERIFIED`، `UNKNOWN` یا `REOPENED` را به‌جای «قهرمان پیروز شد» ثبت کنید. Remaining risk، recurrence، scope و Next question را بیاورید. رفع یک Symptom پایان داستان سیستم نیست.

پایان باز شکست نیست

گاهی معتبرترین پایان «در Fixture بازتولید شد؛ Production prevalence و علت اصلی هنوز Unknown است» است. Resolution احساسی نباید Unknown را ببندد. مخاطب با پایان دقیق بهتر تصمیم می‌گیرد تا پایان رضایت‌بخش جعلی.

Moral را به Claim محدود تبدیل کنید

«همیشه مستندسازی کنید» یا «Microservice ما را برای رشد آماده کرد» تعمیم‌اند. Takeaway بهتر: «در Runهای R1..R6، حفظ Correlation ID زمان یافتن همین State mismatch را کاهش داد؛ انتقال به Production/سایر Incidentها آزموده نشده است.»

Data story باید Raw data route داشته باشد

Chart/جدول پایه، Query، Transform، Definition و Accessible alternative را لینک کنید. Axis start، Window selection و دو نقطهٔ مقایسه نباید برای Plot مطلوب انتخاب شوند. Narrative نباید توان تحلیل مستقل را از مخاطب بگیرد.

عدم‌قطعیت کنار Headline

اگر Headline می‌گوید «Failure کم شد»، همان‌جا بگویید estimate، range، window و محدودیت چیست. مخاطب ممکن است Appendix را نخواند. Uncertainty را برای حفظ «Flow» عقب نیندازید؛ آن را بخشی از Story design کنید.

Layered detail به‌جای حذف جزئیات

لایهٔ ۱: Question/limited takeaway؛ لایهٔ ۲: Scene و Evidence highlights؛ لایهٔ ۳: Contract/Chart/Table؛ لایهٔ ۴: Raw/reproducible artifacts. مخاطب می‌تواند عمق را انتخاب کند، اما مسیر لایه‌ها شکسته نباشد.

Plain language و Glossary

Actor/Action/State را روشن، Acronym را باز و Term فنی را به Glossary وصل کنید. ساده‌سازی نباید Modal، Exception یا Scope را حذف کند. داستان شاعرانه‌ای که Decision را مبهم می‌کند، ارتباط فنی نیست.

دسترس‌پذیری و RTL/LTR

نسخهٔ متنی برای Audio/Visual، Caption، جدول جایگزین Chart، Heading صحیح و ترتیب Keyboard فراهم کنید. شناسه‌ها/کد/زمان LTR در متن فارسی RTL isolate شوند. Color/Animation/Voice نباید تنها حامل فرق Scene یا Uncertainty باشند.

Fear theater و Emotion

Incident را با صدای Alarm، عکس کاربر درمانده یا Worst case بی‌احتمال بزرگ نکنید. Consequence واقعی با Probability/Exposure/Unknown بیان شود. Emotion مشاهده‌شده فقط با منبع و رضایت؛ Emotion ساختگی برای Persuasion ممنوع.

Story Review چهار نقش دارد

• Domain Reviewer: مدل/اصطلاح/Boundary فنی.
• Evidence Reviewer: Claim link، Counterevidence و عدد.
• Affected-party Reviewer: Privacy، Dignity و Misrepresentation.
• Audience Reviewer: Comprehension و برداشت غلط محتمل.

یک نفر می‌تواند چند نقش داشته باشد ولی Conflict افشا شود. Approval ساختاری به معنای حقیقت یا Outcome نیست.

Comprehension Check، نه جذابیت‌سنجی

نپرسید «داستان را دوست داشتید؟» بپرسید: Claim محدود چیست؟ چه چیزی Unknown است؟ تشبیه کجا می‌شکند؟ آیا Resolution Fix یا Mitigation بود؟ پاسخ غلط می‌تواند Story design را اصلاح کند؛ امتیاز فرد نیست.

Misinterpretation Probe

پیش از انتشار، سه برداشت خطرناک محتمل را بسازید: Causality بیش از Evidence، تعمیم Sample، یا قهرمان/مقصرسازی. اگر Story آن‌ها را تقویت می‌کند، Frame، Boundary یا Break-case اضافه کنید.

برچسب Real، Composite، Synthetic و Fictional

Story label باید نوع را در ابتدا بگوید. Synthetic fixture رویداد واقعی نیست؛ Fictional illustration Evidence نیست؛ Composite شخص واقعی واحد نیست. برچسب در Caption کوچک یا پایان مقاله کافی نیست.

Reuse policy؛ قصه از Context جدا نشود

Slide یا Quote ممکن است جدا بازنشر شود. StoryID/version، Context کوتاه، Source route و Expiry همراه Export بماند. استفادهٔ Marketing از Story داخلی، Purpose/Consent/Review تازه می‌خواهد.

Correction بدون بازنویسی خاموش

اگر Scene، عدد، Quote یا Transition غلط بود، نسخهٔ قبلی حفظ، Correction مشخص و تمام Reuseهای شناخته‌شده علامت‌گذاری شوند. Decision متأثر Reopen شود. «داستان برای سادگی بود» دفاع از تحریف مادی نیست.

Metricهای سالم Story

Claim-to-evidence coverage، disclosed-omission coverage، misunderstanding found، analogy break recall، correction latency، raw-route availability و expired-story reuse Signalهای مناسبی‌اند. جذابیت، خنده، مدت تماشا، اعتماد یا یادآوری را بدون طراحی معتبر به Story نسبت ندهید و افراد را امتیاز نکنید؛ `people_scoring=false`.

قالب کامل Story–Evidence Contract

[Identity] StoryID, Version, Status, Supersedes, Effective/Review
[Context] Product, Artifact, Purpose, Audience, Decision, Authority, Channel
[Source] Authority, Snapshot, AsOf, Provenance, Population, Env, Build, Data, Access
[Claim] Statement, Type, Scope, Window, Confidence, NotClaimed
[Evidence] Refs, Fitness, Counterevidence, Unknowns, Uncertainty, Alternatives
[Narrative] Question, Start, Change, End, SequenceBasis, CausalBoundary
[Scenes] Manifest, Claim/EvidenceLinks, Omissions, Transitions, ScaleChanges
[Actors] Identity, Composite, Quote, IntentBoundary, Privacy, Dignity
[Analogy] Target, Mapping, Holds, Breaks, Test, Retirement
[Numbers] Denominator, Baseline, Unit, Window, Absolute/Relative, Range, Source
[Time] EventOrder, PresentationOrder, Compression, Gaps, Zone
[Resolution] ActualStatus, RemainingRisk, Recurrence, NotVictory, NextQuestion
[Framing] NoFabrication/CherryPick/Fear/Hero/Villain/AuthorityLaundering
[Access] Plain, Glossary, TextAlternative, RTL-LTR, Layers, RawRoute
[Review] Domain, Evidence, AffectedParty, Comprehension, Misinterpretation, Approval
[Publication] Labels, Revision, Correction, Reuse
[Governance] Owner, Expiry, Audit, Retention, people_scoring=false, NotProof

آزمایشگاه آفلاین Checkout ایرانی

Fixture خیالی `SYN-STORY-EVIDENCE-۰۱` یک Checkout کاملاً جدا از شبکه/Production دارد: Order/PaymentAttempt جعلی، PSP Stub، Callback، Ledger، Reconciliation و اعلان ساختگی. Timeout پیش/پس از Fake Commit، Retry، Callback تکراری/دیر/جابجا و State مبهم با Event order ثابت بازپخش می‌شوند.

شناسه‌های Tenant/Order/Attempt/Event/Run/Build/Data/Evidence/Claim/Scene/Story/Decision پایدارند. IRR خیالی Canonical و تومان فقط View برچسب‌خورده است. ارقام فارسی/عربی/لاتین، ی/ی، ک/ک، ZWNJ، RTL/LTR/Bidi، UTC، Asia/Tehran و جلالی نمایشی پوشش داده می‌شوند. هیچ شبکه، سازمان، فرد، کاربر، سفارش، پرداخت، PSP، بانک، پول، PII، نام، موبایل، ایمیل، IP، حساب، PAN، CVV2، OTP، Cookie، Token، Credential، Log یا Screenshot واقعی و هیچ توصیهٔ مالی/بانکی/حقوقی/امنیتی/حریم خصوصی/HR وجود ندارد.

Checker سطحی چگونه فریب می‌خورد؟

Checker فقط Hero، Conflict، Journey، Resolution، Moral، Emotion و Analogy را می‌بیند و می‌گوید:

superficial: STORY_POWERFUL

هیچ‌کدام Truth، Causality، Comprehension یا اخلاق روایت را ثابت نمی‌کنند.

ممیزی ساختاری چه یافت؟

اجرای نخست Validator یک mismatch یک‌موردی نشان داد: ۱۰۳ Finding واقعی در برابر انتظار ۱۰۴. شمارنده پایین نیامد و کنترل ماهوی Decision Authority افزوده شد. سپس دو برخورد نام Fixture—بولی `analogy`/`resolution` با اشیای Contract—به `hasAnalogy`/`hasResolution` اصلاح شدند. اجرای نهایی:

audit: HOLD-104
independentPeopleScoringRule: PASS

قاعدهٔ ۱۰۵ مستقل `people_scoring=false` است. ۱۰۴ فقط تعداد کنترل غایب همین Fixture/نسخه است؛ امتیاز قدرت Story یا نویسنده نیست.

نسخهٔ اصلاح‌شده چه می‌گوید؟

corrected: READY_FOR_STORY_EVIDENCE_REVIEW-0

صفر یعنی Contract ساختاری کامل است؛ نه اینکه Evidence راست، Explanation علّی، فهم/اعتماد/حافظهٔ مخاطب، کیفیت محصول، Safety، Outcome یا Decision درست ثابت شده باشد.

ضدالگوهای داستان‌سرایی فنی

• Story به‌عنوان Evidence.
• ادعای عمومی Oxytocin/اعتماد/حافظه.
• قهرمان اجباری برای هر مفهوم.
• فرد ناجی و تیم/سیستم نامرئی.
• توسعه‌دهنده یا کاربر به‌عنوان Villain.
• Emotion یا Intent بدون منبع.
• Quote ساختگی با گیومهٔ واقعی.
• Composite بدون Disclosure.
• Fictional example بدون برچسب.
• شروع از Moral مطلوب و انتخاب شواهد.
• Counterevidence در Appendix پنهان.
• حذف Unknown برای پایان خوش.
• «بنابراین» بدون Causal evidence.
• جابه‌جایی Event order بدون Disclosure.
• فشرده‌سازی زمان پنهان.
• پرش یک Run به کل Production.
• تشبیه بدون Break/Retirement.
• ۹۹٪ بدون Dataset/Threshold.
• ۵۰٪ کاهش بدون Baseline/Window.
• Before/After به‌عنوان Causality.
• Resolution به‌عنوان Victory کامل.
• Moral عمومی از Case محدود.
• Chart/Query/Raw route حذف‌شده.
• Uncertainty در Footnote.
• Fear theater و Worst case بی‌احتمال.
• Story جذاب به‌عنوان Authority.
• Comprehension بر اساس Like/View.
• Reuse خارج Context.
• Correction خاموش.
• AI به‌عنوان سازندهٔ Quote/Fact.
• امتیازدهی افراد بر اساس توجه/یادآوری.

چک‌لیست Story Owner

• StoryID/version/status/expiry روشن‌اند.
• Purpose/Audience/Decision/Authority مشخص‌اند.
• Source Snapshot/as-of/Population/Env/Build/Data ثبت‌اند.
• Claim type/scope/window/confidence/not-claimed کامل است.
• Evidence/Counterevidence/Unknown/Alternative کنار هم‌اند.
• Question/Start/Change/End از Evidence آمده‌اند.
• Event order و Presentation order جدا هستند.
• Scene Manifest به Claim/Evidence وصل است.
• Omission/transition/time compression/scale change افشا شده‌اند.
• Actor identity/privacy/dignity کنترل شده‌اند.
• Composite/Quote/Fiction labels روشن‌اند.
• Intent بدون Evidence ادعا نشده است.
• Analogy mapping/holds/breaks/test/retirement دارد.
• Number denominator/baseline/unit/window/range/source دارد.
• Resolution actual status/remaining risk/next question دارد.
• هیچ Fabrication/Cherry-pick/Fear/Hero/Villain نیست.
• Plain/Glossary/Text/RTL-LTR/Layered detail آماده‌اند.
• Raw Evidence route کار می‌کند.
• Domain/Evidence/Affected-party reviewers ثبت‌اند.
• Comprehension و Misinterpretation probe اجرا شده‌اند.
• Reuse policy و Correction route وجود دارد.
• Audit/Retention/Expiry مالک دارند.
• `people_scoring=false` مستقل کنترل شده است.
• NotProof حدود Story را می‌گوید.

Pilot سی‌روزه Story–Evidence

1. روز ۱ تا ۵: یک Fixture کم‌خطر انتخاب و Source/Claim/Question را بدون Story Freeze کنید.
2. روز ۶ تا ۱۰: Scene Manifest، Omission و Event/Presentation order را در Shadow بسازید.
3. روز ۱۱ تا ۱۵: Analogy break، Number contract، Resolution و layered raw route را Review کنید.
4. روز ۱۶ تا ۲۰: Composite/Quote/privacy labels و Accessibility را تست کنید.
5. روز ۲۱ تا ۲۵: Comprehension/Misinterpretation probe را اجرا و Story را اصلاح کنید؛ افراد را نسنجید.
6. روز ۲۶ تا ۳۰: یک Correction/Reissue مصنوعی انجام و Continue/Adapt/Stop تصمیم‌گیری کنید.

Pilot، اعتماد، حافظه، کیفیت محصول یا اثر علّی Story را ثابت نمی‌کند. هدف آن تمرین Traceability و Repair است.

جمع‌بندی اجرایی

داستان‌سرایی فنی زمانی مفید است که پیچیدگی را لایه‌بندی و مسیر بازگشت به Evidence را حفظ کند. Plot را پس از Claim بسازید؛ Scene/Omission/Transition را ممیزی کنید؛ قهرمان/تشبیه/عدد را محدود نگه دارید؛ پایان باز و Unknown را بپذیرید؛ و Correction را به همهٔ Reuseها برسانید. داستان خوب جای حقیقت را نمی‌گیرد؛ راه دیدن آن را کوتاه‌تر می‌کند.

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

داستان‌سرایی فنی چیست؟

ساخت یک View ترتیبی و قابل‌فهم از Claim/Evidence است که هر Scene آن قابل‌ردیابی، محدودیت/حذف آن آشکار و Raw source در دسترس باشد. Story توضیح است، نه Evidence یا اثبات علت.

آیا هر توضیح فنی باید قهرمان و کشمکش داشته باشد؟

خیر. State machine، Process یا Evidence chain می‌تواند محور باشد. برای Procedure، API contract و Proof، ساختار مستقیم اغلب بهتر است. قهرمان فقط وقتی استفاده شود که مدل را بدون تحریف روشن‌تر کند.

چگونه از تحریف در داستان داده جلوگیری کنیم؟

Snapshot را Freeze، Scene را به Claim/Evidence وصل، Counterevidence/Unknown را کنار پیام اصلی، Omission/Window/Scale را افشا و Query/Chart/Raw route را فراهم کنید. Transition علّی فقط با Evidence علّی مجاز است.

یک تشبیه فنی خوب چه ویژگی دارد؟

Target و Mapping روشن، بخش‌های برقرار، Break-case، آزمون فهم و نقطهٔ Retirement دارد. تشبیه Cache/کتابدار اگر Staleness، invalidation و concurrency را پنهان کند، فقط Orientation محدود است.

آیا Storytelling اعتماد و یادگیری را تضمین می‌کند؟

خیر. اثر به Audience، محتوا، Context، روش و Outcome measurement وابسته است. جذابیت، View یا Recall به‌تنهایی فهم، اعتماد موجه یا تصمیم درست را ثابت نمی‌کند؛ Comprehension و Misinterpretation باید مستقیماً بررسی شوند.