5 Operations
Operational responsibilities are split between customer-owned systems and Quiver-managed integration infrastructure.
5.1 Responsibilities
| Area | Customer | Quiver |
|---|---|---|
| Source system availability | Owns uptime and maintenance windows | Consumes source access according to agreed schedule and alerts when unsuccesful |
| Data delivery | Delivers agreed files or exposes agreed source interfaces | Receives, extracts, validates, and loads agreed datasets |
| Synchronization monitoring | Receives escalations when source-side action is required | Monitors scheduled runs and investigates failures |
| Data scope | Defines and approves the business scope and filtering rules | Applies agreed connector-side or mapping-layer filters where approved |
| Data model changes | Communicates upcoming source-side changes | Updates connector and mapping logic |
| Security and access control | Provides approved source-system access and communicates access changes | Applies least-privilege access, secure credential handling, and encrypted transport |
5.2 Monitoring
Quiver monitors scheduled synchronization jobs and reviews failures caused by authentication, source availability, missing deliveries, schema changes, data validation issues, and destination write issues.
Monitoring also includes data freshness checks and validation against large unexpected changes in data volume. These checks are used to identify missing deliveries, stalled synchronizations, schema changes, or unusually large changes in the amount of data received from a source system.
Checks are agreed during the integration phase, and typical checks include:
- Connectivity and authentication checks.
- File presence or source endpoint availability checks.
- Schema and required-field checks.
- Freshness checks against the agreed delivery cadence.
- Row-count and data-volume change checks.
- Duplicate or conflicting external-reference checks where relevant.
- Business-rule checks for dates, quantities, statuses, and missing dimension mappings.
Quiver can include customer contacts in relevant alerts when the customer wants direct visibility into source-side or delivery-side issues. Any validation issues will be shown in the application, so users are aware of synchronization issues.
5.3 Data Isolation And Location
Data is stored in a customer-specific isolated namespace in Google Cloud. Unless otherwise agreed, Quiver’s default hosting location is Germany.
5.4 Security Operations
Quiver operates the integration with a least-privilege access model. Production access is limited to authorized personnel and services that require access for implementation, monitoring, support, or maintenance.
Credentials and access tokens are handled through managed secret storage and are rotated or revoked when access changes are required. Customer-side access should be scoped to the agreed source systems, datasets, and environments.
Traffic between systems is encrypted in transit. Where the integration uses APIs, databases, or file transfer, the selected access method must support secure transport and authentication suitable for production use.
Google Cloud infrastructure is configured and operated in alignment with Google Cloud recommendations for identity and access management, network security, service configuration, and separation of customer data.
5.5 Change Management
The customer should notify Quiver before source-side changes are introduced to production. This includes changes to file layouts, API fields, source table schemas, status codes, units of measure, naming conventions, filters, credentials, network access, or delivery schedules.
Quiver will assess whether a connector or mapping change is required and will coordinate implementation and validation before the change is treated as production-ready.
5.6 Escalation
Escalation contacts and communication channels are confirmed during implementation.