Construct Mapping Table¶

Mapping artifact — instantiates Scale-Bridging Translation

A construct-by-construct crosswalk recording what each source-scale term becomes at the target scale — its units, proxies, exclusions, and the terms that have no clean counterpart.

Construct Mapping Table is the flat, inspectable ledger that pins down, term by term, what a source-scale construct means once you move to the target scale. Each row takes one source construct and records its target-scale counterpart, the unit change, the proxy standing in when no exact counterpart exists, and — crucially — an explicit cell for where a term simply does not carry over. Its defining move is that it is a vocabulary map, not a verdict: it never says whether the translated relationship still holds, only what each word denotes on each side, so that everyone downstream is arguing about the same objects. Where the substantive translation methods rebuild a model or a policy, this artifact just makes the correspondence of terms legible and reviewable.

Example¶

A SaaS company built its "active user" metric around a single product: logged in and performed a core action within 30 days. Now the company sells three products, and the board wants one portfolio-wide "active users" number. Before anyone builds the new dashboard, they lay out a Construct Mapping Table. One row: source construct active user (single product) → target construct active account (portfolio); unit changes from per-product to per-account; the proxy becomes "any core action in any product," with a flagged mismatch — a user busy in the small utility product but dormant in the flagship counts as active at the portfolio scale though the old metric would have called them churned. Another row handles internal test accounts, which the source silently included and the target must exclude.

The output is a one-page table the analytics, finance, and product teams all reference. Its value is narrow and real: the portfolio "active users" figure now means one thing, and the two places where the old and new definitions genuinely disagree are written down rather than discovered three quarters later in a board deck.

How it works¶

The table is a construct-by-construct crosswalk, and what distinguishes it from a generic glossary is three disciplines:

One row per source construct, each with an explicit target-scale counterpart — including a "no clean counterpart" cell that is filled, not left blank, when a term does not survive the move.
Separate the unit change from the meaning change. A cell that only rescales a number (per-day to per-month) is parameter mapping; a cell where the underlying thing being measured shifts is a construct remap. Conflating the two is where silent redefinition hides.
It is a living reference, not a one-time derivation — versioned and re-reviewed when either scale's definitions move.

Tuning parameters¶

Row granularity — one row per headline construct, or a row for every sub-field and unit. Finer granularity catches hidden redefinitions but bloats the table and invites false precision.
Proxy strictness — how close a target-scale stand-in must be before it earns a row versus a flagged mismatch. Loose proxies keep the table complete; strict ones keep it honest.
Mismatch handling — whether a term with no clean counterpart is a hard exclusion, a footnoted caveat, or a split into two target constructs.
Ownership and refresh — who signs off on each row and how often the crosswalk is revisited as definitions drift.

When it helps, and when it misleads¶

Its strength is killing silent redefinition — the failure where the same word denotes different things at two scales and nobody notices until the numbers refuse to reconcile. Written down, the disagreements become arguable.

Its failure mode is being mistaken for more than a vocabulary map: a complete, tidy table can feel authoritative, but it certifies nothing about whether the relationship between constructs still holds at the target scale — that is the job of a correspondence test, not a crosswalk. The construct-validity risk is real: a target-scale proxy can share a name with the source construct while capturing a different underlying thing.^[1] The classic misuse is running it backwards — assembling a mapping after the fact to make two incompatible metrics look comparable. The discipline is to keep every "no clean counterpart" cell filled and to treat the table as an input to validation, never a substitute for it.

How it implements the components¶

source_scale — the left column: each source construct with its original unit, definition, and instrumentation.
target_scale — the right column: the corresponding target construct the source term must become.
translation_variable — the body of the table is the remap of source constructs into target constructs, mismatches included.
parameter_mapping — the unit- and numeric-conversion cells, kept explicitly separate from meaning changes.

It does not record what must stay true or where the mapping is safe to trust — assumption_log, evidence_transport_rule, and validity_boundary belong to the Scale Assumption Register — and it never tests correspondence; that is Multi-Level Model Check and Stratified Target-Scale Rollout.

Instantiates: Scale-Bridging Translation — the artifact that fixes the shared vocabulary the rest of the bridge is built on.
Sibling mechanisms: Scale Assumption Register · Micro-to-Macro Model Translation · Lab-to-Field Translation · Pilot-to-Scale Translation · Macro-to-Micro Operational Translation · Individual-to-Population Policy Translation · Ecological Scale Translation · Multi-Level Model Check · Stratified Target-Scale Rollout · Team-to-Organization Process Translation

References¶

[1] Construct validity — whether a measure actually captures the underlying construct it names — is the psychometric risk the table makes visible: two scales can share a term while their proxies measure different things. ↩