AIFX: Creation Records vs. Rights Review
What you’ll learn
- AIFX and its image format, AIFI, transfer an AI-created work together with records such as who created it, which AI was used, and when it was created
- A complete creation record does not necessarily mean that an image may be used in advertising or sold. File changes, usage rights, and release approval require separate checks
- For organizational use, creation records and internal review results need to point to the same work and version. The workflow also needs a way to stop release when evidence or approval is missing
The Role and Scope of AIFX
AIFX is an open container standard for transferring AI-created images or video with their creation records. Its image format, AIFI, puts the image and its creation record into one ZIP file, a format that bundles several files for storage and handoff. This makes the record easier for the recipient to inspect.[1][2][3]
Source availability: As of September 21, 2026, the official AIFX GitHub organization page remains public, but the AIFX Desktop and AIFI Standard repositories referenced by this article are not publicly accessible.[2][3] The format details below are based on material that was public when the original article was updated on September 16, 2026. Before implementation, check whether official documentation or a successor specification has been published.
However, being able to inspect a creation record is not the same as having permission to use or release the work. A record does not prove the creator’s identity, establish that a contract is valid, or show that the intended use is permitted.
Separating what AIFX can inspect from what an organization must review makes it easier to decide which parts of creation-record management can be automated and where a person must decide.
Images and Creation Records Included in AIFI
Required Files and Optional Information
AIFI requires the image and manifest.json, a file that records creation information under defined fields. The manifest records details such as the creator, creation time, and AI system used.[3]
The package may also include the following information.[3]
- The prompt, or instructions given to the AI
- Information about the model, meaning the type and version of AI used for generation
- License information describing permitted uses
When an image and its tracking sheet are stored separately, copying the image, converting its format, or sending it to an outside production company can break the link between the image and its record.
Putting them in one ZIP file lets the final image and creation record travel under the same management number and revision number. Validation software can also check mechanically whether the required fields are present.[1]
Matching a File with a Hash
A hash is a comparison value calculated from a file’s contents. Its value changes when the contents change, so the recipient can compare the recorded value with the received file to check whether the file matches.[1][2]
A hash only confirms a file match. It does not establish that the depicted content is accurate or that the user has the right to use it.
Storing Prompts That Contain Confidential Information
A prompt should not always be stored in full inside the ZIP file. It may contain customer information, unreleased product information, or internal instructions.
In those cases, the full text belongs in a location that only people with a business need can access. The ZIP file can instead record where the original is stored, a summary, who may view it, and its scheduled deletion date.
The Difference Between Creation Records, File Changes, Usage Rights, and Release Approval
AIFX uses the official term Self-Declared Authorship for authorship information entered by the creator. It does not establish copyright or prove originality or identity. AIFX also states that it is not a moderation or enforcement platform that removes unacceptable content or stops prohibited use.[1][2]
Separating the review into the following four checks makes the responsibilities of people and software clearer. This is a classification created for this article, not an official AIFX classification.
| Type of check | What it checks | Main evidence | Main owner |
|---|---|---|---|
| Creation record | Who recorded that the work was made, what was made, and under which conditions | Creator, model, time, input information | Creator or production owner |
| File-change check | Whether the file changed after the record was made | Hash, revision number, comparison result | Validation software and operations owner |
| Rights review | Whether the inputs and generated work may be used for the intended purpose | Contracts, consent, permitted-use terms, record of the rights-holder check | Legal or rights owner |
| Release approval | Whether the work may be released for the brand and intended use | Review result, approver, usage restrictions | Brand or business owner |
The creation-record check prevents an organization from keeping a record without knowing who entered it. File comparison helps detect an unnoticed replacement or revision. Rights review helps prevent use of material or purposes that are not permitted, while release approval prevents publication without an accountable approver.
AIFX directly supports the transfer of creation records and checks for file changes. It can also carry usage-condition information, but it cannot automatically prove the following:
- An attached contract is valid
- The person who entered the record owns the rights to the work
- Consent to use a person’s face or voice covers the current use
Those decisions need separate internal rights-review and release-approval records. The organization also needs named owners and conditions that stop use or release while a review remains incomplete.
Management Records That Connect the Work with Internal Reviews
A Shared Management Number and Revision Number
Creation records and rights documents do not establish that the released image was reviewed if they point to another image or an older revision. The AIFI information and internal review results therefore need to be linked to the same work and version.
This article proposes using asset_id, a management number for the work, and asset_version, the revision under review.
It calls the collection linked by those two identifiers an “AI Asset Evidence Packet”: a set of creation, rights, and approval evidence for an AI-created work. This is an organizational method proposed in this article, not an official AIFX specification.
Required Records and Owners
The following table lists the minimum records and their owners. Each owner records or checks the information and prevents the work from moving to the next stage when evidence is missing.
| Review item | Minimum record | Owner |
|---|---|---|
| Work identification | asset_id, asset_version, file format, hash | Production manager |
| Creation context | AI service used, model type and version, creation time, creator-provided record | Creative owner |
| Inputs and references | Source material, references, prompt storage location | Creative owner and records manager |
| Rights material | Contract, permitted-use documentation, consent to use a person’s face or voice, expiration date | Legal or rights owner |
| Usage conditions | Whether commercial use is permitted, permitted regions, publication destinations, modification terms, and conditions for reuse | Legal or rights owner |
| File and record inspection | Required-field result, hash match, inspection time | Validation software and operations owner |
| Human decision | Brand and factual review results, whether the expression suits the target region and culture, approver | Brand or business owner |
| Handoff to the next stage | Distribution destination, what to disclose about AI use, and a record showing who made each decision | Distribution owner |
Responses to Missing or Mismatched Records
The response to missing evidence should be defined alongside each record.
| Review item | Problem to prevent | Response when information is missing or a problem is found |
|---|---|---|
| Work identification | Confusing the work with another work or revision | Stop delivery and distribution |
| Creation context | Using a work without knowing how it was created | Recheck it or restrict its use |
| Inputs and references | Using material from an unknown source | Stop release if the source cannot be identified |
| Rights material | Using the work without checking permission or expiration | Send it for rights review and stop use until that review is complete |
| Usage conditions | Using the work beyond the permitted scope | Do not use it outside the permitted scope |
| File and record inspection | Distributing a file with incomplete records or a replaced file | Remove it from distribution and recheck it |
| Human decision | Releasing the work without accountable approval | Do not release it before approval |
| Handoff to the next stage | Transferring the work without an owner or decision record | Hold it when there is no responsible recipient |
The important distinction is between information being present and the review being complete.
For example, text in a usage-condition field is not enough to mark a rights review complete. The contract location, covered work, expiration date, and permitted use need to correspond.
Likewise, a matching hash only shows that the file is identical to the recorded file. It does not show that the content is lawful or factually correct.
Introducing AIFI into Existing Asset Management
Initial Scope and Three Management Fields
Converting every work to a new format at once can increase the creative team’s workload and the scale of system changes before the organization has tested the benefit. One option is to begin with one type of externally published AI-generated image.
Three elements can then be added to existing asset storage, project tracking, and approval systems.
- A shared identity from creation through distribution: Use the same
asset_idandasset_versionfor the same work and revision across every stage - The evidence location and comparison value: Record the evidence-packet location and hash in the existing management record
- Stop conditions and procedures: Define the response when rights are unknown, file or record comparisons do not match, or approval has expired
Preparing for Specification Changes and Long-Term Storage
The AIFX Desktop material available when the original article was updated described the project as under active development and warned that specification changes could include breaking changes.[2]
Long-term storage should therefore avoid depending on one application to read the records. The retained material should include the source file and creation-information list, the version of the validation software, and a procedure for moving older records into a new system.
Summary: Creation Records Do Not Decide Usage Rights or Release Approval
AIFX and AIFI transfer AI-generated works with their creation records and allow software to check required information and file changes. Rights to use the work and permission to release it still require contract and purpose checks and approval from the responsible people.
Collecting the evidence for one work makes operational gaps easier to see. An organization can base its AIFI adoption decision on whether its existing workflow can accommodate automatically recorded information, specialist-reviewed items, and a named person who stops release when evidence is missing.
This article is a general information summary and is not legal advice. Confirm practical decisions with a qualified specialist.
References
- AI First Exchange, official GitHub organization page (checked September 21, 2026)
- AI First Exchange, AIFX Desktop (consulted September 16, 2026; no longer publicly accessible as of September 21, 2026)
- AI First Exchange, AIFI — AI First Image Format (consulted September 16, 2026; no longer publicly accessible as of September 21, 2026)
Before using the format details in an implementation, check the official organization page for republished or successor documentation.