Operational requirements

1.1 Read-Only Access Principle

SelectZero is designed to operate exclusively in read-only mode against customer source systems. All database credentials configured in a SelectZero Connection must be provisioned with read-only (SELECT) privileges limited to the schemas and objects in scope for data quality monitoring, profiling, cataloging, and lineage analysis.

Specifically, the database user or service account assigned to a SelectZero Connection:

• Must be granted SELECT privileges only, on the relevant schemas, tables, and views;

• Must be granted access to the database system catalog / metadata views required for metadata synchronization (e.g., information_schema, or the platform-specific equivalent);

• Must not be granted INSERT, UPDATE, DELETE, TRUNCATE, DROP, ALTER, CREATE, or any other data- or schema-modifying privileges;

• Must not be granted administrative, superuser, or role-management privileges;

• Must not be shared with other applications, ETL processes, or interactive users.

SelectZero does not require and will not request write access to customer source systems at any point during installation, operation, or upgrade. All results, configurations, validation rules, and execution history are stored exclusively in the SelectZero repository database.

1.2 Credential Provisioning Checklist

Before configuring a Connection, the customer's database administrator should confirm:

2.1 Performance Impact Notice

Executing any query using SelectZero — whether a test case execution, a profiling execution, a reconciliation, or a metadata synchronization — allocates compute resources from the target database defined in the Connection and can have an effect on the performance of that database. SelectZero submits standard SQL queries to the customer's database engine; the resource cost of those queries (CPU, memory, I/O, temporary space, concurrency slots) is borne by the customer's database environment, subject to the workload management configuration of that environment.

The magnitude of the impact depends on factors under the customer's control, including: the size and structure of the objects being profiled or validated, the complexity of configured test cases, execution schedules, the concurrency settings of the Connection, and the workload management policy applied to the SelectZero service account.

2.2 Required Workload Isolation

To ensure predictable performance for both SelectZero and the customer's other workloads, the SelectZero Connection account must be assigned to a dedicated, resource-limited workload management construct in the target database, for example:

• Vertica: a dedicated resource pool with defined MEMORYSIZE, MAXMEMORYSIZE, MAXCONCURRENCY, and RUNTIMECAP appropriate to the environment;

• Snowflake: a dedicated warehouse (sized and auto-suspended appropriately), with statement timeout parameters set;

• PostgreSQL: a dedicated role subject to resource queues / resource groups and statement_timeout;

• Other platforms: the equivalent workload management, resource governor, or query-governance mechanism.

Assigning the SelectZero account to an unrestricted or shared default resource pool is not a supported configuration.

2.3 Scheduling Requirements

The customer is responsible for aligning SelectZero execution schedules with its own operational calendar. The Supplier recommends that the customer:

• Schedule full-table profiling executions and large reconciliations outside business-critical processing windows (e.g., end-of-day batch, month-end close, regulatory reporting production runs);

• Introduce new test cases and profiling jobs incrementally, observing resource consumption before scaling out schedules;

• Use sampling and incremental validation options where full-volume scans are not required;

• Review Connection concurrency settings together with the database administrator responsible for the target environment.

Performance degradation of the target database arising from execution schedules, concurrency settings, or workload management configurations chosen by the customer, or from deviation from the requirements in Section 2.2, does not constitute a defect or malfunction of the Application.

3.1 Customer Backup Responsibility

The SelectZero repository database is deployed self-hosted within the customer's environment, and the customer is solely responsible for backing it up. The repository contains all customer-created content: Connections and their configurations, test cases and validation rules, profiling definitions, glossary content, catalog annotations, and execution history. Loss of the repository without a restorable backup is not recoverable by the Supplier.

The customer is responsible for:

• Including the SelectZero repository database in its regular backup schedule, in accordance with the customer's internal backup and recovery policies;

• Verifying that repository backups are restorable, at intervals consistent with the customer's business continuity requirements;

• Retaining backups for as long as the customer's recovery and retention policies require (see Section 3.2 regarding the limited retention of automatic SQLite backups);

• Taking a backup before applying any version upgrade, and retaining it until the upgrade has been verified in accordance with Section 3.4.

3.2 SQLite Repositories

When the repository runs on the default SQLite database, the application creates an automatic backup once per day, stored under database/backups. Automatic backups are retained for 7 days only — older automatic backups are deleted automatically. For any retention period longer than 7 days, the customer must copy the backup files to its own backup storage.

Manual backups can be created, restored, exported, and deleted at any time from Database settings; manual backups are not subject to the 7-day automatic cleanup. The automatic daily backup is a convenience only and does not replace the customer's own backup regime.

3.3 PostgreSQL Repositories

When the repository is configured to run on the customer's own PostgreSQL database, SelectZero performs no automatic backups. The customer must back up the repository database entirely with its own tooling (e.g., pg_dump or the customer's standard database backup infrastructure), on a schedule and with a retention period consistent with its backup and recovery policies.

3.4 Upgrades and Post-Upgrade Verification

Before applying any version upgrade, the customer must take a backup of the repository database (or, on SQLite, verify that a sufficiently recent backup exists and copy it out of the 7-day automatic rotation). After each upgrade, the customer should verify that Connections, test cases, and scheduled executions operate as expected before discarding the pre-upgrade backup. Any discrepancy should be reported through the agreed support channel without undue delay, and in any case before the next scheduled upgrade, so that restoration from the pre-upgrade backup remains available as a remediation path.