Question → evidence → model → inspectable explanation · schematic
Fig. 01 — working methodInspect: hover, tap or focus any element
01Question
A question that can be tested
Enters left · unresolved
Does the language firms use carry a measurable signal about what they later do?
The question fixes the unit, the window, and the outcome before any evidence is read.
02Evidence
Fragmented evidence
Documents
Observations
Data marks
Financial signals
Codebuild_panel()
Counts schematic · classes kept separate
Each class enters in its own register. Nothing is merged before it is counted.
03Model
One analytical system
Assumptions held visible
Proxy stands in for construct
Selection on observables only
Window fixed ex ante
Uncertainty carried forward
+19 bp [−4, +42] · schematic
Assumptions and uncertainty stay on the surface of the model, not underneath it.
04Explanation
Three connected outputs
Output 01
Model
An estimate with its interval, its assumptions, and its failure cases attached.
Output 02
Tool
The pipeline runs again on new data without being rebuilt.
Output 03
Explanation
The reasoning is readable end to end, including what it cannot establish.
Each output can be opened, checked, and reused on its own.
Make the reasoning inspectable.
Fig. 01 · schematic · no fitted values
Inspecting —Hover, tap or focus any element to read its role and its boundary.
Approach
Build the system the question needs.
I work where finance, empirical research, and software meet. I begin with the question and the available evidence, then build the data and technical system needed to test it.
Models are useful when their assumptions, uncertainty, and limits remain visible. The same principle shapes the tools and explanations I build: rigorous enough to inspect, clear enough to reuse.
Contact
For professional inquiries, connect through one of these public profiles.
