Step 0: V1.0 Documentation Overview

Documentation for the production automation in Amir2000 Image Automation V1.0. This page is the navigation hub for the core path and supporting references.
Start at:Amir2000 Image Automation V1.0 | Case Study first.
Then continue from Step 1 to Step 5 in order.

Current Production Additions

• DB-based multi-set workflow in main_set.py.
• Local subject suggestion and regeneration with optional soft hints, without copying hints directly into subject or folder fields.
• Temporary Ollama resize stage to keep full-resolution originals untouched while reducing model load.
• Subject regenerate keeps its context alive for the background worker, avoids same-wording repeats, and falls back when the configured stronger model is not installed.
• Deterministic metadata repair before the production quality gate.
• metadata_quality proof table stores accepted upload metadata, issue reasons, repair attempts, and final upload state.
• Quality gate blocks filler wording, filename token leaks, folder/category leaks, repeated wording, broken keyword fragments, empty upload fields, and duplicate captions or alt text.
• Identifier router scripts provide the V1.0 foundation for general vision, biology, vehicle/aircraft, consensus, and DB writeback paths.
• Scratch validation now blocks mixed-set subject mistakes and weak broad metadata instead of forcing a folder/topic-specific fix.
• Stage 6 stability guards: idle/hard timeout watchdog plus row quarantine on repeated native prefill crashes.
• Review-editor Generate action for row-level metadata retry with pending-row duplicate protection.
• Publish completion UX uses one final dialog and closes review window on OK.
• Startup Ollama runtime visibility line (processor=GPU/CPU context=... vram=...) for immediate mode verification.
• Optional run-end Ollama process close via OLLAMA_CLOSE_ON_RUN_END.

V1.0 Metadata Quality and ML Foundation

• metadata_quality is initialized as the audit table for generated, repaired, accepted, rejected, blocked, and uploaded metadata.
• Rows capture accepted upload fields separately from current/generated fields, making later model evaluation measurable.
• Repair attempts are bounded so failed metadata does not create endless loops.
• Database writes happen only after regenerated metadata passes quality proof.
• The ML track starts from this table: reviewed outcomes become evaluation data for future caption/keyword models.
• Improvements remain generic and archive-wide, not tied to one folder, one topic, or one subject.

Core Reading Order (Step 1 to Step 5)

Use this sequence first. It covers the project end-to-end with minimal page switching.

1. Step 1: Purpose and scope - business context, boundaries, and expected outcomes.
2. Step 2: Workflow - exact 8-stage runtime behavior.
3. Step 3: Runbook - daily operation plus recovery procedure.
4. Step 4: Database model - operational truth and publish-side model.
5. Step 5: Developer guide - how to extend without breaking reliability.

Supporting References

Use this order when you need deeper details after the core path.

1. Reference 1: Install and setup - environment bootstrap and first-run readiness.
2. Reference 2: User guide - operator workflow from run to publish.
3. Reference 3: Troubleshooting - targeted diagnosis and fix paths.
4. Reference 4: Logging and failure handling - where to read failures first.
5. Reference 5: Data contracts - config, JSON, and schema contract surfaces.
6. Reference 6: File reference - ownership lookup for scripts and data.
7. Reference 7: Design principles - architecture rationale and guardrails.
8. Reference 8: Diagrams - visual flow and system boundaries.