How HEAT lines up with HUD coordinated entry requirements
Public beta in development. Not for production decision making.
Read this first, because it changes what the rest of the page is. This is HEAT's own reading of what the rules require and of what HEAT does about each one. It is not a HUD determination, not an approval, and not a certification, and no reviewer has signed it. Nothing here is legal advice. Every section number below was checked against the notice or rule it cites, so a reader can open the citation and disagree with us on the record. Where this page and the annual Notice of Funding Opportunity differ, the NOFO controls, and so does anything HUD or a local HUD field office tells a community directly. It is published for the same reason every other page here is published: a tool that asks a community to trust its governance should not keep its own reading of the regulation private.
Several requirements in the notice bind a community's PROCESS rather than any tool. Each row says which it is, so nothing here claims credit for work that belongs to the Continuum of Care.
HEAT is an assessment instrument and decision-support tool. Several CPD-17-01 requirements bind the CoC's process, not any tool. Each row states whether HEAT satisfies the requirement in software, supports the CoC in satisfying it, or leaves it wholly to CoC governance.
HUD Notice CPD-17-01 11 requirements
Notice CPD-17-01, January 23, 2017, "Notice Establishing Additional Requirements for a Continuum of Care Centralized or Coordinated Assessment System". Section numbers verified against the notice itself.
II.B.1 Full coverage
What the notice requires: CE covers the entire CoC geographic area
Where HEAT stands: CoC duty; HEAT is location-agnostic and runnable at any access point, so it never narrows coverage
Where to check it: No geographic logic anywhere in engines
II.B.3 Standardized prioritization in referral
What the notice requires: Prioritization follows documented, publicly available policies consistent with written standards
Where HEAT stands: Satisfied by design: HEAT outputs facts and never ranks; the CoC's written policy is the only prioritization layer
Where to check it: The assessment and prioritization layers are separate by construction; no numeric score exists; the landing page's "HEAT assesses. Your community decides." section; /governance "Where the line is"
II.B.4 Lowering barriers
What the notice requires: May not screen out for: too little/no income, active or past substance use, DV history, service resistance, extent of disability-related supports needed, evictions/poor credit, lease violations/non-leaseholder history, criminal record (limited exceptions)
Where HEAT stands: Satisfied and permanently enforced: no banned factor gates any determination; income/employment excluded from vulnerability entirely
Where to check it: screeningOut.test.ts (runs every commit); construct v2 engine comment; lexical guards
II.B.7 Emergency services
What the notice requires: Emergency services with as few barriers as possible; shelter never prioritized by vulnerability; 24/7 access
Where HEAT stands: Supported: crisis routing is workflow-only and never waitlisted; unsheltered next-step is low-barrier shelter tonight, outside prioritization
Where to check it: IA engine + results scope note ("Crisis response is immediate and never waitlisted"); ID-R5 statement
II.B.10 Safety planning
What the notice requires: Safe, confidential access for people fleeing DV/trafficking; VSP-comparable process; immediate emergency access
Where HEAT stands: Supported: behavior-based situational safety screen (covers trafficking, and never requires self-identification as a victim), consent-based VSP routing with equal-access guarantee, Cat 4 result never printed, quick-exit affordance. v0.65.0 extended this to the whole safety box on the participant copy: the printed page a person is told to keep and carry no longer names a domestic violence referral or the routing preference, both of which stay on the screen. The printed sheet is the only artifact HEAT creates, so it is the only thing that can be found by the person someone is fleeing
Where to check it: safety_fleeing_violence, dv_provider_pref, HC-R3 sensitive handling, quick-exit button, noprint on the participant-view safety detail
II.B.11 Participant autonomy
What the notice requires: May refuse to answer any question or refuse options "without retribution or limiting their access to assistance"
Where HEAT stands: Satisfied structurally: every item requires allowUnknown/allowDecline as schema literals; declines never coerce to "no" and never lower a band
Where to check it: Zod ItemSchema literals; decline-semantics.test.ts
II.B.12 Privacy protections (a-g)
What the notice requires: Consent, right to withhold, no denial for refusal, no forced disability/diagnosis disclosure (f), nondiscrimination-complaint notice (g)
Where HEAT stands: Satisfied in beta (memory-only, nothing transmitted; independently verified 2026-09-01 by instrumenting the browser network layer); diagnosis disclosure never requested (event history only); complaint pointer is a localConfig slot the CoC fills. v0.65.0 added the public statement, which was the gap: the behaviour was right and no page said so, including what the site DOES load (anonymous counts, page-speed numbers, error reports; session replay off everywhere and absent from /assessment; all three gated on Global Privacy Control)
Where to check it: Memory-only mode; PROHIBITED_SCORING_TERMS; appealsContact; /governance#rights and the landing page
II.B.13 Data security
What the notice requires: Data security protocols
Where HEAT stands: Beta: no server storage exists to secure; HMIS-assisted phase will require full protocol
Where to check it: Roadmap phase 3 gate
II.B.14 Assessor training
What the notice requires: Training protocols, at least annual
Where HEAT stands: CoC duty; HEAT supports with in-flow assessor guidance and the published questions page as training material
Where to check it: Mode hints ("read aloud", "ask privately"); /questions
III.C Assessment tools and processes
What the notice requires: Tools should gather only necessary information; phased assessment permitted
Where HEAT stands: Satisfied: necessity test required for every item (each purpose names the determination it feeds); branch-gated modules are the phased design
Where to check it: The purpose field the schema requires on every item; module gating
I.D Non-discrimination
What the notice requires: Fair Housing Act, Sec. 504, Title VI, ADA, Equal Access Rule
Where HEAT stands: Satisfied at the tool layer: protected characteristics permanently excluded from items and scoring; WCAG 2.1 AA target scanned against the 2.2 AA rule set. v0.65.0 published the statement and made the claim measurable: an axe gate over every page, every sample and a full assessment walk in four palettes, blocking on any violation, plus a numeric contrast gate over every design token in every palette. Baseline moved from 165 node-level violations to 0
Where to check it: PROHIBITED_SCORING_TERMS; assurance/a11y-local.mjs; tools/contrast-check.mjs; /governance#rights
The other rules a reviewer will ask about 6 rules
CPD-17-01 is the coordinated entry notice. It is not the only thing a HUD, fair housing or civil rights reviewer opens a tool against. Each row states what HEAT does and where, in the same shape as the table above.
Fair Housing Act (42 U.S.C. 3601 et seq.); Title VI; Section 504; ADA
What it requires: No discrimination on a protected basis in a housing program
Where HEAT stands: Structural: no item collects race, ethnicity, national origin, religion, sex, gender identity, sexual orientation, marital or familial status, so no rule can read one. The single disability item is the yes/no long-continuing-condition question 24 CFR 578.3 requires for chronic homelessness, never a diagnosis
Where to check it: Instrument has no such item; screeningOut.test.ts runs the proof every commit; statement at /governance#rights
HUD Equal Access Rule, 24 CFR 5.105(a)(2) (2012, amended 2016) and 24 CFR 5.106 (Gender Identity, 2016)
What it requires: Serve a person in accordance with their gender identity; no intrusive questioning; no placement on the basis of gender identity
Where HEAT stands: Strongest available position for a tool: HEAT asks nothing that could be used to place anyone anywhere. The rule binds the projects a CoC operates, and HEAT never supplies them a basis
Where to check it: No gender item exists; statement at /governance#rights. Trade-off, published rather than buried: this also means HEAT cannot supply a CoC's own Equal Access documentation or a gender-disaggregated disparity analysis
VAWA 2013 and 2022; 24 CFR 5.2007
What it requires: Confidentiality for survivors; no disclosure that endangers
Where HEAT stands: No PII is collected, nothing is stored or transmitted, so there is no record to breach. The printed participant copy is the only artifact and is designed for the case where a survivor is handed one: Category 4 never printed, and as of v0.65.0 the DV referral line and the routing preference never printed either
Where to check it: hudCategory.sensitive; participant-view noprint on the safety box; quick exit
Title VI LEP; Executive Order 13166; HUD LEP guidance (72 FR 2732)
What it requires: Meaningful access for people with limited English proficiency
Where HEAT stands: Stated honestly rather than claimed: HEAT is English-only today, and until translations exist the adopting CoC carries the interpretation obligation and should plan for it in writing before it starts. Every item is versioned, so a translation ships as an item version rather than a fork
Where to check it: Statement at /governance#rights and on the landing participant card
Section 508 (adopting WCAG 2.1 AA); ADA effective communication
What it requires: Electronic content usable by people with disabilities
Where HEAT stands: Target WCAG 2.1 AA, scanned against the 2.2 AA rule set, gated on every change over 8 pages, 4 sample results, a full assessment walk and 4 palettes, plus a 320px reflow measurement and a numeric token-contrast gate. Nothing is signalled by colour alone
Where to check it: assurance/a11y-local.mjs (blocking); tools/contrast-check.mjs; assurance/a11y-scan.mjs (weekly, deployed)
HUD person-first language practice; SAMHSA and USICH style
What it requires: Wording that describes situations, not identities
Where HEAT stands: Mechanical: a banned/preferred gate over every served page, every render script and the instrument, with defined HUD terms and quoted regulation exempted by rule rather than by hand, and a self-test that proves the gate still catches what it claims to
Where to check it: tools/language-check.mjs (blocking, with --selftest)
Why a tool with no score is the cleanest fit, not a gap
HUD's own CE self-assessment treats scoring as optional (assessment section), while prioritization must rest on documented public criteria (II.B.3). A tool that outputs transparent facts and leaves prioritization to written policy is therefore not merely permitted; it is the cleanest possible fit to the notice's structure.
If a determination is wrong
Procedural fairness requires a documented answer to "this determination is wrong." The pathway: (1) in-flow, any answer can be changed at any time ("Change an answer, nothing is erased") and results recompute deterministically; (2) every result footer renders the CoC's appeals contact when localConfig.appealsContact is configured (production adoption REQUIRES this field), and the CoC's written CE policy names the grievance process (CPD-17-01 II.B.12.g complaint notice); (3) because every determination carries its full reasoning trace and versions, an appeal reviewer can reconstruct exactly what produced the result and which answer to dispute; (4) professional reviewers have the structured disagreement channel, and participant appeals plus professional disagreement both land in the same admin review queue.
Disagree with any row on this page? Use the Feedback button, bottom left. A crosswalk nobody can argue with is a claim, not a check.