> ## 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.

# Rehearsal and Acceptance

> Scoring-only scope, DCinside’s draft pass criteria, open decisions and start conditions

## Scope

The dress rehearsal uses real candidates and model scores. DCinside logs would-be picks, while operators continue their existing publishing. The model does not publish. This stage can run **before DCinside's publishing API is ready**.

Operator reason labels and daytime overlap with operator picks are reviewed during rehearsal, but DCinside did not propose them as pass criteria. Model quality needs real placements later. Operator-placed outcomes can be shared daily by separate agreement; their delivery is not listed as a rehearsal pass condition. The client-facing outcomes and weights-management endpoints are marked **Not in scope for trial** in this integration draft. Surf configures the initial model and weights.

## DCinside's draft pass criteria

These are DCinside's proposals, pending confirmation by both teams. They are not a finalized SLA.

| Criterion | Draft threshold |
| - | - |
| Duration | Three consecutive days, including three 02:00–07:00 KST overnight windows. |
| Delivery continuity | At least 99% of 288 daily cycles sent; any gap over 15 minutes must trigger an alert. The 288 count assumes five-minute cycles. |
| Response time | Scores arrive within the agreed response deadline in at least 99% of cycles. The deadline is not yet set. |
| First score | At least 99% of queue candidates receive a score within two cycles of entering the queue. |
| Removals | Saved, hidden, deleted and aged-out posts are no longer scored. |
| Reconciliation | Daily sent, received and scored counts reconcile; 100% of scores join to DCinside's post IDs. Agree how unique candidates and repeated scoring events are counted. |
| Failure drills | Stop sending for 20 minutes and verify the 15-minute alert reaches DCinside; send a late response and verify DCinside skips that cycle. |

Agree how the intentional interruption is counted in delivery percentages and how removals before first scoring are counted in the first-score denominator. These are open measurement details, not automatic exclusions.

## Decisions to confirm

| Topic | Surf proposal / open question |
| - | - |
| Transfer | HTTPS API; DCinside's agenda also offers S3. Confirm reachable host, image layout and payload. |
| Credentials | Long-lived, scoped credential; confirm scope, handoff, rotation and whether sender IP allowlisting is needed. |
| Timestamps | RFC 3339 with an explicit offset; normalize to KST. |
| Cadence | Start at five minutes within the stated 2–5-minute range. |
| Score delivery | Scores in the cycle response, plus retrieval for recovery. |
| Re-scoring | Refresh every pending candidate on each new cycle. This remains an open agenda item. |
| Deadline and freshness | Agree maximum API response time, stale-score detection and retry budget. |
| Alert | Surf sends a 15-minute no-data alert; Slack channel, recipient contacts and a Surf contact need confirmation. |
| Recovery | Stable request IDs; confirm retention, restart recovery and reconciliation of unacknowledged data. |
| Start | Agree a date after the integration checks and readiness work below are complete. |

## Before starting

Endpoint availability is not sufficient evidence of rehearsal readiness. Surf must verify the delivered model, initial-scoring timing, agreed refresh behavior, durable recovery and alert delivery with DCinside.

The current implementation still has a placeholder scorer, a 15-minute delay, cached per-post scores and process-local cycle state. Independent no-data alert delivery and restart recovery have not been demonstrated. These gaps must be addressed and tested before the three-day acceptance run. The request-level `scored_at` also needs to represent actual completion before using it for latency measurement.

## Later publishing stages

DCinside's proposed Stage 1 is 02:00–07:00 KST every day, including weekends, on Main and Light, with next-morning operator review. The Night tier and weekend daytime are excluded from that first stage. An interleaved daytime stage comes later. **The publishing API dependency applies to publishing stages, not to the scoring-only rehearsal.** Publishing controls remain DCinside's responsibility.

## Source messages

* [DCinside's consolidated requirements and scoring-only rehearsal](https://asksurfai.slack.com/archives/C0BTC0P6L23/p1790673671675129)
* [Technical agenda and open decisions](https://asksurfai.slack.com/archives/C0BTC0P6L23/p1790691915368649)
* [Draft rehearsal acceptance criteria](https://asksurfai.slack.com/archives/C0BTC0P6L23/p1790693062916269)

These links require access to the shared Slack channel. This page summarizes the relevant requirements for developers without Slack access.