---
title: Estate Map & Portfolio Architecture
description: How the estate map shows a portfolio's business domains, dependencies, topology and company Scale readiness tier, and how to read, filter and adjust it
category: Portfolio Analytics
order: 5
---

# Estate Map & Portfolio Architecture

The estate map is CodeDD's portfolio-level view of architecture: it shows how the repositories of a group audit fit together as business domains, which depend on which, and what scale the whole estate is built for. It sits on the Architecture tab of a portfolio organization, below the company's Scale readiness tier.

The estate map answers three questions. Which scale are the systems built for? Does the codebase match the intended product topology? Where will integration or consolidation be expensive? It reports what the code and configuration show. Where CodeDD could not see something, it says so instead of drawing a conclusion.

For a single repository, see [Architecture Analysis & Mapping](/documentation/architecture-analysis-mapping).

## When does the estate map appear and what does it need?

The estate map appears on the Architecture tab of a portfolio organization once a group audit has analyzed its repositories. A group audit is created as described in [Setting Up a Portfolio Organization](/documentation/setting-up-a-portfolio-organization).

After every repository audit finishes, the group audit runs three estate stages in order: grouping repositories into business domains, working out the estate topology (roles and relationships), and writing the executive summary. A banner above the filters appears when a stage is pending, running, failed or out of date, for example because a repository was added or removed after it ran. It also names repositories on the map that take no part in the estate analysis, with the reason. If the banner says a stage failed, re-run the group audit to retry.

Until the stages complete, parts of the map may be missing. A group audit finalized before stage status was recorded shows no banner, which means "not recorded", not "all good".

Everything on the map is computed on the repositories in the group audit. Dependencies on repositories outside it cannot be seen, and an estate of a single repository has no relationships to draw.

## What are business domains in the estate map?

In the estate map, a business domain is a group of repositories that serve one capability of the business, such as orders, payments or identity. Each card on the map is a domain.

Domains are proposed by the analysis from what each repository does, so that "Orders", "Order Engine" and "Order Mgmt" become one domain. The estate map aims for a small, readable set of domains rather than one per repository. The wording of a domain's name and description is the AI's; which repositories belong to it can be corrected by an administrator.

Above domains, repositories that ship or run one product together can be proposed as a product. A product's basis is stated: every repository linked by detected runtime dependencies, some linked and the rest grouped by the AI, grouped by the AI from descriptions alone because no runtime dependency was detected, or added by an administrator. The last two are judgments, and detection may be incomplete.

When a domain's repositories have different primary roles, it is split into one card per role, so a domain can appear in more than one lane. Repositories not yet assigned to a domain are shown as Unclassified.

## What are the lanes of the estate map?

The lanes of the estate map are swim lanes, one per estate role. A repository sits in the lane of its primary estate role.

| Lane | What belongs there |
|------|--------------------|
| Edge / UI | Customer-facing surfaces and gateways |
| Core Business | Primary product and revenue systems |
| Shared / Platform | Reusable platform services |
| Data & Analytics | Warehouses, ETL, BI, ML |
| Integration Adapters | Connectors to third parties |
| Security & Compliance | Identity, secrets, audit, security tooling |
| Tooling / DevOps | CI/CD and internal tooling |
| Unclassified | Repositories without a classified estate role |

A repository without a classified role goes to the Unclassified lane, never into a classified one. Lanes that no card has as its primary role collapse into one "Not present" row. A repository that also serves a second role appears as a dashed chip on that lane's "Secondary role" card, so an empty lane by primary role does not read as "nothing does this".

The estate role is proposed by the analysis from what the repository is and does. Deterministic role signals are checked against it, and a repository whose signals disagree gets a "Review" badge. An administrator can set the role, and a curated role is kept.

## What does a repository card show?

A repository card, the row for one repository inside a domain card, shows the repository's name with a set of chips that state facts about it.

- **Code health.** The labelled figure on a domain card is a code health score weighted by lines of code, so one very large repository can dominate it. It measures code quality, not architecture.
- **Share of the estate's code.** A thin bar under the card header shows the domain's share of all lines of code, so a large system does not look like a small service.
- **Kind.** What the repository is: service, library, frontend, infrastructure as code and so on. An undecided kind reads "Kind not determined".
- **Tier.** A band showing the repository's Scale readiness tier, from T1 (the lightest) to T5 (the darkest), in one color ramp. The color encodes scale, not risk or quality. It is shown only when a tier exists. A repository whose kind has no running scale, or with not enough evidence, shows no tier, and its tooltip says why. A "+" after the tier (T2+) means at least that tier. A hatched band means the repository was analyzed before the requirement checks.
- **Topology role chips.** Producer, Consumer or Hub, shown only when a dependency relationship on the map backs them.
- **Hatched chip.** The scan found no usable dependency evidence for this repository, so some of its relationships may be missing.
- **Dark border.** The anchor: the repository the estate's directed dependencies converge on.

Click a repository to open a popover that says why it has its role, how far its role signals agree, and its review notes. From the popover you can open the repository's own architecture view, focus on its connections, or open its domain.

## How do I read the lines between domains?

The lines between domain cards are the relationships between their repositories. A line attaches to the repository row it concerns, and lines between the same two lanes share a channel.

- **Arrowhead.** The repository at the tail depends on the repository the arrowhead points to.
- **No arrowhead.** A shared resource such as a data store, with no direction. Neither depends on the other.
- **Solid line.** Static evidence, or curated by an administrator.
- **Dashed line.** Heuristic only: inferred from names or co-occurrence. Verify it before relying on it.
- **Dotted line.** Shared stack, drawn only when you turn on "Show shared-stack links".
- **Red line.** A critical path: a failure of the repository depended on would reach the repository that depends on it. Red is used for nothing else.
- **Thicker line and count badge.** A line that bundles several links of one type and direction. Click the badge to see all of them.

Relationships between repositories of the same domain are listed on its card. The relationship chips above the map list only the types present and can hide or show a type. "Min evidence" keeps the evidence-backed or the critical relationships only. A footer reconciles the map with the data: relationships drawn, listed on cards, kept in the shared stack, filtered, inside collapsed lanes or unresolved.

Click a line or its badge to see the evidence for each link: how the other repository was matched and which files the evidence comes from.

## What relationship types does the estate map show?

The relationship types in the estate map name how two repositories are connected, and each type belongs to one of three families: dependencies, delivery links and shared technology.

**Dependencies** are directed: the source depends on the target.

| Type | Meaning |
|------|---------|
| Source dependency | Pulls source code from the other repository |
| Library import | Depends on a library the other publishes |
| Build inheritance | Builds against build configuration the other publishes |
| Catalog relation | Declares the dependency in a service catalog |
| API contract | Consumes API contracts or schemas the other owns |
| Architecture interface | Calls an interface of the other named in the architecture analysis |
| API call | Calls the other's API, for example through a configured endpoint |
| Event messaging and event topic coupling | Publishes or consumes events the other publishes or consumes |
| Shared data store | Both use one named resource; coupled but undirected |

**Delivery links** are about how software is built and shipped: base image reuse, CI/CD orchestration and deployment assembly. They are shown, but they are not coupling.

**Shared technology** (shared technology stack, shared messaging technology, same-named data store) is commonality, not a relationship. See the next section.

Each line is marked with its family's color and a symbol, so families that share a color stay apart. Relationship types are defined in the [Enterprise Data API](/documentation/enterprise-data-api), whose estate-map resource carries the same types.

## What is the difference between a dependency and a 'Shared stack'?

A dependency in the estate map is a directed relationship, where one repository needs something the other provides. A shared stack is technology that two or more repositories both use. Shared technology is never coupling.

Two repositories that both run PostgreSQL or Kafka share an engine, not an instance, a schema or a topic. Neither depends on the other, so a shared engine adds no dependency, no choke point and no weight to the coupling figures. For that reason the map keeps shared technology in a separate "Shared stack" strip above the lanes. Hover a technology to highlight its repositories, and click to keep the highlight. "Show shared-stack links" draws them as dotted lines. It is off by default.

A technology counts as used by a repository when its manifest, lockfile or configuration declares it for runtime. A test or development-only dependency, a mention or a file name does not.

Use the shared stack for rationalization questions, such as how many different message brokers the estate runs. Do not use it to judge how tightly the systems are coupled. Likewise, delivery links such as a shared CI template or base image show how things are built, not how they behave at runtime.

## What do the evidence basis labels mean?

The evidence basis of a relationship in the estate map says how it was established. There are three labels.

| Label | Meaning |
|-------|---------|
| Static evidence | Resolved from manifest, configuration, catalog or code references |
| Heuristic | Inferred from keyword, role or co-occurrence signals |
| Curated | Recorded by a user in the estate editor |

CodeDD finds dependencies by comparing what each repository publishes (an API, a topic, a service name, a package, a repository address) with what the others reference, such as configured endpoints, integration settings, topics, package declarations and source or build references. A match found this way is static evidence. Each link lists the files it comes from and how the other repository was identified.

A heuristic relationship rests on weaker signals, and the map draws it dashed. Relationships that would be even weaker are not drawn at all. They are listed under "Suggested relations" with the reason they were held back, such as evidence below the threshold, a loose name match or a pairing inferred only from a shared business domain. They are never drawn or counted, and an administrator can add one if they know it exists.

When several detectors find the same dependency, it counts once. Independent findings raise the confidence in it.

## What does 'No directed dependencies detected' mean?

"No directed dependencies detected" is a banner on the estate map. It means detection found no relationship in which one estate repository depends on another. It is a statement about what was found, not proof that the repositories are independent.

The banner always states how many repositories detection could actually assess: "Dependency detection covered X of Y repos". When it appears, check that figure. If coverage is low, the absence of lines mostly reflects what could not be seen. For example, a repository may use a stack whose configuration the scan does not read, or the scan may have found only CI and deployment evidence and nothing about runtime dependencies.

The banner also notes undirected relationships and shared technology where they exist, and states that shared technology is not a dependency.

A hatched repository chip marks a repository with no usable dependency evidence. For these, a missing line is a blind spot, not isolation. The domain drawer's "Why no relation?" tool explains a missing line for any two repositories: whether a dependency connects them, a link too loose to draw, one side not assessable, or both scanned and nothing matched.

## What does detection coverage mean and why is coupling 'not assessable'?

Detection coverage in the estate map is the share of repositories whose dependencies could actually have been seen. Coupling and choke points are judged only when coverage is high enough.

A repository counts as covered when its scan found dependency evidence: something it publishes that others can point at, or references it makes to other systems. A repository is not covered when:

- the scan read none of its files, because its stack's manifests and configuration are not among those read;
- the scan failed or never ran;
- the scan found only delivery evidence such as CI, deployment references and base images, which says nothing about what the repository calls at runtime; or
- the scan found nothing.

A repository that runs as a service does not earn coverage merely from the package name in its manifest. That only shows nobody consumes it as a package, not what it calls.

When too few repositories are covered, or when no directed dependency was found, the Coupling and Choke Points figures read "Not assessable" instead of "Loosely coupled" or "None detected". Verdicts of absence are never drawn from missing evidence. Flagged choke points, being positive evidence, are always listed.

To improve coverage, include the repositories that define deployment and configuration, and re-audit older repositories. Coverage figures also appear in the [Enterprise Data API](/documentation/enterprise-data-api).

## How are topology roles assigned in the estate map?

The topology role of a repository in the estate map describes how it sits among its dependencies. It is derived from directed dependency evidence only.

| Role | Meaning |
|------|---------|
| Central producer | Several repositories depend on it |
| Producer | Serves other repositories, according to its framework and API signals |
| Consumer | Calls other repositories without serving them |
| Shared hub | Shares a data store with several other repositories |
| Unconnected | No dependency edge connects it |
| Hybrid | Both serves and calls |

Roles come from the relationships on the map and from a producer and consumer check on each repository, which scores its framework and API signals against what each role needs. A chip is shown only when a dependency relationship on the map supports it. Delivery links such as CI, deployment assembly or a base image do not back a role.

Without a directed dependency, no repository is the anchor and no role chip is drawn. A repository whose dependencies could not be seen keeps a neutral treatment in the company tier: its missing edges are unknown, not absent.

The domain drawer shows the basis of each role: the rule that gave it, the repositories that depend on it and that it depends on, any curation, and the classifier's scores with the signals behind them. A role that the current relationships no longer give is marked out of date. An administrator can set a topology role, and a curated role is kept.

## What are choke points and the anchor repository?

A choke point in the estate map is a repository that other repositories depend on through directed dependencies, so that a failure there would spread. The anchor is the repository the estate's directed dependencies converge on.

Only directed dependencies count. A shared technology or a delivery link never creates a choke point. A dependency also counts with at least medium evidence. The Choke Points figure lists each flagged repository with its reason, its estate role, the number of repositories that depend on it and the repositories a failure would reach.

The Coupling figure counts directed dependencies and critical paths, and lists the shared stack beside them without counting it.

"Critical path" lines are drawn red and on top: they run from a repository to the one it depends on, where a failure of the latter would reach the former.

Treat flagged choke points as places to look first in a diligence or consolidation review. Check the evidence of the dependencies behind a choke point before relying on it, since some may be heuristic. When the Choke Points figure reads "Not assessable", the estate does not have enough dependency evidence for a choke point verdict either way.

## What is the company Scale readiness tier?

The company Scale readiness tier is the estate-level version of the repository tier: how much growth the systems of a portfolio company support today, from T1 Foundational to T5 Hyperscale. It appears at the top of the Architecture tab and always covers the whole estate; the map filters never change it.

It uses the same checklist as a single repository, with the same six areas (release and deployment, data, communication, infrastructure, scaling and operations), the same four requirement states (Met, Not met, Not assessed, Doesn't apply) and the same definitions of Exact and at least. See [Architecture Analysis & Mapping](/documentation/architecture-analysis-mapping) for these.

The section shows:

- the company tier, its summary and its certainty;
- what limits it: the area, the repositories and the missing capability;
- what would lift it, and whether that is needed;
- a basis line stating which repositories meet the company tier, with their share of the estate's weight and code, which are below it and which could not be read;
- how each of the six areas sets the tier. Each mark is one requirement, and a row opens its checklist and the evidence per repository;
- the repositories, in groups: those that meet the company tier, those below it and those not rated.

A higher tier is not better. The tier describes scale, not quality, and should match the growth plan. A "when it is not needed" note accompanies each next step.

## How is the company tier calculated?

The company tier is calculated per area from the repositories that are rated, and the company tier is the lowest area.

1. **Which repositories count.** Repositories that are rated take part. Those with no running scale (libraries, infrastructure code and similar), those without enough evidence, those an administrator excluded, and archived ones do not.
2. **Weight.** Each repository counts in proportion to its size, so a large system counts for more than a small service, but not in direct proportion to its lines of code.
3. **Area level.** An area reaches a tier when repositories holding at least 80% of the weight (among those the area applies to) reach it there. Unreadable repositories stay in that comparison and never count toward reaching it. Every repository rated business-critical must also reach the tier in that area.
4. **Company tier.** The lowest of the six area levels.

A business-critical repository here is one with a high business impact rating, or one an administrator curated as Core. The company tier is therefore never higher than such a repository allows.

The tier is recounted the same way everywhere: the group audit, curation changes and the dashboard figures use one calculation. Open an area row and then a requirement to recount any claim, with the files read for each repository. A checklist CSV carries the same states.

## Which repositories are Not rated, pending or not re-analysed in the company tier?

In the company Scale readiness section, a repository can be outside the tier calculation for four reasons, and each is listed so you can see it.

- **Not rated.** The repository's kind has no running scale: libraries, CLI tools, frontend, mobile and desktop apps, infrastructure and GitOps repositories, data and ML projects, and documentation. This is not a poor result. An infrastructure repository still provides evidence that can settle checks in the repositories it provisions.
- **Not enough evidence.** Its files could not be read, or too few checks ran. Such a repository counts in the denominator and never toward reaching a tier.
- **Not re-analysed.** It was analyzed before the requirement checks existed. It shows its tier as "(previous method)" and has no checklist. Re-run the analysis to include it.
- **Excluded.** An administrator excluded it, with the date, shown under Not rated.

When repositories without a rating hold a share of the weight, they can only stop the next tier from being proven. The section then says "depends on" the named repositories. When they hold most of the weight, there is no company tier.

## When does the company tier say 'at least' or show no tier?

The company Scale readiness tier is either exact, at least, or absent.

- **Exact.** The next tier was checked and ruled out: even if every Not assessed requirement turned out Met, enough weight would still not reach it.
- **At least (T2+).** The tier is proven, but the next one is not ruled out. Evidence may sit outside the audited repositories, an unreadable repository may hold the answer, or the check does not exist yet. Treat it as a lower bound.
- **No tier.** Shown when no repository can be rated (for example an estate of libraries and infrastructure code only), when repositories without a rating hold most of the weight, or when too few repositories were re-analysed. The section states which and what to do.

Not assessed never counts against the company tier. Adding the infrastructure repository to the audit usually settles most "to confirm" items and can turn an at-least tier into an exact one.

An "at least" tier must not be compared with an exact tier. Benchmarks and exports flag it, and the estate map shows it as a dashed outline or a "+".

In an organization still on the previous method, the company tier is shown as "(previous method)" until the repositories are re-analyzed.

## How do I exclude a repository from the company tier, and who may?

Excluding a repository from the company tier removes it from the Scale readiness calculation. Use it when a repository does not belong in a judgment of what the estate runs, such as a retired system or an experiment.

An estate editor can exclude a repository under "Adjust data". After exclusion, the repository appears under Not rated with the date it was excluded, and the section discloses the company tier without it. The exclusion can be reversed.

A repository the tier depends on has a restricted exclusion. That means one needed for the next tier, rated business-critical, holding a large share of the weight, or whose exclusion would change the company tier or its certainty. If CodeDD cannot check the effect, the exclusion is also treated as restricted. Only an organization owner (the initiator) or a CodeDD administrator can exclude such a repository, and they must give a reason. Changing the estate role of a business-critical repository is restricted in the same way, since it also changes the tier.

Every restricted change is logged with the person and the reason. If you cannot make the change, the message says why.

The reason is deliberate: excluding the repositories that hold the tier down would otherwise make a company tier look better than the estate is.

## How do I filter, search and move around the estate map?

The estate map has filters, a search, zoom and a table view so that large estates stay readable.

- **Filters.** A filter bar sets the activity window (it defaults to "All time", so dormant repositories remain on the map), lifecycle, business impact, exposure, estate role, architectural style, tier, business domain and size. Repositories that do not match but connect to a matched one are kept at reduced opacity unless you turn that off. The KPI strip and the header sentence describe the filtered view when filters are set, while Scale readiness always covers the whole estate.
- **Find repo.** Type part of a repository or domain name to bring it into view and focus. It expands a collapsed lane or card if needed.
- **Focus connections.** Keeps a repository, its relationships and the repositories at their other ends in focus, and dims the rest.
- **Zoom and pan.** Use the buttons, the Fit button or Ctrl or Cmd with the wheel. A minimap shows where you are. Zoomed out far enough, cards show only aggregates.
- **Lanes.** Collapse a lane into one card and expand it again.
- **Phones.** The map becomes a list with one section per lane, and each card's connections are listed instead of drawn.
- **Table view.** Lists the domains, repositories and every relationship as tables, with where the map shows each relationship or why it is not drawn.

The map works from the keyboard, and screen readers receive a summary and the tooltip text of each item.

## What do the domain drawer and the KPI strip show?

The domain drawer in the estate map is a panel docked beside the map when you select a domain card. The KPI strip above the map summarizes the estate.

The KPI strip shows four things: the composition of the estate by estate role, the style mix, coupling and choke points. The tier is in the Scale readiness section above it, not in the strip.

The domain drawer shows:

- **Repositories.** Share of code, tier, code health, and why a repository takes no part in the estate analysis when that is the case. A repository holding most of a domain's code dominates its code health. A "Review" badge marks a repository an administrator should look at, and the notes say why.
- **Connections.** What the domain depends on, what depends on it and what it shares without direction, each with its evidence basis. Repositories without dependency evidence are named.
- **Topology basis.** Each role and what it rests on.
- **Why no relation?** Pick a repository of the domain and any other repository to see why they are or are not connected.
- **Classification confidence.** How far role signals agree and which fields an administrator curated.
- **External systems.** Third-party systems the domain's repositories call.
- **Tier peers and recommendations.** A comparison with repositories of the same tier, and recommendations drawn from evidence such as a critical-path repository or the largest gaps to the next tier.

The criticality rationale on a repository is an AI narrative. The systems it names are unverified candidates, each checked against the detected relationships.

## How can I adjust the estate data?

Estate editors can correct the estate map under "Adjust data". Initiators and reviewers of the organization can edit, as can CodeDD administrators. Submitters cannot.

The editor has three parts:

- **Repositories.** Set a repository's business domain, estate role, secondary role, architecture style and topology role, or exclude it from the company tier.
- **Domains.** Rename domains and products, confirm or reject what the analysis proposed, add one, and, under advanced options, merge, split or delete domains.
- **Relations.** Add a relationship, change its type or direction, or remove it. "Not a real dependency" removes a relationship for good, and the detectors do not bring it back. A pencil marks a curated relationship.

A curated value is marked as such and is trusted over the analysis: a curated style shows as Curated, and a curated role or relationship is drawn as curated evidence. Setting a curated style back to Unknown clears the curation and brings back the detected style.

Curation is for fixing what the analysis got wrong or could not know. Do not use it to hide a finding. Restricted changes need an organization owner or administrator and a reason. See the answer on exclusion above.

## What is kept when I re-audit a repository or re-run the group audit?

Your curation is kept for the repository itself, identified by its organization and Git remote, so a re-audited repository keeps its curated domain, role, style, topology role and relationships. The analysis does not overwrite curated business domains.

What is recomputed is everything that was not curated: detected relationships, the shared stack, coverage, the tiers and the company tier. After a re-run, check the estate analysis banner, because stages can be out of date when repositories were added or removed.

A removed relationship stays removed. A relationship the detectors only propose appears under "Suggested relations" and is not added automatically.

## Can I export the estate map or its data?

The company Scale readiness section has a checklist export as CSV, where the server supplies it. It carries the same requirement states as the section, so a tier can be recounted outside CodeDD. The map has no image download; use the table view for a text version.

For programmatic access, the [Enterprise Data API](/documentation/enterprise-data-api) serves the estate map as a versioned resource. Its second version states what every relationship means and what evidence it rests on, lists shared technology separately from dependencies, serves detection coverage and the estate analysis stage status, and serves the company tier with its certainty and requirement-ladder summary. A tier is `null` when it does not apply, never a made-up number.

The estate map is safe to screenshot for diligence materials, since its layout is stable and does not move between visits.

## How does the estate map relate to the AI advisor?

The AI advisor in the app answers product questions from this documentation and can use your portfolio data. The executive summary of a group audit is written under evidence guardrails: it makes no coupling, role or tier claim the evidence does not support, and it says so when cross-repository coupling cannot be determined.

Ask the advisor how to read the map ("what does Shared stack mean?") or for a summary of a domain. For anything decisive, open the evidence on the map yourself.

## What are the limitations of the estate map?

The estate map is limited by what static analysis of the audited repositories can see.

- **Only audited repositories.** A dependency on a repository outside the group audit cannot be drawn. A system split across repositories needs all of them in the audit.
- **Static evidence.** Relationships come from configuration, manifests and code references. Runtime traffic is not measured.
- **Coverage varies by stack.** Where the scan cannot read a repository's stack, its relationships may be missing. Hatched chips and the coverage banner show where.
- **Domains and roles are proposals.** They come from AI analysis checked by deterministic signals, and they can be wrong. Curate them.
- **A tier is a lower bound where it says "at least".** The checklist also has checks that are not built yet.
- **Platform settings outside the repositories** show as Not assessed.
- **Previous-method repositories** carry no checklist until re-analyzed.

None of these limitations is hidden: each shows as a banner, a hatched chip, a "Not assessable" or a "Not assessed". Where the map is silent, it is not claiming there is nothing there.

## Frequently asked questions

These are short answers about the estate map, its relationships and the company Scale readiness tier, covering evidence, coverage, curation and access.

### Why does my estate show no company tier?

An estate shows no company Scale readiness tier when no repository can be rated, when repositories without a rating hold most of the weight, or when too few repositories were re-analyzed. The section states the reason. Re-run the analysis for repositories analyzed before the requirement checks, and check that files could be read.

### Why is my repository 'Not rated'?

A repository is Not rated in the estate map when its kind has no running scale (library, CLI tool, frontend, mobile or desktop app, infrastructure, data pipeline, documentation), when there is not enough evidence, or when an administrator excluded it. It does not count toward the company tier, and it is not a poor result.

### Why does a repository card show no tier?

A repository card shows a tier band only when a tier exists. A missing band means the tier does not apply to its kind, there is not enough evidence, or the repository was analyzed by the previous method and has none. The chip's tooltip says which.

### Is a shared database or shared technology a dependency?

A shared database or shared technology in the estate map is not a dependency, because shared technology is never coupling: two repositories on PostgreSQL share an engine, not an instance. It is listed in the Shared stack strip. Only a directed relationship, where one repository needs something the other provides, is a dependency.

### Why is there no line between two repositories I know are connected?

The line may be missing because one repository has no usable dependency evidence (a hatched chip), because the link was too loose to draw and appears under "Suggested relations", or because the connection runs outside the audited repositories. Use "Why no relation?" in the domain drawer, and add the relation under "Adjust data" if you know it exists.

### What does 'not assessable' mean for coupling?

Coupling not assessable means the estate does not have enough dependency evidence for a verdict. It is not "loosely coupled" and not "tightly coupled". Increase coverage by auditing the repositories that define deployment and configuration.

### What is the difference between Static evidence, Heuristic and Curated?

Static evidence is a relationship resolved from manifests, configuration, catalogs or code references. Heuristic is inferred from names, roles or co-occurrence, and is drawn dashed. Curated was recorded by a user. Verify heuristic relationships before relying on them.

### Does a higher company tier mean a better company?

A higher company Scale readiness tier does not mean a better company: it means the systems support more scale at more cost and complexity, not that the code or the business is better. It should match the growth plan. Each next step states when it is not needed.

### Can I change a tier directly?

A Scale readiness tier cannot be edited directly. It is recalculated from the requirement states. You can change what goes into it: exclude a repository (restricted where the tier depends on it), curate a repository's role, or add the repositories that settle "to confirm" items.

### Who can change the estate map?

Initiators and reviewers of the organization, and CodeDD administrators, can adjust domains, roles, styles and relationships. Submitters cannot. Changes that move the company tier, such as excluding a repository the tier depends on, need an organization owner or administrator and a reason. See [Team Members & Access Roles](/documentation/team-members-access-roles).

### Are my curated changes lost when I audit again?

Your curated changes are not lost on a re-audit: curated domains, roles, styles, topology roles and relationships are kept for the repository, identified by organization and Git remote. Detected values are recomputed.

### Where do I see the estate data programmatically?

The [Enterprise Data API](/documentation/enterprise-data-api) serves the estate map as a versioned resource with typed relationships, evidence, coverage and the company tier. Use the second version for new integrations.

## Related guides

These pages describe the audit stages and portfolio features around the estate map.

- [Architecture Analysis & Mapping](/documentation/architecture-analysis-mapping)
- [Setting Up a Portfolio Organization](/documentation/setting-up-a-portfolio-organization)
- [Portfolio Monitoring](/documentation/portfolio-monitoring)
- [Enterprise Data API](/documentation/enterprise-data-api)
- [Team Members & Access Roles](/documentation/team-members-access-roles)