Geometric Calibration Engine (GCE), Deep Field Orchestrator
Geometric Calibration Engine (GCE)
GCE is the engine behind my own portfolio site. It reads my project, research, and education logs plus a skills registry, and computes a career rank and a 12-field capability map from pure math, no manual grading and no language model call anywhere in the scoring path. I built it to replace a gut-feel seniority claim with a number traceable back to evidence, sensor by sensor. It runs as a build script that recalculates my technical identity from source every time I add a project.
The problem
A portfolio site normally states a seniority level or a skill list by hand, and that claim does not move when the underlying work changes and cannot be checked against anything. I wanted a rank and a set of capability scores that come out of the actual log of what I built, when, how deep, and how often I returned to it, recomputed the moment a new project is added. A weighted sum of skill counts fails fast, since it rewards whoever lists the most skills rather than whoever used them well, cannot tell a skill used once from one used for three years, and cannot say senior in backend, associate in mobile at the same time, which is the real shape of most careers. What was needed was a system that scores structure and repetition, not just volume, separately per field, and that stays honest as the registry itself grows.
Constraints
- ·No manual scoring. Every number had to come from the logs and the registry, never typed in by hand.
- ·No model in the scoring path. The rank had to be explainable with algebra, not a black-box judgment call.
- ·Registry-invariant. Adding a new skill or category to the registry must never shift an existing score.
- ·Headless by rule. The engine carries zero UI code and only produces data for the site to render.
- ·Small, growing evidence base. Roughly three dozen logged entries today, growing one at a time.
- ·Sole engineer, sole subject. I designed, built, and am also the data the engine scores.
Architecture
The live path runs once, left to right: registry and logs are ingested, reduced to 32 sensors, split into a volume-aware model and a shape-only model, then matched against eight rank archetypes to set the global rank. A second pass, the deep field multi-pass, repeats the same three layers once per field, on the subset of projects that actually belong to that field, and writes a per-field maturity value back into the same output file.
- ›Registry + logs: 638 skills, 102 categories, 23 domains, 12 fields in YAML/JSON, plus 39 project, research, and education logs.
- ›Ingestion pipeline: sorts the registry YAML by id, loads registry and logs, and weights each log by context (project, research, education).
- ›Layer 1, atomic sensors: 32 sensors covering volume, temporal, density, repetition, variance, entropy, and velocity.
- ›Layer 2, Model B: an 8-axis semantic embedding built by log-sum composition over the sensors, gated by a churn penalty and a practitioner ratio.
- ›Layer 2, Model C: a 10-dimension structural fingerprint built only from variance, entropy, and correlation, with volume sensors forbidden by rule.
- ›Layer 3, rank inference: concatenates Model B and Model C into an 18-dimension DNA vector and matches it by cosine similarity against 8 hand-defined rank archetypes, gated by a tenure score.
- ›Deep field multi-pass: for each of the 12 fields, isolates projects where that field is at least a fifth of the project's skills, then reruns Layer 1 through Layer 3 on that subset alone.
- ›computed.json: the single output file holding the global rank, the 8-axis capability vector, and all 12 field results. Read by the site UI, out of scope for the engine itself.
- ›Model A: an earlier hybrid scorer using raw ratios and unnormalized covariance, kept in the codebase as a reference but not imported by the current calibration pipeline.
How one request flows
- 01The registry is sorted and loaded. Skills, categories, domains, and the 12-field taxonomy are read from YAML and JSON, and the YAML files are re-sorted by id on every run so the registry stays diffable in git.
- 02Logs are loaded and weighted by context. Every project, research note, and education entry is read. A shipped project counts at full weight, a research entry at 0.4 to 0.6 depending on the sensor and scaled further by depth (surface, deep, published), and an education entry at 0.15 to 0.3, less again while in progress.
- 03Layer 1 turns logs into 32 sensors: volume (skills, categories, domains used), time (career span, active years, recency gap), density (skills per project), repetition (reuse, churn, usage gaps), variance and entropy (evenness of the work), and velocity (growth rate, chronological slope).
- 04Layer 2 turns the sensors into two vectors. Model B combines them into 8 semantic axes such as capacity, momentum, and persistence, gated by a churn penalty and a practitioner ratio. Model C is built only from variance, entropy, and correlation, with every volume sensor forbidden by rule.
- 05Layer 3 matches the combined vector to a rank. The 8 Model B values and 10 Model C values concatenate into an 18-dimension DNA vector, compared by cosine similarity against 8 rank archetypes from Academic to Principal, gated by a tenure score built from career span and skill retention.
- 06The same three layers run again per field. For each of the 12 fields, the pipeline isolates the projects where that field makes up at least a fifth of the skills used, then reruns sensors, Model B and C, and the rank match on that subset alone.
- 07Everything is written to one file. The global rank, the 8-axis capability vector, and all 12 field results land in computed.json, which the site reads at build or request time.
Engineering decisions
Deterministic math instead of a model
What. Every score is a closed-form function of the logs: sums, logs, cosine similarity, entropy. No model call runs anywhere in the scoring path.
Why. A given set of logs always produces the same rank, and any number can be traced back to the sensor that produced it.
Tradeoff. I had to hand-design every formula and every archetype myself, where a language model could have taken a shortcut and inferred a plausible-looking score from a prompt. I chose the harder path because a score I cannot explain is not a score I trust.
Two models instead of one blended score
What. Model B mixes volume and structure. Model C is shape only, with the code forbidding it from touching any volume sensor directly.
Why. Keeping them apart means a large but shallow portfolio and a small but well-distributed one show up differently in the DNA vector Layer 3 matches against, instead of collapsing into one number that volume alone could win.
Tradeoff. Two models to maintain and reason about instead of one, accepted because a single blended score kept rewarding whoever logged the most.
Context-weighted evidence
What. Each log type, project, research, or education, gets its own multiplier for how much it contributes to count, duration, and skill usage. Research is scaled further by depth and education is discounted more while in progress.
Why. A shipped project, a research note, and a course do not carry the same weight as proof of ability.
Tradeoff. Hand-picked constants rather than weights learned from data, fine at this evidence size and worth revisiting at much larger scale.
Churn and retention baked into the vector, not bolted on after
What. A skill logged once and never touched again counts as unverified evidence. That penalty lives inside Model B's capacity axis and inside two of Model C's shape dimensions.
Why. A churny profile should score lower on the vector Layer 3 actually matches, not get a separate discount applied afterward.
Tradeoff. Genuinely deep one-off work looks weaker than continuous work on paper, accepted because repetition is the strongest signal available for real, not theoretical, capability.
A hard tenure gate on top of the shape match
What. A separate tenure score, built from career span with quality allowed to shift it by at most a fifth in either direction, gates which rank can be selected right now.
Why. Shape alone could let a short but intense burst of activity match a senior archetype on paper. No amount of quality lets a two-year career reach Senior, because time is not a shortcutable axis.
Tradeoff. A genuinely exceptional short career is capped by tenure regardless of quality, a deliberate hard gate rather than a soft one.
Two Gaussians instead of one, for selection and for display
What. Selection uses a tight, two-sided Gaussian around the tenure score so the current rank is a genuine best fit for right now. Display uses a wider, one-sided Gaussian, so ranks already passed keep their full match score and future ranks fade in slowly.
Why. Picking the current rank and showing career trajectory are different jobs and needed different statistical treatments of the same tenure score.
Tradeoff. Two separate formulas over one shared score add complexity, accepted because a single compromise Gaussian could not do both jobs well.
Deep field passes instead of one global number
What. The full sensor-to-rank pipeline reruns for each of the 12 fields, on the subset of projects where that field is at least a fifth of the project's skills.
Why. A single rank cannot say senior in backend, associate in mobile at the same time, and that is the real shape of most careers.
Tradeoff. Twelve times the computation per calibration run, a non-issue at this registry size and the first thing to optimize if the evidence base grew by orders of magnitude.
A soft cap instead of a hard ceiling on field maturity
What. Field maturity starts as volume scaled by tenure, capped at the value a rank would normally expect. Above that cap, extra evidence counts through a logarithm rather than linearly.
Why. Exceptional depth in one field can visibly exceed the average ceiling for its rank without the number running away.
Tradeoff. A hard ceiling would have thrown away real signal, and no cap at all would have let volume dominate again, which is what the two-model split was built to prevent.
What changed along the way
- →The first working model, kept in the codebase as a reference and no longer wired into the pipeline, scored careers from raw ratios and unnormalized covariance. It was replaced once ratios alone proved to reward volume over structure, leading to the current split between Model B and Model C.
- →Rank anchors were retuned after adjacent ranks bled into each other. The Associate anchor moved from 0.22 to 0.30 on the tenure scale, and a rule was added that anchors must sit more than one standard deviation apart.
- →Context weighting for research and education was added after an unweighted first pass let a single research note count the same as a shipped, maintained project.
- →The single global score was replaced by the 12-field deep pass once it was clear that a generalist and a specialist should not collapse into one number.
Security and reliability
- ·No network surface. The engine is a local build script that reads files from disk and writes one file back, with no endpoint to secure and nothing to authenticate.
- ·No external call in the scoring path. No model API, no third-party service, nothing to fail, rate-limit, or hand data to at calibration time.
- ·Idempotent by design. Re-running the pipeline on the same registry and logs always produces the same computed.json.
- ·Registry-invariant scoring. Adding a new skill or category cannot shift an existing project's score, by construction of how sensors are normalized.
- ·Fails loud. The ingestion pipeline wraps the run in a try/catch that logs the failure and rethrows instead of writing a partial result.
- ·Malformed logs are skipped, not fatal. A log file that fails to parse is logged as a warning and excluded from that run.
Metrics
What shipped
- ✓Computes a global career rank and a per-field maturity score for all 12 fields directly from the current registry and log set, with zero manual input.
- ✓Keeps scoring registry-invariant, so growing the skills taxonomy never silently moves an existing score.
- ✓Separates volume from shape across two independent models before any rank is matched, so activity alone cannot outscore structure.
- ✓Recomputes deterministically on every run, currently landing at Professional as the global rank, traceable sensor by sensor.
- ✓Runs as a single, idempotent build step with no server, no external API, and no runtime dependency to operate.
Lessons learned
- ·A single blended score cannot represent a real career. Splitting volume from shape into two models was the change that mattered most.
- ·Hard-coded weights are fine at small evidence sizes, but every constant added needed a written reason or it would not be trusted a month later.
- ·Separating best fit right now from trajectory to show needed two different statistical treatments of the same tenure score, not one compromise.
- ·Forbidding a model from touching certain inputs by rule, not just by convention, is what kept Model C honest as the codebase grew.
- ·Being both the builder and the test subject is a real constraint. Every formula change had to be checked against a career known well enough to catch a wrong number by eye.