Step 2: Workflow

This chapter defines how the automation executes in production, from set validation to review and publish. Step 1 defined why and boundaries; Step 2 defines runtime behavior.

2.1 End-to-end execution model

The workflow is a staged desktop pipeline orchestrated in main_set.py. It is designed so the operator can process high-volume sets while keeping strict publish control through a mandatory review gate.

• Stages 1 to 7 prepare files and metadata into a review-ready state.
• Stage 8 opens the review editor where human decisions are applied.
• Only approved rows continue into publish (FTP + MySQL sync path).
• Blocking failures trigger rollback so the run can be retried safely.

Workflow figure: high-level stage flow from import through publish.

2.2 Stage sequence in main_set.py

1. Validate sets - checks selected set inputs before any write operations.
2. Prepare DB and copy to incoming - establishes working context and staged local inputs.
3. Extract EXIF and initial metadata - seeds technical metadata used downstream.
4. Insert or refresh review rows - creates or updates queue rows in review_queue.
5. AI quality scoring - computes quality signals for later review decisions.
6. Resize images for Ollama - writes temporary model-ready files and tracks ollama_path.
7. Caption and keywords prefill - generates assistive metadata suggestions locally with evidence-first keyword guardrails, plus filename/time-of-day consistency checks and NL lowland anti-mountain filtering.
8. Open review editor - transitions into manual review and approval workflow.

2.3 Runtime data flow

• Source files are normalized into staging paths for deterministic processing.
• Operational record truth is stored in data/review.db, table review_queue.
• In EXE runs, helper scripts are staged into data/_runtime_scripts before execution to avoid frozen-runtime DLL conflicts.
• Caption stage reads ollama_path (fallback Path) on a row basis.
• Keyword post-filter enforces evidence-only behavior for sensitive geography/terrain terms (no forced usa/colorado or generic terrain fillers without context).
• Context guardrails keep metadata aligned with set cues: NL/polder runs suppress mountain-alpine drift, and filename cues such as sunrise/sunset constrain time-of-day wording.
• Editor updates write final text fields, quality decisions, and publish intent.
• Publish sync writes approved rows to remote assets and DB while updating local mirror state.

2.4 Review and publish path after stage 8

1. Operator validates and edits caption, alt text, keywords, and filename fields.
2. Each row receives a decision status (approved or rejected).
3. Publish action targets approved rows only.
4. Uploader sends full image and thumbnail outputs to configured FTP destinations.
5. MySQL upsert is applied using File_Name as stable key.
6. Local mirror IDs and publish state are synchronized after remote write success.
7. Temporary model artifacts are cleaned when publish completes without blocking errors.

2.5 Queue statuses and transition intent

Primary fields:

• QC_Status - quality class from automated scoring and review updates.
• Review_Status - lifecycle decision such as Pending, Approved, Rejected, Published, or Error.

Transition rule: no row enters publish state without explicit review approval.

2.6 Failure handling and rollback behavior

Failures are handled as session events, not isolated row edits. If a blocking error occurs during the pipeline, rollback logic restores operational consistency so a clean rerun is possible.

• Inserted session rows are removed from the active review queue when required.
• Moved or staged files are restored to original folders.
• Reserved filenames are released from data/used_filenames.json.
• Failure details remain visible in logs for diagnosis before rerun.

Rollback figure: blocking caption-model error followed by automated session cleanup.

2.7 Run artifacts and logs

• Pipeline log: logs/latest_run.log (or beside EXE in frozen builds).
• Uploader log: logs/db_uploader.log.
• Runtime callback crash log: data/crash_runtime.log.
• Run summary: data/run_log.txt.
• Frozen helper staging path: data/_runtime_scripts/.
• Temporary model files: data/ollama_tmp/run_*.

2.8 Continuation path

Step 2 describes execution behavior. Step 3 defines daily operation, checklists, and recovery procedure for production use.