# Artifact Registry - Database Tooling Evaluation Framework > **Scope:** Both query tooling (Go package for interacting with Postgres) and migration tooling > (in-app and/or schema migration framework) for the Artifact Registry service. --- ## Hard Disqualifiers *Fail any one of these = rejected immediately, no further evaluation.* | # | Criterion | Why | |---|-----------|-----| | D1 | Low maintenance or no active community | Infrastructure-level tooling that goes unmaintained becomes a long-term liability. See **D1 Health Signals** below for specific measurable checks. A tool exhibiting two or more signals fails this criterion. | | D2 | No Postgres support or materially incomplete Postgres feature support | The artifact registry schema will likely use hash partitioning, partial indexes, JSONB, and CHECK constraints from day one. A tool that cannot express these forces workarounds that erode the value of using the tool at all. | | D3 | PgBouncer transaction pooling incompatible with no workaround | GitLab.com routes all connections through PgBouncer in transaction pooling mode. Server-side prepared statements break in this mode. Any tool that cannot be configured to use simple query protocol (e.g. `QueryExecModeSimpleProtocol` or DSN-level config) is dead on arrival for GitLab.com deployment. | | D4 | Migration tooling: CLI-only, no embeddable library mode | The project requires in-app migrations with no external process or orchestrator. A CLI-only tool reintroduces the external coordination dependency the project explicitly wants to avoid. | | D5 | Query tooling: bypasses LabKit v2's pgx-level OTel tracing, or replaces the pgx driver with one that has no `QueryTracer` support | LabKit v2 implements per-query distributed tracing via pgx's `QueryTracer` interface (https://gitlab.com/gitlab-org/labkit/-/merge_requests/340). Any query tool operating through the `database/sql` wrapper inherits per-query OTel spans automatically - no instrumentation required. A tool only fails this criterion if it replaces the pgx driver entirely with an alternative that has no `QueryTracer` support, or executes queries through a separate connection that bypasses LabKit v2's pool. Tools using `database/sql` pass automatically. | ### D1 Health Signals to Verify A tool fails D1 if it exhibits **two or more** of the following signals. A single signal warrants a note in the evaluation but is not alone a disqualifier. - **Commit frequency:** No meaningful commits in the last 6 months - **Issue health:** High open/closed issue ratio with stale, unresponded issues - especially bug reports and security disclosures left unacknowledged for weeks - **Contributor breadth:** Effectively a single-maintainer project with no succession plan or org-level ownership (bus factor of 1) - **Corporate backing:** No corporate sponsor, no funded team, and no evidence of paid maintenance - community-only projects with a single author are high-risk for infrastructure-critical dependencies - **Adoption:** Not used by any notable production projects; no integrations with major ecosystem tooling (CI systems, cloud providers, ORMs); low downstream dependents on pkg.go.dev or equivalent - **CVE response:** History of slow or absent responses to disclosed vulnerabilities **Judgement note on solo-maintainer community tools:** Two signals (solo maintainer + no corporate backing) trigger a D1 flag, but should not be a mechanical DQ for established tools with a demonstrable multi-year track record, consistent release cadence, and meaningful adoption. The intent of D1 is to reject unmaintained or abandoned tools - not to penalise well-maintained community projects with one dedicated author. When these two signals co-occur without the others (no commit slowdown, no stale issues, no adoption gap), the evaluation should document the risk explicitly and set concrete re-evaluation criteria rather than rejecting the tool outright. --- ## Section A - Migration Tooling ### A1. SQL Expressiveness *Can the tool express everything this [schema](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/18456) needs?* - Supports `CREATE INDEX CONCURRENTLY` without wrapping or escaping - Supports hash partitioning DDL (`PARTITION BY HASH`, `CREATE TABLE ... PARTITION OF`) - Supports partial indexes (`WHERE` clause on index definition) - Supports `CHECK` constraints and `ON CONFLICT` clauses - No DSL that silently rewrites or limits raw Postgres DDL > **Why this was added:** The blob storage tables (`blob_storage_blobs`, `blob_storage_attachments`) > are hash-partitioned by `organization_id` from day one (ADR-[007](https://gitlab.com/gitlab-com/content-sites/handbook/-/blob/16f10d5dbce36b3d5e2e202b8a6a97162f4e9110/content/handbook/engineering/architecture/design-documents/artifact_registry/decisions/007_database_schema.md), 16 initial partitions). The > schema also uses partial unique indexes (e.g. `sha1 WHERE sha1 IS NOT NULL`) and CHECK > constraints for mutual exclusivity in virtual repository upstreams. Post-deployment migrations > will need `CONCURRENTLY` to index large tables without locking. A tool that cannot express these > natively forces raw SQL escaping or splitting migrations across multiple tools - both fragile at > scale. **Weight: Critical** --- ### A2. In-App Execution *Can migrations run inside the application process without an external CLI?* - Embeddable as a Go library (importable, not shelled out) - Migration runner can be invoked programmatically at startup or in the background - No hard dependency on a separate binary or external process > **Why this was added:** A strong preference for running migrations inside the > application, either at startup (pre-deployment) or in the background (post-deployment and > batched). Relying on an external CLI or process introduces an external coordination dependency > the project explicitly wants to avoid. **Weight: Critical** --- ### A3. Distributed Multi-Instance Coordination *Can multiple independent app instances coordinate safely without an external orchestrator?* - Uses **transaction-level** advisory locks (`pg_advisory_xact_lock`) - not session-level (broken in PgBouncer transaction mode) - Guarantees exactly one runner wins across concurrent instances - Non-winning instances either wait or skip gracefully - no crash, no double-apply - No external lock store (Redis, etcd, etc.) required > **Why this was added:** The deployment model of runway is rolling deploys with independently starting > instances and no external orchestrator. Multiple instances will attempt to run migrations > simultaneously at startup. Without distributed locking, migrations double-apply. > Session-level advisory locks (`pg_advisory_lock`) are explicitly broken under PgBouncer > transaction pooling mode - only transaction-level advisory locks (`pg_advisory_xact_lock`) are > safe here. This is a constraint that narrows the solution space significantly. However we can (and likely should) always avoid running schema migrations via PgBouncer as that's a known anti-pattern that could lead to disaster and instead consider establishing a direct session based connection with the database) **Weight: Critical** --- ### A4. Migration Type Coverage *Does the tool natively address what the three migration tiers were solving?* | Migration tier | What it requires | |---|---| | Pre-deployment | Blocking, must complete before app serves traffic | | Post-deployment | Long-running, non-blocking, can be deffered, safe to run while app is live (`CONCURRENTLY`, large table operations) | | Background/batched | Incremental data migrations over hours/days/weeks, throttled, resumable, progress-trackable | | **Post-deployment via background framework** | Whether the background framework can absorb post-deployment DDL semantics - running `CREATE INDEX CONCURRENTLY` and similar as retryable, progress-tracked jobs, collapsing the post-deployment and background tiers into one | Score each tool against each tier: - **Native support** - the tool models this explicitly - **Achievable** - possible with minor configuration or wrapping - **Gap** - requires building custom infrastructure around the tool > **Why this was added:** The three-tier migration model was not a deliberate architectural > choice - it was an emergent workaround built because no single tool covered all three scenarios. > The container registry project had to build a custom wrapper around [sql-migrate](https://github.com/rubenv/sql-migrate) package, a custom background > migration framework (that mirrors GitLab.com's - to some degree), and a DAG abstraction to coordinate across all three. The goal here is to > find a tool (or combination) that collapses this complexity natively. A tool that natively > handles all three tiers scores highest; one that only handles one tier reintroduces the same > burden. If a tool does away with the three-tier model entirely through a better abstraction > (e.g. expand/contract natively), that is a positive signal. > > An additional positive signal: whether the background migration framework can absorb > post-deployment semantics entirely. If it can run arbitrary Postgres DDL as jobs - e.g. a > [River](https://github.com/riverqueue/river) job executing `CREATE INDEX CONCURRENTLY` in a controlled, retryable, progress-tracked > manner - the post-deployment tier ceases to be a separate concern. It becomes a subset of the > background framework with DDL as the payload. This collapses the model to two tiers: a schema > migration tool (pre-deployment) and a background framework (post-deployment DDL + batched data > migrations). A combination that achieves this scores maximum on this criterion. **Weight: Critical** --- ### A5. Dependency Management *Can migrations declare ordering dependencies on other migrations?* - Migrations can express DAG-style dependencies (not just linear sequence) - Dependencies can span migration types (e.g. background migration B cannot start until post-deployment migration A completes) - Dependency violations are caught before execution, not during > **Why this was added:** In the container registry project, coordinating dependencies across the three > migration tiers required building a custom DAG abstraction - one of the most painful parts of > the homegrown framework. Dependencies between tiers are real: a background data migration cannot > efficiently run until the column it paginates over has the necessary indeces - typically a a post-deployment migration - and a post-deployment migration can not safely start until a pre-deployment migration adds the column that needs indexing. Without native > dependency management, that coordination burden returns. **Weight: High** --- ### A6. Rolling Deploy Safety *Is the tool safe for environments where old and new app versions run simultaneously?* - Enforces or encourages backward-compatible (expand/contract) migration patterns - Does not apply destructive schema changes while old app version is still serving traffic - Forward-only philosophy ? - no reliance on down migrations in production > **Why this was added:** The deployment model is rolling deploys, meaning old and new versions > of the application coexist during every release. A migration that drops a column the old version > still reads will cause immediate failures in the instances that haven't yet rolled over. > Best practice is the expand/contract pattern - additive changes first, destructive changes only > after full rollover - and forward-only migrations in production. Down migrations in production > are dangerous, rarely tested, and often impossible to write safely for data-destructive changes. **Weight: High** --- ### A7. Migration Format Readability *Can you understand what a migration does without deep knowledge of the tool?* - The migration format is self-describing - intent is clear from reading the file, not from cross-referencing tool documentation - Plain SQL is the ceiling (maximally transparent), but structured formats (HCL, JSON DSL) are acceptable if the operations are legible without a reference manual - Code-based migrations (Go functions) are acceptable as an escape hatch for logic that cannot be expressed in a declarative format - A reviewer or AI agent encountering the file for the first time can reason about what schema change it produces > **Why this was added:** > The underlying concern is readability and reviewability across a large contributor base, not > the file format itself. A well-structured declarative format (e.g. pgroll's JSON operations or > Atlas HCL) can be as readable as SQL for common DDL - the key test is whether a reviewer can > understand the migration's intent without running the tool. Plain SQL remains the highest score > because it requires zero tool knowledge, but structured formats that clearly express schema > intent score 2. **Weight: High** --- ### A8. Operational Visibility *Can you tell what has run, what is pending, and what failed?* - Migration state stored in Postgres (no external state store) - Clear audit trail: which migrations ran, when, on which instance - Failed migrations are surfaced clearly with actionable error messages - Background migration progress queryable (percentage complete, estimated finish) > **Why this was added:** Background batched migrations can run for days or weeks across millions > of records. Without progress visibility it is impossible to know whether a migration is healthy, > stalled, or silently failing. Pre and post-deployment migrations also need clear state tracking > across multiple independent instances to confirm all nodes have completed before the next phase > proceeds. Storing this state in Postgres (rather than an external store) keeps the system > self-contained and consistent with the no-external-orchestrator requirement. **Weight: Medium** --- ### A9. Non-Transactional Migration Support *Can individual migrations opt out of the default transaction wrapper?* - Per-migration directive to disable transaction wrapping (e.g. goose `-- +goose NO TRANSACTION`, Atlas `atlas:nontransactional`) - Tool does not silently ignore or error on non-transactional DDL when a transaction wrapper is active - Non-transactional migrations are isolated - a failure does not leave a partial transaction open - Clear documentation and error messaging when non-transactional mode is required > **Why this was added:** Postgres prohibits several DDL statements inside a transaction: > `CREATE INDEX CONCURRENTLY`, `DROP INDEX CONCURRENTLY`, `ALTER TYPE ... ADD VALUE` (pre-PG12), > and others. Migration tools wrap each migration in a transaction by default for safety. Without > a per-migration escape hatch, these statements fail at runtime - forcing manual intervention > and breaking the hands-off migration model. Given that long-running index creation on the > hash-partitioned blob storage tables (`blob_storage_blobs`, `blob_storage_attachments`) will be > a regular operation, and that the background framework may also execute DDL jobs, this is a > required capability, not an edge case. **Weight: Critical** --- ## Section B - Query Tooling ### B1. PgBouncer Compatibility *Does the tool work correctly in PgBouncer transaction pooling mode?* - Does not use server-side prepared statements by default - Supports `QueryExecModeSimpleProtocol` or equivalent - Configurable via DSN query string as a fallback - No hidden session-state assumptions (temp tables, `SET LOCAL`, `LISTEN/NOTIFY`) > **Why this was added:** GitLab.com routes all database connections through PgBouncer in > transaction pooling mode. Server-side prepared statements - used by default by most query > tooling - break in this mode because the connection is not held for the duration of a session. > The Container Registry project solved this using pgx's `QueryExecModeSimpleProtocol`. > Any query tool that cannot be configured to avoid server-side prepared statements, either > programmatically or via DSN, cannot be deployed on GitLab.com. This is a runtime correctness > issue, not a performance preference. > > **Open gap in LabKit v2:** `QueryExecModeSimpleProtocol` support is tracked as a follow-up > in LabKit v2 issue https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/work_items/4291 and is not yet implemented as of https://gitlab.com/gitlab-org/labkit/-/merge_requests/340. Until https://gitlab.com/gitlab-org/quality/quality-engineering/team-tasks/-/work_items/4291 lands, query > tooling must be independently configurable to disable server-side prepared statements - either > via pgx connection config applied before the `pgx/v5/stdlib` adapter, or via DSN parameter. > Do not assume LabKit v2 handles this automatically. **Weight: Critical** --- ### B2. Interface Compatibility with LabKit v2 *Does the tool work with LabKit v2's confirmed `*sql.DB` interface?* - LabKit v2 exposes `*sql.DB` via `pgx/v5/stdlib` - confirmed in https://gitlab.com/gitlab-org/labkit/-/merge_requests/340. Tools must be compatible with the `database/sql` interface. - Tools that require direct `pgxpool.Pool` access without a `database/sql` path are not compatible with LabKit v2 and fail this criterion > **Why this was added:** LabKit v2 is the shared library all Go satellite services will depend > on. The POC assessment identified the interface choice (pgxpool vs database/sql) as the single > most cross-cutting open decision - query tooling evaluated against the wrong interface would > produce a false recommendation. https://gitlab.com/gitlab-org/labkit/-/merge_requests/340 settled this: LabKit v2 exposes `*sql.DB` via > `pgx/v5/stdlib`. **Weight: Critical** --- ### B3. Query Mistake Prevention *How well does the tool catch query mistakes before they reach production?* This criterion uses a graduated scale rather than a pass/fail check. Score against the highest level the tool achieves: - **Score 3 - Compile-time:** Column names, types, and query structure validated at build or codegen time. Wrong column fails `sqlc generate` or schema regeneration. Schema changes that break queries surface in CI before any code runs. No reliance on test coverage for correctness. - **Score 2 - Test-time with real DB:** Query predicate columns are string-based, but the project's real-Postgres test suite (testcontainers-go, per-test rollback, CI-enforced) catches column reference errors before merge. Return types are strongly typed Go structs - result mapping is compile-time safe; predicate construction is not. - **Score 1 - Runtime only:** No compile-time or systematic real-DB test guarantee. Errors reach production under load or in low-coverage code paths. - **Score 0 - No guardrail:** Raw string queries, untyped results, no structural type checking. > **Why this was added:** Most code in this codebase will likely be co-ordinated with AI agents, and the > contributor base is expected to be large with varying levels of SQL fluency. The tooling itself > must enforce correctness - a query that references a non-existent column or passes the wrong > type should fail the build, not fail in production. Runtime column reference errors caught by a real-DB test suite are also > a meaningful safety net, even if they are a step down from compile-time catching. The > criterion rewards compile-time safety with the highest score while recognising test-time > safety as a legitimate, lower-score alternative. Tools with no safety net at either level > score 0 and remain clearly undesirable. **Weight: Critical** --- ### B4. Dynamic Query Building *Can optional filters, multi-table joins, and keyset pagination be composed without complexity ?* - Optional filter conditions can be added/omitted without string concatenation or manual parameter indexing - Multi-table joins are expressible without raw string assembly - Keyset pagination (`WHERE (col_a, col_b) > ($1, $2)`) is natively supported or straightforwardly expressible - `organization_id` as mandatory partition key on every query is enforceable or naturally falls out of the pattern > **Why this was added:** Dynamic filtering across many optional fields and tables is a core > query-layer pain point from the container registry project - it produced a proliferation of complex > if-statement chains to build queries conditionally. The schema has multi-format artifact tables, > cross-table joins through blob storage, and API surfaces that > requiring flexible filtering for various data views. Keyset pagination (not offset) is required for correctness and > performance at large sets of rows. A tool that cannot compose queries dynamically in a > clean, type-safe way reintroduces the same problem. **Weight: Critical** --- ### B5. SQL Transparency and Predictability *Is the SQL the tool generates visible, predictable, and reviewable?* - Generated SQL is inspectable (loggable, testable against `EXPLAIN ANALYZE`) - No surprising query rewrites or hidden N+1 patterns - A code reviewer or AI agent can reason about the SQL a query produces by reading the Go code - No "magic" that makes query review unreliable > **Why this was added:** With AI agents writing code and a large open contributor base, code > review is the last line of defence against bad queries reaching production. If the SQL a tool > generates is opaque or unpredictable, reviewers cannot catch N+1s, missing partition key > filters, or full table scans in code review - they only surface under load. At tens of millions > of rows with a read-heavy public workload, a single query that bypasses partition pruning or > misses an index can cause serious degradation. Transparency is what makes type safety meaningful > at review time. **Weight: High** --- ### B6. Postgres-Specific Feature Support *Does the tool support the Postgres features this schema actually uses?* - JSONB column querying and filtering (`rule_configuration` in lifecycle rules, `package_json` in npm_versions) - Partial index awareness (queries against `sha1 WHERE sha1 IS NOT NULL` use the right index) - Hash-partitioned table queries always include `organization_id` (partition pruning) - `ON CONFLICT ... DO UPDATE` (upsert) support for cache entries - `RETURNING` clause support - No forcing of `SELECT *` - only fetch columns needed > **Why this was added:** The schema is Postgres-specific by design - JSONB for variable artifact > manifests and lifecycle rule configuration, partial indexes for nullable hash fields, hash > partitioning for blob storage scale, and upserts for cache entry management in virtual > repositories. A tool that abstracts these away or cannot express them forces fallback to raw SQL > for a significant portion of the codebase, undermining the consistency and type safety benefits > of having a query tool at all. **Weight: High** --- ### B7. Testability *Does the tool work cleanly against a real Postgres instance in tests?* - No special test-mode scaffolding required - same code runs in tests and production - Compatible with transaction-rollback test isolation pattern - Does not encourage or require mocking the database layer > **Why this was added:** Best practice for Go database testing is to run against a real Postgres > instance - mocking the database layer gives false confidence and misses the things that matter: > query correctness, constraint violations, index behaviour, and partition pruning. The test suite > should spin up real Postgres, apply migrations, and wrap each test in > a transaction that rolls back. A tool that requires overly-complicated or special test-mode configuration or > encourages mocking is working against this and hiding the very bugs the tests are meant to catch. **Weight: High** --- ### B8. Code Review and AI Codegen Friendliness *Does the tool produce consistent, auditable patterns safe to generate and review at scale?* - Consistent, predictable patterns across the codebase regardless of who or what wrote the query - Type safety acts as a guardrail catching AI codegen mistakes at compile time - Schema-aware - generated code breaks loudly when the schema changes - Low surface area for subtle performance bugs to slip through unnoticed > **Why this was added:** The contributor model for this project is explicitly large and > AI-heavy. Unlike a small team where tribal knowledge compensates for tooling gaps, a large open > contributor base and AI-generated code require the tooling to enforce patterns consistently. If > the tool allows many ways to express the same query, AI agents produce inconsistent patterns > that are harder to review. If the tool is schema-aware, a schema change that breaks a query > surfaces in CI rather than in a production incident. **Weight: High** --- ### B9. Distributed Query Tracing *Does the tool inherit LabKit v2's pgx-level query tracing without bypassing it?* - Operates through the `database/sql` interface, thereby inheriting per-query OTel spans from pgx's `QueryTracer` automatically (zero instrumentation required from the tool itself) - Does not execute queries through a separate, untraced connection or driver that bypasses LabKit v2's pool - Does not require additional instrumentation boilerplate to achieve per-query spans - tracing is a zero-config consequence of using LabKit v2's connection - Span attributes (query text, duration, error status) are emitted at the pgx driver layer and visible in the OTel Collector → Tempo pipeline > **Why this was added:** This criterion enforces D5. https://gitlab.com/gitlab-org/labkit/-/merge_requests/340 moved query tracing from > "tool responsibility" to "LabKit v2 responsibility" - tracing is implemented via pgx's > `QueryTracer` interface at the driver level, below the `database/sql` abstraction. > Any tool that operates through `database/sql` inherits per-query OTel spans automatically > and passes this criterion. A tool only fails if it replaces the pgx driver with an > untraced alternative, making all database queries invisible as an undifferentiated blob of > "database time" on the parent span. On a read-heavy public registry, per-query trace spans > are the primary signal for diagnosing which specific queries contribute to latency. **Weight: Critical** --- ### B10. Application-level Metrics *Can application-level database metrics be exposed in a Prometheus-compatible format?* - Query duration histograms (beyond what `pg_stat_statements` captures at the DB level) - Connection pool utilization (active, idle, waiting connections) - Error rates per query type > **Why this was added:** Runway handles infrastructure-level observability, but > application-level metrics - query duration distributions, pool saturation, per-query error > rates - are not fully captured by `pg_stat_statements` alone. This is not a blocking > requirement - Runway's stack handles the baseline and D5/B9 cover distributed tracing - but > a tool that exposes Prometheus metrics natively saves instrumentation work and gives earlier > signal on query performance regressions. **Weight: Medium** --- ### B11. GraphQL-style Field Selection and Relationship Traversal *Can the tool support dynamic column selection and relationship traversal without N+1 queries?* - Ability to select a subset of columns based on the incoming request (avoid `SELECT *` when only a few fields are needed) - Ability to resolve related entities (e.g. a container image with its tags and blobs) in a single query or a controlled batch - no implicit N+1 - Compatible with or extensible to GraphQL resolver patterns - Useful for building flexible API surfaces that AI agents can consume predictably > **Why this was added:** There's a high chance we will need to support GraphQL queries on the Artificat Registry backend (See: https://gitlab.com/gitlab-org/gitlab/-/issues/591887#note_3123837463) **Weight: Nice to Have** --- ## Candidate Matrix ### Migration Tooling | Tool | Notes | |---|---| | **goose** | Widely used, plain SQL + Go migrations, in-app library mode | | **Atlas** | Declarative schema, HCL/SQL, versioned + declarative modes | | **pgroll** | Postgres-native, expand/contract built-in, multi-version schema, pgroll is relatively new | | **pgschema** | Declarative, Terraform-style diff-based | | **River** (`riverqueue/river`) | Postgres-native background job queue; candidate for absorbing post-deployment DDL + batched data migration tiers into one framework | | `ADD ME` | .... | ### Query Tooling | Tool | Notes | |---|---| | **sqlc** | SQL-first codegen, pgx native, already used in go-service-template | | **Ent** | Schema-first ORM, requires `database/sql` | | **Bun** | Query builder + ORM, `database/sql` compatible; weaker type safety than sqlc or jet remains | | **go-jet/jet** | Type-safe query builder, `database/sql` native | | **bob** (`stephenafamo/bob`) | Solo maintainer risk remains. No hardened release. | | `ADD ME` | .... | ### Mix-and-Match Combinations Worth Evaluating | Combination | Rationale | |---|---| | `sqlc` + `goose` | Both present in go-service-template baseline; lowest friction starting point | | `sqlc` + `Atlas` | Atlas manages schema state declaratively, sqlc handles query layer | | `sqlc` + `pgroll` | pgroll's expand/contract model may eliminate the three-tier migration need entirely | | `go-jet/jet` + `goose` | jet's dynamic query building vs sqlc's SQL-first codegen approach | | `go-jet/jet` + `Atlas` | Declarative schema management paired with type-safe dynamic queries | | `sqlc` + `Atlas` + `River` | Atlas for pre-deployment schema migrations; River for post-deployment DDL jobs + batched data migrations; sqlc for query layer - the combination most likely to collapse three tiers to two | | `go-jet/jet` + `Atlas` + `River` | Same migration stack as above with jet replacing sqlc for dynamic query building | | `ADD ME` | .... | --- ## Scoring Rubric Apply this to each candidate or combination: | Score | Meaning | |---|---| | **3** | Fully met natively, no workaround needed | | **2** | Met with minor configuration or wrapping | | **1** | Partially met, requires non-trivial custom work | | **0** | Not met, gap remains | | **DQ** | Disqualifier triggered - stop evaluation | Sum scores per section. A combination scores as the sum of both tools, with gaps penalized where they create integration friction between each other.