동맹 카탈로그에 원형(primitive)을 추가하는 길은 두 가지다. 포크 한다 — 자신의 네임스페이스에 사적 확장을 유지하고, 파트너가 그것을 읽을 수 있기를 바란다. 또는 카탈로그 소유자가 적재하기로 합의한 파트너 네임스페이스 에 출판한다.
우리는 두 번째 경로를 택했다. 2026년 4월이 그 선택을 선례로 만들었다.
포크 경로의 비용
포크는 출하가 더 쉽다. 협상할 필요 없이 쓰기만 하면 된다. 그 비용은 동맹 경계에서 드러난다 — 너의 데이터가 필요한 모든 연합 파트너는 (a) 너의 사적 확장을 설치하거나, (b) 런타임에 번역하거나, (c) 그 데이터가 없는 척해야 한다.
(a) 는 50개 전구(theater) 연합에서는 물류적으로 비싸다. (b) 는 사건 발생 중에 표면화되는 스키마 번역 버그를 만든다 — 정확히 감사가 불가능한 순간이다. (c) 는 운영자 대부분이 실제로 취하는 경로이며, 이는 데이터가 없는 것과 같다.
파트너 네임스페이스 패턴
_uamkt_extensions 는 Anduril 의 카탈로그가 아니다. Anduril 의
카탈로그 안에 사전 합의되고 공개적으로 문서화된 명명된 확장 슬롯
(named extension slot) 이다. AVIX-AI 가 파트너 Lattice 인스턴스에
_uamkt_extensions:bird 를 출판하면 파트너의 카탈로그는 그 슬롯이
무엇인지 안다.
이 패턴이 작동하는 이유:
- 슬롯에는 스키마 정의를 책임지는 단일 소유자(우리)가 있다
- 카탈로그 소유자가 그 슬롯을 적재하기로 합의했다
- 카탈로그를 상속하는 동맹 운영자는 그 슬롯도 함께 상속한다
- 감사는 사적 벤더 자료가 아니라 공개된 문서에 대해 수행된다
2026년 4월 카탈로그 릴리스는 platform_type: Animal 과
aliases.name: Bird (Species) 를 네이티브로 출하했다 — 우리가
2026년 3월에 제출한 원형들이다. 그 릴리스가 다음 벤더가 카탈로그를
책임감 있게 확장하고자 할 때 따를 파트너 네임스페이스 패턴의
선례가 되었다.
19/19 HTTP 200 이 실제로 검증하는 것
모든 동맹 운영자는 카탈로그 확장에 대해 합리적으로 의심한다. 우리가
인천테크노파크 실증(커밋 fbcb327, 2026-04-20) 동안 수행한 19/19
HTTP 200 entity-API 검증은 그 의심에 대해 가능한 가장 좁은 답이다.
그것은 우리의 스키마가 좋다 는 것을 검증하지 않는다. 그것은 우리의 스키마가 카탈로그의 파서에 대해 매번, 테스트 코퍼스 전체에 걸쳐 역직렬화된다 는 것을 검증한다. 이것은 진입 조건이다 — 그 외 모든 것은 후속 검토다.
네임스페이스는 계약이지 브랜드가 아니다
_uamkt_extensions 는 "UAMKT 의 것" 을 의미하지 않는다. 그것은 "UAMKT
가 유지하기로 약정한, 공개 문서화되고 doctrine reference 에 대해
감사 가능하며 source frames + model versions 에서 재현 가능한 원형"
을 의미한다.
자산은 계약이다. 브랜드는 계약의 하위 산출물이다.
—
문의: ceo@uamkt.com
1차 reference: Anduril Industries (2026). Lattice Catalog Reference v3.