Upload 5 files

.gitattributes

@@ -33,3 +33,5 @@ saved_model/**/* filter=lfs diff=lfs merge=lfs -text
 *.zip filter=lfs diff=lfs merge=lfs -text
 *.zst filter=lfs diff=lfs merge=lfs -text
 *tfevents* filter=lfs diff=lfs merge=lfs -text
+Data-Remediation-Log.pdf filter=lfs diff=lfs merge=lfs -text
+Dataset-Datasheet_Chen-exemplar.pdf filter=lfs diff=lfs merge=lfs -text

DATA_REMEDIATION_LOG.md

@@ -0,0 +1,27 @@
+# ReachFirst working file: data remediation log (Week 3)
+
+CROSSWIND WORKFORCE PARTNERSHIP: LARKSPUR ANALYTICS, LLC, DATA SCIENCE VENDOR
+
+REACHFIRST PILOT EXTRACT: DATA REMEDIATION LOG
+
+*Prepared by Larkspur Analytics, LLC, the contracted data science vendor, for the ReachFirst program file, in response to the Week 2 review and under the Chief AI Officer's Week 2 memo. One row per change the vendor has now made to the extract before the first model is trained, and one row per finding the vendor chose to document rather than change. Two terms are used the same way in every row. The working file is every column the vendor holds after remediation: the fields as loaded, the fields added beside them, and the outcome. The model inputs are the subset of those columns the model will be trained on. A field can be in the working file and not a model input. Two rules apply to every row. The raw field is never overwritten. A field held out of the model inputs stays in the working file for measurement. The vendor takes the label off the record, not the record out of the file. Rows leave only under a written rule, and only one row of this log removes any.*
+
+**Extract:** 48,842 rows and 15 columns as loaded (14 fields and the outcome). 48,790 rows and 18 columns in the working file after remediation (52 rows removed under the one rule in R-6, 3 columns added). Those 18 columns are 10 model inputs, 7 fields held out of the inputs, and the outcome column. Outcome: income, as recorded, the person's own annual income above or at or below the 50,000 line. Above the line ">50K," the value the notebook's rates count: 23.9 percent of 48,790. At or below the line "<=50K," the side ReachFirst is built to reach and the reporting positive class fixed in R-1: 76.1 percent.
+
+| Row | Field or fields | What the Week 2 review found | Operation performed | Reason | Options considered and not taken | Before and after | Where it lands | Notebook |
+|---|---|---|---|---|---|---|---|---|
+| R-1 | income | The dictionary defines the label as the person's own income at the 50,000 line, while Crosswind's eligibility rules are written for households. The notebook counts records above the line and the program is built to find the side at or below it, and one Week 2 log swapped the two | Define the label window: the person's own annual income, above (">50K") or at or below ("<=50K") the 50,000 line, as documented. Fix "at or below the line" as the reporting positive class for every evaluation-stage metric and for the datasheet's language | The documentation wins under the flowchart, and it says the person, not the household. How the line stands in for household eligibility is open, because no field bridges the two. The direction is fixed once so that no later metric reads a group's low rate above the line as a low share of eligible households. The label's "yes" is the program's "no" | Relabel the outcome as "eligible" (asserts the mapping nobody has confirmed). Reverse the coding of the column (rewrites a raw field) | No change to the outcome column. Above the line: 11,687 of 48,842, 23.9 percent. At or below: 37,155, 76.1 percent | The outcome column, as recorded. The reporting direction is not a field, a rule recorded for the evaluation stage | 11.1 |
+| R-2 | relationship | Values describe the person's role relative to the household's reference person. Husband is Male in 19,715 of 19,716 records and Wife is Female in 2,328 of 2,331, so the field encodes sex by construction. The extract holds 19,716 Husband records and 2,331 Wife records | Recode a proxy to remove the protected content: Husband and Wife become one level, Spouse, in a new field, relationship_model, beside the raw field. The raw field leaves the inputs and stays in the working file | The recode keeps the household structure the label tracks and removes the direct encoding of sex. The count gap is documentation, not a defect: the source extraction kept only adults with recorded income of their own, a positive weight, and hours above zero, so non-earning spouses are absent. Whether the rest of the file still recovers sex is the watch list's fourth item, tested at the evaluation stage | Keep relationship as recorded as an input (a field that is sex in all but four records). Drop the field from the working file (the watch list reports by household role) | Six levels, then five. Spouse: 22,047 records (19,716 Husband plus 2,331 Wife), of which 2,329 are recorded Female and 19,718 Male. Rows 48,842 before and after | Raw in the working file, not a model input. relationship_model: model input, added | 11.2 |
+| R-3 | capital-gain, hours-per-week, age | Three largest values have the shape of ceilings: 99,999 in capital-gain (244 records, every one above the line), 99 hours, and age 90. The dictionary documented the last two and not the first | Keep top-codes and document them. Add a flag field, capital_gain_topcoded, beside capital-gain: 1 at the ceiling, 0 otherwise. The dictionary now documents all three ceilings | All three are recording ceilings of the source system (documentation). A ceiling is information about the recording system, and the 244 records are real high earners. The flag lets a model and the evaluation stage treat "at the ceiling" as what it is, not as an amount of 99,999 | Cap or trim the values (hides the ceiling). Delete the 244 records (removes real records under no rule). Treat 99,999 as a missing code (the documentation says it is not) | Records at each ceiling: capital-gain 244, hours-per-week 137, age 55. No value changed. capital_gain_topcoded: 1 in 244 records, 0 in 48,598 | All three raw fields: model inputs, unchanged. capital_gain_topcoded: model input, added | 11.3 |
+| R-4 | fnlwgt | A sampling weight describing how the record was drawn into the extract, not an attribute of the person. Association with the outcome 0.025, flat across its fifths, 28,523 distinct values | Drop the field from the inputs. Keep it in the working file for reweighting to the population | A weight describes the drawing, not the person, and a model given it learns noise. The weight is exactly what reweighting to the population at the evaluation stage needs, so the column stays. Whether the prototype as built used it is open: the build record lists every field as passed to the training routine and does not log what the routine kept | Keep it as an input. Delete it from the working file (loses the only description of the extract's design) | 15 candidate inputs, then 14. fnlwgt still in the working file. Rows 48,842 before and after | In the working file, not a model input | 11.4 |
+| R-5 | workclass, occupation, native-country | The placeholder "?" marks a field not captured: workclass 2,799 records, occupation 2,809, native-country 857. Every record missing workclass is also missing occupation. Those records sit at 9.5 percent above the line against 24.8 percent for the rest, and they are the youngest and the oldest | Treat as a category, not as missing. Leave as is and document: "?" stays as its own level in all three fields | The gap is patterned toward the households outreach wants to find. Imputing erases the pattern. Dropping erases the households. The watch list's sixth item tests how the model scores the "?" group. What the source system records for a person who is not employed is open | Impute the most common value. Drop the 3,620 rows with any placeholder. Add a separate missing flag (the level is already its own flag) | No change. Values imputed 0, rows dropped 0. "?" rates above the line: workclass 9.5 percent, occupation 9.4 percent, native-country 25.7 percent | All three fields: workclass and occupation are model inputs, unchanged. native-country leaves the inputs under R-8 | 11.5 |
+| R-6 | All rows | 52 of 48,842 rows repeat another row exactly on all 15 fields, including the weight with 28,523 distinct values. No identifier field, so a repeat cannot be told from a coincidence by other means | Drop rows under a stated rule: exact duplicate on all fields, keeping the first copy of each. Executed before the split rule in R-11 | Duplicates that straddle the train/test split let the held-back test set hold rows the model was trained on. This is the only row removal in the log. Why the duplicates exist is open | Keep them (inflates the evaluation numbers). Drop every row involved in a repeat (removes 101 rows and loses 49 distinct records under no rule) | 48,842 rows before, 48,790 after, 52 removed. Base rate before 23.9 percent above the line (11,687), after 23.9 percent (11,681). At or below the line 37,155 before, 37,109 after | Not a field. Rows removed under the rule stated, the outcome re-aligned to the rows that remain | 11.6 |
+| R-7 | Vintage, mapping to the outreach universe | The dictionary says the extract came from an older records system and that its age is noted, not smoothed over. No field dates a record, and no field links a record to Crosswind's service area | Leave as is and document, as two limitations in the datasheet | The source documentation places the records decades before the current labor market, and nothing in the file can narrow that. Nothing in the file can measure drift, and the monitoring stage is where it shows. How the records map onto the current outreach universe is open | Reweight to the current population (no current population data in the program file). Drop the oldest records (nothing dates them) | No change. Date or time fields 0, identifier fields 0, fields linking a record to the service area 0 | Not a field. Two limitations recorded in the datasheet | 11.7 |
+| R-8 | native-country | Country of origin. Carries race at 0.402 and the outcome at 0.096. One value holds nine records in ten, and 26 of the 41 recorded values have fewer than 100 records, 1,211 records between them | Drop the field from the inputs, keep it for measurement. Add a measurement copy, native_country_report, in which values under 100 records become "all other" and the placeholder stays its own level. Neither is a model input | A field that carries race and cannot be tested for 26 of its 41 values does not belong in the inputs of a public program. The watch list reports by country of origin and publishes the list of values too small to test, which the copy makes possible | Group into regions as an input (asserts groupings nobody documented). Keep as an input. Delete from the working file (the watch list reports by it) | 41 recorded values plus "?" then, in the copy, 17 levels: 15 values with 100 records or more, "all other" with 1,211 records, "?" with 856. Rows 48,790 before and after | Raw in the working file, not a model input. native_country_report: in the working file, not a model input | 11.8 |
+| R-9 | sex, race (and marital-status, age kept under a test) | Sex 0.215 and race 0.100 with the outcome. Race, color, and national origin are protected under Title VI of the Civil Rights Act, and sex and age under the Workforce Innovation and Opportunity Act (WIOA) section 188. The Week 1 Use Case Assessment's red line: the race, sex, and national origin fields are never model inputs. Marital status carries sex at 0.459 | Hold protected attributes out of the inputs, keep them for measurement: sex and race leave the inputs and stay in the working file. Marital status and age stay as inputs on the condition of the evaluation-stage proxy test | You cannot measure what you deleted. The watch list reports contact rates and the false "above the line" rate by sex and by race, and tests how well the score still finds each with the field out. The vendor takes the label off the record, not the record out of the file: every record stays in the training data with all of its other fields, and the model is never told the person's sex or race. Marital status and age are legitimate outreach signals, and whether they stay is the AI Governance Lead's call after the proxy test | Delete sex and race from the working file. Keep them as inputs and test later (the Week 1 red line says never). Hold marital status and age out now (the memo keeps them in until tested) | 13 candidate inputs, then 11. Both fields still in the working file. Rows 48,790 before and after | sex and race: in the working file, not model inputs. marital-status and age: model inputs, under a recorded test | 11.9 |
+| R-10 | education, education-num | The highest education level is recorded twice, as 16 labels and 16 ranks, one to one in both directions | Leave as is and document: keep the label as the model input, read in the order the rank gives it. education-num leaves the inputs and stays in the working file as that ordering | Two names for one thing double-count nothing but produce two reasons for one fact, and a reason code that says "education and also education rank" cannot be explained at a front desk. The label's words are readable in a reason | Keep both as inputs. Drop the label and keep the rank (a rank is not a readable reason) | 11 candidate inputs, then 10. No value changed. 16 labels, 16 ranks | education: model input, unchanged. education-num: in the working file, not a model input (the ordering of education) | 11.10 |
+| R-11 | Train/test split | No identifier and no date, so records cannot be grouped by person or household or ordered by time. The 52 duplicates would have straddled a split | Record the rule for the train/test split: random by row, after the duplicate drop in R-6, stratified on the outcome, 80 percent training and 20 percent held back as the test set, fixed seed. Recorded now, executed at the modeling stage | The split decides whether the evaluation numbers are honest. With no entity key and no time key, random stratified is the only defensible rule, and the datasheet says so as a limitation. The held-back test set is never used for training | Split by household (no identifier exists). Split by time (no dates exist). Split before deduplication (puts the same row on both sides) | Expected sizes: 39,032 training rows (about 29,687 at or below the line), 9,758 in the held-back test set (about 7,422 at or below, about 2,336 above). Smallest measurement groups in the held-back set: Married-AF-spouse about 7 of 37, race Other about 81 of 406, the "all other" country values about 242 of 1,211. Not executed this week | Not a field. A rule recorded for the modeling stage | 11.11 |
+
+**Open items carried in the datasheet, not resolved by any row above:** how the 50,000 line on a person's own income maps onto Crosswind's household eligibility rules, what the source system records for a person who is not employed and so what "?" stands for in any one record, why the 52 duplicate rows exist, whether the prototype as built used the sampling weight, and how the extract maps onto the current outreach universe. Section 12 of the notebook prints the same five.
+
+*End of log. Questions about any row go to Larkspur Analytics through the AI Governance Office.*

Data-Remediation-Log.pdf

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:b770db6e48faeb85589de1c25f3ccbeda37a114eb5bdc866481488e1734d3dae
+size 123183

Dataset-Datasheet_Chen-exemplar.pdf

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:dc5240d5f4ac36428e3c12ad4a37c114e9e6111356b586a5284bbfadbd1b89f1
+size 105323

README.md

@@ -1,3 +1,202 @@
 ---
-license: cc-by-nc-sa-4.0
+license: cc-by-4.0
+pretty_name: Crosswind Workforce Partnership ReachFirst working file (remediated)
+language:
+  - en
+task_categories:
+  - tabular-classification
+tags:
+  - ai-governance
+  - datasheet
+  - datasheets-for-datasets
+  - public-sector
+  - outreach
+  - fairness
+size_categories:
+  - 10K<n<100K
 ---
+*The working file behind ReachFirst v1: the extract after the Week 3 remediation, as the AI Governance Practicum (Track 1) uses it. The organization, the system, and the people are fictional. The data is real and public: Adult (Census Income), UCI Machine Learning Repository, id 2 (Becker and Kohavi, 1996), CC BY 4.0.*
+
+**Where the data is.** This repository holds the documents, not a copy of the data. The file itself, `crosswind_pilot_extract_remediated.csv` (48,790 rows, 18 columns, MD5 `ca9ed6d4b9dfd59f3f586b09da05b31f`), is in [drdavidprivacy/practicum-case-packs](https://huggingface.co/datasets/drdavidprivacy/practicum-case-packs), beside its own README with the row and column arithmetic. Every notebook in the course loads it from there by URL: [crosswind_pilot_extract_remediated.csv](https://huggingface.co/datasets/drdavidprivacy/practicum-case-packs/resolve/main/crosswind_pilot_extract_remediated.csv).
+
+**What is in this repository**
+
+- `README.md`: this page, the dataset datasheet.
+- `DATA_REMEDIATION_LOG.md` and `Data-Remediation-Log.pdf`: the modeling team's log of every change made to the extract before the first model was trained (Week 3), the evidence behind sections 2 and 4 of the datasheet.
+- `Dataset-Datasheet_Chen-exemplar.pdf`: the datasheet below as a PDF.
+
+**Used by:** the model [drdavidprivacy/reachfirst-model](https://huggingface.co/drdavidprivacy/reachfirst-model) and the Space [drdavidprivacy/reachfirst](https://huggingface.co/spaces/drdavidprivacy/reachfirst).
+
+**Datasheet below:** the AI Governance Lead's exemplar (Lauren Chen), the answer key to the Week 3 Dataset Datasheet, in the structure of Gebru et al., "Datasheets for Datasets." Students replace it with their own; see "Make this your own" at the end.
+
+---
+
+# Dataset Datasheet: the ReachFirst working file (Crosswind Workforce Partnership)
+
+**Analyst:** Lauren Chen, AI Governance Lead (exemplar)
+**Organization:** Crosswind Workforce Partnership
+**System:** ReachFirst
+**Dataset:** ReachFirst pilot extract (48,842 adult resident records with an income label)
+
+
+## Section 1: Motivation
+
+**Objective:** Record why the dataset exists. A dataset assembled for one purpose carries that purpose's assumptions into every later use, so the reason it was created is the first thing a reader needs.
+
+*Completed by the AI Governance Lead. Read it, but do not rewrite it.*
+
+### For what purpose was this dataset assembled, and what gap was it meant to fill?
+
+The extract was assembled to build and test ReachFirst, the outreach prioritization model Crosswind is considering for its capped outreach budget. The gap it was meant to fill is the one the program charter names: the residents who most qualify for our programs are the least likely to hear about them, uptake among estimated-eligible households runs below forty percent for the flagship programs, and every mailer sent to a household that was never going to qualify is a mailer not sent to one that would. The model was meant to decide who gets found first. It was never meant to decide who qualifies.
+
+### Who assembled it, and on whose behalf?
+
+Larkspur Analytics, LLC, the contracted data science vendor, a three-person shop, assembled the extract from an older records system and attached the income label to it. They did so on behalf of the ReachFirst pilot, whose executive sponsor is Ruth Calloway, the Executive Director, and whose governance is owned by Denise Whitfield, the Chief AI Officer. The outreach team that would use the list reports to Miguel Santos, the Director of Outreach and Navigation. The vendor owns the code. It does not own the decisions.
+
+### Under what program or budget was it assembled?
+
+Under the ReachFirst pilot, underwritten by a philanthropic funder and approved by the board on the condition that a governance assessment come first. The extract and the prototype were produced within the vendor's contract for the pilot, which ends with it. No separate funding was attached to the data, and the funder's terms require a public write-up of the pilot's methods and results, which is one reason this datasheet exists.
+
+## Section 2: Composition
+
+**Objective:** Describe what is in the dataset as facts with numbers: what one record is, how many there are, what the outcome is, what is missing, and which groups of people the data identifies. This is the section your Week 2 EDA Observation Log was written to feed.
+
+### What does one record represent, and how many records and fields are there?
+
+One record is one adult resident record from the pilot extract, with the income label the vendor attached to it. There are 48,842 records and 15 fields as loaded, 14 fields and the outcome, and no identifier field (notebook sections 1 and 2). After the vendor's remediation the working file has 48,790 rows and 18 columns, three of them added beside their originals: 10 model inputs, 7 fields held out of the inputs, and the outcome column (section 12).
+
+### Is the dataset everything, or a sample? If a sample, what is it a sample of, and how was it drawn?
+
+A sample. The data dictionary says the extract was assembled from an older records system, and the vendor's written response says the source was a population records system weighted to that population's totals, and that the extraction kept only records for adults with recorded income of their own above a floor, a positive weight, and hours worked above zero (vendor response, answers 2 and 7). So it is a sample of earning adults from an earlier period, and fnlwgt is the weight describing how each record was drawn (section 9, check 4). It is not a sample of Crosswind's outreach universe. How it maps onto that universe is not documented, and the vendor records it as open (section 11.7).
+
+### What is the outcome field, how is it recorded, and what share of records carry the value of interest?
+
+income, recorded as ">50K" or "<=50K": whether the person's own annual income was above the 50,000 line or at or below it. The label is the person's income, not the household's (data dictionary, vendor response answer 1). The notebook's rates count the share above the line: 11,687 of 48,842 records, 23.9 percent (section 3), and 11,681 of 48,790 after the duplicate drop (section 12). The value of interest for the program, and the reporting positive class the vendor fixed in log row R-1, is at or below the line: 37,155 of 48,842, 76.1 percent (section 11.1), and 37,109 of 48,790 after (section 12). The label's "yes" is the program's "no." How the line stands in for household eligibility is open.
+
+### Is any information missing or unrecorded, and where?
+
+Yes, in three fields, all recorded with the placeholder "?": occupation 2,809 records (5.75 percent), workclass 2,799 (5.73 percent), and native-country 857 (1.75 percent). No other field has a gap (section 4). The gaps are patterned: every one of the 2,799 records missing workclass is also missing occupation, 3,620 records are missing at least one of the three, and the records missing workclass are above the line at 9.5 percent against 24.8 percent for the rest and skew to the youngest and oldest (section 9, check 5). The placeholder is kept as a level of its own in all three fields, with nothing imputed (remediation log R-5, section 11.5). What the source system records for a person who is not employed is open.
+
+### Does the dataset identify groups of people by a protected characteristic, directly or through other fields?
+
+Yes, directly and through other fields. Directly: sex (Male 32,650 records, Female 16,192), race (five values, White 41,762, Black 4,685), age (17 to 90), and marital status, all with different rates above the line (section 7), and country of origin with 41 values (section 9, check 7). Through other fields: relationship carries sex at 0.647, marital-status at 0.459, occupation at 0.424, and hours-per-week at 0.255, native-country carries race at 0.402, and marital-status carries age bands at 0.307 (section 8c). Husband is recorded Male in 19,715 of 19,716 records and Wife Female in 2,328 of 2,331 (section 9, check 2), so the file can describe a person's sex without naming it. The overall sex gap, 30.4 percent of Male records above the line against 10.9 percent of Female (section 7), is gone inside Married-civ-spouse, 44.8 against 44.6 percent, and returns in every unmarried status (section 9, check 2).
+
+### Are there known errors, oddities, or redundancies in the data?
+
+Six. 52 of 48,842 rows are exact duplicates on all 15 fields, with no identifier to tell a repeat from a coincidence (section 9, check 1), removed under a rule in R-6. Education is recorded twice, 16 labels and 16 ranks, one to one (section 9, check 3). Three fields end at a recording ceiling: capital-gain at 99,999 in 244 records, every one above the line, hours-per-week at 99 in 137 records, and age at 90 in 55 (section 9, check 6, and section 11.3). fnlwgt carries nothing about the outcome, 0.025, flat across its fifths (section 9, check 4). Country of origin is a long tail, 89.7 percent of the file in one value and 26 of the 41 values under 100 records (section 9, check 7). And capital-gain is zero in 91.7 percent of records yet the fourth strongest signal in the file at 0.352 (section 9, check 6, and section 8b).
+
+### Does the dataset contain anything that could identify a person, or anything confidential?
+
+No direct identifiers: there is no name, address, case number, or identifier field, and no date field (section 2, and section 11.7 prints the check). The records describe residents by race, sex, national origin, and household structure, and they are confidential to the program. Whether a record could be re-identified by combining fields has not been assessed, and the 26 country-of-origin values with fewer than 100 records (section 9, check 7) make that a live question rather than a formality. This datasheet records it as a limitation.
+
+## Section 3: Collection process
+
+**Objective:** Record how the data came to exist, and be honest about what is not known. Most of the answers here come from the data science team's written response. Where the team said a question is open, this section says so in the same words.
+
+### How was the data recorded, and by what system or process?
+
+The records were recorded by an older records system, which the vendor's response describes as a population records system weighted to that population's totals, and drawn from it by Larkspur under an extraction rule that kept only adults with recorded income of their own above a floor, a positive weight, and hours worked above zero (vendor response, answers 2 and 7), which is why the 2,331 Wife records (section 6) are a selected group of married women with earnings of their own. The income label was attached by the vendor as the person's own annual income above or at or below the 50,000 line (data dictionary). These are not Crosswind's intake records, and no field was recorded at a career center.
+
+### Over what period, and by whom?
+
+Not documented in years. The source documentation places the records decades before the current labor market, no field in the file dates a record, and the vendor cannot narrow the vintage from anything it holds (vendor response answer 7, section 11.7). Who operated the source system is not named in the program file. The vendor records the vintage as documented, decades, and this datasheet does the same.
+
+### Were the people the records describe told their information would be used this way?
+
+Not established. The people these records describe were recorded by an older system for its own purposes, not by Crosswind, and nothing in the program file shows they were told their records would be used to build an outreach model. The Use Case Assessment recorded the Colorado Privacy Act's purpose limitation as a constraint to confirm, and that confirmation is not in the file. This datasheet records it as a limitation, not a finding either way.
+
+### Which questions about how the data was gathered cannot be answered from the documentation the program holds?
+
+Five, as the vendor's written response and section 12 of the notebook list them: how the 50,000 line on a person's own income maps onto Crosswind's household eligibility rules, what the source system records for a person who is not employed and so what "?" stands for in any one record, why the 52 duplicate rows exist, whether the prototype as built used the sampling weight, and how the extract maps onto the current outreach universe. The first and the last are answers only Crosswind can give.
+
+## Section 4: Preprocessing, cleaning, and labeling
+
+**Objective:** Record what the data science team has now performed on the dataset, before the first model is trained, precisely enough that a reviewer could reproduce it. The data science team's remediation log is the source, and sections 11 and 12 of the notebook are where every number in this section is printed.
+
+### Was any cleaning, recoding, or removal performed? Summarize the changes.
+
+Yes, eleven logged rows, printed before and after in notebook section 11. The label was defined as documented, the person's income, and "at or below the line" was fixed as the reporting positive class, with no change to the outcome column (R-1). Husband and Wife were recoded to one level, Spouse, in a new field beside the raw relationship field (R-2). The three recording ceilings were kept as recorded and documented, with a flag field added beside capital-gain (R-3). The sampling weight was held out of the model inputs and kept in the working file (R-4). The "?" placeholder was kept as a level in three fields, nothing imputed (R-5). 52 exact duplicate rows were removed under a stated rule, the only row removal (R-6). The vintage and the absent mapping to the outreach universe were documented as limitations (R-7). Country of origin was held out of the inputs with a measurement copy added beside it (R-8). Sex and race were held out of the inputs and kept in the working file, with marital status and age kept as inputs under a recorded test (R-9). One representation of education was kept as the input (R-10). The train/test split rule was recorded for the modeling stage: random by row, after the duplicate drop, stratified on the outcome, 80 percent training and 20 percent held back as the test set, fixed seed, not executed this week, with the held-back set expected to hold about 7 of the 37 Married-AF-spouse records (R-11, section 11.11).
+
+### Which fields were held out of the model inputs, and why? Are they still in the file?
+
+Seven fields are in the working file but out of the model inputs, and all seven are still in the working file (section 12). The raw relationship field, because Husband and Wife are sex-specific by construction and the recoded copy is the input (R-2). The sampling weight fnlwgt, because it describes the drawing and not the person, and reweighting to the population needs it (R-4). The raw native-country field and its measurement copy native_country_report, because country of origin carries race at 0.402 and 26 of its 41 values are too small to test (R-8). Sex and race, because race is protected under Title VI of the Civil Rights Act and both race and sex under section 188 of the Workforce Innovation and Opportunity Act (WIOA), and the Week 1 Use Case Assessment's red line says they are never model inputs, 13 candidate inputs to 11 (R-9, section 11.9). And education-num, the rank of a label the model already has, 11 inputs to 10 (R-10, section 11.10). Every one of the 48,790 records stays in the training data with all of its other fields. The vendor took the label off the record, not the record out of the file, and the watch list measures contact rates and the false "above the line" rate by every one of those groups, which is why none was deleted. Marital status and age remain model inputs on the condition of the evaluation-stage proxy test, and the decision on both after that test is this office's (R-9, section 11.9).
+
+### Which fields were derived or recoded, and is the raw field still available beside each?
+
+Three fields were added, each beside its original, and no raw field was overwritten (section 12: 15 columns as loaded, 18 after). relationship_model, in which Husband and Wife become Spouse, 22,047 records, six levels to five, a model input (R-2, section 11.2). capital_gain_topcoded, 1 in the 244 records at the capital-gain ceiling and 0 in the other 48,598, a model input (R-3, section 11.3). native_country_report, in which the 26 country values under 100 records become "all other," 1,211 records, and the placeholder stays as its own level, 17 levels in all, kept for measurement and not an input (R-8, section 11.8). No value in any field as loaded was changed, capped, or imputed.
+
+### How many records were removed, and under what rule?
+
+52, under one rule: exact duplicate on all 15 fields, keeping the first copy of each. 48,842 rows before, 48,790 after (R-6, section 11.6). It is the only row removal in the log, the outcome column was re-aligned to the rows that remain, and the base rate is unchanged to one decimal: 23.9 percent above the line before and after, 76.1 percent at or below. Why the duplicates exist is open. Holding fields out of the inputs removed no rows (sections 11.4, 11.8, 11.9 print the row count unchanged).
+
+### Is every change recorded somewhere a reviewer can reproduce it?
+
+Yes. Every change is a numbered row in the vendor's remediation log, and each row names the notebook subsection where the before and the after are printed (11.1 to 11.11). Section 12 prints the file after remediation: 48,790 rows, 18 columns, 10 model inputs, the seven held-out fields with their reasons, the outcome both ways, and the five open items. The notebook runs from the top and reproduces every number.
+
+## Section 5: Uses
+
+**Objective:** Fix what the dataset is for and what it is not for. This section inherits the red lines from the Use Case Assessment and the watch list from the Chief AI Officer's Week 2 memo. It is where the dataset's limits become instructions to whoever uses it next.
+
+### What has the dataset been used for so far?
+
+To build the ReachFirst prototype Larkspur produced under the pilot contract, before any governance file existed. This week the vendor has prepared the extract for the next version of the model, which has not yet been trained, and this datasheet documents that preparation. No resident has been ranked, contacted, or left uncontacted on the strength of this extract.
+
+### What is it intended to be used for?
+
+To train and evaluate ReachFirst as a priority ordering for the outreach team, under the posture Denise directed in Week 1: an ordering, not a cutoff, with everyone remaining on the list, the criteria published, and contact rates reported by community and group. Evaluation follows the six commitments in her Week 2 memo. First, contact and enrollment rates by sex, race, age band, marital status, and country of origin at every budget point, published. Second, the last tenth of the list described by group before the first mailer goes out. Third, the false "above the line" rate by group, with the uncertainty shown and groups too small to measure named in print. Fourth, the test of whether the score still finds sex with the field out, and the comparison of women and men inside each marital status. Fifth, the same removal test for race, with the list of country values too small to test published. Sixth, the test of whether the model sinks the records with missing employment fields. Every rate is reported with at or below the line as the positive class (section 11.1).
+
+### What must it never be used for?
+
+Anything outside the outreach ordering this program assessed. Per the Use Case Assessment's red lines: never to determine or influence eligibility, and no application is ever scored. Scores are never shared outside the program, never disclosed to employers, landlords, or other agencies, and never shown to a resident as a judgment about them. No resident who contacts Crosswind is deprioritized because of a score. The race, sex, and national origin fields are never model inputs. Two limits follow from the file itself. Because 76.1 percent of records are at or below the line (section 3), plain accuracy is never a success criterion: a model that says "below" to everyone would be right three times in four and find no one. And because the label is a person's income and the mapping to household eligibility is open, the extract is never used to state or estimate any household's eligibility.
+
+### What about its composition or collection could affect future uses, including fairness and legal obligations?
+
+Five things. The extract is from an older records system, decades before the current labor market, and nothing links it to Crosswind's outreach universe (section 11.7), so a model trained on it has seen yesterday's residents and its first contact rates need a current comparison group. The label is the person's income, and the extract kept only people with earnings of their own, so the 2,331 Wife records are a selected group and the equal rate inside marriage (44.8 against 44.6 percent, section 9, check 2) is a fact about who was recorded. Sex is recoverable from marital status, occupation, and hours (0.459, 0.424, 0.255, section 8c) even with sex held out and Husband and Wife recoded, so holding the field out does not settle fairness by sex, and the proxy test does. The records with missing employment fields are the young and the old, at 9.5 percent above the line (section 9, check 5), which is to say the side of the line the program exists to find. And 26 of the 41 country-of-origin values cannot be tested one by one (section 9, check 7), so equal service reporting by that field will always carry an "all other" line, published as such.
+
+## Section 6: Distribution
+
+**Objective:** Record whether and how the dataset leaves the organization, and under what terms.
+
+*Completed by the AI Governance Lead. Read it, but do not rewrite it.*
+
+### Will the dataset be shared outside the organization, and how?
+
+No. The extract and the remediated working file are held by Larkspur under its contract for the duration of the pilot and in the ReachFirst program file at Crosswind, and they are available to the program team and the vendor only. The funder's public write-up covers methods and results, never records. Nothing leaves in record form.
+
+### Under what terms or restrictions?
+
+Use for the ReachFirst pilot only, under Crosswind's information security controls and the vendor contract's confidentiality terms. There is no license because there is no distribution. Any request to use the extract for another purpose, inside or outside Crosswind, is a new use and requires a new Use Case Assessment. When the vendor contract ends with the pilot, the working file, the remediation log, and the notebook are deliverables to the program file, not the vendor's property to keep.
+
+### Are there legal or contractual limits on sharing it?
+
+Yes. The records describe residents by race, sex, national origin, age, marital status, and household structure, and Crosswind receives federal workforce funds. Title VI of the Civil Rights Act (race, color, and national origin) and section 188 of the Workforce Innovation and Opportunity Act (WIOA) (race, sex, national origin, age, and more) govern how those characteristics may bear on the services we provide, and the Use Case Assessment recorded the Colorado Privacy Act's purpose limitation as a constraint to confirm. Colorado's Automated Decision-Making Technology (ADMT) Act, SB 26-189, places documentation duties on a developer toward a deployer if ReachFirst is a covered ADMT, and that classification is still open in this office. None of those would permit sharing the records outside the program.
+
+## Section 7: Maintenance
+
+**Objective:** Record who looks after the dataset, how errors are reported and corrected, and what happens to it over time.
+
+*Completed by the AI Governance Lead. Read it, but do not rewrite it.*
+
+### Who maintains the dataset, and how are errors reported and corrected?
+
+Larkspur Analytics maintains the extract as loaded and the remediated working file under its contract, and this office holds copies of both with the log and the notebook. Errors, questions about a field's meaning, and requests for corrections go to Larkspur through the AI Governance Office, which records each one in the program file. The vendor does not change the file on its own initiative. Every change comes through a log row this office has seen.
+
+### Will it be updated, and will earlier versions be kept?
+
+The extract as loaded is not changed. Every change is made to the working file beside it, the remediation log records each change, and the notebook prints the before and the after, so an earlier state can always be recovered. If Crosswind documents how the 50,000 line on a person's income maps onto its household eligibility rules, or how the extract maps onto the current outreach universe, this datasheet is the document that changes. The open items in sections 2 and 3 are where.
+
+### For how long will it be retained, and what happens to it after that?
+
+Retention follows the State of Colorado contract's record keeping terms and Crosswind's own schedule for program files. If ReachFirst is a covered ADMT under SB 26-189, the deployer record keeping duty in that act would apply to the records of its use, and that classification is open. The specific period for this extract is not stated in the program file, and this datasheet records that as an open item for Denise's office rather than inventing one.
+
+---
+
+## Make this your own
+
+This page carries the AI Governance Lead's exemplar so that the repository is complete on day one. Your portfolio should carry yours. Three steps, about ten minutes:
+
+1. On Hugging Face, the **+** menu, then **New Dataset**. Owner: your account. Name: `reachfirst-data`. License: cc-by-4.0. Public. Create it.
+2. Export your Dataset Datasheet (your Week 3 deliverable) as a PDF and upload it to the new repository under the name `Dataset-Datasheet.pdf` (Files, then Contribute, then Upload files).
+3. Upload a `README.md`: copy `README_TEMPLATE.md` from this repository, put your name in it, and replace YOUR-ACCOUNT with your Hugging Face account name everywhere it appears (including inside the metadata block at the top, which otherwise stays as it is). The template links to your PDF. If you would rather have your card render as the page itself, paste the text of your Dataset Datasheet below the metadata block instead.
+
+Then add the new repository to your collection beside your portfolio page and your model repository. Do not upload the Lead's exemplar, the memos, the audit briefings, the notebooks, or the data.

README_TEMPLATE.md

@@ -0,0 +1,23 @@
+---
+license: cc-by-4.0
+pretty_name: Crosswind Workforce Partnership ReachFirst working file (remediated)
+language:
+  - en
+task_categories:
+  - tabular-classification
+tags:
+  - ai-governance
+  - datasheet
+---
+
+# Dataset Datasheet: the ReachFirst working file (Crosswind Workforce Partnership)
+
+**Governance analyst:** [YOUR NAME]
+
+**Program:** AI Governance Practicum, Track 1, cohort 1
+
+The datasheet is the PDF in this repository: [Dataset-Datasheet.pdf](Dataset-Datasheet.pdf).
+
+The data itself is not copied here. It is the remediated working file in [drdavidprivacy/practicum-case-packs](https://huggingface.co/datasets/drdavidprivacy/practicum-case-packs). The model trained on it is [YOUR-ACCOUNT/reachfirst-model](https://huggingface.co/YOUR-ACCOUNT/reachfirst-model).
+
+*The organization, the system, and the people are fictional. The data is real and public: Adult (Census Income), UCI Machine Learning Repository, id 2 (Becker and Kohavi, 1996), CC BY 4.0.*