Unknown ଏକ error କି result?
Human, Human + AI, Agent କିମ୍ବା Unknown ଭାବରେ interactions କୁ classifying କରିବା ଆରମ୍ଭ କରିବାବେଳେ, Unknown bucket ପ୍ରାୟତଃ ଲୋକେ ଆଶା କରିଥିବାଠାରୁ ବଡ଼ ଥାଏ। ଏହାକୁ ଲୁଚାଇବାକୁ ଏକ gap ଭାବରେ ଦେଖିବା ଲୋଭନୀୟ, ହୋଇପାରେ Unknown କୁ Human ଭିତରେ ମିଶାଇଦେଇ କିମ୍ବା ଏହାକୁ ସନ୍ଦେହଜନକ ଭାବି। ଦୁଇଟି ଚୟନ ମଧ୍ୟ ସମସ୍ୟା ସୃଷ୍ଟି କରେ।
Unknown ର ଅର୍ଥ ହେଉଛି ଉପଲବ୍ଧ evidence ଭରସାଯୋଗ୍ୟ determination କୁ ସମର୍ଥନ କରୁନାହିଁ। ଯେ client କୌଣସି JavaScript ଚଳାଏ ନାହିଁ ସେଠାରୁ request, ଯେ endpoint ରେ ଆପଣ କୌଣସି signal ସଂଗ୍ରହ କରୁନାହାନ୍ତି ସେଠାକୁ call, ଗୋଟିଏ page ପରେ ଶେଷ ହୋଇଯାଇଥିବା session: ଏ ସବୁ ସମ୍ପୂର୍ଣ୍ଣ legitimate ହୋଇପାରେ, ଏବଂ କୌଣସିଟି ମଧ୍ୟ କିଏ କିମ୍ବା କଣ acting କରୁଥିଲା ବୋଲି କହିବାକୁ ପର୍ଯ୍ୟାପ୍ତ ଦେଇନାହିଁ।
Unknown କୁ ସତ୍ୟନିଷ୍ଠ ଭାବରେ report କରିବା ହେଉଛି ଅନ୍ୟ class ଗୁଡ଼ିକୁ trustworthy ରଖିବାର ଉପାୟ। ଯଦି ଆପଣଙ୍କ system କେବେବି Unknown କହେନାହିଁ, ପ୍ରତ୍ୟେକ Human result ଆଂଶିକ ଭାବରେ ଅନୁମାନ ହୋଇଯାଏ, ଏବଂ କେଉଁ ଅଂଶଟି ବୋଲି ଆପଣ କହିପାରିବେ ନାହିଁ। AI traffic କୁ classifying କରିବାବେଳେ Unknown କାହିଁକି ଏକ valid result ଅଟେ ନେଇ ଥିବା ଆମର post ଏହି reasoning କୁ ଅଧିକ ବିସ୍ତାରରେ ଦେଖାଏ।
ଏହି guide practical ଭାବରେ Unknown କୁ କିପରି ହାତଲ କରିବେ ସେଥିପାଇଁ କଭର୍ କରେ: explicit per-route fallback, ଏହାକୁ ଅନ୍ୟ class ଭିତରେ ଝରିବାରୁ ରୋକିବା rules, ଏହାକୁ କିପରି monitor କରିବେ, ଏବଂ ଯେଉଁଠି ଅର୍ଥ ଅଛି ସେଠି କିପରି କମାଇବେ।
Step 1: Human କୁ କେବେବି default କରନ୍ତୁ ନାହିଁ
ସବୁଠାରୁ ସାଧାରଣ mistake ହେଉଛି ଏକ classification function ଯାହା automation signal ମିଳିଲା ନାହିଁ ଯେତେବେଳେ ସବୁବେଳେ Human return କରେ। ଏହା ଯୁକ୍ତିଯୁକ୍ତ ଲାଗେ ଏବଂ ଏହା ଭୁଲ। bot signal ର ଅଭାବ ହେଉଛି human signal ର ଉପସ୍ଥିତି ନୁହେଁ।
// Wrong: silence becomes Human
function classifyWrong(e: Evidence) {
if (e.signatureValid) return { actor: "agent", basis: "verified" };
if (e.declaredAgent) return { actor: "agent", basis: "declared" };
return { actor: "human", basis: "inferred" };
}
// Right: Human requires positive evidence, otherwise Unknown
function classify(e: Evidence) {
if (e.signatureValid) return { actor: "agent", basis: "verified" };
if (e.declaredAgent) return { actor: "agent", basis: "declared" };
if (e.interactiveSession) return { actor: "human", basis: "inferred" };
return { actor: "unknown", basis: "unknown" };
}result ଉତ୍ପାଦିତ ହେଉଥିବା ସବୁଠାରେ ସମାନ rule ଲାଗୁ କରନ୍ତୁ: timeout, error, stale cache entry ଏବଂ missing telemetry ସବୁ Unknown produce କରେ। ଏହି ପଥଗୁଡ଼ିକର ପ୍ରତ୍ୟେକ ପାଇଁ test ଲେଖନ୍ତୁ ଯାହାଦ୍ୱାରା behavior ଶାନ୍ତ ଭାବରେ regression ହେବ ନାହିଁ। ନିମ୍ନର example ରେ built-in Node.js test runner ବ୍ୟବହାର ହୋଇଛି।
import { test } from "node:test";
import assert from "node:assert/strict";
test("missing evidence is unknown, not human", () => {
const r = classify({ signatureValid: false, declaredAgent: false, interactiveSession: false });
assert.equal(r.actor, "unknown");
});Step 2: ପ୍ରତ୍ୟେକ route କୁ ଏକ explicit fallback ଦିଅନ୍ତୁ
Unknown କୁ ଏକ defined behavior ଆବଶ୍ୟକ, ଏବଂ ସଠିକ୍ behavior route ଉପରେ ନିର୍ଭର କରେ। route ପ୍ରତି ଏହା ନିଷ୍ପତ୍ତି କରନ୍ତୁ, ଲେଖି ରଖନ୍ତୁ, ଏବଂ configuration ଭିତରେ ରଖନ୍ତୁ। ଏହି fallback ଗୁଡ଼ିକ କିପରି ଏକ wider policy model ଭିତରେ fit ହୁଏ ସେଥିପାଇଁ humans ଏବଂ AI agents ପାଇଁ app-level policy design କରିବା ଦେଖନ୍ତୁ।
| Route ପ୍ରକାର | Example | Unknown ପାଇଁ ଯୁକ୍ତିସଙ୍ଗତ fallback |
|---|---|---|
| Public content | Marketing pages, docs | Allow, standard response |
| Read-only data | Catalog, search API | Standard rate limit ସହିତ allow |
| Account creation | Signup | Existing checks ରଖନ୍ତୁ, optional review queue |
| Sensitive change | Password, email, billing details | Existing re-authentication, କୌଣସି relaxation ନାହିଁ |
| High-value action | Bulk export, admin operations | Existing strong authorization |
Pattern ସରଳ। low-risk route ଗୁଡ଼ିକ ପାଇଁ, Unknown ସାଧାରଣ traffic ଭଳି ବ୍ୟବହାର କରେ। high-risk route ଗୁଡ଼ିକ ପାଇଁ, Unknown route ପାଖରେ ଯାହା protection ଅଛି ସେଇ protection ପାଏ। ଦୁଇଟି ମଧ୍ୟରେ, ଅନୁରୂପ ଭାବେ class କରାଯାଇନଥିବା କିନ୍ତୁ legitimate user ପାଇଁ actor result କଥାକୁ ଖରାପ କରେନାହିଁ।
type Fallback = "allow" | "standard_limit" | "existing_checks" | "review";
const unknownFallback: Record<string, Fallback> = {
"GET /docs/*": "allow",
"GET /api/catalog": "standard_limit",
"POST /signup": "existing_checks",
"POST /account/password": "existing_checks",
"POST /exports": "review",
};Step 3: timeout ଏବଂ error କୁ ସମାନ ଭାବରେ ହାତଲ କରନ୍ତୁ
Actor evaluation request path ଉପରେ ବସେ, ସେଥିପାଇଁ ଏହାର strict time budget ଥିବା ଆବଶ୍ୟକ। budget ଅତିକ୍ରମ ହେଲେ, Unknown produce କରନ୍ତୁ ଏବଂ route fallback ଲାଗୁ କରନ୍ତୁ। Evaluation ଧୀର ଥିବାରୁ request କୁ କେବେବି block କରନ୍ତୁ ନାହିଁ।
async function withBudget<T>(work: Promise<T>, ms: number, onTimeout: T): Promise<T> {
let timer: NodeJS.Timeout;
const timeout = new Promise<T>((resolve) => {
timer = setTimeout(() => resolve(onTimeout), ms);
});
try {
return await Promise.race([work, timeout]);
} finally {
clearTimeout(timer!);
}
}
const result = await withBudget(evaluateActor(req), 150, { actor: "unknown", basis: "unknown" });କାହିଁକି ଗୋଟିଏ result Unknown ହେଲା ସେଥିରେ record କରନ୍ତୁ: no evidence, timeout, evaluation error କିମ୍ବା stale evidence। ଏହି reasons ଆପଣଙ୍କୁ କଣ fix କରିବାକୁ ପଡ଼ିବ ସେଥିରେ ସୂଚନା ଦେଇଥାଏ।
Step 4: Unknown କୁ ସନ୍ଦେହଜନକ ଭାବରେ ଦେଖନ୍ତୁ ନାହିଁ
Unknown ଏକ risk score ନୁହେଁ। ଅନେକ legitimate client କିଛି route ଉପରେ ସବୁବେଳେ Unknown ରହିବେ: command-line tool, signature ବିନା server-side integration, accessibility tool, privacy-focused browser ଏବଂ simple feed reader। ଆଜି even ବଡ଼ AI operator ମାନେ ମୁଖ୍ୟତଃ user agent ଏବଂ published IP range ଦ୍ୱାରା ତାଙ୍କର fetcher ଚିହ୍ନଟ କରନ୍ତି। OpenAI's crawler documentation, ଉଦାହରଣ ସ୍ୱରୂପ, November 2026 ଅନୁସାରେ ତାଙ୍କ bot ମାନଙ୍କ ପ୍ରତ୍ୟେକ ପାଇଁ user agent string ଏବଂ published IP address file ତାଲିକା କରେ।
ଯଦି ଆପଣ ସନ୍ଦେହଜନକ behavior ଉପରେ କାର୍ଯ୍ୟ କରିବାକୁ ଚାହାନ୍ତି, ତେବେ request rate, failed login pattern କିମ୍ବା abuse report ପରି ଯାହାକୁ ଆପଣ ବର୍ଣ୍ଣନା କରିପାରିବେ ସେହି behavior ଉପରେ ଆଧାର କରନ୍ତୁ, ନିଜସ୍ୱ evidence ସହିତ। ସେଇ logic କୁ actor class ଠାରୁ ଅଲଗା ରଖନ୍ତୁ ଯାହାଦ୍ୱାରା କୌଣସିଟି ଅନ୍ୟଟିକୁ ବିକୃତ କରିନାହିଁ।
Step 5: ଆପଣଙ୍କ Unknown rate କୁ କିପରି monitor କରିବେ?
Unknown rate ହେଉଛି Unknown ଭାବରେ class କରାଯାଇଥିବା interactions ର share। ଏହାକୁ ପ୍ରତ୍ୟେକ route ଅନୁସାରେ, ପ୍ରତ୍ୟେକ integration context ଅନୁସାରେ ଏବଂ ସମୟ ସହିତ track କରନ୍ତୁ। ଏହା ଆପଣଙ୍କ ପାଖରେ ଥିବା ସବୁଠାରୁ useful health metric ମଧ୍ୟରୁ ଗୋଟିଏ।
type Row = { route: string; actor: string };
export function unknownRate(rows: Row[]) {
const byRoute = new Map<string, { total: number; unknown: number }>();
for (const r of rows) {
const s = byRoute.get(r.route) ?? { total: 0, unknown: 0 };
s.total += 1;
if (r.actor === "unknown") s.unknown += 1;
byRoute.set(r.route, s);
}
return [...byRoute].map(([route, s]) => ({ route, rate: s.unknown / s.total, total: s.total }));
}ସଂଖ୍ୟାଗୁଡ଼ିକ କଣ କହୁଛି:
- ଗୋଟିଏ route ଉପରେ ଉଚ୍ଚ, ସ୍ଥିର rate ସାଧାରଣତଃ ଅର୍ଥ ହେଉଛି ଆପଣ ସେଠାରେ signal ହରାଇଛନ୍ତି। ଯେ page କେବେବି ଆପଣଙ୍କ browser integration load କରେନାହିଁ, କିମ୍ବା ଯେ API signed request କେବେବି ଦେଖେନାହିଁ, ସେମାନେ ଅଧିକାଂଶ Unknown ରହିବେ।
- ହଠାତ୍ ବୃଦ୍ଧି ପ୍ରାୟତଃ ଅର୍ଥ ହେଉଛି ଆପଣଙ୍କ stack ରେ କିଛି ବଦଳିଛି, ଉଦାହରଣ ସ୍ୱରୂପ ଏକ release ଯାହା ଗୋଟିଏ header କୁ drop କରିଦେଲା, signature header କୁ strip କରୁଥିବା CDN rule, କିମ୍ବା frontend change ଯାହା ଆପଣଙ୍କ app ର declarations ପଠାଇବା ବନ୍ଦ କରିଦେଲା।
- ହଠାତ୍ ହ୍ରାସ ମଧ୍ୟ check କରିବା ଯୋଗ୍ୟ। Unknown କମି Human ବଢ଼ିଲେ, ନୂତନ evidence ଆସିଛି କି ନାହିଁ ସେଥିରେ ପ୍ରମାଣ କରନ୍ତୁ, ନାହିଁଲେ fallback ଶାନ୍ତ ଭାବରେ ବଦଳିଗଲା କି ନାହିଁ।
Absolute level ଉପରେ ନୁହେଁ, ତୀବ୍ର ପରିବର୍ତ୍ତନ ଉପରେ alert କରନ୍ତୁ। ପ୍ରତ୍ୟେକ application ର ନିଜସ୍ୱ normal ଥାଏ।
Step 6: ଯେଉଁଠି ମୂଲ୍ୟ ଅଛି ସେଠି Unknown କୁ କିପରି କମାଇବେ?
ଆପଣଙ୍କୁ Unknown କୁ zero କରିବା ଆବଶ୍ୟକ ନାହିଁ। ଯେଉଁ route ଗୁଡ଼ିକରେ decision matter କରେ ସେଠି ପର୍ଯ୍ୟାପ୍ତ evidence ଦରକାର। impact ଅନୁସାରେ ସେଗୁଡ଼ିକ ଉପରେ କାମ କରନ୍ତୁ:
- ପ୍ରଥମେ high-impact route ଗୁଡ଼ିକରେ evidence ଯୋଡନ୍ତୁ। ଯଦି account change ଅଧିକାଂଶ Unknown ଅଟେ, browser integration କିମ୍ବା server-side check ସେଠି ସବୁଠାରୁ ଲାଭଦାୟକ ହେବ।
- Automated client ମାନଙ୍କୁ ନିଜେମାନଙ୍କୁ identify କରିବାକୁ invite କରନ୍ତୁ। ଆପଣଙ୍କ API ପାଇଁ documentation ପ୍ରକାଶ କରନ୍ତୁ ଯାହା ବୁଝାଏ କିପରି agent ମାନେ HTTP Message Signatures ଏବଂ IETF Web Bot Auth conventions ସହ request sign କରିପାରିବେ, ଏବଂ verified client ମାନଙ୍କୁ ଉଚ୍ଚ limit କିମ୍ବା structured response ପରି ଭଲ experience ଦିଅନ୍ତୁ। Verify କରିପାରୁଥିବା client ମାନେ ସେଇପରି କରିବା ଆରମ୍ଭ କରିବେ।
- ନିଜ application knowledge ବ୍ୟବହାର କରନ୍ତୁ। ଯଦି user ଆପଣଙ୍କ built-in assistant ସହିତ interact କରୁଛନ୍ତି, ଏହାକୁ declaration ଭାବରେ record କରନ୍ତୁ। ଆପଣଙ୍କ app ପ୍ରାୟତଃ network ଠାରୁ ଅଧିକ ଜାଣେ।
- Plumbing ସଠିକ୍ କରନ୍ତୁ। Proxy ଗୁଡ଼ିକ ଆପଣଙ୍କ reliance ଥିବା header ଗୁଡ଼ିକ forward କରୁଛି କି ନାହିଁ ଏବଂ evaluation ସମାପ୍ତ କରିବାକୁ ପର୍ଯ୍ୟାପ୍ତ time budget ରହିଛି କି ନାହିଁ ସେଥିରେ ନିଶ୍ଚିତ କରନ୍ତୁ।
Unknown ରୁ traffic କୁ କେଉଁ signals ବାହାର କରେ ସେଥିରେ practical look ପାଇଁ website traffic AI agents ଠାରୁ ଆସୁଛି କିପରି କହିବେ ପଢ଼ନ୍ତୁ।
Step 7: Dashboards ରେ Unknown କୁ ସତ୍ୟନିଷ୍ଠ ଭାବରେ ଦେଖାନ୍ତୁ
Other class ଗୁଡ଼ିକ ପରି ସମାନ visual weight ସହିତ Unknown କୁ ନିଜସ୍ୱ series ଭାବରେ ଦେଖାନ୍ତୁ। ଏହାକୁ "other" bucket ଭିତରେ ଲୁଚାଇବେ ନାହିଁ, ଏବଂ ଏହାକୁ alert ଭଳି color କରନ୍ତୁ ନାହିଁ। Stakeholder ମାନେ ଯେତେବେଳେ ବଡ଼ Unknown share ଦେଖନ୍ତି, ସଠିକ୍ ପ୍ରତିକ୍ରିୟା ହେଉଛି "ଆମକୁ କେଉଁଠି ଅଧିକ evidence ଆବଶ୍ୟକ", ନୁହେଁ "bots କେଉଁଠି"।
Step 8: Assumption ନୁହେଁ, outcome ସହ Unknown କୁ review କରନ୍ତୁ
ପ୍ରତି କିଛି ସପ୍ତାହରେ, ଆପଣଙ୍କ ସବୁଠାରୁ important route ଗୁଡ଼ିକରୁ Unknown interactions ରୁ ଗୋଟିଏ sample ନିଅନ୍ତୁ ଏବଂ ପ୍ରକୃତରେ କଣ ଘଟିଲା ତାହା ଦେଖନ୍ତୁ। Session କି purchase ସମାପ୍ତ କଲା, project ସୃଷ୍ଟି କଲା, ତିନୋଟି article ପଢ଼ିଲା, କିମ୍ବା login ରେ ପୁନଃପୁନ ଅସଫଳ ହେଲା? Outcome ଆପଣଙ୍କୁ bucket ଭିତରେ କେଉଁ ପ୍ରକାରର traffic ଅଛି ସେଥିରେ premature label ଲଗାଇବାକୁ ବାଧ୍ୟ ନକରି ବୁଝାଏ।
ଆପଣ ଯାହା ମିଳାନ୍ତି ତାହାକୁ ତିନୋଟି practical category ଭିତରେ group କରନ୍ତୁ:
- Legitimate ଏବଂ low risk। Feed reader, link preview, monitoring tool ଏବଂ privacy setting ଥିବା ଲୋକମାନେ। Route fallback କୁ ଯେମିତି ଅଛି ସେମିତି ରଖନ୍ତୁ।
- Legitimate automation ଯାହା ନିଜକୁ identify କରିପାରେ। Integration ଏବଂ agent ଯେମାନେ structured path ବ୍ୟବହାର କରିବାକୁ କିମ୍ବା request sign କରିବାକୁ ଖୁସି ହେବେ ଯଦି ଆପଣ ଗୋଟିଏ ପ୍ରଦାନ କରନ୍ତୁ। Guidance ପ୍ରକାଶ କରନ୍ତୁ ଏବଂ ସମ୍ଭବ ଯେଉଁଠି ସେଠି reach out କରନ୍ତୁ।
- Behavior ଯାହାକୁ ନିଜସ୍ୱ control ଆବଶ୍ୟକ। Credential stuffing କିମ୍ବା scraping pattern, ଦୁହେଁ OWASP Automated Threats to Web Applications project ଭିତରେ catalogued ଅଛି। ଏଗୁଡ଼ିକୁ behavior-based control ଦ୍ୱାରା address କରନ୍ତୁ ଯାହାଙ୍କର ନିଜ evidence ଅଛି, ଯଥା login failure rate, ଏବଂ ସେଗୁଡ଼ିକୁ actor class ଠାରୁ ଅଲଗା ରଖନ୍ତୁ।
ଏହି review ଆପଣଙ୍କ fallback ଗୁଡ଼ିକୁ ଆପଣଙ୍କ ନିଜସ୍ୱ traffic ଉପରେ grounded ରଖେ ଏବଂ ପରବର୍ତ୍ତୀ evidence କେଉଁଠି ଯୋଡିବେ ସେଥିପାଇଁ ସ୍ପଷ୍ଟ ତାଲିକା ଦେଇଥାଏ।
Common questions
Unknown କୁ rate limit ଗଣନାରେ ଧରିବା ଉଚିତ କି? ଆପଣଙ୍କ standard limit ବ୍ୟବହାର କରନ୍ତୁ। Class ଅନୁସାରେ rate limiting verified agent ମାନଙ୍କ ପାଇଁ ଠିକ୍, ଯେମାନେ ଉଚ୍ଚ limit ଅର୍ଜନ କରିପାରନ୍ତି, କିନ୍ତୁ Unknown କୁ ସାଧାରଣ limit ମିଳିବା ଉଚିତ, ଶାସନମୂଳକ limit ନୁହେଁ।
ଆମେ Unknown user ମାନଙ୍କୁ challenge କରିପାରିବା କି? କେବଳ ସେଠି ଯେଉଁଠି route ପୂର୍ବରୁ ସେହି ପରିସ୍ଥିତିରେ ସମସ୍ତଙ୍କୁ challenge କରେ। କେବଳ result Unknown ଥିବାରୁ challenge ଯୋଡିବା legitimate user ମାନଙ୍କୁ ଶାସନ କରେ ଯେମାନଙ୍କ client କମ୍ signal ପଠାଏ।
Standards ପକ୍କା ହେବା ସହ Unknown କମିବ କି? ଅଧିକ automated client request sign କରିବା ସହ, ଅଧିକ agent traffic Unknown କିମ୍ବା declared ଠାରୁ verified କୁ ଯାଏ। ଆପଣଙ୍କ monitoring route ଅନୁସାରେ ସେହି shift ଦେଖାଇବ।
Proof of Actor କେଉଁଠି fit ହୁଏ
Proof of Actor Unknown କୁ first-class result ଭାବରେ report କରେ, reason ସହିତ, ଏବଂ କେବେବି ଏହାକୁ Human ଭିତରେ convert କରେନାହିଁ। ଆପଣଙ୍କ application ପ୍ରତ୍ୟେକ route ପାଇଁ fallback ବାଛେ, ଏବଂ analytics coverage କେଉଁଠି ଶେଷ ହୁଏ ସେଥିରେ ଦେଖାଏ ଯାହାଦ୍ୱାରା ଆପଣ ଯେଉଁଠି ମୂଲ୍ୟ ଅଛି ସେଠି evidence ଯୋଡିପାରିବେ।
ଆମ team ସହ production application ଉପରେ ଏହା ସେଟ୍ କରିବାକୁ, early access ପାଇଁ apply କରନ୍ତୁ। Evidence ନିଜେ କ’ଣ establish କରିପାରେ ସେଥିକୁ ସଠିକ୍ ଭାବରେ ବୁଝିବାକୁ, Detection & Limitations ପଢ଼ନ୍ତୁ।
Sources
- RFC 9421: HTTP Message Signatures: standard ଯାହା automated client ମାନେ request sign କରିବାକୁ ବ୍ୟବହାର କରିପାରନ୍ତି
- draft-ietf-webbotauth-httpsig-protocol: signed automated traffic ପାଇଁ IETF Web Bot Auth draft (November 2026 ଅନୁସାରେ work in progress)
- OpenAI: Overview of OpenAI Crawlers: OpenAI's bots ପାଇଁ user agent string ଏବଂ published IP address file
- OWASP Automated Threats to Web Applications: credential stuffing ଏବଂ scraping ପରି automated threat ର taxonomy
- Node.js test runner: example ରେ ବ୍ୟବହୃତ
node:testmodule