---
title: "Collection, Diagnosis, and Observation: Why Should Three Kinds of Success Status Be Separated?"
slug: "collection-diagnosis-observation-states"
language: "en"
tags: ["상태 의미론","아키텍처 노트","sag 기술","수집 아키텍처"]
created: "2026-10-06T08:00:00.000Z"
published: "2026-10-08T10:13:31.441Z"
updated: "2026-10-08T10:13:36.612Z"
sample: false
---

# Collection, Diagnosis, and Observation: Why Should Three Kinds of Success Status Be Separated?

## What Is Status Semantics?

**It is the principle of modeling data acquisition, completion of internal analysis, and confirmation of external visibility as separate statuses.** This note reads status semantics in terms of the responsibilities of inputs, transformations, and outputs rather than feature names. To trust analysis results, you need a traceable account of what data came in, what was checked, and how far conclusions can be drawn.

## Why Is This Technology Needed?

HTTP 200 means only that a request succeeded; it does not mean the brand appeared in an AI answer. If only “completed” is shown, customers may confuse result quality with execution status.

## Design Principles and Data Flow

Record task status, validation status, and metric values in separate fields. Distinguish errors and unobserved data from an actual 0% result, and specify the next actions available for each status.

> **Page collection** → **Diagnosis completed** → **Separate search/AI observation**

Each stage must not relabel the success of the preceding stage as the performance of the next. Recording data identifiers, periods, and validation status throughout makes it possible to locate where omissions and errors occurred and determine what to check again.

## Connection to the SAG Architecture

SAG’s monthly screen aggregates page collection, completed analysis, and visibility observation separately. AEO analysis completion status is also not the same as question coverage or the actual mention rate.

SAG’s operational value lies in connecting these relationships to pages and questions, comparison results, and improvement tasks. Rather than reading numbers alone, customers can review both what needs to be strengthened and the grounds for making that judgment. Patterns requiring further application should be interpreted based on the scope of the relevant paragraph.

## Illustrative Example and Criteria for Judgment

For illustration, if there are 10 collected items, 6 analyzed items, and 0 observed items, operational work has already taken place, but there is no data from which to calculate a visibility rate. The fact that there are 0 observed items does not prove that the brand was not visible.

The example above is provided to explain the structure and calculation; it is not measured performance from a particular customer. In an actual report, the selected period, targets, observation conditions, and original records must be linked so the same judgment can be checked again.

## Practical Verification Checklist

| Flow stage | Item to check |
| --- | --- |
| Page collection | Document the definition for each success status |
| Diagnosis completed | Distinguish unobserved data from 0% |
| Separate search/AI observation | Ensure aggregations match the screen descriptions |

Check that meanings remain consistent not only with normal inputs, but also with empty, duplicate, and differently conditioned data. Connecting validation items to task completion criteria can reduce the gap between feature descriptions and actual operations.

## Limitations and Considerations for Application

The more statuses you create, the easier it is for their definitions to become inconsistent. Document the entry conditions and aggregation denominator for each status, and distinguish customer-facing terminology from internal enums.

## Research and Official Documentation

- [IETF HTTP Semantics RFC 9110](https://www.rfc-editor.org/rfc/rfc9110.html) — A standard for checking the meaning of HTTP requests, responses, and statuses.

External materials provide background on the design topic above; they do not certify every SAG implementation or customer result. The interpretation and illustrative example in this note are organized around SAG’s operational structure. Source checked: 2026-10-06.

## Further Reading and Feature Information

- [Related architecture note](/ko/blog/observability-audit-log)
- [Try a service connected to status semantics](/ko/preview/dashboard?scenario=cream)
- [Feature-specific FAQ](/en/faq)
- [Discuss implementation scope](/ko#inquiry)


## How to Continue Reading About This Technology

Follow the sequence: HTML ZIP/site map → normalization → page version → evidence record.

- [How data becomes evidence](/ko/blog?tag=%EC%88%98%EC%A7%91%20%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98)
- [Feature guide FAQ](/en/faq)