Reep Register stable football IDs
Handbook
Reep is the identity layer football data is missing.
Reep turns provider-specific football records into stable entities, safe provider bridges, useful aliases, and release-level coverage that product teams can build on without re-solving the same identity problem.
Current public release
A stamped data product, not a one-off crosswalk.
The public release is a loadable projection of the register. It carries enough metadata for consumers to know what was covered, what providers were attached, and which files they loaded.
provider ID links
name surfaces
public graph edges
bridge-register-v1
What Reep is trying to do
Balance accuracy, speed, and coverage.
A useful identity register has to be broad enough to matter, accurate enough to trust, and fast enough to maintain. Optimising only one of those produces either a tiny gold set, a large noisy crosswalk, or a process that cannot keep up with football.
Accuracy
Avoid false merges, keep provenance on identity claims, and measure quality instead of assuming a large crosswalk is correct.
Speed
Keep the register re-derivable enough that new competitions, providers, and corrections can move through the loop quickly.
Coverage
Treat provider diversity, entity-type range, aliases, relationships, and global competition breadth as first-class product surfaces.
What it combines
Prior work, turned into a football-native product.
Reep is not just fuzzy matching. It combines entity-resolution practice, football graph structure, provider-specific doctrine, measured release management, and human review where evidence runs out.
Entity resolution
Classic matching ideas
Blocking, scoring, anchors, discriminators, and Fellegi-Sunter style evidence weights are useful, but only when football context tells the model what counts.
Football structure
The game graph
Competitions, seasons, stages, matches, teams, squads, lineups, coaches, referees, and succession edges give football-specific context that generic name matching misses.
Provider doctrine
Hard-won source knowledge
Provider namespaces, shared upstream feeds, gender-scoped sources, placeholder rows, score quirks, and historical format changes are captured as data rather than tribal memory.
Quality loop
Canaries and measured releases
Known-answer tripwires, sampled precision checks, coverage scorecards, and release manifests make quality observable as the register expands.
Human review
Defer the ambiguous tail
The clean cases should flow automatically. Ambiguous identity calls become review inputs, then durable examples, so the next similar case is easier.
Modern tooling
LLMs as assistants, not judges
LLMs help investigate residual cases and draft new rules, but deterministic vetoes, source independence, and measured release gates remain the product controls.
How Loom pulls it together
A fixed loop, parameterised by the world model.
L0 describes the football context as scoped records. Loom reads those records and runs the same loop over each slice, changing the rules through data rather than bespoke code.
Describe the slice
A slice is defined by facets such as competition type, tier, gender, locale, era, coverage, and season topology. A Welsh split season and an MLS season should not run through the same assumptions.
Materialise the world model
Loom resolves the scoped L0 records that apply to the slice: provider rules, independence buckets, gate posture, shape families, canaries, and bridge contracts.
Gather and score evidence
Provider rows, names, IDs, dates, teams, matches, and neighbouring relationships are gathered, blocked into candidate sets, scored, fused, and checked for contradictions.
Decide, review, or defer
High-confidence cases mint entities or attach bridges. Conflicts, weak evidence, or ambiguous collisions become review inputs instead of silent writes.
Measure and release
The output is exported as a release with counts, provider roles, schema metadata, checksums, samples, and coverage information for consumers.
World model
Football context is a data dependency.
The world model uses facets such as competition type, tier, gender, locale, era, season topology, and coverage posture. It also captures provider quirks, independence buckets, bridge rules, shape families, and canaries. That lets a domestic league, continental cup, development league, and regional division each get the matching posture they need.
The spine comes first
The spine is the competition-season-stage-match structure. Teams, players, coaches, referees, squads, lineups, and appearances become easier to resolve when their football neighbourhood is known.
Coverage changes the gate
Rich competitions can demand multiple independent sources before a mint. Thin competitions may need single-source canonical-by-necessity with explicit flags. The goal is to avoid demanding evidence the football market does not provide.
Common pitfalls
Where football identity work goes wrong.
The hard problems are rarely about whether two strings are similar. They are about when a row is allowed to create an entity, when a provider ID can attach to one, and when evidence should stay unresolved.
Minting from too little evidence
A single provider row can be enough in thin coverage, but rich competitions should demand independent support. Loom changes the gate with the coverage context rather than applying one global rule.
Bridging as a side-door merge
Attaching a provider ID to an existing entity is an identity assertion. Bridge-only providers are useful for interoperability, but they still need a safe anchor and namespace.
Dedupe by name and DOB
Same-name, same-DOB collisions exist. Date of birth is a strong anchor, not a final proof. Team, role, gender, competition, and source lineage decide whether the risk is acceptable.
Aliases treated as leftovers
A nickname, romanisation, birth name, spelling variant, or provider display label can be the clue that makes future matching work. Reep persists useful aliases with provenance.
Provider brands counted as independent
Two sites can share an upstream feed. Loom collapses shared-upstream providers into independence buckets before counting corroboration.
Competition shape assumed from the name
Domestic leagues, cups, development leagues, continental cups, split seasons, Apertura/Clausura shapes, and regional divisions all create different identity risks.
Provider roles
A provider can be useful without doing every job.
Public provider roles explain how rows should be read in the release. Canonical bridges, bridge-only rows, and overlay rows serve different consumer needs.
Canonical bridge
8 providers currently expose public bridge rows that link source IDs to Reep entities.
Bridge-only
12 providers improve interoperability where present, but are handled conservatively as source evidence.
Overlay-only
33 providers currently provide discovery context rather than canonical bridge rows.
Outputs
What the register produces.
The output is designed for product and data teams: stable IDs for joins, provider bridges for interoperability, aliases for search and matching, relationships for graph context, and release metadata for operational trust.
Entities
Stable Reep IDs for football things: players, teams, coaches, referees, competitions, seasons, stages, and matches.
rp... / rt... / rc... / rm... / rl... Bridges
Provider, namespace, and external ID rows that resolve source IDs to Reep entities without relying on bare integers or slugs.
provider / namespace / external_id / reep_id Aliases and attributes
Public-safe names and selected facts, separated from raw provider payloads and unresolved working evidence.
name / gender / country / date of birth Relationships
Public graph edges for seasons, stages, match sides, squad membership, lineups, coaches, and succession where release-safe.
competition -> season -> stage -> match Coverage metadata
Provider roles, country and region coverage, entity counts, gender/senior/youth/club/national breakdowns, and known gaps.
coverage / provider roles / counts Release artefacts
CSV bundles, API metadata, schema details, checksums, samples, and stamped manifests that make a release loadable and verifiable.
public_bridge_v1 Boundary
What the public release is allowed to say.
- The public register is a projection of the identity graph, not a raw provider mirror.
- Corrections and mapping drops create review inputs; they do not write directly to the register.
- Overlay data helps discovery, but does not become canonical bridge evidence by itself.
- Private working datasets, source payloads, credentials, and unresolved review evidence stay out of the release.
Use it