The W3C PROV Recommendation (2013) provides a stable, widely-deployed data model for tracking data transformation. The PROV-DM specification defines provenance as "a record that describes the people, institutions, entities, and activities involved in producing, influencing, or delivering a piece of data or a thing" (Moreau & Missier 2013). The three core types — Entity ("a physical, digital, conceptual, or other kind of thing with some fixed aspects"), Activity ("something that occurs over a period of time and acts upon or with entities"), and Agent ("something that bears some form of responsibility for an activity") — and six core relations (wasGeneratedBy, used, wasAttributedTo, wasDerivedFrom, wasAssociatedWith, actedOnBehalfOf) are mature infrastructure. Domain-specific extensions exist (ProvONE for scientific workflows, GDPRov for consent tracking). The spec's Entity type does encompass conceptual things, and the core model includes actedOnBehalfOf for basic delegation — so PROV-DM is not limited to data tracking in the narrow sense. But the organizational decision context — why decisions were made, under what constraints, with what alternatives considered, and toward what committed outcomes — exceeds what the model's extension mechanisms (subtyping, expanded relations) can structurally represent, because governance primitives like constraint context, epistemic classification, and decision rationale require infrastructure the PROV data model was not designed to provide.

Buneman, Khanna & Tan (2001) formalized the distinction between why-provenance (which source data contributed to a result) and where-provenance (which locations in source databases data was extracted from) at ICDT 2001. Their syntactic approach modeled provenance in relational and XML data contexts. Cheney, Chiticariu & Tan (2009) added how-provenance — the derivation path or process by which output was produced — in their comprehensive survey for Foundations and Trends in Databases. Herschel, Diestelkämper & Ben Lahmar (2017) organized the entire field by three axes: What for (accountability, reproducibility, debugging), What form (annotations, graphs, logs), and What from (eager vs. lazy capture, workflow vs. OS-level). All three foundational surveys operate at the data level. The why/where/how taxonomy answers: which data influenced this output? Where did data originate? How was it transformed? Organizational governance asks fundamentally different questions: why was this decision made? By whose authority? Under what constraints? Considering what alternatives? Expecting what outcomes?

Singh, Cobbe & Norval (2019) introduced "decision provenance" in IEEE Access, proposing that data provenance methods could expose "decision pipelines" — chains of inputs to, and flow-on effects from, automated decisions — to enhance oversight, auditing, compliance, and user empowerment. Their work emerged from concerns about algorithmic accountability and opacity in systems-of-systems. The contribution is conceptual: they identified the need and proposed a data-flow-oriented approach. They did not provide a formal infrastructure specification — no primitive system, no invariant structure, no operational model for capturing decision rationale at the point of action.

The trajectory begins with Rittel & Webber (1973), who introduced "wicked problems" and the Issue-Based Information System (IBIS) — structuring deliberation as Issues, Positions, and Arguments. Conklin & Begeman (1988) implemented this as gIBIS, a graphical hypertext tool for collaborative IBIS networks, at CSCW '88 — demonstrating the concept could be computerized but revealing the adoption problem: users had to step outside their work to construct rationale artifacts. MacLean et al. (1991) introduced QOC (Questions, Options, Criteria) for design space analysis — more structured than IBIS but still a separate artifact. Lee (1997) synthesized the field in IEEE Expert, documenting that "most current design rationale systems fail to consider practical concerns, such as cost-effective use and smooth integration," and identifying seven technical and business barriers. Dutoit et al. (2006) and Burge et al. (2008) compiled comprehensive Springer volumes on rationale management — the existence of these volumes is itself evidence that three decades of work had not resolved the adoption problem. Tyree & Akerman (2005) pivoted to Architecture Decision Records in IEEE Software, proposing a lightweight template (Issue, Assumptions, Alternatives, Decision, Rationale) to make architecture "more transparent and structured." Jansen & Bosch (2005) named "knowledge vaporization" — architectural knowledge lacking first-class representation — at WICSA 2005. Nygard (2011) popularized lightweight ADRs (Title, Context, Decision, Consequences) on the Cognitect blog, achieving widespread adoption. But Ahmeti, Linder, Groner & Wohlrab (2024) at ECSA 2024 documented through action research that even in a company without proper architecture documentation, introducing ADRs faced significant adoption challenges — determining which decisions warrant records, integrating into existing workflows, and scaling documentation practices.

The 50-year pattern: IBIS (1973) → gIBIS (1988) → QOC (1991) → DRL (1997) → ADRs (2005) → Lightweight ADRs (2011) → still struggling with adoption (2024). Each generation reduces capture burden without eliminating the fundamental problem.

Every design rationale approach — from IBIS through lightweight ADRs — requires extraneous cognitive load: the effort of stepping outside the work to create and maintain separate rationale artifacts. Even Nygard's lightweight format (one-to-two page markdown files) requires practitioners to stop working, open a separate file, write context and consequences, and commit. The burden is reducible but not eliminable within the documentation paradigm. Nonaka & Takeuchi's (1995) SECI model provides additional grounding: design decisions are largely tacit knowledge (acquired through experience, practically useful, not fully articulable). The design rationale tradition attempted externalization — converting tacit to explicit knowledge. Externalization is inherently lossy and effortful. The resolution is not lighter documentation but the elimination of the separate documentation step: making governance context a structural requirement of the operation itself, so that lineage emerges as a by-product of deciding, not a retrospective annotation of having decided.

Walsh & Ungson (1991) established the foundational framework in the Academy of Management Review, identifying five retention facilities: individuals (personal knowledge), culture (language, frameworks), transformations (procedures, systems), structures (organizational hierarchy, roles), and ecology (external archives, physical workspace). Memory is distributed across these facilities — it is a structural property of the organization, not a single store. When any facility degrades (turnover, restructuring, system migration), memory degrades with it regardless of database capacity.

Stein (1995) defined four memory processes — acquisition, retention, maintenance, retrieval — and stressed that maintenance is the critical bottleneck: memory degrades without active investment. Darr, Argote & Epple (1995) demonstrated empirically in Management Science that knowledge depreciates rapidly even in standardized operations: studying 36 pizza franchise stores over 18 months, they found that "as the organizations gain experience in production, the unit cost of production declines significantly," but "knowledge acquired through learning by doing is found to depreciate rapidly." Benkard (2000) confirmed organizational forgetting as structural in aircraft manufacturing in the American Economic Review. Wegner (1987) introduced transactive memory systems, and Ren & Argote (2011) reviewed 76 empirical studies over 25 years in the Academy of Management Annals, finding that transactive memory depends on relationship stability, shared mental models, and communication infrastructure — all disrupted by organizational change. Ackerman & Halverson (2000) demonstrated through ethnographic study that most organizational memory is informal and embedded in practice. Fiedler & Welpe (2010) confirmed across 122 organizations in Organization Studies that structural design determines what organizations remember.

Pollitt (2000) identified four types of institutional amnesia in Prometheus: (1) significant decisions not documented, (2) records lost, (3) archives inaccessible, (4) records exist but no one thinks to use them. Stark (2019) extended this to government. De Holan & Phillips (2004) distinguished accidental forgetting from intentional unlearning in Management Science.

Van der Aalst (2012) established process mining in ACM TMIS as three capabilities: discovery (constructing models from event logs), conformance checking (comparing models against reality), and enhancement (extending models with additional information). Song & van der Aalst (2008) extended this to organizational mining, analyzing roles, resources, and decision patterns from event data. The critical limitation is structural: event logs record what happened and when, but cannot capture why decisions were made. Decision mining can infer decision patterns from behavioral data but cannot reconstruct rationale, authority basis, constraint context, or alternatives considered. Process mining is powerful retrospective analysis; it cannot provide prospective governance. The distinction between reconstructing patterns from event logs after the fact and capturing governance context at the moment of action is architecturally fundamental.

Kroll (2021) established at ACM FAccT that traceability "connects records of how the system was constructed and what the system did mechanically to the broader goals of governance, in a way that highlights human understanding." Traceability requires establishing "not only how a system worked but how it was created and for what purpose." He explicitly identified a gap between what traceability requires and what practitioners have available: the toolbox is insufficient for full traceability implementation. This maps directly to the structural gap identified across the other five traditions: the requirement is established, the consequences of its absence are documented, but the infrastructure is missing.

Mitchell et al. (2019) proposed Model Cards at FAT* 2019 — standardized documentation for ML models covering training data, performance benchmarks, limitations, and intended uses. Gebru et al. (2021) proposed Datasheets for Datasets in Communications of the ACM — documentation of motivation, composition, collection process, and intended uses. Both extend beyond data provenance toward decision provenance: Model Cards capture why models were built and where they perform poorly. Datasheets capture why data was collected and what's excluded. Ojewale, Suresh & Venkatasubramanian (2026) proposed LLM audit trails as "a chronological, tamper-evident, context-rich ledger of lifecycle events and decisions that links technical provenance (models, data, training and evaluation runs, deployments, monitoring) with governance records (approvals, waivers, and attestations)." The AI accountability infrastructure being constructed piecemeal — model cards + datasheets + ML-BOMs + audit trails — addresses the same need that governance infrastructure could provide structurally.

Regulatory frameworks (21 CFR Part 11, SOX Section 404, HIPAA, ISO 9001, ISACA standards) consistently require records of actions taken, by whom, and when. None requires decision rationale, authority basis, alternatives considered, or expected outcomes. Pollitt's (2000) four types of institutional amnesia apply directly: the "why" is either not documented (type 1), lost (type 2), inaccessible (type 3), or ignored (type 4). The gap across all audit standards is not merely an omission — it is the structural source of expensive retrospective reconstruction of decision context from fragmentary evidence, after decision-makers' understanding has degraded or departed.

xAPI captures learning experiences as Actor-Verb-Object JSON statements stored in a Learning Record Store (LRS). IEEE-standardized and deployed across education, defense, and corporate training. The standard defines "actor," "verb," and "object" as required statement components, with verbs defined by communities of practice rather than by the standard itself. xAPI validates the pattern: statement-based capture works at organizational scale. It reveals the gap: no governance primitives (any actor can assert anything), no truth type system (all statements are epistemically equal), no authority model (no delegation chains), no organizational state representation.

Data provenance (F1–F2), design rationale (F4–F5), institutional memory (F6), process mining (F7), AI accountability (F9), and audit compliance (F10) independently converge on the same structure: the requirement for organizational decision provenance is well-established, the consequences of its absence are well-documented, but no infrastructure makes it a structural by-product of organizational operation. The convergence across traditions with different assumptions, methods, and vocabularies arriving at the same boundary is stronger evidence than any single tradition's argument, because the gap is structural — it exists at the intersection of fields, not within any one of them.

Enterprise tools (Apache Atlas, DataHub, Collibra, Informatica, Alation, MANTA) provide technical data lineage — tracking transformations through ETL pipelines, databases, and analytics platforms. Enterprise investment validates the pattern: organizations will pay for lineage infrastructure. No tool provides governance primitives, authority delegation chains, truth type systems, or organizational decision provenance. The market gap mirrors the academic gap.

Three market leaders warrant structural differentiation from DLP architecture:

Collibra AI Agent Registry. Collibra positions AI agents as "governance participants" — agents that propose metadata tags, lineage suggestions, and governance recommendations within the Collibra knowledge graph. The registry is a deployment mechanism for agents to participate in metadata governance. Structural difference from DLP: Collibra's knowledge graph is an asset repository (what data exists, how it relates) and an agent can propose changes to this repository. DLP is a governance protocol (why decisions are made, by what authority, under what constraints) and agents are constrained as AI-Assistive and AI-Agentic non-principals. Collibra invites agents into governance decisions as active proposers; DLP constrains agents to support and inform human decision-makers. This is an important architectural boundary: Collibra is centralized governance-by-agents; DLP is decentralized governance-with-agents. The two are not competitive because they operate at different abstraction levels — Collibra manages metadata asset governance, DLP governs the decisions about assets.

Alation "decision trace" concept. Alation captures "decision trace" as the implicit chain of SQL queries, transformations, and lookups that together implement a business decision (e.g., "determine customer credit risk"). The trace reconstructs decision logic from data pipeline evidence. Structural difference from DLP: Alation's decision trace is retrospective (reconstructed from pipeline evidence after the fact). DLP captures decision context prospectively (authority, constraint, alternatives, expected outcomes recorded at decision-making time). Alation answers "what sequence of operations led to this output?" DLP answers "why was this decision made, by whom, under what constraints?" These are complementary — a retrospective trace of operations paired with prospective decision context would provide full auditability. But Alation does not capture or enforce the governance context that DLP provides.

Convergence with DLP: Both Collibra and Alation represent sophisticated deployments of the data lineage paradigm within enterprises. Neither crosses into decision provenance infrastructure because neither constrains authority, enforces constraint context at decision time, or manages the escalation of governance questions from technical lineage to organizational accountability. DLP's differentiation is architectural — the protocol level (not tool level) that makes governance context structural.