Context Layer Banana: Ek Worker ke Store se Poori Workforce ke Corpus Tak ka Crash Course
15 Concepts · Onyx, MCP, aur sources ki chaar classes · Aap ke agent ne banaya, haath se nahin
AI Searchable Context ne ek Worker ke liye us ka apna store banaya tha. Yeh course woh corpus banata hai jahan se poori workforce parhti hai.

AI Searchable Context mein aap ne ek Worker ko us ka apna store diya tha: aap ke documents, chunks mein taqseem, embedded, maani ke zariye searchable, aur aap ke control wale ek Neon Postgres mein rakhe hue. Aap ne usay MCP tool mein bhi wrap kiya tha taake doosre agents usay call kar sakein.
Lekin woh ab bhi ek bounded store tha, jis ki boundary aap ne khud banai thi. Us mein har document aap ne chuna. Aap ne tay kiya ke wahan kaun pohanch sakta hai. Aisi koi cheez nahin aai jo aap ne khud na rakhi ho.
Ab kisi customer ki building mein chalein.
Un ke bees saal ke working papers SharePoint mein hain. Engagement letters email mein hain. Koi decision kyun liya gaya, is ki wajah chat thread aur safar karte manager ke zehan mein hai. Current balances aise system mein hain jo har ghante badalta hai. Is mein se kuch bhi aap ka store nahin. Kaam mukammal karne ke liye sab zaroori hai.
Yeh course woh layer banata hai jo in sab tak pohanchti hai, aur isay ek aise sawaal ke gird banata hai jo koi asli company waqai poochegi.
Northstar Services bees percent discount chahti hai, abhi invoice chahti hai, aur implementation revenue isi quarter mein recognise karna chahti hai. Kya yeh mumkin hai?
Yeh ek customer ka ek jumla hai, lekin ek sawaal nahin. Yeh sales ka sawaal, accounting ka sawaal, live-state ka sawaal, aur email mein suni hui ek baat hai. Sahi jawab ke liye chaaron ko alag rakhna zaroori hai. Course ke aakhir tak Worker iska sahi jawab dega. Citations ke saath. Current facts ko live fetch karke. Email ko authority nahin balke evidence samajh kar. Aur do professional decisions ko ek khushgawar "haan" mein milane ke bajaye alag rakh kar.
Agar yeh naye hon to pehle teen alfaaz samjhein. Connector woh hissa hai jo kisi source system ko parhta aur us ke content ki copy ko current rakhta hai. Indexing us copy ko is tarah store karna hai ke usay search kiya ja sake. Permission inheritance ka matlab har document ke access rules ko us ke home system se har search result tak saath le jana hai, taake reader sirf wohi dekhe jo woh pehle se khol sakta hai.
Ek idea is poore course ko samajh mein la deta hai. Pichle course ka ek sawaal tha: kya sahi chunk context window mein hai? Is course ke teen sawaal hain, aur har concept unhi ke liye hai. Layer se lautne wali har cheez ke liye poochein:
Yeh kahan se aaya? Kya yeh shakhs isay dekh sakta hai? Kya yeh ab bhi govern karta hai?
Search box in mein se kisi sawaal ka jawab nahin deta. Context layer har item ke liye, har baar, teenon ka jawab deta hai. Yehi poora farq hai, aur isi liye yeh ek course hai, sirf config file nahin.
| Lafz | Seedha matlab |
|---|---|
| System of Record | Woh system jo kisi cheez ka official record rakhta hai. Agar koi copy us se mukhtalif hai to copy ghalat hai |
| Vertical | Ek profession ya industry, jaise accounting, law, ya sales engineering. Yeh general-purpose ka ulat hai |
| Authority class | Yeh kis qisam ka statement hai aur is liye us ka kitna wazan hai: law, standard, contract, policy, transaction, guidance, message, ya example |
| Working context | Company ka rozmarra material: email, chat, drafts, files. Asli aur mufeed, lekin kabhi rule nahin |
| Connector | Woh hissa jo ek source system parhta aur us ke content ki copy current rakhta hai |
| Sync | Connector ka ek run, jo pichli baar ke baad ki tabdeeliyan fetch karta hai |
| Index | Layer ki rakhi searchable copy, taake cheezein jaldi mil sakein |
| Corpus | Tamam connected sources ka poora content jisay layer search kar sakti hai |
| Fixture | Practice ke liye banai gayi jaali lekin haqeeqat ke qareeb file, taake asli data risk mein na ho |
| Document Set | Connectors ka named group, jo batata hai search kin sources mein dekh sakti hai |
| Onyx Agent | Onyx ke andar configured assistant jis ke paas instructions, knowledge, aur tools hote hain |
| Action | Aisa tool jisay Onyx Agent call kar sakta hai, jaise aap ki search ya live lookup |
| Canonical | Kisi banai hui copy ke bajaye original aur official copy |
| Projection | Governed content ki searchable copy, jo sirf original dhoondne ke liye rakhi jati hai |
| Stable ID | Kisi rule ka permanent naam, taake copy us ke original ki taraf ishara kar sake |
| Superseded | Naye version se replace ho chuka aur ab lagu rule nahin |
| Gateway | Onyx ke samne baitha aap ka code, jo tay karta hai yeh shakhs kya search kar sakta hai |
| Packet | Ek sawaal ke liye jama kiye gaye rules, facts, aur evidence ka bundle |
| Envelope | Kisi item ke saath lage labels: kahan se aaya, us ka version, aur aap usay kyun dekh sakte hain |
| Provenance | Kisi information ke asal tak ki poori kahani |
Baqi har naya lafz wahin samjhaya gaya hai jahan woh pehli baar aata hai.
Yeh course farz karta hai ke aap ne AI Searchable Context mukammal kiya hai. Aap ke paas Neon aur pgvector par working RAG hona chahiye. Aap chunking aur embedding worker ka matlab jante hon. Eval set se retrieval quality judge karne mein bhi aaram hona chahiye. Us Neon project ko rakhein. Yahan aap us ki infrastructure aur retrieval skills dobara istemaal karenge. Lekin saaf samjhein ke us ne kya banaya aur kya nahin, kyun ke yehi farq is course ka mauzu hai.
Us course ne ek bounded retrieval store banaya tha: documents, chunks, embeddings, search function, answer function, aur eval set. Us ne sikhaya ke documents searchable knowledge kaise bante hain. Us ne store ko professional authority nahin di thi. Us mein authority classes, jurisdictions, effective periods, ya supersession links nahin hain. Is liye Concept 10 mein aap maujooda structure ke saath chota governed schema jorenge, aur Concept 10 us tak pohanchne ka raasta banata hai. Yeh course yeh bhi farz karta hai ke aap ne Claude Code ya OpenCode ko plan mode mein drive karne ke liye Agentic Coding, aur MCP ke liye Skills & Connectors kiya hai.
Is build ke peeche concept page The System of Context hai. Agar pehle daleel samajhna chahte hain to usay parhein. Yeh course factory floor hai, aur Northstar wohi worked example hai jisay woh page alag hisson mein samjhata hai.
Yahan poora system ek page par hai. Har concept ke saath aage barhte hue aap isi map ko mukammal karenge:

Yeh course kya cover karta hai
| Part | Mauzu | Aap kya seekhte hain |
|---|---|---|
| 1 | Bunyadein | Scope ka jump, sources ki chaar classes, Onyx Standard, ek model, aur search baseline |
| 2 | Aap ka pehla corpus | Shared method ke taur par kitab, Northstar fixtures, Document Sets, chunker, aur permission gate |
| 3 | Governed hissa | MCP par aap ka Neon record, discovery banam confirmation, aur live state |
| 4 | Routing aur citing | Prompt se pehle likha authority map, saat-section packet, aur woh conflicts jo milne nahin chahiye |
| 5 | Northstar case | Poora end-to-end build, phir usay jaan boojh kar torne ke chaar tareeqe |
| 6 | Isay sabit karein | Aath eval dimensions, aur jawab dene wale model ko khud grading kyun nahin karni chahiye |
| 7 | Isay serve aur operate karein | Har external Worker ke liye ek gateway, phir connector health, upgrades, aur definition of done |
Ek running Onyx Standard deployment jis mein sources ki chaar classes connected aur alag rahengi. Shared method ke taur par Agent Factory ki kitab khud index hogi. Northstar ke do Vertical records, sales aur accounting, mufeed tareeqe se disagree karenge. Current customer state ke liye live MCP server hoga. Aap ka Neon record MCP par serve hoga aur kabhi crawl nahin kiya jayega. Versioned authority-map.yaml batayegi ke kis sawaal ko kaunsa record govern karta hai. Context Router har baar citations ke saath wohi saat sections lautayega. Aap ka likha permission gate aise role ke saath test hoga jis ka sahi jawab kuch bhi nahin hai. Eval set aath dimensions par score hoga. Aur Context Gateway MCP endpoint authorized external Workers ko usi identity aur permission boundary ke saath shared corpus query karne dega.
Isay kaise parhein. Parts 1 aur 2 ke saath Part 5 ka Northstar build poora system hai. Isay parhne mein taqreeban do ghante aur keyboard par kuch ghante lagenge. Parts 3 aur 4 isay sirf working nahin balke trustworthy banate hain, aur dono zaroori hain: Part 5 har concept ko waqai chalata hai. Pehle build aur baad mein wajah parhna chahte hain? Part 5 se shuru karein.
📚 Tadreesi Madad
Is course ki slideshow tayyar ki ja rahi hai.
Apna environment ek baar setup karein
Aap jo kuch banayenge woh ek folder mein hai aur pehle se wired hai.
context-layer-base.zip download karein
Isay unzip karein. Andar poora Northstar case connect hone ke liye tayyar hai, governance files bharne ke liye tayyar hain, aur teen MCP server skeletons hain jin ke mushkil hisse TODO se marked hain:
fixtures/ two governed records, live state, working context
plus PLANTED.md, the answer key for Part 5
governance/ authority map, model register, permission matrix,
production gates, boundary contract
mcp/ vertical_sor, customer_state, context_gateway
prompts/ the Context Router instruction file
evals/ ten cases, scored on eight dimensions
scripts/ the governed schema for your existing Neon project
AGENTS.md the standing rules your agent reads every session
.env.example every credential this course needs, and nowhere else to put them
cd context-layer-base
cp .env.example .env
Is course mein pichle course se zyada credentials hain, aur in mein se har ek single commit mein customer ka trust khone ka raasta hai.
| Secret | Yeh kya kholta hai |
|---|---|
| Neon pooled connection string | Aap ka governed record |
| Model provider API key | Aap ka model spend |
| Onyx admin login | Poora corpus |
| Onyx API key | Us key ki access ke mutabiq search |
| Onyx MCP token | Optional, sirf Part 7 mein native-endpoint comparison ke liye |
| Context Gateway tokens | Har role ke liye ek, server-side mapped. Yehi permission boundary hai |
Onyx admin login ke siwa in mein se har secret .env mein rehta hai, jisay .gitignore pehle se exclude karti hai. Admin login aap ke password manager mein hona chahiye. In mein se kuch bhi committed file, paste kiye prompt, ya kisi classmate ke liye screenshot kiye terminal output mein nahin hona chahiye.
Apne agent ko saaf batayein: credentials environment se parhein, commit hone wali file mein kabhi na likhein, aur kabhi print na karein. Approve karne se pehle diff check karein.
Shuru karne se pehle cost. Agar aap ne pichla course kiya hai to kuch nahin.
| Cheez | Cost |
|---|---|
| Onyx Community Edition | free, MIT core |
| Neon | free tier, credit card ki zaroorat nahin |
| Model provider | Is course ke liye free tier kaafi hai |
Kitna waqt lagega. Parts 1 aur 2 parhne mein taqreeban do ghante aur keyboard par do ya teen ghante lagenge. Concept 4 ki install mein taqreeban bees minute intezar hai, jis mein zyada tar image pulls hain. Part 5 ka Northstar build ek lamba din leta hai, aur agar yeh aap ka pehla MCP server hai to aur bhi zyada. Isay ek sitting mein mukammal karne ki koshish na karein. Acha split hai: pehle Onyx aur connectors, phir governed record aur us ke do MCP servers, aur aakhir mein gateway aur Router. Har group apne aap mein ek lesson hai. Teenon ko ek shaam mein bharna logon ko yeh samjhata hai ke woh is mein ache nahin.
Folder ke ilawa machine par teen cheezein chahiye. Docker, kyun ke Onyx containers ke set ke taur par chalta hai. Python wale hisse ke liye uv. Aur aap ka agent. Isay folder ke andar kholein:
cd context-layer-base
claude
cd context-layer-base
opencode
Shuru karne se pehle ek warning, kyun ke yeh tay karti hai aap isay kahan chalayenge.
Onyx asli infrastructure hai. Standard deployment ek saath taqreeban barah containers shuru karti hai: web frontend, API backend, nginx proxy, Postgres, search index, Redis, object storage, do model servers (ek indexing aur ek inference ke liye), code interpreter, aur background sync workers.
Is ke liye kai gigabytes RAM chahiye. Baqi sab open rakh kar mamooli laptop par yeh aaram se nahin chalta. Class mein isay sambhalne ke teen tareeqe hain, preference ke mutabiq:
| Tareeqa | Kis ke liye behtar | Cost |
|---|---|---|
| Aap ke institution ka chalaya ek shared lab instance | Poori cohort, sab ke liye reachable ek Onyx se connect karna | Ek machine, ek baar |
| Local minimal deployment, sirf ek connector | Woh hafta jab internals dekhne aur code parhne ki zaroorat ho | Aap ki apni RAM |
| Onyx Cloud trial | Ek cohort week ya aisa laptop jo isay chala nahin sakta | 14-day trial, card nahin |
Internals wala hafta local karein, chahe baqi sab ke liye lab instance istemaal karein. Sync chalte waqt connector ka code parhna aisa lesson hai jo koi hosted service nahin de sakti.
Part 1: Bunyadein
Kuch install karne se pehle chaar ideas samjhein.
Aap ka pichla store chota aur mehfooz tha, kyun ke us mein sab kuch aap ke control mein tha. Company ke sources aise nahin hote. Woh chaar qisam ke hote hain, aur unhein aapas mein milana is build ki sab se mehngi ghalati hai. Aap Onyx istemaal karenge. Woh cheezein dhoondne mein acha hai aur yeh tay karne mein kamzor ke sach kya hai. Onyx ke do install modes bhi hain, jin mein se ek khamoshi se woh hisse band kar deta hai jin ke baare mein yeh course hai.
1. Scope ka jump: ek store se sab ke sources tak
Isay parhte waqt Northstar ka sawaal zehan mein rakhein, kyun ke aap ka pichla build isay chhoo bhi nahin sakta tha.
Kya Northstar ko bees percent discount mil sakta hai, abhi invoice ho sakta hai, aur revenue isi quarter mein recognise kiya ja sakta hai?
Aap ke Postgres store mein kuch nahin janta ke Northstar kya hai. Woh nahin janta kis ne kya approve kiya, acceptance kab aai, ya pichle Mangal ko sales manager ne email mein kya kaha. Yeh aap ke build ka gap nahin. Yeh mukhtalif qisam ka system hai.
Aap ke store mein chaar properties thin jin par shayad aap ne dhyan nahin diya, kyun ke un ke baare mein sochne ki zaroorat nahin pari.
Us mein sab kuch aap ne likha tha. Har document aap ke docs/ folder se aaya. Us ka ek reader tha. Aap ka app jo allow karta tha store bhi wohi allow karta tha. Us mein sach ki ek qisam thi. Har cheez aap ka likha document thi aur sab ka wazan barabar tha. Us mein live balance, signed obligation, ya email mein kisi ki rai nahin thi. Koi content aise naye version se khamoshi se replace bhi nahin hua tha jisay aap ne dekha na ho. Aur woh banawat se current tha, kyun ke sirf aap ka worker usay likhta tha.
Company connect karte hi yeh chaaron properties ek saath khatam ho jati hain.
Ab content un ka hai, jis mein kuch ghalat aur kuch superseded hai. Ab first-year junior aur partner wohi sawaal poochte hain, lekin un ke jawab mukhtalif hone chahiye. Ab corpus mein signed contract, policy memo, chat message, aur live invoice status hain jin ka wazan bahut mukhtalif hai. Mangal ko index kiya document Budh ko koi aisa shakhs replace kar sakta hai jo aap ko kabhi batayega bhi nahin.
Northstar in chaaron ko wazeh banata hai. Contract aur CRM un ke hain. Discount par account executive aur VP ko mukhtalif jawab milne chahiye. Signed contract, policy memo, email, aur live approval status ka wazan bahut mukhtalif hai. Worker jawab bana raha ho aur isi dauran approval status badal sakti hai.
Yehi scope jump hai, aur isi liye build ki shakal mukhtalif hai.

Pichla course retrieval problem tha. Yeh governance problem hai jis ne retrieval problem ke kapre pehne hain.
Is mein aap ka kaam hamesha jaisa hai: aap agent ko direct karte aur us ke output ko judge karte hain. Lekin judgment badal jata hai. Ab aap zyada tar yeh nahin pooch rahe ke sahi chunk mila ya nahin. Aap pooch rahe hain: kya har returned item batata hai woh kahan se aaya, kya is reader ko woh milna chahiye, aur kya kisi cheez ne confirm kiya ke woh ab bhi lagu hai.
2. Sources ki chaar classes aur un ke aane ke mukhtalif tareeqe
Is build ki sab se mehngi single mistake har connected system ko befarq pile samajhna hai. Kuch connect karne se pehle unhein chaar classes mein taqseem karein, kyun ke class tay karti hai content kaise fetch hoga aur Worker us ke saath kya kar sakta hai.
| Class | Misaalein | Yeh kaise aata hai | Kya Worker isay cite kar sakta hai? |
|---|---|---|---|
| Agent Factory System of Record | Shared method aur standards | Discovery ke liye Web-indexed, canonical page cite hota hai | Haan, shared method ke taur par |
| Vertical Systems of Record | Aap ke Neon record mein Northstar ke sales aur accounting rules | Discovery ke liye indexed, phir MCP par confirmed | Haan, governing rule ke taur par |
| Customer operational records | ERP, CRM, ledger, contract system | Live typed query, kabhi indexed nahin | Haan, apni current state ke liye, timestamp ke saath |
| Customer working context | Email, chat, files, project trackers | Permission-aware indexing | Jo kaha ya kiya gaya us ke evidence ke taur par, rule ke taur par kabhi nahin |
Is table se do baatein yaad rakhein.
Pehli teen mukhtalif sawalon par authoritative hain. Vendor ki aam line kehti hai traditional record "sirf data store karta hai" jab ke context layer us ki interpretation karti hai. Finance director ke samne isay na dohrayein. Un ka ERP transactional integrity, approval limits, aur audit trail enforce karta hai, aur inhi controls ki wajah se business operate kar sakta hai. Gap seriousness ka nahin balke scope ka hai: record apne domain ke baare mein mukammal aur us ke gird profession par khamosh hai.
Sirf chauthi class mein governing professional authority nahin hai. Yeh bareeki yaad rakhein. Email aur chat aksar access controls, retention rules, privacy policy, legal holds, aur records-management requirements se governed hote hain. Un ke paas professional sawaal settle karne ki authority nahin hoti.
Yehi woh class hai jis par sab pehle search tool point karte hain. Isi liye itne pilots fluent jawab banate hain jin ke peeche kuch nahin hota.
Glean chauthi class aur teesri class ke kai systems ke liye native connectors deta hai. Jin systems ko woh cover nahin karta un ke liye Indexing API deta hai. Aap custom datasource define karte, content, metadata, aur permissions wale documents push karte, phir admin console mein usay activate karte hain.
Glean aap ki chaar classes tay nahin karta. Woh har datasource ko KNOWLEDGE_HUB, EMAIL, MESSAGING, CRM, TICKETS, aur kai doosri categories se tag karta hai, lekin yeh categories ranking aur page par result ki shakal tune karti hain. In mein se koi nahin batati ke source governing rule ke taur par cite ho sakta hai ya nahin. Har source ki class, aur is liye Worker usay kis taur par cite kar sakta hai, ab bhi aap ka design decision hai. Onyx yeh aap ko mehsoos karata hai kyun ke separation aap haath se banate hain. Glean isay skip karne deta hai, aur isi wajah se kai Glean deployments bhi flat pile ban jati hain.

Chaar classes ki poori daleel aur pehli teen mukhtalif sawalon par authoritative kyun hain, yeh Authority is scoped across many records mein hai.
Aap jis profession mein bhi kaam karte hon, pehla connector run hone se pehle apne asli sources ke liye yeh table likhein. Concept 12 mein yehi routing map banegi.
3. Onyx kya hai aur kya nahin
Onyx khud ko aap ke docs, apps, aur logon se connected open-source AI chat kehta hai. Yeh course isay System of Context ka open reference implementation samajhta hai; yeh framing hamari hai, un ki nahin. Onyx kai sources connect karta, synchronised copies rakhta, maani aur keyword se search karta, cited jawab lautata, aur agents aur actions expose karta hai. Is ka core MIT-licensed aur waqai self-hostable hai. Is course mein isay chunne ki yehi wajah hai. Aap connector code parh sakte, sync run dekh sakte, aur permission check kahan fire hoti hai dekh sakte hain. Yeh real companies mein real scale par chalta hai, is liye yahan seekhi cheezein interview mein pehchani jayengi.
Yeh teen cheezein nahin hai, aur har ek us cheez se map hoti hai jo aap khud banayenge.
Yeh aap ka System of Record nahin hai. Onyx dhoondne ke liye copies rakhta hai. Aap ka governed record cite karne ke liye originals rakhta hai. Yehi ek qanoon hai: layer authority ko carry karti hai, hold nahin. Isay ulta karein to corpus current nazar aa sakta hai jab ke Worker aise index se pichle saal ka rule quote kar raha ho jisay update kabhi mila hi nahin.
Yeh permission system nahin hai. Jis edition mein support ho wahan permissions inherit karta hai, lekin aap ke profession ke controls khud enforce nahin karta. Part 2 mein isay sanjeedgi se liya jayega.
Yeh jawab nahin hai. Retrieval hit ek pointer hai. Woh kehta hai: yahan dekhein. Pointer ko jawab banane ke liye doosra step chahiye, aur Concept 10 wohi call hai.
Aur ek cheez jo Onyx nahin, lekin Onyx ki kisi bhi cheez se jaldi build tor sakti hai:
Aap ka Worker language model par chalta hai. Retrieval se kuch na milne par woh apne knowledge se professional sawaal ka jawab dega. Output grounded jawab jaisa hi lagega. Kahin error nahin aayegi.
Model ke paas source nahin, weights hote hain. Us ke jawab ke peeche register row nahin: publisher, authority class, jurisdiction, version, ya effective period nahin, aur us ke andar ek statement theek karne ka raasta nahin. Plausibility provenance nahin hai.
Build karte waqt teen khamosh leaks dekhein:
- Gap fill. Retrieval kuch mufeed nahin lautata aur model phir bhi jawab deta hai.
- Drifting paraphrase. Model sahi rule retrieve karke restate karte hue threshold ya condition kho deta hai.
- Persistent memory. Sessions ke darmiyan facts carry karne wala model aisa unversioned store ban gaya jis ka owner koi nahin.
Hal prompt nahin, structural hai. Missing evidence packet ka wazeh field hai, aur governing source na dhoond pane wala Worker aage barhne ke bajaye escalate karta hai. Poori daleel concept page mein hai.
Mukammal tab hai jab: aap baghair dekhe bata sakein ke in teenon mein se har ek kis sawaal ka jawab deta hai. Confirmation call kis masle ko theek karti hai. Permission gate kis masle ko theek karta hai. Aur aap ka Neon record index ke bahar kyun rehta hai.
Glean sab se mashhoor commercial System of Context hai. Aap isay yahan deploy nahin karenge, phir bhi is par ek ghanta dena mufeed hai.
Do wajahen. Pehli, Glean ne current enterprise AI market mein system of context phrase ko popular kiya aur isay apni enterprise data layer ka naam banaya. Yeh kitab phrase ko jaan boojh kar apnati hai, taake graduate buyer ke office mein wohi zubaan bole jo buyer pehle se istemaal karta hai. Glean ne term coin ki ya nahin, yeh alag sawaal hai aur yahan claim karne laiq nahin. Doosri, market ne isi product ke zariye is layer ki qeemat tay ki hai. Company "enterprise AI search", "work assistant", "AI knowledge layer", ya "enterprise context platform" maang sakti hai. Sab isi category ki taraf ishara karte hain, aur samne baithe shakhs ne taqreeban yaqeenan Glean demo dekha hoga.
Is liye us ke product pages ko doctrine nahin, diagnostic ki tarah parhein. Ek sawaal:
Is course ki architecture ke kaun se hisse product waqai implement karta hai, aur kaun se khamoshi se aap ke liye chor deta hai?
Yeh sawaal connector list, permission model, citation format, aur action surface par lagayein. Aap ko wohi chaar source classes, wohi permission problem, aur wohi discovery-versus-confirmation gap milega jis ke gird aap build karenge.
Parhte waqt ek aadat rakhein. Category ke naam baar baar aur mukhtalif analysts ne ek hi waqt mein badle hain: insight engines, cognitive search, enterprise AI search, generative AI knowledge management. Layer seekhein, logo nahin. Shuru ke teen sawaal list ke har product name se zyada der rahenge. Graduation par market mein jo bhi ho, aap usay inhi se judge karenge.
Ab aage aksar concepts ke aakhir mein chota Glean mein note hoga. Woh batata hai commercial product mein wohi idea kaisa nazar aata hai, aur zyada mufeed baat: Glean aap ke liye kaun se hisse karta hai aur kaun se dono products par aap ka design work rehte hain. Aap se Glean account ki tawaqqo nahin. Aap se meeting mein saaf batane ki tawaqqo hai ke dono mein kya mushtarak aur kya mukhtalif hai.
Phir Onyx kyun, Glean kyun nahin?
Is sawaal ke imaandaar jawab mein teen hisse hain, aur sirf pehla products ke baare mein hai.

Pehla, product mein control hone ki baat parh kar aap control nahin seekh sakte. Glean ka permission model Concept 9 ke aap ke banaye model se behtar hai. Woh nazar bhi nahin aata. Aap configure karte, woh kaam karta, aur hafta khatam hota hai magar fail hone par kya hota hai nahin jante. Aisa path ek baar imperfect tareeqe se khara karna jis mein kisi role ko kuch nahin milta, ache path ko das baar configure karne se zyada sikhata hai.
Doosra, closed box architecture nahin sikhata. Course ka har concept Onyx mein dekha ja sakta hai. Connector code parhein. Chunker ko barah controls phenkte dekhein. Search ko stale branch par point karke perfect citations ke saath ghalat jawab aate dekhein. Product page se yeh nahin milta.
Teesra, aur students aksar yehi chookte hain: course ka zyada hissa product ke baare mein hai hi nahin. Oopar sunehri column dekhein. Aap ki banai saat cheezein na Onyx tay karta hai na Glean, kyun ke woh platform features nahin balke professional judgments hain. Source kis class ka hai. Sawaal ko kaunsa record govern karta hai. Rule ab current hai ya nahin. Do sources disagree karein to kya ho. Glean par bana course yehi saat cheezein sikhayega; sirf neeche ki teen kam nazar aayengi.
Customer ko Glean kab istemaal karna chahiye?
Aksar. Saaf kahein, kyun ke ulat dikhawa pehli meeting mein client ka trust kho dega.
Agar company ko agle quarter tak darjan SaaS systems mein permission inheritance chahiye to khareedna banane se kaafi behtar hai. Agar platform team nahin to hosted self-hosted se behtar hai. Agar unhon ne Glean pehle se khareeda hai to aap ka kaam migration proposal nahin. Aap ka kaam un ke governed record ko us se connect karna aur batana hai ke current setup teen mein se kin sawalon ka waqai jawab deta hai. Rebuild se yeh behtar pehli guftagu hai.
Poore course ka rule:
Hum woh sikhate hain jisay aap khol sakte hain. Aap woh deploy karenge jo customer pehle se khareed chuka hai. Architecture dono mein wohi hai, aur sirf wohi hissa aap ka hai.
4. Standard install karein, Lite nahin
Onyx ke Lite aur Standard deployment modes hain, aur ghalat choice ek din zaya karegi.
Lite chota chat interface hai. Woh vector index, background connector workers, aur woh poori infrastructure disable karta hai jisay yeh course sikhata hai. Standard chunein.
Installer Docker Compose se deploy karta aur mode poochta hai. Exact script badalti rehti hai, is liye guess karne ke bajaye agent se current documentation parhwayein:
Current official Onyx Quickstart aur Resourcing pages parhein. Is machine ke Docker CPU, RAM, aur free disk ko documentation ki requirements se check karein. Is course ke liye latest stable Onyx Community Edition ko Standard mode mein install karein aur localhost se bind karein. Exact Onyx version, install method, ports, aur persistent data location ko
README.mdmein record karein. Lite na chunein. Koi container shuru karne se pehle plan aur resource check dikhayein.
Plan mein Standard aur persistent data location dono hon tab approve karein. Startup ke baad:
Running Onyx containers aur logs inspect karein. Report karein kaun si services healthy hain, UI kis port par hai, aur kaun si errors repeat ho rahi hain. Wajah samjhaye aur exact command dikhaye baghair kuch restart ya recreate na karein.
Docker ko kam memory mile to Onyx Standard ki search aur indexing services restart, stall, ya health checks fail karti hain. Har symptom configuration bug jaisa lagta hai.
Us machine par config debug karne mein ek ghanta na lagayein jisay Docker ke liye sirf 4 GB mila hai.
Local lab ke liye mufeed Standard target kam az kam 4 virtual CPUs aur 10 GB RAM hai. 8 CPUs aur 16 GB aaramdeh hai. Hamesha resources pehle confirm karein.
Plan parhein. Container list maangne ka sabab trivia nahin. Plan ke baad aap ko teen containers ka naam pata hona chahiye. Memory khane wala vector index. First start par slow model server. Aur background sync workers, jahan khamoshi se fail hota connector chhupta hai. Baad mein yehi teen surprise karenge.
Dhyan rakhein: first start kai gigabytes images pull karta aur model server ko ready hone mein kuch minutes lagte hain. Yeh expected hai, hang nahin. Stack chalne ke baad search kuch na lautaye to aam tor par kisi connector ki first sync mukammal nahin hui. Container loop mein restart ho to configuration se pehle memory check karein.
Mukammal tab hai jab: aap web interface khol, first admin user se login, aur woh single command bata sakein jo sab band karke disk reclaim karti hai.
Aap ko kuch install nahin karna. Glean managed service ke taur par chalta hai, apni infrastructure ya aap ke GCP/AWS account ke single-tenant deployment mein. Doosre model mein bhi Glean hi deploy aur patch karta hai. Is liye yeh poora concept, container list, memory hisab, aur Part 7 ki disk monitoring gayab ho jati hai.
Yehi trade hai. Aap operations khareed kar hata dete hain, aur code parhne ki salahiyat bhi. Ek baar Onyx khara kar chuka student janta hai vector index ki cost aur sync kahan khamoshi se fail hoti hai. Sirf hosted product wala student dono nahin janta.
Ek model, jaan boojh kar chuna gaya
Onyx context platform ko language model se alag rakhta hai. Admin Panel mein ek capable provider configure karein aur visible list choti rakhein: aap context layer evaluate karne aaye hain, das chat models compare karne nahin. Phir agent se governance/model-register.md likhwayein. Is mein provider, model, date, data-processing assumption, kaun dekh sakta hai, aur kyun chuna record hota hai. Ek field aur:
Replacement test. Stronger model tool use aur answer composition behtar karta hai. Woh missing connector, wrong authority routing, stale operational facts, ya broken permission boundary repair nahin kar sakta. Yeh context-layer failures hain. Is jumle ko register mein likhein taake pressure mein future-you na bhoole.
Tune karne se pehle search baseline
Pichle course ne retrieval ke neeche machinery sikhai thi taake aap judge kar sakein. Ab Onyx usay package karta hai. Embedding models foran swap aur har experimental option enable na karein, kyun ke embedding model badalne par full re-index chahiye. Stable defaults se shuru karein aur governance/search-baseline.md mein Onyx version, embedding model, reranking configuration, baseline date, eval set version, aur wajah record karein.
Pichle course ka rule yahan bhi hai: retrieval changes evaluate hote hain, admire nahin. Onyx SQL chhupata hai, evidence ki zaroorat nahin hatata.
/init run karein aur output chaar lines tak trim karein. Kis Onyx instance ki taraf point hain. Sab credentials environment mein, repo mein kabhi nahin. Koi real customer data connect nahin. Aur hard rule:
Aisa source kabhi connect na karein jisay mein ne is session mein explicitly approve nahin kiya.
Connector kisi ka data copy karne ki standing instruction hai. Usay destructive SQL jitna review chahiye.
Part 2: Aap ka pehla corpus
Ab aap real content connect karke dekhenge us ke saath kya hota hai.
Aap is kitab se shuru karenge, kyun ke yeh public hai aur permission nahin maangti. Phir Northstar naam ka jaali customer bana kar us ki files connect karenge. Dhyan se dekhenge search index ne kya rakha aur khamoshi se kya phenk diya. Phir course ki sab se aham cheez banayenge: aisa check jo tay kare har shakhs kya dhoond sakta hai.
Hum choti synthetic company banayenge: do governed records, do operational snapshots, aur email aur chat wala working-context folder. Synthetic hona jaan boojh kar hai, aur Concept 8 samjhata hai yeh shortcut kyun nahin.
5. Pehle shared method, phir customer connect karein
Us source se shuru karein jisay koi permission nahin chahiye. Onyx ka Web connector base URL ke neeche pages crawl karta, reachable links follow karta, text saaf karta, aur citation ke liye source metadata rakhta hai.
| Field | Value |
|---|---|
| Connector type | Web |
| Name | AF-SOR-PUBLIC |
| Base URL | https://agentfactory.panaversity.org/docs/getting-started |
| Source class | Agent Factory System of Record |
| Permission basis | Public |
Haan, aap isi kitab ko index kar rahe hain. Yehi maqsad hai. Agent Factory System of Record asli, public, aur governed source hai. Yehi ek class hai jisay pehle din ek bhi permission sawaal ke baghair connect kiya ja sakta hai.
Har governed source par ek baat lagu hoti hai. Index Worker ko method dhoondne mein madad karta hai. Citation ko original page dobara kholna chahiye.
Web-indexed chunk stable web address ka pointer hai, replacement nahin. Yehi find-then-confirm shakal aap Concept 10 mein theek se banayenge.
Ab customer. Northstar fixtures base folder mein pehle se hain, is liye unhein generate nahin, connect karein. Kuch connect karne se pehle fixtures/ khol kar parhein:
| Folder | Is mein kya hai |
|---|---|
sales-sor/ | Teen governed sales rules, har ek ka stable ID, version, aur effective date. Discount rule account executive ko 15 percent tak allow karta hai |
accounting-sor/ | Chaar governed accounting rules, jin mein ek jaan boojh kar superseded file kehti hai revenue acceptance ke bajaye billing par recognise hota hai |
operational/ | Do JSON records: approval pending, acceptance not received. Inhein kabhi index nahin kiya jata |
working-context/ | Teen emails aur do chat threads. Ek kehta hai finance aisi baat par raazi hai jisay koi governed source support nahin karta |
fixtures/PLANTED.md chaaron planted inconsistencies ki list hai. Us file ko index na karein, aur Part 5 tak usay ghour se na parhein. Wohi answer key hai.
Agar apna corpus generate karna ya testing ke liye doosra chahiye to yeh prompt equivalent output banata hai:
Northstar Services naam ke synthetic customer ke liye
fixtures/folder banayein.
fixtures/sales-sor/ke neeche chota governed sales record banayein: discount-authority rule jo kahe pandrah percent se zyada discount ke liye VP Sales approval chahiye, saath qualification method aur proposal policy. Front matter mein har rule ko stable ID, version, aur effective date dein.
fixtures/accounting-sor/ke neeche chota governed accounting record banayein: implementation-revenue rule jo kahe revenue customer acceptance par recognise hota hai, saath do supporting entries aur wohi front matter. Phir ek superseded file jorein jo kahe revenue billing par recognise hota hai, earlier effective date aur superseded-by link ke saath.
fixtures/operational/ke neeche do JSON records banayein: opportunity jis mein twenty percent discount requested aur approval pending ho, aur contract jis mein signature complete aur acceptance not received ho.
fixtures/working-context/ke neeche teen emails aur do chat threads banayein. Sales manager ka ek email kahe, "finance is fine with booking it this quarter", jisay koi governed source support nahin karta.Aakhir mein
fixtures/PLANTED.mdlikhein jis mein jaan boojh kar banai har inconsistency listed ho, taake baad mein system ke dhoondne ko check kar sakun. Us file ko index na karein.
Folders ko ek nahin, alag connectors ke taur par connect karein:
| Connector | Source class | Alag kyun |
|---|---|---|
VERTICAL-SALES-SOR | Vertical record | Discount authority ko govern karta hai |
VERTICAL-ACCOUNTING-SOR | Vertical record | Revenue recognition ko govern karta hai |
CUSTOMER-WORKING-CONTEXT | Working context | Sirf evidence, authority kabhi nahin |
Aap customer ka material index karne wale hain. Woh unhi ka rehta hai.
Northstar ke emails, chat threads, aur governed rules bhi customer instance mein customer content hain. Woh shared vertical record mein migrate nahin hote jisay aap client se client le jate hain. Aisa karna contamination hai: profession ka record ek company ka private material rakhne lagega aur phir kahin aur nahin le ja sakte.
Material sirf promotion law se oopar jata hai: pattern teen ya zyada customers mein repeat ho, de-identify ho, promotion review pass kare, aur aap ki expert usay apni voice mein dobara likhe. Yeh authorship hai, copying nahin.
Connect karte waqt rule: customer ki duniya andar aati hai. Kuch bahar nahin jata.
Dhyan dein table mein kya nahin. Operational JSON bilkul connect nahin hoti. Concept 11 mein live serve hogi, aur wajah poore concept ka mauzu hai.
Dhyan rakhein: text ke ilawa connector har document ke saath kya carry karta hai. Local folder ka file connector path aur modified time dekhta hai, magar kaun parh sakta hai kuch nahin. Real SharePoint ya Drive ka connector access rules samet bahut kuch dekhta hai. Yehi asymmetry Concept 8 ka mauzu hai, aur folder par dekhna sab se sasta tareeqa hai.
Yeh bhi dekhein: sync complete report kare lekin search kuch na lautaye to aam tor par indexing peeche chal rahi hoti hai. Intezar karke dobara search karein. Connector error dikhaye lekin search kaam kare to old content index mein reh gaya hai, yehi Part 7 ka trap hai. Permission change phailne mein bhi kuch waqt lagta hai.
Document Sets: search scope, legal ladder nahin
Connector batata hai content kahan se aaya. Document Set connectors ke named group ke liye Onyx ka lafz hai. Is se bataya jata hai particular search ya Agent kin sources mein dekh sakta hai.
| Document Set | Is mein kya hai | Maqsad |
|---|---|---|
AF Shared Method | AF-SOR-PUBLIC | Architecture aur doctrine |
Sales Authority | VERTICAL-SALES-SOR | Governed sales rules |
Accounting Authority | VERTICAL-ACCOUNTING-SOR | Governed accounting rules |
Customer Working Context | CUSTOMER-WORKING-CONTEXT | Supporting evidence |
Northstar Cross-Domain | Chaaron | Poora lab corpus |
Yeh teen kaam karte hain. Scope visible banate hain. Agent ko sirf task ke zaroori sources search karne dete hain. Cross-domain se pehle single domain test karne dete hain, jis se routing bug aur retrieval bug alag dikhte hain. Ek warning:
Document Set search scope hai, authority hierarchy nahin. Yeh batata hai kahan dekha ja sakta hai. Kya govern karta hai, nahin batata.
Kya govern karta hai woh alag file batati hai jo Concept 12 mein aayegi.
Mukammal tab hai jab: sirf Sales Authority scope mein search karke revenue recognition par kuch wapas na mile. Is ka matlab scope kaam kar raha hai.
6. Sync dekhein aur samjhein chunker ne kya phenka
Pichle course se aap chunking jante hain, jahan dials size aur overlap aur stake recall tha. Yahan doosra, bara stake hai.
Governed record ki entry barah cheezein saath rakhti hai. Stable ID. Domain. Authority class. Jurisdiction. Version. Effective date. Approval status. Applicability conditions. Owner. Superseded-by link. Required checker. Permission boundary.
Generic indexing pipeline jumla bacha leti hai.
Revenue may be recognised when control transfers.
Alfaaz bach jate hain. Barah controls chale jate hain, aur retrieved text mein kahin nahin dikhta ke woh missing hain.
Worker ab chhe cheezein nahin bata sakta. Statement ko kaunsa standard govern karta hai. Is contract type par lagu hai ya nahin. Current hai ya nahin. Is country par lagu hai ya nahin. Authority hai ya explanation. Kaun se exceptions jawab badlenge.
Apne corpus par dekhein:
fixtures/accounting-sor/se woh rule lein jis ke front matter mein version aur effective date hai. Pehle raw document dikhayein, phir exact dikhayein index mein us ka ek chunk kaisa hai: chunk text aur saath stored har field. Saaf batayein kaun se document-level facts chunk tak nahin pohanche.
Mukammal tab hai jab: ek chunk utha kar parent document ke baare mein aisi sach baat bata sakein jo sirf chunk parhne wala Worker kabhi nahin janega. Yeh Onyx bug nahin. Concept 10 mein confirmation isi liye hai.
Glean ki Indexing API documents ke saath structured metadata attach karne deti hai, aur knowledge graph logon, content, aur processes ke relationships rakhta hai jinhein plain chunker phenk deta hai. Gap Onyx se kam hai.
Kam hona band hona nahin. Jab tak aap effective date, jurisdiction, aur superseded-by link fields nahin dete aur Worker ko check karna nahin sikhate, koi product nahin janta. Barah controls dono cases mein aap ko carry karne hain.
7. Search karein aur dekhein kya mila
Corpus mein aisa sawaal search karein jis ka jawab do documents mein ho. Results scores aur sources ke saath dikhayein, phir wohi sawaal Onyx chat se answer karein taake attached citations dikh sakein.
Ab discipline. Har result se teen sawaal buland awaaz mein poochein, jab tak aadat ban jaye:
Yeh kahan se aaya? Onyx is mein acha hai aur citation samne hai. Check karein woh pehchane document ki taraf point karta hai.
Kya yeh shakhs isay dekh sakta hai? Abhi imaandaar jawab sab sab kuch dekhte hain hai, kyun ke sirf aap user aur source folder hai. Yeh khayal chaar minute rakhein.
Kya yeh ab bhi govern karta hai? Onyx nahin bata sakta. Usay words se match document mila. Currency ka jawab similarity score nahin de sakta. Concept 5 ki superseded accounting file ka topic search karein aur dekhein kaunsa version aata hai.
Retrieval hit pointer hai, jawab nahin. Parts 3 aur 4 pointers ko aise jawab banate hain jin ka aap difa kar sakein.
Governed knowledge ke paas original hai, is liye hit pointer hai. Working context ke paas nahin: Mangal ko manager ne jo kaha us ka canonical version nahin, retrieved email hi item hai. Working context ko imaandaar doosre do sawaal rakhte hain: kya yeh shakhs dekh sakta hai, aur kya yeh rule ke bajaye evidence hai.
Mukammal tab hai jab: superseded accounting file ka topic search karke dekha ho kaunsa version pehle aaya. Jo bhi ho, Onyx ne currency ke bunyad par decision nahin liya.
8. Permission inheritance aur Community Edition ki had
Yeh course ka sab se aham aur sab se zyada skip kiya jane wala concept hai, kyun ke skip karne se taqreeban chhe hafton tak sab asaan ho jata hai.
Document ke access rules us ke home system mein rehte hain. Private channel private, restricted folder restricted hai. Jab layer document copy kare to access rules bhi saath copy kare aur har query par poochne wale khaas shakhs ke liye dobara check kare. Permission inherit hoti hai, invent nahin. Yeh sirf privacy nahin balke control ka sawaal kyun hai, Permission comes before the model mein hai.
Isay ghalat karein to leak se bhi bura system banta hai: leak karne mein helpful system. Junior munasib sawaal poochta aur pehle ranked friendly summary mein compensation memo pata hai jisay kabhi khol nahin sakta tha. Kisi ne attack nahin kiya. Layer ne ghalat rules par kaam kiya.
Onyx Community Edition connectors, indexing, retrieval, citations, agents, aur actions seekhne ke liye kaafi hai. Apne aap mein users ke darmiyan production permission fidelity dikhane ke liye kaafi nahin.
Onyx documentation external systems se user permissions inherit karne wale permission-sync connectors, user groups, RBAC, aur group-based permissions ko Onyx Cloud aur Enterprise Edition features batati hai, self-hosted Community Edition nahin. External permission inheritance ko Enterprise jane ki wajah bhi kaha gaya hai.
Is liye pure Community Edition lab mein har student wohi corpus dekhta hai. Restricted role ka sahi nothing result demo nahin ho sakta. Cohort Onyx Cloud trial chalaye to ho sakta hai, aur real access-control sync ko yeh kaam khud karte dekhna mufeed hai jo aap haath se karenge.
Yahan commercial product saaf aage hai, aur yeh kehna chahiye.
Glean har connected system se content ke saath access-control list parhta aur source ki maujooda permissions enforce karta hai. Drive file ya Slack channel aap nahin khol sakte to result aur answer mein nahin aata. Indexing API per-user aur per-group permissions aur verification ka checkdocumentaccess endpoint deti hai.
Glean mein isay configure karte hain. Onyx Community Edition mein build, jo Concept 9 hai.
Ek baar build karna behtar taleem hai. Khareedna aam tor par behtar production decision. Samne ki situation par kaunsa jumla lagu hai janna asal skill hai.
Teen tareeqe, aur course pehla leta hai.
Apni boundary par permission check khud enforce karein. Code aap likhte hain, poora control aap ka hai. Access check implement karna configure se zyada sikhata hai. Yehi Concept 9 hai.
ee/ code parhein. MIT na hone par bhi source-available hai. Deploy kiye baghair dekhein real source se ACL inheritance kaise implement hoti hai.
Ek lab ke liye trial ya licence. Ek hafta, ek demonstration, phir Community Edition.
Is se non-negotiable rule nikalta hai.
Jab tak deployment Concept 9 ka permission test set pass na kare, real corpus connect na karein. Employer ki drive, client ka system, apna inbox bhi nahin. Permission ke liye kabhi test na hui layer partial system nahin, tez system hai jo ghalat rules ki taraf point kar raha hai.
9. Gate khud banayein aur aise role se test karein jisay kuch nahin milta
Community Edition per-user documents gate nahin karegi, is liye retrieval ke samne ek layer oopar gate banayein. Production mein bhi apni boundary par aap sabit kar sakte hain kya hua.
Likhne se pehle imaandari: aap fixtures par permissions invent karenge, jo abhi seekhe rule ka ulat hai. Yeh lab ki property hai, design ki nahin. Local folder inherit karne ke access rules nahin rakhta. Real deployment mein source system yeh kaam karta hai. Yahan tagging us inheritance ki stand-in hai, aur governance/production-gates.md mein likhein ke woh abhi baqi hai.
Shakal seedhi hai, order sab kuch:
1. Resolve identity who is asking
2. Resolve permissions what may this identity see, per source
3. Filter eligible docs remove everything else, BEFORE retrieval
4. Retrieve and rank search only what remains
5. Assemble the answer with citations
6. Resolve action rights separately, at the tool boundary
Unsafe order fitri lagta hai. Sab retrieve karein. Model ko dein. Phir kahen reader jo nahin dekh sakta us ka zikr na kare.
Model context ke andar hidden passage hidden nahin hai.

Isay banayein:
governance/permission-matrix.csv har source ki row ke saath aati hai. Gate isi file ko enforce karta aur reviewer ko deta hai.
Onyx retrieval ke samne access layer jorein. Northstar ke teen roles define karein:
account_executive,sales_manager, aurvp_sales. Har fixture ko minimum readable role se tag karein. Discount-authority rule teenon parh sakte hain. Pricing-approval thread aur manager ka "book it this quarter" email sirfsales_manageraur oopar. Phirsearch(query, role)function likhein. Onyx call se pehle eligible document set role se filter kare, baad mein kabhi nahin. Har result ke saath source aur permission ki wajah lautaye. Filtering code path dikhayein aur sabit karein koi ineligible document model tak nahin pohanchta.
Phir aham test:
Permission test set banayein: har role aur question ki row, source mein allowed content, layer ka result, aur pass/fail. Aham Northstar case:
account_executiveke taur par poochein sales manager ne is quarter booking par kya kaha, jahan sahi jawab kuch bhi nahin. Run karke table dikhayein.
Mukammal tab hai jab: teenon roles sirf allowed cheez lautayein, aur account_executive manager email par nothing paye. Jo layer kabhi nothing nahin lautati woh test nahin hui.
Yeh test manager ki hearsay protect karta hai. Email retrieve karne wala account executive manager ki rai finance decision ki tarah quote kar sakta hai.
Phir lab ki current sachai aur production requirements likhein.
Pehle governance/permission-matrix.csv:
source,student,teacher,production_employee,permission_mechanism,production_ready
Agent Factory SoR,read,read,read,public,yes
Sales fixture,read,read,not applicable,class-authorized,no
Accounting fixture,read,read,not applicable,class-authorized,no
Operational fixture,read,read,not applicable,synthetic MCP,no
Working context fixture,read,read,not applicable,synthetic files,no
Aur security reviewer ki governance/production-gates.md:
# Production permission gates
- [ ] Source permissions are synchronised or enforced before retrieval.
- [ ] Individual identity reaches live MCP and API tools.
- [ ] Search, chat, Agents, and external MCP clients enforce the same boundary.
- [ ] Revoked source access disappears within the accepted time window.
- [ ] A red-team test proves one user cannot retrieve another user's document.
- [ ] Connector credentials are encrypted and operationally protected.
Dono likhne se Community Edition limitation explicitly open gate hai, hidden assumption nahin. Yehi lab aur liability ka farq hai.
Aksar domains mein permission failure privacy problem hai. Regulated profession mein zyada gehra hai. Precise rahein, kyun ke loose argument ghalat hai.
Segregation of duties visibility nahin balke ability ke combinations hain: journal entry create aur approve dono, transaction originate aur reconcile dono. Read access akela aam tor par aisa combination nahin. Context layer ne "segregation of duties tor di" kehne par controller ke samne daleel haar jayenge.
Asal exposure ek layer neeche hai. Access control woh bunyad hai jis par baqi control environment khara hai. Isi liye auditors weak IT general controls ko oopar application controls par shak ki wajah mante hain. Firm ki periodic access review certify karti hai named user ke paas specific entitlements hain. Layer usay aisa content deti hai jo entitlements ne kabhi grant nahin kiya. Kuch chori nahin, documented rule formally nahin toota, magar review ghalat tasveer certify kar rahi hai.
Is liye sahi aur mazboot daleel: Entitlement model ke bahar effective access dene wali context layer ek control nahin torti. Woh sab ko certify karne wali review ko khamoshi se invalid karti hai.
Part 3: Governed hissa
Search pointer deti hai, jawab nahin.
Is part mein doosra half jorein. Aap ke Neon database ko rules ki choti governed table milegi, har rule ke saath version aur date. Phir usay tool ke taur par serve karein, taake Worker index mein mile rule ko original se pooch sake: kya yeh ab bhi rule hai? Approval mili ya nahin jaise live numbers har baar taaza pooche jate hain.
10. Apna record MCP par serve karein aur two-call pattern banayein
Ab tak sab indexed discovery half tha. Is mein governed knowledge bhi hai, kyun ke do Vertical records aur kitab index ki. Lekin sab searchable copy ke taur par aaya, aur copy pointer hai.
Ab canonical aur live half aata hai, aur us ka rawayya mukhtalif hai.
Pehle record ko authority dein
Aap ke Neon project mein documents, chunks, aur embeddings hain. Abhi aisa rule nahin jisay controller ko cite kiya ja sake, kyun ke pichle course ko zaroorat nahin thi. Maujooda structure ke saath chota governed schema jorein. Isi bootstrap par baqi part hai:
Base folder ke scripts/ mein required schema hai. Prompt se pehle parhein taake dekhi cheez approve karein.
Hamare existing Neon project ki
devbranch pargovernedschema aurruletable banayein. Columns:stable_id,domain(sales ya accounting),authority_class,jurisdiction,version,effective_from,effective_to,approval_status,superseded_by,owner, aurbody.fixtures/se Northstar ke sales aur accounting rules load karein, jis mein superseded accounting rule kasuperseded_bycurrent rule ki taraf ho. Branch commit se pehle rows dikhayein.
In mein nau columns Concept 6 ke barah controls hain, ab description nahin real.
Dono professions ek table mein domain column se alag hain. Demonstration server simple rehta hai. Concept 12 ki routing visible kaam karti hai, kyun ke confirm se pehle Worker domain chunta hai.
Phir isay serve karein
Northstar ka accounting rule kehta hai implementation revenue customer acceptance par recognise hota hai. Us ka version aur effective date hai, aur fixtures mein mukhtalif baat wali superseded file. Is concept ka har hissa sahi rule cite karane ke liye hai.
Pichle course ka store pehle se chal raha hai: Neon par chota Postgres, pgvector enabled, aap ke documents, aur dev branch. Yahan kuch nahin badalta. Badalta hai kaun pohanchta hai.
Yeh crawl hone wala folder nahin. Kisi connector ko point na karein. Yeh poocha jane wala source hai, jaise pichle course ke Part 6 mein.
Base folder ka mcp/vertical_sor/ FastMCP skeleton hai, teen tools stub aur mushkil hisse TODO. Pehle parhein, phir agent se bharwayein.
Neon-hosted governed record ko
vertical-sornaam ke FastMCP server mein wrap karein. Har tooldomainargument le, sales ya accounting, taake ek server dono professions dikhaye. Teen read-only tools, aur live customer state in mein nahin:
search_rules(domain, query)candidate rules stable IDs ke saath lautata haiconfirm_rule(domain, stable_id)authority class, jurisdiction, version, effective period, approval status, aur superseded-by link ke saath full current entry lautata haivalidate_action(domain, action)proposed action ko domain rules se check karke blocking rule ke saath approved ya refused lautata hai Environment se pooled Neon connection string lein, read-only role se connect karein, aur stateless mode mein Streamable HTTP par serve karein. Requests ke darmiyan MCP session na rahe. Code se pehle tool list aur docstrings dikhayein.
Ek server kyun, do kyun nahin. Production mein har profession ka record alag party ke owned system mein ho sakta hai, aur domain future split ki jagah hai. Crash course mein ek server canonical path saaf rakhta hai. Dono professions ke liye rule confirm karne ki exactly ek jagah hai. Onyx indexed copies us ki projections hain. Har projected chunk stable_id, domain, aur version rakhta hai taake confirmation lookup ho.
Plan mein do Neon details check karein. Server -pooler host wali pooled connection string use kare, kyun ke context layer kai short-lived connections kholti hai. Tables-owning role ke bajaye read-only role ho, taake tool argument cited record na badal sake.
Stateless HTTP FastMCP mein constructor nahin run-time argument hai. FastMCP("vertical-sor", stateless_http=True) FastMCP 2.x mein valid tha, 3.x mein TypeError deta hai. Current form:
from fastmcp import FastMCP
mcp = FastMCP("vertical-sor")
if __name__ == "__main__":
mcp.run(transport="http", host="127.0.0.1", port=8101, stateless_http=True)
Server bare host ke bajaye /mcp par answer karta hai. Plan approve karne se pehle current FastMCP docs se dono check karwayein.
Branch habit rakhein. Schema change Neon branch par aur preview karein. Stale-copy demo ke liye record fork karein, jaan boojh kar outdated hone dein, discovery point karein, phir branch phenk dein.
Tool list dekhein. Naive design ki ek call ki jagah search_rules aur confirm_rule do calls hain, aur yehi split point hai.
Discovery poochti hai: relevant information kahan ho sakti hai? Recall, similarity, aur speed ke liye optimize; output pointer.
Confirmation poochti hai: is decision par officially kaunsa source lagu hai? Domain, class, jurisdiction, version, effective date, aur approval check; output jawab.
Sequence fixed hai:
search discovers → you route → the record confirms → the Worker cites
Governed pages discovery ke liye index karna mufeed hai. Copy par reliance kabhi nahin. Doctrine Discovery is not confirmation hai.
governing_rule(question)likhein josearch_rulescall kare, top candidate ka stable ID le,confirm_rulecall kare, aur confirmed entry lautaye. Superseded ho to successor follow aur confirm kare. Failure demo: record ki Neon branch banayein, default branch par implementation-revenue rule acceptance se billing mein badlein taake branch stale ho,search_rulesstale branch par aurconfirm_rulecurrent par rahe, phir poochein Northstar revenue kab recognise kar sakta hai. Dono jawab side by side. Baad mein branch delete karein.

Mukammal tab hai jab: stale branch ko confidence se billing par aur confirmation ko acceptance par theek karte dekhein.
Ek jawab Northstar ko isi quarter revenue book karne deta hai, doosra nahin. Yeh demonstration course ki sab se qeemti cheez hai.
Yahan product yeh kaam nahin karta, aur yeh page ka aham note hai.
Glean behtareen indexing aur retrieval karta aur currency signal rakhta hai: owner page verify kar sakta, badge verifier aur waqt dikhata, dead page deprecate ho sakta hai. Yeh human reminder hai, aap ke profession ki authority classes, jurisdictions, effective periods, ya supersession links nahin. Glean superseded rule ko perfect citations, permission fidelity, aur green badge ke saath la kar bhi ghalat ho sakta hai.
Confirmation call dono products par aap banate hain. Glean Agents remote MCP par confirm_rule tak Onyx Agent ki tarah pohanch sakte hain, writing ke waqt beta plan-and-execute path mein. Design nahin badalta.
11. Live state har baar poochi jati hai
Balances, approval status, open items, current versions. Kuch authored nahin, kuch stable nahin, sab exact. Index karna us cheez ki ageing copy hai jis ki qeemat current hona hai.
Rule:
Agar stale value conclusion, permission, payment, filing, ya customer action badal sakti hai, live fetch karein.
Teen retrieval modes:
| Information | Kaise pohanchte hain |
|---|---|
| Working context | Permission-aware indexing |
| Governed knowledge | Discovery index, reliance se pehle confirmed |
| Current records aur actions | MCP ya API par live typed query |
Working context index karein. Governed knowledge discover karein. Current truth live query karein.
Ek source ko do modes chahiye ho sakte hain. Contract clauses ke liye indexed, active version ke liye system live queried.
Format aur length kuch tay nahin karte. Freshness risk sab tay karta hai.
Kuch systems ke liye Glean query time par fresh data fetch kar sakta hai, jo kuch hissa automatically cover karta hai.
Kuch, sab nahin. Aap ke profession mein kaun se fields freshness-critical hain, yeh judgment koi platform nahin kar sakta. Decision rule products ke darmiyan aap ke saath jata hai.
Northstar ke do operational records ko
vertical-sorse alag customer-state server par serve karein:get_opportunityapproval aurget_contract_stateacceptance status lautaye. Alag rakhna chaar source classes ko physical banata hai: Vertical record rules govern, operational record state own karta hai. Phir "kya revenue recognise ho sakta hai" do baar poochein, indexed snapshot aur live call se, darmiyan acceptance not-received se received karein. Timestamps ke saath dono jawab.
Mukammal tab hai jab: indexed aur live jawab disagree karein, aur aap batayein controller ke samne kaunsa jayega.
Part 4: Routing aur citing
Customer ka ek sawaal aksar kai professional sawalon ko saath chhupata hai.
Yeh part Worker ko alag karna, har sawaal governing record tak bhejna, aur lautne wali har cheez label karna sikhata hai. Sab se mushkil aadat: do sources disagree karein to dono dikhayein. Ek aaramdeh jumle mein na milayein.
12. Authority routing: is sawaal ko kaunsa record govern karta hai
Professional work kai sawal poochta hai: kya decide ho, kaunsa action permitted, kaunsa checker, kya evidence missing. Lekin context assemble karne ke liye zyada tar requests teen forms mein aati hain:
| Sawaal | Source | Path | Kya lautta hai |
|---|---|---|---|
| Rule kya hai? | System of Record | Discovery, phir confirmation | Class, jurisdiction, version ke saath cited governed truth |
| Number kya hai? | Usay own karne wala system | Typed query | Exact current value, timestamp ke saath |
| Is case par kya kaha gaya? | Working context | Permission-aware retrieval | Evidence, governing rule kabhi nahin |
Jo Worker nahin janta kaunsa sawaal pooch raha hai woh teenon ka jawab ek tarah dega, aur teesra path pehle do ko nigal lega.
Ek step aur: customer ke kai governed records hon to routing pehle resolve karti hai sawaal kis profession ka hai, phir us mein source. Revenue recognition accounting sawaal hai chahe alfaaz sales conversation se aaye hon.
Prompt se pehle map likhein
Model first-ranked chunk se governing source invent na kare. Routing table versioned artifact hai jo pehle likha, review, aur rakha jata hai. Base folder ki governance/authority-map.yaml fill karein:
version: 1
updated_at: 2026-07-31
routes:
shared_method:
questions: [architecture, Agent Factory doctrine, implementation method]
governing_source: AF-SOR-PUBLIC
sales.discount_authority:
questions: [requested discount, approval threshold, proposal permission]
governing_source: VERTICAL-SALES-SOR
confirm_with: vertical-sor.confirm_rule(domain=sales)
current_state_tool: customer-state.get_opportunity
accounting.implementation_revenue:
questions: [revenue recognition, implementation acceptance, quarter-end treatment]
governing_source: VERTICAL-ACCOUNTING-SOR
confirm_with: vertical-sor.confirm_rule(domain=accounting)
current_state_tool: customer-state.get_contract_state
rules:
- working_context may support what was said or requested, but never governs a professional conclusion
- indexed governed knowledge is discovered, then confirmed at the source before it is relied on
- current state must be confirmed live before any action
- conflicts are surfaced, never silently merged
- missing authority or evidence becomes an explicit gap
Har name pehle bana hai: Concept 5 ke connectors, Concepts 10 aur 11 ke tools. Callable source ke baghair routing map diagram hai, router nahin.
File ka kaam seedha: ek vague company sawaal ko named professional decisions mein badalna, har ek ke named governing source ke saath. Production mein governed registry ya Vertical SoR mein ho sakti hai. YAML decision ko pehle ghante se inspectable aur versioned rakhta hai.
route(question)function banayein jogovernance/authority-map.yamlparhe, question ko professional decisions mein classify kare, aur har ek ke governing aur current-state sources bataye. Reason ke saath structured data lautaye, sirf tool call nahin. Northstar question par run karke routing table dikhayein taake reasoning check ho.
Dhyan rakhein: decision return karna reviewable banata hai. Sirf jawab dene wala router audit nahin ho sakta.
Mukammal tab hai jab: Northstar sawaal kam az kam sales aur accounting ke do routed decisions banaye, retrieval se pehle governing sources ke saath.
13. Provenance aur citation envelope
Layer ka har material item envelope carry karta hai: labels jo batate hain kahan se aaya aur reliance ho sakti hai ya nahin. Is ke baghair packet text ki pile; saath reviewable evidence.
| Field | Kyun aham hai |
|---|---|
| Source system | Information ka owner |
| Stable ID | Reviewer exact item dobara fetch kare |
| Authority class | Law, standard, contract, policy, transaction, guidance, message, ya example |
| Scope | Kaunsa question, customer, jurisdiction, case govern |
| Version aur effective period | Retired rules ko wapas aane se roke |
| Retrieved ya synchronised at | Item ki freshness |
| Permission basis | Reader ko kyun mili |
Fluent jawab ko imaandaar rakhne ka rule:
Worker koi permitted, task-relevant supporting context parh sakta hai. Supporting context ko governing rule kabhi nahin bana sakta.
Email client request ka evidence, prior working paper pichle treatment ka evidence. Koi requirement nahin.
Packet ek output contract hai
Onyx Agent configured assistant hai: behavior instructions, searchable knowledge, aur callable tools yani Actions. Northstar Context Router banayein.
Ab aasani se ghalat hone wala hissa jo Concept 9 undo karega.
Northstar Cross-Domain seedha attach karna foran kaam karta hai, lekin do retrieval paths banata hai:
SAFE user -> permission gate -> filtered Onyx search
BYPASS user -> Onyx Agent -> the whole attached Document Set
Attached knowledge Agent ka searchable scope hai. Cross-domain set laga kar Agent kisi ke liye bhi sab parh sakta hai.
Router ke saath role-sensitive knowledge attach nahin. Sirf Actions.
Exactly paanch Actions:
| Action | Kya karta hai |
|---|---|
search_permitted_context(query) | Gateway. Credential se caller role resolve, allowed Document Sets/tags apply, phir Onyx search |
confirm_rule(domain, stable_id) | vertical-sor se canonical confirmation |
get_opportunity(id) | Customer-state se timestamp wala live opportunity state |
get_contract_state(id) | Usi server se live contract state |
validate_action(domain, action) | Proposal ko governing rules se check |
search_permitted_contextAction Onyx search API wrap kare. Configured credential se role parhe, tool argument se nahin. Role se permitted Document Sets aur tags derive, search filters lagaye, phir query. Har result ki permission reason lautaye. Northstar Context Router bina Document Set, sirf Action aur chaar MCP tools ke saath banayein.
Role comparison kahan run hota hai aham hai. Action ek credential aur role carry karta hai, is liye single Router same sawaal do logon ki tarah nahin pooch sakta. Gate gateway par prove karein jahan identity resolve hoti hai:
Sirf
vp_saleswali cheez gateway sevp_salesauraccount_executivetokens par poochein, dono results side by side. Phir Router ko Action se wohi sawaal answer karte dikhayein, aur batayein woh kis role ki taraf se bol raha hai.
Saari indexed retrieval gateway se guzarti hai. Agar component us ke baghair search kare to gate decoration hai.
Default Glean agent invoking user ki identity par chalta hai, is liye sirf usi ki permissions. Glean agent identity bhi deta hai, jahan administrator ki scoped service credentials hoti hain. Yeh unattended agent ki reach narrow karta hai, widen nahin.
Do cheezein aap ki: saat-section output contract aur authority routing, kyun ke revenue question accounting ka hai yeh professional knowledge hai.
Router ko prompts/context-router.md instruction file dein jo is fixed shape par khatam ho:
Return exactly these sections:
## Decisions involved
## Governing authority
## Current facts
## Supporting context
## Conflicts and gaps
## Permitted next steps
## Citations
Yeh saat sections hi context packet hain, aur fixed shakal nazar se zyada kaam karti hai.
Onyx mein Context Packet naam ka database object nahin. Aap isay ek task ka stable output contract implement karte hain. Reviewer seconds mein scan, eval harness har section check, missing section visible. Khali Conflicts and gaps ka matlab check hua aur kuch nahin mila. Heading na ho to dekha nahin.
Packet design se temporary hai. Current facts, reader permissions, applicable version badal sakte hain. Is liye cache nahin, har baar rebuild.

Contract ke peeche assembler banayein. Routed question par confirmed rules, live values, permitted supporting context gather karein. Full envelope ke saath har section bharein aur governed truth evidence se alag. Wohi jawab structured object aur human prose mein dikhayein.
Mukammal tab hai jab: content khali ho tab bhi headings hon, aur claim source, version, aur permission basis tak trace ho.
Assembler finite context budget par selection aur compression karta hai. Version stamp drop, do sources merge, ya authority class strip karna tokens nahin bachata; evidence ko text banata hai.
Prose compress karein. Provenance kabhi nahin.
14. Conflict result hai, retrieval failure nahin
Yehi System of Context ko ache search tool se alag karta hai. Search tool disagreement par rai nahin rakhta. Professional system ko rakhni chahiye.
Concept 5 ki planted inconsistencies dhoondein.
Conflict ke exactly teen outcomes:
- Scope se resolved. Sources mukhtalif sawalon ke sahi jawab. Sales deal June close kehta, accounting acceptance tak revenue nahin; dono sahi.
- Authority se resolved. Applicable source govern aur hierarchy tay karti hai.
- Unresolved. Worker conflicting evidence organise karke escalate karta hai.
Chautha kabhi nahin: ordinary summariser sources ko aise smooth jumle mein milata hai jo kisi ne nahin kaha.
Assembler mein conflict detection banayein. Do items material point par disagree karein to summary na milayein. Envelopes intact, scope ya authority se resolution, warna escalation: sources, dono ke statements, authority test, aur open issue.
fixtures/PLANTED.mdpar run karke har inconsistency dikhayein.
Mukammal tab hai jab: superseded memo aur contradicted chat khud milein, aur escalation partner ko bina edit bheji ja sake.
Yeh disagreement gayab nahin karta. Reviewable banata hai.
Na Onyx na Glean professional authority map ya conflict rules automatically lagata hai. Retrieval matching passages laati hai. Contradiction aur governing source professional judgment hai.
Stronger retrieval engine isay notice karna mushkil bana sakta hai, kyun ke jawab smoother aur confident hota hai.
Teen outcomes aur scope se resolved pehle kyun hai, Conflict is a result, not a retrieval failure mein hai.
15. Act aur record: loop band karna
Finding aur doing ek nahin; darmiyan paanch jobs:
the layer finds → the Worker reasons → the governing record validates
→ the tool acts → the owning system records
Teesra step aksar drop hota hai.
Discount approval CRM write se pehle sales record se check. Journal entry ERP draft se pehle accounting record se check.
Governing record rule parhne ki jagah hi nahin; proposed action us rule se wahin check hota hai. Yehi rule ko advisory ke bajaye real banata hai.
Do absolute rules:
Context layer kabhi second transaction system ya governed record ke gird write path nahin banegi.
Read, recommend, prepare, execute alag grants. Retrieval mein excellent Worker ke paas execution authority zero ho sakti hai. Access permission nahin.
Router ke
validate_action(domain, action)ko recommendation path mein wire karein. Proposed action ko governed record ke domain rules se check, blocking rule ke naam ke saath approved draft ya refusal. Kabhi execute nahin. Aisa case dikhayein jahan retrieval aur reasoning sahi lekin action refused.
Glean human-in-the-loop approvals aur user permissions support karta hai. Yeh approval half hai. Validation half, proposed action ko profession rules se check karna, dono products par aap ka validate_action hai.
Mukammal tab hai jab: sales approval rule discount recommendation refuse kare aur refusal rule ka naam bataye.
Part 5: Northstar case, end to end
Ab poori cheez tartib se banayein, phir jaan boojh kar torein.
Torna bonus nahin. Loud failure safe; fluent confident ghalat jawab ke saath quiet failure dangerous. Yeh part quiet failure dikhata hai.
Poora course ek build: empty instance se cited, correctly-refused jawab.
Case. Account executive ne 20 percent discount manga. CRM approval pending. Signed contract signature par billing allow karta hai. Accounting SoR implementation revenue ko customer acceptance par recognise karta hai. Operational contract kehta acceptance nahin mili. Sales manager email kehta finance isi quarter booking se raazi hai.
Sawaal.
Kya Northstar ko 20 percent discount, abhi invoice, aur isi quarter implementation revenue recognition mil sakta hai?
Step 1. Plan. Strong model ke saath plan mode:
Full Northstar context layer banayein: chaar source classes connected aur separated wala Onyx Standard, Neon project ka dono domains ke rules wala
governedschema, search, confirm, validate, aur live-state tools walavertical-sorMCP server, paanch Document Sets,governance/authority-map.yaml, aisacontext-gatewayjo kisi Onyx search se pehle identity resolve aur permitted sets apply kare, aur bina Document Set attach kiye sirf Actions wala Context Router. Code se pehle plan, component boundaries, aur tool list dikhayein.
Step 2. Approve se pehle plan parhein. Chhe checks:
- Permission filtering retrieval se pehle?
- Router samet har retrieval path gateway se? Agent par Document Set nahin aur role tool argument se nahin?
- Discovery aur confirmation do alag calls?
- Operational state live, index ka koi path nahin?
- Router conflicts preserve, blend nahin?
- Neon record MCP se, connector door?
Kisi ka jawab no ho to code se pehle wapas.
Steps 3 se 7. Checkpoints mein execute. Routine build ke liye cheaper model.
Onyx Standard shuru,
AF-SOR-PUBLICconnect, kitab se cited jawab.
Dono Vertical SoR fixtures aur working-context ko teen alag connectors. Document counts aur confirm operational JSON connect nahin hui.
Neon
governedschema aur superseded rule samet dono domains load.vertical-soraur customer-state server, aur sabit kareinconfirm_rulewoh deta hai josearch_rulesakela nahin.
Paanch Document Sets,
authority-map.yaml,context-gateway, aur bina knowledge attach sirf paanch Actions wala Context Router.
Gateway se per-role permission test,
account_executiveka correct nothing case. Wohi sawaal direct Onyx se dikhayein gateway kya rokta hai, aur Router se confirm karein woh isi path se jata hai.

Step 8. Sawaal poochein. Passing packet dono live tools call, confirmation ke baad Vertical SoRs cite, manager email evidence only, sales/accounting alag, aur blended yes ke bajaye do alag refusals.
Discount pending approval mein account executive level par nahin; acceptance outstanding mein revenue nahin. Signature par billing permitted. Sab refuse bhi sab approve jitna ghalat. Abridged shakal:
## Decisions involved
1. Sales: may an account executive grant 20 percent?
2. Accounting: may implementation revenue be recognised this quarter?
3. Contract: are the billing terms enforceable now?
## Governing authority
- SALES-DISC-001 v2, effective 2026-01-01, approved. Discounts above 15 percent
require VP Sales approval. [Vertical Sales SoR, confirmed 14:22]
- ACC-REV-001 v3, effective 2026-04-01, approved. Implementation revenue is
recognised at customer acceptance. [Vertical Accounting SoR, confirmed 14:22]
Supersedes ACC-REV-002, which said billing. Not applied.
## Current facts
- Opportunity NS-4471: discount 20 percent, approval PENDING. [CRM, read 14:22]
- Contract NS-2026-11: signed, acceptance NOT RECEIVED. [Contract system, read 14:22]
## Supporting context
- Email, sales manager, 2026-07-28: "finance is fine with booking it this quarter."
Evidence of what was said. Not authority. [Working context, permitted: vp_sales]
## Conflicts and gaps
- The email asserts a finance position no governed accounting source supports.
Unresolved by authority: escalate. Nothing in the corpus records a finance decision.
## Permitted next steps
- Route the 20 percent discount to VP Sales for approval.
- Bill at signature. Permitted by the signed contract.
- Do not recognise implementation revenue until acceptance is recorded.
## Citations
- SALES-DISC-001 v2 · ACC-REV-001 v3 · NS-4471 · NS-2026-11 · email 2026-07-28
Har governed claim version aur confirmation time. Superseded rule named aur explicitly not applied. Email labelled section aur unsupported claim ke sabab Conflicts and gaps mein. Teen verdict alag: refusal, permission, refusal.
Step 9. Jaan boojh kar torein.
| Test | Expected behavior |
|---|---|
| CRM pending rakh kar email mein discount approved | Conflict surface, CRM current state |
search_rules stale Neon branch par | Confirmation correct, stale jawab visibly ghalat |
| Customer-state MCP stop | Current state unconfirmed, dependent conclusion refuse |
| Gateway scope se sales rules hata dein | Email substitute nahin, missing governing authority |
| Cross-domain Document Set Router se attach | Gate bypass, restricted content visible. Detach par correct jawab |
Mukammal tab hai jab: ek confirmation call skip karne wale system se confident, fluent, well-cited, poora ghalat jawab dekhein.
Step 10. Baseline save. evals/questions.yaml ke har case ka raw response, citations, tool-call evidence, dimension pass/fail, Community permission limitation, exact Onyx/model versions.
Part 6: Isay sabit karein
Pichle course ka test: search ne sahi text paya? Yahan kaafi nahin. Layer pichle saal ka sahi passage, unauthorized content, ya number ki old copy se jawab de sakti hai. Aath cheezein test karein aur har failure bataye kaunsa hissa toota.
RAG eval sahi chunks poochti thi. Context layer failures retrieval se zyada hain, is liye alag set aur scorecard.
evals/questions.yaml ke das cases mein chhe ko ghour se parhein:
version: 1
cases:
- id: inventory-01
question: What sources contain Northstar discount information?
expected:
must_find: [Sales SoR, CRM, draft proposal]
must_not_treat_as_authority: [draft proposal]
- id: sales-01
question: Can the account executive approve a 20 percent discount?
expected:
governing_source: Sales SoR
live_tool: get_opportunity
conclusion: no, VP Sales approval is required and remains pending
- id: accounting-01
question: Can implementation revenue be recognised this quarter?
expected:
governing_source: Accounting SoR
live_tool: get_contract_state
conclusion: no, acceptance has not been received
- id: stale-01
question: When is implementation revenue recognised?
expected:
prefers_current_version: true
flags_superseded: true
- id: conflict-01
question: Finance should be fine with booking it, right?
expected:
working_context_is_not_authority: true
conflict_visible: true
- id: gap-01
question: Which executive approved the discount?
expected:
answer: not established
no_guess: true
Har run ko prose nahin, aath dimensions par score:
| Dimension | Passing sawaal |
|---|---|
| Inventory | Sab relevant source classes? |
| Routing | Har professional decision aur domain? |
| Authority | Source par confirmed sahi governing source? |
| Freshness | Current state par live tool? |
| Permission | User ke allowed corpus aur action authority mein? |
| Conflict | Disagreement surface, blend nahin? |
| Gaps | Guess ke bajaye missing bataya? |
| Citation | Reviewer har item dobara khol sakta hai? |
Pehla baseline Agent se haath se run aur save. Phir automate:
Current official API se running Onyx ka eval harness.
evals/questions.yaml, har question Router ko, raw response, citations, tool-call evidence, aath-dimension Markdown scorecard. Jahan mumkin deterministic checks. Jawab dene wale model se professional correctness auto-grade na karayein. Authority aur conclusion explicit expected-value comparisons.
Model failures summarize kar sakta hai, expected rules aur facts replace nahin.
Definition of done: cross-domain case production permission fidelity ke siwa har dimension pass; permission explicitly open gate.
Part 7: Poori workforce ko serve aur operate karein
Jo layer sirf ek chat window mein kaam kare, mukammal nahin.
Aakhri build step colleagues ke tools ko usi corpus tak, wohi permissions ke saath kholta hai. Phir woh hissa jo koi nahin likhta: real log depend karein to running kaise rakhein.
Ab tak humans aur Onyx Agents ne interface ke andar corpus use kiya. Architecture apna naam tab poora karti hai jab external Workers private copies ke bajaye wohi corpus query karein.
Onyx dono directions mein chalta hai:

Do tareeqe, sirf ek boundary rakhta hai.
Native Onyx MCP server quick route. Enable, token, client point. Search tool query aur source type, Document Set, time filters leta hai; resource reachable sets list karta hai.
Document Set filter client chunta hai. Server caller role se scope derive nahin karta; client doosra scope ya none chun sakta hai.
Direct native MCP Worker gate ke bahar search karta hai. Community Edition mein permission inheritance ke baghair sab.
Administrator tool, public corpus demo, ya production sirf permission fidelity prove hone ke baad, Enterprise ya equivalent auth layer ke saath.
Direct Community Edition MCP ko same user boundary na kahein. Nahin hai.
Context Gateway MCP server boundary wala route, pehle gateway ko bahar expose:
Claude Code · OpenCode · your Digital FTE
|
Context Gateway MCP
resolves identity
applies permitted sets and tags
routes authority, confirms, fetches live
|
Onyx
Gateway ko
context-gatewayMCP server mein wrap karein.search_permitted_context,confirm_rule,get_opportunity,get_contract_state,validate_actionexpose, external Worker kisi aur server tak na jaye. Streamable HTTP.Identity bearer tokens ko server-side roles se map. Har role token, mapping environment, har request token se role. Role tool argument se kabhi nahin.
ACCOUNT_EXECUTIVE_TOKEN -> account_executive
SALES_MANAGER_TOKEN -> sales_manager
VP_SALES_TOKEN -> vp_sales
Client token deta, server role map. Client apna role name nahin karta, warna boundary nahin.
Ab tak sab http:// par chala kyun ke sab aap ki machine par tha. Gateway bahar reachable ho to bearer token hi plain-text boundary hai. TLS, per-person token, expiry. Never-expiring role token job title wala shared password.
FastMCP default /mcp par answer. Bare host nahin. Wire:
claude mcp add --transport http context-gateway http://YOUR_GATEWAY_HOST:8102/mcp \
--header "Authorization: Bearer $ACCOUNT_EXECUTIVE_TOKEN"
opencode.json remote block:
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"context-gateway": {
"type": "remote",
"url": "http://YOUR_GATEWAY_HOST:8102/mcp",
"headers": { "Authorization": "Bearer {env:ACCOUNT_EXECUTIVE_TOKEN}" },
"enabled": true
}
}
}
Token commit nahin. OpenCode {env:NAME} se shell token rakhta hai. Phir bahar se:
context-gatewayse twenty percent Northstar discount ka governing rule. Source title, canonical link, confirmed version, exact passage. Memory se nahin.
Sales aur accounting wala doosra question. Client variation point nahin.
Aham test: same sawaal account_executive aur vp_sales tokens se, mukhtalif results. Nahin to identity client-controlled hai.
Glean MCP native identity/permissions bypass nahin karta. End user authenticate, Glean user map, har call us user ke taur par, interface jaisi permission check. Admin exposed tools chunta hai.
Yehi boundary context-gateway haath se reproduce karta hai. Ek baar banayein taake missing platform feature samajh sakein.
Layer ek chat interface ke search se complete nahin. Har authorized human aur AI Worker apni working surface se same governed inventory, source identity, aur permission boundary ke saath pohanche.
Yehi application aur shared infrastructure ka farq hai.
Isay operate karna
Context layer roz badalti hai kyun ke gird systems badalte hain. Production "deploy once" nahin: connector health, permission fidelity, freshness, measurement, controlled upgrades.
Connector operations
Har connector ke nau records: owner, source class, credentials owner, refresh/prune frequency, indexing start, expected document count, last successful sync, acceptable staleness, escalation path.
Onyx status indexed, scheduled, indexing, paused, error aur history. Trap: error connector pehle indexed content zaroori nahin hatata. Search chalti, corpus stale. Alerts search works aur corpus current ko alag rakhein.
Version aur upgrade discipline
One-command upgrade ko no-review upgrade kabhi na samjhein. Aath steps:
- Current version record.
- Release notes.
- Persistent volumes/config backup.
- Connector, model, Agent, Action, permission settings export.
- Eval baseline.
- Pehle non-production upgrade.
- Wohi evals dobara.
- Counts, citations, tool calls, latency compare.
Embedding aur index changes
Embedding change re-index hai, schema migration ki tarah. Deployment clone, representative corpus, authority/retrieval evals, recall, citation, latency, cost, storage compare. Sirf measured improvement.
Resource planning
Local lab minimum 4 virtual CPUs aur 10 GB RAM; 8 CPUs aur 16 GB behtar. Production indexed volume, concurrency, embedding/reranking, refresh load par. Disk monitor, flood threshold par index writes block.
Production definition of done
- Har source shared method, Vertical authority, operational state, ya working context classified.
- Har connector owner, canonical source, refresh expectation, failure alert.
- Authority routing versioned aur experts reviewed.
- Governed knowledge reliance se pehle source par confirmed.
- Current facts zaroorat par live confirmed.
- Source permissions retrieval se pehle synchronised/enforced.
- MCP/API actions individual identity aur least privilege.
- Conflicts aur missing evidence visible.
- Citations canonical source/record kholti hain.
- Har release cross-domain evals pass.
- Backups/restoration tested.
- Upgrade/retrieval rollback path.
- System of Context applicable System of Record ke gird write nahin kar sakta.
Digital FTE tak bridge
Do halves. Pichle course ne Worker ko owned knowledge di. Is course ne company-owned knowledge tak permission, provenance, confirmation ke saath access.
Digital FTE Worker ke gird success contract aur ek outcome hai. Retrieval yahan, authority governed record, trustworthiness model ki property nahin.
Aage kahan jayein
- Build ke peeche daleel: The System of Context
- Layer ka record: Designing the Vertical SoR
- Reliable banayein: Eval-Driven Development
- Work unit banayein: Building a Digital FTE
- Logon ke saath rakhein: Human-Agent Teams
Aath rules, ek jagah
Har profession, customer, product par:
| # | Rule |
|---|---|
| 1 | Authority kabhi move nahin hoti. Layer record citations carry; layer/model cited source nahin |
| 2 | Relevance authority nahin. Reliance se pehle routing |
| 3 | Permission inherit hoti hai, invent nahin, model se pehle enforce |
| 4 | Freshness per field. Working context index, governed knowledge discover, current truth live |
| 5 | Provenance har item ke saath, compression strip nahin |
| 6 | Conflict preserve aur escalate, blend nahin |
| 7 | Working context governing authority nahin banta. Promotion reviewed authorship |
| 8 | Discovery confirmation nahin. Search hit pointer, governing record confirms |
Table print karein. Onyx, Glean, aur replacements se zyada chalegi.
Throughline sakht hoti hai: sahi information, sahi waqt, irrelevant bahar. Ab teen defensible sawaal:
Yeh kahan se aaya? Kya yeh shakhs isay dekh sakta hai? Kya yeh ab bhi govern karta hai?
Har item, har baar, teenon jawab aur profession is ke peeche khara ho sakta hai.