The governance gap in enterprise AI is not a shortage of frameworks. The EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework all mandate that high-risk AI systems maintain records sufficient to allow post-hoc evaluation of system behavior. What these frameworks do not provide is a definition of what information must be in that record.

In practice, this gap produces a characteristic failure mode: an organization receives an audit inquiry about an AI-assisted decision from three months prior and discovers that while they logged the output, they cannot reconstruct the conditions that produced it. The model has been updated. The retrieved context is no longer available. The prompt template was modified in a hotfix and not versioned. The inference temperature was tuned without a change log entry.

This failure mode is not a logging deficiency in the narrow sense. It is an architectural property: the system was not designed to capture the information that would be needed to answer the audit question. We call this condition Provenance Opacity, and we show that it is endemic to deployments that were not designed with Output Genealogy in mind from the start.

This paper makes three primary contributions:

• C1. The formal definition of Output Genealogy G(o) as a 5-tuple that specifies every condition necessary and sufficient to audit an AI output against its generative state.
• C2. The formal definition of Provenance Opacity as a structural condition of a deployment, with an analysis of which components of G(o) are most frequently absent and why.
• C3. The Retroactive Unverifiability existence result: a formal demonstration that once time-varying components of G(o) are lost, reconstruction is architecturally impossible regardless of log retention policy.

We additionally introduce the Output Genealogy Maturity Model as an indicative adoption framework and provide component-level implementation guidance mapped to existing regulatory requirements.

The remainder of this paper is organized as follows. Section II reviews existing work on AI provenance, data lineage, and model documentation. Section III introduces Output Genealogy and its components. Section IV defines Provenance Opacity and analyzes deployment failure modes. Section V establishes Retroactive Unverifiability. Section VI presents the Maturity Model. Section VII discusses regulatory alignment and limitations. Section VIII concludes.

The model documentation literature has focused on artifact-level provenance: Datasheets for Datasets [1] and Model Cards [2] introduced structured disclosure at the level of the training artifact. These frameworks answer questions about what a model was trained on and how it was evaluated, but do not address the conditions under which a specific output was generated. An organization with a complete Model Card still cannot reconstruct the prompt, retrieved context, or inference configuration that produced a disputed output.

The influence function literature [3] addresses attribution at the training data level, estimating which training examples most influenced a given prediction. This is a powerful tool for understanding model behavior in aggregate, but it operates on the model artifact, not on the deployment state. In a RAG deployment, the most influential factor in a specific output is often the retrieved document, not the training data: influence functions do not model retrieval.

Retrieval-Augmented Generation [4] introduced the architectural pattern that now dominates enterprise AI deployments: a retrieval step pulls context documents from an external store, and those documents condition the generation. This architecture creates a fundamental provenance challenge: the output depends on both the model state and the retrieval state at generation time, and the retrieval state changes continuously as documents are updated, added, or removed from the store.

The prompt sensitivity literature [5] demonstrates that AI outputs are highly sensitive to prompt ordering and wording. This finding implies that provenance capture must include the exact prompt used, not merely the template identifier, because template instantiation at query time may differ from the stored template if either the template or the input data changed between logging and audit.

Raji et al. [6] analyze the accountability gap in AI systems, identifying the disjunction between regulatory intent and operational capability as the primary barrier to meaningful AI audit. Our contribution operationalizes the accountability gap in the specific context of output provenance: we provide the missing definition that regulatory frameworks presuppose but do not supply.

No existing work, to our knowledge, defines the minimum information set required for an AI output to be auditable, names the structural condition in which that information is unavailable, or establishes the impossibility result for retroactive reconstruction. These are the three contributions of this paper.

When a regulator, auditor, or affected party asks "why did the system produce this output?", the question is not about the model's weights in the abstract. It is about the specific generative state at the moment the output was produced. That generative state has five components, each of which can vary independently over time. A complete audit answer requires the values of all five at the moment of generation.

M: Model Version. The model version must uniquely identify the model artifact used at generation time. For self-hosted deployments, this is a weights checksum or git SHA. For API deployments, this is the exact model identifier returned in the API response, not the alias (e.g., "claude-opus-4-8" vs. a versioned snapshot reference). Aliases resolve to different underlying versions over time, creating a class of M-ambiguity that makes G(o) non-reconstructible even when the alias is logged.

P: Resolved Prompt. Prompt templates with variable substitution create a critical distinction: the template identifier is not equivalent to the resolved prompt. Logging the template identifier without the resolved values at generation time means P cannot be reconstructed when the template or input data changes. P must be the complete, resolved prompt text as submitted to the model.

C: Retrieved Context Sequence. For RAG deployments, the retrieved context C is the sequence of text passages retrieved, in the order they were presented to the model. Order matters: the prompt sensitivity literature [5] establishes that output is sensitive to the ordering of context passages. C must include passage text, not merely document identifiers, because passage extraction logic may change.

D_r: Source Document Set. D_r is the set of source documents from which C was drawn, with version identifiers. As the document store evolves, the same retrieval query will return different passages: D_r records the state of the store that produced C. For non-RAG deployments, D_r is the empty set.

Theta: Inference Configuration. Temperature, top-p, and other generation parameters directly affect output stochasticity. An audit that cannot establish Theta cannot determine whether a different output was possible under the same M, P, and C. For deterministic inference (temperature=0), Theta's contribution to output variance is zero, but Theta must still be recorded to establish this fact for the auditor.

G(o) is not a best-effort record. It is a binary property: either all five components are captured at generation time, or the output is not genealogy-complete. Partial G(o) captures, in which M and P are logged but C and D_r are not, are common in practice but do not satisfy regulatory audit requirements, because the missing components are precisely those that explain the content of the output in a RAG deployment.

Provenance Opacity is a property of the deployment architecture, not of an individual logging event. A deployment can produce thousands of correctly-logged outputs and still be Provenance-Opaque if even one component of G(o) is not captured. This is the architectural sense in which Provenance Opacity is structural rather than incidental.

In practitioner observation, Provenance Opacity arises from four distinct failure modes:

Alias Resolution Failure. The deployment logs an API model alias rather than a versioned model identifier. When the alias resolves to a new model version (through provider updates), historical logs become ambiguous: M cannot be reconstructed from the alias alone.

Template-Variable Collapse. The deployment logs the prompt template identifier without resolving template variables to their generation-time values. When the template is updated or the input data schema changes, P cannot be reconstructed.

Retrieval Statelessness. The deployment does not log retrieved passages or their source documents at generation time. As the document store evolves, C and D_r cannot be reconstructed: a re-run of the same query against the updated store produces different results.

Configuration Drift. Inference parameters are tuned without version control. Theta at generation time differs from Theta in the deployment configuration at audit time, and no record exists of the change.

Observation 1 has a direct regulatory consequence: an organization in a state of Provenance Opacity at t_g cannot become compliant retroactively for outputs produced in that period, regardless of what engineering work is done at t_a. The audit obligation applies to outputs already produced, not only to future outputs. This is why Provenance Opacity is a present liability, not a future risk.

Theta is partially reconstructible if and only if inference parameters are maintained in an immutable, timestamped configuration store. This is the only exception to Retroactive Unverifiability: a component is reconstructible at t_a if and only if its value at t_g was recorded in a system that is itself auditable, which returns the problem to G(o) capture for the configuration store.

M is partially reconstructible if the model provider maintains immutable versioned snapshots accessible by timestamp, and the deployment logs the precise timestamp of the API call alongside the alias. This recovery path exists for some major model providers but is not guaranteed by any current provider SLA. It should not be relied upon as a substitute for logging the resolved model identifier at generation time.

Retroactive Unverifiability has a direct implication for compliance architecture: G(o) capture must be in place before the first regulated output is produced, not after the first audit inquiry is received. This is the architectural analogue of the data retention principle: you cannot retain data you did not capture.

This principle is not currently reflected in enterprise AI deployment practices. In practitioner observation, the sequence is typically: pilot deployment, regulatory inquiry, discovery of Provenance Opacity, remediation effort. Remediation addresses future outputs but cannot close the gap for the period of Opacity already incurred. The Output Genealogy Framework is designed to invert this sequence.

We define four tiers of Output Genealogy maturity. Organizations advance through tiers as they instrument additional components of G(o) and integrate genealogy capture into their deployment lifecycle. The tiers are indicative and based on practitioner observation of enterprise AI deployment patterns.

The organization logs AI output text and timestamps. No component of G(o) is captured beyond partial P (the raw user input, not the resolved prompt). This tier satisfies no current regulatory audit requirement and is Provenance-Opaque by construction. In practitioner observation, this represents the most common starting state for enterprise AI pilots.

The organization captures M (resolved model identifier, not alias) and P (fully resolved prompt text). C, D_r, and Theta remain uncaptured. This tier is sufficient for non-RAG deployments with fixed inference parameters, and represents partial compliance for simple text generation use cases. For RAG deployments, Tier 2 is insufficient: the output content is primarily determined by C and D_r, which are not recorded.

The organization captures all five components of G(o) at generation time. The Genealogy Store is write-once and tamper-evident. This tier satisfies the record-keeping requirements of EU AI Act Article 12 and ISO 42001 clause 9.1 as applied to individual outputs. It does not yet integrate G(o) into change management, alerting, or continuous compliance processes.

G(o) capture is integrated with the deployment lifecycle: model version changes, prompt template updates, and document store changes trigger automated genealogy audit events. The organization maintains a continuous compliance posture in which Provenance Opacity is detected and remediated before regulated outputs are produced in an opaque state. Genealogy data is used proactively for incident investigation, not only reactively for audit response.

The EU AI Act Article 12 requires that high-risk AI systems maintain logs sufficient to allow post-hoc assessment of system performance and inputs. The regulation specifies that logs must include "the data used for training, testing and validation" and "input data" but does not define what constitutes complete input data for a generative AI system. G(o) provides this definition: the complete input to a generation event is (P, C, D_r), not merely the user-supplied query.

ISO/IEC 42001 clause 9.1 requires monitoring, measurement, analysis, and evaluation of the AI management system, including "the criteria against which AI system performance will be evaluated." For generative AI systems, performance evaluation requires G(o): without knowing the exact conditions under which an output was produced, evaluating whether the system performed correctly is not meaningful. ISO 42001 does not specify what information must be recorded to enable this evaluation.

NIST AI RMF GOVERN 1.7 identifies provenance as a key risk category and requires that organizations "identify and manage the provenance of AI data, models, and tools." This guidance covers artifact-level provenance (consistent with Model Cards and Datasheets) but does not address generation-event provenance. G(o) fills this gap.

The Output Genealogy framework addresses single-model, single-inference-step deployments. Multi-agent and chain-of-thought deployments, in which multiple inference steps produce a final output, require an extended formulation: G(o) for a multi-step output is a directed acyclic graph of generation events, each with its own 5-tuple, connected by data flow edges. This extension is a direction for future work.

The framework does not address the storage cost of genealogy-complete logging. In high-volume deployments, logging full prompt and retrieved context text for every generation event can be substantially more expensive than logging only the output. Practical implementations may use compression, deduplication, and sampling strategies that must be evaluated against regulatory requirements before adoption. A sampled genealogy log may satisfy some compliance frameworks but not others.

Theta capture assumes that inference parameters are accessible to the logging layer. For black-box API deployments in which the provider does not return full inference configuration in the API response, Theta reconstruction depends on what parameters the deployment controls versus what the provider sets internally. This limitation should be surfaced in compliance assessments of black-box API deployments.

Output Genealogy is distinct from data lineage as practiced in data engineering. Data lineage tracks the transformation history of data from source to destination: how a dataset was derived, cleaned, joined, and aggregated. G(o) tracks the generative conditions of a model output: not the history of the data but the state of the system at a specific generation event. The two concepts are complementary: G(o) extends data lineage to the AI generation event as a first-class provenance object.

We have introduced Output Genealogy G(o) as the 5-tuple (M, P, C, D_r, Theta) that formally specifies the conditions necessary and sufficient for an AI output to be auditable. We have defined Provenance Opacity as the structural condition in which a deployment cannot produce G(o), and established Retroactive Unverifiability as the existence result that Provenance Opacity, once incurred, cannot be remediated retroactively for the period of opacity. We have mapped these constructs to EU AI Act Article 12, ISO 42001 clause 9.1, and NIST AI RMF GOVERN 1.7, demonstrating that these regulatory frameworks presuppose Output Genealogy without defining it.

The practical implication is direct: any enterprise AI deployment that does not capture all five components of G(o) at generation time is Provenance-Opaque and cannot satisfy audit requirements for outputs produced in that state, regardless of subsequent engineering remediation. The Output Genealogy Maturity Model provides an indicative path to Tier 3 compliance, which we estimate as indicatively achievable within a focused 60-to-90 day engineering effort for a team of two to four engineers with access to the deployment's inference pipeline.

The coined terms introduced in this paper, Output Genealogy, Provenance Opacity, and Retroactive Unverifiability, are intended as vocabulary for practitioners, compliance officers, and regulators to communicate precisely about what an AI audit trail must contain and what the consequences are of failing to capture it. The vocabulary is operational: a CISO can use these terms to specify audit requirements, an engineer can implement them as capture criteria, and a regulator can reference them to evaluate whether a deployment satisfies the record-keeping intent of existing frameworks.

Future work includes the multi-agent extension of G(o) to directed acyclic graph structures, the development of sampling strategies for high-volume deployments that preserve statistical audit capability, and empirical measurement of Provenance Opacity prevalence across enterprise AI deployment cohorts.

© 2026 Arjun Jaggi and Aditya Karnam Gururaj Rao. All rights reserved. Academic citation permitted with attribution; commercial use and derivative frameworks require written permission.