CHO-FAM ANS
용어 구분 — 계약의 말과 화면의 말
패밀리 공통. 같은 것을 두 층에서 다르게 부른다. 어느 말을 어디에 쓰는지 정한다.
게시 위치 — 조회 https://cho-fam.com/ans/vocabulary · 다운로드 https://cho-fam.com/ans/vocabulary.md. 이 파일이 원본이고 사이트의 것은 산출물이다. 함께 읽을 것: ANS 규격 · Agent Card 규격 기준일: 2026-08-12
0. 세 줄
- 계약의 말은 바뀌지 않는다. 바꾸면 상대 저장소가 깨진다.
- 화면의 말은 바뀐다. 브랜딩·현지화가 그것을 고친다.
- 둘을 섞으면 어느 쪽도 바꿀 수 없게 된다.
1. 왜 지금 나누는가
CAL 제안서가 에이전트를 Free Agent / Pro Agent로 부르고, ANS 규격은 registered / certified로 부른다. 어휘가 부딪히는 것처럼 보였으나 층이 다르다 — 하나는 프로토콜 응답의 값이고 하나는 사람에게 보이는 이름이다.
층을 나누지 않으면 둘 중 하나가 죽는다. 화면 이름으로 통일하면 resolve 응답이 브랜딩을 따라 바뀌고, 프로토콜 값으로 통일하면 사용자가 certified라는 영단어를 읽는다.
2. 규칙 셋
| # | 규칙 | 어기면 |
|---|---|---|
V-1 | 계약에는 계약의 말만 싣는다. 화면 이름을 계약 필드·이벤트·API 응답에 넣지 않는다 | 브랜딩을 바꾸면 계약이 깨진다 |
V-2 | 화면에는 계약의 값을 그대로 내보내지 않는다. 반드시 매핑을 거친다 | 사용자가 chofam:kind/advisory를 읽는다 |
V-3 | 매핑은 한 곳에만 있다 — 이 문서다. 각 표면이 자기 매핑을 갖지 않는다 | 화면마다 다른 이름이 나온다 |
V-2는 "번역하라"가 아니다. 계약의 값은 화면에 그대로 나가면 안 되는 것이지 숨겨야 하는 것이 아니다. 개발자 도구·API 응답·로그에는 계약의 말이 그대로 있어야 한다 — 그래야 화면에서 본 것과 실제 값을 맞춰 볼 수 있다.
3. 대조표 — 같은 것의 두 이름
| 계약의 말 | 어디에 | 화면의 말 | 비고 |
|---|---|---|---|
registered | ANS resolve.tier | 등록 | |
certified | 〃 | 공인 | 만료는 읽는 시점에 판정한다(ANS 규격 §5.3) — 화면도 판정 시점을 함께 보인다 |
employment | society | Roster(배치) | |
contract_ref + party_confirmation | society | Signing(선임) | |
GET /names · GET /agents | ANS · society | Scout Net(탐색) | |
hire/v1 unitPrice | 카드 확장 | 호가 | 계약가와 다를 수 있다(카드 규격 §4.1) |
credit | society 원장 | 크레딧 | 같은 말이다 |
party | society | 파티 | 같은 말이다 |
3.1 ethos 결정 세션 단계 — 화면 어휘는 canon 중립이다 (2026-08-12 개정)
주관자: *"canon을 분리하고 ethos의 용어에 영향을 주지 않도록 함."*
같은 날 채택했던 성리학 화면 어휘(格物·誠意·修身)를 철회한다. canon이 병렬 렌즈로 서는 구조(Canon 검토 §8)에서 엔진의 화면이 한 전통의 언어를 입으면 그 전통이 선택지이자 인터페이스가 된다 — 검토 §9.4가 긴장으로 기록해 둔 것을 주관자가 닫았다.
V-5 — canon의 어휘는 엔진에 들어오지 않는다. 계약의 말(StageId)은 물론 화면의 말도 특정 전통의 언어를 입지 않는다. 전통의 어휘는 그 전통의 canon 에이전트 응답 안에서만, 출처가 붙은 채로 나타난다.
철회 뒤에도 살아남는 것:
| # | |
|---|---|
| 계약의 말 불변 | stages.ts의 StageId는 애초에 바뀐 적이 없다(V-1) |
| 화면 이름은 일대일이 아니어도 된다 | V-2가 요구하는 것은 대응이 아니라 계약의 값이 그대로 나가지 않는 것 |
safety_check은 화면 이름을 갖지 않는다 | 절차의 한 칸이 아니라 모든 절차에 앞서는 관문이다 |
| 홈의 입력창 하나 | UI 형태로서 유지 — 이름 없이. 敬이라는 명칭은 철회에 포함된다 |
감정 점검 유형(ethos E-11) | 실질 불변 — 그 유형이 메우는 공백은 전통과 무관하게 실재한다. 유형명·화면명 모두 중립으로 |
화면의 말은 ethos가 canon 중립 안을 내면 여기 올린다 — 파티 9상태와 같은 규칙이다(V-3: 매핑은 한 곳에, 낱말은 사실의 소유자가).
4. 계약에만 있는 말 — 화면에 나가면 안 된다
| 말 | 왜 화면에 없나 |
|---|---|
trustTier(domain·community) | society가 자기 채널 구성을 정하는 내부 판단이지 사용자에게 답할 사실이 아니다(카드 규격 §4) |
chofam:kind/* · chofam:effect/* · chofam:scope/party | 호출자가 읽는 기계 태그다 |
pid · outbox · dataschema · whitelist/1.x | 전송 계약의 부품 |
party_id · lot_id · bearingPartyId | 식별자. **부담 파티라는 *사실*은 화면에 나가되 UUID는 나가지 않는다** |
5. 화면에만 있는 말 — 계약 대응이 없다
Offer(제안) · Compare(비교) · Watchlist(관심) · Reserve(백업). CAL 제안서 §6의 흐름이고 지금 구현이 없다.
Offer는 AP-2(협상이 일어나는 자리)의 후보다 — registerContract가 이미 합의된 값을 받는 자리이고 그 앞이 비어 있다. 나머지 셋은 화면 기능이므로 계약을 늘리지 않는다.
6. Free / Pro는 두 축을 하나로 묶었다
CAL은 Free Agent를 *"무료 + 기본"*, Pro Agent를 *"유료 + 검증됨"*으로 정의한다. 묶여 있는 두 축이 실제로는 독립이다.
| 축 | 값 | 어디에서 오나 | |
|---|---|---|---|
| 공인 | 이름이 심사를 통과했는가 | 등록 · 공인 | ANS tier |
| 과금 | 크레딧 고용 경로가 있는가 | 없음 · 있음(호가) | 카드 hire/v1 |
둘은 따로 움직인다.
- 공인인데 호가가 없다 — 지금 패밀리 전부가 여기다. 등재되고 고용도 된다 — 호가는 협상의 출발점이지 계약가의 출처가 아니다(카드 규격 §4.2). 게시돼 있지 않을 뿐이다.
- 미공인인데 호가가 있다 — 막을 근거가 없다. 값을 매기는 것과 심사를 통과하는 것은 다른 일이다.
하나의 라벨이 두 축을 덮으면 화면이 거짓을 말한다. 공인된 무료 에이전트를 Free로 부르면 심사를 통과하지 않은 것처럼 보인다.
공인 축의 화면 이름은 이미 있다 — 등록 · 공인(ANS 규격 §5.2). Free/Pro는 과금 축에 쓸 수 있으나 공인의 뜻을 실어서는 안 된다. 최종 라벨은 브랜딩 결정이고 이 문서는 축이 둘이라는 것만 정한다.
7. K-1 정밀화 — 계약이 나르는 것과 화면이 보이는 것
업무지시서 §7.2 K-1이 *"화면에 나가는 것은 ANS tier다"*로 확정했다. V-2에 맞춰 한 단계 더 나눈다.
| 계약이 나른다 | registered / certified — 계약의 말 그대로다 |
| 화면이 보인다 | 등록 / 공인 + 판정 시점 |
slime planComponent의 등급 필드에 실리는 값은 registered/certified다. 한글 라벨을 계약에 넣으면 브랜딩 변경이 계약 변경이 된다(V-1). 바꾸는 것은 렌더러이지 계약이 아니다.
K-1이 확정한 나머지는 그대로다 — trustTier는 화면에 나가지 않고(§4), 등급은 언제 판정된 값인지가 함께 드러나야 한다.
8. 층의 소재 — 어느 저장소가 어느 말을 하는가
주관자: *"chofam ANS는 기술 언어로, society는 사용자 언어로 표현."*
| 말 | 대상 | 왜 | |
|---|---|---|---|
| chofam ANS | 기술 언어 | 개발자 · 기계 · 외부 등재자 | 규격과 resolve 응답이다. 사용자 표면이 아니다 |
| society | 사용자 언어 | 사람 | 사용자를 관리하는 유일한 곳(P-5)이고 사용자가 메뉴로 접근하는 자리다 |
8.1 V-4 — 변환은 사실을 소유한 쪽이 낸다. 표면은 변환하지 않는다
변환이 표면마다 있으면 표면마다 다른 이름이 나온다(V-3 위반). 렌더러·메뉴·손목 표면이 각자 certified → 공인 표를 들면, 그 표 중 하나가 낡는 날 같은 에이전트가 화면마다 다르게 불린다.
society가 사용자 언어의 정본 표현을 낸다. 표면은 받은 말을 그린다.
정밀화 (2026-08-12) — V-4가 *"society가 낸다"*로만 적혀 ethos 자기 표면(apps/web)을 다루지 못했다. ethos 세션 단계는 ethos가 소유한 사실이므로 그 변환은 ethos가 한다(§3.1).
**가르는 기준은 *"그 사실을 누가 소유하는가"*다. society가 대부분을 변환하는 것은 society가 소유한 사실이 많아서이지 society가 변환 창구여서가 아니다. 어느 쪽이든 매핑의 정본은 이 문서 하나다(V-3) — 저장소는 그것을 구현**할 뿐 낱말을 짓지 않는다.
8.2 society는 두 얼굴이다 — 이벤트는 기술 언어 그대로다
이것을 명시하지 않으면 V-4가 계약을 깬다.
| society가 내는 것 | 말 |
|---|---|
| 사용자 대면 응답 | 사용자 언어 |
society.event/1.0(terra 수신) | 기술 언어 그대로. 계약이다 |
내부·운영 API (endpoint 해석 등) | 기술 언어 그대로 |
society.party.transition의 Recruiting을 한글로 바꾸면 terra가 거부한다. 사용자 언어는 사람이 읽는 자리에만 적용된다.
가르는 기준은 "누가 읽는가"이지 "어느 저장소가 내는가"가 아니다.
8.3 계약은 여전히 기술 언어를 나른다
V-1이 그대로다. 저장소 사이의 계약에는 화면 이름이 실리지 않는다 — slime planComponent의 등급 필드는 registered/certified다(§7).
표시 문자열이 필요하면 계약의 값과 나란히 실리고, 그 값을 만드는 곳은 society다. 계획에 그것을 싣는 것은 Hub의 일이고 Hub가 어디 서는지는 ADR-1이다 — 이 문서가 정하지 않는다.