Linked Platform Repositories
Why some readiness signals come from other repos, and what to do when a scan needs them.
Why scores sometimes depend on other repos
The platform scores each connected repository on its Agentic Foundation rubric. Some dimensions are naturally about this repo: agent instructions, tests, CI config, README. But a few delivery and platform signals usually live somewhere else:
| Signal | Normally lives in |
|---|---|
| Terraform (H5–H7: IaC, remote state, plan in CI) | A terraform repository |
| Kubernetes manifests and GitOps (H3–H4) | A gitops repository |
| Shared CI templates (B3–B6, H2) | A CI templates repository |
| API contracts owned centrally (F) | An API contracts repository |
If your organization keeps infrastructure and pipelines in dedicated repos (common for Terraform, GitOps, and shared CI), those repos are scanned separately. The service repo’s scan accounts for their signals through linked platform repositories, not by copying delivery files into every app repo.
How linked scans work
There is no giant combined download. The platform treats each repo type on its own:
- Platform repositories (terraform, gitops, CI templates, API contracts) are scanned as first-class subjects. Each one gets a readiness score using the criteria that apply to it; the rest are marked Not applicable rather than penalized. A terraform repo is not dinged for missing a Dockerfile or unit tests.
- After a platform scan, the platform records what it found for each service it references (for example, the gitops repo notes which Argo applications or Helm releases map to which service repos).
- When a service repo is scanned, the platform pulls in those linked signals and combines them with the repo’s own signals before grading. So
payments-apican earn credit for infrastructure managed inplatform-gitopswithout hosting any YAML itself.
Only repositories you have connected to the workspace are used as candidates. Unrelated repositories are simply not referenced.
What an “incomplete assessment” means
A service repo sometimes shows an incomplete assessment on Delivery, Platform Governance, Repo Hygiene, or API Contracts. That is on purpose. It means a linked platform repo needs to be scanned before the service repo can be fairly graded.
The list/detail view shows which repos are missing. Each entry is one of:
| Status | Meaning | What to do |
|---|---|---|
| Needs scan | The linked repo has never been analyzed. | Run a scan on that repo, then re-scan this one. |
| Scanned, no linkage found | The repo was scanned, but no matching signals were found yet. | This often means an old scan or a repo whose archetype wasn’t recognized. Re-scan the platform repo. |
| Stale | The linked signals are older than the freshness window. | Re-scan the platform repo to refresh them. |
How to fix it: open GitHub, run Analyze on the linked platform repo first, then run Analyze again on the service repo. Missing linked evidence is never scored as a code gap: the platform blocks a definitive rating until the prerequisite scan exists, so you are not punished for keeping infrastructure in its own repository.
Platform repositories score differently
A repository detected as a platform repo (for example, a dedicated terraform repo) gets a Platform repository badge. Its headline score reflects IaC and platform practices, not application readiness, and it is scored only on the criteria that apply to it. You should not compare its percentage directly against an application service’s percentage.
Not applicable vs gap
The rubric distinguishes three states you will see:
- Not applicable (N/A): the criterion legitimately does not apply to this kind of repository (no Dockerfile for a docs repo, no Terraform for a store-only mobile app).
- Gap: the criterion applies and the evidence is missing from the analyzed tree.
- Blocked / incomplete: the criterion’s evidence normally lives in an external location that has not been scanned yet.
Keeping Terraform and GitOps in their own repos is a common, healthy layout. When the linked signals exist, they are recognized. When they do not, the platform tells you exactly which repo to scan rather than guessing.
Delivery models
Under Workspace settings → Agentic Foundation → Linked platform repositories, Delivery model describes how your organization typically ships software. It helps the platform interpret split infrastructure and which linked roles (Terraform, GitOps, CI templates, API contracts) you are likely to need. Prefer Auto unless you know your dominant pattern.
| Delivery model | When to choose it |
|---|---|
| Auto | Default. The platform infers shape from each repo’s scan signals. Use this when teams ship in more than one style. |
| Kubernetes microservices | Services deploy to Kubernetes (Helm, Kustomize, Argo CD, or Flux). GitOps and often Terraform usually live outside the app repo. |
| Mobile store | Primary delivery is App Store / Play Store release pipelines, not container/GitOps deploy of the same repo. |
| Web hosting | Static or app hosting (CDN, PaaS, managed web hosts) rather than cluster GitOps. |
| Data pipelines | Batch or streaming data jobs are the main ship path; infra may live in a data platform or shared Terraform repo. |
| Monorepo | Many services and delivery files share one repository. Linked platform roles are often unnecessary for in-tree delivery. |
| Library | The repo is a shared library or SDK, not a deployable service. Delivery criteria may not apply the same way. |
| Hybrid | No single pattern dominates (for example, some K8s services and some hosted web apps). Use per-repo overrides when a service differs from the workspace default. |
CI provider on the same settings card names where shared pipelines live (GitHub Actions, Jenkins, GitLab, Bitbucket, hybrid, or external CI that you document elsewhere). Choose External (documented) when CI is outside those systems but still described for the workspace.
You can override the delivery model or role mappings for individual service repos under per-repo overrides on the same card.