2026-08-20

1광고 브랜드 안전 V2 판정을 하루 만에 다시 설계했다 — X

• 4세대+1(2026-08-14, c65aa17)은 가중치 해석 규칙과 브라질 선거 필터, Thompson sampling, Phoenix bool 3종, BDSM enforcement note를 부분적으로 공개했다. 규모는 파일 21개, +2,271/−32이고, 상세는 daily/2026-08-16.md에 있다.
• 4세대+2(2026-08-17, b089ce6)는 광고 브랜드 안전 V2 판정 함수와 성인 컨텐츠 Grok 4.5 심판 계층을 넣었고, Phoenix retrieval 인덱싱 게이트를 없앴다. V2 판정 쪽에는 compute_verdict_v2와 strip_v1_grok_written, PROMPT_OWNED_RULES 7개가 들어 있었다. 규모는 파일 34개, +751/−162이고, 상세는 daily/2026-08-19.md에 있다.

오늘의 자료는 그다음 공개(2026-08-18, 11a71f8)다. 어제 정본(서비스마다 현재 이해를 담는 문서)에 자세히 반영한 마이그레이션 헬퍼가 이 커밋에서 완전히 삭제됐다. 삭제된 것은 strip_v1_grok_written과 PROMPT_OWNED_RULES 7개 rule id다. 이 저장소가 다루는 유일한 "매일 커밋" 오픈소스 서비스에서 이런 일이 벌어진 것은 처음이다. 어제 daily에 남긴 "다음 커밋에서 어떤 param이 어떻게 바뀌는지가 곧 A/B 결과의 지연 지표가 된다"는 관찰이 하루 만에 실제 근거를 얻었다.

이 커밋에는 어제 반영한 사실 하나를 하루 만에 뒤집는 dual-write 재설계가 들어 있다. dual-write는 마이그레이션 중에 옛 형식과 새 형식으로 같은 데이터를 함께 기록하는 방식이다. 이번 커밋은 파이프라인·인덱싱·grox(Grok 기반 콘텐츠 분류 서비스) 세 층도 함께 정리했고, 이 재설계를 포함한 다섯 방향이 정본에 영향을 준다.

광고 브랜드 안전 V2에서 dual-write 라벨을 다루는 방식이 하루 만에 다시 설계됐다. 4세대+2 원안에서는 V2 판정 로직이 V1 라벨을 볼 때, 특정 botmaker(X의 규칙 엔진) rule id 7개에 속한 dual-write 라벨만 걸러 낸 뒤 V2 라벨 세트로 판정했다. 이 7개를 담은 상수가 PROMPT_OWNED_RULES다. 오늘 커밋은 이 헬퍼(strip_v1_grok_written)와 Cow import까지 모두 지웠다. 대신 새 상수 V2_WRITTEN_LABELS(V2 라벨 4개)를 판정 조건으로 삼는다.

• 판정 함수 compute_verdict_v2는 초입에서 라벨 집합에 이 4개 중 하나라도 있는지 검사한다.
  • 하나도 없으면 곧장 compute_verdict(v1)으로 폴백한다.
  • 하나라도 있으면 순수 V2 라벨 세트로 판정한다. NSFA_HIGH_PRECISION과 NSFA_LIMITED_INVENTORY를 제거한 세트다.
• 핵심 변경은 새 상수와 판정 함수 초입의 새 게이트다 확인 — home-mixer/models/brand_safety.rs

  • 새 상수에는 V2 라벨 4개가 들어 있다.

    const V2_WRITTEN_LABELS: &[SafetyLabelType] = &[
        SafetyLabelType::GROK_SFA_V2,
        SafetyLabelType::GROK_NSFA_V2,
        SafetyLabelType::GROK_NSFA_LIMITED_V2,
        SafetyLabelType::GROK_NSFA_EXPANDED_V2,
    ];
    

  • 새 게이트는 V2 라벨이 없으면 V1 판정 함수를 그대로 부른다.

    pub(crate) fn compute_verdict_v2(
        labels: &HashMap<SafetyLabelType, SafetyLabel>,
        tweet_id: u64,
    ) -> BrandSafetyVerdict {
        if !V2_WRITTEN_LABELS.iter().any(|l| labels.contains_key(l)) {
            return compute_verdict(labels, tweet_id);
        }
        if MEDIUM_RISK_LABELS_V2.iter().any(|l| labels.contains_key(l)) {
            return BrandSafetyVerdict::MediumRisk;
        }
        // ... low risk 검사, 그 외 Safe
    }
    

  • V2 라벨 세트도 줄었다. MEDIUM_RISK_LABELS_V2에서 NSFA_HIGH_PRECISION을 제거했고, 이전 16개 중 하나였다. LOW_RISK_LABELS_V2에서는 NSFA_LIMITED_INVENTORY를 제거했고, 이전 3개 중 하나였다.

• 이 변경을 결정적으로 보여 주는 근거는 새 테스트 케이스 v2_defers_to_v1_when_v2_has_not_ruled가 assert하는 사례 하나다.
  • NSFA_HIGH_PRECISION + GROK_NSFA + GROK_SFA_V2 라벨 세트를 V1은 MediumRisk로 판정하지만, V2는 Safe로 판정한다.
  • 즉 V2가 GROK_SFA_V2 하나로 판정 신호를 보내면, V1의 전통적인 heuristic 라벨인 NSFA_HIGH_PRECISION까지 무시하고 V2 결정이 완전히 지배한다.

새 테스트 v2_defers_to_v1_when_v2_has_not_ruled는 이 판정 방식을 케이스 6개로 명시한다.

let v1_safe = labels_with(&[SafetyLabelType::GROK_SFA]);
assert_eq!(compute_verdict_v2(&v1_safe, PRE_CUTOFF_ID), compute_verdict(&v1_safe, PRE_CUTOFF_ID));
assert_eq!(compute_verdict_v2(&v1_safe, PRE_CUTOFF_ID), BrandSafetyVerdict::Safe);

// 결정적 케이스: V2가 SFA 라벨을 보내면 V1의 heuristic까지 무시
let freed = labels_with(&[
    SafetyLabelType::NSFA_HIGH_PRECISION,
    SafetyLabelType::GROK_NSFA,
    SafetyLabelType::GROK_SFA_V2,
]);
assert_eq!(compute_verdict(&freed, PRE_CUTOFF_ID), BrandSafetyVerdict::MediumRisk);
assert_eq!(compute_verdict_v2(&freed, PRE_CUTOFF_ID), BrandSafetyVerdict::Safe);

— home-mixer/models/brand_safety.rs:290-322

어제 정본에 반영한 4세대+2 원안과 비교하면 다음이 뒤집혔다.

이번 재설계는 방향이 훨씬 명확하다. dual-write 마이그레이션의 정공법인 "V2가 판정했으면 V2가 지배하고, 아니면 V1 안전망을 유지한다"를 그대로 택했기 때문이다. 어제 반영한 rule id 7개 필터 방식은 하루짜리 실험이었던 셈이다.

Following 피드를 만드는 reverse-chron(시간 역순) 파이프라인이 전용 노출 판정 하이드레이터로 분기됐다. 노출 판정을 맡는 VF(visibility-filtering)는 포스트를 지금 뷰어에게 보여도 되는지 판정하는 서비스다. 하이드레이터는 후보 포스트에 필요한 필드 값을 채우는 단계다.

신규 파일 home-mixer/candidate_hydrators/vf_following_candidate_hydrator.rs(95줄)가 연결됐고, reverse_chron_posts_pipeline.rs는 기존 VFCandidateHydrator 대신 이 새 하이드레이터를 쓴다. 새 하이드레이터의 시그니처는 기존과 거의 같다. 다만 반환하는 PostCandidate에 visibility_reason과 drop_ancillary_posts 두 필드만 값을 채우고, 나머지는 ..Default::default()로 초기화한다. 즉 Following 파이프라인은 VF 하이드레이션 산출물을 이 두 필드로 줄이고, 나머지 후보 필드는 다른 하이드레이터가 채우는 구조다. should_drop_ancillary 헬퍼는 기존 파일에서 pub(crate)로 공개되어 새 파일에서 재사용된다.

• 새 하이드레이터는 별도 파일로 새로 생겼다 확인 — home-mixer/candidate_hydrators/vf_following_candidate_hydrator.rs

  pub struct VFFollowingCandidateHydrator {
      pub strato_vf_client: Arc<dyn VfClient + Send + Sync>,
      pub xai_vf_client: Arc<dyn VfClient + Send + Sync>,
  }
  
  #[async_trait]
  impl Hydrator<ScoredPostsQuery, PostCandidate> for VFFollowingCandidateHydrator {
      async fn hydrate(&self, query: &ScoredPostsQuery, candidates: &[PostCandidate])
          -> Vec<Result<PostCandidate, String>> {
          // ... post_ids 수집, client.get_result(post_ids, TimelineHome, query.user_id, context)
          let hydrated = match primary_result {
              Some(Err(err)) => Err(err.to_string()),
              _ => Ok(PostCandidate {
                  visibility_reason,
                  drop_ancillary_posts: Some(drop_ancillary),
                  ..Default::default()
              }),
          };
          // ...
      }
  }
  

• reverse_chron_posts_pipeline.rs는 기존 하이드레이터 대신 새 하이드레이터를 연결한다 확인.

  -            Box::new(VFCandidateHydrator::new(strato_vf_client, xai_vf_client).await),
  +            Box::new(VFFollowingCandidateHydrator::new(
  +                strato_vf_client,
  +                xai_vf_client,
  +            )),
  

• SafetyLevel::TimelineHome은 그대로 유지된다. Following과 For You가 안전 레벨은 공유한다는 뜻이고, TimelineHomeRecommendations가 아니라는 점도 다시 확인했다.

• should_drop_ancillary 헬퍼는 기존 vf_candidate_hydrator.rs에서 pub(crate)로 승격되어 두 하이드레이터가 함께 쓴다.

• 반환값이 다르다. 기존 하이드레이터는 후보의 모든 필드를 채워서 반환하지만, 새 하이드레이터는 두 필드(visibility_reason과 drop_ancillary_posts)만 채우고 나머지는 default로 둔다. 즉 Following 파이프라인에서는 다른 하이드레이터가 나머지 필드를 이미 채워 둔 상태에서 VF 결과만 추가한다는 뜻으로 읽힌다 추정.

재순위를 담당하는 VMRanker에 보내는 요청에 SID(semantic ID, 아이템을 여러 층의 이산 코드로 표현한 ID) 필드 7개가 새로 연결됐다. 3세대부터 4세대+2까지 SID는 Phoenix retrieval의 window 이름(video_14day·video_48h·nsfw_video_48h/168h/14day)에만 등장했다. 이번 변경은 VMRanker 쪽에서도 SID를 명시적으로 소비하기 시작한 첫 흔적이다. 3-level 코드북(coarse → fine)이 존재한다는 아키텍처 사실도 이 연결로 새로 확정됐다.

home-mixer/scorers/vm_ranker.rs의 build_request는 각 source의 k, pool_rank, pool_rank_gap 옆에 새 필드를 함께 실어 보내기 시작했다. 새 필드는 sid_known, 3-level 계층 SID codeword인 sid_k1/k2/k3, 각 레벨의 이웃 gap인 sid_gap1/gap2/gap3이다.

• build_request는 source마다 기존 rank 필드 셋과 SID 필드 일곱을 함께 싣는다 확인 — home-mixer/scorers/vm_ranker.rs:194-206

  Some(Source {
      k: s.k,
      pool_rank: s.pool_rank,
      pool_rank_gap: s.pool_rank_gap,
      sid_known: s.sid_known,
      sid_k1: s.sid_k_l1,
      sid_k2: s.sid_k_l2,
      sid_k3: s.sid_k_l3,
      sid_gap1: s.sid_gap_l1,
      sid_gap2: s.sid_gap_l2,
      sid_gap3: s.sid_gap_l3,
  }),
  

  • 요청의 sid_k1/k2/k3과 sid_gap1/gap2/gap3에는 source의 sid_k_l1/2/3과 sid_gap_l1/2/3 값을 그대로 옮긴다.

• 3-level 계층 SID다. 각 후보 소스는 세 codeword를 함께 실어 온다. sid_k_l1이 coarse, sid_k_l2가 mid, sid_k_l3이 fine이다.

• sid_gap_l{1,2,3}은 각 레벨 코드북에서의 이웃 gap이다. pool_rank_gap과 짝을 이루는 필드명이라서 신뢰도나 희소성을 대신 나타내는 지표로 보인다 추정.

• sid_known은 SID가 known(유효)인지 나타내는 bool 플래그다. unknown이면 VMRanker가 다른 필드로 fallback하는 것으로 보인다 추정.

• 새 필드는 기존 k·pool_rank·pool_rank_gap 옆에 나란히 연결됐다. 이 셋은 4세대에서 확정된 후보 소스 rank 정보다. 즉 VMRanker는 다양성과 재순위를 판단할 때 세 축의 정보를 갖게 됐다.

  • 후보 소스별 collaborative rank
  • 3-level semantic ID 위치
  • 이웃 gap

• Phoenix retrieval 쪽 SID window와 이 vm_ranker 필드가 같은 코드북을 공유하는지 다음 커밋에서 확인해야 한다. 이 SID window는 2026-08-14 커밋(4세대+1)에서 video_14day가 추가된 그 SID다.
• DPP(determinantal point process)는 비슷한 아이템이 함께 뽑히면 점수가 깎이도록 집합 단위로 고르는 다양성 기법이다. VMRanker가 SID gap을 DPP 커널의 유사도 성분으로 쓰는지도 다음 커밋에서 확인해야 한다.
• Kuaishou HD-Rec과 PushDualGen에서 관찰된 SID 계열 3층 코드북 방식과 어떻게 대응되는지도 함께 확인할 부분이다. 두 사례는 radar.md에서 관찰 중이다. X는 코드북 구성과 훈련 방법, vocabulary를 공개하지 않았다.

Phoenix retrieval이 받는 upstream 이벤트 스트림이 unified posts topic V3로 마이그레이션됐다. 옮겨 간 것은 Phoenix의 postCreationEventForwarder이고, 다음이 바뀌었다.

• Kafka topic이 content_understanding_realtime_unified_posts에서 ..._v3로 바뀌었다.
• Kafka 클러스터가 X 메인인 main-2에서 Phoenix 전용 별도 클러스터인 phoenix-kafka-external-bootstrap으로 옮겨 갔다.
  • 전체 경로는 /s/kafka/main-2:kafka-tls와 /s/kafka/phoenix-kafka-external-bootstrap이다.
• 매핑이 ValueOnly에서 KeyValue(key=Long)으로 이동했다. 이전에는 Thrift value만 실었고, 이제는 postId를 Kafka key로 명시한다.
  • 새 매핑은 KeyValue({key = Long, keyEncoding = NativeEncoding, ...})다.
• Consumer group도 post_creation_event에서 post_creation_event_v3로 새로 만들었고, develConsumerGroupId = Some("post_creation_event_v3_devel")도 함께 신설했다.

postCreationEventProcessor.strato의 시그니처도 Op.execute[Event, Unit]에서 Op.execute[(Long, Event), Unit]로 바뀌어서, 튜플에서 온 postId를 우선 사용한다.

• 포워더 설정은 다음 diff처럼 바뀌었다 확인 — phoenix-rankall-strato/stream_forwarders/postCreationEventForwarder.strato

  -import <content_understanding/sharedConfig>
  +import <hydra/sharedConfig>
  
   StreamForwarder({
     source = KafkaTopic({
  -    topic = "content_understanding_realtime_unified_posts",
  -    dest = "/s/kafka/main-2:kafka-tls",
  -    consumerGroupId = "post_creation_event",
  -    develConsumerGroupId = None,
  -    mapping = ValueOnly({
  +    topic = "content_understanding_realtime_unified_posts_v3",
  +    dest = "/s/kafka/phoenix-kafka-external-bootstrap",
  +    consumerGroupId = "post_creation_event_v3",
  +    develConsumerGroupId = Some("post_creation_event_v3_devel"),
  +    mapping = KeyValue({
  +      key = Type(Long),
  +      keyEncoding = NativeEncoding,
         value = Type(...ContentUnderstandingMetadataV2),
  -      encoding = ThriftEncoding
  +      valueEncoding = ThriftEncoding
       })
     }),
  

• postCreationEventProcessor.strato의 시그니처도 이에 맞춰 바뀌었다 확인.

  -val executeOp = Op.execute({ idempotent = true })[Event, Unit] { ctx =>
  +val executeOp = Op.execute({ idempotent = true })[(Long, Event), Unit] { ctx =>
  +  val (postId, _) = ctx.arg
     val request = {
  -    postId = ctx.arg.postMetadata.post.postId,
  +    postId = postId,
       eventSource = PostCreation
     }
  

• 콘텐츠 이해 스키마를 v1에서 v3로 올렸다.
• X 메인 Kafka 클러스터에서 Phoenix 전용 격리 클러스터로 옮겼다.
• 매핑에서 postId를 Kafka key로 승격해서, 파티셔닝과 중복 제거, 역인덱스 조회를 순수하게 key 기반으로 처리할 수 있게 했다.

import를 hydra/sharedConfig로 옮긴 것은 Phoenix 계열이 hydra 인프라 아래로 편입되고 있다는 신호다. 이 변경은 2026-08-17 커밋(4세대+2)의 "인덱싱 게이트 제거"와 방향이 같다. 인덱싱 처리량이 커지니 별도 Kafka 클러스터가 필요해졌다고 보면 앞뒤가 맞는다 추정.

grox의 reply_spam이 별도 흐름을 지우고 단일 통합 흐름으로 압축됐다. 이전에는 두 생성기가 나란히 있었다. PostStreamTaskGenerator는 전체 post 스트림에서 스팸을 감지하고, ReplyRankingTaskGenerator는 답글을 랭킹한다.

• 오늘 커밋은 PostStreamTaskGenerator를 삭제하고 TOPIC_UNIFIED_POSTS(v1 topic) 상수까지 지웠다.

• 대신 ReplyRankingTaskGenerator가 세 플랜을 함께 주입하는 형태로 통합했다. PlanReplyRanking은 기존 플랜이고, PlanSpamComment와 PlanCoordinatedSpam은 새로 흡수한 플랜이다.

• task_filter.py에서는 follower 임계를 40k에서 60k로 1.5배 올렸다 확인 — grox/flows/reply_spam/task_filter.py.

  • 2026-08-14 커밋(4세대+1)의 15k → 30k, 2026-08-17 커밋(4세대+2)의 30k → 40k에 이은 세 번째 상향이다.

• 즉 grok 스팸 판정 대상은 넓어지고 답글 랭킹 채점 대상은 좁아졌다 확인 — task_filter.py:77-92, 214-225.

  • root와 답글 대상이 모두 임계 이하인 답글은 스팸 판정을, 하나라도 임계를 넘는 답글은 답글 랭킹 채점을 받는다.
  • 채점 파이프라인 자체도 단일 topic(v3)에 단일 흐름 하나로 정리됐다.

• 생성기 정리는 다음 diff와 같다 확인 — grox/flows/reply_spam/generators.py

  -@register
  -class PostStreamTaskGenerator(StreamTaskGenerator):
  -    TASK_GENERATOR_TYPE = POST_STREAM
  -    PLANS_TO_INJECT = {PlanSpamComment.KEY, PlanCoordinatedSpam.KEY}
  -
  -    def _get_loader(self):
  -        return KafkaPostLoader(TOPIC_UNIFIED_POSTS)
  -
  
   @register
   class ReplyRankingTaskGenerator(StreamTaskGenerator):
       TASK_GENERATOR_TYPE = REPLY_RANKING
  -    PLANS_TO_INJECT = {PlanReplyRanking.KEY}
  +    PLANS_TO_INJECT = {
  +        PlanReplyRanking.KEY,
  +        PlanSpamComment.KEY,
  +        PlanCoordinatedSpam.KEY,
  +    }
  
       def _get_loader(self):
           return KafkaPostLoader(TOPIC_UNIFIED_POSTS_V3)
  

• task_filter.py의 두 임계 상수도 재조정했다 확인.

  • TaskSpamFilter.FOLLOWER_COUNT_THRESHOLD_FOR_SPAM_DETECTION: 40,000 → 60,000
  • TaskReplyRankingFilter.FOLLOWER_COUNT_THRESHOLD_FOR_REPLY_RANKING: 40,000 → 60,000

• constants.py도 정리했다 확인. POST_STREAM과 TOPIC_UNIFIED_POSTS 상수를 삭제했다.

  • 남은 상수는 REPLY_RANKING, REPLY_RANKING_RECOVERY, TOPIC_UNIFIED_POSTS_V3, TOPIC_REPLY_RANKING_RECOVERY 네 개다.

콜드스타트 계측이 단순해졌다. 바뀐 곳은 author_cold_start.rs의 count_tracked_ids이고, tracked 필터가 사라졌다.

• 카운트 로직이 다음처럼 바뀌었다 확인 — home-mixer/scorers/author_cold_start.rs:100-107

       let source = c.served_type.map(|t| t as i32).unwrap_or(0);
  -    if tracked.contains(&c.tweet_id) {
  -        *counts.entry((c.tweet_id, source)).or_insert(0) += 1;
  -    }
  -    if tracked.contains(&c.author_id) {
  -        *counts.entry((c.author_id, source)).or_insert(0) += 1;
  -    }
  +    *counts.entry((c.tweet_id, source)).or_insert(0) += 1;
  

• tracked 리스트 필터를 제거하고 author_id 카운트도 삭제해서, 이제 모든 후보의 tweet_id를 항상 카운트한다.

• 즉 home_mixer.cold_start_tracked_ids_total{id, source} 계측의 성격이 바뀌었다. 이제는 특정 tracked ID의 등장 횟수가 아니라, 콜드스타트 파이프라인이 소스별로 후보를 몇 개 흘려보내는지의 전수 관측이다.

• ColdStartTrackedIds param 자체는 그대로 남아 있지만, 이 함수를 쓰는 곳과의 연결이 바뀐 셈이다. 관찰 훅의 목적이 "특정 계정 A/B"에서 "소스별 전체 트래픽"으로 이동했다.

이 커밋에는 마이너 변경 4건도 함께 들어 있다.

• grox 성인 콘텐츠 cross-validation의 로깅이 개선됐다 확인. 어제 반영한 심판 태스크에서 Metrics.counter(metric)의 outcome attribute가 "hard"|"soft" 두 가지 라벨에서 판정 결과인 policyType.value 원본으로 바뀌었다. 심판이 성인 카테고리를 더 세분화해서 반환하더라도 손실 없이 계측할 수 있다.
• home-mixer/candidate_hydrators/mod.rs에 vf_following_candidate_hydrator 모듈이 등록됐다 확인.
• visibility-filtering/server_deps.rs에서 Gizmoduck(X의 유저 정보 서비스) Strato 클라이언트의 타임아웃을 80ms로 명시했다 확인. 이전에는 timeout을 명시하지 않았다.
  • const GIZMODUCK_STRATO_REQUEST_TIMEOUT_MS: u64 = 80 상수를 새로 만들고, request_timeout_ms: Some(GIZMODUCK_STRATO_REQUEST_TIMEOUT_MS)로 클라이언트 설정에 연결했다.
• home-mixer/candidate_hydrators/ads_brand_safety_vf_hydrator.rs가 +1/−1 바뀌었다 확인. 상위 하이드레이터를 미세하게 조정했고, V2 판정 재설계에 맞춰 연결을 유지했다.

• 한 줄 요약 절: 최종 갱신은 2026-08-19 → 2026-08-20, 요약 문단에는 4세대+3 서술을 추가했다.
• 공개 소스 4세대 테이블: 4세대+3 행(11a71f8)을 추가했다.
• 광고 절(brand_safety V2): 4세대+2와 4세대+3 두 세대를 나눠 서술하는 형태로 넓혔다. strip_v1_grok_written 삭제와 V2_WRITTEN_LABELS 게이트 재설계를 자세히 적고, 새 테스트 v2_defers_to_v1_when_v2_has_not_ruled의 결정적 케이스를 인용했다.
• 랭킹 절(VMRanker와 DPP): SID 필드 7개를 정리한 표를 추가하고, 3-level 계층 코드북 사실을 반영했다.
• 콜드스타트 절: count_tracked_ids 단순화를 반영했다.
• Phoenix 학습·인덱스 절: postCreationEventForwarder V3 마이그레이션 상세 표를 넣었다.
• Grox 절: 4세대+3의 재조정과 흐름 통합(PostStreamTaskGenerator 삭제, follower 임계 60k)을 반영했다.
• Grox → PtOS 성인 콘텐츠 cross-validation 절: 4세대+2 심판 태스크의 로깅 개선을 반영했다.
• 피드 지면 절(Following): VFFollowingCandidateHydrator 분기를 반영했다.
• 열린 질문 절: "4세대+3 공개로 해소된 것 / 뒤집힌 것 (2026-08-20)"을 신설했다. ⚠ 주장 변경 (하루 만에) 항목으로, 어제 반영한 PROMPT_OWNED_RULES 라인이 뒤집혔음을 명시했다.
• 출처 절: 4세대+3 관련 파일 6개 링크를 추가했다.

어제 daily에 심층 분석이 필요하다고 남겼던 "PROMPT_OWNED_RULES 7개 rule id ↔ botmaker-rules/ 실 규칙 파일 매핑" 질문은 저절로 해소된 것이 아니라 질문 자체가 없어졌다. 그 상수가 코드에서 지워졌기 때문이다.

이 일은 정본에 두 가지 관찰 근거를 남긴다.

1. X의 4세대 릴리즈 주기가 "매일 커밋하고 하루 만의 재설계도 흔하다"는 관찰로 확정됐다. 4세대(8-13) → 4세대+1(8-14) → 4세대+2(8-17) → 4세대+3(8-18)은 닷새 사이(8-13~8-18)에 나온 4번의 공개다. 그중 마지막 두 개(어제와 오늘)는 어제 넣은 dual-write 로직을 오늘 완전히 대체한 하루짜리 실험이다. 4세대에서 docs/BIDIRECTIONAL_BOOST_CHANGE.md가 도입한 "코드 diff로 파라미터 변경을 문서화하겠다"는 관행이, 닷새 만에 실제 사례를 두 번 만들어 냈다.
2. 정본이 새 dual-write 로직을 반영할 때는 "이 로직 자체가 다음 커밋에서 바뀔 수 있다"는 점을 서술에 함께 담는 것이 맞다. 어제 daily의 strip_v1_grok_written 서술은 상세한 근거와 rule id 나열, 미공개 항목 목록까지 완벽했다. 하지만 "이 로직이 안정판이 될 것"이라는 함의를 은연중에 담고 있었다. 오늘 이후로는 새 dual-write 연결을 볼 때 "이번 커밋의 특정 헬퍼가 다음 세대에서 지워질 수 있다"는 관찰을 항상 함께 적는다.
3. 새 판정 조건인 V2_WRITTEN_LABELS 라벨 4개의 유래가 새 심층 분석 대상이다. GROK_SFA_V2·GROK_NSFA_V2·GROK_NSFA_LIMITED_V2·GROK_NSFA_EXPANDED_V2 네 개는 어제 라벨 세트에 들어간 3개(GROK_NSFA_V2·GROK_NSFA_EXPANDED_V2·GROK_NSFA_LIMITED_V2)에 GROK_SFA_V2를 더한 구성이다. GROK_SFA_V2는 새 라벨이 아니라, 4세대+2부터 compute_verdict_v2가 Grok 채점 여부를 가릴 때 쓰던 라벨이다 확인 — brand_safety.rs:120-130@b089ce6. 아직 확인하지 못한 것은 다음 세 가지다.
   • GROK_SFA_V2가 "safe for ads V2"라는 명시적 positive 라벨을 뜻하는지
   • Grok 프롬프트 재훈련이 어제와 오늘 사이에 배포된 것인지
   • 아니면 V2 라벨러가 자산의 다른 파이프라인에서 온 것인지

검증에서 뒤집힌 것

⚠ 4세대+2의 dual-write 로직 서술이 뒤집혔다. 어제 daily/2026-08-19의 상세 인용도 여기에 포함된다. strip_v1_grok_written과 PROMPT_OWNED_RULES 7개 rule id 라인이 오늘 코드에서 삭제됐다.

• 정본에서는 4세대+2 서술을 지우지 않았다. 대신 "하루 만에 재설계됨"이라는 주석을 붙여서 세대를 비교하는 근거로 남겼고, 열린 질문 절과 4세대 테이블 두 곳에 명시했다.
• 이렇게 하면 CLAUDE.md의 "정본은 결론만 담아 압축한다" 원칙을 조금 어기는 것처럼 보인다. 그래도 하루짜리 dual-write 실험 자체가 X의 릴리즈 주기를 관찰하는 데 결정적인 근거이므로, 세대 비교용으로 남겨 둔다.

레이더와 확인 범위

레이더에 새로 올린 항목은 없다. 오늘 확인한 곳과 결과는 다음과 같다.

arXiv에서 triage한 30건 가운데 프로덕션이나 A/B 진술이 있어서 새로 통과한 항목은 0건이다. UniDot(arXiv 2608.16797, 2026-08-17)은 industrial recommender 통합 아키텍처를 다루지만 레이더 수용 기준에 미달한다. KDD Cup 2026 runner-up 결과 진술만 있고, 프로덕션 배포와 저자 소속, A/B 지표 어느 것도 공개되지 않았기 때문이다.

다음에 볼 것