> For the complete documentation index, see [llms.txt](https://experience-digital-transform.gitbook.io/experience-digital-transformation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://experience-digital-transform.gitbook.io/experience-digital-transformation/analytics/technical-specifications/5.-cross-cutting-requirements.md).

# 5. Cross-Cutting Requirements

Baseline non-functional requirements for the Analytics Building Block — privacy, reconciliation governance, audit logging, security, retention, availability, interoperability and measurability.

These are the non-functional requirements that apply across every Key Digital Functionality — the baseline every deployment must meet, tagged REQUIRED or RECOMMENDED throughout.

{% hint style="warning" %}
🛡️ **Treat REQUIRED as your conformance floor.** Every item below is explicitly tagged — there's no ambiguity about what a conformant deployment must do versus what merely strengthens it.
{% endhint %}

## 5.1 Data Privacy and Sensitive-Data Protection

* The Analytics BB must never store or process identifiable personal data. All PII must be masked, hashed, or pseudonymised by upstream ingestion, registry and Information Mediator layers before data enters the analytical environment. The Consent Building Block manages consent records and status only. <mark style="color:$danger;">**REQUIRED**</mark>
* Where a deployment involves no personal data (as is typical for climate and environmental datasets), the same confidentiality and access controls must be applied to any otherwise sensitive or access-restricted data, such as commercially licensed sources. <mark style="color:$danger;">**REQUIRED**</mark>
* The Building Block must comply with applicable national data-protection legislation and with the GovStack privacy principles. <mark style="color:$danger;">**REQUIRED**</mark>
* Data subjects must, where applicable, retain the right to inspect logs of accesses to their pseudonymised records. <mark style="color:$info;">**RECOMMENDED**</mark>

## 5.2 Reconciliation and Data-Quality Governance

* Reconciliation rules — matching logic, discrepancy thresholds and survivorship/blend rules — must be transparent, explainable and configurable by data stewards or business owners, not hard-coded. <mark style="color:$danger;">**REQUIRED**</mark>
* The Building Block must distinguish technical lineage (where data came from and how it was transformed) from business ownership and accountability (who validated a value and under which process it became the authoritative source of truth). <mark style="color:$danger;">**REQUIRED**</mark>
* Automated reconciliation must defer to governed human review where sources diverge beyond threshold or where institutional accountability is involved; every adjudication must be recorded as an append-only, reversible decision with a rationale and a named actor. <mark style="color:$danger;">**REQUIRED**</mark>
* A data-validation strategy must be defined covering functional (smoke) tests, consistency (sanity) checks, timeliness and freshness SLAs (monitoring pipeline latency and execution schedules) and end-to-end scenarios verifying the full data lifecycle from ingestion through reconciliation, storage, API exposure and downstream use. <mark style="color:$info;">**RECOMMENDED**</mark>

## 5.3 Audit Logging

* All data-access and decision events must be automatically logged with: record identifier, fields accessed, subject/record token (where applicable), requesting user identity and role, timestamp, and stated justification. <mark style="color:$danger;">**REQUIRED**</mark>
* All audit logs must be integrity-protected using cryptographic record chaining. No account, including super-administrative accounts, may modify or delete log entries. <mark style="color:$danger;">**REQUIRED**</mark>
* A role-based access model with segregation of duties must govern who may read, steward, reconcile and approve data, ensuring traceability and preventing unauthorised modification of audit information. <mark style="color:$danger;">**REQUIRED**</mark>
* Audit logs must be retained for a period consistent with national archiving policy (minimum 5 years recommended). <mark style="color:$info;">**RECOMMENDED**</mark>

## 5.4 Security Enforcement

* The Building Block must apply RBAC, ABAC, and PBAC controls at the query-execution layer, not solely at the application interface. <mark style="color:$danger;">**REQUIRED**</mark>
* The AI-assisted query module must enforce AST-level security inspection on every generated SQL query before execution, blocking all DML and DDL operations. <mark style="color:$danger;">**REQUIRED**</mark>
* All communications between the Analytics BB and other Building Blocks must use mutually authenticated, encrypted channels (TLS 1.2+). <mark style="color:$danger;">**REQUIRED**</mark>
* Broader platform security capabilities (encryption at rest, secrets management, network protection and threat monitoring) should align with the GovStack Security and Identity Building Blocks rather than being re-specified here. <mark style="color:$info;">**RECOMMENDED**</mark>

## 5.5 Retention, Backup, Recovery and Archival

* Data retention, backup and archival policies must be configurable per dataset and per logical layer, with automated archival to cold storage upon policy expiry. <mark style="color:$danger;">**REQUIRED**</mark>
* The Building Block must document whether historical versions are retained and, if so, the corresponding retention and lifecycle policies (append-only decision history must always be preserved). <mark style="color:$danger;">**REQUIRED**</mark>
* Recovery Point Objective (RPO) ≤ 1 hour and Recovery Time Objective (RTO) ≤ 4 hours are recommended for production analytical services, subject to national requirements. <mark style="color:$info;">**RECOMMENDED**</mark>

## 5.6 High Availability and Resilience

* The Building Block must achieve a 99.9% availability SLA for production analytical services. <mark style="color:$danger;">**REQUIRED**</mark>
* Infrastructure must be distributed across a minimum of three independent Availability Zones with automated failover, and should support geo-replication for multi-country deployments. <mark style="color:$danger;">**REQUIRED**</mark>

## 5.7 Interoperability and Integration

* All external interfaces must expose documented REST/OpenAPI-compliant APIs, with managed versioning, authentication and rate limiting. <mark style="color:$danger;">**REQUIRED**</mark>
* The Building Block must support integration with the GovStack Information Mediator Building Block for inter-BB data exchange, and must expose webhooks for event-driven notification when data is published, promoted or updated. <mark style="color:$danger;">**REQUIRED**</mark>
* Data schemas must follow open, version-controlled standards; proprietary formats are not permitted for inter-BB data exchange. <mark style="color:$danger;">**REQUIRED**</mark>
* The data layer should be modular and configurable by country, allowing national terminology, code sets and reporting to be adapted without changing the core specification, including version management for national taxonomies that must interoperate with a common reporting framework. <mark style="color:$info;">**RECOMMENDED**</mark>

## 5.8 Measurable Non-Functional Requirements

* The specification for a given deployment must quantify maximum concurrent users, data volume and growth, performance targets, geo-replication, backup and disaster recovery (RPO/RTO), high availability, monitoring and alerting, and log-retention periods, so the architecture can be sized to clear service-level expectations. <mark style="color:$info;">**RECOMMENDED**</mark>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://experience-digital-transform.gitbook.io/experience-digital-transformation/analytics/technical-specifications/5.-cross-cutting-requirements.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.