Tracking How Work Travels Across Organisational Systems

Research Question

Can we track how a unit of 'Work' -- an idea or concept -- travels across organisational systems (SharePoint, Confluence, Azure DevOps (ADO)/Jira, Git, monitoring systems, and data platforms), and what mechanisms or patterns exist to trace its full lifecycle from inception to delivery and beyond?

Findings

Executive Summary

• [inference] End-to-end tracking of organisational work is achievable, but only by building a graph of work artefacts and typed evidence links (a provenance graph) that stitches together local identifiers, web links, and event records from multiple systems rather than by discovering a single native identifier that already follows the work everywhere. Sources: SharePoint document-library items as `driveItem` / `listItem` resources with stable identifiers Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links GitHub deployment and deployment status events for release-stage traceability PagerDuty change events and incident change-correlation model for monitoring-stage linkage current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events
• [inference] The strongest native traceability today sits in the issue-to-code-to-build or deployment path, where GitHub, Azure Boards, and Jira all provide explicit mechanisms for linking work items, branches, commits, pull requests, and builds. Sources: GitHub issue and pull request linking Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links current Jira Smart Commits documentation (replaces the original listed web link, which now returns 404)
• [fact] SharePoint, Confluence, monitoring systems, and data platforms can all contribute important lifecycle evidence, but they do so through weaker document links, service correlations, or specialised standards such as OpenLineage rather than through one shared work-tracking schema. Sources: SharePoint document-library items as `driveItem` / `listItem` resources with stable identifiers Confluence Smart Links for Jira and Atlassian project links PagerDuty change events and incident change-correlation model for monitoring-stage linkage current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events
• [inference] The best minimum viable approach is to choose the issue layer as the canonical work key, ingest every deterministic native link the tools already expose, and then attach provenance plus confidence to any correlation-based or inferred joins that extend the lifecycle into documents, incidents, and data jobs. Sources: Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links current Jira Smart Commits documentation (replaces the original listed web link, which now returns 404) PagerDuty change events and incident change-correlation model for monitoring-stage linkage current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events

Key Findings

1. [fact][high confidence] Azure Boards, Jira Software, and GitHub all support explicit issue-to-code linkage, but they rely on product-specific identifiers and text conventions such as AB#123, Jira issue keys, and pull request closing keywords instead of one shared cross-system work identifier. Sources: Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links current Jira Smart Commits documentation (replaces the original listed web link, which now returns 404) GitHub issue and pull request linking
2. [fact][high confidence] SharePoint and Confluence expose stable, addressable artefacts that can anchor provenance, but their public documentation positions them primarily as content surfaces and link renderers rather than as authoritative registries for the lifecycle of engineering work. Sources: SharePoint document-library items as `driveItem` / `listItem` resources with stable identifiers Confluence Smart Links for Jira and Atlassian project links
3. [inference][high confidence] Deployment-stage traceability becomes materially stronger when deployments are modelled as first-class records, because GitHub deployment objects tie an environment and status history to a specific ref while Azure Boards can return build evidence to the originating work item. Sources: GitHub deployment and deployment status events for release-stage traceability Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links
4. [inference][medium confidence] Monitoring-stage linkage is usually correlation-based rather than strictly deterministic, because PagerDuty connects incidents to recent changes by time, related service, and machine-learning similarity instead of requiring every incident to carry the original issue or deployment identifier. Sources: PagerDuty change events and incident change-correlation model for monitoring-stage linkage
5. [fact][high confidence] OpenLineage provides a mature provenance model for the data-platform segment through Jobs, Runs, Datasets, and extensible facets, but its native entity set stops short of documents, pull requests, deployments, and incidents. Sources: current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events current OpenLineage facets guide; standard and custom metadata extension points
6. [fact][medium confidence] Commercial products such as LinearB and the older Sleuth positioning create value mainly by standardising existing keys and correlating signals across systems, which means their effectiveness still depends on disciplined issue references, deployment records, and service-mapping data upstream. Sources: LinearB documentation on matching Jira issue keys to branches, PRs, commits, and incidents Sleuth article on DevOps Research and Assessment (DORA) metrics, including deployment frequency, change lead time, change failure rate, and mean time to recovery (MTTR) PagerDuty change events and incident change-correlation model for monitoring-stage linkage
7. [inference][high confidence] The most defensible organisation-wide architecture is a provenance graph with typed nodes and edges, because each platform owns only one segment of the lifecycle and no reviewed standard already spans document intent, tracked work, code change, release, incident, and data lineage together. Sources: SharePoint document-library items as `driveItem` / `listItem` resources with stable identifiers GitHub deployment and deployment status events for release-stage traceability current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events
8. [inference][high confidence] A minimum viable implementation should start at the issue layer as the canonical work key, capture deterministic joins first, and treat semantic matching or correlation as a secondary repair strategy for missing document-origin, incident, or downstream data-job links. Sources: Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links current Jira Smart Commits documentation (replaces the original listed web link, which now returns 404) PagerDuty change events and incident change-correlation model for monitoring-stage linkage current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events

Assumptions

• [assumption] The issue or work-item layer is the best canonical key for most organisations. Justification: the strongest reviewed native joins cluster around Azure Boards and Jira issue identifiers. Sources: Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links current Jira Smart Commits documentation (replaces the original listed web link, which now returns 404)
• [assumption] Documents should be modelled as contextual provenance nodes even when they are not authoritative identifiers. Justification: SharePoint and Confluence both expose stable, linkable artefacts that can preserve origin and decision context. Sources: SharePoint document-library items as `driveItem` / `listItem` resources with stable identifiers Confluence Smart Links for Jira and Atlassian project links
• [assumption] Semantic inference should be reserved for explicit-link gaps rather than used as the default join strategy. Justification: deterministic identifiers and event objects exist across much of the lifecycle, while confidence drops noticeably at the correlation layer. Sources: GitHub deployment and deployment status events for release-stage traceability PagerDuty change events and incident change-correlation model for monitoring-stage linkage current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events

Analysis

• [fact] The evidence supports a layered traceability model: deterministic reference links at the issue and code layer, first-class event objects at the deployment and data layer, and weaker explicit-link or correlation logic at the document and incident layer. Sources: Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links GitHub deployment and deployment status events for release-stage traceability PagerDuty change events and incident change-correlation model for monitoring-stage linkage current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events
• [inference] This layered model explains why organisations can usually answer "which ticket drove this pull request?" more confidently than "which document started this work?" or "which deployment caused this incident?" because the latter questions rely on looser metadata or probabilistic correlation. Sources: SharePoint document-library items as `driveItem` / `listItem` resources with stable identifiers Confluence Smart Links for Jira and Atlassian project links PagerDuty change events and incident change-correlation model for monitoring-stage linkage
• [inference] OpenLineage's success inside data platforms suggests that broader work provenance should also be event-centric and extensible, but the broader problem needs a super-graph because the lifecycle crosses entity types that were never designed to share one canonical schema. Sources: current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events current OpenLineage facets guide; standard and custom metadata extension points
• [inference] The minimum viable design choice is therefore organisational rather than purely technical: choose a canonical issue key, enforce identifier hygiene, emit deployments and change events, and preserve edge provenance so that downstream graphs expose certainty and ambiguity separately. Sources: Azure Boards to GitHub linking with `AB#` references, branch links, and integrated build links GitHub deployment and deployment status events for release-stage traceability PagerDuty change events and incident change-correlation model for monitoring-stage linkage

Risks, Gaps, and Uncertainties

• [fact] The reviewed public sources do not define one vendor-neutral standard that covers documents, tracked work, code changes, deployments, incidents, and data lineage together. Sources: current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events SharePoint document-library items as `driveItem` / `listItem` resources with stable identifiers PagerDuty change events and incident change-correlation model for monitoring-stage linkage
• [fact] Several originally listed sources had drifted or moved, which means product-level evidence in this domain can become stale quickly and must be revalidated before implementation decisions. Sources: current Jira Smart Commits documentation (replaces the original listed web link, which now returns 404) learn.microsoft.com checked because it was in the original item; the site now markets agent-governance products rather than the older DORA-tracing positioning
• [inference] The real operational risk is false confidence: a graph that hides whether an edge is declared, correlated, or inferred will look more precise than the evidence actually warrants. Sources: PagerDuty change events and incident change-correlation model for monitoring-stage linkage current OpenLineage facets guide; standard and custom metadata extension points
• [inference] Organisations with inconsistent branch naming, missing issue keys, or absent deployment or change-event instrumentation will only recover a partial lifecycle regardless of how good the graph technology is. Sources: current Jira Smart Commits documentation (replaces the original listed web link, which now returns 404) GitHub deployment and deployment status events for release-stage traceability PagerDuty change events and incident change-correlation model for monitoring-stage linkage

Open Questions

• [inference] What is the smallest metadata contract that would let SharePoint and Confluence pages declare themselves as the origin or justification of a specific work item without forcing a new authoring workflow?
• [inference] Which public monitoring and observability APIs provide the cleanest deterministic deployment-to-incident joins beyond PagerDuty's correlation model?
• [inference] What graph query patterns are most useful for users once the lifecycle graph exists: origin tracing, blast-radius analysis, compliance evidence, or onboarding explanations?

sources

• [x] OpenLineage overview; confirms the project is an open framework for data lineage collection and analysis
• [x] current OpenLineage object model; jobs, runs, datasets, and design-time/runtime events
• [x] current OpenLineage facets guide; standard and custom metadata extension points
• [x] GitHub issue and pull request linking
• [x] Azure Boards to GitHub linking with AB# references, branch links, and integrated build links
• [x] current Jira Smart Commits documentation (replaces the original listed web link, which now returns 404)
• [x] Confluence Smart Links for Jira and Atlassian project links
• [x] SharePoint document-library items as driveItem / listItem resources with stable identifiers
• [x] GitHub deployment and deployment status events for release-stage traceability
• [x] PagerDuty change events and incident change-correlation model for monitoring-stage linkage
• [x] LinearB documentation on matching Jira issue keys to branches, PRs, commits, and incidents
• [x] Sleuth article on DevOps Research and Assessment (DORA) metrics, including deployment frequency, change lead time, change failure rate, and mean time to recovery (MTTR)
• [x] checked because it was in the original item; the site now markets agent-governance products rather than the older DORA-tracing positioning
• [x] American Society for Quality overview of Value Stream Mapping (VSM) as a lean flow-mapping method
• [x] Prior completed research: Research/completed/2026-03-21-dependency-mapping-dotnet-terraform-dynatrace.md
• [x] Prior completed research: Research/completed/2026-03-15-latent-concept-extraction-confluence.md
• [x] Prior completed research: Research/completed/2026-03-08-servicenow-process-mapping.md
• [x] Prior completed research: Research/completed/2026-03-03-knowledge-linking-connected-corpus.md