ZAF / CHAPTER 08 / 15

Data architecture, ownership and trustworthy reporting

Public reference edition 1.0 · 5 November 2026 · Fictional institutional example. No client outcome or deployment is claimed.

In this chapter
  1. 8.1 Assign authority before designing a warehouse
  2. 8.2 Information model
  3. 8.3 Source-to-report lineage
  4. 8.4 Reporting contract and quality controls
  5. 8.5 Analytical evolution and AI readiness
  6. 8.6 Acceptance package

8.1 Assign authority before designing a warehouse

The institution needs an agreed meaning for request, approval, fulfilment and outstanding obligation. A database schema can encode a definition; it cannot establish its institutional authority. Name the owner who decides the meaning, the steward who investigates exceptions and the technical custodian who operates storage. For the example, a request version is authoritative in the request domain. Execution facts belong to operations. The finance report combines those facts under an approved contract without rewriting their source meaning.

8.2 Information model

Information objectAuthorityKey relationshipControl
Request versionRequest ownerStable request ID plus versionChanges do not silently retain approval
Approval decisionDelegated authorityReferences exact request versionActor, scope and decision time retained
Fulfilment entryOperations ownerReferences authorizationPartial and reversed execution distinguished
Report publicationFinance ownerContract version and source cut-offCoverage and revision visible
ExceptionAssigned stewardSource reference and rule versionResolution does not erase original evidence

Retention and access apply to these objects and their copies. The design must identify sensitive fields, attachment handling and any permitted use in test environments. “Keep raw data” is not a blanket permission to retain everything indefinitely.

8.3 Source-to-report lineage

Figure 8.1 · Information authority and reporting lineage
Information authority and reporting lineageReporting combines authoritative facts through a defined contract. Exceptions remain visible; publication identifies source coverage, cut-off and revision.Request versionRequest domainApproval recordDelegated authorityFulfilment recordOperations domainQuality exceptionsAssigned stewardReconciliationFinance contractPublished reportCut-off and revision
Reporting combines authoritative facts through a defined contract. Exceptions remain visible; publication identifies source coverage, cut-off and revision.

Separate business event time, arrival time and publication time. A branch may submit Monday’s execution after reconnecting on Wednesday. Replacing the business timestamp with ingestion time would change the report’s meaning. Record corrections as revisions or authorized adjustments according to the institution’s policy.

8.4 Reporting contract and quality controls

Define grain, included states, period, currency treatment, expected sources and late-arrival policy. For one known cut-off, reconcile eligible source records against accepted records and identified exceptions, where those sets are mutually exclusive by definition.

  • Missing references remain visible with a responsible steward.
  • Repeated input does not duplicate an accepted fact.
  • Corrections have a version policy and a replay test.
  • Publication states whether expected sources are complete.
  • A successful processing job does not by itself establish correct totals.

8.5 Analytical evolution and AI readiness

A daily projection is proposed initially because the scenario has not established a real-time decision need. Introduce a separate analytical platform when history, isolation or analytical workload justifies the additional operating contract. AI use requires a separate problem definition, permitted data use, evaluation set, error consequences and human oversight. A clean data pipeline does not prove a model is appropriate. Begin with traceable data and a measurable decision problem; do not label ordinary reporting as AI to make the architecture appear more advanced.

8.6 Acceptance package

The data owner approves definitions and retention. Finance signs off a representative reconciliation. Engineering demonstrates replay and correction behaviour. The architecture record links source objects to report fields and exposes unresolved quality limitations before the report is relied upon.