Plan Safe Record Linkage Across M&E Sources

Evidence and applicability: use only supplied evidence for historical facts, source values, completed checks and approvals. Cite source labels and row, item or section references. Separate observed facts, assumptions, proposed procedures and unresolved questions. Preserve conflicting claims with provenance; absent documentation does not prove a practice never occurred. Do not invent data, permissions, findings, validation or sign-off. A draft plan grants no operational, ethical or legal clearance.

Use only material supplied in this conversation. Request missing essential inputs and continue metadata-level planning where supported. Needed: the specific linkage purpose and intended output; documented permitted uses, access and sharing limits; safe schemas and field definitions; units, source versions, periods and coverage; intended relationship/cardinality; aggregate key-quality summaries; any authorized identity-crosswalk description; and existing validation evidence, policies and retention constraints. Ask for no actual identifiers, identifiable records, secrets, linkage keys or sensitive case histories. A common field name, platform name or assertion of consent does not establish compatible keys or permission to link. If purpose or authorization is unresolved, mark linkage execution blocked pending the responsible review while describing the missing decision.

Plan safe record linkage across the supplied M&E source schemas. Design the matching specification and its quality accounting; do not perform linkage or request actual personal records.

1. Define the proposed unit and relationship for each source: person, household, encounter, organization or another supplied unit. State whether the intended relationship is one-to-one, one-to-many or many-to-many and why. Check time, coverage, field meaning, identifier scope and whether keys are unique, reused, shared, stale or missing using supplied metadata and summaries. A repeat service encounter is not automatically a duplicate person, and a household key cannot establish individual identity. Flag unresolved compatibility before specifying a join.
2. Build a minimum-field linkage specification: source/version, candidate key or approved crosswalk description, key scope and quality, proposed normalization, comparison rule, cardinality, permitted purpose, required access and unresolved prerequisite. Preserve originals and log transformations. Limit keys to what the purpose and authorized method require; do not recommend collecting more identifiers by default. Formatting normalization cannot establish identity. Hashing or pseudonymization alone does not guarantee anonymity, prevent collisions or make use permissible; do not expose actual key values, hashes of identifiers, secrets or salts.
3. Propose a staged matching procedure only where inputs support it. Distinguish exact-key agreement from a validated identity match; a key may be duplicated, assigned incorrectly or reused. An existing authorized crosswalk needs version, provenance and validation status. If approximate/probabilistic comparison is being considered, state required expertise, safe environment, evidence for model/rule calibration and independent validation before thresholds can be chosen. Do not invent similarity cutoffs, match probabilities or a universal acceptable error rate. Similar strings or shared characteristics alone are not proof of the same unit. Candidate-generation/blocking rules can miss true matches and need evaluation as well as final match rules.
4. Define a match-status and exception table with mutually understandable statuses: accepted under a documented rule and review status, candidate/ambiguous, unmatched, conflicting key or relationship, and out of scope with an evidenced reason. Retain uncertain candidates as unresolved. Never choose the first candidate, force a unique match, drop ambiguous records or delete source duplicates to make a join succeed. Preserve legitimate repeated events and document how conflicts and multiple candidates would be reviewed by authorized personnel. No actual case review or recontact is authorized here.
5. Design linkage QA and error accounting. Specify which safe aggregate counts will reconcile source rows, eligible unique units, candidate pairs, accepted links, unresolved cases, unmatched units and join output rows; these quantities have different units and must not be added indiscriminately. Check unexpected row multiplication and relationship violations. Separate false matches from missed matches and distinguish a candidate pair from a linked entity. Propose independent validation using permitted reference evidence and an appropriate review design, including difficult, unmatched and ambiguous cases where feasible. Report precision or missed-match/recall measures only when the reference evidence, denominator and review design support them; reviewing accepted pairs alone cannot establish recall. Document uncertainty, potential errors in the reference standard, coverage of validation, and differential linkage error by relevant group only when safe and supported. Match rate alone is not accuracy or absence of bias. Do not fabricate validation counts, labels or completed checks.
6. State downstream limits: preserve source references, linkage-rule version, match/review status and unresolved cases in a restricted audit trail. Keep raw sources unchanged. Define separately any proposed analysis subset and how exclusion or uncertain links could affect comparisons; propose sensitivity checks without treating unresolved links as confirmed identities. A linked row count is not unique reach, a representative population, an outcome or causal impact. Route unique-reach aggregation to its separate counting task after linkage quality is addressed.
7. Provide a restricted-key handling plan tied to actual policies: authorized roles, separation of the identity crosswalk from analytical data, safe transfer and review environment, minimum release fields, and retention/disposal decisions including copies and backups. Leave unknown durations and obligations unresolved for the responsible owner. Do not promise erasure, anonymization or compliance without evidence. Deletion is a proposed governed action, never an instruction to erase evidence or execute disposal now.

Output: a purpose/authorization prerequisite register; unit/key/cardinality compatibility table; conditional matching specification; match-status and exception schema; QA/error-accounting plan with denominators; and restricted-key handling and downstream-limit notes. Mark each element documented, proposed or unresolved. With no schemas or validation evidence, provide an explicitly incomplete specification and targeted requests, not a completed matching design or quality claim.