Owner Exception Management

درخواست فوری یک Owner به‌خودی‌خود مجوز جدید برای Agent نمی‌سازد. اگر Agent طبق قاعده‌ی عادی اجازه‌ی انجام یک Action را ندارد، Exception باید روشن کند چه کسی واقعاً اختیار تأیید دارد، دقیقاً چه Action/Subject/Resourceای مجاز می‌شود، از چه زمانی تا چه زمانی، با چه Evidence و Risk، با چه Compensating Control و تحت چه Revocation/Auditی.

Shortcut خطرناک این است: «Owner در چت گفت انجام بده، پس مجاز است.» این کار Request، Approval و Policy Change را در یک پیام ادغام می‌کند. در این درس Owner Exception Request & Decision Ledger v1 را می‌سازیم تا Normal Rule سر جای خودش بماند و یک Override یک‌باره هرگز بی‌صدا به Authority دائمی تبدیل نشود.

قاعده‌ی اصلی: Normal Rule را تغییر نده. Exception یک رکورد جدا، محدود، زمان‌دار، قابل‌لغو و قابل‌ممیزی است. اگر Authority یا Evidence تعیین‌کننده ناقص باشد، سیستم باید fail-closed شود و یک state غیرموفق صریح بدهد.

مرز درس و مسیر

AGN-001 مالک Owner Exception Management است. COM-037 مالک Native App Decision Gate و AGN-001 مالک Recommendation با Evidence/Confidence است. این درس هیچ‌کدام از این Outcomeهای مجاور را جذب نمی‌کند.

Prerequisiteهای مجاز FND-003 به‌صورت Hard و AIE-009 به‌صورت Soft هستند. فقط مرز لازم را حمل می‌کنیم: Action پراثر بدون Evidence و Authority پاسخ‌گو نباید صرفاً به‌دلیل Urgency آزاد شود.

همه‌ی مثال‌ها و Lab مصنوعی و آفلاین‌اند. هیچ Refund واقعی، Billing، Customer، Tenant، Production System یا Approval واقعی تغییر نمی‌کند.

مدل ذهنی: Exception یک Delta محدود است، نه Default جدید

این زنجیره را نگه دارید:

normal rule → exception request → authority check → evidence/risk check → reject | hold | approve-bounded → compensating control → expiry/revoke → audit → separate policy-change path

چهار چیز را از هم جدا نگه دارید:

1. Normal Rule: Agent در حالت عادی چه اجازه‌ای دارد.
2. Exception Request: چه انحرافی از Rule درخواست شده و چرا.
3. Exception Decision: اگر موجه بود، یک مجوز محدود و ثبت‌شده.
4. Policy Change: تغییر جداگانه و Governed در Rule پیش‌فرض.

Exception معتبر Normal Rule را بازنویسی نمی‌کند. تکرار Exception هم خودکار Policy نمی‌سازد. حالت‌های HOLD, UNKNOWN, PARTIAL, DISPUTED, STALE, BLOCKED, EXPIRED, REVOKED Outcome معتبرند وقتی Evidence ناقص است یا Grant دیگر معتبر نیست.

مبانی: FACT، INFERENCE و DESIGN را جدا نگه دارید

FACT — NIST: NIST AI 600-1 می‌گوید استفاده از GAI ممکن است به Human Review بیشتر، Tracking/Documentation و Management Oversight بیشتری نیاز داشته باشد و سازمان‌ها می‌توانند کاربردهایی را که از Risk Tolerance عبور می‌کنند محدود کنند. این منبع از Oversight صریح و مدیریت Risk پشتیبانی می‌کند، اما Roleها، Expiry و Stateهای MAKNOW را تعریف نمی‌کند.

FACT — OpenAI Agents SDK: مستندات فعلی Human-in-the-loop نشان می‌دهد Tool Call نیازمند Approval می‌تواند Pause شود، Approval Pending به‌صورت Interruption ظاهر شود و بعد از Approve/Reject همان Run Resume شود. این یک مکانیزم فنی Approval است؛ ثابت نمی‌کند فرد تأییدکننده در سازمان Authority لازم را دارد.

INFERENCE: وقتی Normal Rule و Exception Record جدا باشند و Scope، Authority Evidence، Control، Expiry/Revocation و Audit صریح ثبت شود، Exception دفاع‌پذیرتر و قابل‌ممیزی‌تر است.

DESIGN: فیلدهای Ledger، نام Stateها، Fail-closed Ruleها، Revalidation و Policy-promotion gate قرارداد محلی MAKNOW هستند.

قرارداد ۲۲فیلدی Owner Exception Ledger

رکورد اصلی ۲۲ بُعد دارد:

exception_id, requester_id, owner_authority_ref, normal_rule_ref, requested_action, subject_scope, resource_scope, reason_code, evidence_refs, risk_class, approval_required, decision_state, decision_by, decision_at, effective_from, expires_at, compensating_controls, audit_event_ref, revocation_trigger, revalidation_due, policy_change_candidate, final_disposition.

Gate 1 — Normal Rule را حفظ کن

normal_rule_ref باید در رکورد باقی بماند. Rule پایه را برای عادی جلوه‌دادن Exception ویرایش نکنید.

Gate 2 — Authority را Verify کن

owner_authority_ref باید به Authority محلی برای همین Class از Exception اشاره کند. کلمه‌ی «Owner» در مکالمه کافی نیست. اگر Authority مفقود، Unknown، Stale، Disputed یا خارج از Scope/Risk باشد، HOLD کنید.

Gate 3 — Action، Subject و Resource را Bound کن

مجوز برای یک Refund، یک Customer مصنوعی و یک Account/Resource را نمی‌توان برای یک Customer Tier، Action دیگر یا Resource دیگر reuse کرد. Scope Expansion تصمیم جدید می‌خواهد.

Gate 4 — Reason، Evidence و Risk را ثبت کن

Urgency فقط Context است، Authority نیست. reason_code، evidence_refs و risk_class Trade-off را آشکار می‌کنند. Exception پرریسک Evidence و Control قوی‌تری می‌خواهد.

Gate 5 — Approval را صریح کن

اگر Approval لازم است، decision_by باید یک Approver مجاز باشد و decision_at ثبت شود. State از قبل پرشده‌ی APPROVE_BOUNDED نبود Authority را جبران نمی‌کند.

Gate 6 — زمان را Bound کن

effective_from و expires_at پنجره‌ی اعتبار را مشخص می‌کنند. بعد از Expiry اجرا Block می‌شود. Request جدید یعنی Evaluation جدید، نه تمدید بی‌صدا.

Gate 7 — Compensating Control اضافه کن

مثلاً Review نفر دوم، سقف مبلغ پایین‌تر، Single-use، Reconciliation بعد از Action یا Monitoring بیشتر. Control Risk محدود را کاهش می‌دهد؛ Authority نمی‌سازد.

Gate 8 — Audit و Revocation

هر Exception یک audit_event_ref و revocation_trigger می‌خواهد. اگر Trigger فعال شد، Exception حتی قبل از Expiry باید REVOKED/BLOCKED شود.

Gate 9 — Revalidate و Policy Change را جدا کن

Exceptionهای تکرارشونده می‌توانند Signal بدهند که Normal Rule نیاز به بازنگری دارد. policy_change_candidate=true را ثبت کنید، اما خودکار Promote نکنید؛ Policy Change مسیر Governed جدا دارد.

مثال‌های حل‌شده

مثال ۱ — Exception محدود و معتبر

Agent پشتیبانی در حالت عادی حق Refund بالاتر از ۵۰۰ واحد ندارد. هنگام Incident، Service Owner مجاز برای یک Customer با شناسه‌ی C-104 یک Refund برابر ۷۵۰ درخواست می‌کند. Authority مخصوص Incident Exception Verify شده، Evidence جاری است، Risk بالا ولی Bound شده، Reconciliation نفر دوم الزامی است، Grant بعد از ۳۰ دقیقه Expire می‌شود و Revocation Trigger هم دارد. APPROVE_BOUNDED فقط به‌دلیل کامل‌بودن Evidence قابل‌دفاع است.

مثال ۲ — Approval باقی است ولی Owner Authority حذف می‌شود

owner_authority_ref را حذف کنید اما decision_state=APPROVE_BOUNDED را نگه دارید. این State دیگر Evidence ندارد. خروجی باید HOLD_AUTHORITY_UNVERIFIED باشد؛ متن Approval خودش Proof نیست.

مثال ۳ — یک Customer به کل Customer Tier تبدیل می‌شود

Baseline فقط C-104 را پوشش می‌دهد؛ Mutation، subject_scope را به premium_customers گسترش می‌دهد. این همان Exception نیست. تا Decision مستقل و مجاز ساخته نشود، HOLD_SCOPE_BROADENED لازم است.

مثال ۴ — Expiry گذشته اما Agent هنوز Grant را executable می‌داند

Exception منقضی «احتمالاً هنوز قابل‌قبول» نیست. Evaluator باید BLOCKED_EXCEPTION_EXPIRED بدهد و Request/Evaluation جدید بخواهد.

مثال ۵ — Exception تکراری به رفتار عادی تبدیل می‌شود

اگر یک Deviation مرتب تکرار می‌شود، آن را policy_change_candidate کنید. ادامه‌ی نامحدود با Exceptionهای جدید جای Policy Review را نمی‌گیرد.

Failure Modeهای رایج

• Chat-as-authority: پیام Request همان Permission فرض می‌شود.
• Normal-rule overwrite: به‌جای ثبت Exception، Rule پایه تغییر می‌کند.
• Scope creep: یک Subject/Action/Resource بی‌صدا به Class بزرگ‌تر گسترش پیدا می‌کند.
• Approval without approver: State می‌گوید Approved اما Authority Evidence نیست.
• Permanent temporary: expires_at وجود ندارد یا Expiry نادیده گرفته می‌شود.
• Control theater: Compensating Control نام برده می‌شود ولی به Risk وصل نیست.
• No revocation: حتی بعد از تغییر شرایط Grant معتبر می‌ماند.
• Audit gap: معلوم نیست چه کسی، چه چیزی را، چه زمانی تأیید کرده.
• Exception-to-policy drift: تکرار Exception بدون Policy Change Governed به رفتار عادی تبدیل می‌شود.
• Baseline reuse: Request بعدی بعد از Expiry، Approval قبلی را کپی می‌کند.
• External-mechanism overreach: Approval فنی SDK با Authority سازمانی اشتباه گرفته می‌شود.
• Forced success: Evidence ناقص به‌جای HOLD/UNKNOWN/BLOCKED به Approval تبدیل می‌شود.

Alternatives و Trade-offها

می‌توانید همه‌ی Exceptionهای پرریسک را Reject کنید یا Exception محدود با Control قوی‌تر داشته باشید. Reject-all ساده‌تر و محافظه‌کارانه‌تر است؛ Exception محدود انعطاف عملیاتی می‌دهد اما Evidence، Ownership، Expiry و Audit بیشتری لازم دارد.

Exception می‌تواند Single-use یا Time-windowed باشد. Single-use راحت‌تر Audit می‌شود؛ Time Window در Incident مفیدتر است ولی Risk اجرای چندباره‌ی ناخواسته را بالا می‌برد.

برای Deviationهای تکراری می‌توانید Exceptionهای جدید بدهید یا Policy Review باز کنید. مسیر Exception سریع‌تر است ولی Drift می‌سازد؛ Policy Review پرهزینه‌تر است اما Default Rule را شفاف، تست‌پذیر و پاسخ‌گو می‌کند.

قاعده‌ی کنترل‌کننده: Exception فقط می‌تواند یک Deviation را محدود و زمان‌دار کند؛ نباید Authority بزرگ‌تر یا ماندگارتر از Evidence تولید کند.

پل مسیر باتجربه

برای Review سریع، هشت سؤال بپرسید:

1. دقیقاً کدام Normal Rule قرار است bypass شود؟
2. Requester کیست و چه Evidenceای Authority او را ثابت می‌کند؟
3. دقیقاً چه Actionای مجاز می‌شود؟
4. Subject و Resource داخل Scope و خارج Scope چیست؟
5. چه Evidence و Riskای Deviation را توجیه می‌کند؟
6. چه Compensating Controlی داریم؟
7. Expiry چیست و چه Triggerی زودتر Revocation می‌کند؟
8. هنوز یک Exception است یا تکرار آن Signal یک Policy Change شده؟

اگر جواب سؤال ۲ فقط «Owner است» باشد، Decision هنوز Auditable نیست.

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

Lab آفلاین را اجرا کنید:

python -B lab/AGN-001-LAB1/learner/run_checks.py

از Baseline محدود شروع کنید. سپس این Mutationها را اجرا کنید: Owner Authority را حذف ولی Approval را نگه دارید؛ یک Customer را به Customer Tier گسترش دهید؛ Expiry را عبور دهید ولی Exception را executable نگه دارید؛ Compensating Control یک Case پرریسک را حذف کنید؛ Revocation Trigger را فعال کنید؛ و یک Exception تکراری را بدون Policy-change disposition ادامه دهید.

در Transfer، بعد از Expiry یک Request جدید برای Action و Customer Class متفاوت بیاید. Approval baseline یا Authority ref قبلی را بدون بررسی Applicability کپی نکنید.

شواهد Verification

قبولی وقتی است که Decision از روی Fieldهای Visible و Ruleهای deterministic بازتولید شود. Lab باید حداقل این موارد را بگیرد:

• Approval بدون Owner Authority قابل‌Verify؛
• Scope Expansion خارج از Subject/Action/Resource مجاز؛
• Execution بعد از Expiry؛
• Revocation Trigger فعال؛
• Exception پرریسک بدون Compensating Control؛
• Exception تکراری که مثل Policy عادی استفاده می‌شود؛
• Transfer که Approval baseline را reuse می‌کند؛
• Missing field تعیین‌کننده که به success تبدیل می‌شود.

Oracle فقط Fixture و Ruleهای آشکار است؛ نه Hidden Reasoning مدل و نه سرویس Live.

Assessment و Transfer

Learner باید چهار توانایی را نشان دهد: مرز AGN-001 را توضیح دهد؛ Baseline Ledger کامل بسازد؛ Mutation «Owner Authority حذف شده ولی Approval مانده» را diagnose کند؛ و Changed-context Request بعد از Expiry را از صفر recompute کند.

Diagnosis قوی Field خراب، Consequence و کوچک‌ترین Repair را نام می‌برد. مثال: owner_authority_ref=UNKNOWN → approval unsupported → HOLD_AUTHORITY_UNVERIFIED → resolve authority evidence before any execution.

در Transfer نهایی Action و Customer Class تغییر کرده‌اند. Approval قبلی فقط Historical Evidence است؛ Standing Policy نیست، Authority قابل‌ارث نیست و Answer Key محسوب نمی‌شود.

منابع و Freshness

• NIST AI 600-1 — Generative AI Profile: منبع رسمی برای Human Oversight بیشتر، Tracking/Documentation، Management Oversight، Risk Tolerance و Governance Control؛ نه منبع Stateهای محلی Exception.
• OpenAI Agents SDK — Human-in-the-loop: مکانیزم فعلی Pause/Approve/Reject/Resume برای Tool Call حساس؛ نه Proof برای Authority سازمانی.
• Frozen AGN-001 Lesson Bible: Authority محلی برای Fieldها، Stateها، Negative Caseها، Transfer و جداسازی Policy Change.

NIST و Agents SDK در 2026-09-14 دوباره بررسی شدند. رفتار volatile مربوط به SDK را تا 2026-10-18 و claimهای practice-level را تا 2027-01-01 بازبینی کنید یا زودتر اگر semantics materially تغییر کرد.