Public-sector data governance: ownership, lineage and quality

Answer for management practice

For “Public-sector data governance: ownership, lineage and quality”, define the outcome as a change in management practice. The central object is scenarios, directives and control; it needs an agreed source, decision owner and observable state after the action “define checks and corrections”.

The first evidence is not a solution presentation but a reproducible example of “execution cannot be verified against a source”. It allows the team to set the process boundary, inspect baseline data and select the fact that will confirm completion.

Official sources for a public-sector environment

Federal Law No. 149-FZ provides the general legal context for information and information systems. Applicable requirements are mapped to registers and sector systems, a specific process stage and an accountable owner; other specialised rules are determined from the actual project scope.

The requirements register distinguishes a legal rule, an organisational decision and technical implementation. Each entry identifies the official source, current version, interpretation owner, affected data and evidence of fulfilment; the control signal here is “execution cannot be verified against a source”.

Subject model and boundaries

The subject model starts with two reference objects: registers and sector systems and scenarios, directives and control. They may reside in different systems, so each needs an identifier and owner; their relationship is tested through the action “identify key objects”.

The primary boundary is registers and sector systems. Its system of record, semantic owner, quality owner, refresh cycle and permitted transformations are documented. An error is also defined explicitly: who corrects it and how the change reaches dependent reports, plans or documents.

• Control record 1. Object: Goals and public programmes. Observable signal: Execution cannot be verified against a source. Accountability: semantic owner and quality owner.
• Boundary 2. Object: Activities and projects. Define the source, frequency, permitted transformations and response to “one object is duplicated across registers”.
• Object 3: Measures and sources. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: A measure is disconnected from an activity.

End-to-end scenario data

An integration design begins not with arrows between applications but with events and accountability. It defines who creates a record, where it becomes authoritative, which checks run before transfer, how duplicates are handled and which action is blocked when records disagree. The reference object here is scenarios, directives and control.

Every exchange has a business owner, technical owner and observable control point. API, messaging, file transfer or another technology is selected after frequency, volume, resilience and error behaviour are known. For the signal “execution cannot be verified against a source”, quality is assessed before transfer and after loading so that the origin of a discrepancy can be located.

• Record 5. Object: Scenarios, directives and control. Required details: identifier, lineage, quality rule and update event. Signal: A project is not linked to a programme goal.
• Subject area 4: Registers and sector systems. Verification basis: system of record, owner authority and the signal “a situation centre only visualises data”.
• Object 3: Measures and sources. Record fields: source, semantic owner, quality owner and refresh rule. Control signal: A measure is disconnected from an activity.

Management question

State the decision before compiling requirements. It identifies goals and public programmes, the role authorised to choose, the permitted action and the evidence participants will use to accept or reject an option.

Do not combine the signal “execution cannot be verified against a source” and the risk “claiming access to public-sector data” into one measure: the former describes an observable state, while the latter describes a possible consequence. The action “define checks and corrections” connects them in a testable scenario.

• Decision 1: object — goals and public programmes; signal — a project is not linked to a programme goal; action — define checks and corrections.
• Decision 2: object — activities and projects; signal — execution cannot be verified against a source; action — maintain lineage and versions.
• Decision 3: object — measures and sources; signal — one object is duplicated across registers; action — identify key objects.

Quality and correction rules

The method is a sequence of decisions rather than a universal checklist. For scenarios, directives and control, each output is used at the next step: the model supports the scenario, the scenario defines data and requirements, and requirements become test and acceptance criteria.

For registers and sector systems, the sequence may change with scale and constraints, but assumptions are always documented. When source data is incomplete or a decision involves an external party, the dependency receives an owner, review date and condition for proceeding. The first action is “define checks and corrections”.

• Step 1. Identify key objects. Output: scenarios, directives and control.
• Assign systems of record is the action at stage 2. The output documents goals and public programmes.
• At position 3, the action is “align identifiers and master data”; its result is activities and projects.
• Stage 4: define checks and corrections. The working artefact describes measures and sources.

Where the problem becomes visible

Diagnosis examines a concrete episode involving registers and sector systems. Its record states the time, participants, data used, decision made and consequence; recurrence is checked against a second sample.

Review the signal “a measure is disconnected from an activity” with the process owner. If its cause lies outside the selected boundary, record the dependency separately and do not expand scope without a new decision on timing, resources and acceptance.

• Signal: One object is duplicated across registers. Evidence includes an example, frequency and consequence for scenarios, directives and control.
• Event to test: a measure is disconnected from an activity. Evidence shows timing, frequency and consequence for goals and public programmes.
• Indicator: A situation centre only visualises data. Analysis needs an actual example and the resulting change in activities and projects.

Decision-rights matrix

For goals and public programmes, the role model determines more than screen access. In the action “define checks and corrections”, it identifies who changes a rule, authorises an exception, accepts risk and confirms the outcome. The accountability matrix is tied to decisions and artefacts rather than abstract departmental participation.

A business–IT disagreement is resolved by the decision owner using agreed evidence. The architect does not replace the business owner, and the project manager does not define the meaning of a measure. For goals and public programmes, this separation is especially important because of the risk “requirements without a current official regulatory source”.

• Business owner: decision area — scenarios, directives and control; control action — identify key objects.
• Architect is accountable for goals and public programmes and confirms the action “assign systems of record”.
• Role: Data owner. Decision object: activities and projects; verified step: align identifiers and master data.
• Project manager decides within measures and sources; the basis is prepared through “define checks and corrections”.

Evidence that the solution works

The acceptance criterion for goals and public programmes includes a baseline sample, calculation rule, expected change and source of the actual outcome. The interpretation owner confirms that comparison conditions have not changed.

The end-to-end test starts with “a measure is disconnected from an activity”, passes through an authorised decision and “identify key objects”, and ends with an execution record. Interface defects and process nonconformities are logged separately.

• Criterion 1: Goals and public programmes; evidence needs a baseline sample, expected change, interpretation owner and source of actuals. Test signal: A measure is disconnected from an activity.
• Criterion 2. Object: Activities and projects. Test fields: baseline, target change, source and owner. Signal: A situation centre only visualises data.
• 3. Acceptance object: measures and sources; compare the baseline sample, expected change and confirmed actuals. Test signal: A project is not linked to a programme goal.
• Evidence item 4 describes registers and sector systems, comparable test conditions and the person accountable for interpretation. Signal: Execution cannot be verified against a source.

Controlling critical dependencies

The risk map starts with two conditions: “claiming access to public-sector data” and “requirements without a current official regulatory source”. Each receives an observable event, decision owner, control and outcome that requires a stop or rollback.

A regulated environment maintains a register of applicable requirements: official source, version, interpretation owner, affected process and confirmation method. The risk “requirements without a current official regulatory source” is reviewed whenever affected data, integrations, roles or control scenarios change.

• Risk: Claiming access to public-sector data. Control: maintain lineage and versions. Evidence: activities and projects.
• Risk condition 2: One platform without an authority model. Response: Identify key objects. Testable evidence: Measures and sources.
• The risk scenario “requirements without a current official regulatory source” is addressed through “assign systems of record” and confirmed using registers and sector systems.
• Controlled constraint: centralisation without sector data owners. The owner performs “align identifiers and master data” and provides scenarios, directives and control.

Materials for starting work

The first session examines one real case involving registers and sector systems. Participants bring a source document or sample, data-flow diagram, current procedure and an example of “execution cannot be verified against a source”.

The session ends with a decision on the next format rather than a wish list. Assign an owner and due date to “define checks and corrections”; assign an additional test or stop condition to the risk “requirements without a current official regulatory source”.

• Step 1. Identify key objects. Output: scenarios, directives and control.
• Assign systems of record is the action at stage 2. The output documents goals and public programmes.
• Evidence item 4 describes registers and sector systems, comparable test conditions and the person accountable for interpretation. Signal: Execution cannot be verified against a source.
• Test 5 concerns scenarios, directives and control. The method, interpretation owner and outcome source are documented. Signal: One object is duplicated across registers.