> ## Documentation Index
> Fetch the complete documentation index at: https://developers.argosidentity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 출력 스키마

> 커스텀 출력 스키마로 검증 결과의 JSON 구조를 정의합니다.

## 출력 스키마란?

출력 스키마는 Omni가 반환하는 검증 결과의 **정확한 JSON 구조**를 정의합니다. 원시 엔진 출력 대신 시스템이 필요로 하는 형식으로 정확히 포맷된 결과를 받을 수 있습니다.

## 출력 스키마 정의하기

출력 스키마는 워크플로우 설정에서 JSON 구조로 정의합니다. 각 필드는 워크플로우 엔진이 추출하고 검증한 데이터에 매핑됩니다.

### 스키마 작성 가이드

워크플로우 생성 **Step 4: 출력 스키마**에서 Field Builder 또는 JSON 입력을 사용할 때 아래 규칙이 적용됩니다.

* **표준**: [JSON Schema Draft-07](https://json-schema.org/draft-07/json-schema-release-notes.html)을 따릅니다. 다만 Omni에서는 아래 **추가 제약**이 있습니다.
* **루트 구조**: 최상위는 `"type": "object"`로 시작하고, 필드는 `"properties"` 객체 안에 정의해야 합니다.
* **필드 타입**: `string`(문자열), `number`(소수), `integer`(정수), `boolean`(참/거짓), `object`(중첩 객체), `array`(목록)를 사용할 수 있습니다.
* **중첩 깊이**: 필드 중첩은 **최대 2단계**까지 허용됩니다(예: 최상위 `object` → 그 안의 `object`까지).
* **이름 중복**: 동일한 필드 이름을 중복해 정의할 수 없습니다.
* **`description`**: 각 필드에 `description`을 추가하면 AI가 스키마를 해석하고 결과를 생성할 때 **더 정확한 매핑**에 도움이 됩니다.
* **동기화**: **Field Builder**(테이블 뷰)와 **JSON 입력**(코드 뷰)은 서로 **자동으로 동기화**됩니다. 한쪽에서 수정하면 다른 쪽에도 반영됩니다.

### Step 4. 출력 스키마

워크플로우 생성 마지막 단계에서 출력 스키마를 정의합니다. **JSON Schema 코드 입력** 또는 **테이블 뷰**로 전환하여 편집할 수 있습니다.

<Tabs>
  <Tab title="JSON Schema 코드 뷰">
    JSON Schema를 직접 코드로 입력하여 출력 구조를 정의합니다.

    <Frame caption="JSON Schema 코드 뷰 — JSON Schema를 직접 작성하여 출력 구조를 정의합니다.">
      <img src="https://mintcdn.com/argosidentity/7l1n9Ki4cvQVRdUJ/images/omni/ko/workflow-step4-schema-code.png?fit=max&auto=format&n=7l1n9Ki4cvQVRdUJ&q=85&s=77094f39d3ad33716117627f1db0321c" alt="출력 스키마 - JSON Schema 코드 뷰" width="1918" height="958" data-path="images/omni/ko/workflow-step4-schema-code.png" />
    </Frame>

    <Frame caption="스키마 작성 팁 — JSON Schema 작성 시 참고할 수 있는 가이드라인이 제공됩니다.">
      <img src="https://mintcdn.com/argosidentity/7l1n9Ki4cvQVRdUJ/images/omni/ko/workflow-step4-schema-tips.png?fit=max&auto=format&n=7l1n9Ki4cvQVRdUJ&q=85&s=9dffccc2da0a91f13bcc2665ce9feb59" alt="출력 스키마 - 스키마 작성 팁" width="1918" height="958" data-path="images/omni/ko/workflow-step4-schema-tips.png" />
    </Frame>
  </Tab>

  <Tab title="테이블 뷰">
    필드 이름, 타입, 설명을 테이블 형태로 확인하고 편집할 수 있습니다.

    <Frame caption="테이블 뷰 — 스키마 필드를 테이블 형태로 확인하고 편집합니다.">
      <img src="https://mintcdn.com/argosidentity/7l1n9Ki4cvQVRdUJ/images/omni/ko/workflow-step4-schema-table.png?fit=max&auto=format&n=7l1n9Ki4cvQVRdUJ&q=85&s=47ac8d42fcae9d14beebdd3c5e7b1328" alt="출력 스키마 - 테이블 뷰" width="1918" height="958" data-path="images/omni/ko/workflow-step4-schema-table.png" />
    </Frame>
  </Tab>

  <Tab title="JSON Schema 미리보기">
    모달 팝업에서 JSON Schema 전체를 미리 확인할 수 있습니다.

    <Frame caption="JSON Schema 미리보기 — 정의된 스키마 전체를 모달에서 확인합니다.">
      <img src="https://mintcdn.com/argosidentity/7l1n9Ki4cvQVRdUJ/images/omni/ko/workflow-step4-schema-modal.png?fit=max&auto=format&n=7l1n9Ki4cvQVRdUJ&q=85&s=d4584a982cf27aadaf3749362350dcec" alt="출력 스키마 - JSON Schema 미리보기" width="1918" height="958" data-path="images/omni/ko/workflow-step4-schema-modal.png" />
    </Frame>
  </Tab>
</Tabs>

**KYB 출력 스키마 예시:**

```json theme={null}
{
  "company": {
    "name": "string",
    "registrationNumber": "string",
    "country": "string",
    "incorporationDate": "string",
    "directors": ["string"]
  },
  "verification": {
    "amlScreeningResult": "string",
    "registrationValid": "boolean",
    "beneficialOwnership": "string"
  },
  "decision": {
    "result": "APPROVE | REJECT | FLAG",
    "verificationStatus": "pending_review | approved | rejected",
    "flagReasons": ["string"]
  }
}
```

## 검증 상태 (`verificationStatus`)

분석 결과에는 **`verificationStatus`** 하나로 최종 상태가 올라오며, 값은 세 가지 중 하나입니다: `pending_review`, `approved`, `rejected`. 출력 스키마의 **결정(decision)** 블록에도 동일한 enum을 맞추면 다운스트림에서 분기하기 쉽습니다.

| 값                | 일반적인 처리     |
| ---------------- | ----------- |
| `approved`       | 자동 승인·통과 처리 |
| `pending_review` | 사람 검토 대기열   |
| `rejected`       | 거부·정책 미충족   |

## 스키마 모범 사례

<AccordionGroup>
  <Accordion title="다운스트림 시스템에 맞추세요">
    백엔드 또는 컴플라이언스 시스템이 기대하는 형식에 맞게 스키마를 설계하세요. 후처리 변환의 필요성을 제거합니다.
  </Accordion>

  <Accordion title="결정 블록을 포함하세요">
    항상 `result`, `verificationStatus`(`pending_review` / `approved` / `rejected`), 사유가 포함된 최상위 결정 필드를 포함하세요. 워크플로우에서 자동화된 라우팅이 가능해집니다.
  </Accordion>

  <Accordion title="가능하면 평면 구조를 사용하세요">
    단순한 스키마가 유지보수와 통합이 더 쉽습니다. 데이터가 자연스럽게 요구하는 경우에만 중첩하세요.
  </Accordion>
</AccordionGroup>

## Ontology Mapper

Ontology Mapper는 엔진 출력이 정의된 스키마에 부합하는지 검증합니다. 엔진이 다른 형식으로 데이터를 반환하면 매퍼가 결과를 전달하기 전에 스키마에 맞게 정규화합니다.