Runtime Contract
정책 판단과 실행 자산을 하나의 계약으로 연결 — PROMOTE/RETRY/ROLLBACK/HUMAN_REVIEW verdict 표준
한눈에 보기
Runtime Contract는 “무엇을 판단해야 하는가”(정책)와 “그 판단을 언제 실행하고 기록할 것인가”(런타임)를 연결하는 계약입니다. 완전 자동화를 허용하되, 모든 자동 결정이 사후 감사 가능한 증거를 남기도록 만드는 것이 목표입니다.
- 핵심 질문: 자동화된 release 결정을 어떻게 표준 verdict와 증거로 묶을 것인가?
- 읽는 대상: 에이전트 자동화의 판정·기록 체계를 설계하려는 운영자
- 연결 문서: Policy to Harness Lifecycle, Harness Engineering, Evidence Dashboard
한 줄 정의
규칙 source는 무엇을 판단해야 하는지를 정의하고, 런타임은 그 판단을 언제 실행하고 기록할지를 담당합니다.
책임 경계
| 영역 | owner | 책임 |
|---|---|---|
| 정책/판정 기준 | 규칙 원천 | risk tier, release mode, verdict vocabulary, threshold, rollback contract |
| 프로젝트 규칙 배포 | 규칙 원천 | 프로젝트 규칙 파일과 governance template을 adapter/export로 생성 |
| 런타임 실행 | 런타임 레이어 | commands, skills, hooks, eval runner, fixture replay, 로컬/글로벌 runtime 자산 |
| 메모리/측정 | 런타임 레이어 | memory facts, eval history, hook telemetry, repeated failure signals |
| 프로젝트별 구현 | project adapter | 규칙 산출물 생성 + 프로젝트별 test/deploy/rollback/golden set 확장 |
Release Verdict 표준
모든 release gate는 최종적으로 아래 네 가지 중 하나로 수렴해야 합니다.
기존 eval 판정어인 PASS, CONDITIONAL, FAIL은 검증 결과를 뜻합니다. release verdict는 그 검증 결과를 바탕으로 다음 실행을 무엇으로 할지 표현합니다. 따라서 둘은 교체 관계가 아니라 병행 관계입니다.
| verdict | 의미 | 기본 동작 |
|---|---|---|
PROMOTE | 필요한 증거가 있고 다음 단계로 진행 가능 | merge/deploy/publish 진행 |
RETRY | 수정 가능한 실패가 있음 | 수정 후 동일 gate 재실행 |
ROLLBACK | 현재 상태가 불안정하거나 회귀 발생 | 이전 known-good 상태로 복구 |
HUMAN_REVIEW | 증거 부족, 위험 초과, 판단 불명확 | 사람의 명시 판단 전까지 정지 |
기본 fallback은 HUMAN_REVIEW입니다. 자동화가 강해질수록 fallback은 더 중요해집니다.
Runtime Event 표준
hook, eval, CI, 수동 승인, rollback은 모두 같은 형태의 이벤트로 남깁니다.
필수 필드:
timestampprojectsourceevent_typeverdictevidence.summary
권장 저장 위치:
- Decision Log: 자동 결정 로그 디렉토리
- Metrics: release-events JSONL
Gate Evidence
자동 verdict에는 최소한 아래 증거가 있어야 합니다.
| evidence | 설명 |
|---|---|
risk_tier | 작업 위험도. 최소 T0~T3 또는 unknown |
gate_results | static/eval/cross-verify/hook 결과 |
eval_summary | golden set, replay, domain eval 요약 |
rollback_path | 실패 시 복구 방법. 없으면 HUMAN_REVIEW |
human_override_reason | 사람이 우회한 이유 |
post_eval_deadline | 긴급 우회 후 사후 평가 기한 |
증거가 없으면 자동 성공이 아니라 HUMAN_REVIEW입니다.
런타임 자산 매핑
| Runtime Contract | 런타임 자산 | 역할 |
|---|---|---|
| golden/replay evidence | replay fixture + golden set 디렉토리 | 회귀와 도메인 판정의 기준 데이터 |
| eval execution | eval runner 스크립트 | hook fixture와 project eval 실행 |
| push gate | eval gate hook | eval 실패 시 push 차단 |
| golden lock | golden set lock hook | AI가 기준 fixture를 임의 수정하지 못하게 차단 |
| metric history | eval history JSONL | 판정 품질 추세 기록 |
| self-improve input | repeated hook/eval failure | 반복 실패를 rule candidate로 승격 |
Tier 5 연결
Tier 5는 “사람이 사라지는 단계”가 아닙니다.
Tier 5는 다음 상태입니다.
- 자동화가 기본 경로다.
- 자동화는 release verdict로 자기 판단을 표현한다.
- 모든 verdict는 runtime event로 기록된다.
- 반복 실패는 rule/eval/hook candidate가 된다.
- 사람은 매번 실행을 승인하는 대신 기준, 금지선, 예외 조건을 설계한다.
우선 구현 순서
- release gate 스키마에 verdict contract를 둔다.
- project template의 release gate 설정에 네 가지 verdict 기본 규칙을 넣는다.
- eval/hook 결과를 runtime event로 변환한다.
- 실제 프로젝트 하나에 golden set과 release verdict를 파일럿 적용한다.
- 30일 이상 metric을 보고 자동화 Trust Score를 계산한다.
Source Notes
이 문서는 KeystoneHub 규칙 원천의 Runtime Contract 가이드를 공개용으로 정리한 것입니다. 내부 스키마 파일 경로와 프로젝트 식별자는 일반화했습니다. Provenance: keystone-native.