The Data Usage and Processing Lineage Ontology connects what processing was intended, what processing occurred, and which conclusions about the resulting data are supported by evidence. It enables downstream data classifications to be traced through concrete processing lineage to the classifications and evidence on which they depend.

This ontology reuses DPV for processing and measure categories, PROV-O for execution history, and the Inferal Data Classification Ontology for classification records. It adds the terms needed to relate abstract contracts, actual data use and transformation, classification effects, lineage coverage, and evidence-backed assessments without treating any one of those as proof of another.

This is an unofficial 0.1 Editor's Draft maintained in the Inferal ontology repository. Public terms are drafts until release, but their IRIs are designed for stable publication under the Inferal ontology namespace.

Feedback should be sent to contact@inferal.com.

Introduction

This specification uses the key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY as described by BCP 14 when, and only when, they appear in all capitals.

A data graph conforms to the base vocabulary when it uses these terms according to their RDFS semantics and the normative requirements in this document. A graph conforms to the operational profile when it also validates against the applicable SHACL shapes with RDFS inference and the imported ontology context. SHACL conformance does not prove that a processing claim is true; it proves only that the represented claim is structurally consistent with the profile.

Namespace

Namespace

https://ontology.inferal.com/modules/data-usage-processing-lineage/

Preferred prefix

duplo

The module uses a descriptive namespace rather than a prefix-derived namespace. The compact duplo: prefix is only an authoring convenience; published term IRIs continue to explain their subject even when viewed without prefix declarations.

Scope

This ontology is in scope for:

• abstract processing specifications and deployable processing plans;
• category-level processing policies;
• actual PROV activities, usage, generation, association, and derivation;
• immutable data snapshots and versioned data elements;
• direct and indirect element dependencies;
• expected and observed classification impacts;
• classification propagation activities;
• qualified mitigation requirements and assessments;
• lineage completeness statements; and
• operational tracing, review, policy comparison, and conservative materialization.

This ontology is not intended to:

• replace the DPV processing or personal-data taxonomies;
• describe executable source code or algorithm internals completely;
• assert legal compliance merely because a graph validates;
• treat an expected plan outcome as an observed fact;
• prove anonymisation from an activity label; or
• embed secrets, keys, salts, credentials, or reversible parameters in provenance.

Competency questions

The vocabulary and its reference operational behavior are designed to answer:

1. Which source entities and elements directly contributed values to an output?
2. Which elements indirectly influenced an output through joins, filters, groups, sorts, windows, or conditions?
3. Which upstream classifications are reachable from a downstream classification?
4. Is an apparent lineage root a complete source or merely the oldest known node?
5. Which processing specifications can accept a concretely classified data element?
6. Which plan and port roles governed a particular activity?
7. Does an execution have every input and output binding expected by its specification?
8. What classification change did a specification expect?
9. What classification change was observed for a concrete execution?
10. Which expected or observed impacts still require review?
11. Which processing activities violate a category-level policy in the same context?
12. Which mitigation was required, which measure was applied, and was that application assessed as sufficient?
13. Which runs have partial, unknown, or unstated lineage, and independently which are positively source-free with respect to data inputs?
14. Can a downstream candidate classification be materialized without prematurely confirming it?
15. Can a compact mitigation hook be expanded into a qualified, traceable requirement?

Design principles and decisions

Reuse and non-reuse decisions

PROV-O

Imported for entities, activities, plans, roles, usage, generation, derivation, qualified influences, associations, agents, time, and version-aware provenance [[PROVO]]. This ontology does not redefine those relations.

DPV

Imported for data, processing, sensitivity, and technical or organisational measure categories [[DPV]]. Its properties reference DPV processing categories instead of creating a parallel taxonomy.

Inferal Data Classification

Imported for addressable data elements, classification records, workflow status, sensitivity, context, and compact policy hooks.

Inferal Confidence

Imported for optional scale-aware confidence assessments on assessment conclusions.

P-Plan

Not imported. P-Plan demonstrates a useful plan/step/variable to execution correspondence pattern [[PPLAN]], but its scientific workflow scope and published non-commercial share-alike license make a small PROV-aligned local vocabulary preferable. A separate published mapping records directional compatible terms, confidence, and loss without claiming equivalence.

OpenLineage

Not imported as an ontology. Its direct and indirect column lineage distinction informed the element-lineage relations [[OPENLINEAGE]]. A separate published mapping records how OpenLineage facets can be projected into this vocabulary and where information is lost.

Reuse metadata records the source, license, retrieval date, and reason for each imported ontology.

Authorization is modeled here as a policy concern rather than a service capability. When a classification triggers a processing policy, that policy can carry reified DPV permissions binding a data target, a processing operation, an active role or entity, and a purpose or context. This keeps authorization distinct from Data Access, which describes provider capability, and from Authentication, which describes credential presentation. A permission supplements a data element's contextual sensitivity; it does not replace it.

The operational profile validates every reified permission linked by dpv:hasPermission. It MUST be an IRI typed dpv:Permission, identify data, processing, and an active entity or role, and identify at least one IRI purpose or context. The profile permits multiple values for each facet so that a permission can express a complete scope without reducing it to a single statement.

Abstract processing contracts

Runtime provenance and lineage

Classification impacts and propagation

Mitigation requirements, application, and assessment

This ontology separates normative requirements from historical application and evidential satisfaction. This prevents a required measure from being mistaken for a performed measure and prevents a performed measure from being mistaken for a successful control.

1. dcls:requiresMeasure is a compact class-valued policy hook.
2. A duplo:MitigationRequirement qualifies measure, origin, scope, and context.
3. duplo:appliedMeasure records what an actual activity claims it applied.
4. A duplo:MitigationAssessment evaluates a particular requirement against evidence.

A requirement MUST identify at least one DPV technical or organisational measure category and exactly one scope. It MUST originate from a classification or be declared by a specification. An assessment MUST identify exactly one requirement, processing activity, and assessed measure, plus an outcome, a rationale, and its generating activity. The assessed measure MUST be required by that requirement and recorded as applied by that activity. Every stated requirement context MUST match the activity's processing context.

Assessments and conformance

A duplo:ProcessingAssessment is a provenance entity generated by a validation, review, or other assessment activity. It MUST assess a named resource, have exactly one outcome, give a rationale, and identify exactly one generating activity. It MAY reference a structured confidence assessment.

duplo:ConformanceOutcome and duplo:MitigationOutcome are extensible specializations of duplo:AssessmentOutcome. Conformance assessments MUST use the former; mitigation assessments MUST use the latter. duplo:Indeterminate belongs to both families because insufficient evidence can prevent either conclusion.

A duplo:ProcessingConformanceAssessment assesses exactly one processing activity against exactly one specification. A conformant conclusion MUST cite evidence using prov:used. Claiming duplo:realizesSpecification does not itself entail conformance.

Core controlled outcomes are:

• duplo:Conformant and duplo:NonConformant are conformance outcomes.
• duplo:Satisfied and duplo:Unsatisfied are mitigation outcomes.
• duplo:Indeterminate is valid for both outcome families.

Lineage coverage and stated uncertainty

duplo:hasLineageCoverage intentionally has no RDFS domain so it can describe activities, entities, element versions, bundles, or locally scoped lineage resources without retyping them. The operational profile requires one value on each processing activity.

Every activity MUST also identify exactly one duplo:lineageCoverageScope value from duplo:LineageScope. duplo:ElementDependencyLineageScope covers every represented direct value dependency and indirect join, filter, grouping, ordering, windowing, or conditional dependency within the evaluated execution boundary. Local scope resources MAY name narrower asset, graph, time-window, system, or organisational boundaries.

duplo:CompleteLineage

All dependencies within an explicitly declared scope are represented.

duplo:PartialLineage

Some known dependencies are represented, but more can be absent.

duplo:UnknownLineage

The dependency structure or completeness is not known.

Partial, unknown, or unstated coverage anywhere on a recorded lineage chain prevents a consumer from presenting the oldest known node as a certain original source. Reference tracing behavior therefore aggregates coverage across every recorded generating activity reachable from the output and exposes the underlying activity-level assertions beside the conservative aggregate.

A non-root intermediate element without a recorded generating activity is an unknown coverage boundary, not evidence of completeness. Complete trace results additionally require the built-in direct-and-indirect element scope on every evaluated generating activity.

Evidence-bearing compatibility, coverage, and validation

Exact context IRI identity is the default safety rule. Unequal contexts can be related only through a directional duplo:ContextCompatibilityAssessment. The assessment identifies one duplo:sourceContext, one duplo:targetContext, and every evaluated duplo:assessesContextFacet. A target specification, policy, requirement, activity, or profile uses duplo:requiresContextFacet to name the dimensions which MUST be covered. If no required facets are declared, an unequal-context assessment does not relax exact identity in the reference operational behavior.

duplo:ContextFacet values include duplo:JurisdictionContextFacet, duplo:PurposeContextFacet, duplo:ControllerContextFacet, duplo:LegalBasisContextFacet, and duplo:SystemContextFacet. The duplo:ContextCompatibilityOutcome family contains duplo:Compatible, duplo:Incompatible, and duplo:Indeterminate. Compatibility is directional, scoped to the named facets, and MUST NOT be represented with owl:sameAs.

A lineage summary is backed by a duplo:LineageCoverageAssessment connected through duplo:hasLineageCoverageAssessment. The assessment records duplo:assessedLineageCoverage, one or more duplo:assessedLineageScope values, and at least one concrete duplo:coverageBoundary. Time-bounded assessments MAY use duplo:coverageStartTime and duplo:coverageEndTime.

The built-in scope dimensions are duplo:AssetLineageScope, duplo:ElementLineageScope, duplo:DirectDependencyScope, duplo:IndirectDependencyScope, duplo:ExecutionBoundaryScope, and duplo:CrossSystemBoundaryScope. duplo:ElementDependencyLineageScope provides a combined compatibility summary. A direct duplo:hasLineageCoverage value and duplo:lineageCoverageScope MUST match the linked assessment under the operational profile.

Structural validation is represented by a duplo:StructuralConformanceAssessment. It names the duplo:validatedResource, duplo:validationShape, versioned duplo:validationShapesGraph, optional duplo:validationContext, and authoritative duplo:validationReport. The report uses standard sh:ValidationReport and sh:conforms; this ontology does not copy SHACL result semantics. A structural assessment can close a contract gap only when the resource, shape, shapes graph, report outcome, provenance, and required context facets match.

Operational behavior can be registered as duplo:OperationalRule resources with a duplo:RuleKind, duplo:hasRuleKind, duplo:ruleImplementation, duplo:ruleFailureBehavior, and duplo:ruleIsMonotonic. The kinds are duplo:NormativeSafetyRule, duplo:ReferenceInferenceRule, and duplo:DiagnosticRule. Registration makes scope and failure behavior explicit; it does not claim complete semantics for every future impact kind, mitigation scope, or context policy.

Reference operational behavior

Reference operationalizations support upstream classification tracing, category-contract selection, execution-conformance review, lineage and impact gap detection, mitigation review, indirect-influence discovery, and processing-policy comparison. Materialization behavior is limited to conservative candidate classifications and qualified mitigation requirements; it does not silently confirm a classification or a mitigation outcome.

Candidate propagation checks performed-versus-declared processing, explicitly scoped complete lineage, every source binding of an n-ary impact, source category, classification status, sensitivity, contract ownership, and exact source/specification/activity context. It retains context on the candidate and deliberately excludes sensitivity, requirement, suppression, and unknown impacts from category materialization. Structural SHACL contracts are not evaluated inside SPARQL and remain a separate conformance concern. Reference materialization uses SHA-256 over complete identity tuples so repeated execution is idempotent and equal local names from different namespaces cannot collide. Candidate identity uses output element, processing activity, impact, and context; all source classifications remain explicit provenance without making identity depend on SPARQL row order. Requirement identity uses classification, measure, scope, and context.

Validation profile

The operational SHACL profile enforces at least the following:

• Specifications declare processing and at least one port.
• Plans identify an implemented specification.
• Policies identify an applicable category and normative processing statement.
• Activities identify performed processing, provenance input or output, and exactly one coverage value.
• Activities identify exactly one explicit lineage coverage scope.
• Transformations both use and generate entities and never use and generate the same fixed-aspect entity.
• Source-free activities have no data-port binding; every used dependency is explicitly qualified through an auxiliary port.
• Source-dependent activities bind at least one used entity through a data input port.
• Ports belong to exactly one specification.
• Expected-impact ports and runtime bindings belong to the contract being evaluated.
• Constraints constrain at least one semantic or structural dimension.
• Element versions identify exactly one source asset.
• Qualified direct and indirect influences identify an input element.
• Impacts have one kind and an explicit review marker.
• Sensitivity escalation and requirement introduction have structured result operands.
• Suppression and unknown impacts require review.
• Observed impacts cite a classification and generating activity.
• Assessments cite target, outcome, rationale, and generating activity, using the correct outcome family.
• Conformant assessments cite evidence.
• Required, applied, and assessed measures use DPV measure categories.
• A mitigation assessment evaluates a measure both required by its requirement and applied by its activity, in matching context.
• Specification, policy, activity, and requirement context properties are single-valued bundled contexts.

SHACL evaluates represented graph completeness under a chosen data graph; it does not override RDF's open-world semantics outside validation. Implementations SHOULD preserve the validation report as provenance when its conclusion drives policy or classification decisions [[SHACL]].

Security and privacy considerations

A lineage graph can be sensitive even when it contains no payload values. It can reveal the existence of personal-data fields, join paths, processing destinations, data-controller relationships, security mechanisms, and the possibility of identity linkage. Implementations SHOULD classify, authorize, minimize, and retain provenance data under controls appropriate to its contents.

measureImplementation identifies a versioned algorithm, configuration, service, or control entity. It MUST NOT embed secret keys, salts, credentials, tokens, or reversible parameters. A reference MAY point to a protected configuration record whose existence is visible but whose secret content is access-controlled elsewhere.

Classification propagation can amplify errors. A confirmed source classification does not guarantee a confirmed output when lineage is partial, context changes, the plan is unverified, or the processing is non-deterministic. Consumers SHOULD retain source status, context, evidence, and coverage in explanations.

Governance, versioning, and extension

Public IRIs in this ontology MUST NOT be repurposed after adoption. Semantic changes to impact kinds, coverage claims, policy modality, or class boundaries require versioning and migration notes. Local processing categories SHOULD extend or map to DPV categories rather than redefine imported terms.

Domain-specific extensions MAY specialize ports, specifications, activities, impacts, requirements, and assessments. An extension SHOULD use mappings weaker than OWL equivalence unless meanings are genuinely complete in both directions. Profiles MAY add closed enumerations, cardinalities, sensitivity orderings, or alternative category groups appropriate to a deployment.

Automated classifiers and pipeline extractors SHOULD record the agent, activity, plan version, timestamp, confidence, and known coverage that support their output. Disagreement among assessments SHOULD remain explicit rather than being silently overwritten.

Term reference

Worked modeling patterns

The examples throughout this specification illustrate both successful and non-conforming assessments without treating a negative assessment as a structurally invalid graph. Together they cover:

• abstract category contracts and concrete plan versions;
• qualified usage, generation, association, and port bindings;
• email-to-HMAC pseudonymisation;
• identity copy and category preservation;
• encryption as protection without declassification;
• aggregation with an uncertain candidate result;
• joins with indirect sensitive influence;
• element elision and positive absence;
• source-free random generation;
• in-place logical updates as entity versions;
• stateful stream windows;
• partial lineage at an organizational boundary;
• category-level processing policy; and
• explicit non-conformance caused by candidate input status.