AIPM 1.2 Specification

Overview

The AI Provenance Mark (AIPM) is an open, vendor-neutral specification for disclosing AI involvement in content creation. It is intentionally minimal, web-native, and extensible. AIPM is pronounced "ape 'em" — rhymes with shape pum, phonetically ap-um.

AIPM 1.2 adds file integrity hashing (hs, hd), content type declaration (type) for EU AI Act alignment, the automated role for system-generated marks, file upload to context (.txt, .md, .pdf, .docx), JSON-LD structured data output on provenance pages, and copy-as-citation. It is fully backwards compatible with AIPM 1.0 and 1.1.

The AIPM Provenance URL

An AIPM record is a provenance URL — a plain HTTPS link with all metadata encoded in the URL hash fragment. The hash fragment is processed entirely by the browser and never sent to any server. The provenance URL is the canonical record; everything else is a way to carry or display it.

From a provenance URL you can derive three shareable forms:

The provenance URL can also be shared directly — as a hyperlink, in an API response, or in any plain-text context. Structured JSON-LD derived from the provenance page makes records discoverable by search engines and AI crawlers without scanning.

Design Goals

• Mobile-safe QR scanning on all modern devices
• Human-readable first, machine-readable friendly
• No vendor lock-in or proprietary app requirements
• Minimal cognitive and technical overhead for creators
• Suitable for institutional, academic, journalistic, and public contexts
• Durable — QR codes that work today must work in ten or thirty years
• Privacy-preserving — metadata never transmitted to any server
• Zero infrastructure — static hosting only, no backend required
• Make it effortless to declare how much AI was involved — from full AI generation to full human authorship
• Make it easy to share the context or prompt with others — so work can be continued, verified, or built upon

Parameters

All fields are publicly visible to anyone who scans or opens the AIPM URL — including ctx, author, org, and all hash values. Do not include sensitive or private information in any field.

Role Values

The role field describes the human's involvement in the content creation process. Values are ordered from most human involvement to least.

Note on wrote: Use wrote when you are the intellectual author and AI acted as an editorial tool — not when AI generated the content from your prompt. The key distinction: in wrote, the ideas and structure are yours; in prompted+edited, the AI produced the first draft.

Note on automated: The AI Show abbreviation is intentionally two characters — the only two-character abbreviation in the set — to distinguish it clearly from single-character human-present roles. Use supervised (not automated) when a responsible human was present and monitoring, even if not reviewing each individual output.

Unusual situations: If your role doesn't fit any value precisely, choose the closest one and explain the difference in the ctx (Context) field.

Vibe coding and agentic coding: Repeated prompting, iteration, and testing can involve substantial human effort, but that does not automatically make the role supervised. If a human directed an AI through prompts and meaningfully tested and approved the result, prompted+reviewed is usually the best fit. Use prompted+edited when the human directly modifies, refactors, or substantially rewrites the implementation. Use supervised when an AI system operates autonomously within an ongoing workflow and a human actively monitors, intervenes, and is responsible for the process — not simply repeated prompting. Use automated when no human is involved.

Show Mode

Show mode embeds an abbreviated human role directly in the QR code's center mark, making the level of AI involvement visible at a glance without scanning. Show mode is on by default. Set show=0 to disable it. Omitting the show parameter entirely is equivalent to enabling show mode. under Advanced settings. Marks generated without show=1 display the AIPM version only — the role abbreviation is omitted from the QR center mark.

When Show mode is active (show=1), the center mark displays three lines:

AIPM       ← line 1: mark identifier
1.2 S      ← line 2: version + "S" (Show mode indicator)
P+R        ← line 3: abbreviated human role

See the Marks & Badges page for SVG downloads of all Show mode variants including the new AI abbreviation for role=automated.

Content Type (type)

The type parameter declares the media type of the content being marked. It is optional but recommended for organizations subject to EU AI Act Article 50 disclosure requirements, where those obligations differ by content type.

Unknown values are displayed on the provenance page but flagged as non-standard. The EU AI Act Article 50(1) requires specific disclosure for AI-generated audio, video, and images that could be mistaken for authentic content, including a watermarking requirement for some categories. Article 50(2) covers AI-generated text at scale on topics of public interest. See Regulatory Context for details.

File Integrity Hashing (hs / hd)

The hs and hd parameters store SHA hashes of the content file (src) and Full Context Document (doc) respectively. Either hash may be set without the corresponding URL.

Hash format — why base64url, not hex

AIPM uses W3C SRI format (algo-base64url) because it is algorithm-agile: the algorithm name is explicit in the value itself, making it forward-compatible with future algorithms without changing the parameter names.

Requirement Generators MUST support sha256 and MUST support sha384. Support for sha512 in generators is MAY. Verifiers (display pages and tools that verify hashes) MUST support sha256, sha384, and sha512. Unknown algorithm prefixes must render as "unverifiable — unrecognized algorithm" and must not fail silently.

Hex is always accepted and auto-converted. Paste raw hex from terminal tools directly into the generator — it is auto-normalized to SRI format. SHA-256 hex is 64 chars, SHA-384 hex is 96 chars, SHA-512 hex is 128 chars.

Hash specification

• Algorithm: SHA-256 (default), SHA-384 (required for generators, recommended for long-term archival), SHA-512 (permitted)
• Encoding: W3C SRI format — sha256-<base64url> (50 chars), sha384-<base64url> (71 chars). Raw hex and plain base64url also accepted and auto-normalized.
• Input: raw file bytes with no encoding normalisation
• For text files: the hash is of the bytes as stored/served. Line ending differences between platforms (Windows CRLF vs Unix LF) will produce different hashes of the same logical content. The verification tool detects this and offers to try common line ending variants.

Computing a hash

In the generator: drag and drop the file onto the Content Hash or Full Context Document Hash zone, or click "Choose file". Select the algorithm (SHA-256 or SHA-384) from the dropdown above the hash field. The hash is computed locally in the browser using the Web Crypto API — the file never leaves your device.

Mac / Linux (SHA-256):   shasum -a 256 filename
Mac / Linux (SHA-384):   shasum -a 384 filename
Mac / Linux (SHA-512):   shasum -a 512 filename

Windows 10+ (SHA-256):   Get-FileHash filename -Algorithm SHA256
Windows 10+ (SHA-384):   Get-FileHash filename -Algorithm SHA384
Windows 10+ (SHA-512):   Get-FileHash filename -Algorithm SHA512

Terminal output (hex) can be pasted directly — the generator and provenance page both auto-convert hex to SRI format, detecting the algorithm from the hex length.

Circular dependency: hashing a file that will contain the AIPM mark

If you embed an AIPM QR code inside the file you want to hash (e.g. a PowerPoint with a QR code on the cover slide), you face a circular dependency: you cannot know the file's hash before generating the AIPM URL, but generating the URL requires knowing the hash.

Two clean approaches:

1. Hash before embedding (recommended for simple cases). Hash the file before adding the AIPM QR code. Use that hash in the AIPM URL. Optionally, set src to a link to the original (pre-QR) file — so recipients can download the exact version that was hashed. Embed the QR. The hash in the mark refers to the pre-QR version — this is intentional and semantically accurate: you are attesting to the AI-generated content, not to the AIPM citation layer on top of it. The display page notes this convention when showing the verification zone.
2. Separate the embedded mark from the hash-bearing mark. Embed a hash-free AIPM mark (no hs) in the file. Once the final file is saved, hash it. Create a second AIPM mark with hs set to the hash of the file containing the first mark. Use prev to reference the hash-free mark embedded in the distributed file, creating a chain that links the verifiable external record back to the mark visible in the document. Share the second URL externally (e.g. in email, on a web page, or alongside the file download) — anyone can verify by hashing the file and comparing against this mark.

In brief: Either (a) hash the original file, add hs and optionally src linking to the original, then embed the AIPM QR in the distributed file — the hash refers to the pre-QR version, which is semantically accurate; or (b) embed a hash-free AIPM QR in the distributed file, then separately share a second AIPM URL with hs set to the hash of the file-with-QR, using prev to chain back to the embedded mark.

Verification on the provenance page

When hs or hd is present, the provenance page shows a verification zone. Drop the file or paste a pre-computed hash. Results are shown as:

• Verified — hash matches. The file is identical to the one hashed at time of marking.
• Failed — hash does not match. The file may have been modified, or line endings may differ (for text files). The verification tool offers to try common line ending variants (CRLF↔LF) on mismatch for text files.

AIPM hash verification is an integrity check, not an authenticity proof. A Verified result confirms the file has not changed since hashing; it does not confirm the identity of who created it. AIPM remains a declaration-based standard.

File Upload to Context (ctx)

The generator accepts file uploads to populate the ctx field. Text is extracted client-side — no file is sent to any server.

If extracted text exceeds the available capacity, the generator offers two options: Keep beginning or Keep end. Truncation is code-point aware and will not split multi-byte characters (emoji, non-BMP Unicode).

Privacy note Extracted text is embedded in the AIPM URL and visible to anyone who has the link. Do not upload private or sensitive content.

Using AI to Generate AIPM Marks

You can instruct an AI model to automatically generate an AIPM provenance URL whenever it produces final output. Copy the snippet below into your AI tool's system prompt.

When you produce a final deliverable (document, post, report, code, or other substantive output), append an AIPM 1.2 provenance URL at the end.

Use this format:
https://aipmq.org/1.2/aipm/#v=1.2&model=[MODEL]&role=prompted&date=[DATETIME]&show=1&ctx=[PROMPT_OR_CONTEXT]

Replace [MODEL] with your model name, [DATETIME] with the current date and time in ISO 8601 format (e.g. 2026-05-04T14:30-04:00 with UTC offset, or just 2026-05-04 for date only), and [PROMPT_OR_CONTEXT] with a short URL-encoded summary of the prompt or context (e.g. Blog+post+about+climate+policy).

The human role should be prompted by default. If the human has indicated another role, use that instead. Use %2B to encode the + character in role values (e.g. prompted%2Breviewed).

Valid role values (choose the most accurate):
- all           Human only — no AI involvement
- wrote         Human wrote the content; AI corrected grammar/spelling/clarity; human approved
- prompted+edited   Human prompted; AI generated; human made substantive edits
- prompted+reviewed Human prompted; AI generated; human reviewed (default — most common)
- prompted      Human prompted; AI generated; no further review
- edited        AI generated (prompt unspecified); human edited
- reviewed      AI generated (prompt unspecified); human reviewed
- supervised    AI autonomous; human oversight
- automated     No human involvement; system-generated mark

Optional fields you may also include: &type=[text|code|image|audio|video|multimodal], &lang=[BCP47_LANGUAGE], &author=[NAME], &org=[ORGANIZATION], &src=[CONTENT_URL], &doc=[FULL_CONTEXT_URL].

Custom AI Tools

The AIPM provenance page includes "Try it" links for Claude, ChatGPT, Gemini, Grok, and Perplexity. Users can add up to 5 of their own preferred tools via the Custom Tools page — stored locally, no account required.

Four URL placeholders are supported:

AIPM provenance URLs use https://. The src, doc, and prev fields accept https:// or http:// URLs; all other URI schemes are rejected. HTTPS is strongly recommended for all linked resources.

URL Schema

AIPM 1.1 and later encode all metadata in the URL hash fragment (#). Hash fragments are processed entirely by the browser and never sent to any server.

Plain (uncompressed) format

https://aipmq.org/1.2/aipm/#v=1.2&model=Claude+Sonnet+4.6&role=prompted%2Breviewed&date=2026-05-04T14%3A30-04%3A00&ctx=Blog+post+draft&show=1

Compressed format

When context exceeds ~200 characters, the generator automatically switches to the compressed z param. All metadata is packed into JSON, compressed with deflate-raw, and encoded as base64url.

https://aipmq.org/1.2/aipm/#z=<base64url-encoded-compressed-payload>

Resolution Model

Unicode Support

AIPM 1.2 explicitly supports UTF-8 in all fields. All text is encoded via TextEncoder before compression, ensuring correct handling of CJK, Arabic, Devanagari, emoji, and all other Unicode scripts. Non-Latin users should prefer the compressed path — percent-encoding of non-ASCII characters significantly reduces effective uncompressed capacity.

Compression

The generator automatically switches to the compressed z param when the total URL approaches the QR byte limit or when context exceeds ~200 characters. The z value is produced by:

1. Serializing all metadata as a JSON object
2. Encoding as UTF-8 bytes using TextEncoder
3. Compressing with CompressionStream('deflate-raw') — browser-native, no library
4. Encoding as base64url: +→-, /→_, padding removed

The display page reverses this using DecompressionStream('deflate-raw'). It checks for z first, then falls back to individual params — ensuring full backwards compatibility with AIPM 1.0 and 1.1 QR codes.

QR Mark Image Export

Exported QR mark images (PNG or equivalent) must include a white quiet zone of at least 4 modules on all sides, as required by ISO/IEC 18004 §9.1. Without a quiet zone, QR scanners cannot reliably locate the code boundary — particularly when the image is displayed against a dark or non-white background (phone photo apps, PDF viewers, slide decks).

The AIPM generator adds 20px of white padding around the exported PNG, which exceeds the 4-module minimum at all supported export sizes. Implementors producing QR images should apply equivalent padding.

QR Code Capacity

Implementation note AIPM's QR_BYTE_LIMIT is 1,000 bytes — below the theoretical maximum of 1,273 bytes for QR version 40 Level H in binary mode. The conservative limit improves reliability across real-world encoders and scanners. Implementors MUST use 1,000 (not 1,273) for conformance with AIPM 1.2.

The hard limit is 1,273 bytes for QR Version 40, Level H error correction (required for mark overlay).

Compressed capacity depends on content compressibility. English prose typically compresses at 2.5–3×. CJK text is 3 UTF-8 bytes per character and compresses at 1.5–2×. For content exceeding QR capacity, use the doc param to link to a hosted full-context document, or use qr=0 URL-only mode.

JSON Representation (z param)

When compression is active, all metadata is a single JSON object. Fields in order: required, recommended, optional. The 1.2 payload adds hs, hd, and type.

{
  "v": "1.2",                   // Required
  "role": "prompted+reviewed",  // Required
  "model": "Claude Sonnet 4.6", // Recommended
  "date": "2026-05-04T14:30-04:00", // Recommended — datetime with UTC offset preferred
  "show": 0,                    // Only include when disabling: show=0. Absence = on (default). Integer 0, never boolean.
  "ctx": "Internal memo draft", // Recommended
  "src": "https://example.com/article", // Optional
  "hs": "sha256-uU0nuZNNPgilLlLX2n2r-sSE7-N6U4DukIj3rOLvzek",  // Optional — SHA-256 SRI format, of src file
  "type": "text",               // Optional — see Content Type
  "doc": "https://gist.github.com/user/abc", // Optional
  "hd": "sha256-jUMOtzRyvQF3zzzRZclUHHdaWfaHHPKp5zbkBYTSS3g",  // Optional — SHA-256 SRI format, of doc file
  "author": "Jane Smith",       // Optional
  "org": "Acme Corp",           // Optional
  "prev": "https://aipmq.org/1.2/aipm/#...", // Optional
  "lang": "en"                  // Optional
}

Omit fields that are not applicable — do not include empty strings or null values. show is always an integer (1 or absent), never a boolean. qr is never inside the JSON payload — it is always appended as a visible plain param: #z=...&qr=0.

QR Overflow (qr=0)

When a provenance record is too long to encode as a QR code even after compression, the generator appends qr=0 as a visible plain hash param and hides QR output. The URL remains a fully valid AIPM 1.2 record — share it as a link.

https://aipmq.org/1.2/aipm/#z=<compressed-payload>&qr=0

qr=0 is always a plain visible param so automated systems can detect it without decompressing. To avoid overflow, keep ctx brief and use doc for extended context.

Versioning and Version Lifecycle

The path structure (/1.0/, /1.1/, /1.2/) ensures existing QR codes never break — each version's pages are hosted permanently.

Each version's pages are frozen permanently when a new version ships. The /current/ redirect always points to the latest stable version. A /beta/ redirect exists when a new version is under active testing and listed on the root page with a beta flag. Existing QR codes always point to the correct frozen version path and will resolve indefinitely.

Backwards compatibility

AIPM 1.2 is fully backwards compatible with 1.0 and 1.1 in two directions:

• Existing QR codes resolve unchanged. A QR code generated with AIPM 1.0 or 1.1 resolves to its version-specific display page, which continues to function exactly as it always did. No migration is required.
• 1.2 display page reads 1.1 and 1.0 URLs. The 1.2 display page checks for the compressed z param first, then falls back to individual query params (1.0 behavior), handling all three formats transparently.

Upgrading an existing mark to 1.2

"Update this mark" links on 1.0 and 1.1 provenance pages point to the same version's generator. To upgrade to 1.2, use the 1.2 generator's "Update this mark" flow:

1. Open the old mark on the 1.2 provenance page — an upgrade notice will appear
2. Click Update this mark — the 1.2 generator opens with all fields pre-filled and prev= automatically set to the original mark's URL, creating a provenance chain

Alternatively, for a quick compatibility upgrade without creating a chain, change the version path from /1.0/ or /1.1/ to /current/.

Self-Hosting

AIPM is designed for static global hosting with no backend. All provenance data lives in the URL hash — there is no database, server-side processing, or user tracking.

Canonical domains: The reference implementation is hosted at aipmq.org (owned domain, canonical) and ai-pm.pages.dev (Cloudflare Pages infrastructure subdomain). Both serve identical content. QR codes generated by the official generator use aipmq.org by default.

Durability difference: aipmq.org is an owned domain. If the hosting provider changed, updating the domain's DNS CNAME record would be sufficient — all existing QR codes pointing to aipmq.org would continue to resolve automatically. ai-pm.pages.dev is a platform subdomain; DNS redirection is not possible for domains you do not control, so QR codes pointing there are dependent on Cloudflare Pages remaining available.

For self-hosters: use an owned custom domain (e.g. aipm.yourdomain.com) and point it at your static host via CNAME. If hosting changes, updating the DNS record is all that's required — existing QR codes continue to work.

Emergency fallback (legacy ai-pm.pages.dev marks only): QR codes predating aipmq.org adoption may point to ai-pm.pages.dev. If that domain became unavailable, you can add an entry to your local /etc/hosts file or local DNS server pointing ai-pm.pages.dev to a self-hosted AIPM instance. This restores resolution for devices under your control. QR codes pointing to aipmq.org do not need this fallback — DNS can be updated at the registrar level.

For doc and src URL longevity, choose durable hosting:

1. Your own domain / Cloudflare Pages / GitHub Pages — most durable
2. GitHub Gist — free, extremely durable, secret gists are unlisted
3. rentry.co — no account, custom slugs, markdown

Avoid anonymous URL shorteners — they cannot be edited and carry link rot risk.

Python Reference Implementation

A Python reference implementation (aipm.py) is available for generating AIPM 1.2 URLs from build scripts and automation pipelines. It uses only the Python standard library and supports all AIPM 1.2 parameters, W3C SRI hash computation, and URL compression. Download aipm.py →

Regulatory Context

EU AI Act — Article 50

Article 50 of the EU AI Act becomes applicable on 2 August 2026 — and enforcement powers arrive the same day: from that date national authorities and the AI Office can impose fines of up to €15 million or 3% of worldwide annual turnover for breaches of these obligations. The European Commission published the final Code of Practice on marking and labelling of AI-generated content on 10 June 2026 — it is the practical benchmark for demonstrating Article 50 compliance, though voluntary. An "AI Act Omnibus" simplification agreement reached 7 May 2026 extends one deadline: providers of generative systems already on the market before 2 August 2026 have until 2 December 2026 to retrofit machine-readable content marking. All other Article 50 obligations — including disclosure for new systems, chatbot identification, and provenance marking — remain due 2 August 2026. Status note: the European Parliament adopted the Omnibus on 16 June 2026, but it takes legal effect only upon Council approval and publication in the Official Journal (expected before 2 August 2026) — until then, the December date is provisional.

Article 50(4) also contains an editorial-control exemption: AI-generated text published to inform the public need not be disclosed as such where it has undergone human review or editorial control and a natural or legal person assumes editorial responsibility. This maps directly onto AIPM's human-role taxonomy — roles like prompted+reviewed, prompted+edited, and wrote are precisely declarations of that human review, so an AIPM record documents the basis for the exemption even where disclosure is not required.

The Code of Practice introduces a two-layered marking approach (secured metadata + watermarking) and a proposed standardised "AI" visual label. It distinguishes between fully AI-generated content and AI-assisted content with different disclosure requirements — mapping directly to AIPM's role spectrum (automated vs prompted+reviewed etc.).

AIPM can help with disclosure relevant to Article 50 in the following ways — this is not a claim of legal compliance; see the disclaimer below.

• Article 50(1) / 50(2) — disclosure for AI-generated audio, video, images, and text. Set type=audio, type=video, type=image, or type=text to enable the Article 50 notice on the AIPM provenance page. AIPM's role values map to the "fully AI-generated" / "AI-assisted" taxonomy the Code requires.
• Article 50(4) — institutional disclosure. Use org to identify the responsible organization.
• AIPM as a provenance record — the AIPM URL provides human-readable disclosure that survives printing and physical distribution via QR code. It complements (does not replace) machine-readable watermarking where technically feasible.

AIPM provides a disclosure mechanism. It does not substitute for legal advice on AI Act compliance, which may require additional technical measures (watermarking, C2PA metadata). This section was last reviewed 2 July 2026 against the sources below and may not reflect subsequent regulatory changes — always confirm current requirements with qualified legal counsel and the primary sources. See the EU AI Office Code of Practice → for the final requirements (published 10 June 2026).

California — SB 942 as amended by AB 853

California SB 942 (AI Transparency Act), as amended by AB 853 (signed October 13, 2025), has an operative date of 2 August 2026 — deliberately aligned with the EU AI Act. AB 853 extended obligations beyond the original covered providers (generative AI systems with 1M+ monthly users) on a phased schedule: large online platforms (2M+ monthly users) and generative-AI hosting platforms from 1 January 2027, and capture-device manufacturers from 1 January 2028. Follow-up legislation addressing implementation is expected during 2026.

Scope note on watermarking: SB 942's latent and manifest disclosure obligations apply to AI-generated or substantially altered image, video, and audio content; text-only outputs fall outside the statute's watermarking requirements. AIPM itself is content-type-neutral — it works identically for text, code, image, audio, video, and multimodal content — so creators marking any content type can use this note to see where the California obligations do and do not apply to them.

AIPM URLs can serve as the provenance record in SB 942 disclosures — the URL encodes model, role, date, and context in a machine-readable, human-readable format requiring no proprietary tooling to inspect.

Security Considerations

Security note AIPM is a declaration-based standard. Any creator can generate an AIPM mark with any field values — there is no cryptographic verification of claims. Trust is based on context, source credibility, and the verifiable consistency of the record. AIPM does not assert the identity of the creator — it records what the creator chose to declare. A reader who trusts the channel through which they received the content (a known author, a verified publication, a signed email) can treat the AIPM record as part of that trusted context. For content where identity matters, pair AIPM with a signing mechanism (PGP, document signing) that independently verifies authorship.

The hs and hd hash parameters provide file integrity verification — a Verified result confirms the file is unchanged since hashing, but does not authenticate the identity of the creator.

For creators generating AIPM marks

• All QR generation and URL construction happens locally — no data is sent to any server.
• File hashing is entirely local — your files are not uploaded anywhere.
• All fields in an AIPM record are publicly visible to anyone with the URL. Do not include sensitive or private information in any field.

For implementors rendering AIPM records

• Validate all URLs before rendering as links. The src, doc, and prev fields are untrusted input. Security note Accept only https:// and http:// schemes; reject all others.
• Escape all string values before DOM insertion. Every field from the hash must be HTML-escaped, including hash values and type strings.
• Escape JSON-LD output. If rendering JSON-LD structured data, replace </ with <\/ in the serialized JSON to prevent script tag breakout.
• Hash values before DOM insertion. Pass hs and hd through HTML escaping before display — even though valid SHA-256 base64url is safe, do not rely on format validation.
• File operations are local only. Hash computation (crypto.subtle) and file extraction (FileReader, PDF.js, mammoth) all run client-side. No file or file content is transmitted to any server.
• crypto.subtle requires a secure context (HTTPS or localhost). If unavailable, hash zones show a clear error rather than failing silently.

Privacy

Privacy note In AIPM 1.1 and later, all provenance metadata is encoded in the URL hash fragment. Hash fragments are processed entirely by the browser and are never sent to the AIPM server — the server sees only the base path (aipmq.org/1.2/aipm/). AIPM 1.0 is the exception: it used query parameters, which are included in the HTTP request and may be logged by the server.

Privacy note Following a src, doc, or prev link may take you to a non-AIPM page with its own logging, tracking, privacy, or data retention practices. AIPM does not control those pages and makes no representation about them.

Privacy note Similarly, using the "Try it" links on the provenance page sends your context or linked resources to the selected AI service. Review that service's privacy policy before sharing sensitive content.

Security note All fields in an AIPM provenance URL are publicly visible to anyone who scans or opens the URL. Do not include sensitive or private information in any field.

Accessibility

All AIPM 1.2 pages target WCAG 2.1 AA compliance. Known shortfalls from AAA are documented below.

Verified AA conformance includes:

• Skip navigation link on every page
• All interactive elements keyboard accessible, with visible focus indicators (2px solid outline)
• File upload and hash verification accessible via "Choose file" / "File ↓" buttons — drag-and-drop is an enhancement, not the only path
• All images (QR codes, badges, SVG marks) include meaningful alt text
• QR canvas elements given role="img" and descriptive aria-label after rendering
• Form fields have associated <label> elements or aria-label attributes
• Error and result messages in aria-live="polite" regions
• Toggle switches use role="switch" with aria-checked updated on state change
• Colour contrast: body text #111111 on #f9f9f7 = 19:1 (AAA); secondary text #525252 on #f9f9f7 = 7.4:1 (AAA); secondary text on #f0f0ec background = 6.4:1 (AA)

The QR mark is a visual medium. AIPM addresses this: the generator always displays the full provenance URL as copyable text, and the provenance page is reachable directly via URL. Recommended alt text for QR marks in documents:

alt="AI Provenance Mark QR code — scan or visit [URL] for details"

Known WCAG AAA shortfalls

• Context-sensitive help (AAA 3.3.5): Not all form fields have an inline help mechanism. Most fields have hint text, but AAA requires a mechanism for every input. The Implementor's Guide contains extended field documentation.
• Reading level (AAA 3.1.5): The specification page is written at a technical level above lower secondary education. No simplified alternative exists. This is accepted for a technical spec audience.
• Enhanced contrast (AAA 1.4.6): Body text uses #111111 on #f9f9f7 (contrast 19:1, passes AAA). Secondary text uses #525252 on #f9f9f7 (7.4:1, passes AAA). Interactive control labels at reduced weight may not meet 7:1 for all states — full audit in progress.

Comparison: AIPM and alternatives

Several approaches exist for disclosing AI involvement in content. They serve different audiences and solve different problems — most are complementary rather than competing.

IBM AI Attribution Toolkit (aiattribution.github.io) — IBM Research prototype; questionnaire-style disclosure statement in a Creative Commons–inspired format. Text output only; no QR or machine-readable URL. Apache 2.0. AID Framework (aidframework.org) — by Dr. Kari Weaver (University of Waterloo); CRediT-inspired taxonomy for academic and research writing. Strong adoption in the library and academic community. CC-BY-SA 4.0. Both are complementary to AIPM — the AID Framework statement and an AIPM QR mark can appear side by side in a document.

Glossary

Terms are listed alphabetically. Each term has its own anchor for direct linking.

AIPM

AI Provenance Mark. An open, CC0 standard for disclosing AI involvement in content creation. Pronounced "ape 'em".

AIPM record

A single provenance declaration encoded as a provenance URL. The canonical form of an AIPM disclosure.

AIPM provenance URL

A plain HTTPS URL with all provenance metadata encoded in the hash fragment. Source of truth for an AIPM record. Never sends metadata to any server (AIPM 1.1+).

authenticity

Whether a claim in an AIPM record is truthful. AIPM is declaration-based — it records what the creator chose to declare, not cryptographically verified facts. See also: declaration-based standard.

badge

A compact rectangular SVG that links to the provenance URL. Displays AIPM v1.2 with an optional role abbreviation. Used in digital contexts — GitHub READMEs, blogs, web pages, email signatures.

citation in text

A formatted citation string (AIPM, APA 7th, MLA 9th, Chicago, or AID Framework) generated from provenance URL metadata. Copied from the provenance page for use in footnotes, acknowledgements, and README files.

consumer

Any person or system that reads, scans, or verifies an AIPM record. Distinguished from a generator (creator) and a verifier (integrity checker).

declaration-based standard

A standard where disclosures are self-reported rather than cryptographically proven. AIPM records what the creator declares; trust is based on context, source credibility, and consistency — not digital signatures. Contrast with C2PA.

display page

The page at aipmq.org/1.2/aipm/ that renders a provenance URL into a human-readable provenance record. Also called the provenance page.

doc

Optional parameter. A URL linking to a Full Context Document — a hosted file containing the full prompt, methodology, or session log for the content. See Full Context Document.

Full Context Document

A document hosted at a durable URL that contains the detailed context behind an AIPM record — prompts, methodology, session logs, or editorial process. Referenced via the doc parameter. Always capitalised.

generator

A tool or implementor that creates AIPM provenance URLs. The AIPM generator at aipmq.org/1.2/generate/ is the reference implementation. Generators MUST support SHA-256 and SHA-384.

hd

Optional parameter. A W3C SRI hash of the Full Context Document file, used to verify the document has not changed since marking. Format: sha256-base64url or sha384-base64url.

hs

Optional parameter. A W3C SRI hash of the source content file, used to verify the file has not changed since marking. Format: sha256-base64url or sha384-base64url.

integrity verification

Confirming that a file matches the hash stored in hs or hd. A match proves the file is unchanged since marking; it does not authenticate the creator's identity.

prev

Optional parameter. A URL pointing to the previous AIPM record for this content — used when updating or upgrading a mark to create a provenance chain.

Privacy note

A label used in this specification to flag text with privacy implications — particularly around what data may be sent to external parties. See Privacy.

provenance page

The human-readable page rendered from a provenance URL. See display page.

QR mark

The provenance URL encoded as a QR image with the AIPM mark composited at center. Scannable with any smartphone camera. The preferred term for the scannable form of an AIPM record.

qr=0

A plain URL parameter (never inside the z payload) signalling that this AIPM record exceeds QR code capacity and exists as a URL-only record. No QR mark was generated.

Recommendation

A label used in this specification for guidance that implementors are strongly encouraged to follow but that is not strictly required for conformance.

Requirement

A label used in this specification for normative conformance obligations — behavior that generators or verifiers MUST implement.

Security note

A label used in this specification to flag text with security implications for implementors.

Show mode

A display mode that adds the role abbreviation (e.g. P+R, H, AI) as a third line on the AIPM mark at the center of the QR code. Show mode is on by default; set show=0 to disable it. Does not affect the badge.

src

Optional parameter. A URL linking to the content this AIPM record applies to. HTTPS recommended; HTTP permitted in AIPM 1.2.

verifier

A tool or implementor that checks the integrity of files using hs or hd hashes. Verifiers MUST support SHA-256, SHA-384, and SHA-512.

z payload

A deflate-raw compressed, base64url-encoded JSON object containing all provenance metadata, used when the plain URL would exceed ~200 characters or the QR byte limit. The qr parameter must never be placed inside the z payload.

License

The AIPM specification and all associated documentation are dedicated to the public domain under Creative Commons CC0 1.0 Universal. You may use, adapt, implement, and build upon AIPM without restriction and without any attribution requirement. No rights reserved.

Full legal text →