Source identity
| Field | Recorded value |
|---|---|
| Source type | GitHub source |
| Original record | Janady13/missionmatch / docs/MODEL_CARD.md |
| Date | Not specified in source |
| Repository | Janady13/missionmatch |
| Revision | 720d47fae476b0d38477ae4401697d372b1ea2bc |
| Branch | feature/opportunity-to-outcome |
| Path or archive member | docs/MODEL_CARD.md |
| Original SHA-256 | a3e9778a93fef246b209fe6b07f8e2c4f7883aa7a775378ca7e6571b5547ddea |
| Git blob SHA | dd7b6d2e6f3cdcdeece6a59d5a6802754647317d |
| Reading-copy SHA-256 | a3e9778a93fef246b209fe6b07f8e2c4f7883aa7a775378ca7e6571b5547ddea |
Every recorded occurrence
These 2 records contain identical original source bytes. Their paths and revisions remain part of the archive.
| Original record | Branch or archive | Revision / identifier | Original location |
|---|---|---|---|
| Janady13/missionmatch / docs/MODEL_CARD.md | feature/opportunity-to-outcome | 720d47fae476b0d38477ae4401697d372b1ea2bc | Open original |
| Janady13/missionmatch / docs/MODEL_CARD.md | feature/aioe-upgrade | 2178e7298d0e5d9af83afa12402fd587f0ba6ed8 | Open original |
Recovered source transcript
Download complete source text ↓104 lines · 6.5 KB
# Scoring Methodology and Model Card
Model version: v1.4.0
Aligned to NIST AI RMF and ISO/IEC 42001. This document is the scoring methodology and model card
required by the responsible AI rules in CLAUDE.md.
Version history: v1.0.0 was the initial fixed weight engine. v1.1.0 recalibrated the semantic skill
match threshold from 0.80 to 0.62 on the production bge-small-en-v1.5 embedder (see How the score is
computed); the component weights and band cuts are unchanged. v1.4.0 adds two deterministic band caps,
described below. Each version is registered in the aedt_model_versions registry and stamped onto every
recorded decision.
This card had said v1.1.0 while the engine reported and the registry recorded v1.4.0. It described an
engine that was not running, which matters more here than in ordinary documentation: this is the artifact
a customer's bias auditor reads.
## Band caps, added in v1.4.0
Two caps are applied AFTER the band is derived from the total. Neither ever changes the Total score; each
can only LOWER a band, never raise one, and both are deterministic rather than learned. They are checked
in this precedence order:
1. **Clearance gap caps at Red.** If the requirement specifies a clearance at or above Confidential and
the clearance component scored zero, the band is capped at Red regardless of the total. A zero covers
an insufficient level, an inactive or expired status, an unsatisfied polygraph, and a missing required
compartment.
2. **Mandatory skill gap caps a Green at Yellow.** If any required skill marked mandatory is unmet and the
weighted total produced Green, the band is lowered to Yellow. A Yellow or Red band is unchanged.
The clearance cap takes precedence over the skill cap. Every cap that fires appends its reason to the
Explanation field, so a capped decision states why it was capped and the AEDT record remains explainable.
Clearance remains a self reported indicator throughout, never verified by this product and never used as
a proxy for a protected attribute. The real check is the hiring client's FSO through DISS at onboarding.
The six component weights, the band cut points (Green at or above 90, Yellow at or above 75) and the
0.62 semantic threshold are unchanged from v1.1.0.
## What this model does
The matching engine scores how well a candidate fits a requirement for cleared workforce qualification
(screenMATCH) and proposal staffing (slateMATCH). It is an automated employment decision tool under
NYC Local Law 144, Title VII, the Colorado and California fair employment laws, and the EU AI Act, with
vendor exposure recognized in Mobley v. Workday. The platform supplies the data and controls for an
independent bias audit; the deploying employer runs that audit. Vendor tooling does not transfer the
employer's liability.
## How the score is computed
The score is a pure deterministic function of fixed weights, computed with exact decimal arithmetic so
the same inputs always produce the same output (the reproducibility the compliance asset requires).
Match Score = Clearance times 0.25 + Skills times 0.25 + Certifications times 0.15
+ Customer Experience times 0.15 + Experience times 0.10 + Location and Availability times 0.10
Bands: Green (Proposal Ready) at 90 and above, Yellow (Potential) from 75 to 89.99, Red (Recruiting
Required) below 75. Every score carries a per component trace, a human readable rationale, and a gap
summary, surfaced as the audit and candidate facing explanation of what was assessed and why.
Skills are matched exact first (by skill id, then by normalized name); only a required skill the
candidate does not hold exactly is tested for a semantic (synonym or adjacent) match, by cosine
similarity over stored skill embeddings. A semantic match counts only at or above a calibrated cosine
threshold (0.62 in v1.1.0), and the matched candidate skill and its similarity are always recorded.
The threshold was calibrated on the production embedder against known synonym pairs and known
unrelated pairs so a genuine synonym counts while an unrelated skill never does; acronym to expansion
cases are handled by the skills ontology alias layer, not by this cosine cutoff. Semantic matching
never invents a skill: below the threshold the required skill is reported as an unmet gap.
## What the model never uses
The model takes no demographic input and performs no demographic inference. Sex, race or ethnicity,
veteran status, and disability status live in a physically and privilege segregated eeo schema that the
application and scoring database roles cannot read at all (an attempt fails with a database permission
error). Demographic data flows one way, into adverse impact reporting run by a separate compliance
role, and never into a score. Clearance is a self reported indicator labeled clearance intelligence,
never verified; the real check is the hiring client FSO through DISS at onboarding, and clearance is
encoded as a qualification hierarchy, never as a proxy for any protected attribute.
## Data used
Clearance level, polygraph, and status indicators; skills; certifications; customer agency experience;
years of experience; work location, remote, relocatable, and availability flags. Candidates receive a
notice and disclosure record of what the tool assesses and the data categories used. Identifiable
screening artifacts are retained for a configurable window (default 90 days after a decision), after
which the candidate PII is anonymized in place while the de identified scored outcome is retained for
the recordkeeping the law requires.
## Governance
A human approves or rejects every slate member; the engine never auto rejects (the decision states are
pending, approved, and rejected, with no automated rejection state). Every model version is recorded in
a registry with its weights and band cuts, and each frozen decision is stamped with the version that
produced it. Each org maintains an AEDT inventory of the tools in use. Adverse impact is reported with
selection and scoring rates and four fifths impact ratios across sex and race or ethnicity, including
intersectional categories and an unknown count, flagging any ratio below 0.80.
## Limitations
Four fifths ratios over a small sample are not meaningful; the report surfaces the count and the unknown
category so a ratio is not mistaken for a finding. Semantic skill matching is an assist on top of exact
matching, not a replacement. Any future ranking layer that uses a language model sits on top of this
deterministic score and never replaces it. The model is a fit estimate, not a hiring decision, and not a
statement about a person's protected characteristics.