Appearance
Developer duties
§ 6-1-1702 (enrolled-act numbering) is the developer's section. On and after January 1, 2027, a developer owes each deployer of a covered ADMT it developed a transparency package, update notices, and the records that show both were done. MFF-28 carries these as MRF-483 and MRF-484, tagged ADMT Role: Developer. A deployer that intentionally and substantially modifies an ADMT into a covered ADMT becomes its developer and picks up these duties too (see Coverage and roles).
When the section applies
Two provisions bound the section:
- Trigger (§ 6-1-1702(5)): the section applies when the developer creates a covered ADMT that is intended, documented, marketed, advertised, configured, or contracted to be used to make consequential decisions, or when the developer becomes aware that it is being used to make consequential decisions in a manner consistent with the intended and contracted uses.
- Scope limit (§ 6-1-1702(3)): the disclosure duties of subsections (1) and (2) apply only for a deployer's use of a covered ADMT where the ADMT was marketed, advertised, configured, contracted, sold, or licensed to be used to materially influence a consequential decision. The limit does not reach the record-retention duty of subsection (4).
The duty attaches to developers doing business in Colorado (§ 6-1-1701(8)). A deployer procuring from a developer outside that definition has no statutory package coming; the organization framework's contract-hygiene requirement (ORF-486) is where a deployer contracts for one.
The transparency package — MRF-483
On and after January 1, 2027, a developer shall make available to each deployer of a covered ADMT developed by the developer, in a form and manner that is reasonably understandable to a deployer and that protects trade secrets or information protected from disclosure by state or federal law:
followed by the five elements (§ 6-1-1702(1)(a)–(e)):
| Element | Content |
|---|---|
| (a) | A general statement describing the intended uses and known harmful or inappropriate uses of the covered ADMT |
| (b) | A description of the categories of data, including personal data, used to train the covered ADMT, to the extent known |
| (c) | Known limitations, including known risks and circumstances in which the covered ADMT should not be used |
| (d) | Instructions for the deployer's appropriate use, monitoring, and meaningful human review, where applicable |
| (e) | Information reasonably necessary for the deployer to comply with § 6-1-1704 (the deployer's notices and disclosures) |
And the withholding mechanic, verbatim: "If information is withheld, the developer shall notify the deployer."
Three points shape how the package is used:
- "Make available", not "deliver": the developer's duty is to make the package available to each deployer in an understandable, trade-secret-protective form. There is no statutory duty on the deployer to request it; intake of the package is the deployer's recommended practice, because the deployer's own disclosure duty depends on it.
- Element (e) is what makes the deployer's duty performable. The deployer's post-adverse-outcome disclosure of the tool's name, version, developer, and data types, categories, and sources is owed only "to the extent the deployer receives the necessary information from the developer" (§ 6-1-1704(3)(b)). A withheld item plus the required withholding notice shifts the practical burden visibly.
- Element (d) feeds the reviewer test. The deployer's meaningful human review requires reviewer access to the output's intended use, material limitations, input categories, and principal factors (§ 6-1-1701(15)); the instructions and information in the package are where a deployer gets them.
The requirement is carried by the new control MCF-689 (Developer ADMT transparency package): the package's completeness across the five elements, its understandable and trade-secret-protective form, its availability to every deployer, and notice of any withheld information. No existing control packages supplier documentation with this statutory item list and the withholding-notice mechanic.
Update notices and developer records — MRF-484
A developer shall provide to each deployer of a covered ADMT developed by the developer a notice of material updates, intentional and substantial modifications, and changes to the intended use of, limitations for, or risk mitigation for the covered ADMT within a reasonable time.
Two definitions decide what triggers a notice (§ 6-1-1701):
- Material update (¶ 14): an update, patch, release, revision, or new version, including associated software, model parameters, default settings, or documentation, that the developer knows or reasonably should know is likely to materially affect the covered ADMT's outputs or performance in a manner relevant to its intended use, or the developer's stated intended use. Routine maintenance, cosmetic changes, and bug fixes without such effects are excluded.
- Intentional and substantial modification (¶ 12): a deliberate change resulting in a material change to the system's intended, documented, advertised, configured, or contracted use.
The release-notes route (§ 6-1-1702(2)(b)): public release notes containing the required information comply if the developer provides direct notice of the public release to each deployer. Public notes without the direct notice do not.
Records (§ 6-1-1702(4)): the developer retains, for not less than three years after the creation of a record required or created under the section, or longer if required by applicable state or federal law, the records reasonably necessary to demonstrate compliance, including system version identifiers, changelogs, and documentation and notices of material updates provided to deployers.
Two clocks, two owners
The developer's clock runs from the creation of each record. The deployer's clock (§ 6-1-1703, MRF-488) runs from the date of each consequential decision. Both are minimums, extended by any longer applicable retention law. The framework keeps them in separate requirements because the statute gives them different owners and different triggers.
The requirement is carried by the new control MCF-690 (Developer update notices and records): what counts as material, reasonable time, the release-notes route with direct notice, the subsection (3) scope on the notice duty, and the developer-side record set with its from-creation clock.
Why the developer's representations matter beyond § 6-1-1702
Under § 6-1-1707 a developer is liable in a state anti-discrimination action only to the extent its covered ADMT was used in a manner that was intended, documented, marketed, advertised, configured, or contracted for by the developer and materially influenced the decision giving rise to the violation. The developer's § 6-1-1702 compliance also conditions the deployer-liability rule for off-envelope use (§ 6-1-1707(6)) and the developer carve-out from the void-indemnification rule (§ 6-1-1707(7)(b)). The package and the update notices are therefore liability-shaping documents as much as compliance documents; the deployer side of that story is on Deployer duties and consumer rights.
Where to go next
- Deployer duties and consumer rights — the duties the package feeds.
- Operationalizing SB 26-189 in Modulos — the full
MFF-28/OFF-28rollout with the mapping tables.
Disclaimer
This page is for general informational purposes and does not constitute legal advice. Section citations follow the SB 26-189 enrolled act; part 17's final codified disposition is pending. Always verify against the current published text and consult qualified advisers.