KArtSell.Aegis/docs/CURRENT/PHASE-1_EXECUTION_EVIDENCE_PLAN.md

Phase 1 Execution Evidence Plan

Objective

Create the evidence required to move PHASE-1-SHADOW-RUN from BLOCKED to RUNNING, using shadow-only / EVALUATION_ONLY execution. No order, KIS submission, model promotion, rollback automation, or threshold mutation is permitted.

Owner and deadline

• Owner: 김재현
• Target date: 2026-08-06 KST
• Evidence root: evidence/phase-1-requeue-20260806/
• Approval record: docs/CURRENT/PHASE-1_REQUEUE_READINESS.md

Step 1 — Freeze the server-side VersionSet

The owner obtains these values from the approved server-side PIT context; do not invent or accept client-supplied values:

DatasetId:
ModelSha256:
ConfigSha256:
CodeSha:
ContractVersionSet:
PolicyTraceSchemaVersion:
PITCutoffUtc:
PublishedRevisionRule:

Save the exact values and the source query/API response as:

evidence/phase-1-requeue-20260806/versionset.json
evidence/phase-1-requeue-20260806/versionset-command.txt

Pass condition: every field is present, server-derived, and approved by the Model/Data Owner. A missing field stops the procedure.

Step 2 — Record DBA migration evidence

The DBA runs the following read-only checks against the explicitly approved target database and saves output. The database name must be checked before execution.

SELECT current_database(), current_user;

SELECT scriptname, applied
FROM public.__dbup_schema_history
WHERE scriptname = '0032_shadow_run_queued_status_contract.sql';

SELECT conname, pg_get_constraintdef(oid)
FROM pg_constraint
WHERE conrelid = 'model_operations.shadow_run'::regclass
  AND conname = 'check_status';

Save:

evidence/phase-1-requeue-20260806/db-migration-receipt.txt
evidence/phase-1-requeue-20260806/db-migration-receipt.sha256

Pass condition: migration journal contains 0032, the constraint includes Queued, and the DBA records database, timestamp, operator, and approval ID.

Step 3 — Generate new immutable execution identifiers

Generate locally or at the approved server boundary; never reuse Job 893:

$runId = [guid]::NewGuid()
$jobRunId = [guid]::NewGuid()
$correlationId = [guid]::NewGuid()
$idempotencyKey = "phase1-requeue-20260806-$([guid]::NewGuid())"
@{
  runId = $runId; jobRunId = $jobRunId; correlationId = $correlationId
  idempotencyKey = $idempotencyKey; generatedAtUtc = (Get-Date).ToUniversalTime().ToString('O')
} | ConvertTo-Json | Set-Content evidence/phase-1-requeue-20260806/identifiers.json

Record the generated values in the approval form before enqueue. Do not log credentials or tokens.

Step 4 — Execute the contract-compliant enqueue

Only after Steps 1–3 pass and the human approval record is complete, use the approved host URL and server-side model context. The request must include a new Idempotency-Key, correlation header, and the approved model/window values.

$headers = @{
  'Idempotency-Key' = $idempotencyKey
  'X-Correlation-Id' = $correlationId
  'X-KArtSell-User' = '김재현'
  'X-KArtSell-Role' = 'Researcher'
}
$body = @{
  model_id = '<approved-model-id>'
  window_start = '<approved-pit-window-start>'
  window_end = '<approved-pit-window-end>'
  phase_filter = 'All'
} | ConvertTo-Json

Invoke-WebRequest -Uri '<approved-host>/api/shadow-runs' -Method Post `
  -Headers $headers -ContentType 'application/json' -Body $body `
  -OutFile evidence/phase-1-requeue-20260806/enqueue-response.json

Pass condition: HTTP 202, a new run_id, a new job_id, and status=Queued. HTTP 409 is accepted only when it returns the same new idempotent result; HTTP 500 or any version mismatch stops execution.

Step 5 — Preserve observation evidence

Poll only the returned new run_id. Save raw responses and timestamps under the evidence root. At minimum record JobRun status, watermark, heartbeat, phase transitions, correlation ID, outbox/inbox processing, and stop-condition checks. Do not claim completion until the actual artifacts exist.

Gate decision

• RUNNING: Steps 1–4 pass and the 202 response plus new identifiers are preserved.
• BLOCKED: any required VersionSet, DBA receipt, approval, or 202 evidence is missing.
• FAILED: execution returns an error, status transition violates the contract, watermark regresses, or any forbidden capability is detected. Preserve evidence and stop; do not mutate historical records.

This plan is an execution aid, not evidence itself. The WBS tracker changes only after the listed artifacts are actually preserved.