Skip to content

Projects & Organization

Work at Sartiq is split across four YouTrack projects. Each project defines a boundary around a domain — not just for organizing issues, but for ownership, sprint planning, and reporting. Understanding where an issue belongs is the first decision you make when creating one.

The four projects

SAR — Core Product

Prefix: SAR- · Default Category: Product

SAR is the heart of the system — the Sartiq platform itself. This is where user-facing features, business logic, and the main application codebase live.

What belongs here:

  • Platform features (user management, billing, dashboards, shooting workflows)
  • API endpoints that serve the product
  • Frontend components, pages, and UX flows
  • Business logic and domain rules
  • Integrations with external services (payment, auth, notifications)

Examples: SAR-456 Add retry logic to image upload endpoint, SAR-789 Fix pagination in user listing API, SAR-1200 Implement team invitation flow

IDQ — Image & Data Quality

Prefix: IDQ- · Default Category: Product

IDQ covers everything related to the quality of images and data flowing through the platform. This includes GenAI pipelines, validation systems, scoring algorithms, and the tools that ensure output meets standards.

What belongs here:

  • Image processing and GenAI pipelines
  • Quality scoring and validation logic
  • Data pipelines (ingestion, transformation, enrichment)
  • Quality metrics and benchmarks
  • Guideline enforcement and compliance checks

Examples: IDQ-78 Implement background removal quality scoring, IDQ-112 Fix color profile mismatch in export pipeline, IDQ-150 Add batch validation for uploaded assets

SAR vs IDQ: If the issue is about what the user sees and does in the platform, it's SAR. If it's about the quality of the images and data the platform processes, it's IDQ. A button that triggers image processing is SAR. The algorithm behind that processing is IDQ.

OPS — Infrastructure & Tooling

Prefix: OPS- · Default Category: Infrastructure

OPS is where the engineering platform lives. Servers, pipelines, monitoring, developer tools — anything that keeps the system running and developers productive.

What belongs here:

  • CI/CD pipelines and GitHub Actions workflows
  • Docker, deployment, and environment configuration
  • Monitoring, alerting, and observability (Grafana, Prometheus, logging)
  • Developer tooling (scripts, CLI tools, local dev setup)
  • Database administration and migrations infrastructure
  • Security infrastructure (SSL, IAM, access control)

Examples: OPS-89 Set up staging environment for SAR, OPS-134 Add Grafana dashboard for API latency, OPS-200 Upgrade PostgreSQL to v16

Tip: If an engineer is the primary beneficiary of the work, it probably belongs in OPS. If a user is, it's SAR or IDQ.

LAB — Research & Experiments

Prefix: LAB- · Default Category: Research

LAB is the sandbox. Prototypes, spikes, evaluations, and anything that might not ship. Work here is exploratory — it's OK for LAB issues to conclude with "this approach doesn't work" as a valid outcome.

What belongs here:

  • Technology evaluations and proof-of-concepts
  • Model training experiments and benchmarks
  • Architecture spikes (testing a new pattern before committing to it)
  • Research into tools, libraries, or services
  • Experimental features not yet approved for production

Examples: LAB-12 Evaluate ControlNet for product shot consistency, LAB-34 Spike: replace Celery with Temporal for orchestration, LAB-67 Benchmark SDXL vs Flux for our use case

LAB → SAR/IDQ/OPS graduation: When a LAB experiment proves successful and is approved for production, create new issues in the target project (SAR, IDQ, or OPS) for the actual implementation. Reference the LAB issue for context. Don't move LAB issues — they stay as research records.

Issue ID format

Every issue gets a project-prefixed sequential ID: SAR-123, IDQ-45, OPS-312, LAB-7.

Always use the full ID when referencing issues:

  • In commit messages: fix(auth): resolve token refresh race condition (SAR-456)
  • In PR descriptions: link to the issue with the full ID
  • In documentation: reference specific decisions or context
  • In Slack/conversations: YouTrack auto-links IDs in connected channels

Decision guide

When you're not sure where an issue belongs:

Is this about the quality of images or data?
  → Yes: IDQ
  → No: continue

Is this about infrastructure, deployment, or developer tooling?
  → Yes: OPS
  → No: continue

Is this experimental or exploratory?
  → Yes: LAB
  → No: SAR

Another way to think about it: who cares about the outcome?

Stakeholder Project
End users, product managers SAR
Quality team, data scientists IDQ
Engineers, DevOps OPS
Nobody yet (it's research) LAB

Cross-project work

Some initiatives span multiple projects. For example, a new feature might need API work (SAR), quality validation (IDQ), and infrastructure changes (OPS).

In this case:

  1. Create an Epic in the primary project (usually SAR)
  2. Create subtasks in each relevant project
  3. The Epic tracks overall progress; subtasks track individual work

Legacy note

The original project prefix was SHO- (from the Shootify brand). It was renamed to SAR- during the Sartiq rebrand. Old references to SHO-* in documentation, commits, or conversations map to the same issues under SAR-*. YouTrack handles the mapping internally — old links still resolve.