सामग्रीकडे जा

Governed Work च्या पाच surfaces

Threada workspace ला पाच surfaces मध्ये विभागते - intent, canvas, evidence, controls, आणि run log. प्रत्येक कशासाठी आहे आणि हा split का महत्त्वाचा आहे ते येथे आहे.

work-orchestration • workspace • governance • product

Blank chat box consequential work चालवण्यासाठी खराब जागा आहे. ती पाच वेगळे प्रश्न - तुम्हाला काय हवे, तुम्ही काय पाहत आहात, ते कशावर आधारित आहे, तुम्हाला काय करण्याची परवानगी आहे, आणि आधी काय झाले - एका undifferentiated stream मध्ये ढकलते. Casual tasks साठी ते ठीक असू शकते. Governed operations मध्ये, जिथे actions systems of record ला स्पर्श करतात आणि decisions defensible असणे गरजेचे असते, ते collapse परवडत नाही.

Threada चा workspace मुद्दाम पाच surfaces मध्ये decomposed आहे. प्रत्येक एक प्रश्नाचे उत्तर देते, आणि त्यांना वेगळे ठेवणे work reviewable बनवते.

1. intent bar - तुम्हाला काय हवे?

Threada मधील work deep navigation ऐवजी persistent intent bar पासून सुरू होते. तुम्ही outcome natural language मध्ये सांगता, optional structured commands सोबत, आणि runtime ते structured, executable artifact मध्ये बदलतो: extracted entities, confidence score, आणि risk flags असलेला WorkItem.

हे intent-first interaction आहे. Operator ला कोणता form, queue, workflow लागू आहे हे आधी माहीत असण्यास भाग पाडण्याऐवजी system goal capture करून path assemble करते. Information missing असेल तर सुरुवातीला मोठा static wizard देण्याऐवजी नेमके जे लागते ते विचारते.

2. adaptive canvas - तुम्ही कशावर काम करत आहात?

Canvas म्हणजे WorkItem राहते आणि shape होते ते ठिकाण. ते adaptive आहे: प्रत्येक work type साठी fixed layout render करण्याऐवजी UI missing context गोळा करण्यासाठी temporary forms, comparisons, आणि decision panels assemble करू शकते.

Generated output committed change नसून editable draft म्हणून येते. Operator review, edit, decide करतो. Control affordances explicit असतात - 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 स्पष्ट सांगतो.

यामुळे “trust the AI” हा leap of faith न राहता inspectable claim बनतो. Operator ला draft वर अंधविश्वास ठेवावा लागत नाही; drawer उघडून तो कायावर उभा आहे, sources किती fresh आहेत, आणि प्रत्येक claim कुठून आला ते तपासता येते.

4. action controls - तुम्ही काय करू शकता?

Reading आणि drafting सुरक्षित आहेत. जगावर act करणे तसे नाही - म्हणून 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 मधून जातात, आणि policy परवानगी देते तेथेच auto-execute होतात. Service-level kill switch connector call होण्यापूर्वी execution थांबवू शकतो आणि review साठी state preserve करतो. Controls surface म्हणजे system ची caution concrete होण्याचे ठिकाण.

5. run log - काय झाले आहे?

Run log हा WorkItem चा timeline आहे: प्रत्येक transition, approval, action, AI participant event, क्रमाने. इथे receipts history मध्ये जमा होतात.

महत्त्वाचे म्हणजे AI actions human activity मध्ये मिसळत नाहीत; ते distinct actor events म्हणून दिसतात. Run log वाचताना कोण proposed, कोण approved, काय executed झाले - human की agent - हे guess न करता दिसते. Quarter शेवटी auditor जे वाचतो आणि आज operator case समजण्यासाठी जे वाचतो ते run log आहे.

Split हाच मुद्दा का आहे

एकच surface बांधणे आणि सगळे blur होऊ देणे सोपे झाले असते. तसे न करण्याचे कारण म्हणजे consequential work ला हे प्रश्न वेगळे ठेवणे आवश्यक आहे.

Intent, evidence, आणि action एकाच surface वर असतील तर कधी न grounded केलेल्या गोष्टीवर act करणे किंवा basis न पाहता approve करणे सोपे होते. प्रत्येकाला स्वतःची surface दिल्याने Threada careful path natural बनवते: intent सांगा, canvas वर draft shape करा, evidence तपासा, मग governed controls मधून act करा - run log सगळे record करत राहतो.

पाच surfaces packs आणि roles भर constant राहतात; त्यात काय भरते ते adapt होते. ही stability deliberate आहे. एका workspace ची shape शिकलेला operator सर्वांची shape शिकतो, तो IT access provisioning चालवत असो, vendor security review, किंवा procurement approval. Work बदलते. त्याबद्दल reason करण्याची पद्धत नाही.