Get a worker-built app approved¶

Stage 2 of 8: intake

To get a worker-built app approved, fill in a short intake form before you share it, or before it uses more than public data or your own files, reaches the internet, sends messages, or writes to anything shared. The form asks a few things about the app, then the six tier questions, and shows follow-ups only where your answers need them. You get a risk tier and one of four answers (approved, approved with conditions, build with IT, or no, with a reason) within five working days, a target we'll measure. Sandbox experiments need only your registered sandbox workspace.

Who this is for

Builders, whether you vibe-code with an AI app builder (see what vibe coding means for a business) or write code with a coding agent, who want to share or extend an app; and the enablement lead, who triages intake requests and sets up the form. You get the form, what happens after you send it, what must exist before intake opens, and how requests are triaged. Reading time: about 15 minutes.

Do I need intake?¶

You need intake the first time any of your answers to the six tier questions would be (b) or higher. Until then, you're in Sandbox and your registered sandbox workspace covers you. The usual first triggers are:

You share the app with anyone else, even one colleague.
It uses data beyond public data or your own work files, or your own files hold anything Confidential or Restricted (customer details, HR records, pay, health, bank or card data, credentials).
Someone can reach it from the internet without company sign-in: a public URL, "anyone with the link" sharing, a public form, or publicly readable storage.
It writes to anything shared: a shared spreadsheet, a team mailbox, a CRM, ERP, HR or ticketing system.
It sends messages or takes actions outside itself: emails or chat messages to anyone, payments, deletions.
Other people's work stops or goes wrong if it does, or it scores, ranks or flags people (for example applicants or staff), even if only you use it.

These are examples, not the whole test. If you're unsure, run through the six questions: any answer above (a) means intake.

After intake, come back and update your answers whenever the app gains users, data, reach, permissions or an AI feature. Automations, scheduled jobs and agents count as apps.

Don't: register every sandbox experiment

Sandbox experiments are registered once per builder, as a workspace, not one by one, and they don't go to a committee. Asking for a form or a meeting for every throwaway prototype teaches builders to skip the process. Thoughtworks notes that AI lets noncoders build software themselves "instead of waiting for the IT department to get around to their requirements"¹. Sandbox has its own guardrails: a 90-day time-box, private by default, approved tools only (see the Sandbox rules).

Don't: skip intake for a spreadsheet

Unregistered spreadsheets in a decision path have caused real damage (AP17). In October 2020, England's public health agency left 15,841 positive COVID-19 cases out of its reports because of a row limit in an old spreadsheet file format used in a data load². How an app was built doesn't change what it does. Spreadsheets with formulas and macros go through intake like any other app.

The intake form¶

The form has three parts: about the app, the six tier questions and two flags, then follow-ups that appear only when an answer needs them.

How long it takes. Be honest with builders: the first time, read carefully, expect 15–20 minutes, mostly on the data question and the kill criteria. A simple app on internal data, or a builder's second form, takes much less. The under-10-minute target (A-031) is a hypothesis for a form built the way the next section describes; time it in your pilot.

Build the form so it's quick to answer¶

Copy the question and answer wording exactly into your form tool; paraphrased questions drift and stop mapping to one tier. You can still make it fast:

Show each answer as a short label, with the full wording one click away. For example, show "(b) Internal data, or people's business contact or work-admin details" and expand the full Q1(b) text on click. The full text stays the answer; the label is only a handle.
Skip what doesn't apply. If Part 1 says the app doesn't call an AI model, hide the AI follow-ups. If it doesn't run on its own, hide the agent follow-ups. If Q5 is (a), hide the human-review questions.
Explain jargon in place. Link each term to its glossary entry: system of record, data classes, OAuth grant, deny-by-default, the trifecta, meaningful human review and the audit-scope flag. SSO means company sign-in. The general ledger is the company's main accounting record; a reconciliation is a check that two records agree.
Let builders save and come back. Kill criteria take thought; don't lose the rest of the form while someone thinks.
Time it. Before the pilot, time five real builders completing it, and publish the median against A-031.

Part 1: about the app¶

App name and one sentence on what it does and for whom (copy it from the spec you wrote, if you have one).
Builder (role), proposed app owner (role, with a named successor) and team.
The tool or platform it's built on, and where it runs.
Does it call an AI model while it runs? (yes / no) A tool's built-in AI features count, such as an AI formula in a spreadsheet or an AI step in a workflow tool, when they process the app's data at runtime. AI used only to write the app doesn't count. Yes opens the AI follow-ups. A built-in feature that's already on the approved-tools list for your data class needs no separate approval.
Does it run on its own (on a schedule or trigger) or chain tool calls? (yes / no) Yes opens the agent follow-ups, and you list its identity and every grant now, before the six questions, because you answer those questions for every grant.
Kill criteria and a retire-by date. What result would make you stop, and the date by which the app is retired unless it's renewed. Many AI projects are stopped before production (42% of companies abandoned most of their AI initiatives in 2025, in one S&P Global survey³), so plan the exit now.

If item 4 or 5 is yes, also answer these now (they decide the trifecta rule):

Does it read content from outside the business, or content anyone can write to? For example email, web pages, uploaded files, tickets or form submissions.
Can it send anything out? For example email, web requests, links or images it renders, or files in public storage.
For an agent or automation: whose identity it runs under (a person's or a service identity), every OAuth grant and token it holds, and its schedule or trigger. If the tool lets you scope a token (for example read-only), scope it first.

Part 2: the six tier questions and two flags¶

Answer for what the app can do with the data, reach and permissions it holds, not for what it's meant to do. For an agent or automation, answer for every permission it has been granted. Pick one answer per question. The tier is the highest answer or modifier; never add them up. Answers marked (legal) are set by a legal trigger and can't be downgraded. The wording below is the form; the rules behind each answer, and why it sets that tier, are on the six tier questions.

FormPlain text to copy

Answer for what the app CAN do with the data, reach and permissions it
holds, not for what it's meant to do. For an agent or automation, answer
for every permission it has been granted. The tier is the highest answer
or modifier.

Q1. Data. What's the most sensitive data the app reads, stores or sends?
(a) Public data, or your own work files that contain nothing listed in (c) or (d). "Your own work files" means files you created yourself, or exports you're entitled to use for your own job, that you don't share with anyone and that nobody else relies on. Receipts and statements for your own expenses are own work files even when they show a truncated card number -> Sandbox
(b) Internal: non-public business information, including information that identifies people only by business contact details (name, job title, work email, work phone, employer), including the business contact details of customer, prospective-customer and supplier staff, or by staff work-administration details (role, team, work location, shifts, leave dates but not the reason or type of leave, desk or room bookings, start date, equipment, training completion). The prices on individual invoices, purchase orders and quotes are (b) -> Team (legal where the information identifies people)
(c) Confidential: any other information about identifiable people, including everything beyond business contact details about customers, consumers, applicants and patients, and staff HR records (pay, benefits, performance, discipline, leave reasons and leave types, home contact details). This includes the sensitive categories (health or insurance-claim data, bank account numbers, truncated card numbers other than on your own expense receipts, government ID numbers, biometrics, precise location, children's data) and commercially sensitive data (price lists, margins, contracts and their negotiated terms, supplier bank details) -> Important (legal for the sensitive categories)
(d) Restricted: other people's sign-in credentials (passwords, PINs, security answers, account access codes) that the app collects or stores; full payment card numbers or card security codes; or patient or health-plan-member health information, if your business is a health-care provider, a health plan, or a vendor handling that information for one (your privacy officer can confirm) -> Critical (legal floor Important)
The app's own keys and tokens aren't data for this question, but the data they can read is: answer Q1 for everything the token can read.

Q2. Users. Who uses it or relies on its output? People who only receive messages from it (reminders, notifications, emails, replies) are answered under Q6, not here.
(a) Only you -> Sandbox
(b1) People in one team -> Team
(b2) Several teams or the whole company, all inside the business -> Team. If that app holds Confidential data or a business process depends on it, Q1(c) or Q4(c) makes it Important; Q2 doesn't need to.
(c) Anyone outside the business (customers, applicants, suppliers, partners, the public) -> Important (legal)

Q3. Reach. Can someone reach it from the internet without company sign-in?
(a) No. It's reachable only after company sign-in (SSO), or only inside the company network -> Sandbox
(b) Yes: a public URL, "anyone with the link" sharing, a public form, or publicly readable storage or database -> Important, and it may run only on an approved public-facing hosting pattern

Q4. Dependence. What happens if it stops, or gives wrong results, for a day?
(a) Only your own work is inconvenienced -> Sandbox
(b) The people who use it work around it -> Team
(c) A business process stops or produces wrong results, or its output feeds a system of record, a report, a reconciliation or a control, but a person re-performs that output or checks it against the system of record before it's used -> Important
(d1) Its output is posted to the general ledger or financial statements, or is itself the evidence for an account reconciliation or a control your auditors test, without being independently recomputed -> Critical (legal). Output a person re-performs or checks against the system of record before use is (c), not (d1).
(d2) It directly produces regulatory or legal filings, safety-related actions, or customer transactions with no person checking each output before it takes effect -> Critical

Q5. Decisions about people. Does its output decide, rank, score, recommend or flag anything, or produce a score, ranking, flag, summary or recommendation that a person relies on to decide, about a person's job (hiring, firing, promotion, performance rating), pay, discipline, credit, insurance, housing, education, health care, or access to public benefits?
(a) No -> Sandbox
(b) Yes, and every outcome is reviewed before it takes effect by a person who meets the meaningful-human-review test -> Important (legal), plus the notice, explanation and review controls on governance/automated-decisions
(c) Yes, and an outcome can take effect before that review happens -> Critical (legal), plus graduation
This applies whether or not the app uses AI. Calculating an amount under a fixed, documented rule (a commission plan, a published rate card) isn't a decision about a person; answer Q4 and Q6 for it instead.

Q6. Actions. What can it do without a person approving each action?
(a) Nothing beyond itself: it reads, calculates, shows, or drafts for a person to act on -> Sandbox
(b) It writes to its own data store, or sends messages to colleagues -> Team
(c) It writes to a shared system of record (CRM, ERP, HR system, ticketing), or sends automated messages to people outside the business -> Important
(d) It moves or commits money, deletes records, changes records in bulk (more than the change cap, which defaults to 100 records per run), or takes any action it can't undo -> Critical

Jurisdiction flag. Does the app handle information about people in Quebec, the EU or the UK, or about staff who work in the EU or UK, or is an AI feature's output used in the EU? If you don't know, answer yes. Yes -> route to counsel before building (tier unchanged).

Audit-scope flag. Does the app produce records used to show a control works (access reviews, change approvals, incident logs, vendor reviews, onboarding and offboarding records)? Does it help deliver a service covered by a SOC 2, ISO 27001 or similar attestation? Does it hold admin rights, or bulk read or write access, to a system in audit scope? Does it touch data that flows into the ledger, financial statements or a financial control? If you're not sure, ask your compliance or security lead. Yes to any -> route to the compliance owner (tier unchanged).

Your provisional tier is the highest answer or modifier from Parts 1 and 2: the highest tier any of the six answers gives, raised to Critical if the AI follow-up shows customer-facing AI (M2). Full reasons for each answer are on risk tiers.

Don't: ask more before the builder sees a tier

Don't put extra tier questions ahead of the six. Part 1 asks only what the six depend on (what the app is, whether it uses AI, whether it runs on its own and with what grants). The builder should see a provisional tier after Part 2, and then answer only the follow-ups their answers trigger. Every question you add up front raises the time to complete and the chance of abandonment (A-031).

Part 3: follow-ups (only when an answer needs them)¶

Shown when	Ask
Part 1 item 4 is yes (it calls an AI model while it runs)	Which model or service, and is it approved for the data class you named in Q1? (If not, the app is blocked until it is. A tool's built-in AI feature that's on the approved-tools list for that data class already meets this gate.) Does model output reach a customer, applicant or member of the public without a person approving each output? (If yes, the app is Critical: M2.) See AI features.
Part 1 item 4 or 5 is yes, and the app reads private data, reads outside content and can send something out	All three legs of the trifecta are present. Floor 1 is broken: the app can't run until one leg is removed. Say which leg you'll remove.
Part 1 item 5 is yes (agent or automation)	Confirm Q1–Q6 were answered for every grant listed in Part 1, not just the ones it uses.
An answer comes from a token the tool can't scope	Which endpoints the code calls, and where the token is held. If it isn't an agent, has no AI feature, calls only read endpoints and holds the token in a secrets manager (or a platform server-side secret store that meets the conditions there), the enablement lead checks standard downgrade 3.
Q5 isn't (a)	The decision it supports and who it affects. For the reviewer: (1) do they know how to interpret the output, (2) do they review it, (3) do they consider other relevant information, and (4) do they have authority to change the decision? Any "no" makes Q5 ©. For California discipline or termination decisions from 1 Jul 2027: does the reviewer corroborate the output with the underlying data or other evidence, and where is that evidence kept? No corroboration makes Q5 ©. (This site's rule is deliberately broader than SB 947's own trigger; see meaningful human review.)
Jurisdiction flag is yes or don't know	Routed to counsel before building, through the counsel route. Name the people or region if you know them.
Audit-scope flag is yes	Routed to the compliance owner before go-live. Name the service, attestation or control the app supports, if you know it. The compliance owner's change-management and evidence requirements apply at whatever tier the app is, Team included; an audit-scope app gets no minimum tier.
The app collects biometric identifiers, data about anyone under 18, or consumers' health or other sensitive data (other than Q1(d) health information)	Routed to counsel before collecting, through the counsel route; consent-before-collection laws apply.
You're not sure whether Q4(d1) applies	Ask your finance controller before you build: "Is this app's output posted, or kept as reconciliation or control evidence, without anyone recomputing it or checking it against the system of record?" Yes is (d1); no is ©.
You're not sure whether Q1(d)'s health-information answer applies	Ask your privacy officer whether your business is a health-care provider, a health plan, or a vendor handling health information for one.
Q1 is © or (d)	The data owner (role) who will sign off on the app using this data.

If your app helps decide things about people¶

Not legal advice

Not legal advice. This page summarizes laws as of October 2026 for a general audience. It was written with an AI legal-research persona and hasn't been reviewed by a lawyer for your situation. Ask your counsel.

Q5 is the screen for automated-decision laws, and it applies whether or not the app uses AI. A "yes" can bring duties such as notice, an explanation after an adverse outcome, a way to correct data, and review by a person who can change the outcome, depending on where the people are and on each law's scope and thresholds. As of October 2026, the rules that most often reach a North American business are the California CCPA automated-decision rules (from 1 Jan 2027)⁴, California's FEHA automated-decision system regulations (since 1 Oct 2025)⁵, Colorado SB 26-189 (from 1 Jan 2027)⁷, NYC Local Law 144⁸, Illinois HB 3773 (since 1 Jan 2026)⁹, Ontario's job-posting disclosure rule (since 1 Jan 2026)⁶, California SB 947 for discipline and termination (from 1 Jul 2027)¹⁰, Quebec Law 25 s. 12.1¹⁴, GDPR Article 22 where EU people are involved, and the federal adverse-action rules. Who each one covers and what it requires is on apps that make decisions about people.

The two federal adverse-action rules aren't the same. Under ECOA and Regulation B, a creditor that takes adverse action must give the applicant the specific principal reasons for it¹³. Under the FCRA, a business that takes adverse action based in whole or part on a consumer report must give an adverse-action notice: the consumer reporting agency's contact details, the consumer's rights to a free copy of the report and to dispute it, and, when a credit score was used, the score and its key factors. The FCRA doesn't itself require a statement of reasons¹¹. An employer using a consumer report must also give the applicant or employee a copy of the report and a summary of their rights before taking the adverse action¹².

The controls for a Q5(b) app are on apps that make decisions about people. See also the EU AI Act and worker-built apps and US and Canadian laws for AI-built apps. We expect builders to recognize a consequential decision when it's listed in plain words, but that's untested (A-008). When triaging, ask about "helper sheets" that rank applicants, flag staff for review or suggest credit limits.

How long does app approval take, and what are the answers?¶

You get your tier and one of four answers within five working days of a complete form. That's a target we'll measure in the pilot (A-030).

Answer	What it means
Approved	Go ahead under your tier's gates.
Approved with conditions	Go ahead once the listed conditions are met, for example a scoped credential, an approved hosting pattern, or data-owner sign-off.
Build with IT	The app is Critical, or needs something only IT can run. IT co-owns it through graduation.
No, with a reason	It can't be built as described. The reason says what would change the answer.

If you haven't had an answer after five working days, escalate to the enablement lead. Counsel and compliance gates can add time; the enablement lead tells you when a gate is holding your request. For Important apps, the technical check also targets a five-working-day wait (A-042).

What must exist before intake opens¶

The form alone is enough to tier an app, but not to approve one: each gate the tier opens needs somewhere to go. Before intake opens, the enablement lead checks that each of these exists in your business. A spreadsheet or a shared document is enough to start.

Item	Owner (role)	What it's for	Where this site covers it
An app registry with the app-record fields	enablement lead	recording every answer, tier, owner and decision	app registry and the app registry template and app record
A sandbox workspace registration step, with the one-time counsel-gate attestation	enablement lead, with the IT/platform owner	Sandbox	Sandbox rules
An approved-tools list by data class, including tools' built-in AI features	IT/platform owner	"approved tools only" and the M1 approval gate	approve an AI tool or app builder
At least one approved hosting pattern with SSO	IT/platform owner	Team and Important hosting	hosting
The technical check's fixed list, and a named technical reviewer	IT/platform owner	the Important-tier technical check	business review and technical check
A decision-record template	enablement lead	intake answers, downgrades and exceptions	decision record template
A leadership charter naming the executive sponsor	executive sponsor	Critical residual risk and escalations	leadership charter
A counsel route: who counsel is, what to send, a target turnaround	enablement lead	the jurisdiction flag and the consent gate	the counsel route
The minimum staffing, including a security reviewer for Critical	enablement lead and executive sponsor	someone to triage, check and sign	when one person holds several roles

If an item is missing, you can still open intake to tier apps, but approve only the tiers whose gates have somewhere to go: Sandbox needs the workspace registration and the approved-tools list; Team adds the registry, an approved hosting pattern and the decision-record template; Important adds the technical check and its reviewer; Critical adds the security reviewer and the leadership charter. Any app that a counsel gate holds waits for the counsel route.

For the enablement lead: how to triage¶

Who approves at each tier, and who signs what, is on the roles and decision rights page.

Check the form is complete, including kill criteria, a retire-by date, an app owner who isn't only the builder, and, if Part 1 item 4 or 5 is yes, the trifecta answers and the list of grants.
Apply the highest-answer rule. The tier is the highest tier any answer or modifier gives. Never add, average or score.
Check both floors, using the Part 1 trifecta answers for Floor 1. The floors have no exceptions. If an answer is higher only because the app breaks a floor by mistake (for example a publicly readable bucket), apply the floor-breach rule.
Consider the standard downgrades and any downgrade request, on the rules in the downgrade path. The app owner asks and the signers named there sign; you don't grant downgrades yourself. A request to change when or how a gate is met is a bounded exception, never a change to the tier.
Open the gates. Route to counsel through the counsel route if the jurisdiction flag is yes or the consent gate applies. Route to the compliance owner if the audit-scope flag is yes. Get data-owner sign-off for Q1© or (d).
Record the result in the app registry: the six answers, both flags, the tier, any floor breach and fix-by date, any downgrade request, the kill criteria and retire-by date, and the decision below.
Answer the builder with one of the four answers and the next steps for the tier.

Don't: let builders self-declare a tier

A tier picked from a dropdown without the six answers isn't a tier. Risk-calibrated review only works if the low-risk label is checked, so record the answers and check them.

Don't: let intake take weeks

A slow path pushes builders to build without you: Thoughtworks describes noncoders building their own software "instead of waiting for the IT department"¹. The low-power default path only works if exceptions are answered in days (A-002). Publish the median answer time each month.

What happens next at your tier¶

Each tier has its own gates for build, verify, deploy, operate, change and retire. They're in one place, the gate matrix, starting at intake. For the steps from idea to sharing, see the builder handbook.

Questions to ask your counsel¶

For the enablement lead, who triages intake:

Which decisions about people do we make where an automated-decision or employment-AI rule applies (including California's FEHA regulations and Ontario's job-posting rule)?
Who signs off a Q5(b) app's human-review design, and what counts as meaningful human review for us?
For California staff from 1 Jul 2027, which of our tools are an automated decision system under SB 947, and where is our corroboration evidence kept?
Do any of our apps collect biometric identifiers, children's or teens' data, or consumers' health or other sensitive data outside HIPAA, so that consent is needed before collecting?
Do we have Quebec operations, so that Law 25 requires a privacy impact assessment when we build a system that handles personal information?

Record the decision¶

Record each intake answer in the registry as a short Decision Record.

Illustrative composite

App: invoice exception sorter · Date: YYYY-MM-DD · Triaged by: enablement lead (role)

Answers: Part 1: no AI model, doesn't run on its own. Q1© supplier bank details; Q2(b2) AP plus the controller's team; Q3(a); Q4©: the clerks work each exception in the ERP, which re-performs the three-way match; Q5(a); Q6(a): it sorts exceptions in its own view. Jurisdiction flag: no. Audit-scope flag: yes, because it touches invoice data that flows into the ledger, so it's routed to the compliance owner. It produces no control evidence (the ERP's match is the control the auditors test), and the flag doesn't change the tier. Tier: Important.

Decision: approved with conditions: data-owner sign-off from the finance master-data lead (the AP manager owns the app, so can't sign off its data use); the compliance owner's change and evidence requirements; approved hosting with SSO and deny-by-default data rules; business review and technical check before go-live. If the controller ever relies on the app's output as the documented control, re-run intake: that's Q4(d1).

Kill criteria: stop if exception sorting is wrong more than the AP team accepts in the first month. Retire-by: 12 months unless renewed. Review by: six months from the date above.

Assumptions and evidence¶

A-001 (Low): we expect builders to register apps if intake is fast and unlocks something they want (hosting, SSO, data access); test this by comparing registrations with apps found by discovery.
A-031 (Low): we expect a form built with short labels, skip logic and in-place definitions to take under 10 minutes; first-time completion of the full wording is closer to 15–20 minutes on a reviewer's estimate. Test this by timing five builders before the pilot, then timing completion and counting abandoned forms during it.
A-002 (Low): we expect builders to use the low-power default path if exceptions are answered within days; test this by tracking unmanaged tool use after intake opens.
A-008 (Low): we expect builders to recognize a consequential decision about a person when asked in plain words; test this by auditing a sample of Q5(a) answers.
A-030 (Low): we expect intake answers within five working days; test this by publishing the median answer time in the pilot.
A-045 (Low): we expect 35% or less of registered apps to land in Important or above; test this from the registry's tier mix each quarter.

Evidence: government policy, security-agency and practitioner guidance, survey data and statutes; no controlled study of intake for worker-built apps. Facts on this page are as of October 2026.

Risk tiers for worker-built apps: the full model behind the six questions.
App registry: where your intake answers are recorded.
The four data classes (Q1): the class definitions behind Q1, with the reason for each tier.
Apps that make decisions about people: the controls for a Q5 "yes".
AI features: the controls if your app calls a model while it runs.
Build an app with AI at work: the builder's steps from idea to sharing.

Thoughtworks Technology Radar, "AI-accelerated shadow IT", Nov 2025 entry (Vol. 33, Hold): "AI is lowering the barriers for noncoders to build and integrate software themselves, instead of waiting for the IT department to get around to their requirements." https://www.thoughtworks.com/radar/techniques/ai-accelerated-shadow-it [primary], accessed 2026-10-21. ↩↩
The Register, report on the cases missing from Public Health England's COVID-19 reporting, 5 Oct 2020. https://www.theregister.com/2020/10/05/excel_england_coronavirus_contact_error/ [news], accessed 2026-10-21. ↩
CIO Dive, reporting S&P Global Market Intelligence survey data, Mar 2025. https://www.ciodive.com/news/AI-project-fail-data-SPGlobal/742590/ [survey], accessed 2026-10-21. ↩
California Privacy Protection Agency, approved text of the CCPA regulations on automated decision-making technology (effective 1 Jan 2026; compliance by 1 Jan 2027), §7001(e). https://cppa.ca.gov/regulations/pdf/ccpa_updates_cyber_risk_admt_appr_text.pdf [regulator], accessed 2026-10-21. ↩
California Civil Rights Council, release on approval of regulations on employment discrimination and automated-decision systems (effective 1 Oct 2025; four-year retention of automated-decision data), 30 Jun 2025. https://calcivilrights.ca.gov/2025/06/30/civil-rights-council-secures-approval-for-regulations-to-protect-against-employment-discrimination-related-to-artificial-intelligence/ [regulator], accessed 2026-10-21. ↩
Government of Ontario, "Your guide to the Employment Standards Act: requirements related to publicly advertised job postings" (AI disclosure for postings from 1 Jan 2026; O. Reg. 476/24). https://www.ontario.ca/document/your-guide-employment-standards-act-0/requirements-related-publicly-advertised-job-postings [regulator], accessed 2026-10-21. ↩
Colorado General Assembly, SB 26-189 (effective 1 Jan 2027). https://leg.colorado.gov/bills/sb26-189 [statute], accessed 2026-10-21. ↩
NYC Department of Consumer and Worker Protection, "Automated Employment Decision Tools". https://www.nyc.gov/site/dca/about/automated-employment-decision-tools.page [regulator], accessed 2026-10-21. ↩
Illinois Public Act 103-0804 (HB 3773), effective 1 Jan 2026. https://www.ilga.gov/legislation/publicacts/fulltext.asp?Name=103-0804 [statute], accessed 2026-10-21. ↩
California SB 947 (reported as Stats. 2026, ch. 859), Labor Code §§1520–1526.7. https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260SB947 [statute; the page refused our tools, so the scope, the 1 Jul 2027 operative date and the chapter number come from law-firm summaries only, secondary], accessed 2026-10-21. ↩
Fair Credit Reporting Act, 15 U.S.C. §1681m(a) (adverse-action notice contents). https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section1681m&num=0&edition=prelim [statute], accessed 2026-10-21. ↩
Fair Credit Reporting Act, 15 U.S.C. §1681b(b)(3) (pre-adverse-action copy of the report for employment purposes). https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title15-section1681b&num=0&edition=prelim [statute], accessed 2026-10-21. ↩
CFPB, Regulation B, 12 C.F.R. §1002.9 (statement of specific reasons). https://www.consumerfinance.gov/rules-policy/regulations/1002/9/ [regulator], accessed 2026-10-21. ↩
Quebec, Act respecting the protection of personal information in the private sector, CQLR c. P-39.1, s. 12.1. https://www.legisquebec.gouv.qc.ca/en/document/cs/P-39.1 [statute], accessed 2026-10-21. ↩