Documentation

기술 문서 Hub

PEQ의 설계 문서를 한 페이지에서 읽을 수 있습니다. 각 카드는 아래 섹션으로 연결됩니다.

DOC 01Architecture전체 구조와 구성 요소의 책임 DOC 02Fact Model정규화된 Fact 스키마 DOC 03Rule DSLWHEN / UNLESS / THEN 문법 DOC 04Evidence Model근거 체인의 데이터 구조 DOC 05Rule Lifecycle8단계 상태 전이 DOC 06Rule Evolution지식이 Rule이 되는 과정 DOC 07KIPRIS Integration공개 사건 수집 정규화 DOC 08Security접근 통제와 데이터 경계 DOC 09Governance사람이 통제하는 원칙

DOC 01 Architecture

PEQ는 10개의 구성 요소가 단방향으로 이어지는 파이프라인입니다. Input Sources → Document Intelligence → LLM Fact Extraction → Normalized Fact Store → Symbolic Rule Engine → Evidence Trace → Diagnosis Officer → Feedback → Rule Evolution → Rule Knowledge Base.

핵심 경계는 단순합니다: LLM은 Fact까지만 관여하고, 판정은 Symbolic Engine이, 승인은 진단관이 합니다. Rule Engine은 Normalized Fact Store만 바라보므로, LLM 모델이 변경되어도 판정 경로는 영향받지 않습니다.

자세한 노드별 설명은 Architecture 페이지에서 인터랙티브 다이어그램으로 확인할 수 있습니다.

DOC 02 Fact Model

Fact는 LLM이 자연어 문서에서 추출하는 구조화된 사실이며, Rule의 유일한 입력입니다. Fact 스키마는 도메인 전문가가 정의하고 정규화 저장소에서 강제됩니다.

FACT SCHEMA (요약)

case  { caseId }
claim {
  rejected: boolean
  hasAdditionalLimitation: boolean
  additionalLimitation: string | none
  structureValid: boolean
  genericTerm: boolean
  consistencyWithOfficeAction: boolean
}
mapping {
  additionalLimitation: string | none
  elements: { [element]: docId }
}
evidence {
  officeActionAvailable: boolean | none
  priorArtAvailable: boolean | none
}

값이 none(부재)과 null(불명)은 엄격히 구분됩니다. null은 UNKNOWN을 유발합니다.

DOC 03 Rule DSL

Rule은 코드가 아닌 DSL로 작성되어 진단관이 직접 읽고 검토할 수 있습니다.

RULE DSL GRAMMAR

RULE <id>
  WHEN    <predicate> (AND <predicate>)*
  UNLESS  <predicate> (AND <predicate>)*   # 선택
  THEN    <finding>

predicate: path (==|!=) (true|false|none|exists|number|"str")

평가 결과는 네 가지 상태 중 하나입니다:

TRUE — 모든 WHEN 충족, 적용 가능한 UNLESS 없음
FALSE — WHEN 조건 중 충족되지 않은 조건이 있음
UNKNOWN — 판정에 필요한 Fact가 확보되지 않음 (근거 문서 부족)
NOT_APPLICABLE — UNLESS 예외 충족으로 이 Rule은 적용되지 않음

본 사이트의 Demo와 Playground는 이 문법을 해석하는 실제 evaluator(rule-engine-demo.js)로 동작합니다.

DOC 04 Evidence Model

Evidence는 판정 결과를 원본 문서 문장에 연결하는 레코드입니다.

EVIDENCE RECORD

{
  id: "EV-014-01",
  finding: "MAPPING_OMISSION",
  ruleId: "PEQ-IS-014", ruleVersion: 4,
  claim: "9",
  fact: "contains(mold)",
  docId: "OA-001", docTitle: "의견제출통지서",
  passage: "...",        # 원문 문장 전체
  highlight: "..."       # 근거로 사용된 구절
}

Evidence 체인은 Finding → Rule → Fact → Evidence → Source Document 순으로 역추적되며, Evidence Trace Lab에서 체험할 수 있습니다.

DOC 05 Rule Lifecycle

모든 Rule은 8단계 상태 전이를 따릅니다.

LIFECYCLE TRANSITIONS

DISCOVERED → DRAFT → REVIEW → TESTING
    → SHADOW → ACTIVE → DEPRECATED → RETIRED

SHADOW는 필수 관문입니다. 신규 Rule은 실제 진단 결과를 바꾸지 않는 병행 평가를 거쳐 일치율이 검증된 뒤에만 ACTIVE로 전환됩니다. 전체 조건은 Evolution Lab의 Lifecycle 섹션에서 확인할 수 있습니다.

DOC 06 Rule Evolution

Rule은 7가지 소스에서 진화합니다: 심사기준, 판례, 진단사례, 진단관 협의, 정책 변화, False Positive, False Negative.

각 소스는 영향 받는 Rule 식별 → LLM 개선 후보 제안 → 진단관 검토 → 회귀 테스트 → Shadow Mode → 활성화의 동일한 파이프라인을 거칩니다. 회귀 테스트에서 Lost Findings가 발생하면 의도된 변화인지 진단관이 확인할 때까지 활성화되지 않습니다.

Rule Evolution Lab에서 각 소스를 클릭해 전체 과정을 시뮬레이션할 수 있습니다.

DOC 07 KIPRIS Integration

공개 사건은 출원번호 하나로 KIPRIS PLUS에서 서지, 청구항, 심사정보, 인용발명을 수집합니다. 수집 결과는 문서 유형별로 분리되고 하나의 Patent Case Package로 정규화됩니다.

진단 전 Missing Document Check가 수행되며, 필요한 문서가 없으면 해당 영역의 Rule은 UNKNOWN으로 처리됩니다. 이 쇼케이스 사이트는 정적 시뮬레이션이며 KIPRIS API를 호출하지 않습니다. Workflow 페이지에서 공개/비공개 케이스 처리 차이를 확인할 수 있습니다.

DOC 08 Security

비공개 케이스의 문서는 사용자 권한 범위 내에서만 접근됩니다. Fact 추출과 Rule 평가는 접근 권한이 통제되는 환경에서 수행되며, 진단 결과와 Evidence는 권한 있는 진단관에게만 노출됩니다.

본 사이트는 브라우저 저장소에 테마 설정 등 무해한 값만 저장하며, 어떤 실제 특허정보도 다루지 않습니다.

DOC 09 Governance

PEQ의 거버넌스는 한 문장으로 요약됩니다:

LLM can propose. Symbolic Engine can evaluate. Diagnosis Officer can approve.

진단 확정 권한 — 진단관
Rule 활성화 권한 — 진단관 (Shadow Mode 검증 후)
UNKNOWN 원칙 — 불확실하면 추측하지 않는다
지식 자산 — Rule Knowledge Base에 영속 축적