Shared controls · source records · decision gates

How I keep important numbers tied to their sources.

A plain-language set of checks for inputs, tests, source records, and the next decision.

The system is not a promise that every project is perfect. It is a set of habits that makes weak inputs, late information, lucky results, and overconfident conclusions easier to catch before they become a business decision.

The boundary Important claims stay tied to sources, tests, and decisions. If a source-traceable claim drifts, the page should fail its own checks. This shared method ties the statement to its source, timing, test, and next decision—including the answer "not enough evidence yet."
6 questions in the operating loop
6 recurring controls
3 readiness stages
5 projects with inspectable receipts
The operating loop

Every serious project follows the same six questions.

The details change. The questions are deliberately boring.

01 Question. What decision is this meant to improve?
02 Rule. What result would count as useful, weak, or disqualifying?
03 Inputs. Is the source complete, current, and appropriate for the question?
04 Run. Can the work be repeated from the same inputs and written instructions?
05 Check. Did a test, comparison, or hostile example try to break the result?
06 Decision. What is allowed to happen next, and who is responsible for that call?
The recurring controls

These controls are the practical version of “trust, but verify.”

Each one exists because a specific kind of claim has gone wrong before: late data, a moved goalpost, a number nobody can trace.

01 / Timing Timing control Do not use information that arrived after the decision window. The marketing measurement study is the clearest example: late conversions cannot quietly improve an old budget decision.
02 / Pre-commitment Pre-commitment Write the hypothesis, cutoff, or falsifier before seeing the result. This makes it harder to redraw the finish line afterwards.
03 / Comparison Control or comparison Try a shuffled comparison, data kept aside, or another neutral reference so a result has to beat more than a convenient baseline.
04 / Source record Source record Keep the source, date, schema, and important counts. A number without its origin is a decoration, not evidence.
05 / Contract Claim contract Map a headline number to the receipt that supports it. If the receipt changes, the page should fail rather than drift.
06 / Release gate Release gate Passing a test does not automatically authorize spending, applying, publishing, or trading. The next action stays visible.
When the checks caught something

The controls are real because the record includes the awkward parts.

These are not hypothetical failure modes. Each changed the public record or the next decision.

TIMING167 candidates disappeared.The marketing measurement study's first screen found 285 candidates. Once the timing control was applied, 167 only looked good because the credit arrived after the decision date.See the correction →
COMPARISON999 shuffles, zero false alarms.The growth study scrambled the timing 999 times and re-ran the same screen. It never reached the real result by accident.See the placebo check →
PRE-COMMITMENT2 promising ideas were formally refuted.Sports follow-up checks killed two ideas after the first pass made them look promising. The written falsifier did its job.See the sports checks →
RECEIPT11 logged incidents, 24-hour median detection.The options pipeline has broken 11 times. The incident log, coverage floor, and partial test matrix stay visible instead of smoothing the story.See the operating controls →
RELEASE GATE97 clips rejected after passing every rule.The YouTube filter clears a shortlist. The owner can still reject clips, because passing a rule is not the same as being good.See the review gate →
STATUSA Delve release label stayed incomplete.The active component and package metadata did not align cleanly, so the page describes a verified local build rather than a finished release.See the release boundary →
What a source record means here

A source record is not a wall of technical output.

It is the shortest useful answer to: "Where did this claim come from, and what would make me doubt it?" Depending on the project, that can be a JSON file, a test, a timestamped registry, a build result, or an owner decision record. I call these receipts when they are attached to the portfolio.

For marketing measurement: the portfolio page links to the campaign receipt and the detailed method page.

For Options research and Sports research: the staged pages show counts and governance, while sensitive strategy details remain withheld.

For the job search tool and the YouTube video workflow: the receipt shows the funnel and the owner boundary.

For Delve: the receipt is currently a build/test record plus a clear note about which UI ideas are exploratory.

Reader rule If a page gives you a strong conclusion but cannot tell you what was measured, when it was measured, and what would change the conclusion, treat it as a pitch, not proof.
Three readiness stages

“It ran” and “it is ready” are different statements.

01 / Documented Documented The project notes, source code, or design files describe the idea and its intended behavior.
02 / Verified Verified locally A current test, build, audit, or comparison was actually run and returned a usable result.
03 / Public-ready Public-ready The evidence is current, the copy is accurate, the assets are licensed, and the reader can understand the limits.

A project can be documented and locally verified without being ready for a polished public claim. That distinction is intentional.

What this does not promise

Checks reduce avoidable mistakes. They do not make uncertainty disappear.

This system does not promise perfect data, perfect models, commercial success, or a correct answer every time.

It does promise a better question, a visible rule and a traceable source, a chance to catch the result lying, and a clear statement of what remains unknown.

See the deepest technical example in the marketing measurement method →