Source control, cloud infrastructure, and the conventions that hold them together. This page sets out how teams get access to our engineering platforms, the baseline every codebase must meet, and how we name things consistently across GitHub and three clouds, so an asset built by one team can be found, run, and maintained by another.
The Capgemini GitHub Enterprise Service (GHE) is the Group-approved home for source code. Every AI asset that produces code (a model pipeline, an agent, a UI, an evaluation harness) lives in a GHE repository, not in a personal account or an unmanaged tool.
Enterprise identity, audit logging, org-level policy enforcement, and continuity when people move roles or leave. Code tied to a personal account is a handover and compliance risk.
Repos sit under the relevant Capgemini GitHub organisation and are owned by a team, not an individual. Access follows the team, so leavers don't take repo access, or orphan it, with them.
Access is via Capgemini Microsoft Entra ID SSO with MFA. No local GitHub passwords, no unmanaged personal access tokens with broad scopes.
| Step | What to do | Owner |
|---|---|---|
| 1 | Confirm your engagement/project needs a GHE org, or that a suitable org already exists for your business unit or account. | Delivery lead |
| 2 | Raise an access request through the Group IT service request channel Draft: request tool & link to be confirmed, specifying the target org and requested team. | Requester |
| 3 | Request is approved by the GHE org owner or GitHub admin team and access is provisioned via Entra ID group membership. | GHE admin team |
| 4 | New repos are created under the org using the naming convention below, with the AI Design Authority template (README, LICENSE, CODEOWNERS, branch protection) applied from day one. | Repo creator |
| 5 | Repo conformity is checked against these standards: manually at review gates, or on demand via the GitHub admin conformity-check tool (below). | AI Design Authority |
These are the exact rules the GitHub admin conformity-check skill enforces today, one for one: rules.json in .claude/skills/github-conformity-check/ is the machine-checkable source of truth, and this table is its plain-English mirror. Update both together.
| Rule | Current draft value |
|---|---|
| Naming pattern | <country-code>-<application> (or global-<application>), all lowercase, hyphen-separated. See Repo naming convention below. |
| Required files | README.md, LICENSE, CODEOWNERS, .gitignore present at the repo root. |
| Branch protection | Default branch protected, pull request required, at least 1 approving review. |
| Visibility | Public visibility disallowed by default. |
This section is a working draft. The exact request tool, approver, and SLA for GHE onboarding need confirming, flagged with Draft above pending that input. The conformity rules above are equally provisional until the naming convention and required-files list are signed off.
These apply to every repository regardless of language, cloud, or team, on top of the Delivery & Quality domain in Standards, which governs the product built from the code.
| Standard | What it requires | Level |
|---|---|---|
| Repo naming | Follows the naming convention below. Checked at creation and audited afterwards. | Mandatory |
| Ownership | Owned by a GHE team, not an individual. A CODEOWNERS file names the accountable reviewers. | Mandatory |
| README | What the repo does, how to run it locally, how to deploy it, and who owns it, kept current, not written once and abandoned. | Mandatory |
| Licence & dependency hygiene | A LICENSE file, and third-party dependencies scanned for licence and vulnerability risk in CI. | Mandatory |
| Branch protection | Default branch protected: no direct pushes, pull request plus at least one review required, status checks must pass before merge. | Mandatory |
| Secrets management | No secrets, keys, or credentials committed to history. Secret scanning enabled; secrets are sourced from a managed vault or environment configuration, never hard-coded. | Mandatory |
| CI pipeline | Build, lint, test, and security scanning run automatically on every pull request. See the Delivery & Quality domain for the full test/security bar. | Mandatory |
| .gitignore hygiene | Build artefacts, local environment files (e.g. .env), and IDE clutter are excluded, not committed and later scrubbed. | Mandatory |
| Visibility | Internal to the Capgemini org by default. Public visibility is an explicit, approved exception, not a default. | Mandatory |
| Topics/tags | Tagged with the owning initiative (e.g. ai-design-authority) so repos in scope can be discovered and audited. | Recommended |
One predictable pattern so anyone can identify what a repo is and who it belongs to without opening it. This is a working draft. The pattern below is directionally right but not yet finalised.
<country-code>-<application>: all lowercase, hyphen-separated, no underscores or spaces.
uk, fr, in), or global for an asset not scoped to one country.| Example | Reads as |
|---|---|
uk-design-authority | UK-scoped, the "design-authority" application |
fr-claims-assistant | France-scoped claims assistant |
global-eval-harness | Not country-scoped, shared evaluation tooling |
Not yet final. This convention needs sign-off before it's enforced at scale. Check Engage Us or this page for the finalised version before relying on it for automation.
We run on three Group-approved clouds. Which one a given asset uses is a delivery decision, not a preference, driven by client landing zone, data residency, and the approved model/service catalogue for that cloud. The rules below apply regardless of which one is in play.
Default for most Capgemini-hosted AI assets. Provisioned into a named resource group inside an approved subscription; container workloads typically run on Azure Container Apps or AKS, pulling images from Azure Container Registry via managed identity rather than admin credentials.
Used where the client landing zone or an existing account estate is AWS-native. Same principles apply: named account/OU, infrastructure as code, least-privilege IAM roles rather than long-lived access keys.
Used for GCP-native clients and where Vertex AI is the approved model platform (see the GCP Vertex Guidelines). Same principles: a named project, IaC, workload identity federation rather than static service-account keys.
| Rule | What it requires | Level |
|---|---|---|
| Approved subscription/account only | Resources are provisioned inside a Group-approved subscription (Azure), account (AWS), or project (GCP), never a personal or trial account. | Mandatory |
| Infrastructure as code | Environments are defined in code (e.g. Bicep/ARM, Terraform) or a build tool (e.g. a Makefile driving the cloud CLI), not clicked together and undocumented. | Mandatory |
| Identity over static keys | Services authenticate to each other with managed identity (Azure), IAM roles (AWS), or workload identity federation (GCP), not long-lived keys or passwords in config. | Mandatory |
| Least privilege | Roles scoped to exactly what the workload needs (e.g. AcrPull, not Owner) at the narrowest resource scope that works. | Mandatory |
| Cost & tagging | Resources tagged with owning application and cost centre; consistent with the Cost & performance budget standard in Technical Architecture. | Recommended |
| Data residency | Region/location selection respects client data residency requirements before cost or latency preference. | Mandatory |
Same pattern as repos: <country-code>-<application>, all lowercase, hyphen-separated, applied to the cloud resource itself: an Azure Container App, an AWS service/stack name, a GCP project or service name.
Check the target service's own limits first. Each cloud service imposes its own constraints on top of the convention. For example, Azure Container App names must be under 32 characters, start with a letter, and cannot contain --. Where the convention and a service's limit collide, shorten the application segment; never break the pattern's lowercase/hyphen structure to fit.
Naming conventions and codebase standards only hold if someone checks them. A GitHub admin conformity-check tool is in early development. It audits repos against the naming pattern and required-files baseline above and reports where they drift. It's a first draft, wired up alongside this page, and will be finalised together with the conventions themselves.
Raise an advisory request before you provision. It's easier to start on-convention than to rename later.