This document outlines the AILint Marker Specification, detailing the purpose, design principles, types of markers, payload rules, precedence, loss considerations, and security aspects.
2.9 KiB
AILint Marker Specification (v1.0)
- Purpose
Markers are transport mechanisms for carrying AI provenance signals alongside content.
They exist to:
preserve provenance across systems,
survive common transformations (copy, format, diff),
provide machine-readable hints without enforcing interpretation.
Markers do not define truth. They only reference or carry provenance declarations.
- Design Principles
Markers MUST be:
Non-semantic – removing a marker must not change meaning
Loss-tolerant – stripping a marker must not invalidate content
Non-covert – presence must be auditable by tooling
Non-authoritative – never the sole source of provenance truth
Markers SHOULD be:
Minimal
Stable across encodings
Easy to ignore safely
- Marker Types
AILint defines four marker classes, ordered from most robust to most fragile.
3.1 Git Metadata Marker (Normative)
Format: Git trailer
AILint-Provenance:
Example:
AILint-Provenance: prov-2025-01-001
Properties:
Highly durable
Survives formatting and refactoring
Preferred for CI/CD and audits
Status: Recommended
3.2 Inline Comment Marker (Normative)
Used when human readability matters.
Examples:
// AILINT: ai_involved=true; role=assisted
Rules:
MUST be placed in comment-safe regions
MUST NOT affect execution or rendering
SHOULD be concise
Status: Recommended
3.3 Structured Header / Frontmatter Marker (Normative)
Example (YAML frontmatter):
ai_provenance: ai_involved: true role: summarized
Rules:
MUST follow host format conventions
MUST be parseable without executing content
Status: Recommended
3.4 Embedded / Invisible Marker (Optional, Non-Normative)
Examples:
Zero-width Unicode characters
Non-printing delimiters in comment whitespace
Rules:
MUST NOT encode full provenance data
MUST be removable without semantic loss
MUST NOT be the only provenance signal
SHOULD be detectable by linters
Status: Optional / Transport-only
- Marker Payload Rules
Markers MAY contain:
A provenance reference ID
A minimal inline declaration
Markers MUST NOT contain:
Personal identifiers
Behavioral telemetry
Sensitive operational metadata
Enforcement or policy flags
- Marker Precedence
Markers are interpreted only after authoritative provenance sources.
Precedence order:
Sidecar manifest
Git metadata
Inline / header markers
Embedded markers
- Marker Loss and Degradation
Loss of a marker:
MUST NOT invalidate content
MUST NOT imply tampering
MAY reduce downstream confidence
AILint tooling SHOULD treat missing markers as:
“No explicit signal present,” not “signal denied.”
- Security Considerations
Invisible markers MUST NOT form covert channels
Tooling SHOULD provide normalization and stripping options
Markers MUST NOT bypass content security reviews
- Summary
Markers carry provenance. They do not define it.