Swiss Cheese Model for LLM Evaluation: 단일 Grader는 반드시 실패한다

https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Executive Summary

James Reason(1990)의 Swiss Cheese Model은 복잡 시스템에서 사고가 단일 실패가 아닌 다중 방어층의 구멍이 동시에 정렬될 때 발생한다는 프레임워크입니다. 본 문서는 이 모델을 LLM Agent 평가에 적용합니다.
Anthropic의 "Demystifying Evals for AI Agents"(2026.01)는 Agent 평가의 3가지 Grader 유형(code-based, model-based, human)과 평가 하네스 설계를 체계적으로 정리합니다. 각 Grader 유형을 치즈 슬라이스로, 각 Grader의 한계를 구멍으로 모델링하며, 구멍이 정렬되는 순간, 즉 결함이 모든 평가층을 통과하는 시나리오를 서술합니다.

---

1. Swiss Cheese Model: 핵심 구조

1.1 Reason의 원래 모델

James Reason은 1990년 저서 Human Error에서, 이후 2000년 BMJ 논문에서 이 모델을 정립했습니다.
핵심 구조는 다음과 같습니다:

[위험/결함] → [방어층 1] → [방어층 2] → [방어층 3] → [방어층 4] → [사고/실패]
                  ↑              ↑              ↑              ↑
               구멍 있음       구멍 있음       구멍 있음       구멍 있음

각 방어층 = 스위스 치즈 한 슬라이스
각 구멍 = 해당 방어층의 취약점

사고 발생 조건: 모든 슬라이스의 구멍이 동시에 정렬
→ 결함이 모든 방어층을 관통

 
원래 모델의 두 가지 실패 유형:

Active Failure	즉각적이고 직접적인 오류	조종사의 잘못된 판단, 간호사의 투약 실수
Latent Condition	시스템에 내재된, 장기간 잠복하는 조건	피로를 유발하는 교대 정책, 불충분한 훈련 체계

 
핵심 통찰은 단일 방어층에 대한 과신이 시스템을 더 취약하게 만든다는 것입니다. 각 슬라이스의 구멍은 고정되어 있지 않고 열리고 닫히며, 크기가 변합니다. 어느 한 순간에 모든 구멍이 정렬될 확률은 낮지만, 방어층이 적을수록 그 확률은 급격히 높아집니다.

1.2 LLM 평가에서의 적용

이 모델을 LLM Agent 평가로 포팅하면:

[Agent의 결함] → [Grader 1] → [Grader 2] → [Grader 3] → [Human Review] → [Production 사고]
                    ↑              ↑              ↑              ↑
                 구멍 있음       구멍 있음       구멍 있음       구멍 있음

결함 = Agent의 잘못된 행동, 부정확한 출력, 유해한 응답
각 Grader = 방어 슬라이스
각 구멍 = 해당 Grader가 포착하지 못하는 결함 유형
Production 사고 = 결함이 모든 평가층을 통과하여 사용자에게 도달

Swiss Cheese 원칙의 LLM 평가 버전:

어떤 단일 Grader도 모든 결함을 포착할 수 없다. 시스템 신뢰성은 개별 Grader의 완벽성이 아니라, 서로 다른 구멍을 가진 Grader들의 조합에서 나온다.

---

2. 슬라이스 해부: 각 Grader 유형의 구멍

Anthropic의 분류에 따르면, Agent 평가의 Grader는 3가지 유형으로 나뉩니다.
각 유형은 고유한 강점과 고유한 구멍을 가집니다.

2.1 Slice 1: Code-Based Grader

방법: string match, regex, unit test, static analysis, outcome verification, tool call 검증
강점: 빠름, 저렴, 객관적, 재현 가능, 디버깅 용이

이 슬라이스의 구멍들:

Brittleness	유효하지만 예상과 다른 형태의 정답을 오탐	"96.12"를 기대했는데 "96.124991"을 출력 → 실패 처리
Creative Solution Blind	Agent가 설계자가 예상하지 못한 더 나은 해법을 찾은 경우	Opus 4.5가 τ2-bench에서 항공사 정책의 허점을 발견하여 더 나은 솔루션 제시 → "실패" 판정
Nuance Deficit	주관적 품질(톤, 공감, 설명의 명확성)을 측정 불가	고객 지원 Agent가 정확한 정보를 제공했으나 무례한 톤 → code grader는 통과
Specification Gap	태스크 명세의 모호함이 grader에 그대로 반영	"스크립트를 작성하라"에서 파일 경로 미지정 → agent가 다른 경로에 저장 → 실패

CORE-Bench 사례: Opus 4.5가 초기에 42%를 기록했으나, 연구자가 조사한 결과 rigid grading, ambiguous task spec, stochastic task 문제를 발견했습니다. 수정 후 95%로 상승 — 구멍은 Agent가 아니라 Grader에 있었습니다.

2.2 Slice 2: Model-Based Grader (LLM-as-Judge)

방법: rubric 기반 점수, 자연어 assertion, pairwise comparison, multi-judge consensus
강점: 유연함, 확장 가능, 뉘앙스 포착, 개방형 태스크 처리

이 슬라이스의 구멍들:

Non-determinism	동일 입력에 대해 다른 판정	같은 transcript를 두 번 판정하면 결과 불일치 가능
Calibration Drift	시간에 따라 판정 기준이 미묘하게 이동	모델 업데이트 후 이전과 다른 기준 적용
Hallucinated Judgment	근거 없는 판정 생성	"Agent가 정책을 정확히 인용했다"고 판정 — 실제로는 인용하지 않음
Sycophancy	그럴듯한 출력에 높은 점수 부여	자신감 있는 톤의 잘못된 답변에 높은 점수
Anchoring	첫 번째 정보에 편향	여러 차원을 동시에 평가할 때 첫 차원의 점수가 나머지에 영향

Anthropic은 이에 대한 구체적 대응을 제시합니다: 각 차원을 독립된 LLM-as-Judge로 분리 평가하고, "Unknown" 반환 옵션을 제공하여 환각을 줄이며, human expert와의 주기적 calibration으로 drift를 감지합니다.

2.3 Slice 3: Human Grader

방법: SME(Subject Matter Expert) 리뷰, crowdsourced judgment, spot-check, A/B 테스트
강점: gold standard 품질, 전문가 판단과 일치, model-based grader 보정에 사용

이 슬라이스의 구멍들:

Scalability	대규모 평가에 물리적 한계	1,000개 태스크 × 3 trials × 5분/trial = 250시간
Inter-annotator Disagreement	전문가 간 판단 불일치	"comprehensive"의 기준이 사람마다 다름
Fatigue Degradation	장시간 리뷰 시 판정 품질 하락	200번째 transcript의 판정은 20번째와 다를 수 있음
Latency	피드백 루프가 느림	결과를 며칠 후에야 확인 가능 → 빠른 반복 불가
Availability	도메인 전문가 확보의 어려움	의료/법률 도메인에서 전문가 시간 비용

2.4 구멍의 정렬: 결함이 관통하는 시나리오

Swiss Cheese Model의 핵심은 개별 구멍이 아니라 구멍의 정렬입니다. 다음은 실제로 발생 가능한 정렬 시나리오입니다:

시나리오: Agent가 "정확하지만 유해한" 응답을 생성

Slice 1 (Code-Based):
  → Unit test 통과 (기술적으로 정확한 코드)
  → Static analysis 통과 (린트 에러 없음)
  → ✅ 구멍: 유해성은 코드 검증의 영역 밖

Slice 2 (Model-Based):
  → LLM-as-Judge가 "기술적 정확성" 차원에서 높은 점수 부여
  → ✅ 구멍: 유해성 rubric이 없거나, sycophancy로 간과

Slice 3 (Human):
  → Spot-check 대상에서 제외 (샘플링 확률 5%)
  → ✅ 구멍: 해당 trial이 리뷰되지 않음

결과: 유해한 응답이 모든 방어층을 관통 → Production 사고

이 시나리오에서 각 슬라이스는 자신의 역할을 수행했습니다. 문제는 어떤 슬라이스도 "유해성" 차원을 담당하지 않았다는 것입니다. 방어층의 수가 아니라 방어층의 커버리지 다양성이 핵심입니다.

---

3. 방어 아키텍처 설계: 구멍을 정렬시키지 않는 법

3.1 원칙 1: 직교 슬라이스 (Orthogonal Slices)

가장 효과적인 방어는 서로 다른 차원을 평가하는 슬라이스의 조합입니다.

직교 설계 (좋은 예):
┌─────────────────────────────────────────────────────┐
│ Slice 1: Code — 기능적 정확성 (Does it work?)       │
│ Slice 2: LLM  — 커뮤니케이션 품질 (Is it clear?)   │
│ Slice 3: LLM  — 안전성/유해성 (Is it safe?)         │
│ Slice 4: Code — 효율성 (Is it fast enough?)         │
│ Slice 5: Human — 종합 판단 (샘플링)                  │
└─────────────────────────────────────────────────────┘
→ 각 슬라이스가 다른 차원을 커버 → 구멍 정렬 확률 최소화

중복 설계 (나쁜 예):
┌─────────────────────────────────────────────────────┐
│ Slice 1: Code — string match로 정답 확인             │
│ Slice 2: Code — regex로 정답 확인                    │
│ Slice 3: Code — exact match로 정답 확인              │
└─────────────────────────────────────────────────────┘
→ 세 슬라이스가 동일한 차원을 커버 → 동일한 구멍을 공유
→ Creative solution이면 3개 모두 실패 (구멍 완벽 정렬)

 
핵심: 슬라이스의 수보다 슬라이스 간 직교성(orthogonality)이 중요합니다.
같은 차원을 3번 검증하는 것보다 3개의 다른 차원을 각 1번 검증하는 것이 시스템을 더 견고하게 만듭니다.

3.2 원칙 2: Outcome 우선, Path 후순위

Anthropic이 강조하는 핵심 설계 원칙입니다:

"Agent가 생산한 것(what)을 평가하라, 경로(how)를 평가하지 마라."

❌ 경로 기반 평가 (Brittle):
  "agent는 반드시 read_file → edit_file → run_tests 순서로 tool을 호출해야 한다"
  → Agent가 다른 유효한 경로를 발견하면 실패

✅ 결과 기반 평가 (Robust):
  "수정된 코드가 보안 취약점을 해결하고, 기존 테스트를 통과해야 한다"
  → Agent가 어떤 경로를 택하든, 결과가 올바르면 통과

 
경로 기반 평가는 Swiss Cheese 관점에서 구멍이 매우 큰 슬라이스입니다.
frontier 모델이 평가 설계자의 예상을 넘어서는 해법을 찾을수록, 이 구멍은 더 커집니다.

3.3 원칙 3: Partial Credit (부분 점수)

Binary pass/fail은 정보를 버립니다:

시나리오: 고객 지원 Agent

Agent A: 문제 진단 ✅, 고객 확인 ✅, 환불 처리 ❌
Agent B: 문제 진단 ❌, 고객 확인 ❌, 환불 처리 ❌

Binary 평가: 둘 다 FAIL (동일 점수)
Partial Credit: A = 66점, B = 0점 (실질적 차이 반영)

 
Partial credit은 Swiss Cheese의 구멍 크기를 줄이는 메커니즘입니다.
Binary 평가의 구멍은 "올바르지만 불완전한 모든 응답"이며, 이 구멍은 매우 큽니다.

3.4 원칙 4: 양방향 균형 (Balanced Problem Sets)

문제: 검색 Agent가 검색해야 할 때만 테스트하면?
→ Agent가 모든 질문에 검색하도록 최적화
→ "Apple을 창립한 사람이 누구인가?"에도 웹 검색 수행

해결: 양방향 테스트
검색 해야 하는 케이스: "오늘 서울 날씨는?" (should search)
검색 하면 안 되는 케이스: "Apple의 창립자는?" (should not search)

 
Anthropic은 Claude.ai의 웹 검색 평가에서 이 문제를 직접 경험했다고 보고합니다.
한 방향만 테스트하는 eval은 Swiss Cheese 관점에서 한쪽 면이 완전히 열린 슬라이스 — 방어 기능이 절반만 작동합니다.

---

4. 슬라이스의 시간 축: Capability Eval → Regression Eval

Swiss Cheese Model의 원래 이론에서 구멍은 고정되어 있지 않습니다. 
열리고 닫히며, 크기가 변합니다. LLM 평가에서도 동일한 역학이 존재합니다.

4.1 Eval의 생애 주기

Phase 1: Capability Eval (질 평가)
  목표: "이 Agent가 무엇을 잘 하는가?"
  초기 pass rate: 낮음 (30-50%)
  용도: 개선 방향 제시, hill-climbing 지표

    ↓ Agent 개선으로 pass rate 상승

Phase 2: Graduation (졸업)
  조건: pass rate가 안정적으로 높아짐 (90%+)
  전환: Capability eval → Regression eval로 승격

Phase 3: Regression Eval (회귀 테스트)
  목표: "기존에 되던 것이 여전히 되는가?"
  기대 pass rate: ~100%
  용도: 변경 후 퇴행 감지

    ↓ 평가 포화 (Eval Saturation) 발생

Phase 4: Eval Refresh
  증상: 100% pass rate → 개선 신호 없음
  대응: 더 어려운 태스크 추가 또는 새로운 eval suite 설계

Swiss Cheese 관점에서 해석하면: Capability eval의 구멍은 크지만 Agent가 개선되며 구멍을 채웁니다. Regression eval은 구멍이 다시 열리는 것을 감시합니다. Eval saturation은 슬라이스가 너무 얇아져서 더 이상 방어 기능을 하지 못하는 상태입니다.

4.2 Saturation의 함정

SWE-Bench Verified는 이 패턴의 실례입니다:

2025 초: frontier 모델 30% pass rate → 강력한 capability 신호
2025 말: frontier 모델 80%+ → saturation 접근
결과: 큰 capability 향상이 작은 점수 차이로 나타남

Qodo의 경험:
Opus 4.5의 one-shot coding eval → "인상적이지 않음"
새로운 agentic eval 설계 → 장시간 복잡 태스크에서 큰 차이 발견
→ eval이 포화되면 Agent가 아니라 eval을 의심해야 함

4.3 Non-determinism 대응: pass@k vs pass^k

Agent의 비결정성은 Swiss Cheese Model에서 구멍의 위치가 매 실행마다 변하는 것에 해당합니다:

pass@k: k번 시도 중 최소 1번 성공할 확률
  → k 증가 시 점수 상승
  → "하나라도 되면 되는" 시나리오 (코딩: 하나의 해법이면 충분)

pass^k: k번 시도 모두 성공할 확률  
  → k 증가 시 점수 하락
  → "매번 되어야 하는" 시나리오 (고객 지원: 항상 일관된 품질)

수학적 관계:
per-trial success rate = p
pass@k ≈ 1 - (1-p)^k     → k=10, p=0.75: 94%
pass^k = p^k               → k=10, p=0.75: 6%

k=1에서 두 메트릭은 동일합니다: 둘 다 p.
k가 증가하면 극적으로 diverge합니다.

Swiss Cheese 해석: pass@k는 "구멍이 한 번이라도 정렬되지 않을 확률"이고, pass^k는 "구멍이 한 번도 정렬되지 않을 확률"입니다. 고객 대면 Agent에서 pass^k를 사용해야 하는 이유가 여기에 있습니다 — 사용자는 매 상호작용에서 일관된 품질을 기대합니다.

---

5. Eval Harness: 슬라이스를 담는 구조

5.1 환경 격리: Latent Condition 차단

Reason의 원래 모델에서 Latent Condition은 시스템에 내재된, 장기간 잠복하는 조건입니다. Eval harness에서의 latent condition은 공유 상태(shared state)입니다:

Latent Condition 예시:
- 이전 trial의 잔여 파일이 다음 trial에 영향
- git history에서 이전 trial의 답안을 참조
- 메모리/CPU 고갈로 인한 상관된 실패
- 캐시된 데이터가 결과를 오염

→ 이 조건들은 eval 결과를 왜곡하지만, 개별 trial에서는 보이지 않음
→ Reason이 말한 "interdepartmental interstices"의 정확한 디지털 번역

대응: 각 trial을 clean environment에서 시작
→ Latent condition의 축적을 구조적으로 차단

Anthropic은 내부 eval에서 Claude가 이전 trial의 git history를 참조하여 "부당한 이점"을 얻은 사례를 보고합니다. 이것은 eval 결과를 부풀리는 latent condition입니다.

5.2 Transcript 읽기: 구멍의 지도를 그리는 방법

Swiss Cheese Model에서 구멍의 위치를 파악하려면 방어층을 직접 검사해야 합니다. LLM 평가에서 이에 해당하는 것이 transcript(궤적) 읽기입니다.

Anthropic의 원칙:
"Eval 점수를 누군가가 세부사항을 파고들어
 transcript를 읽기 전까지는 액면가로 받아들이지 않는다."

Transcript가 드러내는 것:
1. Agent가 진정한 실수를 했는가, 아니면 grader가 유효한 해법을 거부했는가?
2. 실패가 공정한가? — Agent의 잘못이 명확하고 이해 가능한가?
3. 점수가 오르지 않는 원인이 Agent인가, eval인가?

이것은 Swiss Cheese 관점에서 구멍의 지도를 그리는 행위입니다. 지도 없이는 어떤 슬라이스를 보강해야 하는지 알 수 없습니다.

---

6. 실전 적용: Agent 유형별 슬라이스 구성

Anthropic이 분류한 4가지 Agent 유형에 대해, Swiss Cheese 관점에서 최적의 슬라이스 조합을 제안합니다.

6.1 Coding Agent

Slice 1: Deterministic Test   — unit test pass/fail (기능 정확성)
Slice 2: Static Analysis      — lint, type check, security scan (코드 품질)
Slice 3: LLM Rubric           — 코드 가독성, 구조, 관례 준수 (설계 품질)
Slice 4: State Check           — 환경 상태 검증 (부수 효과)
Slice 5: Transcript Metrics   — turns, tokens, latency (효율성)

핵심 구멍: Creative solution이 rigid test를 실패시키는 문제
→ 대응: Outcome 기반 평가 우선, path 검증은 보조적으로만

6.2 Conversational Agent

Slice 1: LLM Rubric           — 공감, 톤, 명확성 (커뮤니케이션 품질)
Slice 2: State Check           — 티켓 해결, 환불 처리 (태스크 완료)
Slice 3: Tool Call Verify      — 신원 확인, 정책 조회 (프로세스 준수)
Slice 4: Transcript Constraint — max turns, 응답 길이 (효율성)
Slice 5: Simulated User        — LLM이 user persona로 다회차 상호작용 (스트레스 테스트)

핵심 구멍: 다차원 품질 — "해결했지만 무례한" 응답
→ 대응: 각 차원을 독립된 LLM-as-Judge로 분리 평가

6.3 Research Agent

Slice 1: Groundedness Check    — 주장이 인용된 소스에 근거하는가 (환각 방지)
Slice 2: Coverage Check        — 핵심 사실을 빠뜨리지 않았는가 (완전성)
Slice 3: Source Quality        — 인용 소스가 권위 있는가 (신뢰성)
Slice 4: Exact Match           — 객관적 수치가 정확한가 (정밀도)
Slice 5: LLM Coherence         — 종합 보고서의 일관성과 완결성 (품질)

핵심 구멍: 주관적 품질 — "comprehensive"의 기준이 불명확
→ 대응: LLM rubric을 human expert와 주기적으로 calibrate

6.4 Computer Use Agent

Slice 1: URL/Page State        — 올바른 페이지에 도달했는가 (네비게이션)
Slice 2: Backend State         — 실제로 주문이 생성되었는가 (결과 검증)
Slice 3: File System Check     — 생성된 파일이 올바른가 (산출물)
Slice 4: Efficiency Metrics    — 토큰 사용량, 지연 시간 (비용 효율)
Slice 5: Tool Selection        — DOM vs Screenshot 적절히 선택했는가 (방법 최적성)

핵심 구멍: UI 상태와 backend 상태의 불일치
→ "확인 페이지가 표시됨"과 "주문이 실제로 생성됨"은 다른 사실
→ 대응: backend state verification 필수

---

7. Anti-Pattern: 구멍을 넓히는 실수들

7.1 단일 슬라이스 과신

"Unit test만 통과하면 된다"
→ Code-based grader 하나에 모든 것을 의존
→ Swiss Cheese에서 슬라이스가 1개 = 구멍 정렬 확률 = 그 슬라이스의 구멍 확률
→ 방어 없음과 같음

7.2 동질적 슬라이스 중첩

"LLM-as-Judge를 3개 돌리면 3배 안전하다"
→ 같은 모델, 같은 rubric → 동일한 구멍을 공유
→ 확증편향이 3배 증폭될 뿐
→ Reason: "adding layers of the same cheese doesn't help"

개선: 3개의 LLM judge를 쓸 거면
  → 서로 다른 차원을 평가하게 하거나
  → 서로 다른 모델을 사용하거나
  → multi-judge consensus로 불일치를 명시적으로 처리

7.3 Eval을 한 번 만들고 방치

Swiss Cheese의 핵심: 구멍은 동적이다 — 열리고 닫히고 크기가 변한다
→ 모델이 업데이트되면 기존 eval의 구멍 분포가 변함
→ Agent가 개선되면 capability eval이 포화됨
→ 새로운 실패 모드가 등장하면 기존 슬라이스에 없는 구멍이 생김

대응: eval suite를 "living artifact"로 취급
  → 주기적 human calibration
  → 새로운 실패 모드에서 태스크 추가
  → 포화된 eval을 regression suite로 전환하고 새 capability eval 설계

7.4 Grader 자체를 검증하지 않음

METR의 발견:
  time horizon benchmark에서 "stated threshold를 달성하라"고 지시
  → grading은 threshold를 "초과"해야 통과로 설정
  → 지시를 정확히 따른 모델이 오히려 낮은 점수
  → 지시를 무시한 모델이 높은 점수

이것은 Swiss Cheese에서 "방어층이 오히려 위험을 생성하는" 시나리오
→ 잘못 설계된 슬라이스는 구멍이 아니라 새로운 위험원

---

8. 정리: Swiss Cheese 체크리스트

설계 시

□ 최소 3가지 다른 유형의 grader를 사용하는가? (code + model + human)
□ 각 grader가 서로 다른 차원을 평가하는가? (직교성)
□ Outcome 기반인가, Path 기반인가?
□ Partial credit을 지원하는가?
□ 양방향(should/should not) 테스트가 균형 잡혀 있는가?

운영 시

□ 각 trial이 clean environment에서 시작하는가? (latent condition 차단)
□ Transcript를 주기적으로 읽고 있는가? (구멍의 지도)
□ LLM-as-Judge를 human expert와 calibrate하고 있는가?
□ Capability eval의 포화를 모니터링하고 있는가?
□ 새로운 실패 모드를 eval suite에 추가하고 있는가?

해석 시

□ 점수를 액면가로 받아들이지 않는가?
□ 0% pass rate를 "Agent 실패"가 아닌 "eval 점검" 신호로 보는가?
□ 용도에 맞는 메트릭(pass@k vs pass^k)을 사용하는가?
□ Grader 자체의 정확성을 검증했는가?

---

9. 결론: 단일 Grader는 반드시 실패한다

James Reason의 통찰은 30년이 지나도 유효합니다: 복잡 시스템의 사고는 단일 실패가 아니라 다중 방어층의 구멍이 정렬될 때 발생합니다. LLM Agent 평가에서 이 원리는 더욱 강력하게 작용합니다 — Agent의 자율성, 비결정성, 창의적 문제 해결 능력이 각 Grader의 구멍을 예측하기 어렵게 만들기 때문입니다.
Anthropic이 제시하는 eval 설계 원칙들 — 직교적 grader 조합, outcome 기반 평가, partial credit, 양방향 테스트, transcript 읽기, eval suite의 지속적 관리 — 은 모두 Swiss Cheese Model의 핵심 원칙과 대응됩니다.
정리하면 비결정론적 에이전트의 Eval 하네스 구축은 개별 슬라이스를 완벽하게 만드는 것이 아닌, 서로 다른 구멍을 가진 슬라이스를 충분히 적층하여 관통 확률을 최소화하는 작업입니다.

"No single defense is perfect. Safety comes from defense in depth — not from the perfection of any one layer, but from the diversity of many."
— James Reason의 Swiss Cheese Model이 LLM 평가에 남기는 교훈

---

References

1. Reason, J. (1990). Human Error. Cambridge University Press.
2. Reason, J. (2000). Human Error: Models and Management. BMJ, 320(7237), 768–770.
3. Anthropic. (2026, January). Demystifying Evals for AI Agents. Anthropic Engineering Blog.
4. Anthropic. (2024, December). Building Effective Agents. Anthropic Engineering Blog.
5. Wiegmann, D. A., & Shappell, S. A. (2003). A Human Error Approach to Aviation Accident Analysis: The Human Factors Analysis and Classification System. Ashgate.
6. Hollnagel, E. (2004). Barriers and Accident Prevention. Ashgate.
7. Jimenez, C. E. et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? arXiv:2310.06770.
8. Yao, S. et al. (2024). τ-bench: A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045.
9. Yao, S. et al. (2025). τ2-bench: Evaluating Conversational Agents in Multi-Turn Interactions. arXiv:2506.07982.
10. Anthropic. (2025). Automated Auditing of AI Alignment. Alignment Research.