AIPM 1.2 Specification

Overview

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

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.

Four AIPM Artifacts

AIPM combines four elements:

1. A stable visual mark centered within a QR code.
2. A QR code encoding an HTTPS URL with provenance metadata in the hash fragment.
3. A compact badge for digital contexts where QR codes are impractical — GitHub, blogs, email.
4. A human-readable provenance page that renders the metadata client-side — no server lookup required.

Every AIPM provenance record starts as a URL. From that URL, two visual artifacts can be derived.

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.

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 defaults to on in the AIPM generator and is accessible 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 organisations subject to EU AI Act Article 50 disclosure requirements, where compliance 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 Compliance for details.

File Integrity Hashing (hs / hd)

The hs and hd parameters store SHA-256 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

SHA-256 produces a 256-bit (32-byte) digest. The choice of encoding determines how many characters that digest occupies in the URL, which matters for QR code capacity.

AIPM uses W3C SRI format because it is algorithm-agile: the algorithm (sha256) is explicit in the value itself. If SHA-256 were ever weakened, future marks could use sha3-256-… or sha512-… without changing the parameter names. The 7-byte overhead of the prefix is small — with both hs and hd, AIPM's SRI format uses 100 chars vs 128 chars for hex, saving 28 bytes against the 1000-byte QR limit.

Hex is always accepted and auto-converted. Terminal tools (shasum, Get-FileHash) output hex. You can paste hex directly into the generator or the verification paste field — the conversion to SRI format is automatic and silent (a confirmation message appears in the generator).

Hash specification

• Algorithm: SHA-256
• Encoding: W3C SRI format — sha256-<base64url> (50 chars). Hex (64 chars) and plain base64url (43 chars) also accepted and auto-normalised.
• 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". The hash is computed locally in the browser using the Web Crypto API — the file never leaves your device. Files up to approximately 2 GB can be hashed in the browser.

For files over 2 GB, use the terminal. Note: terminal tools output hex (64 lowercase hex characters) — paste the output directly into the hash field or verification paste box and it will be auto-converted to SRI format.

Mac / Linux:   shasum -a 256 filename
               → outputs: b94d27b9...  filename  (hex — 64 chars)

Windows 10+:   Get-FileHash filename -Algorithm SHA256
               → outputs: Hash: B94D27B9...  (hex — 64 chars, uppercase)
               (PowerShell 5.1+, included with Windows 10 and later)

Terminal output can be pasted directly — the generator and provenance page both auto-convert hex to SRI format.

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: 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:

Only https:// URLs are accepted — all other URI schemes are rejected.

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

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": 1,                    // Recommended — integer 1 or omitted, 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 behaviour), handling all three formats transparently.

Upgrading an existing mark to 1.2

To upgrade an existing AIPM 1.0 or 1.1 URL to 1.2, open it in the 1.2 generator using the "Update this mark" link on the display page. The generator will pre-fill all existing fields, set the previous mark URL automatically, and generate a new 1.2 URL. The old URL continues to resolve — the new one adds prev to link back, creating a provenance chain.

Alternatively, any AIPM URL can be manually upgraded by changing the version path from /1.0/aipm/ or /1.1/aipm/ to /1.2/aipm/ and changing v=1.0 or v=1.1 to v=1.2.

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 Compliance

EU AI Act — Article 50

Article 50 of the EU AI Act becomes applicable on 2 August 2026. A second draft Code of Practice on marking and labelling of AI-generated content was published March 5, 2026; the final Code is expected June 2026 and will be the practical benchmark for compliance. An "AI Act Omnibus" simplification agreement was reached May 7, 2026, clarifying requirements and extending some deadlines.

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 supports Article 50 compliance in the following ways:

• 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 organisation.
• 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). Monitor the EU AI Office Code of Practice process → for final requirements.

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 to large online platforms (2M+ monthly users) and camera manufacturers in addition to the original covered providers (generative AI systems with 1M+ monthly users).

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

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. 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.

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.

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 →