Working Heuristics — Data, Matching, Product, Org, Tooling

A list of ~30 hard-won rules of thumb the human distilled from their own data-engineering / product / org work, grouped into five themes. Supplied inline on 2026-06-26 and persisted to raw/. This opens the wiki's engineering-craft domain — distinct from the AI-and-work macro themes that dominate the rest of the wiki, though several heuristics rhyme with them (see Connections).

Summary

These are not arguments to be evaluated so much as operating heuristics — each states a move that worked and the failure mode it avoids. They span the full stack of building a data product: how to model and name data, how to match and de-duplicate identities, where to put capability and compute, how to share a boundary with another team, and how to keep tickets and tooling clean. Three ideas recur across the five themes and are the connective tissue of the whole list:

1. Do It Once, at the Right Place. Derive at the boundary (Data Contract), compute where the data lives (Data Gravity), persist a human decision so it's paid once (Human-in-the-Loop by Exception). Re-derivation is the enemy — it re-introduces bugs and re-spends effort.
2. Directionality and naming are load-bearing. Name tables for the direction data flows; keep ticket links pointed the right way (Pipeline Legibility, Scope Hygiene for Tickets and Tooling). A reversed relationship encodes a lie that silently misleads the next reader.
3. Compose, don't conquer. Build the durable layer as the other team's extension, not a land-grab (Build With, Not Against); place a feature where the user's mental model already is, reusing the nearest proven mechanism (Build It as an Extension). The same "extension, not new thing" move shows up at the org scale and the product scale.

Key claims, by theme

Data modeling & pipelines

• Lands vs Lives. In a view-only medallion, where data lands = the one physical base table; where it lives = the modeling layer. → Pipeline Legibility
• Derivation math belongs in the data contract. Do timezone/unit/format conversion once at the boundary so every consumer inherits a correct value instead of re-deriving (and re-bugging) it. → Data Contract
• One fact per grain. Never widen a dimension or fact with attributes that don't share its key. → One Fact Per Grain
• Name tables for the direction data flows, or you encode a lie that misleads the next reader. → Pipeline Legibility
• Ingestion design is downstream of the source's export contract — confirm how the source actually exports before committing to a pipeline. → Pipeline Legibility
• Trust lineage you can read (DDL/source); don't assert the connector tech you can't see. → Pipeline Legibility
• A "didn't-happen" metric needs both rows. A fact must carry planned and actual records, or the negative case is uncomputable downstream. → One Fact Per Grain

Matching & identity

• Unreliable join key → shrink the candidate space, not tune the matcher. → Shrink the Candidate Space
• A convenient source isn't a system of record. Verify authority before promoting a source to SOT. → System of Record
• Allowlist, not blocklist, for sensitive fields at ingestion — name what you keep and drop the rest, so sensitive data can't leak by omission. → Allowlist over Blocklist
• Automate the structured bulk; reserve humans for true exceptions and confirmation. Never make someone re-type what a system already emits. → Human-in-the-Loop by Exception
• Persist human decisions so each is paid once, not re-derived every cycle. → Human-in-the-Loop by Exception
• Make the manual step productive. Every human confirmation should teach the system something it didn't have. → Human-in-the-Loop by Exception

Product & platform decisions

• Choose the platform by the hardest, most-recurring part of the workflow — not the part that's cheapest to prototype. → Choose the Platform by the Hardest Recurring Part
• Put compute where the data has gravity — move the small thing (query/spec) to the data, not the data to the app. → Data Gravity
• Test a category claim against the other side's actual artifact. If they have one too, find the narrower axis where you're genuinely distinct. → Falsification Is Asymmetric
• Place capability where the user's mental model already puts the data, and reuse the nearest proven mechanism — that's what makes it read as an extension, not a new thing to learn. → Build It as an Extension
• A single probe disproves "always," not "never." Sample across the spectrum before claiming a categorical negative. → Falsification Is Asymmetric

Org & collaboration

• Turf friction is almost always an unowned boundary, not redundant work. Draw the seam explicitly and make the pieces compose, rather than out-building the other side. → Build With, Not Against
• Concede where the other side is genuinely better. It's what makes you a partner, not a territorialist. → Build With, Not Against
• Separate "best for the customer" from "keeps my team relevant." When they diverge, follow customer-best. → Build With, Not Against
• Build with, not against: make the durable layer the other team's extension of their own work, not a land-grab. → Build With, Not Against

Tickets & tooling hygiene

• Split orthogonal scope so neither deliverable blocks the other.
• Don't refactor a downstream spec while the upstream decision is open — flag the dependency, freeze the contingent parts, and rewrite once.
• Scope work to what you uniquely deliver; cut duplicative items explicitly rather than letting them rot.
• Directional links are load-bearing — a reversed relationship gets silently misfiled.
• Put a shared tool at the scope where the people who need it are — team-and-repo → project, personal-and-cross-repo → user, one-off → local.
• Name projects in the stakeholders' words and after the outcome, matching existing conventions rather than inventing a scheme.
• (all six) → Scope Hygiene for Tickets and Tooling

Tension (2026-11-08): Willingham argues that maxims like these are cues, not capabilities. They help someone who already has the domain knowledge to act on them, and they transfer poorly when read cold or practised out of context. For the human who wrote them, each line points to real experience. For any other reader, including future agents, the value lives in worked examples, which this list doesn't carry. Tracked as T1 in Method Reflection.

Borges + pattern-language check (2026-11-08): this list and the 11 pages citing only it total 11.1× the source's length (The Borges Map). By Alexander's test it is "a bunch of good ideas," not yet a language that generates a whole. Proposed: compress, add worked examples, order as a sequence (T1).

Connections

• Metacognitive Strategies — in Willingham's terms, this list is a library of metacognitive strategies. See Method Reflection (T1) for what that implies.
• The Human Sandwich — the matching trio (automate the bulk / persist decisions / make the manual step teach) is the data-pipeline cousin of the human-in-the-loop sandwich; both reserve the human for the judgment slice and bank the rest.
• Personal vs Team Agents — Build With, Not Against rhymes with Every's shared-unit reversal: shared, composable infrastructure beats per-actor land-grabs.
• Control-Flow Integrity — Allowlist over Blocklist is the same default-deny / enumerate-the-legitimate stance CFI takes (only the sanctioned control-flow edges are allowed); this source extends the wiki's software-security thinking into data handling.
• Match Process Weight to Stage and Stakes — see also (not a grounding): the ticket/tooling-hygiene cluster is process craft, but it argues how to keep work clean, not the seed's thesis that process weight should scale with stage × stakes. Related domain, different claim — so the seed stays unpromoted.

Source

• Original: raw/2026-06-26 Working Heuristics — Data, Matching, Product, Org, Tooling.md (human-supplied inline, persisted to raw/ on ingest).