When a formal rule becomes an operating condition

Executive summary

A published rule and a working practice are different objects. This brief examines how to move from the first to evidence about the second without making an unsupported compliance claim. It sets out an editorial protocol for tracing authority, actor, action, record and version.

The source set deliberately contains different kinds of authority: an official legal-policy announcement, a voluntary risk framework and an OPEN VARIABLE narrative inquiry about institutional recognition. They offer distinct perspectives. None can substitute for a factual examination of a particular deployed system.

Key findings

Document status is a material fact. A concept note should retain that label when it is cited; an announcement should not silently become a complete statement of legal applicability.

Responsibility must be located before performance can be evaluated. A provider, an application operator and a downstream distributor can control different parts of a system. An undifferentiated statement about “the AI” makes the evidence harder to assess.

A claim is only as current as the version it describes. Changes to a model, interface, export format or use context can make an earlier observation insufficient for a later judgment.

1. Start with the authority

The European Commission’s July notice describes the start of enforcement and transparency obligations. NIST’s AI RMF page describes a voluntary framework and identifies ongoing work. These sources have different purposes and standing. A research record should preserve those differences. European Commission ↗ · National Institute of Standards and Technology ↗

Record the exact document title, issuing body, date and status. Where applicability depends on a legal definition or exception, the summary must point to the primary text and refrain from deciding facts that have not been established. General guidance can locate the inquiry; it cannot settle every case.

2. Identify the actor and the action

Turn a broad assertion into a sentence with a subject and a verb. Who is said to disclose, test, mark, retain, review or notify? What object does the action concern? Which part of the chain can that actor actually control? These questions often reveal that an apparently simple claim crosses organizational boundaries.

Do not infer responsibility from technical proximity. A company providing an upstream component may not control the interface a person sees. An application operator may control that interface without controlling every property of the underlying model. The record must follow the specific claim and the evidence available for it.

3. Ask what a record can demonstrate

A policy statement establishes what an organization says it intends to do. A test report can establish the conditions and results of a particular test. A retained output can establish what was visible in that output. Each has a useful role, but the scope of the conclusion must match the scope of the observation.

A testable question about disclosure might ask whether a notice remains visible after a specified export or redistribution step. Answering it requires a documented starting state, transformation and output. Without that chain, a screenshot of one interface can prove very little about the entire distribution path.

4. Carry the version forward

Preserve the tested model or service version, date, interface and transformation where those details are available. Record what cannot be identified. If a version changes, decide whether the prior evidence remains relevant rather than assuming that either everything or nothing transfers.

The same discipline applies to the governing document. A revised standard may change the question a record must answer. A research update should identify that change separately from a change in the system under examination. This prevents a moving rule and a moving product from being collapsed into one unexplained status change.

5. Keep recognition and operation distinct

A designation describes a defined assessment; it does not by itself show what happens when a system is used, exported or redistributed. To understand its practical value, ask what was examined, what was excluded, who may rely on the result and whether the observed version is still in use.

A certification or designation can be valuable while still having boundaries. The scope of the evidence should be visible to anyone relying on it. A formal label neither guarantees every outcome nor has no practical value.

Method and limitations

Use this brief to assess documentary claims and identify the records needed for a particular system. It does not evaluate a named deployed product or provide legal advice.

The disclosure question cannot be answered for a specific system without its distribution path, applicable requirements and reproducible observations. The test described here helps readers ask for that evidence; it is not a finding that any provider has passed or failed.