Append-only Ledger و Correction-not-Mutation

۱. Balance فعلی، History نیست

ممکن است ledger مقدار balance فعلی را درست نشان دهد اما integrity تاریخی ضعیفی داشته باشد. اگر debit دیروز از -12000 به -10000 ویرایش شود، عدد امروز درست به نظر می‌رسد ولی سیستم این واقعیت را پاک کرده که posting اولیه با مقدار اشتباه پذیرفته شده بود. این حذف برای audit، replay، incident analysis و reasoning درباره correction مهم است.

خروجی محدود این درس Append-only Ledger Integrity Record v1 است. باید history پذیرفته‌شده را حفظ کنید، correction را به‌صورت entry جدید بسازید، projection را از صفر بازسازی کنید، duplicate posting identity را رد کنید و دقیقاً بگویید evidence چه چیزهایی را ثابت نمی‌کند.

۲. Append-only گواهی Compliance نیست

الگوی Event Sourcing در Azure فقط یک analogy معماری مفید است چون توالی تغییرات را در append-only store نگه می‌دارد و state را می‌توان از replay ساخت. این درس ledger کوچک را با Event Sourcing، قانون حسابداری، fraud prevention یا blockchain یکی نمی‌گیرد. تنها ایده‌ی مالک این بخش این است: fact پذیرفته‌شده قبلی حفظ می‌شود و fact بعدی append می‌شود.

تصمیم نهایی باید سه لایه را جدا نگه دارد: stored history، derived projection و external business approval. history فنی سالم به‌تنهایی authorization یا legal validity correction را ثابت نمی‌کند.

۳. کوچک‌ترین مدل Ledger

هر entry در fixture محلی شامل entry_id، business_key، entry_type، amount_delta، corrects_entry و accepted_at است. business_key یک posting attempt را در سرویس محدود شناسایی می‌کند. corrects_entry برای entry عادی خالی است و برای correction به entry قبلی اشاره می‌کند.

Starter با debit پذیرفته‌شده E1 و business key برابر debit-001 و delta برابر -12000 شروع می‌شود. correction نباید UPDATE باشد. entry جدید E2 با delta برابر +2000 به E1 reference می‌دهد؛ replay مقدار -10000 می‌سازد و debit اولیه همچنان قابل inspection می‌ماند.

۴. Correction یعنی Append کردن Fact جدید

Correction entry دو سؤال متفاوت را پاسخ می‌دهد. delta عددی projection را تغییر می‌دهد، اما corrects_entry علت وجود fact بعدی را توضیح می‌دهد. ممکن است projection به عدد درست برسد ولی lineage field حذف شده باشد. بنابراین projection correctness و correction lineage دو evidence dimension جدا هستند.

Oracle محلی correction را فقط وقتی معتبر می‌داند که entry مرجع از قبل وجود داشته باشد و correction هویت entry و business مستقل داشته باشد. Oracle درباره approval تجاری amount یا reason تصمیم نمی‌گیرد.

۵. Projection Rebuild باید از State تمیز شروع شود

Derived balance قابل حذف است. تست تعیین‌کننده این است که projection پاک شود و از accepted ledger entries با یک ordering و calculation rule مشخص دوباره ساخته شود. Fixture محلی ابتدا بر اساس accepted_at و سپس entry_id مرتب می‌کند و amount_deltaها را جمع می‌زند.

Integrity Record هم input trace مرتب‌شده و هم rebuild result را نگه می‌دارد. projection برابر، فقط reproducibility همین fixture را پشتیبانی می‌کند و تمام domain invariantها را ثابت نمی‌کند.

۶. Posting Identity و Duplicate

سرویس محدود به posting identity پایدار نیاز دارد تا retry همان posting باعث append شدن fact دوم نشود. در harness محلی business_key باید unique باشد. duplicate probe تلاش می‌کند entry دیگری با debit-001 اضافه کند و انتظار می‌رود بدون تغییر history رد شود.

PostgreSQL 18 unique constraint را مکانیزمی برای uniqueness روی column یا مجموعه columnها توضیح می‌دهد. در این درس این فقط boundary محلی storage است. unique key تضمین عمومی exactly-once در distributed systems نیست.

۷. Transaction Boundary محلی است

مستند PostgreSQL 18 transaction را مجموعه all-or-nothing از عملیات database تعریف می‌کند. این برای reasoning درباره append محلی و metadata مرتبط مفید است، اما distributed atomicity بین service، broker، payment network یا approval خارجی ایجاد نمی‌کند.

Learner fixture عمداً self-contained و in-memory است. بنابراین رفتار آن به‌عنوان PostgreSQL runtime observation گزارش نمی‌شود. vendor fact و local observation در Evidence Record جدا می‌مانند.

۸. Negative Probe: Mutation History

اولین failure عمدی، debit اولیه را درجا ویرایش می‌کند. fingerprint history قبل از correction دیگر با prior fact ذخیره‌شده برابر نیست، پس integrity rule fail می‌شود حتی اگر final balance به مقدار مطلوب برسد.

Balance-only test این defect را نمی‌بیند. Evidence باید before/after trace را حفظ و نتیجه را HISTORY_MUTATION_DETECTED طبقه‌بندی کند.

۹. Negative Probe: Duplicate Posting

Probe دوم entry جدیدی را با business_key قبلاً پذیرفته‌شده append می‌کند. نتیجه مورد انتظار DUPLICATE_POSTING_REJECTED است و طول ledger و history قبلی نباید تغییر کند.

این فقط evidence برای posting-identity boundary محلی است و duplicate suppression در database مستقل یا retry توزیع‌شده را ثابت نمی‌کند.

۱۰. Negative Probe: Correction Link گمشده

Probe سوم adjustment عددی را append می‌کند که balance را درست می‌کند ولی corrects_entry خالی است. replay هنوز -10000 می‌دهد، اما lineage correction قابل اثبات نیست؛ بنابراین integrity decision باید با CORRECTION_LINEAGE_MISSING fail شود.

این تفاوت اصلی state correctness و historical explainability است: projection یکسان می‌تواند از historyهایی با integrity متفاوت ساخته شود.

۱۱. Evidence Completeness بخشی از Contract است

تصمیم نهایی بیشتر از runtime سبز لازم دارد. Record باید entry evidence، projection evidence، posting-identity evidence، correction-lineage evidence، residual domain rule و transfer decision را داشته باشد. حذف یک field لازم باعث insufficient شدن record می‌شود حتی اگر probeها اجرا شده باشند.

Runner فقط observation خام محلی می‌نویسد و final bounded decision یا residual risk learner را پر نمی‌کند.

۱۲. Transfer: Imported Correction در Refund Ledger

Context جدید entry typeهای DEBIT و CREDIT جدا دارد و یک historical correction وارد شده است. باید imported fact را immutable نگه دارید، correction link صریح انتخاب کنید، replay ordering rule را بنویسید و duplicate posting identity را محدود کنید.

راه‌حل اجازه ندارد imported row را rewrite کند. همچنین باید یک residual uncertainty درباره approval، settlement، compliance یا external system behavior بیان شود.

۱۳. این درس چه چیزی را ثابت می‌کند

Evidence محلی می‌تواند پنج claim محدود را پشتیبانی کند: history قبلی ثابت مانده، correction یک fact جدید و linked است، projection deterministic rebuild شده، duplicate posting identity محلی رد شده و technical integrity از approval خارجی جدا شده است.

این درس legal compliance، fraud resistance، exactly-once delivery، blockchain property، Event Sourcing architecture یا درستی external accounting decision را ثابت نمی‌کند.

۱۴. Freshness و Source Discipline

Source boundary دقیقاً سه صفحه رسمی است: Azure Event Sourcing فقط به‌عنوان analogy append-only، PostgreSQL 18 Transactions برای semantics atomicity محلی و PostgreSQL 18 Constraints برای semantics uniqueness محلی. در 2026-09-15 دوباره بررسی شدند و material drift در claimهای قفل‌شده دیده نشد.

Azure analogy تا 2026-12-31 و claimهای tool-specific PostgreSQL تا 2026-10-17 یا زودتر در صورت تغییر implementation review می‌شوند.