சொற்களின் பொருள்
request path-இல் இருக்கும் ஒவ்வொரு சோதனையும் ஒரு பதிலை உருவாக்கத் தவறலாம்: ஒரு dependency time out ஆகும், ஒரு signal இல்லை, ஒரு key பெற முடியாது. Fail open என்பது check அங்கே இல்லாததுபோல் request தொடர்வதாகும். Fail closed என்பது request கடுமையான பாதையை எடுப்பதாகும்: அது மறுக்கப்படுகிறது, challenge செய்யப்படுகிறது அல்லது ஏற்கனவே உள்ள stronger control-க்கு அனுப்பப்படுகிறது.
இவற்றில் எதுவும் பொதுவாக சரியானது அல்ல. சரியான தேர்வு route என்ன செய்கிறது மற்றும் தவறான முடிவின் செலவு என்ன என்பதையே சார்ந்தது.
actor சோதனைகளுக்கு இது ஏன் முக்கியம்
actor சோதனைகள் request-களுக்கு context-ஐ சேர்க்கின்றன: interaction மனிதர் சார்ந்ததா, AI உதவியுடனானதா, agent இயக்கியதா அல்லது தெரியாததா என்பதை. அந்த context கிடைக்காதபோது, application இன்னும் பதிலளிக்க வேண்டியதுதான். இரண்டு failure pattern-கள் பொதுவாக காணப்படுகின்றன:
- தவறுதலாக fail closed. timeout அல்லது missing signal சந்தேகத்தக்கதாக கருதப்படுகிறது, outage போது உண்மையான பயனர்கள் தடுக்கப்படுகிறார்கள்.
- முக்கிய செயல்களில் தவறுதலாக fail open. missing result அமைதியாக human என கருதப்படுகிறது, மற்றும் அதிக தாக்கம் கொண்ட செயல் எதிர்பார்த்ததைவிட குறைவான ஆய்வுடன் தொடர்கிறது.
இரண்டும் தேர்வை மறைமுகமாக விட்டுவிடுவதிலிருந்து வருகிறது. தீர்வு அதை ஒவ்வொரு route-க்குமானாக தெளிவாக முடிவு செய்வதே. மனிதர்கள் மற்றும் AI agent-களுக்கான app-level policies வடிவமைப்பது குறித்து உள்ள எங்கள் பதிவில் (/blog/designing-app-policies-for-humans-and-ai-agents) failure behavior per-route policy-இல் எவ்வாறு பொருந்துகிறது என்பதைக் காட்டுகிறது.
எவ்வாறு தேர்வு செய்வது
ஒரு நடைமுறை அணுகுமுறை routes-ஐ risk tier-களாக குழுவாக்குவது:
- குறைந்த தாக்கம் (public pages, documentation, read-only catalog routes): fail open. missing actor result எதையும் மாற்றக் கூடாது.
- நடுத்தர தாக்கம் (signups, form submissions, செலவுள்ள searches): பொதுவாக logging உடன் fail open, அல்லது standard rate limit போன்ற மென்மையான adaptation-ஐப் பயன்படுத்தவும்.
- அதிக தாக்கம் (account மாற்றங்கள், data exports, திரும்பப்பெற முடியாத செயல்கள்): re-authentication அல்லது confirmation போன்ற ஏற்கனவே உள்ள stronger control-க்கு fail closed. நோக்கம் block செய்வது அல்ல, நீங்கள் எப்படியோ பயன்படுத்தும் check-க்கு மீண்டும் திரும்புவதே.
பின்னர் தொடர்புடைய நிலைகளுக்கு ஒரே நடத்தை வரையறுக்கவும்:
- Timeout: check நேரத்திற்குள் பதிலளிக்கவில்லை.
- Missing telemetry: integration இயங்கவில்லை அல்லது ஒரு signal இல்லை.
- Unknown: check இயங்கியது, ஆனால் evidence ஒரு முடிவை ஆதரிக்கவில்லை.
- Stale evidence: முடிவு முன்னதாக இருந்து வந்தது, மேலும் ஒரு அதிக sensitive செயலுக்கு அதை மீண்டும் பயன்படுத்தக் கூடாது.
பொதுவான தவறான புரிதல்கள்
- "Fail closed பாதுகாப்பானது." அது செலவை legitimiate பயனர்களிடம் மாற்றுகிறது. குறைந்த தாக்கம் உள்ள routes-க்கு, incident போது fail closed செய்வது தடுக்கும் risk-ஐவிட அதிக சேதத்தை ஏற்படுத்தலாம்.
- "Unknown என்பது failure." Unknown ஒரு செல்லுபடியாகும் முடிவு. அதற்கு தனியான explicit handling தேவை, அது timeout handling-உடன் பொருந்தலாம் அல்லது இல்லாமலும் இருக்கலாம்.
- "Missing result என்றால் human." evidence இல்லாததால் actor class-ஐ ஒருபோதும் ஊகிக்க வேண்டாம்.
Proof of Actor இதை எவ்வாறு கையாளுகிறது
Proof of Actor ஒருபோதும் timeout அல்லது Unknown result-க்கு Human ஐ ஒதுக்காது, மற்றும் அதை நிறுவுவது எதையும் block செய்யாது: teams முதலில் observation mode-இல் தொடங்குகின்றன. ஒவ்வொரு route மற்றும் risk tier-க்கான fail-open அல்லது fail-closed நடத்தை application owner-ன் தேர்வு; அது Route மூலம் உங்கள் சொந்த code-இல் பயன்படுத்தப்படுகிறது. அது enforcement-ஐ முன்னறிவிக்கக்கூடியதாக வைத்திருக்கிறது, மேலும் எந்த policy live ஆகும் முன்பும் outcomes-ஐ நீங்கள் சரிபார்க்க அனுமதிக்கிறது.
routing decisions எவ்வாறு பொருந்துகின்றன என்பதைப் படிக்கவும், அல்லது early access-க்கு விண்ணப்பிக்கவும்.