Context Management & Reliability

As history is summarized to save tokens, exact figures ('$49.99 refund', 'promised by the 5th') get blurred into 'wanted a refund'. Once lost, the agent can't act correctly. Keep hard facts verbatim.

جیسے جیسے ٹوکن بچانے کے لیے تاریخ کا خلاصہ ہوتا ہے، صحیح اعداد ('۴۹.۹۹ ڈالر ریفنڈ'، '۵ تاریخ تک وعدہ') دھندلا کر 'ریفنڈ چاہتا تھا' بن جاتے ہیں۔ ایک بار کھو جائیں تو ایجنٹ درست کارروائی نہیں کر پاتا۔ ٹھوس حقائق جوں کے توں رکھیں۔

In a long aggregated input, content in the middle is most likely to be under-weighted. Put key findings at the start (or end) and use explicit section headers so nothing important hides in the middle.

لمبے جمع کیے ان پٹ میں بیچ کا مواد سب سے زیادہ نظر انداز ہوتا ہے۔ اہم نتائج شروع (یا آخر) میں رکھیں اور صاف سیکشن سرخیاں لگائیں تاکہ کوئی اہم چیز بیچ میں نہ چھپے۔

An order lookup might return 40+ fields when only 5 are relevant to a return. Left unchecked, these bloat context. Trim to the relevant fields before they pile up.

ایک آرڈر کی کھوج ۴۰ سے زیادہ خانے لوٹا سکتی ہے جبکہ واپسی کے لیے صرف ۵ کام کے ہوں۔ بغیر روک کے یہ سیاق پھلا دیتے ہیں۔ جمع ہونے سے پہلے صرف کام کے خانوں تک محدود کر دیں۔

Maintain a small, structured 'case facts' block (amounts, dates, order numbers, statuses) that you include verbatim every turn — so summarization can never erode it.

ایک چھوٹا، منظم 'case facts' بلاک رکھیں (رقمیں، تاریخیں، آرڈر نمبر، حالتیں) جو آپ ہر باری جوں کا توں شامل کریں — تاکہ خلاصہ اسے کبھی خراب نہ کر سکے۔

CASE FACTS (verbatim, every turn):
- order_id: 12345
- refund_amount: 49.99
- promised_delivery: 2026-07-05
- status: double-charged

When one session covers several issues, keep each issue's facts in its own structured record outside the chat flow. That way a later summary of the conversation can't merge or drop details from a specific issue.

جب ایک سیشن کئی مسئلوں کو ڈھانپے، تو ہر مسئلے کے حقائق اس کے اپنے منظم ریکارڈ میں چیٹ کے بہاؤ سے باہر رکھیں۔ اس طرح بعد کا خلاصہ کسی خاص مسئلے کی تفصیلات ملا یا گرا نہیں سکتا۔

ISSUE LOG (structured, outside chat history):
- issue#1 { order_id: 12345, type: double_charge, amount: 49.99, status: open }
- issue#2 { order_id: 98765, type: late_delivery, promised: 2026-07-05, status: resolved }
// summarizing the transcript can't merge issue#1 and issue#2 or lose an amount

An order lookup might return 40+ fields when 5 matter. Project down to the relevant fields as results come back — otherwise the raw payloads pile up and crowd out context you actually need.

ایک آرڈر کی کھوج ۴۰ سے زیادہ خانے لوٹا سکتی ہے جبکہ ۵ ہی اہم ہوں۔ نتائج آتے ہی صرف کام کے خانوں تک سکیڑ دیں — ورنہ خام ڈیٹا جمع ہو کر وہ سیاق دبا دیتا ہے جو آپ کو واقعی چاہیے۔

// raw tool result (40+ fields):
{ id, status, sku, warehouse, carrier, tax_region, gift_wrap, ...34 more }
// project down BEFORE appending to context:
{ order_id: 12345, status: "shipped", amount: 49.99,
  delivery_date: "2026-07-05", refund_eligible: true }

Because models under-weight the middle of long inputs ('lost in the middle'), lead with the most important findings and label sections with headers so critical content sits where the model reliably attends.

چونکہ ماڈل لمبے ان پٹ کا بیچ کم اہمیت دیتے ہیں ('بیچ میں کھو جانا')، سب سے اہم نتائج شروع میں رکھیں اور سیکشنز پر سرخیاں لگائیں تاکہ اہم مواد وہاں ہو جہاں ماڈل بھروسے سے توجہ دیتا ہے۔

=== KEY FINDING (read first) ===
Customer double-charged $49.99 on 2026-07-02; refund approved.

=== SUPPORTING DETAIL ===
- order placed 2026-07-01
- duplicate charge 2026-07-02
...200 lines of transcript below...
// the decision sits at the TOP, not buried mid-input

When a downstream agent is short on context budget, ask upstream agents for compact structured results (claims + sources + dates) rather than long prose reasoning — same information, far fewer tokens to carry forward.

جب نیچے والے ایجنٹ کے پاس سیاق کا بجٹ کم ہو، تو اوپر والے ایجنٹوں سے لمبی عبارت والی سوچ کے بجائے مختصر منظم نتائج مانگیں (دعوے + ذرائع + تاریخیں) — وہی معلومات، آگے لے جانے کو بہت کم ٹوکن۔

// verbose (3 paragraphs of reasoning) → costly downstream
// compact structured result → same facts, ~90% fewer tokens:
{ "finding": "Q2 adoption up 40%",
  "source": "report.pdf p.12",
  "date": "2024-06",
  "confidence": 0.9 }

Escalate when the customer asks for a human, when policy is silent/ambiguous on their case, or when the agent genuinely can't progress. 'The case feels hard' is not, by itself, a trigger.

آگے تب بھیجیں جب گاہک انسان مانگے، جب اس کے معاملے پر پالیسی خاموش/مبہم ہو، یا جب ایجنٹ واقعی آگے نہ بڑھ سکے۔ 'معاملہ مشکل لگتا ہے' بذاتِ خود کوئی وجہ نہیں۔

If a customer demands a human, don't first attempt to investigate — hand off. If they're frustrated but the issue is easy, acknowledge and offer to fix it, escalating only if they insist.

اگر گاہک انسان کا تقاضا کرے تو پہلے چھان بین کی کوشش نہ کریں — سونپ دیں۔ اگر وہ جھنجھلایا ہوا ہو مگر مسئلہ آسان ہو، تو بات مانیں اور ٹھیک کرنے کی پیشکش کریں، آگے صرف تب بھیجیں اگر وہ اصرار کرے۔

A calm customer can have a hard case; an angry one an easy case. And the agent is already wrongly confident on the hard cases — so its self-reported confidence can't gate escalation.

ایک پُرسکون گاہک کا معاملہ مشکل ہو سکتا ہے؛ ایک غصے والے کا آسان۔ اور ایجنٹ مشکل معاملوں پر پہلے ہی غلط اعتماد رکھتا ہے — اس لیے اس کا اپنا بتایا اعتماد آگے بھیجنے کا فیصلہ نہیں کر سکتا۔

If a lookup returns several possible customers, ask for another identifier. Guessing risks acting on the wrong account.

اگر کھوج کئی ممکنہ گاہک لوٹائے تو ایک اور پہچان مانگیں۔ اندازہ لگانے سے غلط اکاؤنٹ پر کارروائی کا خطرہ ہے۔

Spell out the real triggers — explicit human request, policy gap/ambiguity, no meaningful progress — and show worked examples. Concrete criteria stop the agent from using sentiment or its own shaky confidence as the gate.

اصل وجوہات صاف بتائیں — صریح انسانی مطالبہ، پالیسی میں خلا/الجھن، کوئی بامعنی پیش رفت نہ ہونا — اور حل شدہ مثالیں دکھائیں۔ ٹھوس اصول ایجنٹ کو جذبات یا اپنے ڈگمگاتے اعتماد کو فیصلے کی بنیاد بنانے سے روکتے ہیں۔

SYSTEM PROMPT — Escalate ONLY when:
  1) the customer explicitly asks for a human
  2) policy is silent/ambiguous on the request
  3) you cannot make meaningful progress

Few-shot:
  "I want a person"              -> escalate immediately
  "This is so frustrating!" (simple return) -> acknowledge + resolve, do NOT escalate

When a customer asks for a human, hand off right away — don't insist on trying to resolve it first. Investigating over an explicit request erodes trust and delays the outcome they asked for.

جب گاہک انسان مانگے تو فوراً سونپ دیں — پہلے خود حل کرنے پر اصرار نہ کریں۔ صریح مطالبے کے باوجود چھان بین کرنا بھروسہ گھٹاتا اور مطلوبہ نتیجہ دیر کرتا ہے۔

User: "Just get me a human."
  x  "Let me first pull up your order and try to..."   (investigating over the request)
  ok "Of course - connecting you to an agent now."  -> transfer

Frustration isn't itself an escalation trigger. Acknowledge it, offer to fix an issue that's within your capability, and escalate only if the customer insists on a human — sentiment doesn't equal complexity.

جھنجھلاہٹ بذاتِ خود آگے بھیجنے کی وجہ نہیں۔ اسے تسلیم کریں، اپنی صلاحیت کے اندر مسئلہ ٹھیک کرنے کی پیشکش کریں، اور آگے صرف تب بھیجیں اگر گاہک انسان پر اصرار کرے — جذبات پیچیدگی کے برابر نہیں۔

User: "This is ridiculous, I've been charged twice!"
  ok "I understand the frustration - I can see the duplicate charge and
      can refund $49.99 right now."
// escalate only if they then reply: "No, I want a human."

A genuine policy gap — the rules cover your-site price drops but say nothing about matching a competitor — is a real escalation trigger. Don't invent a ruling; hand the ambiguous case to someone who can set policy.

ایک سچا پالیسی خلا — قواعد آپ کی اپنی سائٹ کی قیمت کمی کو ڈھانپتے ہیں مگر مدمقابل کے برابر کرنے پر خاموش ہیں — آگے بھیجنے کی اصل وجہ ہے۔ خود فیصلہ نہ گھڑیں؛ مبہم معاملہ اسے دیں جو پالیسی بنا سکے۔

Policy: "Match own-site price drops within 14 days of purchase."
Request: "Match Competitor X's lower price."
-> policy is SILENT on competitors = a gap, not a covered case
-> escalate; do NOT invent a ruling to approve or deny

If a customer lookup returns several people, request another identifier (email, order #) instead of heuristically picking one. Guessing risks acting on — and refunding — the wrong account.

اگر گاہک کی کھوج کئی لوگ لوٹائے تو اندازے سے کسی ایک کو چننے کے بجائے ایک اور پہچان مانگیں (ای میل، آرڈر نمبر)۔ اندازہ لگانے سے غلط اکاؤنٹ پر کارروائی — اور ریفنڈ — کا خطرہ ہے۔

lookup("John Smith") -> 3 matches
  x  refund the most recent order  (guessing the account)
  ok "I found a few accounts under that name - can you share the email
      or an order number so I pull up the right one?"

When a subagent fails, it should tell the coordinator WHAT failed, what it tried, any partial results, and possible alternatives. That lets the coordinator retry smartly, reroute, or proceed with partials.

جب کوئی چھوٹا ایجنٹ ناکام ہو، تو اسے بڑے ایجنٹ کو بتانا چاہیے کیا ناکام ہوا، اس نے کیا کوشش کی، کوئی ادھورے نتائج، اور ممکنہ متبادل۔ اس سے بڑا ایجنٹ سمجھداری سے دوبارہ کوشش کر سکتا، راستہ بدل سکتا، یا ادھورے کے ساتھ آگے بڑھ سکتا ہے۔

{ "failure": "timeout",
  "attempted_query": "AI in film production 2024",
  "partial_results": [ ... ],
  "alternatives": ["narrow date range", "try archive source"] }

Distinguish 'I couldn't reach the source' from 'the source has nothing'. They need opposite responses.

'میں ذریعے تک پہنچ نہ سکا' اور 'ذریعے میں کچھ نہیں' میں فرق کریں۔ ان کے ردعمل الٹ ہوتے ہیں۔

A bare 'unavailable' strips the coordinator of the info it needs to decide anything useful.

خالی 'دستیاب نہیں' بڑے ایجنٹ سے وہ معلومات چھین لیتا ہے جو اسے کوئی کارآمد فیصلہ کرنے کے لیے چاہیے۔

Marking a failure as an empty success hides it; killing the entire run on one subagent timeout throws away recoverable progress. Neither is acceptable.

ناکامی کو خالی کامیابی دکھانا اسے چھپا دیتا ہے؛ ایک ایجنٹ کے timeout پر پورا چکر بند کرنا سنبھلنے والی پیش رفت گنوا دیتا ہے۔ دونوں قابلِ قبول نہیں۔

Give the coordinator enough to act: the failure category, the exact query tried, anything partial that was gathered, and suggested alternatives. That's the difference between smart recovery and a dead-end 'search unavailable'.

بڑے ایجنٹ کو کارروائی کے لیے کافی دیں: ناکامی کی قسم، عین آزمائی گئی کھوج، جو کچھ ادھورا جمع ہوا، اور تجویز کردہ متبادل۔ یہی سمجھدار سنبھلاؤ اور بند گلی والے 'کھوج دستیاب نہیں' میں فرق ہے۔

{ "failure": "timeout",
  "attempted_query": "AI in film production 2024",
  "partial_results": [ ... ],
  "alternatives": ["narrow date range", "try archive source"] }

'I couldn't reach the source' (retry/reroute) and 'the source returned nothing' (a valid empty result) demand opposite responses. Report them as distinct outcomes so the coordinator doesn't retry a successful-but-empty query or treat an outage as 'no data'.

'میں ذریعے تک پہنچ نہ سکا' (دوبارہ کوشش/راستہ بدلو) اور 'ذریعے نے کچھ نہیں لوٹایا' (ایک درست خالی نتیجہ) الٹ ردعمل مانگتے ہیں۔ انہیں الگ نتائج کے طور پر رپورٹ کریں تاکہ بڑا ایجنٹ نہ تو کامیاب-مگر-خالی کھوج دوبارہ کرے، نہ خرابی کو 'ڈیٹا نہیں' سمجھے۔

timeout   -> { "outcome": "access_failure", "action": "retry / reroute" }
0 results -> { "outcome": "empty_success",  "action": "report 'no data'" }
// collapsing both into "unavailable" makes the coordinator retry an empty
// query forever OR report an outage as if the topic simply had no data

Let a subagent retry its own timeouts rather than escalating every blip. Bubble up only what it truly can't resolve — and attach what it tried and any partial results so the coordinator continues instead of restarting.

چھوٹے ایجنٹ کو اپنے timeout خود دوبارہ کوشش کر کے سنبھالنے دیں، ہر جھٹکا آگے نہ بھیجیں۔ صرف وہی اوپر لے جائیں جو وہ واقعی حل نہ کر سکے — اور کی گئی کوشش اور ادھورے نتائج ساتھ دیں تاکہ بڑا ایجنٹ نئے سرے سے شروع کرنے کے بجائے جاری رکھے۔

for attempt in 1..3:              # recover transient timeouts locally
    r = search(q)
    if r.ok: return r
// only after exhausting retries, propagate WITH context:
return { "failure": "timeout", "attempts": 3,
         "partial_results": cached_hits,
         "alternatives": ["narrow date range", "try archive source"] }

When a source was unavailable, say so in the output. Marking which conclusions are well-supported and which topics have holes keeps a partial failure honest instead of silently presenting incomplete research as complete.

جب کوئی ذریعہ دستیاب نہ ہو تو آؤٹ پٹ میں یہ بتائیں۔ یہ نشان زد کرنا کہ کون سے نتائج مضبوط بنیاد پر ہیں اور کن موضوعات میں سوراخ ہیں، ادھوری ناکامی کو ایماندار رکھتا ہے، بجائے اس کے کہ ادھوری تحقیق کو خاموشی سے مکمل دکھایا جائے۔

COVERAGE NOTE:
  ok  Market size    - 3 sources, consistent
  ok  Growth rate    - 2 sources
  !!  Regulatory outlook - source timed out, NOT covered
// the gap is visible; the report doesn't read as complete when it isn't

A tell-tale sign of context degradation is answers drifting from specifics ('the OrderService class') to generalities ('a typical service layer'). When you see it, reground from a scratchpad rather than trusting recall.

سیاق کے بگڑنے کی صاف نشانی یہ ہے کہ جواب مخصوص باتوں ('OrderService کلاس') سے عام باتوں ('ایک عام سروس تہہ') کی طرف بہکنے لگیں۔ جب یہ نظر آئے تو یاد پر بھروسے کے بجائے scratchpad سے دوبارہ ٹکیں۔

Writing key findings to a file lets the agent reload them later, surviving compaction and context limits.

اہم نتائج کسی فائل میں لکھنا ایجنٹ کو بعد میں انہیں دوبارہ لوڈ کرنے دیتا ہے، جو سکڑاؤ اور سیاق کی حدوں کے باوجود قائم رہتے ہیں۔

For robustness, have each agent write its state to a known path and a coordinator load a manifest on resume — so a crash doesn't force full re-exploration.

مضبوطی کے لیے ہر ایجنٹ اپنی حالت ایک معلوم راستے پر لکھے اور بڑا ایجنٹ دوبارہ شروع پر ایک manifest لوڈ کرے — تاکہ کریش پوری کھوج دوبارہ کرنے پر مجبور نہ کرے۔

Delegate narrow, verbose lookups to subagents so their file dumps stay in isolated contexts and only a summary returns. The main agent keeps its window for coordination instead of drowning in discovery output.

تنگ، لمبی کھوجیں چھوٹے ایجنٹوں کو سونپیں تاکہ ان کے فائل ڈھیر الگ سیاق میں رہیں اور صرف خلاصہ واپس آئے۔ اصل ایجنٹ اپنا window کھوج کے آؤٹ پٹ میں ڈوبنے کے بجائے انتظام کے لیے بچا لیتا ہے۔

Task(subagent, "Find every *.test.ts and list the modules each covers")
Task(subagent, "Trace the refund flow: entrypoint -> services -> DB")
// each subagent's raw file dumps stay in ITS context;
// only the compact summary returns to the main agent

Write important findings (class names, flow traces) to a file the agent can re-read. The scratchpad survives compaction and context limits, so the agent regrounds from recorded facts instead of hazy recall.

اہم نتائج (کلاس نام، بہاؤ کے سراغ) ایسی فائل میں لکھیں جسے ایجنٹ دوبارہ پڑھ سکے۔ scratchpad سکڑاؤ اور سیاق کی حدوں کے باوجود رہتا ہے، تاکہ ایجنٹ دھندلی یاد کے بجائے لکھی باتوں سے دوبارہ ٹکے۔

# findings.md  (re-read after any compaction)
- OrderService.refund() -> PaymentGateway.reverse()
- refund cap enforced in policy.py:42
- double-charge bug reproduced in test_billing.py::test_dupe
// later: agent re-reads exact names instead of "a typical service layer"

Close each phase with a compact summary and seed the next phase's subagents with it. This hands forward exactly what's needed without dragging the whole prior transcript into every new context.

ہر مرحلہ ایک مختصر خلاصے پر ختم کریں اور اگلے مرحلے کے ایجنٹوں کو وہی دیں۔ یہ صرف ضروری چیز آگے دیتا ہے بغیر پوری پرانی گفتگو کو ہر نئے سیاق میں گھسیٹے۔

PHASE 1 SUMMARY (seed for phase 2):
- refund flow spans 3 services: Order, Payment, Ledger
- entrypoint: routers/quiz.py; writes at ledger.py:88

Task(phase2_subagent, context=<summary above>, "audit Ledger writes for races")
// phase 2 starts with the distilled facts, not the whole phase-1 transcript

Have each agent export its state to a known path and record it in a manifest the coordinator loads on resume. A crash then costs only the in-flight step, not a full re-exploration of the codebase.

ہر ایجنٹ اپنی حالت ایک معلوم راستے پر محفوظ کرے اور اسے اُس manifest میں درج کرے جو بڑا ایجنٹ دوبارہ شروع پر لوڈ کرتا ہے۔ پھر کریش صرف چلتے ہوئے قدم کا نقصان کرتا ہے، پورے کوڈ کی دوبارہ کھوج کا نہیں۔

# each agent writes to a known path
/state/agent-3.json  { "phase": 2, "explored": [...], "pending": ["ledger.py"] }
# manifest lists them; coordinator loads it on resume
/state/manifest.json  { "agents": ["agent-1", "agent-2", "agent-3"] }
// after a crash: resume from 'pending', not from zero

/compact condenses the conversation to reclaim context budget during long exploration sessions.

/compact گفتگو کو سکیڑ کر لمبی کھوج کے سیشنز میں سیاق کا بجٹ واپس حاصل کرتا ہے۔

// context filling with verbose file dumps and search output:
[context 92% full]
/compact
// conversation condensed to key findings + decisions;
// discovery noise dropped, budget reclaimed to keep exploring

A headline 97% can hide that one document type or one field is only 70% accurate. Segment the metric before you trust it to automate.

سرخی والا ۹۷٪ یہ چھپا سکتا ہے کہ کوئی ایک دستاویز کی قسم یا خانہ صرف ۷۰٪ درست ہے۔ خودکار کرنے پر بھروسے سے پہلے پیمانے کو الگ الگ حصوں میں توڑیں۔

Sampling across strata (doc types, field types) surfaces error patterns an overall average would miss, including new failure modes.

الگ الگ تہوں (دستاویز کی اقسام، خانوں کی اقسام) میں نمونہ گیری وہ خرابیوں کے انداز سامنے لاتی ہے جو مجموعی اوسط چھوڑ دیتی، بشمول ناکامی کی نئی صورتیں۔

Have the model emit per-field confidence, then calibrate the thresholds against a labeled set so 'low confidence' actually correlates with 'more likely wrong'.

ماڈل سے ہر خانے کا اعتماد نکلوائیں، پھر حدوں کو لیبل شدہ ڈیٹا کے مقابلے ٹھیک کریں تاکہ 'کم اعتماد' واقعی 'زیادہ امکان غلط' سے جُڑا ہو۔

Sample across strata (document types, field types) rather than uniformly, so you actually measure the error rate inside 'high-confidence' output and catch novel failure modes an overall average would smooth over.

یکساں کے بجائے الگ الگ تہوں (دستاویز کی اقسام، خانوں کی اقسام) میں نمونہ لیں، تاکہ آپ 'زیادہ اعتماد' والے آؤٹ پٹ کے اندر بھی غلطی کی شرح واقعی ناپیں اور وہ نئی ناکامیاں پکڑیں جنہیں مجموعی اوسط چھپا دیتی۔

Pull 30 high-confidence extractions PER stratum, then human-check:
  invoices  n=30    receipts  n=30
  contracts n=30    handwritten forms n=30
// uniform sampling would under-cover rare doc types and miss their errors

A 97% headline can hide a document type or field sitting at 70%. Segment the metric first — automate only the slices that are genuinely accurate, and keep humans on the weak ones.

۹۷٪ کی سرخی کسی ۷۰٪ پر بیٹھی دستاویز کی قسم یا خانے کو چھپا سکتی ہے۔ پہلے پیمانے کو حصوں میں توڑیں — صرف اُن حصوں کو خودکار کریں جو واقعی درست ہیں، اور کمزوروں پر انسان رکھیں۔

Overall accuracy: 97%   <- do NOT automate on this alone
  invoices.total ......... 99%  -> automate
  receipts.date .......... 96%  -> automate
  handwritten.amount ..... 71%  -> keep human review
// the 71% slice is invisible in the 97% average

Emit per-field confidence, then tune the thresholds against a labeled validation set so 'low confidence' reliably correlates with 'more likely wrong'. Uncalibrated confidence routes attention to the wrong places.

ہر خانے کا اعتماد نکالیں، پھر حدوں کو لیبل شدہ جانچ ڈیٹا کے مقابلے سدھاریں تاکہ 'کم اعتماد' بھروسے سے 'زیادہ امکان غلط' سے جُڑے۔ بغیر ٹھیک کیا اعتماد توجہ غلط جگہوں کی طرف موڑ دیتا ہے۔

{ "total":  { "value": 49.99,  "confidence": 0.98 },
  "vendor": { "value": "Acme", "confidence": 0.62 } }
// calibrate vs labeled set: are 0.9-confidence fields actually ~90% correct?
// then: auto-accept total (0.98); route vendor (0.62) to review

Send the extractions most likely to be wrong — low confidence, or drawn from ambiguous/conflicting sources — to human review, and order them so limited reviewer time goes to the highest-impact cases first.

جو نتائج زیادہ غلط ہونے کا امکان رکھیں — کم اعتماد، یا مبہم/متضاد ذرائع سے آئے — انہیں انسانی جائزے کو بھیجیں، اور انہیں اس ترتیب میں رکھیں کہ جائزہ لینے والے کا محدود وقت پہلے سب سے زیادہ اثر والے معاملوں پر لگے۔

review_queue = extractions
    .filter(conf < 0.8 OR source_conflict)
    .sort_by(impact, desc)     # dollar amounts / legal fields first
// scarce reviewer capacity spent on the uncertain, high-stakes items

If summarization compresses findings without carrying the source with each claim, citations vanish and you can't trace where a fact came from. Keep claim and source bound together.

اگر خلاصہ نتائج کو دباتے ہوئے ہر دعوے کے ساتھ ذریعہ نہ لے جائے تو حوالے غائب ہو جاتے ہیں اور آپ سراغ نہیں لگا سکتے کوئی بات کہاں سے آئی۔ دعوے اور ذریعے کو جوڑے رکھیں۔

Two credible sources disagreeing is information, not a bug. Surface both values WITH their sources rather than silently choosing one.

دو معتبر ذرائع کا اختلاف معلومات ہے، خرابی نہیں۔ خاموشی سے کسی ایک کو چننے کے بجائے دونوں قدریں ان کے ذرائع کے ساتھ دکھائیں۔

Growth estimate: 40% (SourceA, 2024) vs 28% (SourceB, 2023) — figures differ; both retained with attribution.

A 2021 figure and a 2024 figure may both be correct for their year. Requiring dates prevents the synthesizer from flagging a false contradiction.

۲۰۲۱ کا عدد اور ۲۰۲۴ کا عدد دونوں اپنے اپنے سال کے لیے درست ہو سکتے ہیں۔ تاریخیں لازمی کرنا ملانے والے کو ایک جھوٹا تضاد نشان زد کرنے سے روکتا ہے۔

Bind every claim to its source (URL, doc name, excerpt) at extraction time and carry that pairing through synthesis. If summarization compresses claims without their sources, citations vanish and nothing is traceable.

ہر دعوے کو نکالتے وقت اس کے ذریعے سے باندھیں (URL، دستاویز کا نام، اقتباس) اور یہ جوڑ ملانے تک ساتھ رکھیں۔ اگر خلاصہ دعووں کو ان کے ذرائع کے بغیر دبا دے تو حوالے غائب اور کچھ بھی قابلِ سراغ نہیں رہتا۔

{ "claim": "Adoption grew 40% in 2024",
  "source": "https://example.org/report",
  "excerpt": "...grew by 40 percent..." }

Split the report into what's solidly supported versus what's disputed, and preserve how each source framed its finding plus how it was measured. Readers can then weigh contested claims instead of seeing everything flattened to equal certainty.

رپورٹ کو دو حصوں میں بانٹیں: جو مضبوط بنیاد پر ہے اور جو متنازعہ ہے، اور یہ محفوظ رکھیں کہ ہر ذریعے نے اپنا نتیجہ کیسے پیش کیا اور کیسے ناپا۔ پھر پڑھنے والے متنازعہ دعووں کو تول سکتے ہیں، بجائے اس کے کہ سب کچھ برابر یقین پر چپٹا نظر آئے۔

## Well-established
- Market reached $2B in 2024 (3 concordant sources)
## Contested
- Growth rate: 40% (SourceA) vs 28% (SourceB)
  method: A measures YoY revenue; B measures user count
// contested findings aren't flattened to look as certain as the settled ones

When credible sources disagree, surface both values with attribution rather than silently picking one — the disagreement is information. Leave the reconciliation to the coordinator (or a human), which may decide dates explain the gap.

جب معتبر ذرائع اختلاف کریں، تو خاموشی سے کسی ایک کو چننے کے بجائے دونوں قدریں حوالے کے ساتھ دکھائیں — یہ اختلاف خود معلومات ہے۔ ملانے کا کام بڑے ایجنٹ (یا انسان) پر چھوڑیں، جو طے کر سکتا ہے کہ تاریخیں اس فرق کی وجہ ہیں۔

{ "metric": "2024 growth",
  "values": [ { "v": "40%", "source": "A", "date": "2024" },
              { "v": "28%", "source": "B", "date": "2023" } ],
  "resolution": "deferred to coordinator" }
// don't delete one value to 'resolve' it - the conflict is a signal

Mandating publication/collection dates stops the synthesizer from misreading a 2021 figure vs a 2024 figure as a contradiction. Match the rendering to the content — tables for financials, prose for news, lists for technical steps — so the format aids comprehension.

اشاعت/جمع کرنے کی تاریخیں لازمی کرنا ملانے والے کو ۲۰۲۱ اور ۲۰۲۴ کے اعداد کو تضاد سمجھنے سے روکتا ہے۔ پیشکش کو مواد کے مطابق رکھیں — مالیات کے لیے جدول، خبروں کے لیے عبارت، تکنیکی قدموں کے لیے فہرست — تاکہ فارمیٹ سمجھنے میں مدد دے۔

Require a date on every claim:
  { "revenue": "$2B", "as_of": "2024-Q2", "source": "10-K" }
Render by content type:
  financials -> table   news -> prose   procedures -> numbered list
// dated: a 2021 figure next to a 2024 figure no longer reads as a contradiction