AIIR as a protected-path policy input

A public implementation note for requiring valid AIIR receipts when AI use is declared on protected repository paths.

Status Draft public note. Narrow goal: let repository policy ask for a valid AIIR receipt when declared AI involvement touches a protected path.

Narrow goal

The policy layer should not need to understand every AIIR field. It only needs to know whether a valid receipt exists for the commit under review and whether policy requires that receipt for the affected path set.

This page is about repository policy evaluation. Attestation emission and provenance graph ingestion are separate adapter notes.

Illustrative policy shape

# illustrative only — not current project syntax
rules:
  - name: require-aiir-on-protected-paths
    when:
      paths: ["src/", "policy/", ".github/workflows/"]
      declared_ai: true
    require:
      - aiir_receipt_present
      - aiir_receipt_valid
      - aiir_receipt_matches_commit

The policy surface stays narrow: the repository policy decides when the rule applies, and AIIR only answers receipt questions.

Why this is useful

Protected-path policy gets a simple allow-or-deny signal.
AIIR stays a local-first receipt and verification tool rather than becoming a policy engine.
Teams can phase this in path by path instead of changing the whole repository at once.

Boundaries

This does not claim AIIR proves undeclared AI use.
This does not ask repository policy to adopt AIIR as its only provenance source.
This note is about repository policy evaluation, not attestation emission or provenance graph ingestion.
This does not require a hosted AIIR service or central gatekeeper.

Next public step

If the shape is useful, the next public step is a design issue or example repository that shows one protected-path rule and one failing case.

See in-toto policy input → Back to ecosystem →