مواد پر جائیں

زیر حکمرانی کام کی پانچ سطحیں

Threada ایک workspace کو پانچ surfaces میں تقسیم کرتا ہے: intent، canvas، evidence، controls، اور run log۔ ہر surface کا مقصد اور اس تقسیم کی اہمیت یہاں ہے۔

work-orchestration • workspace • governance • product

خالی chat box consequential work چلانے کی اچھی جگہ نہیں۔ یہ پانچ بہت مختلف سوالات کو ایک غیر جدا stream میں گرا دیتا ہے: آپ کیا چاہتے ہیں، آپ کیا دیکھ رہے ہیں، یہ کس پر مبنی ہے، آپ کو کیا کرنے کی اجازت ہے، اور پہلے کیا ہو چکا ہے۔ casual tasks کے لیے یہ ٹھیک ہو سکتا ہے۔ مگر governed operations میں، جہاں actions systems of record کو touch کرتے ہیں اور decisions قابل دفاع ہونے چاہئیں، یہی collapse وہ چیز ہے جس کی آپ afford نہیں کر سکتے۔

Threada کا workspace جان بوجھ کر پانچ surfaces میں تقسیم ہے۔ ہر surface ان میں سے ایک سوال کا جواب دیتی ہے، اور انہیں distinct رکھنا ہی کام کو reviewable بناتا ہے۔

1. intent bar: آپ کیا چاہتے ہیں؟

Threada میں کام deep navigation کے بجائے persistent intent bar سے شروع ہوتا ہے۔ آپ natural language میں outcome بیان کرتے ہیں، کبھی structured commands کے ساتھ، اور runtime اسے structured، executable artifact میں بدلتا ہے: ایسا WorkItem جس میں extracted entities، confidence score، اور risk flags ہوں۔

یہ intent-first interaction ہے۔ operator کو پہلے یہ جاننے پر مجبور کرنے کے بجائے کہ کون سا form، queue، یا workflow لگتا ہے، system goal capture کرتا ہے اور path assemble کرتا ہے۔ جب information missing ہو، یہ شروع ہی میں لمبا static wizard دکھانے کے بجائے عین وہی چیز پوچھتا ہے جس کی ضرورت ہو۔

2. adaptive canvas: آپ کس پر کام کر رہے ہیں؟

canvas وہ جگہ ہے جہاں WorkItem رہتا اور شکل لیتا ہے۔ یہ adaptive ہے: UI missing context collect کرنے اور task مکمل کرنے کے لیے temporary forms، comparisons، اور decision panels assemble کر سکتی ہے، بجائے اس کے کہ ہر قسم کے کام کے لیے ایک fixed layout render کرے۔

generated output کا default editable draft ہے، committed change نہیں۔ operator review، edit، اور decide کرتا ہے۔ control affordances واضح ہیں: lock اور no-change zones، side-by-side compare، fast undo، اور version rollback۔ اس لیے canvas deliberation کی جگہ ہے، نہ کہ ایسی جگہ جہاں model کی پہلی guess truth بن جائے۔

3. evidence drawer: یہ کس پر مبنی ہے؟

ہر consequential output کو اپنا کام دکھانے کے قابل ہونا چاہیے۔ evidence drawer وہ citations، retrieval traces، اور source attribution رکھتا ہے جو WorkItem کو ground کرتے ہیں۔ جب system کسی answer کو ground نہ کر سکے تو confidence invent کرنے کے بجائے fallback reason صاف بتاتا ہے۔

یہ surface “AI پر trust کریں” کو inspectable claim بناتی ہے، faith کا leap نہیں۔ operator کو draft پر اندھا یقین کرنے کی ضرورت نہیں؛ وہ drawer کھول کر دیکھ سکتا ہے کہ draft کس پر کھڑا تھا، sources کتنے fresh تھے، اور ہر claim کہاں سے آیا۔

4. action controls: آپ کیا کر سکتے ہیں؟

Reading اور drafting محفوظ ہیں۔ دنیا پر action لینا ایسا نہیں، اس لیے controls surface governed ہے۔ یہی وہ جگہ ہے جہاں proposals approvals بنتی ہیں اور approvals external systems کے خلاف executed actions بنتی ہیں: refund، ticket، record update، access grant۔

یہاں governance policy کی صورت میں ظاہر ہوتی ہے: permissions، thresholds، approval gates، اور redlines؛ scattered settings toggles کی صورت میں نہیں۔ high-risk actions explicit proposed، approved، executing progression سے گزرتے ہیں، اور صرف وہاں auto-execute ہوتے ہیں جہاں policy اجازت دے۔ service-level kill switch کسی connector کے call ہونے سے پہلے execution روک سکتا ہے، state کو review کے لیے محفوظ رکھتے ہوئے۔ controls surface وہ جگہ ہے جہاں system کی احتیاط concrete بنتی ہے۔

5. run log: کیا ہو چکا ہے؟

run log WorkItem کی timeline ہے: ہر transition، ہر approval، ہر action، ہر AI participant event، ترتیب کے ساتھ۔ یہی surface receipts کو history میں جمع کرتی ہے۔

اہم بات یہ ہے کہ AI actions distinct actor events کے طور پر appear ہوتے ہیں، human activity میں fold نہیں ہوتے۔ run log پڑھتے وقت آپ دیکھ سکتے ہیں کس نے propose کیا، کس نے approve کیا، اور کیا execute ہوا: human یا agent، guessing کے بغیر۔ run log وہ چیز ہے جو auditor quarter کے آخر میں پڑھتا ہے اور operator آج اپنے سامنے کے case کو سمجھنے کے لیے پڑھتا ہے۔

تقسیم ہی اصل نکتہ ہے

ایک surface بنانا اور سب کچھ blur ہونے دینا آسان ہوتا۔ ایسا نہ کرنے کی وجہ یہ ہے کہ consequential work میں یہ سوالات الگ رکھنے پڑتے ہیں۔

اگر intent، evidence، اور action ایک ہی surface پر ہوں تو ایسی چیز پر act کرنا آسان ہو جاتا ہے جسے آپ نے کبھی ground نہیں کیا، یا ایسی چیز approve کرنا جس کی basis آپ نے دیکھی ہی نہیں۔ ہر ایک کو اپنی surface دے کر Threada careful path کو natural path بناتا ہے: intent بیان کریں، canvas پر draft shape کریں، evidence check کریں، پھر governed controls سے act کریں، اور run log سب کچھ record کرے۔

پانچ surfaces packs اور roles کے پار constant رہتی ہیں؛ ان کے اندر کا مواد adapt ہوتا ہے۔ یہ stability deliberate ہے۔ جس operator نے ایک workspace کی shape سیکھ لی، اس نے سب کی shape سیکھ لی: چاہے وہ IT access provisioning چلا رہا ہو، vendor security review، یا procurement approval۔ کام بدلتا ہے۔ اس کے بارے میں سوچنے کا طریقہ نہیں بدلتا۔