diff --git a/devfront/src/features/clients/ClientRelationsPage.tsx b/devfront/src/features/clients/ClientRelationsPage.tsx
index e4ba79e4..f99f923b 100644
--- a/devfront/src/features/clients/ClientRelationsPage.tsx
+++ b/devfront/src/features/clients/ClientRelationsPage.tsx
@@ -36,7 +36,6 @@ import { ClientDetailTabs } from "./ClientDetailTabs";
 
 const relationOptions = [
   "admins",
-  "creator",
   "config_editor",
   "secret_rotator",
   "jwks_viewer",
@@ -44,6 +43,7 @@ const relationOptions = [
   "consent_viewer",
   "consent_revoker",
   "relationship_viewer",
+  "audit_viewer",
   "status_operator",
 ] as const;
 
diff --git a/docs/devfront-rp-relationships-guide.md b/docs/devfront-rp-relationships-guide.md
index b6a04fa2..ae2543c6 100644
--- a/docs/devfront-rp-relationships-guide.md
+++ b/docs/devfront-rp-relationships-guide.md
@@ -16,16 +16,16 @@
 
 - 관계 탭에서 부여하는 관계는 **DevFront 운영 권한**이다.
 - `RelyingParty#access`는 실제 서비스 로그인/접근 권한이며, DevFront 운영 권한과 별도이다.
-- 아래 관계 중 하나라도 있으면 해당 RP에 대한 기본 조회 권한(`RelyingParty#view`)도 함께 생긴다.
+- 아래 수동 부여 관계 중 하나라도 있으면 해당 RP에 대한 기본 조회 권한(`RelyingParty#view`)도 함께 생긴다.
 - `RP 관리자(admins)`는 상위 관리 관계이며, 대부분의 세부 운영 권한을 포함한다.
 - 세부 관계는 필요한 기능만 최소 권한으로 부여할 때 사용한다.
+- `creator`는 생성 이력/자동 동기화용 내부 relation이며 관계 탭의 수동 부여 목록에는 노출하지 않는다.
 
 ## 관계 목록
 
 | 화면 표시명 | Relation key | 의미 | 주요 허용 기능 |
 |---|---|---|---|
 | RP 관리자 | `admins` | RP 운영 전반을 관리할 수 있는 관리자 관계 | RP 조회, 설정 관리, secret 재발급, JWKS 운영, consent 조회/회수, 관계 조회, 감사 로그 조회, 상태 변경 |
-| RP 생성자 | `creator` | 이 RP를 생성한 운영 주체를 표시하거나 RP 생성 권한 모델에 연결되는 관계 | RP 조회, RP 생성 정책과 연결 |
 | RP 일반 설정 | `config_editor` | RP 이름, Redirect URI, 메타데이터 같은 일반 설정을 수정할 수 있는 관계 | RP 조회, 일반 설정 수정 |
 | 시크릿 재발급 | `secret_rotator` | Client secret 재발급과 rotation을 수행할 수 있는 관계 | RP 조회, client secret 재발급 |
 | JWKS 조회 | `jwks_viewer` | JWKS 상태, 캐시 정보, key summary를 조회할 수 있는 관계 | RP 조회, JWKS 상태/캐시/key summary 조회 |
@@ -44,7 +44,7 @@ Keto namespace 기준으로 relation은 다음 permit으로 계산된다.
 |---|---|---|
 | `view` | `admins`, `config_editor`, `secret_rotator`, `jwks_viewer`, `jwks_operator`, `consent_viewer`, `consent_revoker`, `relationship_viewer`, `audit_viewer`, `status_operator`, 부모 tenant의 `view` 또는 `view_dev_console` | RP 기본 조회 및 목록 노출 |
 | `manage` | `admins`, 부모 tenant의 `manage` | RP 관리 상위 권한 |
-| `create` | `creator`, 부모 tenant의 `grant_dev_permissions`, `manage` | RP 생성 |
+| `create` | `creator`, 부모 tenant의 `grant_dev_permissions`, `manage` | RP 생성. `creator`는 현재 수동 부여하지 않는 내부 relation이다. |
 | `edit_config` | `config_editor`, `manage` | RP 일반 설정 수정 |
 | `rotate_secret` | `secret_rotator`, `manage` | client secret 재발급/회전 |
 | `view_jwks` | `jwks_viewer`, `operate_jwks`, `manage` | JWKS 상태/캐시/key summary 조회 |
@@ -147,6 +147,8 @@ RP 생성 시 `metadata.user_id`가 존재하면 생성자에게 기본 운영 r
 - `audit_viewer`
 - `status_operator`
 
+`creator`는 이 자동 부여 세트에는 포함되지만, 운영자가 관계 탭에서 수동으로 선택하는 관계는 아니다. 생성자 표시는 장기적으로 relation 부여 여부가 아니라 RP metadata 또는 audit read model 기반의 읽기 전용 정보로 제공하는 방향이 적절하다.
+
 ## 관련 tuple 예시
 
 ```text
@@ -166,4 +168,3 @@ RelyingParty:client-a#relationship_viewer@User:user-5
   - outbox worker가 tuple을 Keto에 반영했는지
   - 대상 RP의 client id가 tuple object와 같은지
   - audit/consent 로그에 `client_id` 또는 `target_id`가 정확히 기록되는지
-