Actor-aware policies ਨੂੰ ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਕਿਵੇਂ ਲਾਗੂ ਕਰੀਏ

Actor-aware policies roll out ਕਰਦੇ ਸਮੇਂ ਕੀ ਗਲਤ ਹੋ ਸਕਦਾ ਹੈ?

Actor-aware policy ਇਹ ਤੈਅ ਕਰਦੀ ਹੈ ਕਿ ਤੁਹਾਡੀ application ਕਿਵੇਂ respond ਕਰਦੀ ਹੈ, ਇਸ ਆਧਾਰ 'ਤੇ ਕਿ ਕੌਣ ਜਾਂ ਕੀ act ਕਰ ਰਿਹਾ ਹੈ। ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਇਹ ਲੋਕਾਂ ਨੂੰ ਸੁਗਮ experience ਦਿੰਦੀ ਹੈ, legitimate agents ਨੂੰ structured ਰਸਤਾ ਦਿੰਦੀ ਹੈ, ਅਤੇ friction ਸਿਰਫ਼ ਉੱਥੇ ਜੋੜਦੀ ਹੈ ਜਿੱਥੇ ਇਸਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਕੀਤਾ ਜਾਵੇ ਤਾਂ ਇਹ real users ਨੂੰ ਬਾਹਰ ਕਰ ਸਕਦੀ ਹੈ, ਉਹ integrations ਤੋੜ ਸਕਦੀ ਹੈ ਜਿਨ੍ਹਾਂ 'ਤੇ ਤੁਹਾਡੇ customers ਨਿਰਭਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਐਸੇ support tickets ਪੈਦਾ ਕਰ ਸਕਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਦੀ ਕੋਈ ਵਜ੍ਹਾ ਨਹੀਂ ਸਮਝਾ ਸਕਦਾ।

ਫ਼ਰਕ ਕਦੇ-ਕਦੇ policy logic ਵਿੱਚ ਨਹੀਂ ਹੁੰਦਾ। ਇਹ rollout ਵਿੱਚ ਹੁੰਦਾ ਹੈ। (Policy model ਆਪਣੇ ਆਪ ਲਈ, humans ਅਤੇ AI agents ਲਈ app-level policies design ਕਰਨ ਨੂੰ ਵੇਖੋ।) ਇਹ guide ਇੱਕ staged process ਦੱਸਦੀ ਹੈ ਜਿਸਨੂੰ teams ਕਿਸੇ ਵੀ route ਲਈ follow ਕਰ ਸਕਦੀਆਂ ਹਨ: observe, preview, enforce ਕਰਨ ਲਈ ਇੱਕ slice, ਫਿਰ expand। ਹਰ stage ਦੀ ਇੱਕ ਸਪਸ਼ਟ exit criterion ਅਤੇ ਵਾਪਸੀ ਦਾ ਤੇਜ਼ ਰਸਤਾ ਹੁੰਦਾ ਹੈ।

ਤਿੰਨ modes

ਹਰ policy ਨੂੰ ਸੋਚੋ ਕਿ ਉਹ ਹਰ route 'ਤੇ ਤਿੰਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ mode ਵਿੱਚ ਚੱਲ ਰਹੀ ਹੈ:

• Observe. Classifications record ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ। Application exactly ਉਹੀ respond ਕਰਦੀ ਹੈ ਜਿਵੇਂ ਇਹਨਾਂ ਦੇ ਬਿਨਾਂ ਕਰਦੀ।
• Preview. Policy evaluate ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਅਤੇ ਇਸਦਾ decision record ਹੁੰਦਾ ਹੈ, ਪਰ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕੀ ਹੋ ਜਾਂਦਾ।
• Enforce. Decision real requests 'ਤੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ।

Mode route ਅਤੇ policy pair ਨਾਲ ਸੰਬੰਧਿਤ ਹੁੰਦਾ ਹੈ, ਨਾ ਕਿ ਪੂਰੀ application ਨਾਲ। ਤੁਹਾਡੇ documentation pages enforce ਹੋ ਸਕਦੇ ਹਨ ਜਦਕਿ ਤੁਹਾਡਾ checkout ਹਾਲੇ ਵੀ observe ਕਰ ਰਿਹਾ ਹੁੰਦਾ ਹੈ।

Step 1: ਆਪਣਾ baseline ਜਾਣਨ ਤੱਕ observe ਕਰੋ

ਹਰ route ਨੂੰ observe mode ਵਿੱਚ ਸ਼ੁਰੂ ਕਰੋ। ਘੱਟੋ-ਘੱਟ ਇਹ ਇਕੱਠਾ ਕਰੋ:

• route ਅਤੇ method,
• actor class (Human, Human + AI, Agent ਜਾਂ Unknown) ਅਤੇ ਇਸਦਾ basis (verified, declared, inferred ਜਾਂ unknown), ਜਿਵੇਂ application traffic ਲਈ ਸਾਡੀ taxonomy ਵਿੱਚ define ਕੀਤਾ ਗਿਆ ਹੈ,
• response status ਅਤੇ route ਲਈ ਇੱਕ ਸਧਾਰਣ outcome marker, ਜਿਵੇਂ "account created" ਜਾਂ "search returned results"।

ਇੰਨਾ ਚਲਾਓ ਕਿ normal weekly cycles ਅਤੇ ਉਸ ਦੌਰਾਨ ship ਹੋਣ ਵਾਲੀ ਕੋਈ ਵੀ release cover ਹੋ ਜਾਵੇ। ਫਿਰ ਹਰ ਉਸ route ਲਈ ਆਪਣਾ baseline ਲਿਖੋ ਜਿਸਦੀ ਤੁਹਾਨੂੰ ਚਿੰਤਾ ਹੈ: class mix, Unknown rate, ਅਤੇ ਹਰ class ਲਈ outcome rate। ਇਸ ਤੋਂ ਬਾਅਦ ਜੋ ਕੁਝ ਵੀ ਹੋਵੇਗਾ, ਤੁਸੀਂ ਇਹਨਾਂ ਨੰਬਰਾਂ ਨਾਲ compare ਕਰੋਗੇ।

Exit criterion: ਤੁਸੀਂ ਹਰ candidate route ਲਈ ਦੱਸ ਸਕਦੇ ਹੋ ਕਿ ਇਸਨੂੰ ਕੌਣ ਵਰਤਦਾ ਹੈ ਅਤੇ class ਦੇ ਅਨੁਸਾਰ outcomes ਕਿਵੇਂ ਵੱਖਰੇ ਹਨ।

Step 2: Policy ਨੂੰ data ਵਜੋਂ ਲਿਖੋ

Policies ਨੂੰ review, test ਅਤੇ rollback ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਉਹ data ਹੋਣ, ਨਾ ਕਿ ਇਧਰ-ਉਧਰ ਫੈਲੀਆਂ if statements।

type ActorClass = "human" | "human_ai" | "agent" | "unknown";
type Basis = "verified" | "declared" | "inferred" | "unknown";
type Action = "allow" | "adapt" | "challenge" | "review" | "limit";
type Mode = "observe" | "preview" | "enforce";

interface Rule {
  actor: ActorClass | "*";
  basis?: Basis[];
  action: Action;
}

interface RoutePolicy {
  route: string;
  mode: Mode;
  enforcePercent: number;
  rules: Rule[];
  fallback: Action;
}

export const policies: RoutePolicy[] = [
  {
    route: "GET /api/catalog",
    mode: "preview",
    enforcePercent: 0,
    rules: [
      { actor: "agent", basis: ["verified"], action: "allow" },
      { actor: "agent", basis: ["declared", "inferred"], action: "limit" },
    ],
    fallback: "allow",
  },
];

ਹਰ policy ਵਿੱਚ ਇੱਕ ਸਪਸ਼ਟ fallback ਹੁੰਦਾ ਹੈ। ਇਹ ਉਹ action ਹੈ ਜੋ Unknown results, timeouts ਅਤੇ ਕਿਸੇ ਵੀ ਐਸੇ case ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਕੋਈ rule cover ਨਹੀਂ ਕਰਦੀ। ਇਸਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਚੁਣਨਾ ਪੂਰੀ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ safety decision ਹੈ।

Step 3: ਇੱਕ ਥਾਂ evaluate ਕਰੋ

ਇੱਕੋ evaluation function modes ਦੇ across behavior ਨੂੰ consistent ਰੱਖਦੀ ਹੈ।

export function decide(policy: RoutePolicy, actor: ActorClass, basis: Basis): Action {
  for (const rule of policy.rules) {
    const actorMatch = rule.actor === "*" || rule.actor === actor;
    const basisMatch = !rule.basis || rule.basis.includes(basis);
    if (actorMatch && basisMatch) return rule.action;
  }
  return policy.fallback;
}

ਫਿਰ mode ਲਾਗੂ ਕਰੋ:

export function applyPolicy(policy: RoutePolicy, actor: ActorClass, basis: Basis, requestKey: string) {
  const decision = decide(policy, actor, basis);
  const inSlice = bucket(requestKey) < policy.enforcePercent;
  const enforced = policy.mode === "enforce" && inSlice;
  record({ route: policy.route, mode: policy.mode, actor, basis, decision, enforced });
  return enforced ? decision : "allow";
}

function bucket(key: string): number {
  let h = 0;
  for (const c of key) h = (h * 31 + c.charCodeAt(0)) >>> 0;
  return h % 100;
}

Stable bucket ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇੱਕੋ session ਜਾਂ client enforced slice ਵਿੱਚ ਅੰਦਰ ਜਾਂ ਬਾਹਰ ਹੀ ਰਹਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਲੋਕਾਂ ਨੂੰ requests ਦਰਮਿਆਨ behavior flip ਹੁੰਦਾ ਨਜ਼ਰ ਨਾ ਆਏ।

Step 4: Enforce ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ false positives ਕਿਵੇਂ ਮਾਪਦੇ ਹੋ?

ਇੱਕ route ਨੂੰ preview ਵਿੱਚ ਲੈ ਜਾਓ। ਹੁਣ ਹਰ request ਉਸ decision ਨੂੰ record ਕਰਦੀ ਹੈ ਜੋ ਇਸਨੂੰ ਮਿਲਣਾ ਸੀ। ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ policy ਠੀਕ ਹੈ ਜਾਂ ਨਹੀਂ।

False positive ਉਹ request ਹੈ ਜਿਸਨੂੰ policy restrict ਕਰਦੀ, ਪਰ ਜਿਸਨੂੰ allow ਹੋਣਾ ਚਾਹੀਦਾ ਸੀ। ਤੁਸੀਂ ਇਸਨੂੰ ਸਿਰਫ਼ classifications ਤੋਂ ਨਹੀਂ ਮਾਪ ਸਕਦੇ, ਕਿਉਂਕਿ classification ਹੀ ਉਹ ਚੀਜ਼ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ testing ਕਰ ਰਹੇ ਹੋ। ਇਸਨੂੰ legitimate use ਦੇ independent signals ਨਾਲ ਮਾਪੋ:

• request ਇੱਕ normal successful flow ਪੂਰਾ ਕਰਦੀ ਹੈ, ਜਿਵੇਂ signed-in user ਦਾ ਆਪਣਾ ਕੰਮ save ਕਰਨਾ,
• client ਇੱਕ ਜਾਣਿਆ partner integration ਜਾਂ ਇੱਕ verified operator ਹੈ ਜਿਸਦੀ ਸੇਵਾ ਕਰਨ 'ਤੇ ਤੁਸੀਂ ਸਹਿਮਤ ਹੋ,
• support tickets ਜਾਂ user reports affected route ਦਾ ਹਵਾਲਾ ਦਿੰਦੇ ਹਨ,
• would-be restricted requests ਦੇ sample ਦੀ manual review।

ਇੱਕ sample ਨੂੰ ਹੱਥੋਂ review ਕਰੋ। ਉਹੀ ਵੀਹ real requests ਪੜ੍ਹਨਾ ਜਿਨ੍ਹਾਂ ਨੂੰ policy challenge ਕਰਦੀ, ਇੱਕ rule ਲੱਭਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ ਜੋ ਬਹੁਤ ਵੱਡੀ ਹੈ।

Exit criterion: would-be restricted set ਉਸ traffic ਨਾਲ dominate ਹੁੰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਸੱਚਮੁੱਚ restrict ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਤੁਹਾਡੇ ਕੋਲ false positive ਦੀ ਹਰ category ਲਈ ਵਜ੍ਹਾ ਹੈ ਜੋ ਤੁਸੀਂ ਲੱਭੀ।

Step 5: ਇੱਕ slice ਲਈ enforce ਕਰੋ

Route ਨੂੰ ਛੋਟੇ enforcePercent ਨਾਲ enforce 'ਤੇ ਬਦਲੋ। Slice ਨੂੰ ਇੰਨਾ ਛੋਟਾ ਰੱਖੋ ਕਿ ਗਲਤੀ ਕੁਝ requests ਨੂੰ ਹੀ ਪ੍ਰਭਾਵਿਤ ਕਰੇ, ਅਤੇ ਇੰਨਾ ਵੱਡਾ ਕਿ ਇੱਕ ਜਾਂ ਦੋ ਦਿਨਾਂ ਵਿੱਚ measurable signal ਮਿਲ ਜਾਵੇ।

ਉਹੀ metrics ਦੇਖੋ ਜੋ ਤੁਸੀਂ baseline ਵਜੋਂ set ਕੀਤੀਆਂ ਸਨ:

• route 'ਤੇ ਹਰ class ਲਈ outcome rate,
• error ਅਤੇ challenge completion rates,
• route ਦਾ ਜ਼ਿਕਰ ਕਰਨ ਵਾਲਾ support volume,
• latency, ਕਿਉਂਕਿ evaluation request path 'ਤੇ ਹੁੰਦੀ ਹੈ।

ਜੇ enforced slice ਵਿੱਚ Human traffic ਦੇ outcomes ਬਾਕੀ ਨਾਲ compare ਕਰਨ 'ਤੇ ਘਟਦੇ ਹਨ, ਤਾਂ ਰੁਕੋ ਅਤੇ expand ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚ ਕਰੋ।

Step 6: ਹੌਲੀ-ਹੌਲੀ expand ਕਰੋ

Slice ਨੂੰ ਕਦਮਾਂ ਵਿੱਚ ਵਧਾਓ, ਉਦਾਹਰਣ ਲਈ ਛੋਟੀ share ਤੋਂ quarter, ਫਿਰ half, ਫਿਰ ਸਾਰੀ traffic, ਅਤੇ ਹਰ step 'ਤੇ ਇੰਨਾ ਰੁਕੋ ਕਿ normal cycle ਦਿਖ ਸਕੇ। ਜਦੋਂ ਪਹਿਲੇ stages ਠੀਕ ਤਰੀਕੇ ਨਾਲ ਕੀਤੇ ਗਏ ਹੋਣ, ਤਾਂ expansion ਨੀਰਸ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ। ਉਹੀ goal ਹੈ।

Fallbacks ਅਤੇ failure behavior ਚੁਣਨਾ

ਪਹਿਲਾਂ ਹੀ ਤੈਅ ਕਰੋ ਕਿ ਜਦੋਂ evidence ਗਾਇਬ ਹੋਵੇ ਜਾਂ evaluation ਚੱਲ ਨਾ ਸਕੇ, ਤਾਂ ਕੀ ਹੋਵੇਗਾ।

• Fail open ਦਾ ਮਤਲਬ ਹੈ ਕਿ request actor context ਬਿਨਾਂ ਵੀ ਉਸੇ ਤਰ੍ਹਾਂ proceed ਕਰਦੀ ਹੈ ਜਿਵੇਂ ਕਰਦੀ। ਇਸਨੂੰ low-risk routes ਲਈ ਵਰਤੋ ਜਿਵੇਂ public pages, documentation ਅਤੇ read-only catalog endpoints।
• Fail closed ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਡਾ ਮੌਜੂਦਾ stronger check ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ re-authentication ਜਾਂ review queue। ਇਸਨੂੰ high-impact actions ਲਈ ਵਰਤੋ ਜਿੱਥੇ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਐਸਾ check ਹੈ।

Timeout ਜਾਂ error ਨੂੰ ਕਦੇ ਵੀ Human result ਨਾ ਬਣਨ ਦਿਓ। Missing evidence Unknown ਹੈ, ਅਤੇ Unknown route ਦੇ fallback ਨੂੰ ਲੈਂਦਾ ਹੈ। AI traffic ਨੂੰ classify ਕਰਦੇ ਸਮੇਂ Unknown ਇੱਕ valid result ਕਿਉਂ ਹੈ ਬਾਰੇ ਸਾਡੀ post ਦੱਸਦੀ ਹੈ ਕਿ ਇਹ rule ਕਿਉਂ ਮਹੱਤਵਪੂਰਨ ਹੈ।

async function actorWithTimeout(evaluate: () => Promise<{ actor: ActorClass; basis: Basis }>) {
  const timeout = new Promise<{ actor: ActorClass; basis: Basis }>((resolve) =>
    setTimeout(() => resolve({ actor: "unknown", basis: "unknown" }), 150),
  );
  return Promise.race([evaluate(), timeout]);
}

Policy ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ rollback ਕਿਵੇਂ ਕਰਦੇ ਹੋ?

Rollback ਇੱਕ configuration change ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, deploy ਨਹੀਂ। Policies ਨੂੰ ਐਸੇ store ਵਿੱਚ ਰੱਖੋ ਜਿਸਨੂੰ ਤੁਹਾਡੀ team ਤੇਜ਼ੀ ਨਾਲ edit ਕਰ ਸਕੇ, ਅਤੇ ਇਹ actions instant ਬਣਾਓ:

1. Route ਨੂੰ ਵਾਪਸ preview ਵਿੱਚ set ਕਰੋ, ਜਿਸ ਨਾਲ measurement ਕਾਇਮ ਰਹਿੰਦੀ ਹੈ ਅਤੇ enforcement ਰੁਕ ਜਾਂਦੀ ਹੈ।
2. enforcePercent ਨੂੰ zero ਤੇ set ਕਰੋ।
3. ਹੋਰ rules ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਇੱਕੋ rule disable ਕਰੋ।

ਹਰ policy change ਨੂੰ ਇਸ ਗੱਲ ਨਾਲ record ਕਰੋ ਕਿ ਕਿਸਨੇ ਅਤੇ ਕਦੋਂ ਕੀਤਾ। ਜਦੋਂ outcomes move ਕਰਦੇ ਹਨ, ਪਹਿਲਾ ਸਵਾਲ ਹਮੇਸ਼ਾ ਇਹ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਬਦਲਿਆ।

ਲੋਕਾਂ ਬਾਰੇ consequential decisions ਤੋਂ ਬਚੋ

Actor classifications ਇੱਕ interaction ਬਾਰੇ evidence ਦਿਖਾਉਂਦੀਆਂ ਹਨ। ਇਹ ਕਿਸੇ ਵਿਅਕਤੀ ਬਾਰੇ judgment ਨਹੀਂ ਹਨ। ਕਿਸੇ inferred class ਨੂੰ ਅਜੇਹੇ decisions ਦਾ ਇਕੱਲਾ ਆਧਾਰ ਨਾ ਬਣਾਓ ਜੋ ਕਿਸੇ ਦੀ employment, credit, education, housing ਜਾਂ essential services ਤੱਕ ਪਹੁੰਚ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੇ ਹੋਣ। ਐਸੀਆਂ flows ਲਈ, actor context ਨੂੰ outcome decide ਕਰਨ ਦੀ ਬਜਾਏ process ਚੁਣਨ ਲਈ ਵਰਤੋ, ਉਦਾਹਰਣ ਲਈ human review ਵੱਲ route ਕਰਨਾ।

Enforce ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ communicate ਕਰੋ

ਜਿਹੜੀਆਂ policies automated clients ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦਾ ਅਸਰ ਉਹਨਾਂ ਲੋਕਾਂ ਅਤੇ companies 'ਤੇ ਵੀ ਪੈਂਦਾ ਹੈ ਜੋ ਉਹਨਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ। ਥੋੜ੍ਹੀ communication ਕਾਫੀ support work ਬਚਾ ਸਕਦੀ ਹੈ:

1. Automated access ਲਈ ਆਪਣੇ rules publish ਕਰੋ। ਦੱਸੋ ਕਿ ਕਿਹੜੇ routes open ਹਨ, ਕਿਹੜੀਆਂ limits ਲਾਗੂ ਹਨ, ਅਤੇ clients signed requests ਨਾਲ ਆਪਣੇ ਆਪ ਨੂੰ ਕਿਵੇਂ identify ਕਰ ਸਕਦੇ ਹਨ HTTP Message Signatures (RFC 9421) ਅਤੇ IETF Web Bot Auth protocol draft ਦੀ ਵਰਤੋਂ ਕਰਕੇ।
2. Partners ਅਤੇ integrators ਨੂੰ ਪਹਿਲਾਂ ਦੱਸੋ। ਜੇ preview ਦੌਰਾਨ ਕੋਈ ਜਾਣਿਆ integration restricted slice ਵਿੱਚ ਆ ਜਾਂਦਾ ਹੈ, ਤਾਂ enforce ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸਦੇ owner ਨਾਲ ਸੰਪਰਕ ਕਰੋ।
3. Useful responses ਵਾਪਸ ਦਿਓ। ਜਦੋਂ ਕੋਈ policy request ਨੂੰ limit ਜਾਂ challenge ਕਰਦੀ ਹੈ, ਤਾਂ ਇੱਕ clear status code ਨਾਲ respond ਕਰੋ, ਜਿਵੇਂ 429 Too Many Requests ਨਾਲ Retry-After, ਅਤੇ ਆਪਣੀ documentation ਦਾ link ਦਿਓ। Problem Details format ਵਿੱਚ ਇੱਕ machine-readable body automated clients ਨੂੰ structured reason ਦਿੰਦੀ ਹੈ। ਚੰਗੀ ਤਰ੍ਹਾਂ ਬਣੇ agents adapt ਕਰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਸਮਝ ਲੈਂਦੇ ਹਨ ਕਿ ਕਿਉਂ।
4. ਆਪਣੀ support team ਨੂੰ evidence ਦਿਓ। ਜਦੋਂ blocked request ਬਾਰੇ ticket ਆਵੇ, support route, class, basis ਅਤੇ policy decision engineering ਨੂੰ ਪੁੱਛੇ ਬਿਨਾਂ ਲੱਭ ਸਕਦੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।

ਜਿਹੜੀਆਂ teams changes announce ਕਰਦੀਆਂ ਹਨ ਅਤੇ ਉਹਨਾਂ ਨੂੰ explain ਕਰਦੀਆਂ ਹਨ, ਉਹ quiet rule switches ਕਰਨ ਵਾਲੀਆਂ teams ਨਾਲੋਂ ਕਿਤੇ ਘੱਟ surprises ਵੇਖਦੀਆਂ ਹਨ, ਅਤੇ ਜੋ clients adapt ਕਰਦੇ ਹਨ ਉਹ ਸਮੇਂ ਦੇ ਨਾਲ ਪਛਾਣਣ ਵਿੱਚ ਆਸਾਨ ਹੋ ਜਾਂਦੇ ਹਨ।

ਹਰ route ਲਈ ਇੱਕ checklist

• Class mix, Unknown rate ਅਤੇ outcomes ਲਈ baseline recorded ਹੈ।
• Policy data ਵਜੋਂ explicit fallback ਨਾਲ ਲਿਖੀ ਗਈ ਹੈ।
• Preview ਚੱਲਿਆ, sample review ਹੋਇਆ, false positive categories explain ਕੀਤੀਆਂ ਗਈਆਂ।
• Enforcement ਛੋਟੀ slice 'ਤੇ ਸ਼ੁਰੂ ਹੋਈ ਅਤੇ metrics ਦੇਖੀਆਂ ਗਈਆਂ।
• Failure behavior ਚੁਣਿਆ ਗਿਆ: fail open ਜਾਂ fail closed।
• Expansion ਤੋਂ ਪਹਿਲਾਂ rollback test ਕੀਤਾ ਗਿਆ।

Proof of Actor ਕਿੱਥੇ fit ਹੁੰਦਾ ਹੈ

Proof of Actor ਇਸ process ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਬਣਾਇਆ ਗਿਆ ਹੈ। Observation default ਹੈ, ਹਰ result ਆਪਣਾ basis ਲੈ ਕੇ ਆਉਂਦਾ ਹੈ, ਅਤੇ Route policies ਤੁਹਾਡੀਆਂ ਹਨ - ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਆਪਣੇ code ਵਿੱਚ, route by route, define ਅਤੇ enforce ਕਰਦੇ ਹੋ। Detect, Understand, Route: ਇਸੀ ਕ੍ਰਮ ਵਿੱਚ।

ਆਪਣੀ application 'ਤੇ ਆਪਣੀ team ਨਾਲ ਇੱਕ rollout ਤੋਂ ਗੁਜ਼ਰਨ ਲਈ, early access ਲਈ apply ਕਰੋ. Decision flow ਨੂੰ end to end ਪੜ੍ਹਨ ਲਈ, How Proof of Actor works ਨੂੰ ਵੇਖੋ।

Sources

• RFC 6585: Additional HTTP Status Codes, Section 4: 429 Too Many Requests status code
• RFC 9110: HTTP Semantics, Retry-After: clients ਨੂੰ ਕਦੋਂ retry ਕਰਨਾ ਹੈ ਦੱਸਣਾ
• RFC 9457: Problem Details for HTTP APIs: machine-readable error bodies
• RFC 9421: HTTP Message Signatures: automated clients requests ਕਿਵੇਂ sign ਕਰਦੇ ਹਨ
• draft-ietf-webbotauth-httpsig-protocol: signed automated traffic ਲਈ IETF Web Bot Auth draft (November 2026 ਤੱਕ work in progress)