Metadata management and information publication

Metadata answers the context questions that raw information often leaves unresolved. It tells consumers what the information means, where it came from, how current it is, who owns it, and what conditions apply to its use.

G234 positions metadata management as an integral part of information architecture, not as a documentation exercise that follows later. The reasoning is practical: if the enterprise waits until after platforms are built and data is flowing to add context, the context will be incomplete, inconsistent, or missing. The cost of retrofitting metadata is always higher than including it from the start because the people who understand the original meaning, assumptions, and provenance have moved on to other work.

Three architectural outcomes depend on metadata. Trust depends on consumers being able to verify what they are looking at. Discoverability depends on information assets being findable and their purpose being clear. Reuse depends on teams being confident enough in the meaning and quality of existing information to use it rather than creating their own copies.

G234 identifies six metadata concerns that form the minimum set any published or shared information asset should address. These are not optional extras. They are the baseline for governed information.

1. Meaning. What does this information item represent and what assumptions shape its interpretation? This includes definitions, units, scope boundaries, and any conditions that affect how the information should be read. For London capacity data, meaning includes whether the figure represents firm capacity, maximum capacity, or scenario-based headroom.
2. Provenance. Where did it come from, through which process or transformation, and on what basis was it produced? This is the lineage that allows consumers to trace the output back to its sources. For a London planning forecast, provenance includes which modelling tool produced it and which input datasets were used.
3. Stewardship. Who owns the meaning, quality, and governance of the information asset? This tells consumers who to contact when they have questions and who is accountable for the asset's integrity.
4. Lifecycle. When is this information current, how often is it refreshed, and when should it no longer be relied upon? This prevents consumers from treating stale or superseded information as current.
5. Classification and access. What sensitivity, security, or compliance classification applies? Who is permitted to access, modify, or redistribute the information? For regulated utilities, classification affects what can be published externally versus what must remain internal.
6. Quality and confidence. What quality thresholds apply and what known limitations exist? If the data has been estimated, extrapolated, or derived from incomplete sources, that should be stated. A planning estimate carries different confidence from a measured operational reading.

These six concerns form the information publication requirements that G234 describes. Every published London output should be testable against them. If any concern is unanswered, the publication is incomplete.

Published and shared information assets carry a higher burden of trust than internal working data. Metadata is what bridges the gap between what the producer knows and what the consumer needs to know.

• Consumers need to distinguish current, historic, and scenario-based views. Without lifecycle metadata, every version looks equally valid.
• Published outputs need enough context to prevent accidental misuse. A capacity figure published without scenario and date context invites misinterpretation.
• Internal reuse becomes much easier when teams can discover what information exists and how trustworthy it is. Discoverability is a metadata outcome.
• Governance review becomes more practical when meaning and ownership are explicit rather than assumed.
• LTDS-style publication requires the enterprise to share network development information that external consumers can interpret without asking the data team for context. The published output must carry its own context through metadata.

In the London case, every published output should carry at minimum: the scenario assumption, the model-run date, the authority source, the stewardship contact, the quality confidence level, and interpretation notes. Those six pieces of metadata transform a raw data file into a governed publication.

Metadata is often delayed because it looks administrative and does not feel like visible transformation. The team is under pressure to deliver platforms, dashboards, and integrations. Recording meaning, provenance, and stewardship feels like overhead.

Later, the organisation discovers that publication, analytics, and integration all became harder because no one captured the context the consumers needed. By that point, retrofitting metadata is more expensive than including it from the start for three reasons.

First, the people who understood the original meaning and assumptions have moved on. Second, the number of information assets that need metadata has grown during the delay. Third, consumers have already built interpretations based on their own assumptions, and those interpretations now need to be corrected.

The architecture team's job is to make the case for metadata early enough that it is included in the platform and publication design rather than bolted on afterwards. G234 provides the framework. The authority ownership model from Module 28 provides the stewardship structure. Together they make metadata a planned architecture output rather than an afterthought.

The London case uses metadata to support LTDS-style publication, internal planning reuse, and consumer confidence. If a published London information asset lacks date context, ownership, meaning, or model assumptions, it cannot support reliable reuse.

• London publication needs metadata because the consumer is not standing inside the producer's head.
• Reuse improves when metadata is treated as part of the information asset, not as an optional attachment.
• A London capacity figure published with clear scenario, date, authority, quality confidence, and interpretation context is an architecture output. The same figure published without that context is a liability.
• All six G234 metadata concerns should be testable for every London published output in the Phase C pack.
• The Phase C pack should specify which metadata fields are mandatory for each publication type and who is responsible for populating them.