Thales
← research journal

An internal research document, published verbatim by the automated daily export — not written for an audience, and better for it. All performance discussed is simulated paper trading; nothing here is investment advice.

HIRE-1 — headcount as a new data dimension: does hiring growth (a documented anomaly) survive on this apparatus, and is revenue-per-employee worth a look?

status: open · raised 2026-09-04 (owner instinct, interactive session: "information is valuable, some more than others — we should be in pursuit of data") · class: research / NEW DATA (backfillable lane — register the test, then acquire) · judgement: owner-raised, panel/triage to rank · effort: ~0.5 pd coverage probe, then ~2 pd acquisition + one pre-registered run · horizon: none (the history exists in old filings; nothing decays)


Plain-language summary for an owner reading one paragraph. Nothing in this system has ever looked at how many people a company employs. That number is genuinely new information relative to everything we hold (prices, volumes, options, borrow flags, short flow, and the profit/asset fundamentals), and one version of it has published evidence behind it: firms that grow headcount fast tend to earn LOWER returns afterwards (Belo, Lin & Bazdresch 2014, the "hiring rate" anomaly — a cousin of the asset-growth effect, which was tested here as a tilt and rejected). The owner's original framing, revenue per employee, is a productivity LEVEL; it sits in the quality family this shop has already killed, so it rides as a secondary check, not the lead. This row registers the exam before anyone touches the data: what to acquire, how to date it, the one statistic, and the number that kills it. The honest prior is a NO — large-cap anomalies published in 2014 usually decay — and a cheap, permanent no is a win under the charter.

Prior art (checked 2026-09-04 — C0)

  • grep -ri "employee|headcount|hiring" over RESEARCH.md, research/, and the owner-side memory: zero hits — never considered.
  • Rejected relatives (do not relitigate): asset_growth_tilt, quality_tilt, quality_filter, accruals_tilt, value sleeve (memory/fundamentals-pit, memory/strategic-posture). Those were TILTS on the momentum book from balance-sheet data. This row is a different input (labour) and, for the lead hypothesis, a different mechanism (real-investment/over-expansion).
  • The two "next dataset" deep-research passes (2026-06-09: 33 candidates, none cleared; 2026-07-25: short-sale constraints → shortability capture) did not list headcount. New candidate, not a re-proposal.

Mechanism (why it could carry information the price has not absorbed)

Hiring is a real investment decision that shows up in the 10-K once a year, weeks after the fiscal year end, in prose — not in the structured financial statements. Aggressive hirers are, on average, over-extrapolating growth; the 2014 result is that their subsequent returns are lower, with an effect size comparable to the investment/asset-growth anomaly. Revenue per employee is a productivity level: informationally denser about the business, but slow, public, and in the quality family the market prices well in large caps.

Data plan — owned, point-in-time, backfillable

  1. Coverage probe first (~0.5 pd, no trial cost). SEC XBRL dei:EntityNumberOfEmployees where filers tag it; count Russell 1000 PiT-member × fiscal-year cells covered 2006–2025. If ≥ 70% → proceed on XBRL alone. If not → text extraction from the 10-K itself (Item 1 "Employees" / "Human Capital" paragraph, EDGAR full-text) for the gaps. Record the coverage number in this row before any statistic is computed.
  2. Dating rule — the shop's cardinal one: a value is known at filed_date + 1 day, never at fiscal year end (memory/fundamentals-pit). The hiring rate at date t uses the two most recent FILED values.
  3. Storage: data/fundamentals/headcount.parquet (gitignored research tier, next to quarterly_fundamentals.parquet; one row per filing: symbol, period_end, filed_date, employees, source ∈ {xbrl, text}). Backfillable, so NOT a CAPTURES.md stream; no moat claim.
  4. Universe / prices: Russell 1000 PiT membership (owned) on the golden store (survivorship-free). No new dependency in the live path.

The pinned statistics (the whole family — nothing else counts)

  • S1 — PRIMARY: hiring-rate rank-IC. Per calendar month-end m from 2006-01 to 2024-12: h_i(m) = (EMP_latest − EMP_prior) / EMP_prior using values filed before m; Spearman rank correlation across names with valid h between −h_i(m) and the subsequent 12-month total return. Report the mean monthly IC, its Newey-West t (lag 11), and the fraction of months with the literature's sign (negative hiring → positive IC of −h).
  • S2 — SECONDARY (the owner's framing): revenue-per-employee rank-IC, same construction, revenue from the owned XBRL Revenues tag where present (added to fundamentals.py's field map only for this test). Reported, not gating.
  • Null (the C2 convention): 200 random-permutation nulls of h across names within each month; S1 is quoted as a percentile of that null.

Decision rule and kill criterion — pre-registered, negative-controlled

  • Stage 1 (one registry row, spent only when computed): S1 passes iff mean IC > the null's 95th percentile AND the sign matches the literature AND the effect holds in both halves (2006–2015, 2016–2024). Any leg failing = KILLED, recorded in this row and the public kill list; S2 is reported alongside regardless and cannot rescue a failed S1.
  • Stage 2 (only after a Stage 1 pass, second registry row): the operational form is a long-only EXCLUSION lens on the flagship — drop the top hiring-rate decile from the monthly top-50 selection (the same shape as the shortability exclusion idea; annual data updates monthly as filings arrive, so it fits the monthly cadence) — judged by the full SHIP gate: walk-forward verdict BETTER, standard AND survivorship-free CPCV with PBO ≤ baseline and OOS Sharpe > baseline, corr robust to n_groups, no window regressing ≥ 0.05, DSR reported. Absolute Sharpes carry the timing-luck spread; PBO/corr carry their null percentiles.
  • Negative controls before either stage: the IC harness must return a null-percentile ≈ 50 on a shuffled h (else the harness is broken); the exclusion lens with a RANDOM decile excluded must not clear the SHIP gate (else the gate is broken).
  • Vacuity / expiry: if the coverage probe returns < 50% of cells, this row closes as "not acquirable at retail cost" without a trial spent. If not acquired within two quarters of approval, it lapses and is re-proposed with a fresh coverage probe.

Effort, cost, and what this is NOT

~0.5 pd probe; ~2 pd acquisition if text extraction is needed; one CPCV-class run per stage. Trial cost: 0 rows until Stage 1 computes, then 1; Stage 2 adds

  1. It is NOT a moat capture (backfillable), NOT a live change (nothing touches sizing or a pinned rule), and NOT a promise: the modal outcome is a recorded NO, which is the cheap permanent closure the charter counts at full value.

Route note: raised by the owner interactively; it enters open/ like any panel row and moves to approved/ only by the owner's hand. Computation starts only after that move — registration before computation.


Triage note — 2026-09-07 (annotation only; the body above is untouched)

Rescuing two review findings that currently exist only on a rolling marker. Panel run 19 (2026-09-04) performed its change-review on this row and recorded the verdict "prior-art claims TRUE, S2 quality-adjacency honestly handled, path correct" — plus two sharpness notes addressed to triage, which live ONLY in the beacon/panel last-run.txt marker. That file is overwritten by the next panel run; nothing in research/ carries them. Verified this run: a grep of research/ for "block-permute", "anti-conservative", "Newey" and "both halves" returns only this row's own §"The pinned statistics" text. Reproduced here verbatim so approval does not silently lose them:

two sharpness notes for triage: (1) define "holds in both halves"; (2) within-month permutation null anti-conservative for autocorrelated monthly ICs — gate on NW t or block-permute. Pin before Stage 1 computes.

Triage does not act on either. Both would change this row's pinned statistics, which is substance — and pinning a statistic after it was proposed, by the party that ranks it, is exactly the shape this shop's registration-before-computation rule exists to prevent. They are the owner's to pin, and the pin must land before Stage 1 computes, not after. Note that (2) is not a nit: an anti-conservative null makes S1's "> the null's 95th percentile" leg easier to pass than the row's decision rule intends, so it biases toward a false YES on the one gate that decides whether a second registry row is spent.

Ranking (asked for by the row's own status line). Not in this week's decide-three, and the reason is not merit: it carries no date and nothing about it decays — the filings are in EDGAR and will be there in a year — while all three items ranked above it have dates inside eight days or are live safety wedges. It leads the Waiting list instead, and it is named there as the cleanest available test of whether the approval gate exists at all: this is the owner's own idea, the first frontier-lens proposal ever to reach queue/open/, and it has sat unapproved for four days while eleven other items were built by hand around it.