An Applicant Asks Which Data Decided Their Case. Can You Show It and Fix It?

Consider a property management company in Colorado operating in 2027. Its screening service’s model gave a rental applicant a risk score, where a higher score means more risk. The score was above the company’s rejection threshold, so the system recommended rejection, and a leasing agent followed that recommendation. Now the applicant writes back with two questions: which data did you use, and where did the unpaid balance on my record come from? The applicant has never lived at the address tied to that balance. Since the decision, the screening vendor has refreshed its data twice and the scoring model has been updated once. The team has to answer from records. (Illustration)

To explain or correct one automated decision, a team has to be able to rebuild it: the personal data as it stood on the day of the decision, the model version that produced the score, and the threshold that turned the score into a recommendation. A correction then involves two kinds of work. The law gives the person rights to an explanation, to the personal data used, to correction of inaccurate personal data, and to human review. Handling the data well, in CUBIG’s view, also means rerunning the decision under the same conditions and checking which other decisions used the same data. Teams that keep data versions together with run conditions can do this from records. Teams that keep only the current data may find past decisions hard and costly to reconstruct.

1. 01Request

   The applicant asks which data was used and disputes an unpaid balance.

2. 02Decision

   A leasing agent followed the system’s rejection recommendation and declined the application.

3. 03Score and threshold

   A specific model version produced the score. The company’s threshold turned it into a rejection recommendation.

4. 04Input record

   The balance came from a vendor record matched to the applicant by name and date of birth.

5. 05Data version

   The vendor file has since been refreshed in place. The record as it stood on decision day is gone.

What the Colorado AI Act now asks after an adverse decision

Colorado’s reenacted law focuses on what happens around each decision rather than on a yearly assessment. SB 26-189, signed on May 14, 2026, repeals and reenacts the Colorado AI Act passed in 2024 as SB 24-205. According to a Norton Rose Fulbright summary, the new version drops the annual impact assessments, the risk management program, and the duty of care to mitigate algorithmic discrimination. The act takes effect on January 1, 2027 and applies to consequential decisions made on or after that date, in areas including education, employment, housing, financial and lending services, and insurance.

The signed act sets out these duties around a decision:

• Notice before use. Before a deployer uses a covered system to materially influence a consequential decision, it gives the consumer clear and conspicuous notice.
• Explanation within 30 days. After an adverse outcome, the deployer provides a plain-language description of the decision and the system’s role in it, with a simple process to request more information. That information includes the system’s name, its version number if applicable, its developer, and the types, categories, and sources of personal data used.
• Access, correction, and human review. On request, the deployer explains how to obtain the personal data used and how to correct factually incorrect or materially inaccurate personal data. It also offers meaningful human review and reconsideration of the decision, to the extent commercially reasonable.
• Records for three years. Deployers keep records reasonably necessary to demonstrate compliance for at least three years after the decision. The act says these may include system version identifiers, changelogs, and documentation of material mitigation changes.
• Developer documentation. From January 1, 2027, developers give deployers documentation that includes a description of the categories of data used to train the system, to the extent known.

One statutory distinction in the correction section matters for data teams. The correction right covers personal data, and the act states that it does not require deployers to correct opinions, predictions, scores, or protected evaluations. When an input is wrong, one practical approach is to correct the record, recompute the score under the original model and settings, and give the results to a human reviewer. That approach works only if the team can rerun the decision.

Draft rules, a pending lawsuit, and what is still open

Several details are not settled. On October 6, 2026, the Colorado Department of Law released a revised interim draft of its implementing rules, as Akin Gump also summarized. The draft presumes that an output meeting certain criteria materially influences a decision, and lets a deployer rebut that by showing the output was only a de minimis factor. It would require access responses to include the specific pieces of personal data used in the decision, listing examples such as a final rank, score, classification, or prediction, and would generally set 45 days to respond to access and correction requests, a point the Morrison Foerster summary also notes. A public hearing was scheduled for October 26, 2026. Written comments were scheduled to close the same day, and the attorney general’s rulemaking page says the comment period continues through the last day of the hearing if the hearing runs past October 26. When we reviewed the attorney general’s rulemaking page on October 27, 2026, it listed the interim draft but no final rules. Any rule wording in this article comes from the October 6 draft and may change.

Enforcement is also limited by a court order. In x.AI LLC v. Weiser (D. Colo., No. 1:26-cv-01515), an April 27, 2026 minute order bars the attorney general from initiating enforcement, including investigations, for alleged violations of SB 24-205, or of legislation replacing or amending it enacted during the 2026 session, that occur on or before 14 days after the court rules on xAI’s forthcoming motion for a preliminary injunction. The same order gives xAI 28 days after final adoption of the implementing rules to file that motion. As of the latest public filings we reviewed, the public docket showed no ruling on such a motion, and its most recent entry was dated October 2, 2026. This article uses the law and the draft rules as context, not as legal advice. Legal and compliance teams decide how they apply to a given system.

Regulators and AI platforms both expect a person to review

Colorado is one example, and other rules differ in scope and wording. In the EU, the GDPR gives people a right of access to their personal data, including meaningful information about the logic involved in certain automated decisions (Article 15), a right to have inaccurate personal data rectified (Article 16), and, where certain decisions based solely on automated processing are allowed, at least the right to obtain human intervention, express a point of view, and contest the decision (Article 22). The obligations are not interchangeable, but they ask for similar evidence.

AI providers draw a similar line. OpenAI’s usage policies, revised on October 21, 2026 with changes effective November 20, 2026, clarify the requirements for high-stakes uses. The policies do not allow automating high-stakes actions in sensitive areas without human review, including decisions that materially affect a person’s rights, safety, or access to essential services. For a team running decisions like these, both the regulator and the platform expect a person to be able to review a decision, and that person needs evidence to review.

Follow one automated decision backward

The quickest way to see what an explanation needs is to start from the request and walk back. Each step asks for a record that someone had to keep at the time of the decision.

• The decision. Who declined the application, when, and whether the agent could have overridden the recommendation.
• The score. Which version of the screening model produced it, with which settings.
• The threshold. Which company threshold was in force that day and turned the score into a rejection recommendation.
• The inputs. Which records fed the score, and how each one was matched to the applicant, for example by name and date of birth.
• The data version. What the vendor file and the matching rule looked like on the day of the decision.

The audit trail often breaks at the last step. Screening data gets refreshed, matching rules get tuned, and models get updated. If the vendor file was overwritten in place, the team can show today’s record but not the one the decision used, and it cannot tell whether the unpaid balance came from bad source data or from a matching rule that joined two people with similar details. Our article on which version of the data passed the test covers the same gap from the evaluation side.

Used, ran, shown, fixed: four questions for each adverse decision

Each question below points to a part of the law and to a record a team can keep. The law column paraphrases SB 26-189. The other two columns are CUBIG’s practical examples based on the rental illustration, not legal requirements.

The shown row is where the difference between data and scores matters. A person can see and dispute the records that fed a decision. The act does not require deployers to edit scores themselves. In CUBIG’s view, one practical answer to a dispute is to recompute the score from corrected data under the same model version, settings, and threshold, and give the result to someone with the authority to change the decision.

After a correction: fix the record, rerun, then check what else used it

The law and good practice cover different parts of a correction. The law gives the person rights to an explanation, access to the personal data used, correction of factually incorrect or materially inaccurate personal data, and meaningful human review, and it requires deployers to keep records. The act does not mandate the versioning and same-condition reruns described below. The two steps below are CUBIG’s recommended practice, not legal requirements.

• For the person (CUBIG practice). Correct the record in a new data version and keep the version the decision used. Rerun the same model version, settings, and threshold on the corrected data, and give both results to the reviewer who can approve, modify, or override the decision.
• For the data (CUBIG practice). If the wrong balance came from a matching rule that joined two people, the same rule may have touched other applicants. List the decisions that used that data version and check whether the same rule affected them.

Rerunning under the same conditions matters for the same reason it does in model testing. If the model, the settings, and the data all change at once, nobody can tell which one moved the result. When the model and the data both change, the comparison only works if the other parts stay fixed.

Building this in-house requires preserving the data versions needed to reconstruct each decision instead of overwriting them, recording which model version, settings, and threshold each run used, and comparing a corrected version with the original under the same conditions, within the retention periods and access controls your privacy and legal teams set. The data side of that work, keeping versions and the conditions they were checked under, is what CUBIG built into Syntitan.

How to prepare to explain and correct automated decisions

1. Pick one decision type and list its inputs. Write down every data source that feeds the decision, including vendor data and the rules that match records to people.
2. Stop overwriting decision data. Keep the records needed to reconstruct each decision, such as the data version it used or a reliable way to rebuild it, with retention periods and access controls reviewed by your privacy and legal teams.
3. Record each run with its conditions. Note the model name and version, settings, the decision threshold in force, the time of the run, and the data version.
4. Separate the data you correct from the outputs you recompute. The correction right covers personal data. Decide in advance whether and how scores and predictions will be recomputed from corrected data.
5. Define the correction workflow before the first request arrives. Decide who creates the corrected version, who reruns the decision, who reviews it, and how other decisions that used the same data get checked.

Where Syntitan fits

Syntitan, CUBIG’s AI-ready data platform, covers the data side of this work. The original Dataset is preserved, work happens on a copy inside a Project, and each successful processing run is saved as a new Version, so the Version a decision used stays as it was while a corrected one is created. In Ready for Raw Data, Syntitan diagnoses a dataset across six axes, including traceability, and proposes changes in plain sentences that the team can apply, hold, or exclude. In Ready for Model, it compares results before and after preparation using the same model and evaluation conditions.

Two more parts are planned for December: Execution Trace, which links a real run’s inputs, outputs, and errors to the Version, settings, and evaluation conditions in use at the time, and the ability to view data as of that time and compare it with the previous state.

For a correction like the one in this example, the output is a pair of Versions: the one the decision used, kept unchanged, and the corrected one, each with the processing that produced it and ready to compare under the same conditions. Syntitan does not decide whether a system materially influences a decision, judge legal adequacy, write consumer notices, or carry out the human review. Legal, risk, and operations teams own those calls.

Pick one automated decision your team made last month and try to answer the four questions for it from records alone. The first question you cannot answer shows where to start keeping versions.

Related reading

• Which version of the data passed the test?: why a version log alone does not tell you which data an evaluation used.
• Your model changed and your data changed. Which one drove the result?: how to compare results when more than one thing moved.