무엇이 고정되고, 무엇이 회사마다 달라지는지 먼저 나눕니다.
플랫폼 class 구조와 검증 규칙
한 번의 실행에서 사용한 의미의 재현 기준
구조·관계·자산 검토를 한 숫자로 뭉개지 않습니다.
현재 인증 Admin은 Ontology 구조, 의미 관계 그래프, 자산 연결 검토와 AI 구성 자산 연결을 서로 다른 작업영역으로 제공합니다.

원본 포인터에서 권위 readback까지
- 01
SOURCE POINTER
원본 시스템과 business ID가 데이터 권위를 유지합니다. Platform은 복제본을 원본처럼 말하지 않습니다.
- 02
COMPANY OVERLAY
회사 용어, 자산, 프로세스와 시스템 식별자를 platform class에 mapping합니다. class 구조 자체를 회사마다 바꾸지 않습니다.
- 03
OWNER REVIEW
근거, 충돌, 적용 범위를 검토해 approve·correct·exclude를 결정합니다. 후보 mapping은 아직 운영 의미가 아닙니다.
- 04
RELEASE & CURRENT
승인 집합을 불변 release로 게시하고 manifest와 current pin을 검증합니다. 게시와 current 전환은 별도 상태입니다.
- 05
CONTEXT SNAPSHOT
실행이 참조한 concept, source pointer, 자산과 정책 버전을 immutable snapshot으로 고정합니다.
- 06
AUTHORITATIVE READBACK
Registry와 원천 권위에서 실제 사용 상태를 다시 읽어 UI·Runtime·증거가 같은 release를 가리키는지 확인합니다.
Context는 프롬프트 문자열이 아니라 실행 당시의 운영 기록입니다.
요청자·조직·위임, semantic concept, 선택 자산, 정책·권한 결정, current release를 함께 묶고 snapshot ID로 Trace와 Receipt에 연결합니다.
START WITH ONE REAL WORKFLOW
AI를 더 붙이기 전에,
첫 실행 계약을 설계하세요.
한 업무의 의미, 원본 권위, 사용할 자산, 사람 결정 지점과 필요한 증거부터 함께 확인합니다. 확인되지 않은 기능을 전제로 도입안을 만들지 않습니다.