> ## Documentation Index
> Fetch the complete documentation index at: https://surf-dcinside-api.kr.ask.surf/llms.txt
> Use this file to discover all available pages before exploring further.

# Overview

> Proposed API for the DCinside scoring-only dress rehearsal

## Scoring-only dress rehearsal

DCinside sends real candidates from the full admin extraction queue to Surf and receives model scores. DCinside records what it would have published and compares those choices with operators' actual picks. **No posts are published by the model during this rehearsal; operators continue as usual.** The rehearsal checks the integration. Model quality needs later evaluation with real placements.

<Warning>
  **Draft for review.** These pages and the OpenAPI specification describe the proposed rehearsal contract, not a declaration that the deployed service is ready. Endpoint shapes are Surf's proposal. The cadence, re-scoring policy, response deadline, credentials and image transfer still need confirmation. See [Rehearsal and acceptance](/rollout) for start conditions.
</Warning>

## Data flow

1. DCinside applies its 24-hour age filter and sends each new candidate's text and images once.
2. Every cycle, DCinside sends engagement updates for all pending candidates and removal signals for posts leaving the queue.
3. Surf returns a final score, post identity, model version and scoring time. We propose refreshing scores for every pending candidate each cycle.
4. DCinside logs would-be picks. Late or stale responses are skipped for that cycle; recovered responses remain useful for reconciliation.

All connections are initiated by DCinside. We propose HTTPS, inline cycle responses and a retrieval endpoint for recovery. Five-minute cycles are the proposed initial setting within DCinside's stated 2–5-minute range. About **2,200 candidates/day is a volume estimate, not a quota**.

## Rehearsal endpoints

| Call | Purpose |
| - | - |
| [`POST /v1/cycles`](/cycles) | New candidates, pending engagement and removals; returns scores. |
| [`GET /v1/scores/{cycle_id}`](/scores) | Retrieve the stored response for a particular cycle. |
| [`PUT /v1/images/{gall_id}/{post_no}/{NN}`](/images) | Proposed image upload route; transfer details remain open. |
| [`GET /v1/health`](/health) | Service information and latest received cycle. |

## Reference endpoints — Not in scope for trial

| Call | Reference purpose |
| - | - |
| [`GET /v1/weights`](/get-weights), [`PUT /v1/weights`](/set-weights) | Inspect and change score weights in a later client integration. The initial trial configuration is set by Surf. |
| [`POST /v1/outcomes`](/outcomes) | Outcome delivery endpoint for a later integration. Operator outcomes may be shared daily by separate agreement during rehearsal. |

## Model and timing

The intended model is the delivered **Model 0924 with down-vote weight 0**. A transport-test adapter is not a substitute for that model. Per-part predictions are optional.

DCinside's draft asks for at least 99% of candidates to receive a first score **within two cycles of entering the queue**. There is no separate scoring wait in this proposal. The maximum wait for each individual API response is a different setting and remains to be agreed.

Read the [conventions](/conventions) and [rehearsal acceptance draft](/rollout) before integrating. [How Scoring Works](/scoring) is marked **Not in scope for trial**. The machine-readable specification is [OpenAPI JSON](/openapi.json).