Governance · HEAT

The ten HEAT principles

A principle with no mechanism is a slogan. Each one below names the thing in the build that would have to be taken out before it could quietly stop being true, and most of those things fail the build rather than a review. The short version of this list is on the front page.

Placement, not a score. You are never turned into a number. No vulnerability score, no rank, and no queue position exists anywhere in HEAT.What keeps it. There is no scoring code to remove, because none was ever written. Every determination is a named category or a documented status, and the build fails if a scoring vocabulary appears anywhere in the engines.
Person-centered. You choose what to answer, and you can stop at any time.What keeps it. Every one of the 38 questions takes "I do not know" and "I prefer not to answer". That is a schema literal rather than a default, so a question a person cannot decline does not load at all. A decline is reported as declined and never read as "no" (CPD-17-01 II.B.11).
Trauma-informed. Safety answers stay off the printed page, and an emergency gets live help first.What keeps it. The safety screen runs first and routes an emergency to live help before anything else is asked. Safety fields are left out of the printed page and the downloaded record unless someone ticks the box that includes them, and an automated walk prints and downloads a real result on every release to prove it.
Every determination explains itself. Ask why, and the page tells you. Every rule it uses is published.What keeps it. The reasoning trace is a required field on the output, so a result that cannot say what produced it is not a valid result. Every question is published with its evidence and its known risks, and a question with no entry in the Evidence Register fails the build.
Honest about doubt. When the answers cannot settle it, HEAT says so instead of guessing.What keeps it. "Unable to determine" is a determination value like any other, not an error state. Missing information is named as declined, unknown or not asked rather than counted as absence, and a record can carry a range where a single figure would be a claim nobody made.
Nothing you say can screen you out. No answer you give can push you down a list or shut a door.What keeps it. A test that runs on every commit proves that none of the factors HUD prohibits screening on changes any determination, that none of them is asked, and that no question gate reads one (CPD-17-01 II.B.4).
The community decides. HEAT does not pick who comes first. Your community's adopted written standards decide who is prioritized, and in what order.What keeps it. With no score to compete with them, a community's written standards are the only prioritization layer there is. A community's settings live in its own configuration and can never reach a shared engine, and the build refuses a deployment that names neither its adopted written standards nor a contact for asking that a result be reviewed (24 CFR 578.7(a)(9); CPD-17-01 II.B.3).
HUD's rules, named. HEAT follows HUD's rules for these questions, and names them on the page.What keeps it. Chronic homelessness is computed to the definition at 24 CFR 578.3, with the arithmetic shown and the documentation still needed listed beside it. Every requirement in HUD Notice CPD-17-01 is mapped to what HEAT does on the HUD alignment page. That mapping is our reading of the notice and not HUD's ruling.
Plain words. Every page says what it means in words a person can read.What keeps it. Three reading tiers, held by the build rather than by good intentions: grade 6 for everything a person being assessed reads, grade 8 for caseworker and landing copy. Every page also carries a plain-words box under its opening, and this one is not exempt.
Your answers stay with you. Your answers stay on your device. Nothing is saved, nothing is sent, and closing the page erases them.What keeps it. There is no server to store an answer in. A walk of a whole assessment, in all three ways of answering, fails the build if one network request goes anywhere but this site's own origin and a bare counter that carries nothing about anybody (CPD-17-01 II.B.12).

Where the line is

HEAT establishes facts. Your community's adopted written standards decide who is prioritized, and in what order. No vulnerability score, no rank, and no queue position exists anywhere in HEAT. When one opening has six eligible households, the CoC's adopted written standards apply these facts (24 CFR 578.7(a)(9); HUD Notice CPD-17-01 II.B.3 requires prioritization to follow documented, publicly available policy).
Nothing here can screen anyone out. Too little or no income, substance use, domestic violence history, service resistance, evictions or credit, and criminal record can never lower anyone's standing, and an automated test proves it on every change (CPD-17-01 II.B.4).
Declining is never read as "no". Every question takes "I do not know" and "I prefer not to answer". A missing answer is reported as missing, named as declined, unknown, or not asked, and no determination is lowered by nondisclosure (CPD-17-01 II.B.11).
HEAT is not for production use without the community's adopted written standards and a working appeals contact. Every result page says that the order is set by the community's adopted written standards (24 CFR 578.7(a)(9); HUD Notice CPD-17-01 II.B.3) and offers a route to ask for a review of the result under the CoC's own grievance and appeal process (CPD-17-01 II.B.13). Those sentences were prose until v0.69.0, and prose is not a condition. The build tooling now refuses to produce a community deployment whose configuration names neither the written standards nor an appeals contact, unless that deployment declares itself to be scenario testing, in which case it builds and prints exactly what is still missing.
Who answered is recorded on every result. HEAT runs in three modes: a person answering for themselves, an assessor working with the person present, or someone answering on their behalf. Question wording follows the mode, and the mode is printed on the result and carried in the record. What runs on this site is a public preview anyone can open. It is not a coordinated entry assessment of record for any community, and no community has adopted it.

Two statements we will defend

On how HEAT is built: HEAT was developed using modern software engineering tools, but every determination is produced by deterministic rules that print themselves, rule by rule, on the result they produce, and can be independently reproduced. No AI, model, or hidden weight participates in any determination. Identical answers always produce identical results.

On bias: We do not claim HEAT is unbiased; no instrument can honestly claim that. We designed it to minimize avoidable bias, we publish every rule, we test for unintended disparities during pilots, and we change the instrument when evidence shows a better approach. A facially neutral fact like emergency-room visits can become a proxy where care access differs by community; that risk is named in our Evidence Register and tested in our validation plan, not hidden.

Color, and five words that stay separate

Two commitments below are not preferences and are not open to being traded for a better looking screen. They are stated here so that a later version of HEAT can be held to them, including by us.

On color: Color describes the state of the record and the workflow, never the value of the person.

On the five words: Need, eligibility, priority, availability, and allocation are separate determinations and must remain visually and logically distinguishable.

The color vocabulary

Five families, one meaning each, applied the same way on every screen. A color is a sentence about the record, so a color with two meanings is a sentence nobody can read.

Red: act now. Something is unsafe right now. On a result, red is reserved for safety and is used for nothing else.
Amber: look here. The record is incomplete, conflicting, or waiting on something. It is an instruction about paperwork and circumstance, never about the person, and it may never land on a determination.
Green: ready. A requirement of the workflow is satisfied, or a step is settled and complete.
Cyan: information. A stated fact or a determination. Every value a determination can take is drawn identically, so no value is highlighted over another.
Neutral: no active status. Context that changes nothing on its own, and is not asking anyone to do anything.

Every color carries a glyph and a word beside it. Nothing on the screen reports a state in color alone, so a reader who cannot see the difference reads exactly the same record.

The five words

Need. What intervention appears appropriate.
Eligibility. Which programs can serve this household.
Priority. How the community's adopted policy orders access when resources are scarce.
Availability. What can actually be accessed now.
Allocation. What was ultimately assigned.

HEAT today establishes need, and the facts that eligibility is decided on. Priority, availability, and allocation belong to the community: its adopted written standards set the order, its inventory sets what is open tonight, and its staff decide what is assigned. Merging any two of these into one indicator is how a tool begins making policy without ever saying that it did.

Written down before we need it

If HEAT ever displays a community's priority groups, all groups will receive identical visual treatment. Priority will never be traffic-light colored, because a color scale on priority is a score, whatever the labels say. We are stating this while HEAT has no priority display at all, which is the only point at which the promise costs us nothing and is therefore worth making. The same rule is already mechanical for the determinations HEAT does make: a test in the automated suite enumerates every value each determination can take and fails the build if any one value is drawn differently from the others.

The standing controls

Everything versioned, nothing edited in place. Questions, rules, and thresholds change only by new version; every result records the versions that produced it, so any determination can be reconstructed later.
Every determination explains itself. The full reasoning trace, rule by rule, is on every result. There is nothing to reverse-engineer because nothing is hidden.
Automated release gates. An automated suite runs on every change: golden scenarios, a practitioner-reviewable chronicity corpus, simulated people, impossible users, thousands of randomized rule-interaction checks, and a suite proving the factors HUD forbids using to screen people out can never change any determination.
Reading level, gated in three tiers. Everything a person being assessed reads is held below a grade 6 reading level, with no string averaging more than 16 words a sentence; everything a caseworker reads while using the tool is held below grade 8 with no sentence over 20 words; and reference pages like this one are left uncapped so they can say exactly what they mean. All three are checked by the same automated test on every change. The first two tiers were grade 8 and grade 12 until 2026-09-06, when the owner lowered them: grade 8 is the reading level of the middle American adult rather than the floor of it, and both of those surfaces are read under pressure.
A public Changelog that includes our mistakes, with root causes, and an Evidence Register stating why each question exists, what was rejected, and what could go wrong. The repository carries a documented harm analysis for each output: which way a wrong answer fails, what that costs a person, and which error the design is built to minimize.
Structured disagreement. Professionals can file "I would have decided differently" from any result, and participants can change any answer at any time and see the result recompute. Every result page carries a route for saying the determination is wrong, with no dead ends: the CoC's own review contact and appeal process where a community has configured one, and the feedback channel built into the tool where it has not. Both routes land in a review queue.
A standing public challenge. Find a scenario where HEAT reaches the wrong determination; accepted cases join the permanent regression suite before any fix is written, credited by the name you choose to leave.
Planned for pilots: monthly non-punitive expert re-derivation of sampled assessments (the medical M&M model), outcome validation against a published baseline, and disparity monitoring with the pilot community's own data.

This community's settings

HEAT is a static tool. There is no admin screen and no hidden switch: a community's settings live in one configuration file that ships with the build, they are changed by the maintainer under the same review as any other change, and they are printed here so the community and the people it assesses can both see what is on and what is off.

Community. Public beta (no CoC configured)
Configuration version. beta-public-0.4.0
Languages the assessment is offered in. English, Spanish. Every page on this site keeps every language it has.
Answering on someone else's behalf. Offered, and it concludes nothing. A session where the person is not there collects, lists the documentation the file will need, and names what is still open.
Asking for a review of a result. Not named in this configuration yet.
The community's adopted written standards. Not named in this configuration yet. HEAT does not host or read a community's written standards; it records enough to find them.
Scenario testing. Not a community deployment. This is the public beta anyone can open, and it is not any community's coordinated entry assessment of record.

Interventions HEAT may name here

These are the kinds of housing HEAT can raise under Interventions to discuss. A type that is not offered here is left off that list and named in the reasoning trace instead, so the record still says what the fitting option would have been. HEAT holds no bed count and never claims a place is open tonight.

Permanent supportive housing. Offered.
Rapid re-housing. Offered.
Transitional housing. Offered.
Emergency shelter. Offered.
Safe haven. Offered.
Prevention and diversion. Offered.
Street outreach. Offered.

Rights, access, and the rules we hold HEAT to

Every rule named in this section is mapped requirement by requirement, against what HEAT actually does about it, on the HUD alignment page. That page is HEAT's own reading of the requirements, not a HUD determination, and it says so at the top of itself.

Nondiscrimination and equal access

HEAT never asks for, records, or reasons about race, ethnicity, national origin, religion, sex, gender identity, sexual orientation, marital status, or familial status. There is no such item in the instrument and no such field in the record, so no rule can read one. The one disability question is the yes or no long-continuing-condition item HUD's own chronic homelessness definition requires (24 CFR 578.3); HEAT never asks for a diagnosis and never asks anyone to prove a condition. An automated test enumerates the prohibited factors and fails the build if any of them can move any determination.

The rules this is written against: the Fair Housing Act (42 U.S.C. 3601 and following), Title VI of the Civil Rights Act, Section 504 of the Rehabilitation Act, the Americans with Disabilities Act, HUD's Equal Access Rule (24 CFR 5.105(a)(2), 2012, amended 2016) and the gender identity rule at 24 CFR 5.106, and HUD Notice CPD-17-01 I.D. Under the Equal Access Rule a person is served in accordance with their gender identity and is never asked to prove it; HEAT asks nothing that could be used to place anyone anywhere, which is the strongest position a tool can take on that rule.

Monitoring for disparities

HEAT collects no race, ethnicity, or gender, so HEAT cannot check its own results for disparities. That is worth saying plainly, because watching for them is a promise this tool makes. The monitoring belongs to the community, using the HMIS data it already holds alongside the results HEAT produced, and a community adopting HEAT should plan that analysis in writing before it starts, because the tool cannot do that part for it. What HEAT owes that work is a determination that does not depend on those characteristics in the first place, and that half is designed in and measured. In the simulation harness that is re-run whenever anything a determination depends on changes, each synthetic person carries a race tag and a gender tag that no question asks about, the tag is flipped, and the whole assessment is run again from the same seed. The result has to come back identical, byte for byte, and any difference is counted as a violation and reported with the profile that produced it. In the most recent run: 3,000 paired runs per tag, on two different populations, and no differences at all. The automated test suite proves separately, and on every change, that none of the factors HUD forbids screening on can move any determination.

Safety and confidentiality for survivors

The safety questions are behaviour-based and never require anyone to self-identify as a victim. Answering yes routes to a choice about who to work with, and choosing a specialist advocate closes no doors. The safety-related HUD category is shown on the screen and never printed. As of v0.65.0 the same rule covers the rest of the safety box on the page written to the person: it is a page we tell people to keep and carry, and a printed sheet naming a domestic violence referral is exactly the artifact that puts a survivor at risk if the wrong person finds it. Everything stays on the screen, where the person reads it, and the printed copy still routes them to help.

Written against the Violence Against Women Act reauthorizations of 2013 and 2022, 24 CFR 5.2007, and CPD-17-01 II.B.10. HEAT collects no personally identifying information at all, and in public mode nothing is stored or transmitted, so there is no database of survivors to protect. The printed page is the only artifact that exists, and it is designed for the worst case that a survivor can be handed one.

Language access

HEAT is published in English and in Spanish. Title VI and Executive Order 13166 make meaningful access for people with limited English proficiency the obligation of the agency receiving federal funds, and HUD's LEP guidance (72 FR 2732) is the standard a CoC is measured against. Two languages are not language access on their own: a community adopting HEAT is still responsible for interpretation at the point of assessment in every other language, and it should plan for that in writing before it starts. Every question is versioned, and each translated item records the version of the English item it was written against, so a reworded question fails the build rather than leaving a fluent translation of a question that no longer exists.

What the language control in the page header changes when Spanish is selected: everything a person being assessed reads. That is every question, help text, range hint and answer label, in all three administration modes and in the variants for someone under 18 and for someone who has a place tonight, plus the participant page at the end and the copy of that page which prints. What stays in English in this phase: the case manager's half of a result, and every reference page including this one. The mechanism that lets a partly translated screen be honest is still in place and still enforced: a string with no Spanish keeps its English and is marked as English on the page, so a screen reader does not read an English sentence with Spanish pronunciation, and nothing is ever left blank. The list of strings knowingly left in English is empty today, and the build refuses to let that list disagree with the file in either direction.

A community may hold Spanish back for the assessment itself, and that is a setting rather than an accident. HEAT's Spanish is published as a draft: it has not been through certified review or cognitive testing with Spanish-speaking readers. That is an honest state for a page somebody reads about the tool, and it is a weaker one for the instrument, where a mistranslated question changes what a person answers and therefore what the engines determine. Each deployment's configuration says which languages the assessment is offered in. Where Spanish is held back, only the assessment narrows: these informational pages keep both languages everywhere, on every deployment, because a Spanish speaker deciding whether to trust this tool should be able to read what it claims, what it refuses to do and what their rights are. The language control on the assessment page is not hidden in that case. It says why, in English and in Spanish, and it names the condition that opens it: an independent review of the translation.

Three things a Spanish reader can still meet in English, named rather than left to be found. The first is the shared page furniture: the site header, its navigation, and the emergency banner across the top of every page. That block is byte-identical on all eight pages by design and is checked as such on every build, so translating it is a change to how the furniture is built rather than a change to a word, and it is not in this phase. The second is the consistency message the assessment shows when two answers cannot both be true ("this does not fit an earlier answer"). Those sentences are produced by the assessment engine, which is the scored source and is not language aware; the alternative fixes it in the wrong place. The third is the four sample personas' names on the demonstration page, which are also identifiers and tab labels; their banner text, which is the prose a person reads, is in Spanish. All three are recorded in the improvement register under IR-15, and the first two are marked as English where they appear rather than presented as Spanish.

HEAT's Spanish is published as a draft pending certified review, and it says so on the page for as long as that is true. It is professional-quality plain Spanish, written to the same standards as the English and held by the same automated gates in their Spanish forms: a reading-level floor (Fernandez-Huerta 70 or higher, and no string averaging more than 18 words a sentence), the administration-mode voice rules (usted for the person answering about themselves, third person for a person who is not in the room, and gender avoided by construction rather than by a typographic device a screen reader cannot pronounce), and the person-first wording rules. What it has not had is a qualified translator's review, and cognitive testing with Spanish-speaking readers, which is IR-13 repeated in Spanish. Two things are true at once here and both are stated: an unreviewed translation is better than no translation for a person standing at an access point tonight, and it is not the same thing as a certified one, which is what a CoC needs before it relies on this instead of an interpreter. Certification is recorded in the Evidence Register when it happens. Until then, interpretation at the point of assessment remains the community's responsibility exactly as described above.

Reporting a wording problem. A translation is wrong in ways only its readers can see. The route is the same one a wrong result takes: the feedback control at the foot of every results page, which reads "Tell us this result is wrong" in English and "Diganos que este resultado esta mal" in Spanish. It reaches the people who maintain HEAT, it carries no identifying information, and it never counts against the person who sent it or changes their options. Corrections land as a new version of the string, recorded in the changelog like any other change.

Accessibility

The target is WCAG 2.1 AA, which is the standard Section 508 adopts, and the automated scan is run against the 2.2 AA rule set as well. Every page, all four sample results, and a complete walk through the assessment are scanned in four colour palettes on every change, and the build fails on any violation. Colour contrast is measured numerically from the design tokens themselves, in all four palettes, rather than only where a scanner happened to find text. Nothing in HEAT is signalled by colour alone: every state also carries a word and a shape. The assessment can be completed with a keyboard alone, honours reduced-motion preferences, and reflows to a 320px viewport at 200% zoom.

A status report, not a conformance claim. HEAT is measured against WCAG 2.1 Level AA, with the Level AA criteria added in WCAG 2.2 (focus not obscured, focus appearance, target size, consistent help, redundant entry) measured as well, criterion by criterion, in the VPAT 2.5 structure, with the ones that are only partially supported saying what remains. It is published as docs/ACCESSIBILITY_STATUS_REPORT.md in the repository, and it is called a status report rather than a conformance report on purpose: no person who uses a screen reader has tested HEAT, so what the document holds is a thorough machine assessment plus careful reading, and "conformance report" is heard as a finished assessment. What has been verified instead is set out in the next two paragraphs and in the document itself: an automated rule engine over every page, every sample result and a complete assessment walk in four colour palettes with no violations; every contrast ratio computed numerically in all four palettes; a screen-reader semantics suite that reads the accessibility tree, the focus and the live regions after every state change, in both languages; keyboard-only operation of every screen; reflow at 320 pixels, text at 200% and the text-spacing overrides; and the accessibility tree of every screen read by hand against what the screen shows. Renamed 2026-09-04, with no change to any mark or remark. Last reviewed 2026-09-03, against v0.68.0.

How it is tested. Three ways, all of them on every change and all of them able to fail the build. An automated rule engine (axe-core) over every page, every sample result and a complete walk through the assessment, in four colour palettes, with the WCAG rule sets and the best-practice set both enabled. A colour pass that computes every contrast ratio from the design tokens themselves rather than only where a scanner found text. And a screen-reader semantics suite that reads the accessibility tree and the keyboard: after every screen change in the assessment it checks that focus landed on the new heading and that something was announced, that every group of choices has a name, that every hint is reachable as that group's description, that the feedback dialog holds the Tab key and gives focus back, that no decorative glyph is read aloud, and that the English page furniture is marked English when the page is in Spanish.

What is not yet true, said plainly. No person using NVDA, JAWS or VoiceOver has ever tested HEAT. Everything above is the accessibility tree read by a browser, which can tell you that something is announceable and can never tell you that the announcement makes sense when heard. Roughly a third of WCAG is machine-testable; this covers that third thoroughly and reasons about the rest. Testing with people who use assistive technology every day is on the improvement register as IR-43 and is recommended before any pilot with real people. Two smaller limits belong here too: the message shown when two answers cannot both be true is written by the scoring engine and is English in every language, and the page furniture shared by all eight pages is English on a Spanish page (it is marked as English so it is pronounced as English, which is a fix for how it sounds and not for what it says).

Asking for an accommodation, or reporting a barrier. If any part of this site or the assessment itself is not usable for you, or you need it provided a different way, send it through the feedback tool built into every page. That is the route on purpose: it needs no email account, it asks for no name, and it reaches the person who maintains HEAT directly. Every accommodation request and every reported barrier gets a written answer within 10 business days. A barrier is treated as a defect rather than a suggestion, and the fix appears on the Changelog like any other.

What this site knows about you

Your answers stay on your device. Nothing is saved, nothing is sent, and closing the page erases them. There is no account, no server, and no database: the assessment runs entirely in your browser. That claim was independently verified during a security review on 2026-09-01 by instrumenting the browser's own network layer.

On the assessment page, nothing third-party runs at all. As of 4 September 2026 the page-count script, the page-speed script and the error reporter each stop before doing anything when the address begins with /assessment. The script tags are still in the page, because all eight pages carry a byte-identical shell and a gate checks that; the files load and return. The one thing that page does send is a first-party counter, whose entire body is the word "visit" when the page opens and the word "completed" when an assessment finishes. No identifiers, no answers, nothing about any person. A browser test walks a whole assessment in all three ways of answering and fails the release if a single request goes anywhere else.

The price of that, stated rather than hidden: we no longer see how fast the assessment page is in the field, and a crash on it is not reported to us. The route for a broken assessment page is the Feedback button, which is a person telling us rather than a script.

On the other seven pages, what loads is stated plainly rather than buried: anonymous page counts, anonymous page-speed measurements, and error reporting, all of which start only after you interact with the page and none of which can see any assessment answer. Session recording is switched off across the entire site. If your browser sends a Global Privacy Control signal, none of the three load at all.

Three things here depend on a service that is not this site. The Feedback button, the public register of proposed changes and the visit counter in the footer all reach a small API run by the same owner, on a different domain, with its own deployment. It can therefore be unavailable while HEAT is fine, and it degrades in the open rather than pretending: feedback says it could not be sent right now and leaves what was typed in the box, the register says it could not be loaded just now, and the counter stays blank. No answer is ever sent there: the counter's whole payload is the one word described above, and the assessment never waits for a reply, so a session runs and finishes exactly the same way when that service cannot be reached at all.

Answering on somebody else's behalf

HEAT offers a third way to answer, in which a helper answers and the person being assessed is not there. That session produces no determination of any kind. It collects, it lists the documentation a file will need, it names what is still unanswered, and its first line says that nothing has been decided. The reason is not a preference about good practice: HUD's coordinated entry guidance (CPD-17-01, the Core Elements brief, the Management and Data Guide) never mentions proxy assessment at all, and the rules that do speak all point one way. 24 CFR 576.500(e)(5) makes the evidence for the safety-related category an oral statement by the individual or head of household seeking assistance, which somebody who is not present has not given. HMIS FY2026 element 4.19 records an assessment as being about the head of household, with an assessment type of Phone, Virtual or In Person and no fourth option, so filing a proxy session as an assessment states something in the record that is not true. CPD-17-01 II.B.11 and II.B.12(b) give the participant a right to refuse any question and control over what is disclosed, and neither right can be exercised by anyone else: a helper who answers a question the person would have refused erases the one signal that the refusal happened. VAWA (34 U.S.C. 12291(b)(2)), 24 CFR 578.103(b) and CPD-17-01 II.B.10 require survivor-directed confidential access, so the safety routing questions are never asked of a third party, and a safety screen answered yes, "I do not know" or "I prefer not to answer" ends that part of the session with a neutral handoff rather than continuing. None of this rules out collateral information, which the regulations contemplate as documentation throughout: 24 CFR 578.103(a)(4)(iv)(A) describes an oral referral recorded by the intake worker, and 576.500(b) sets the evidence hierarchy third-party documentation sits inside. The line is between collateral information as documentation, which is ordinary, and collateral information as the interview, which no rule in the corpus contemplates. A community configures this per deployment, and a deployment may switch the mode off entirely; the Lowcountry configuration has, because it is the first that will meet real households. The full reasoning, with every citation, is in docs/PROXY_MODE_POLICY.md in the repository. This is HEAT's reading of the rules, not HUD's ruling on them.

Your rights during an assessment

You can refuse any question. Every question takes "I do not know" and "I prefer not to answer", and a refusal never becomes a "no" and never lowers anything (CPD-17-01 II.B.11 and II.B.12).
Refusing cannot cost you assistance. Nothing in HEAT can screen anyone out, and an automated test proves it on every change (CPD-17-01 II.B.4).
You are never asked to disclose a diagnosis. HEAT records events and needs, never conditions (CPD-17-01 II.B.12.f).
You can say a result is wrong. Change any answer and the result recomputes; every result page carries a route for disputing it, and where a community has configured its own review contact and grievance process, that appears on the result instead (CPD-17-01 II.B.12.g).
You can see every rule. The questions, the evidence for each one, and the reasoning behind every determination are public, and each determination prints its own reasoning on the result.
Nobody decides anything about you from a session you were not in. Where a deployment allows someone to answer on your behalf, that session produces no determination at all: it lists the documentation a file will need and what is still unanswered, and it says on its own first line that nothing has been decided. Before anything is decided you go through the answers yourself, or with someone helping you in the room (24 CFR 576.500(e)(5); CPD-17-01 II.B.11 and II.B.12(b); HMIS FY2026 element 4.19).

A community adopting HEAT fills in its own review contact, its nondiscrimination complaint route, and its written standards. Those are the CoC's to hold, not a tool's, and the tool has a place for each of them.

How feedback becomes change

Every flag gets a written disposition. Nothing is adopted silently and nothing is dismissed silently. A suggestion passes five tests before it becomes a question or a rule.

Construct fit. Does it belong to what HEAT measures, or is it policy that belongs to the CoC?
Necessity. Does it change a determination or drive a concrete action, or is it information for its own sake?
Question cost. The instrument has a hard cap of 37 questions, so an addition has to earn its place against everything already asked.
The screening-out rule. Anything added must be provably unable to lower anyone's standing (HUD CPD-17-01 II.B.4), enforced by an automated test.
Evidence and traceability. Adopted changes ship as new item versions with an Evidence Register entry naming the source; declined suggestions get their reasoning recorded too.

The outcomes are adopt, adapt, answer without changing, or defer to pilot data, and the Changelog shows which one every flag received.