How Vörr Cloud Mapping Connects Infrastructure, Services, and Repositories into One Debugging Context

Your production service has one name in AWS, another in Prometheus, another in Jenkins, and a fourth in GitHub.

During an incident, someone has to prove they're all the same thing.

That join usually happens inside an engineer's head - from memory, while jumping between dashboards, repositories, and cloud consoles.

Vörr Cloud Mapping does that work before the investigation starts. It scans the connected cloud account, discovers resources and relationships, then adds engineering context such as workspace, environment, purpose, repositories, and deployment paths.

The result is not just a cloud inventory. It is a map of what runs where, what it belongs to, and how the surrounding engineering systems connect.

1. Cloud Mapping

Cloud inventory tells you what resources exist. It does not necessarily give you the engineering-level relationship between those resources, services, repositories, and product flows.

Vörr starts by scanning the connected cloud account and discovering the resources and relationships already present there.

Load Balancer -> ECS Service -> RDS
                    |
                    v
                 SQS Queue -> Worker

That gives Vörr the infrastructure layer. It then adds engineering context around those resources:

workspace     checkout
environment   production
purpose       checkout API
repository    checkout-service
deployment    checkout-prod

Some context comes directly from cloud metadata. Other mappings come from tags, deployment targets, container images, repositories, or other evidence.

2. Identity Drift + Entity Resolution

The same mapped service can appear completely differently depending on where you look.

AWS          user-svc-prod
Prometheus   service="user-service-development"
Jenkins      vorr-dev/user-service-dev #32
GitHub       frigga-cloud/user-service-2

Exact matching fails because the names are different. Fuzzy matching is dangerous because a similar name is not proof that two things are the same.

Vörr therefore keeps the resolution method and diagnostics with the result. A simplified record can look like:

entity:      user-service
matchedBy:   exact

diagnostics:
  attemptCount: 1
  resolutionPath:
    - exact:user-service
  exhausted: false

Field	Meaning
`matchedBy`	The signal used to resolve the entity.
`resolutionPath`	The candidate path Vörr followed while resolving it.
`attemptCount`	How many candidates were tried.
`exhausted`	Whether all available candidates were exhausted without a stronger resolution.

The map does not just say what is connected. It keeps enough information to explain why Vörr believes the connection is valid.

3. Repository + Code Context

Cloud mapping explains where something runs. Repository and code context explains what software produced it and what the application depends on.

Cloud Mapper's native repository signals include:

direct repository matches
CI/CD deployment targets
container image matches
name matches when stronger evidence is unavailable

Code intelligence can add application-side dependency signals such as:

checkout-service
      |
      v
USER_SERVICE_URL
      |
      v
user-service

That distinction matters. Cloud Mapper connects runtime infrastructure to engineering ownership; code intelligence adds relationships the software itself declares. Vörr can bring both into the same debugging context.

4. Cloud Tags + Signal Precedence

The cloud side of the system already carries useful context:

fg:purpose       event-driven communication
ManagedBy        platform-team
org_id           ORG-001
cloudformation   stack/monitoring-baseline

But not every signal has equal authority. In Cloud Mapper, customer-provided tags are useful hints, while fg: tags are treated as authoritative mapping metadata.

Repository suggestions also have an evidence order: direct repository and CI/CD deployment matches are high-confidence signals, container-image matches are medium-confidence, and name matches are low-confidence fallbacks.

CONFLICT HANDLING
When signals disagree, the weaker signal should not silently overwrite the stronger one. Ambiguous cases remain reviewable rather than being flattened into one confident mapping.

5. Mapping Status

Infrastructure mapping is rarely just mapped or unmapped. One resource may be resolved automatically. Another may inherit context from a parent. A third may need a human review.

needs_mapping
      |
partially_mapped
      |
needs_review
      |
auto_resolved / inherited
      |
mapped

These are mapping states - not generic AI confidence levels. They describe where the resource sits in the mapping lifecycle and what still needs attention.

6. Confidence + Provenance

Mapping status, confidence, and provenance answer different questions:

Concept	Question it answers
Mapping status	Where does this resource sit in the mapping lifecycle?
Confidence	How strong is the evidence supporting the suggestion or relationship?
Provenance / evidence	Why does Vörr believe this mapping?

A suggested mapping may look like:

signal:      name_match
confidence:  low
evidence:    resource name matches repository name
verdict:     pending

The scan_derived signal can cover scan-based derivations and model-inferred context. It does not, by itself, prove an observation. Read the evidence, confidence and verdict together to distinguish observed facts from inferred context.

When an engineer confirms, changes, or dismisses a suggestion, that verdict becomes part of the mapping instead of forcing the same ambiguity to be solved again later.

7. Environment Context

A service called checkout in development and a service called checkout in production are not the same debugging target.

environment:  Dev
isProd:       false
via:          declared

The source matters too. A declared environment came from explicit configuration. A derived environment may come from cloud metadata, tags, or naming conventions.

website/production  #37   SUCCESS   production
website/dev         #70   SUCCESS   development
user-service/dev    #32   SUCCESS   development

Without that context, an investigation can correlate a production symptom with a development deployment and produce a perfectly coherent - but irrelevant - explanation.

8. One Debugging Context - With Known Gaps

Once these identities are connected, debugging stops being four separate searches.

Before

Cloud console -> resource
Prometheus -> metrics
Jenkins -> deployment
GitHub -> repository

Mapped context

user-service
  |- runs on -> ECS
  |- observed by -> Prometheus
  |- deployed by -> Jenkins
  |- built from -> GitHub repo
  '- depends on -> mapped services

The important part is that the map also shows where it ends. If Vörr cannot confidently connect a repository, resource, or service, that relationship can remain unresolved.

"There is no relationship."
is different from
"We have not established the relationship with enough evidence yet."

A debugging map does not need to pretend it knows everything. It needs to show what is known, why it is known, and where the gaps still are.

Explore Vörr Cloud Mapping

Build a system map that connects cloud resources to the engineering context around them.

Explore Vörr Cloud Mapping →