Google کا نیا Open Knowledge Format کیا ہے

کسی coding agent کو ایک حقیقی repository پر لگائیں اور دیکھیں کہ وہ ایک بھی لائن لکھنے سے پہلے حقیقت میں کیا کرتا ہے: وہ فائلیں پڑھتا ہے، callers تلاش کرنے کے لیے grep چلاتا ہے، متعلقہ چند modules کھولتا ہے، اور — ہر ایک task کے لیے، ہر بار — ازسرِنو ایک ذہنی نقشہ بناتا ہے کہ آپ کا codebase آپس میں کیسے جڑا ہوا ہے۔ یہ کام مفت نہیں ہوتا۔ یہ tokens ہیں، اور کسی بھی معقول سائز کی repo میں یہ بہت زیادہ ہوتے ہیں، جو انہی ساختی حقائق کو دوبارہ اخذ کرنے میں خرچ ہوتے ہیں جنہیں آپ کی ٹیم پہلے ہی جانتی ہے اور ایک بار لکھ کر محفوظ کر سکتی تھی۔

زیادہ تر ٹیمیں اسے retrieval کا مسئلہ سمجھتی ہیں اور فوراً RAG کی طرف جاتی ہیں۔ یہی وہ عام غلطی ہے جس کے خلاف یہ پوسٹ دلیل دیتی ہے۔ Google Cloud کا نیا Open Knowledge Format، جو June 2026 میں جاری ہوا، ایک بالکل مختلف مفروضے پر بنایا گیا ہے: آپ کے system کے بارے میں کچھ معلومات — کوئی service کیا کرتی ہے، کن چیزوں پر انحصار کرتی ہے، اس کی ownership کس کے پاس ہے — اتنی مستحکم ہوتی ہیں کہ انہیں ہر query پر دوبارہ اخذ نہیں کیا جانا چاہیے۔ انہیں source code کی طرح ایک بار compile کر کے پھر reuse کیا جانا چاہیے۔ خود spec تقریباً کچھ بھی نہیں: ایک required field، plain Markdown، کوئی SDK نہیں۔ اصل engineering مسئلہ، جسے format کی ہر وضاحتی تحریر چھوڑ دیتی ہے، یہ ہے کہ جب ٹیم روزانہ درجنوں commits بھیج رہی ہو تو اس compiled knowledge کو درست کیسے رکھا جائے۔ یہ پوسٹ دراصل اسی کی رہنمائی کرتی ہے۔

آپ یہ سیکھیں گے:

• OKF حقیقت میں کس چیز کو standardize کرتا ہے، اور spec جان بوجھ کر کتنی minimal ہے
• codebase کے مستحکم، curated حصے کے لیے compiled context کیوں RAG سے بہتر ہے — اور کہاں RAG اب بھی جیتتا ہے
• OKF کی ایک “concept” فائل Google کے اصل BigQuery-table استعمال کے بجائے حقیقی code سے کیسے map ہوتی ہے
• git-hook سے trigger ہونے والی enrichment pipeline کیسے بنائی جائے جو graph کو آپ کی repo کے ساتھ sync سے باہر جانے سے بچائے
• progressive disclosure کیسے knowledge bundle کو multi-agent workflows کے لیے ایک حقیقی token-budget control میں بدل دیتی ہے
• اتنی نئی spec کی حقیقی حدود کیا ہیں، اور یہ کیسے فیصلہ کریں کہ اسے ابھی اپنانا فائدہ مند ہے یا نہیں

فہرستِ مضامین

1. بنیادی باتیں
2. مکمل architecture
3. بنیادی تہوں کی وضاحت
4. ابتدا سے انتہا تک walkthrough
5. خصوصی صورتیں
6. scaling اور production چیلنجز
7. code کی مثالیں
8. عام غلطیاں
9. production کی بہترین عملی حکمتِ عملیاں

بنیادی باتیں

OKF حقیقت میں کیا چیز کور کرتا ہے

Open Knowledge Format curated knowledge کو plain Markdown فائلوں کی ایک directory کے طور پر YAML frontmatter کے ساتھ ظاہر کرنے کی specification ہے، جسے Google Cloud کی data team نے June 2026 میں شائع کیا۔ یہ ایک ایسے pattern کو رسمی شکل دیتا ہے جو پہلے ہی ecosystem میں فطری طور پر ابھر چکا تھا — Andrej Karpathy کا وسیع پیمانے پر شیئر ہونے والا “LLM wiki” خیال، AGENTS.md convention جو اب دسیوں ہزار open-source projects میں استعمال ہو رہی ہے، اور developers کا Obsidian-style vaults کو براہِ راست coding agents کے ساتھ جوڑنا۔ OKF کوئی نیا substrate ایجاد نہیں کرتا؛ یہ اسی چیز کو standardize کرتا ہے جو پہلے ہی جیت چکی تھی: Markdown، frontmatter، اور Git۔

ایک “concept” بنیادی اکائی ہے — ایک فائل، علم کا ایک حصہ، اور فائل کا path ہی اس کی شناخت ہے، لہٰذا sync میں رکھنے کے لیے کوئی الگ ID system موجود نہیں۔ تجویز کردہ frontmatter fields کی مختصر سی فہرست میں سے صرف ایک field لازمی ہے: type۔ باقی سب کچھ — title، description، resource link، tags، timestamp — اختیاری ہے۔ یہ minimalism کسی بھول کا نتیجہ نہیں؛ یہی مکمل design philosophy ہے۔ یہ ایک wire format ہے، platform نہیں، اور spec جان بوجھ کر اس بارے میں نرم ہے کہ وہ کیا برداشت کرتی ہے: غیر پہچانے گئے types، غائب اختیاری fields، حتیٰ کہ ٹوٹے ہوئے links بھی ایسی چیزیں ہیں جنہیں conformant consumer کو مسترد کرنے کے بجائے قبول کرنا ہوتا ہے۔

یہ حل کرنے کے لیے اتنا قیمتی مسئلہ کیوں ہے

• Token costs ہر agent، ہر task، اور ہر teammate کے ساتھ بڑھتی جاتی ہیں۔ codebase کے بارے میں وہی ساختی حقائق بار بار اخذ کرنا ایک وقتی خرچ نہیں — یہ ہر interaction پر لگنے والا مسلسل ٹیکس ہے۔
• اس مخصوص قسم کے علم کے لیے متبادل دونوں ہی ناقص ہیں۔ ایک سادہ full-repo dump چھوٹے codebase سے آگے scale نہیں کرتا، اور RAG raw documents سے query کے وقت، ہر بار، ایسے علم کے لیے تعلقات دوبارہ اخذ کرتا ہے جو حقیقت میں اتنی بار بدلتا بھی نہیں۔
• باسی context صرف سست نہیں ہوتا — یہ فعال طور پر غلط بھی ہوتا ہے۔ کوئی agent اگر کسی service کی dependencies کا پرانا ذہنی نقشہ لے کر کام کرے تو وہ صرف tokens ضائع نہیں کرتا؛ وہ ایسی تبدیلیاں بھی کر سکتا ہے جو کسی ایسی چیز کو توڑ دیں جس کے متعلق اسے معلوم ہی نہ ہو کہ وہ جڑی ہوئی ہے۔

مکمل architecture

Commit Pushed
      │
      ▼
Diff-Scoped Scan  (which services/modules actually changed?)
      │
      ▼
Draft / Update Concept Docs  (two-pass enrichment agent)
      │
      ▼
Re-link Cross-References  (update dependency/responsibility links)
      │
      ▼
Lint  (spec-compliance rules)
      │
      ▼
Publish  (commit the bundle, push to CI, or register to a catalog)

رہنما اصول یہ ہے: مستحکم knowledge کو ایک بار compile کریں، تاکہ agents اسے ہر task پر دوبارہ اخذ کرنا بند کر دیں۔ خود OKF کی اس بارے میں کوئی رائے نہیں کہ یہ compilation کیسے ہوتی ہے یا current کیسے رہتی ہے — یہ حصہ مکمل طور پر اپنانے والے پر چھوڑ دیا گیا ہے، اور اسی اصل engineering کام پر یہ پوسٹ توجہ دیتی ہے۔

بنیادی تہوں کی وضاحت

1. Concept فائل

یہ کیا ہے: ایک واحد Markdown فائل جو علم کی ایک اکائی — جیسے service، API، table، runbook — کی نمائندگی کرتی ہے، جس کے اوپر ایک مختصر YAML frontmatter block ہوتا ہے اور اس کے نیچے آزاد طرز کا Markdown body۔

یہ کیوں اہم ہے: کیونکہ فائل کا path ہی شناخت ہے، اس لیے کسی الگ ID system اور علم کے اصل مقام کے درمیان reconcile کرنے کو کچھ نہیں رہتا — filesystem خود index بن جاتا ہے۔

---
type: Service
title: billing-service
description: Handles subscription billing, invoicing, and payment webhooks.
resource: https://github.com/yourorg/monorepo/tree/main/services/billing
tags: [billing, payments, python]
timestamp: 2026-08-01T10:00:00Z
---
# Responsibilities
Owns the Invoice and PaymentEvent domain models.

# Dependencies
- Calls customer-service to resolve account state.
- Publishes events consumed by notifications-service.

Production tip: اصل use case کی structure کو سوچ سمجھ کر mirror کریں — resource میں BigQuery console URL کی جگہ repo path رکھیں، اور data کے # Schema section کی جگہ code-oriented # Responsibilities / # Dependencies structure استعمال کریں۔ concept فائلوں میں body structure کی consistency، agent consumption کے لیے، کسی ایک field سے زیادہ اہم ہے۔

2. index.md اور Progressive Disclosure

یہ کیا ہے: ایک reserved filename جو bundle کے کسی بھی level پر directory listing کے طور پر کام کرتا ہے — وہ entry point جسے agent کسی اور چیز کو چھیڑنے سے پہلے پڑھتا ہے۔

یہ کیوں اہم ہے: یہ سہولت کی فائل نہیں بلکہ حقیقی token-budget control ہے۔ ایک orchestrating agent index.md پڑھتا ہے، فیصلہ کرتا ہے کہ کسی مخصوص subtask کو کن concept files کی واقعی ضرورت ہے، اور صرف وہی load کرتا ہے — کسی ایک service کو چھونے والی تبدیلی کے لیے کوئی بھی پورا bundle context میں نہیں لاتا۔

Production tip: index entries کو ہر concept کے frontmatter سے لی گئی title اور ایک سطری description تک محدود رکھیں۔ تفصیل سے پھولا ہوا index اپنے وجود کا مقصد ہی ختم کر دیتا ہے۔

3. log.md اور تبدیلیوں کی تاریخ

یہ کیا ہے: ایک اور reserved filename — تاریخ وار، دنوں کے مطابق منظم ریکارڈ کہ bundle جو جانتا ہے اس میں کیا بدلا، جو git log سے الگ ہے کیونکہ git log صرف code میں ہونے والی تبدیلیاں محفوظ کرتا ہے۔

یہ کیوں اہم ہے: “اس فائل میں کیا بدلا” اور “اس system کے بارے میں ہماری سمجھ میں کیا بدلا” دو مختلف سوالات ہیں۔ کسی service کا code بدل سکتا ہے بغیر اس کی documented responsibilities بدلے، اور اس کے برعکس بھی — ایک log.md agent (یا انسان) کو دوسرا سوال براہِ راست جواب دینے دیتا ہے، بجائے اس کے کہ وہ commit history سے اندازہ لگائے۔

4. Dependency Graph کے طور پر Cross-Links

یہ کیا ہے: concept فائلوں کے درمیان عام relative Markdown links، جن میں تعلق کا مطلب کسی formal schema کے بجائے اردگرد کے متن سے آتا ہے۔

یہ کیوں اہم ہے: یہ links ایک flat directory کو سادہ folder hierarchy کے بجائے dependency graph کے زیادہ قریب چیز میں بدل دیتے ہیں — billing-service ہر اس چیز کی طرف اشارہ کر سکتی ہے جسے وہ call کرتی ہے اور ہر اس چیز کی طرف بھی جہاں وہ publish کرتی ہے، اس سے قطع نظر کہ وہ services repo tree میں کہاں واقع ہیں۔

Production tip: چونکہ links صرف Markdown ہیں اور spec consumers سے مطالبہ کرتی ہے کہ وہ ٹوٹے ہوئے links بھی برداشت کریں، اس لیے اسے اپنے call graph کے حقیقی static analysis کا متبادل نہ سمجھیں۔ یہ dependency graph کا ایک curated، انسان اور agent دونوں کے لیے قابلِ مطالعہ خلاصہ ہے، باضابطہ طور پر verified ورژن نہیں۔

5. Enrichment Agent Pipeline

یہ کیا ہے: وہ حصہ جسے OKF جان بوجھ کر غیر متعین چھوڑتا ہے — وہ process جو code بدلنے کے ساتھ concept فائلوں کا draft تیار کرتی ہے اور انہیں برقرار رکھتی ہے۔ reference pattern دو passes پر مشتمل ہے: ایک pass جو بدلی ہوئی services پر چلتی ہے اور ان کے interfaces اور structure سے concept file کا draft بناتی یا update کرتی ہے، اور دوسری جو موجودہ documentation، runbooks، اور PRs کی citations واپس شامل کرتی ہے۔

یہ کیوں اہم ہے: OKF اپنانے کے پیچھے یہی اصل engineering کام ہے۔ خود format کا prototype بنانا تقریباً مفت ہے — ایک required field، کوئی SDK نہیں۔ لیکن جب ٹیم روزانہ درجنوں commits بھیج رہی ہو تو ہزار فائلوں کے bundle کو درست رکھنا اصل systems problem ہے، اور اس کا حل spec نہیں بلکہ آپ کو خود نکالنا ہوتا ہے۔

Production tip: ہر enrichment pass کو پوری repository کے بجائے git diff تک محدود رکھیں۔ ہر commit پر full-repo re-scan ہی چیز کو مہنگا بناتی ہے؛ صرف بدلی ہوئی services کی diff-scoped scan ہی اسے اتنا سستا بناتی ہے کہ ہر push پر چلایا جا سکے۔

6. Tooling: Init, Hooks, Search, and Lint

یہ کیا ہے: ایک open-source CLI (Google سے آزاد، Go میں لکھی گئی) جو bundle scaffold کرتی ہے، git hook install کرتی ہے تاکہ updates خودکار طور پر جاری رہیں، concepts پر keyword search فراہم کرتی ہے، اور built-in spec-compliance rules کا ایک مجموعہ نافذ کرتی ہے۔

یہ کیوں اہم ہے: آپ کو automation layer صفر سے نہیں بنانی پڑتی — “commit پر scan کرو، جو بدلا اسے refresh کرو، اس پر اعتماد کرنے سے پہلے lint کرو” والی ساخت موجودہ tooling سے پہلے ہی ثابت شدہ ہے، چاہے ecosystem ابھی اتنا ابتدائی ہی کیوں نہ ہو۔

Production tip: اپنے CI کے agents کو bundle پر عمل کرنے دینے سے پہلے lint کو hard gate کے طور پر چلائیں۔ چونکہ spec خود missing fields اور broken links کے بارے میں بہت نرم ہے، اس لیے “technically conformant” اور “actually useful” کے درمیان lint ہی واحد رکاوٹ ہے۔

ابتدا سے انتہا تک walkthrough

ایک commit کو مکمل pipeline میں trace کریں:

1. ایک developer billing-service میں تبدیلی push کرتا ہے، جس میں fraud-check service پر نئی dependency شامل کی جاتی ہے۔
2. git hook چلتی ہے اور diff-scoped scan trigger کرتی ہے — صرف billing-service اور وہ چیزیں جنہیں diff نے براہِ راست چھیڑا ہو دوبارہ دیکھی جاتی ہیں، پوری repository نہیں۔
3. enrichment agent کی پہلی pass update کا draft بناتی ہے، service کا نیا interface اور call sites پڑھتی ہے، اور billing-service.md کے # Dependencies section کو دوبارہ لکھتی ہے تاکہ fraud-check service شامل ہو جائے۔
4. دوسری pass citations شامل کرتی ہے، تبدیلی کو کسی موجودہ runbook یا PR description سے cross-reference کرتی ہے جو یہ بتاتی ہو کہ dependency کیوں شامل کی گئی، اور ان کے links لگا دیتی ہے۔
5. cross-references دونوں طرف update ہوتے ہیں — billing-service.md اب fraud-check concept file سے link کرتی ہے، اور اگر اس فائل کا # Dependents section موجود ہو تو وہ بھی واپس اشارہ کرنے کے لیے update ہوتا ہے۔
6. Lint چلتی ہے updated bundle پر، frontmatter validity چیک کرتی ہے اور وہ سب کچھ پکڑتی ہے جو enrichment pass نے ساختی طور پر غلط کر دیا ہو۔
7. bundle publish ہو جاتا ہے — code change کے ساتھ commit کر دیا جاتا ہے، یا CI کے ذریعے کسی served location پر push کر دیا جاتا ہے۔
8. اگلے دن، ایک orchestrator agent fraud-check service سے متعلق ایک غیر متعلقہ task اٹھاتی ہے۔ وہ index.md پڑھتی ہے، concept file دیکھتی ہے، صرف وہی ایک فائل load کرتی ہے — جس میں billing-service کی طرف اس کا اب تازہ link بھی شامل ہے — اور تعلق سمجھنے کے لیے اسے دونوں codebases کو ازسرِنو scan کرنے کی کبھی ضرورت نہیں پڑتی۔

خصوصی صورتیں

جہاں OKF ختم ہوتا ہے اور RAG شروع ہوتا ہے۔ OKF codebase knowledge کے مستحکم، curated حصے کے لیے ہے — services، ownership boundaries، dependency graphs، وہ runbooks جنہیں کسی نے واقعی لکھنے کی زحمت کی۔ RAG اب بھی long tail کے لیے درست tool ہے: ایک بار کے design docs، Slack threads، پرانے tickets — ہر وہ چیز جو اتنی غیر منظم ہو یا اتنی کم حوالہ دی جاتی ہو کہ اسے concept file میں curate کرنا جائز نہ ہو۔ OKF کو RAG replacement سمجھنا غلط زاویہ ہے؛ اسے ایک compiled cache سمجھنا جو RAG کو مستحکم حقائق دوبارہ اخذ کرنے سے بچاتی ہے، یہی درست زاویہ ہے۔

Multi-team monorepos اور type drift۔ چونکہ type producer-defined ہے اور کوئی external registry نہیں، ایک ہی bundle میں حصہ ڈالنے والی مختلف ٹیمیں فطری طور پر drift کریں گی — ایک ٹیم کا “API Endpoint” دوسری کی نظر میں “Route” ہو سکتا ہے۔ spec میں کوئی چیز اسے روکتی نہیں؛ صرف آپ کے اپنے lint rules اور conventions ہی معیار قائم رکھ سکتے ہیں۔

Governed metrics اور certified computations۔ spec میں ایک concept type شامل ہے جسے وہ “attested computation” کہتی ہے — کسی value کو compute کرنے کا منظور شدہ، قابلِ جانچ طریقہ، جو محض اس value کے معنی کی documentation سے الگ ہے۔ جن ٹیموں کے metrics میں کیسے calculate کیا جاتا ہے اس کے لیے واحد source of truth درکار ہو، نہ کہ صرف یہ کہ وہ کیا represent کرتے ہیں، ان کے لیے یہ کسی عام description میں computation logic ملا دینے کے بجائے الگ concept file کے قابل چیز ہے۔

scaling اور production چیلنجز

Full-repo rescans scale نہیں کرتیں، diff-scoped کرتی ہیں۔ اس pipeline کا پورا cost model اس بات پر منحصر ہے کہ enrichment passes کو صرف اسی چیز تک محدود رکھا جائے جو واقعی بدلی ہے۔ جو ٹیم ہر commit پر سب کچھ دوبارہ scan کرے گی، وہ pipeline کو جاری رکھنا بہت مہنگا پائے گی، اس سے بہت پہلے کہ اس کی repo اتنی بڑی ہو کہ اسے حقیقتاً اس کی ضرورت پڑے۔

Progressive disclosure کو آپ کی orchestration layer میں design کرنا پڑتا ہے، اسے خودبخود فرض نہیں کیا جا سکتا۔ index.md کا token-budget فائدہ تبھی سامنے آتا ہے جب آپ کا orchestrating agent واقعی پہلے index پڑھنے اور پھر concept files کو منتخب انداز میں load کرنے کے لیے بنایا گیا ہو — اگر آپ OKF کو ایسے agent پر جوڑ دیں جو اب بھی پوری directories کو context میں انڈیل دیتا ہے تو آپ کو بچت کے بغیر maintenance cost ملے گی۔

Drift اور governance، scale پر، آسان نہیں بلکہ زیادہ مشکل ہو جاتے ہیں۔ نہ type registry ہے نہ link semantics enforced ہیں، اس لیے چند لوگوں کے ہاتھ سے maintained bundle صرف convention کے بل پر coherent رہ سکتا ہے؛ لیکن درجنوں contributors کے ہاتھ لگنے والا bundle جان بوجھ کر بنائے گئے lint rules اور review discipline مانگتا ہے، ورنہ وہ ایک غیر مستقل، بکھرا ہوا نظام بن جاتا ہے جو technical طور پر spec-conformant تو ہو مگر عملی طور پر ناقابلِ اعتماد۔

یہ ecosystem ابھی بہت ابتدائی مرحلے میں ہے۔ spec June 2026 میں شائع ہوئی، Google کی اپنی reference implementation کے باہر tooling منتشر ہے، اور بڑے، مسلسل بدلتے codebases پر ابھی تک طویل المدت production case studies موجود نہیں۔ صرف اپنے bundle ہی نہیں بلکہ خود spec کے ارتقا کے لیے بھی budget رکھیں۔

code کی مثالیں

bundle scaffold کرنے اور automatic-update hook جوڑنے کے لیے:

okf init
okf hook install
okf search -q "billing"
okf lint

اپنی CI pipeline سے CLI کال کرنے کے لیے ایک minimal Python wrapper:

import subprocess

def okf_lint(bundle_path: str = ".okf/knowledge") -> bool:
    result = subprocess.run(
        ["okf", "lint", bundle_path],
        capture_output=True, text=True,
    )
    if result.returncode != 0:
        print(result.stdout)
    return result.returncode == 0

وہ load-and-search primitives جنہیں آپ کا orchestrator sub-agent dispatch کرنے سے پہلے call کرتا ہے، اور وہ lint check جسے آپ کی CI bundle پر اعتماد کرنے سے پہلے call کرتی ہے:

bundle, err := okf.LoadBundle(".okf/knowledge", nil)
results := bundle.Search("billing")
report := lint.LintBundle(concepts, lint.DefaultConfig())

عام غلطیاں

غلطی: OKF کو RAG replacement سمجھنا۔ غیر منظم، کم حوالہ دی جانے والی knowledge کو curated concept files میں ٹھونسنے کی کوشش format کی پوری بنیاد ہی ناکام کر دیتی ہے۔ حل: OKF کو مستحکم، curated knowledge کے لیے رکھیں اور long tail کے لیے RAG برقرار رکھیں۔

غلطی: ہر commit پر پوری repo دوبارہ scan کرنا۔ pipeline کو ناقابلِ برداشت حد تک مہنگا بنانے کا یہ سب سے تیز طریقہ ہے۔ حل: ہر enrichment pass کو مکمل codebase کے بجائے git diff تک محدود رکھیں۔

غلطی: spec کے نرم ہونے کی وجہ سے lint چھوڑ دینا۔ Spec-conformant ہونا trustworthy ہونے کے برابر نہیں — broken links اور drifted types سے بھرا bundle technical طور پر پھر بھی pass کر سکتا ہے۔ حل: agents کو bundle پر عمل کرنے کی اجازت دینے سے پہلے lint کو hard CI gate کے طور پر چلائیں۔

غلطی: OKF کو اس سے پہلے اپنانا کہ agents حقیقت میں اسے consume کر رہی ہوں۔ پوری value proposition اس بات پر منحصر ہے کہ کوئی bundle کو پڑھ بھی رہا ہو۔ حل: اگر آپ کے workflow میں ابھی structured context consume کرنے والی کوئی چیز نہیں، تو آپ بس ایک ایسی wiki maintain کر رہے ہیں جسے کوئی نہیں پڑھتا — انتظار کریں جب تک آپ کے پاس واقعی agentic workflows نہ ہوں جو اسے استعمال کریں۔

غلطی: citation pass چھوڑ دینا۔ ایک single-pass enrichment agent جو صرف draft بناتی ہو، موجودہ documentation سے cross-reference نہ کرتی ہو، عموماً معقول لگنے والی مگر غیر مصدقہ descriptions پیدا کرتی ہے۔ حل: two-pass structure برقرار رکھیں — پہلے draft، پھر cite — بجائے اس کے کہ پہلی pass کو ہی final مان لیا جائے۔

production کی بہترین عملی حکمتِ عملیاں

• enrichment کو ہمیشہ diff تک محدود رکھیں۔ یہی فرق ہے ایک ایسی pipeline میں جو ہر commit پر چلتی رہتی ہے اور ایک ایسی میں جو پہلے ہی مہنگے ہفتے کے بعد بند کر دی جاتی ہے۔
• اپنے orchestrator کو ابتدا ہی سے progressive disclosure کے گرد design کریں۔ token savings حقیقی ہیں، مگر صرف تب جب کوئی واقعی concept files load کرنے سے پہلے index.md پڑھے۔
• اعتماد کرنے سے پہلے lint کریں۔ missing fields اور broken links کے بارے میں spec کی نرمی کا مطلب یہ ہے کہ governance مکمل طور پر آپ کی ذمہ داری ہے، format کی نہیں۔
• OKF اور RAG کو مقابل نہیں بلکہ تکمیلی tools کے طور پر رکھیں۔ مستحکم، curated knowledge کو OKF کے ذریعے چلائیں اور باقی سب کچھ RAG کے ذریعے۔
• پورے repo کے بجائے اپنی سب سے زیادہ بدلنے والی service سے شروع کریں۔ ایک minimal pipeline — okf init, ایک git hook، اور آپ کی highest-churn service پر ایک enrichment pass — مکمل rollout کے عہد سے پہلے حقیقی token savings ناپنے کے لیے کافی ہے۔

خلاصہ

خود spec واقعی تقریباً کچھ بھی نہیں — ایک required field، plain Markdown، install کرنے کے لیے کوئی SDK نہیں۔ یہی وجہ ہے کہ اسے اپنانا آسان ہے، اور یہی وجہ ہے کہ دلچسپ حصہ یہ نہیں۔ وہ اصل system جسے بنانا قابلِ قدر ہے، enrichment pipeline ہے جو آپ کے codebase کے نیچے مسلسل بدلتے رہنے کے باوجود knowledge graph کو درست رکھتی ہے، اور یہ ایسا engineering مسئلہ ہے جسے کوئی spec پہلے سے حل شدہ صورت میں آپ کے ہاتھ میں نہیں دے سکتی۔ اگر آپ پہلے ہی اپنی repo پر متعدد agents چلا رہے ہیں، تو اس ہفتے اس کا prototype بنانا قابلِ غور ہے — اپنی سب سے زیادہ فعال service پر ایک git hook لگائیں اور یہ فیصلہ کرنے سے پہلے کہ maintenance cost اس قابل ہے یا نہیں، اپنے اگلے multi-agent task پر token delta ناپیں۔

اگر آپ اسے اپنے codebase پر آزمانے لگیں، تو پہلی enrichment pass کو آپ کس پر محدود کریں گے — اپنی سب سے زیادہ بدلنے والی service پر، یا اس پر جس کی dependencies سب سے زیادہ الجھی ہوئی ہیں؟