Integration teams map dozens of source fields into canonical citizen attributes, but the mappings live only in a developer’s private notes. What should metadata management require?
Select an answer to reveal the explanation.
Short Explanation
Field mappings stuck in private notes are like subway transfers written only on one rider’s napkin. Publish governed source-to-canonical mappings so integrators and stewards share one interoperability map. Expiring chats and tribal memory break the next release.
Full Explanation
Source-to-canonical field mappings for citizen attributes are core integration metadata and must not live only in a developer’s private notes. Metadata management should require documenting governed mappings as shared technical and business metadata so onboarding, impact analysis, and audits can see how departmental fields become enterprise citizen attributes. Recreating every mapping from scratch each release wastes effort and invites silent divergence. Storing mappings only in encrypted chat that expires in 24 hours destroys institutional memory. Forbidding canonical attributes so each source keeps incompatible names forever maximizes pairwise integration cost. Exam answers favor shared, governed mapping documentation. Caveat: mappings need owners and change control when source systems rename fields; undocumented “temporary” maps become permanent risk. Operationally, publish the citizen attribute crosswalk in the catalog or metadata repository, link it to glossary terms, require updates via change tickets, and verify a new integrator can implement a feed using only the published map. Store mapping change history beside the crosswalk so auditors can see when a departmental citizen field was remapped into the canonical attribute.