Saudi data lifecycle evidence for analytics and AI review

A source table can be governed while its derived data is not. An approved record is copied into a warehouse, joined into a metric, transformed into a model feature, embedded into a vector index, exported into a notebook, or cached inside a service. Months later the source is corrected, an access decision changes, or a retention instruction reaches the primary store. The derived assets continue because nobody can answer which version they contain or who owns their revalidation.

For analytics and AI, the data lifecycle must extend from the governed source version to the consuming decision. A review should connect source authority, transformation code, semantic meaning, feature or vector derivation, training or evaluation sets, model and dashboard versions, user authorization, quality cases, withdrawal propagation, and operating ownership. It should show expected and observed behavior at each edge.

Saudi public material gives this review a specific institutional setting. The SDAIA overview provides official data, AI, and governance context. The National Data Management Office page presents data-management and lifecycle-oriented institutional themes, while the National Strategy for Data and AI offers high-level strategy context. The NCA Data Cybersecurity Controls page identifies a specific cybersecurity review input.

None of those sources certifies a platform or turns this article into a Saudi control interpretation. Qualified customer legal, privacy, data-governance, records, cybersecurity, cloud, procurement, and sector reviewers decide applicability and acceptance for the actual workload.

Review a lineage case, not an abstract platform

Choose one decision path: a management metric, risk score, service forecast, recommendation input, document classifier, anomaly signal, model evaluation slice, or other bounded analytical output. Give it a case ID and version. Identify the user, business decision, consequence, source records, derived assets, executable jobs, serving interface, and human or system authority.

State scope and exclusions. A model may consume hundreds of fields, but one case can follow the critical ones that affect a named result. A dashboard may contain many measures, but review one metric through its source periods and adjustments. This narrow grain lets teams execute correction, access, and withdrawal tests rather than presenting a catalog screenshot.

The boundary includes offline paths: development snapshots, feature experiments, evaluation corpora, notebooks, exports, intermediate tables, vector indexes, model artifacts, cached predictions, logs, and backup or replay data. If their discovery is incomplete, record the gap and owner. An unverified lineage edge is not evidence of absence.

Assign identities to source and derived assets

Every source snapshot needs a source ID, owner, authority state, classification supplied by the customer, permitted-purpose reference, access policy version, schema, effective period, revision state, checksum or reproducible query, and lifecycle decision. Derived assets need equally precise identities: transformation build, metric-definition version, feature-definition version, embedding model and chunking configuration, training-set build, evaluation-set build, model version, and serving configuration.

Do not use “latest” as lineage. A pipeline can resolve a moving alias at run time, but the evidence record should preserve what it actually read. Where a managed data source or service cannot expose an immutable build, store retrieval time and available source identifiers, then identify the uncertainty and revalidation trigger.

Lineage should also identify meaning. A field renamed without semantic change differs from a category redefined under the same label. Preserve source notes and domain-owner decisions. Engineering can detect diffs; a qualified data or business owner decides whether historical comparison, feature reuse, or retraining remains valid.

Text equivalent: analytics and AI lineage case register

The diagram is fully represented by the table below. It is the structured alternative and a practical minimum register for a single case.

Trace analytics meaning through transformations

For a metric, record grain, population, period, units, numerator, denominator, exclusions, missing-value treatment, revision handling, reference data, timezone or calendar where relevant, and effective date. Bind the definition to executable query or code. Test with approved fixtures and reconcile selected outputs to source records or aggregates.

Record manual adjustments as transformations. Include owner, reason, affected period or keys, input evidence, reviewer, expiry, and reversal. An unexplained spreadsheet upload breaks lineage even if the warehouse later stores it cleanly. If the business needs an override, make it visible and reviewable.

Quality evidence should be decision-sensitive: duplicate entity-period keys, broken reference mappings, discontinuities, unexplained revisions, invalid units, changed coverage, and stale dimensions. Store expected and observed results for each case. Product owners set thresholds and acceptance based on consequence; this article does not supply universal Saudi thresholds.

Forward lineage matters when a source changes. Query which metrics, dashboards, extracts, features, evaluation sets, model versions, vector indexes, and services depend on the affected version or field. Reverse lineage matters when a user disputes an output. The team should find the source, transformation, configuration, exception, and owner that produced it.

Treat features and vectors as governed derived data

A feature store can multiply copies across offline and online serving. Record source-field mapping, window, aggregation, imputation, normalization, point-in-time behavior, materialization job, freshness observation, and consumers. Test that training and online serving apply compatible definitions where the use case requires it. A matching feature name does not prove matching values.

Vector assets add extraction and embedding dependencies. Record document or record source, version, fields included, chunking or serialization configuration, embedding model identifier, metadata, entitlement mapping, index version, and withdrawal state. This is not a retrieval guide: the lifecycle question is whether a changed source decision reaches the derived representation and every consuming analytical or model process.

Training and evaluation sets need build identities and approved-use references. Preserve selection logic, labels and their owners, time boundaries, exclusions, transformations, and model versions that consumed them. If a source is corrected, reviewers decide whether metrics must be recomputed, features rematerialized, vectors rebuilt, evaluation rerun, or a model retrained. Engineering shows affected assets and executes the approved action.

Propagate authorization and lifecycle decisions

Authorization can differ across source, transformation, feature, model, and output. A service account may read a broad table while the user should see only an aggregate. Map identities, roles or attributes, policy versions, service accounts, privileged paths, and output authorization. Test contrasting users, revoked access, stale groups, policy-service failure, exports, caches, and operator tools.

A source reclassification or purpose change triggers an impact decision. Do not assume that prior derived copies remain authorized because they were created earlier. Qualified customer reviewers decide permitted uses and required action; the lineage graph identifies affected stores and consumers.

Deletion, expiry, correction, and withdrawal require distinct cases. Record the owner instruction, source action, expected propagation, observed result in intermediate tables, features, vectors, datasets, artifacts, caches, logs, and backups within scope, plus unresolved exceptions. Some derived aggregates or model artifacts may require specialist decisions rather than automatic deletion. The platform should not invent those decisions.

Recovery can reintroduce retired data. Restore and replay tests should include lifecycle state and policy versions, not only bytes. After restoring a snapshot, reconcile it against current withdrawal, access, and correction records before serving downstream outputs.

Connect cybersecurity review to observable data paths

The NCA Data Cybersecurity Controls page is a named official input for qualified reviewers. Engineering should provide them with an asset and data-flow inventory, identities, access paths, encryption and key configuration, logs, change history, vulnerability and dependency evidence where requested, backup/recovery behavior, incidents, exceptions, and test results. Reviewers determine scope, interpretation, evidence sufficiency, and acceptance.

Security telemetry itself enters the lifecycle. Logs may contain identifiers, values, prompts, model outputs, queries, or feature payloads. Record collection, access, location supplied by the operator, retention input, redaction, export, and deletion behavior. Preserve investigative usefulness without creating an unowned copy.

Incidents should reference source and derived versions. A contaminated feature, unauthorized extract, incorrect metric, or stale vector needs containment across all consumers. Name triage, technical containment, evidence custody, qualified-review escalation, communication decision, recovery, and resumption owners. Legal or regulatory notification is not an engineering default.

Revalidate when meaning or consumption changes

Triggers include source revision, schema or classification change, new data purpose, new consumer, transformation update, metric-definition change, feature update, embedding or chunking change, model retraining, new endpoint, authorization-policy change, provider change, incident, and expired exception. The case register identifies which tests and reviewers return.

A release board should see case scope, lineage graph reconciled with execution, expected and observed tests, unresolved edges, affected consumers, specialist dispositions, failed cases, exception expiry, rollback, and monitoring. It can approve, condition, hold, roll back, or retire the precise version. The decision should not be reused for another model or dataset without reviewing the changed boundary.

The resulting evidence claim is small enough to defend: for one Saudi analytics or AI case, named source versions were traced through defined derived assets into a bounded use; change and withdrawal propagation were tested; exceptions and owners were recorded; and qualified customer reviewers made their decisions. It is not a statement of SDAIA or NCA conformity. It is the operating record needed to keep governed data governed after it leaves the source.