의사결정 출처

의사결정 출처란?

LexQ가 기록하는 모든 실행은 기록되는 그 순간 의사결정 출처(Decision Provenance)와 함께 봉인됩니다. 결정 결과, 룰별 결정적 사유, 실행이 본 입력 팩트, 실제로 실행된 룰 스냅샷의 지문, 그리고 버전을 누가 작성하고, 발행하고, 배포했는지의 3층 책임 사슬까지. 사후에 재구성되는 것은 아무것도 없습니다. 지금 읽는 것은 결정이 일어난 순간 봉인된 그대로입니다.

실행 이력 vs 의사결정 출처: 실행 이력은 실행 전반에 걸쳐 무슨 일이 있었는지를 알려줍니다(목록, 통계, 지연시간). 의사결정 출처는 하나의 결정에 대해 답합니다. 왜 이렇게 나왔고, 어떤 입력이었고, 누구의 룰이었나?

언제 사용하나

감사 대응: 감사인이 고객 X가 특정 날짜에 왜 결정 Y를 받았는지 묻습니다. trace를 꺼내 봉인된 출처를 그대로 제출합니다.
고객 분쟁: 어떤 룰이 어떤 (마스킹된) 입력에서 발화했는지 확인하고, 의사결정 재실행(Decision Replay)으로 수정을 검증합니다.
주기적 열람 기록 점검: 열람 감사 원장이 누가 어떤 PII를 언제 봤는지 기록하며, API로 자동 수집할 수 있습니다.

결정의 출처 조회

콘솔

실행 이력의 실행 상세에서 의사결정 출처를 엽니다. 출처 화면이 결정, 룰별 사유, 마스킹된 입력, 책임 사슬을 보여줍니다.

CLI

lexq provenance get --trace-id <traceId>

API

curl "https://api.lexq.io/api/v1/partners/provenance/<traceId>" \
  -H "x-api-key: YOUR_API_KEY"

응답

발췌입니다. PII 팩트는 마스킹되어 도착하고, maskedKeys가 그 목록을 알려줍니다.

{
  "result": "SUCCESS",
  "data": {
    "traceId": "8f3c1a2e-1d44-4c1b-9a3e-0f5b7c2d9e10",
    "requestFacts": {
      "customer_segment": "••••••",
      "purchase_subtotal_usd": 129.9
    },
    "maskedKeys": ["customer_segment"],
    "lineage": {
      "authored":  { "name": "Jane Kim", "at": "2026-06-28T09:14:02Z" },
      "published": { "name": "Jane Kim", "at": "2026-06-30T11:40:55Z" },
      "deployed":  { "name": "Jane Kim", "at": "2026-07-01T08:02:19Z" }
    }
  }
}

이와 함께 응답에는 결정 결과, 평가된 모든 룰의 결정적 사유, 룰 스냅샷 지문이 담깁니다. 라이브 시스템을 건드리지 않고 결정 당시의 맥락을 재현하기에 충분한 정보입니다.

PII 마스킹과 열람(Reveal)

Fact Definitions에서 PII로 지정한 팩트는 모든 읽기 표면에서 ••••••로 마스킹됩니다. 의사결정 출처, 실행 이력 상세, 모든 export가 여기에 포함됩니다. maskedKeys가 무엇이 마스킹됐는지 항상 알려주므로, 값을 노출하지 않고도 결정의 구조는 온전히 분석할 수 있습니다. 마스킹된 값의 열람은 별도의, 의도된 행위입니다.

콘솔 전용이며 Admin·User 역할만 가능합니다. API 키는 403으로 거부됩니다. 에이전트나 통합이 PII 평문을 가져갈 방법은 없습니다.
Write-then-reveal: 감사 행이 커밋된 뒤에야 값이 보입니다. 감사되지 않은 열람은 일어날 수 없습니다.
PII로 지정되지 않은 팩트의 열람 시도는 AN-027로 실패합니다.

열람 표면은 CLI와 MCP 툴에서 의도적으로 제외했습니다. PII 평문을 에이전트의 컨텍스트로 흘리면 콘솔의 감사 경계 밖으로 값이 복제되기 때문입니다.

열람 감사 원장

모든 열람은 append-only 원장에 남습니다. 누가, 어느 trace의, 어떤 팩트를, 언제 열람했는지. 값은 절대 저장하지 않습니다. 원장은 메타데이터 전용입니다.

콘솔

사이드바의 PII 열람 감사를 열고 trace, 열람자, 팩트 키, 기간으로 필터합니다.

CLI

lexq provenance reveal-audits --start-date 2026-07-01 --format table

API

curl "https://api.lexq.io/api/v1/partners/provenance/reveal-audits?startDate=2026-07-01&factKey=customer" \
  -H "x-api-key: YOUR_API_KEY"

필터	매칭
`traceId`, `revealedBy`	정확 일치
`factKey`	부분 일치, 대소문자 무시
`startDate`, `endDate`	tenant 타임존 기준 날짜 범위

응답

{
  "result": "SUCCESS",
  "data": {
    "content": [
      {
        "traceId": "8f3c1a2e-1d44-4c1b-9a3e-0f5b7c2d9e10",
        "factKey": "customer_segment",
        "revealedBy": "6a2f31c0-9b7d-4e2a-8c11-3d5e9f0a1b2c",
        "revealedByName": "Jane Kim",
        "revealedAt": "2026-07-06T14:23:11Z"
      }
    ],
    "totalElements": 7
  }
}

Viewer와 API 클라이언트 역할은 열람은 못 해도 원장은 조회할 수 있습니다. 열람 기록을 확인하는 권한을 열람 권한보다 넓게 둔 의도적 설계입니다. 이 구조 덕분에 자동화가 가능합니다. API 키로 보안 로그 수집 시스템(SIEM)을 이 엔드포인트에 연결하면, 규정이 요구하는 주기적 열람 기록 점검을 수작업 없이 처리할 수 있습니다.

출처가 항상 해석 가능한 이유는, 감사 보존이 자신이 참조하는 것의 삭제를 거부하기 때문입니다. 실행 기록이 있는 버전은 제거할 수 없고(AN-028), 감사 기록을 봉인할 수 없으면 그 작업 자체가 거부됩니다(AN-029). 조용히 넘어가는 대신 그 자리에서 실패합니다.

다음 단계

의사결정 재실행

과거 결정을 후보 버전으로 재평가하고 결과를 diff합니다.

Fact Definitions

팩트를 PII로 지정해 마스킹과 감사되는 열람을 활성화합니다.

시작하기

핵심 개념

기능

의사결정 출처