Explore AI-Provenance for MIF units (related, extended, or unique provenance block)

[zircote]

Summary

Explore adding AI-Provenance to MIF: a provenance facet that records the
AI-authorship context of a unit (which model authored it, in which session, under
what authoring mode and cohort, what proportion was AI-generated, and whether a
human ratified it). Weigh three shapes: a related sibling block, an
extension of the existing provenance block, or a unique provenance
profile.

Motivation

MIF's Level-3 provenance block (in schema/mif.schema.json) records who and what
produced a unit through W3C PROV: sourceType, trustLevel, confidence,
agent, agentVersion, sourceRef, wasGeneratedBy, wasAttributedTo and
wasDerivedFrom. That captures attribution and derivation, but not the operational
AI-authorship context that matters once AI-assisted authoring is routine:

• the exact model resolved at generation time (not a static agent string),
  which can change across a single session;
• the session the unit came from, for lineage;
• whether it was produced by an autonomous workflow, an interactive agent,
  or a human;
• the cohort the authorship falls in (human-authored, AI-assisted,
  AI-generated-autonomous);
• the proportion of the unit that was AI-generated or AI-modified;
• whether a human reviewed and ratified it.

As AI authorship becomes the norm, a MIF unit should be able to answer "how was
this authored, by which model, in which session, and was it human-ratified" as
structured provenance that audit, trust-scoring, governance and attestation
consumers can read deterministically.

The provenance details (the candidate field set)

A small, parseable AI-authorship field set, modeled on AI-authorship metadata
already used as a structured block on versioned artifacts:

• aiModel: the specific model resolved live at generation time, self-correcting
  across mid-session model switches, distinct from the static agent.
• authoringAgent / aiTool: the agent surface (interactive CLI agent, IDE,
  autonomous workflow runner).
• authoringMode: for example interactive-agent, autonomous-workflow,
  human-authored, human-ratified.
• cohort: the authorship classification (human-authored, AI-assisted,
  AI-generated-autonomous).
• sessionId: the authoring session identity, for lineage across units.
• generatedAt: the AI generation timestamp, distinct from
  temporal.recordedAt.
• aiContributionRatio: the proportion of the unit that was AI-generated or
  AI-modified, in the range 0 to 1.
• humanRatified and ratifiedBy: whether a human reviewed and approved the unit,
  and who.
• optional linkage to the originating source or VCS object.

Design options to weigh

• (A) Related sibling block. A new top-level aiProvenance object alongside
  provenance, keeping the PROV-O provenance graph and the AI-authorship facet
  cleanly separable.
• (B) Extension of the existing provenance block. Add the fields above to the
  current provenance object (which already declares additionalProperties: true)
  as OPTIONAL fields, so AI-authorship lives in one provenance graph.
• (C) Unique provenance profile. A distinct @type (for example
  AIProvenance) that specializes PROV-O for AI authorship, possibly with its own
  conformance expectations.

Tradeoffs: separability and schema clarity (A and C) against single-block
simplicity and backward compatibility (B); how each maps to PROV-O; and whether the
facet is ever required or always optional.

MIF integration considerations

• PROV-O alignment. Model the authoring as a prov:Activity (wasGeneratedBy)
  attributed to a prov:SoftwareAgent (the model), so AI-Provenance is a typed
  specialization rather than a parallel vocabulary.
• Schema and versioning. Any new required field is breaking. Keep AI-Provenance
  OPTIONAL and additive, with the canonical schema $id values unchanged (ADR-007),
  and apply the mirror and alias discipline if a new schema file is added.
• Round-trip. The field set must round-trip markdown to JSON-LD losslessly and
  validate at Level 3.
• Record the decision as an ADR under adr/.

Acceptance criteria (EARS)

• The exploration SHALL produce a recommendation among related, extended, or
  unique, with the PROV-O mapping for the chosen shape.
• WHERE AI-Provenance is added, it SHALL be OPTIONAL and additive: no existing
  document becomes invalid, and the canonical schema $id values SHALL remain
  unchanged.
• A worked-example MIF unit carrying AI-Provenance SHALL validate at Level 3 and
  round-trip losslessly.
• The chosen shape SHALL be recorded as an ADR.

Open questions

• Is AI-Provenance a sibling, an extension, or a new type? This is the core
  question.
• Should any MIF level ever require it, or is it always optional?
• How does it interact with trustLevel (does an unratified, autonomously
  AI-generated unit cap trust)?
• Privacy: session identifiers and model identifiers in published units may need a
  redaction policy.

Scope

A specification and schema exploration plus an ADR. No breaking change to the
existing provenance block.

---

Opened from issue #191 and moved here as an idea.