How It Works
SGD works in three phases: Connect your repositories, Govern your development process, and Prove the value. Each phase builds on the last.
1. Connect
Install the SGD GitHub App on your organisation, or connect your Jira / Azure DevOps instance. The platform immediately begins scanning.
Two entry points
Most teams start with GitHub repos — install the app, scan your estate, see health scores in minutes. If your workflow starts from Jira or ADO tickets, you can connect from there instead. Both paths converge on the same governance model.
What happens during Connect:
- Tech stack detection — The platform reads package files, lock files, Dockerfiles, IaC templates, and CI configs to identify languages, frameworks, cloud providers, and build toolchains across every repository.
- Health scoring — Each repo gets an initial health score (0-100) based on nine dimensions: compliance, pattern drift, CI/CD, documentation, infrastructure, observability, security, freshness, and AI-readiness.
- Capability model inference — Repositories are grouped into logical capabilities (e.g., "Payment Processing," "Customer Onboarding," "Risk Engine") based on naming patterns, dependencies, and code analysis. You review and adjust.
The result is a living map of your entire repository estate — what you have, what state it is in, and how it all connects.
2. Govern
Once connected, SGD provides three governance mechanisms that work together:
Feature Specifications
Every significant change starts with a specification. Specs define what should change, which repos are affected, what the acceptance criteria are, and which architectural decisions apply. When developers (or AI agents) open PRs, the platform checks them against the spec.
PR Governance Checks
Every pull request is automatically evaluated against:
- The relevant feature spec (does this PR do what the spec says?)
- Your design system rules (naming conventions, file structure, dependency constraints)
- Coherence with the rest of the capability (is this consistent with sibling repos?)
- Architectural Decision Records (does this violate any active ADRs?)
Checks appear as GitHub status checks — the same workflow your team already uses.
AI Agent Context
SGD generates and maintains CLAUDE.md files and MCP server configurations that give AI coding tools the context they need. When a developer opens Claude Code or Cursor in a governed repo, the AI agent automatically receives:
- The relevant feature spec
- Active ADRs and design constraints
- The capability model for cross-repo context
- Coherence rules that prevent drift
The AI tools still write the code. SGD makes sure they write the right code.
3. Prove
Governance without measurement is just another policy document nobody reads. SGD tracks everything:
Coherence Scores
Every capability gets a coherence score (0-100) that measures how consistently its repos follow the defined patterns. Scores trend over time, so you can show whether governance is working.
Full Traceability
Every change in the system is traceable through the full chain:
Jira ticket → Feature spec → Pull request → Governance check → Deployment
This is not reconstructed after the fact — it is recorded as work happens. When an auditor asks "why was this change made?", the answer is one click away.
ROI Metrics
The platform tracks the metrics that matter to leadership:
- Time to first PR — how quickly specs turn into code
- Rework rate — how often PRs fail governance checks (and the trend)
- Drift reduction — coherence improvement over time
- Compliance coverage — percentage of repos meeting your standards
Next steps
Connect from GitHub
Install the GitHub App and scan your repos in under 10 minutes.
Connect from Jira / ADO
Start from your issue tracker and let SGD map issues to repos.
The Six Governance Layers
Understand the full governance model from capability model to change protocol.
SGD & Your Framework
See how SGD maps to Scrum, Kanban, SAFe, and the Spotify model.