Traceability: Jira → Code → Production
Every change in an SGD-governed organisation is traceable through a complete chain of six links. No manual assembly, no after-the-fact reconstruction — the chain is built as work happens.
The full traceability chain
What each link represents
| Link | Stored data | Created when |
|---|---|---|
| Jira Epic / ADO Item | External issue ID, title, assignee, priority | ALM connector syncs the issue into SGD |
| Feature Spec | Spec ID, version, affected capabilities, acceptance criteria, approval status | Author creates and approves the spec in the SGD registry |
| Pull Request | PR number, repo, author, spec reference, file changes, AI provenance metadata | Developer or AI agent opens a PR with a spec reference |
| Governance Check | Check run ID, pass/warn/fail result, individual rule results, timestamps | SGD runs governance checks on the PR automatically |
| Deployment | Environment, version, timestamp, deployment method | CI/CD pipeline reports the deployment to SGD |
| ROI Metric | Time-to-merge, rework rate, incident attribution, coherence delta | SGD calculates metrics from the chain data |
What this means in practice
When the regulator asks "show me the chain"
Imagine an FCA auditor asks: "Show me the governance chain for the change to your payment processing system on 14 March."
With SGD, the answer takes seconds, not days:
Link 1 — Jira Epic: "PAY-1234: Add Strong Customer Authentication to card payments." Business intent documented, approved by product owner, priority P1.
Link 2 — Feature Spec: "PAY-SCA-001 v2.1: Strong Customer Authentication." Spec defines affected repos (payment-gateway, card-processor, auth-service), acceptance criteria (3DS2 challenge flow, fallback handling, audit logging), and architectural decisions (ADR-047: use delegated authentication).
Link 3 — Pull Request: PR #892 on payment-gateway. Author: @developer (assisted by Claude Code). References Spec: PAY-SCA-001. Changes: 14 files, 847 additions, 203 deletions.
Link 4 — Governance Check: SGD governance passed. Spec traceability: verified. Design system compliance: 0 violations. Coherence check: consistent with card-processor PR #445.
Link 5 — Deployment: Deployed to production on 14 March 09:42 UTC via GitHub Actions pipeline deploy-payment-gateway.yml. Environment: production-eu-west-1. Version: v3.14.1.
Link 6 — ROI Metric: Time from spec approval to production: 6.2 days. First-time governance approval: yes. Post-deployment incidents in 7-day window: 0.
Every link is stored in the SGD audit trail. The auditor can walk through the chain in the dashboard, or you can export it as a PDF evidence pack.
No manual assembly required
In most organisations, answering an audit question like this requires pulling data from Jira, GitHub, CI/CD logs, deployment records, and incident trackers — then manually stitching them together. SGD records the chain as work happens, so the answer is always ready.
Chain completeness
Not every PR will have a complete chain from day one. SGD tracks traceability coverage — the percentage of merged PRs with all six links present.
| Chain status | What it means |
|---|---|
| Complete | All 6 links present. Full audit trail from business intent to measured outcome. |
| Partial — missing spec | PR merged without a spec reference. Common for bug fixes and dependency updates. |
| Partial — missing ALM link | Spec exists but is not linked to a Jira/ADO item. Governance chain starts at the spec. |
| Partial — missing deployment | PR merged but deployment not yet recorded. Chain completes when CI/CD reports the release. |
| Broken | Spec reference in PR does not match any known spec. Likely a typo or deleted spec. |
The goal is not 100% completeness on every PR — bug fixes and dependency updates genuinely may not need a spec. The goal is high completeness on feature work: PRs that implement capabilities should have the full chain.
How chains are linked
SGD builds the chain automatically using three mechanisms:
Spec references in PRs — The
Refs: SPEC-IDorSpec: SPEC-IDpattern in PR titles, descriptions, or commit messages links the PR to the spec. The spec links to the ALM item via its external issue field.Deployment events — CI/CD pipelines report deployments to the SGD API (or via GitHub Deployment events). SGD matches the deployment to the most recent merged PRs on the deployed branch.
Metric calculation — When a deployment is recorded, SGD automatically calculates the ROI metrics for all PRs in the deployment and attaches them to the chain.
No manual tagging, no post-hoc assembly. The chain builds itself from the metadata your team is already producing.