> ## Documentation Index
> Fetch the complete documentation index at: https://docs.responsibleailabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Applications
> API keys, environments, और governance policy कैसे आपस में जुड़ते हैं।
**Application** वह तरीका है जिससे RAIL आपके monitor किए जाने वाले AI products को organize करता है। हर application की अपनी API keys, अपना environment, और अपनी governance policy होती है। जब आप किसी key से content evaluate करते हैं, तो उस key की application से जुड़ी policy तय करती है कि result को कैसे treat किया जाए।
## Model
आपका account एक organization का हिस्सा होता है, जो एक या ज्यादा applications और आपके team members का मालिक होता है।
हर application एक AI product या surface को दर्शाती है जिसे आप govern करना चाहते हैं, जैसे कोई support chatbot या summarizer। इसके साथ एक [policy](/concepts/policy-engine) होती है और यह किसी environment में रहती है (अभी `production`)।
Keys एक ही application तक सीमित होती हैं। उस key से की गई हर evaluation उस application की policy से govern होती है। keys [dashboard](https://responsibleailabs.ai/dashboard) में बनाएं और manage करें।
## अपना configuration देखना
चूंकि एक key किसी application से bound होती है, आप API से पूछ सकते हैं कि उसे क्या govern करता है। ये read-only endpoints किसी भी `rail_` key के साथ काम करते हैं:
आपकी key जिस application और policy से bound है, और enforcement active है या नहीं।
8 RAIL dimensions और आपकी application उन्हें कैसे weight करती है।
आपके plan में उपलब्ध features और limits।
## Policy application से आती है
आप हर request पर governance rules पास नहीं करते। हर application के साथ एक policy होती है, जो dashboard में एक बार configure होती है और उसकी keys से की गई हर evaluation पर अपने आप लागू होती है। एक नई application observe-only mode में शुरू होती है, इसलिए जब तक आप enforce करना न चुनें तब तक कुछ block नहीं होता। policy में क्या होता है और enforcement modes (log, block, regenerate) कैसे काम करते हैं, यह जानने के लिए [Policy Engine](/concepts/policy-engine) देखें।
**Locked vs unlocked.** Default रूप से policy *unlocked* होती है: per-request parameters जैसे `mode`, `domain`, और `weights` policy की defaults को override कर देते हैं, जो experiment करते समय सुविधाजनक है। जब आप policy को *lock* करते हैं, तो उन request parameters को ignore कर दिया जाता है और policy ही authoritative हो जाती है — यह तब useful है जब आप तय कर चुके हों कि application की हर key को किस governance का पालन करना चाहिए। current state कभी भी [`GET /config`](/api-reference/config) से check करें।
## Environments
एक application किसी environment में चलती है — अभी `production`। Environments किसी एक application को आगे चलकर, उदाहरण के लिए, production traffic को staging से अलग करने देते हैं; फिलहाल हर key `production` के against issue होती है।
policy edit करने के लिए dashboard access चाहिए। API keys evaluate करने और configuration पढ़ने के लिए हैं, उसे बदलने के लिए नहीं।