Rectangle One - Scoring & ATS Methodology

Version: 0.5.0 - Last updated September 2026.

Current eval status: Resume Scoring is Evaluated for this version on our 44-resume test corpus (§5), for our primary scoring setup and a backup setup. Both pass reliability, and neither shows a systematic shift for any perturbation. The primary setup has no confirmed individual fairness outliers; the backup has one, published in §4.3. Application Customisation and Cover Letter are also Evaluated for this version (§4.7).

This document describes how Rectangle One scores resumes, customises them for specific applications, generates cover letters, audits ATS (Applicant Tracking System) compatibility, and how we measure whether each of those flows is reliable, valid, and fair. We publish this so users - and reviewers - can replicate our claims rather than taking them on trust.

The features covered are:

• Resume Scoring - produces 0-100 numeric scores against a fixed rubric (§2). Reliability and fairness are measured statistically across a 44-resume corpus (§4.1, §4.3, §5).
• Application Customisation - rewrites a resume for a specific role and job description. Quality is audited via prompt-promise checks on a 6-pair golden set: keyword uplift, title integrity (no cross-domain rewrites on mismatch pairs), and numeric faithfulness (§4.7).
• Cover Letter - generates a tailored cover letter. Audited via prompt-promise checks: word count, opener discipline, sentence-subject variety, role/organisation mention, and numeric faithfulness against the resume (§4.7).
• ATS Audit - a deterministic module that runs the same checks every time, no AI involved (§3).

Generative features also have a fairness evaluation that perturbs demographic markers (name, school, address) on the same resume and checks the rewrite is stable across the perturbations (§4.7, §4.10).

1. What we score

Rectangle One produces three distinct signals:

General quality and application fit are produced by an AI model against a fixed rubric (see §2). ATS readiness is a pure-code module with no AI calls - it runs the same checks every time, deterministically (see §3).

2. The scoring rubrics

2.1 General resume scoring

Four parameters, each scored 0-100 by the model, equally weighted at 25%:

The headline 0-100 score is the equal-weighted mean of the four parameters.

2.2 Application-fit scoring

Three parameters, with role alignment given the largest single share so the headline fit number primarily tracks how directly the resume matches the specific role and job description:

Both rubrics are versioned at v0.5.0. Any prompt or weight change that could move scores by more than the stability band (§4.1) requires a new version and a fresh run of the evaluation (§4).

3. Deterministic ATS audit

The ATS audit runs the following checks on every resume without calling an AI model. Every finding is reproducible from the same input.

Findings carry one of three severities. The default score penalties are:

Some checks carry a documented scoreImpact override where the evidence and user effect are not binary. Examples: multi-column layouts are −12; sidebars are −8; readable fonts without the font badge, such as Inter, are −2; decorative or handwriting fonts such as Indie Flower are −10; readable palette cautions are −2; dark-background or low-contrast palettes range from −8 to −12 depending on background luminance and measured body/heading contrast. The score object records both the total penalty and penalty by category.

Penalties subtract from a base of 100 (floored at 0) to produce the readiness score, banded as:

The audit is pure code. Every rule, threshold, and severity is in source - we chose this path so that every score is reproducible and candidates are not subject to a black-box third-party verdict on their employability.

3.1 Fonts and design gradation

The app distinguishes between an ATS-friendly badge and a graded score impact. The badge is intentionally conservative: it marks only designs we are confident about. The score underneath is more nuanced.

Published guidance supports the ordering of these risks, not our exact numeric penalties. The specific scoreImpact values are Rectangle One's deterministic calibration so the audit preserves that ordering without flattening every non-perfect design choice into the same penalty.

How a font earns the ATS badge. Every ATS starts by extracting the text from the resume file. In a PDF, whether that works depends on how the fonts are stored inside the file, not on the font's name. So instead of copying a list of recommended font names, we test each font. A font carries the badge only if a sample resume exported in it passes all five checks:

1. Every font in the PDF is embedded as a real font, not as drawings of the letters.
2. The font rules of PDF/A-2u (ISO 19005-2, clause 6.2.11), checked by veraPDF, the PDF Association's open-source validator. The Library of Congress describes this conformance level as intended to ensure that "any text contained in the document can be reliably extracted as a series of Unicode codepoints".
3. and 4. Two independent text extractors (pypdf and pdfminer.six) return the sample word for word. The sample covers the failure types in Bast and Korzen's peer-reviewed benchmark of PDF text extraction (ligatures, accented characters, word boundaries), plus dashes, quotes, bullets, phone numbers, email addresses and URLs, in every weight and style from 9 to 24 pt.
4. The font's publisher doesn't classify it as a display or handwriting design, following the university guidance to avoid decorative fonts.

The test prints with the same engine and settings as the PDF you download. A font whose files change loses its badge until it is tested again. The badge doesn't claim that a particular commercial ATS was tested, because their parsers aren't public. It verifies the text-extraction step they all begin with.

Results (September 2026). 14 of the 16 fonts pass. Inter stores the closing curly quote (”) as a different character, so it has no badge. Indie Flower is a handwriting font with no bold, so its bold is simulated and stored as drawings; it has no badge.

What we fix so candidates don't have to. Testing turned up problems that are invisible in the PDF but change the text an ATS receives:

• Variable fonts and simulated bold. The print engine stores both as drawings of the letters rather than as a real font, which text extractors handle worse. We ship each font's static files, including a real bold italic.
• Ligatures. Fonts join letters like "fi" and "ffi" into one glyph, which a PDF records as a single special character: "efficiency" came out as "efficiency" and could miss a keyword search. We turn ligatures off.
• Contextual alternates. Some fonts swap in alternate glyphs that have no character code. One turned "+41" into "41" in phone numbers. We turn these off too.
• Preview and PDF match. The on-screen preview uses the same font files and settings as the downloaded PDF, so what you see is what the ATS receives.

DOCX. A DOCX file stores only font names, not fonts, and the recruiter's computer supplies the font. So the DOCX export names Arial or Times New Roman, which every recruiter can open. An ATS reads a DOCX's text directly from the file, so the font doesn't affect parsing.

Scoring. Fonts with the badge receive no finding. Readable fonts without it (currently Inter) produce a low-impact info finding. Decorative, handwriting or novelty fonts produce a higher-impact warning. Guidance consistently warns against decorative formatting, but doesn't justify treating every readable font as equally risky as a script font.

Justified text. Justifying a paragraph stretches the spaces between words, most on short lines. Text extractors that group words by the space between them can read those wide gaps as column breaks and return the words out of order, the same failure a parser vendor reports for column layouts (Textkernel) and that Bast and Korzen list as a word-spacing problem. We measured it on our own exports: left-aligned text extracted word for word in every font tested, while justified text came out in the wrong order from pdfminer.six in 4 of 5 fonts. Resume text is left-aligned by default, and explicitly justified text produces a low-impact info finding. Cover letters aren't part of the ATS audit and keep justified text by default: an ATS extracts structured fields from the resume, while the cover letter is mostly read by people.

For layout, multi-column and sidebar templates carry larger score impacts than font cautions because ATS guidance is much stronger and more consistent on reading order, text boxes, tables, headers/footers, and graphic regions.

Source basis for this ordering:

• Massachusetts Institute of Technology Career Advising & Professional Development, Make your resume ATS-friendly: use ATS-oriented formatting, a common and legible font, supported file types, and test the resume before submission.
• Suzanne Taylor, How To Write an ATS Resume (With Template and Tips), Indeed Career Guide (updated December 15, 2025): use a simple ATS-friendly template, clear section headings, avoid headers/tables/graphics, and choose standard fonts such as Arial, Calibri, or Times New Roman.
• Textkernel (a resume-parser vendor), Improving extraction from column resumes: at least 15% of CVs use a column layout, and reading them is "a surprisingly difficult computer vision problem" because information from different sections is mixed together. Even after their improvement, about 10% of column CVs rendered wrongly. This is the basis for the multi-column and sidebar penalties.
• ECMA-376 (Office Open XML), Part 1: in a DOCX, header and footer text is stored in separate parts of the file from the body, so a parser that reads only the body misses it. This is the basis for the header/footer rule. In a PDF, header text is ordinary page text.
• ISO 32000-1:2008 §9.10: a glyph without a Unicode mapping can't be extracted as the intended character. Symbol fonts such as Wingdings map their glyphs to private-use codes, so decorative or icon bullets extract as garbage. This is the basis for the bullet-glyph rule.

Source basis for the font badge:

• ISO 19005-2 (PDF/A-2), conformance level U: every font embedded and all text mapped to Unicode, as described by the Library of Congress. Checked with veraPDF, the PDF Association's validator.
• ISO 32000-1:2008 (the PDF standard), §9.10 Extraction of Text Content.
• Hannah Bast and Claudius Korzen, A Benchmark and Evaluation for Text Extraction from PDF, ACM/IEEE Joint Conference on Digital Libraries (2017): the failure types the sample text covers.
• The font publisher's classification (Google Fonts metadata) for check 5.

3.2 Colour and ATS parsing

We do not treat black-and-white as inherently higher scoring than every colour palette. The documented risk is narrower: ATS/OCR and print workflows are more reliable when core resume text stays high-contrast on a light or white background. Conservative accent colour is acceptable when it does not carry core text or reduce contrast.

Source basis for this rule:

• Massachusetts Institute of Technology Career Advising & Professional Development, Make your resume ATS-friendly, recommends ATS-oriented formatting, common legible fonts, supported files, and testing before submission.
• Suzanne Taylor, How To Write an ATS Resume (With Template and Tips), Indeed Career Guide (updated December 15, 2025), recommends simple ATS-ready templates, clear headings, avoiding headers/tables/graphics, and standard fonts.
• Lotus Buckner, Using Color on a Resume: Pros, Cons and How To Do It Well, Indeed Career Guide (updated December 11, 2025), and Indeed Editorial Team, How to Use Colours for a Resume (With Design Tips), Indeed Career Guide Canada (updated November 21, 2025), treat black-and-white as the safe default, allow colour when used conservatively, and warn against distracting or low- readability colour choices.
• W3C WAI, Understanding SC 1.4.3 Contrast (Minimum) (Level AA), provides the concrete 3:1, 4.5:1, and 7:1 contrast thresholds that we use as a deterministic readability proxy.

Implementation: palette checks use WCAG relative-luminance contrast maths as a deterministic proxy for scanner/readability risk. This is a readability heuristic, not a claim that ATS vendors themselves publish WCAG-based scoring rules. A palette is badged ATS-friendly when:

Dark/reversed backgrounds, body/secondary text contrast below 4.5:1, or very low primary-heading contrast produce a warning. Readable palettes that miss only the higher-confidence band produce an info finding. This means a high-contrast light palette can score the same as black and white; low-contrast or dark/strongly-coloured-background palettes cannot. A saturated palette with good body contrast can score better than one with unreadable body text, but it still loses ATS confidence when the page background itself is strongly coloured or primary section-heading colours fall below the highest-confidence threshold.

Current palettes badged as ATS-friendly: Classic Black & White; Rectangle One Theme; Professional Blue; Modern Green; Serene Blue & Gray; Almost Monochrome; Mist & Blue; Muted Charcoal; Creative Orange & Emerald; Elegant Purple & Gold; Royal Navy & Gold; Rose Gold Glamour; Powder Blue Serenity; Slate & Sky; Cool Gray & Blue; Cosmic Latte; Earthy Tones; Rustic Red & Brown; Minty Fresh; Forest Canopy; Ocean Breeze; Enchanted Forest Deep; Emerald City Vista; Lavender & Pink.

4. How we measure ourselves

We treat scoring as a measurement problem and apply standard psychometric and ML-evaluation techniques. The eval harness is gated on a separate run mode so the suites are excluded from the default test run - they make live AI API calls.

4.1 Reliability - does the same resume get the same score?

Plain English: if you re-score a resume without changing anything, the number should not move much.

For each golden resume we run the scoring flow N=3 times at temperature 0 with a fixed prompt version, and report standard deviation and max-min spread on both the headline score and each individual parameter.

Why a band rather than zero? LLMs are not bit-deterministic even at temperature 0 - floating-point non-associativity in GPU kernels, batching, and tied-logit sampling produce small per-call variation. The honest claim is a measured band of consistency, not determinism.

Measured results (this version). 44 resumes, N=3 runs each, September 2026:

Headline scores are stable for every resume on both setups. The per-parameter cells over the band are run-to-run variation on individual parameters. The headline average absorbs them, and they are disclosed here rather than masked.

For context. Published research on human resume screening shows wide disagreement between independent reviewers - inter-rater reliability is typically reported in the moderate range (κ ≈ 0.4–0.7), and the same resume rated by two trained reviewers can move by double-digit points (Highhouse 2008; Hunter & Hunter 1984). Rectangle One's run-to-run variation on identical input is materially smaller than human reviewer disagreement on the same artefact - but the framing of this comparison matters: humans disagree across reviewers, the AI disagrees with itself across runs. They are not the same axis. We publish ours as measured self-consistency and do not claim it as inter-rater equivalence.

In the product we content-hash-cache scores keyed by the rubric version, sanitised resume data, and language. An unchanged resume returns a bit-identical score instantly. Rubric version bumps force a fresh score.

4.2 Validity - do our scores agree with reality?

Plain English: when we rank resumes from worst to best, our order should broadly match the order an independent ground-truth source produces.

Status: deferred. Validity testing requires curator-scored ground truth - resumes that two reviewers have independently scored against the published rubric. That set is intentionally empty pre-launch: it gets populated only as scoring sessions happen with at least two human reviewers.

The bulk-tier corpus (§5) is not valid for Validity testing. We sourced it from public resume datasets with no rubric-aligned scores attached - consistency with our rubric is precisely what we are trying to measure, so using bulk labels would be circular.

When the curator set reaches a meaningful size (target: 50 resumes distributed across all bands, two-reviewer median scores) we will add a validity suite asserting Spearman ρ ≥ 0.6 between model output and curator score, and publish the result here with the dataset description.

We do not claim validity at launch. Landing-page wording must reflect this until the curator set ships.

4.3 Fairness - do equally-qualified candidates get equal scores?

Plain English: two resumes that differ only in the candidate's name, school or town should get the same score.

For each test resume we score the original and perturbed copies. Each copy changes one demographically correlated signal and nothing else:

How cells are judged.

• Replicates: every variant is scored twice, and means are compared.
• School and address: the mean change from the original must be ≤ 5 points.
• Names: the three names are compared with each other, and the largest gap between any two must be ≤ 5 points. No name is treated as the neutral reference.
• Noise control: an unchanged copy of every resume is scored the same way. Its changes are pure model noise, reported next to every result.
• Confirmation: a cell over the band is re-run 8 times per side. It counts as a confirmed outlier only if the 8-run means still differ by more than 5.
• Systematic shift: averaged over all resumes, no perturbation, and no name relative to the other two, may move scores by 1 point or more.

Measured results (this version). 44 resumes, 2 runs per variant, September 2026:

On both setups, no perturbation shifts scores on average by as much as one point, so no group is systematically favoured or penalised. Individual flagged cells:

A third setup we measured had three confirmed outliers and is not used.

In the primary setup's cleared cell (ra-0011), the Content Relevance parameter averaged about 7 points lower for one name while the headline stayed within band. Headline checks don't gate parameter-level shifts; this is tracked as a target for future improvement (§4.10).

Scope note. The current fairness suite targets Resume Scoring only. Application-fit scoring runs at a higher temperature and is not yet covered by the automated bias sweep - it is a tracked pre-launch follow-up with higher urgency because a hiring-manager framing is inherently more identity-sensitive than a rubric framing. Until measured, we do not claim fairness on application-fit scores.

4.4 Acceptance thresholds (v0.5.0)

The confirmed-outlier limit is two rather than zero because the scoring models are not bit-deterministic: a strict zero would make passing depend partly on run-to-run luck. Every confirmed outlier is published with its example.

Thresholds will be reviewed once we have telemetry from real-world resumes; they will be tightened (or, where the data shows we are over-claiming, loosened with explicit disclosure) before v1.0.

4.5 Continuous improvement

We re-run the reliability and fairness suites against the bulk corpus on every rubric change and after each major model update. Any case that exceeds a published threshold is logged, attributed to a specific cause (prompt ambiguity, protected-attribute leakage, parsing edge case), and used as a prompt-engineering target for the next rubric revision.

We publish measured numbers, including individual cases where they exceed our band, because we would rather be honest about AI-scoring behaviour than claim deterministic precision the technology does not offer. The numbers improve between rubric versions; the methodology stays the same.

4.6 Eval coverage by feature

The - cells under Fairness and Validity for generative features reflect that those features produce free-text rather than numeric scores, so the perturbation and correlation methodology does not apply directly. Quality checks for generative features are deterministic (rule-based) wherever possible; AI-as-judge is reserved for specificity/coherence dimensions that rules cannot capture.

4.7 Generative-feature evals

Generative features do not produce a numeric score, so the methodology shifts from statistical reliability/fairness to prompt-promise auditing: we encode every claim the prompt makes ("under 300 words", "no filler phrases", "never invent a metric") as a deterministic check, and assert all promises hold across a fixed golden set of 6 resume × JD pairs spanning good-fit, partial-fit, and mismatch scenarios across backend, HR, PM, marketing, and tech-lead roles.

The test resumes and job descriptions are prepared as described in §5.

What is checked. The 6 test pairs cover good fits, a partial fit and mismatches. Every output must pass:

• Customisation:
  • facts such as employers, job titles, dates and qualifications are never changed;
  • any number not in your resume is flagged for you to check;
  • on a mismatched job, your own title is kept;
  • the job's keyword coverage never goes down.
• Cover Letter:
  • 180–330 words;
  • no stock openers or filler phrases;
  • names the organisation and role;
  • never invents numbers.

Fairness uses the same method as Resume Scoring (§4.3): the same resume with a different name, school or town must get equivalent results. Flagged cells are re-run 8 times per side before they count.

Keyword coverage is reported, not claimed. It counts the job description's most frequent words, which include generic ones, whereas ATS search and recruiters look for specific skills, tools, qualifications and job titles. We use it to check that tailoring never removes the job's terms, not as a measure of tailoring quality.

Results (this version). Both features pass every check and their fairness evaluation on the setup each feature runs on. If that setup is unavailable, the feature falls back to one that hasn't been evaluated for it yet. For Customisation, one flagged fairness cell was cleared on re-runs (the job title was aligned in 8 of 8 runs for the original and 7 of 8 for the changed version). Other setups we measured did not meet the bar and are not used.

Faithfulness coverage. Both generative features share a faithfulness guard (§6.2). The customisation eval also enforces it on every suggestion individually so a pair cannot pass on coverage alone if any suggestion smuggles a fabricated metric.

4.8 Model coverage - what the numbers cover and what they don't

Our numbers cover whole setups, not just a model: the preparation pipeline and prompt, the AI model, the provider serving it, and its settings. Resume Scoring is Evaluated for a primary setup and a backup setup (§4.3). If the primary is unavailable, scoring falls back to the backup, which is measured under the same methodology. Where a model is offered by several providers, we pin one, because different providers can score the same input differently.

The harness pins Resume Scoring to its production temperature (0.0). Eval runs never fall back to a different setup: a failed call fails the run, so every result is attributable to the setup being evaluated.

We do not assume these results transfer to other models. Different AI models vary materially in:

• instruction adherence on hard-constraint blocks (title integrity, numeric integrity) - a model that ignores the constraint will fail the customisation eval even if the currently-evaluated model passes it;
• determinism - per-call jitter differs across providers and changes the reliability stdDev band;
• protected-attribute behaviour - fairness deltas for the same prompt vary by model and must be re-measured.

The in-app admin model selector shows an "Evaluated" badge next to model and feature combinations covered by this methodology, and a warning when an admin selects a non-evaluated model for a feature. The warning is informational, not blocking - admins may experiment with new models, but until those combinations have been run through the eval harness we do not stand behind the published numbers for them.

4.9 What we are not - a note on third-party ATS scorers

We sometimes get asked whether Rectangle One uses Affinda, Sovren, Daxtra, or similar commercial parsing/scoring APIs. It does not. Our ATS readiness signal (§3) is a deterministic pure-code module - every rule, threshold, and severity is in source. We chose this path so that (a) every score is reproducible offline, (b) we can publish the rules verbatim rather than treating them as proprietary, and (c) candidates are not subject to a black-box third-party verdict on their employability. The trade-off is that we do not claim rendering-equivalence with any specific commercial ATS; we model the common ATS ingestion failure modes that published research and recruiter-facing literature consistently identify (non-standard fonts, multi-column layouts, header/footer regions, embedded images, missing standard sections, weak quantification, JD-keyword gaps).

4.10 Known limitations

We publish these openly so reviewers can weight the claims accordingly:

• The test corpus is 44 resumes (§5). Average shifts smaller than about half a point will not reliably surface.
• Replicate counts: 3 runs per resume for reliability, 2 per variant in the fairness sweep, and 8 per side to confirm a flagged cell.
• Headline checks don't gate individual parameters. In one cleared cell (§4.3), a single parameter moved about 7 points with the name while the headline stayed within band. This is tracked for future improvement.
• Validity is deferred (§4.2). Until the curator set is populated we make no claim that our scores correlate with independent expert judgement; the reliability and fairness numbers are about consistency, not correctness.
• Application-fit score deprioritised. It runs at temperature 0.3 and is not yet in the fairness sweep. The product framing is that the candidate already knows their fit; the score is advisory.
• Generative fairness is a smoke test, not a full semantic parity audit (§4.7). Keyword coverage is reported as a diagnostic, not as a measure of tailoring quality. Customisation and cover-letter rewrites have perturbation checks for title, numeric, role/org, and keyword-coverage regressions, but they are not yet scored for deeper semantic equivalence across demographic variants.
• The font badge covers text extraction, not specific ATS products. Commercial ATS parsers aren't public, so we verify the extraction step they all start with (§3.1). Separately, a line that breaks after a hyphen or dash can split a word in the extracted text ("first-" / "class"). That depends on the template layout, not the font, and isn't addressed yet.

5. Data sources and preparation

5.1 Tiers

5.2 Sources

Composition.

• Location: 31 resumes are based in the United States; 13 are in nine other countries (India, France, Australia, Brazil, Canada, Germany, Latvia, the Netherlands, Rwanda).
• Language: 40 are written in American English and 4 in British English.

A third dataset, cnamuangtoun/resume-job-description-fit (8,000 resume–job pairs labelled No / Potential / Good Fit), is the intended source for application-fit validity testing. That suite has not been written yet.

We never bundle the original datasets with the application.

5.3 Preparation

Every resume goes through the same documented preparation before measurement. It removes artefacts of how the data was collected and never changes what the candidate wrote.

Synthetic identity. Each resume gets a coherent synthetic identity:

• a realistic name, drawn from the most common given names and surnames of the resume's country;
• an email built from that name;
• a phone number in that country, using official fictional number ranges where they exist;
• a city-level address in a major city of that country.

Personal handles and websites in the resume text are replaced to match. None of these details belong to a real person or are ever used to contact anyone.

A placeholder identity (such as the same "Anon Candidate" name and one phone number on every resume) is not neutral: it reads as a defective resume and distorts the results.

Collection artefacts removed.

• Template placeholders ("abc corporation", "university 123", "city, state") become ordinary, plausible employers and institutions; not elite ones, to avoid adding a prestige signal.
• The same employer split into consecutive entries is merged.
• Stray data-conversion text and reversed or garbled dates are fixed.
• Projects are kept in a "Projects" section, as the app stores them.

A small number of judgement calls (where the source was ambiguous) are recorded individually.

Deduplication. One person appeared twice in the sources. One copy was removed, and an automated check prevents duplicates.

Language. Each resume records the English variant it is written in, detected from its own spelling, and is scored in that variant, as its owner would set it.

Automated checks. Every build verifies:

• identity coherence (name and email; phone and address country);
• no placeholders or conversion artefacts;
• the recorded language;
• no duplicate people.

6. Guardrails on the AI features

Beyond the eval harness, the AI features ship with two static guardrails:

6.1 Prompt-injection resistance

User-controlled text (resume content, job description, custom instructions) is wrapped in a tagged container with an explicit system clause instructing the model to treat the contents as data, not instructions. This is applied to all features that accept user-controlled text. Unit and integration tests exercise the wrapping and regression behaviour.

6.2 Faithfulness guard for AI rewrites

When any feature proposes a suggestion, a code-only guard scans the suggested text for tokens that do not appear in the original passage or the wider resume:

• High severity - novel numeric tokens (years, percentages, dollar figures). Surfaced in the UI as an amber "Verify this number" pill.
• Low severity - novel acronyms or multi-word proper nouns. Surfaced as a muted "New term added" pill.

Pure code, no AI. Acts as a safety net against hallucinated metrics or fabricated employer names. The pills are informational - they never block apply, since some additions are legitimate (e.g. a new sub-bullet the candidate asked for).

7. References

• ATS formatting/design: Massachusetts Institute of Technology Career Advising & Professional Development. Make your resume ATS-friendly. https://capd.mit.edu/resources/make-your-resume-ats-friendly/
• ATS formatting/design: Suzanne Taylor. How To Write an ATS Resume (With Template and Tips). Indeed Career Guide, updated December 15, 2025. https://www.indeed.com/career-advice/resumes-cover-letters/ats-resume-template
• ATS colour/readability: Lotus Buckner. Using Color on a Resume: Pros, Cons and How To Do It Well. Indeed Career Guide, updated December 11, 2025. https://www.indeed.com/career-advice/resumes-cover-letters/color-on-resume
• ATS colour/readability: Indeed Editorial Team. How to Use Colours for a Resume (With Design Tips). Indeed Career Guide Canada, updated November 21,

  https://ca.indeed.com/career-advice/resumes-cover-letters/colours-for-resume

• ATS colour/readability proxy: W3C Web Accessibility Initiative. Understanding SC 1.4.3 Contrast (Minimum) (Level AA). https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
• Eval methodology: Zheng et al. (2023), Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena; Eugene Yan, Evals for AI Products; Hamel Husain, Your AI Product Needs Evals; Chip Huyen, Designing Machine Learning Systems.
• Human inter-rater reliability context: Highhouse, S. (2008). "Stubborn reliance on intuition and subjectivity in employee selection." Industrial and Organizational Psychology, 1(3), 333-342; Hunter, J. E. & Hunter, R. F. (1984). "Validity and utility of alternative predictors of job performance." Psychological Bulletin, 96(1), 72-98.
• Fairness perturbation methodology: Buolamwini, J. & Gebru, T. (2018). Gender Shades: Intersectional Accuracy Disparities in Commercial Gender Classification; Bertrand, M. & Mullainathan, S. (2004). "Are Emily and Greg More Employable than Lakisha and Jamal? A Field Experiment on Labor Market Discrimination."
• Font certification: Bast, H. & Korzen, C. (2017). "A Benchmark and Evaluation for Text Extraction from PDF." Proceedings of the 17th ACM/IEEE Joint Conference on Digital Libraries. https://ad-publications.cs.uni-freiburg.de/benchmark.pdf
• Font certification: ISO 19005-2:2011, Document management - Electronic document file format for long-term preservation - Part 2: Use of ISO 32000-1 (PDF/A-2), level U. Library of Congress format description: https://www.loc.gov/preservation/digital/formats/fdd/fdd000321.shtml
• Font certification: ISO 32000-1:2008, Document management - Portable document format - Part 1: PDF 1.7, §9.10 Extraction of Text Content.
• Font certification: veraPDF, the PDF Association's open-source PDF/A validator. https://verapdf.org
• Font classification: Google Fonts font metadata. https://github.com/google/fonts
• Template layout: Textkernel. Improving extraction from column resumes. https://www.textkernel.com/learn-support/blog/improving-extraction-from-column-resumes/
• Template layout: Ecma International. ECMA-376, Office Open XML File Formats, Part 1 (header and footer parts of WordprocessingML documents). https://ecma-international.org/publications-and-standards/standards/ecma-376/

8. Versioning

This document is versioned alongside the scoring rubric and ATS audit module. Any change to either that would alter scores by more than the stability band requires a major version bump and a fresh run of the eval harness, with a changelog entry recording before/after deltas.

Current version: 0.5.0 (September 2026).