document-haness/docs/clean-architecture-backend-template/tech-log-studio/what-a-gate-does-not-prove/concept/concept-evidence-grades-and-provenance.md

---
kind: CONCEPT
slug: evidence-grades-and-provenance
title: 증거 등급과 provenance — R1과 R2를 가르는 것
topic: what-a-gate-does-not-prove
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: concept:evidence-grades-and-provenance
evidenceCapturedOn: 2026-09-01
assets:
  - key: evidence-grades-and-provenance
    file: ../../../final/evidence/rendered/evidence-grades-and-provenance.svg
  - key: evidence-grades-and-provenance-diagram
    file: ../../../final/assets/diagrams/evidence-grades-and-provenance.svg
evidence:
  - ../../../final/evidence/raw/evidence-grades-and-provenance.txt
source:
  - 원본 분석 절은 final/document.md#6-5 · analysis/05 §15.6 이다.
---

# 증거 등급과 provenance — R1과 R2를 가르는 것

같은 테스트 결과라도 어디서 어떻게 나왔는지에 따라 등급이 갈린다. R2 는 다섯 가지 provenance 조건을 모두 만족해야 하고, 하나라도 어긋나면 R1 에 머문다.

## 관계

- **후보 증거는 통과해도 R1에 머무르고 R2는 별도 게이트가 판정한다**
  이 등급 체계를 채택한 결정이다.
- **아무도 돌리지 않는 레인의 게이트는 마지막으로 돌린 사람이 본 것을 보고한다**
  provenance 가 없으면 생기는 문제를 다룬 규칙이다.
- **strict test lane — 발견하지 못하면 실패하는 레인**
  증거를 생산하는 레인 쪽의 규약이다.

## 본문

<!-- body:start -->

증거가 "돌았다"에서 "믿을 수 있다"로 올라가는 조건의 설명이다.

## R1과 R2를 가르는 것

:::evidence key="evidence-grades-and-provenance-diagram" alt="내용 검증 통과와 보존된 readinessBlockers 가 R1 쪽에, clean revision 과 prerequisite DAG 가 R2 쪽에 같은 축으로 놓인다" caption="R1과 R2를 가르는 것" zoom="false"
:::

## 통과해도 R1에 머무는 이유

후보 검증(R1)은 JUnit XML에서 exact selector와 executed/skipped/failure 수를 읽고 canonical JSON SHA-256으로 manifest를 만든다. 그런데 candidate profile·dirty source·아직 R2가 아닌 prerequisite를 `readinessBlockers`에 **보존**한다.

## 돌았다에서 믿을 수 있다로 가는 조건

:::evidence key="evidence-grades-and-provenance" alt="분석 문서 final/document.md 에서 이 기록의 근거 절을 그대로 잘라낸 18줄. 코드베이스를 측정한 것이 아니라 원본 판정이 무엇을 적었는지를 보여 준다." caption="final/document.md 발췌 — 18줄" zoom="true"
:::

## R2가 추가로 요구하는 것

clean revision + CI provenance(`JPA_EVIDENCE_CI_JOB`, artifact location) + immutable PostgreSQL image digest + prerequisite DAG. 로컬 dirty worktree에서 `worktree-is-dirty`로 실패하는 것이 정식 동작이다.

:::note

두 프로파일 모두 실행하지 않았다 — 컨테이너 필요

:::

## 두 등급

`attainedReadiness` 는 `R1` 또는 `R2` 다. 그 외의 값은 거부된다.

R1 은 결과가 나왔다는 뜻이고, R2 는 그 결과를 나중에 다시 확인할 수 있다는 뜻이다.

## R2 가 요구하는 다섯 가지

```groovy
if (manifest.attainedReadiness == 'R2') {
        violations << "${cardId}: R2 requires the r2 profile"
        violations << "${cardId}: R2 requires a clean worktree"
        violations << "${cardId}: R2 has missing evidence ${missing}"
        violations << "${cardId}: R2 requires a real CI job identity"
        violations << "${cardId}: R2 requires an externally retained artifact location"
```

| 조건 | 그것이 없으면 |
|---|---|
| r2 프로파일 | 어떤 설정으로 돌았는지 알 수 없다 |
| 깨끗한 워크트리 | 실행된 코드가 커밋된 코드와 같은지 알 수 없다 |
| 누락 없는 증거 | 어떤 차원이 검사되지 않았는지 알 수 없다 |
| 실제 CI 잡 신원 | 누가 언제 돌렸는지 알 수 없다 |
| 외부에 보존된 산출물 위치 | 나중에 원본을 다시 볼 수 없다 |

다섯 가지 모두 결과의 내용이 아니라 결과의 출처에 대한 조건이다. 같은 테스트가 같은 결과를 냈어도 로컬의 더러운 워크트리에서 나왔다면 R2 가 아니다.

## 후보 검증기는 관대하다

```groovy
/*
 * active card. The candidate verifier deliberately permits incomplete R2 dimensions while the
 * canonical primary-foundation task requires a clean CI R2 profile and a complete prerequisite
 */
```

개발 중에는 불완전한 R2 차원을 허용한다. 정본 판정은 별도 태스크가 한다. 두 경로를 나눈 이유는 개발 반복을 막지 않으면서 승격 판정은 엄격하게 유지하기 위해서다.

## 이 체계 자체를 검사한다

```groovy
description = 'Mutation-tests JPA evidence schema, no-skip, content hash, and R2 provenance checks.'
```

돌연변이 테스트가 있다. 깨끗하지 않은 R2 매니페스트를 만들어 검증기가 그것을 잡는지 확인하고, 잡지 못하면 실패한다.

```groovy
'verifyJpaEvidenceHarnessContract: OK — skip, dirty/local R2, and content mutation fail closed.'
```

:::note

증거 체계를 만들면 그 체계가 실제로 닫혀 있는지를 확인할 방법이 또 필요해진다. 이 저장소는 그것을 돌연변이 테스트로 답한다.

:::

## 이 개념이 답하는 질문

지원 매트릭스의 한 행이 검증됐다고 할 때, 그 검증이 언제 어디서 나왔는지를 물을 수 있는가. R2 등급은 그 질문에 답할 수 있다는 선언이고, R1 은 답할 수 없다는 선언이다.

<!-- body:end -->