# Documenting an estate

How a team takes an inherited estate to a confirmed graph: agree the scope, run the first inference, hold the confirmation sessions, keep the model current.

## Before connecting: agree the scope

The first decision is not technical. Your team decides which databases and which environments Datapace may read, and in what order. A common first scope is the two or three systems most of the routine work touches, in a non-production environment that mirrors production's schema.

Datapace is designed to read within that scope only. Widening it later is a decision, not a setting someone flips.

## The first inference

Once connected, Datapace reads schema metadata, workload signals, and sample structures, and proposes the graph: entities, measures, relationships, semantics, lineage, each with a confidence score, plus the infrastructure facts around each database. See [infer and confirm](/docs/concepts/infer-and-confirm).

Nothing is confirmed yet. What you have is a map with every road drawn and none of them named by a person.

## The confirmation sessions

A first pass is a few working sessions with the people who know the data. Datapace orders the proposals so each session spends its time where it matters:

1. **The entities most of the workload touches.** The ten tables behind most of the reads are the ten the team should name first.
2. **The columns flagged as personal data.** Confirmed flags travel through lineage and into governed context, so they are worth settling early.
3. **The relationships with the most joins behind them.** These are the ones dashboards and agents rely on.
4. **The measures dashboards already report.** Where two dashboards disagree on "active customers", the session decides.

In a session an expert accepts, corrects, or reassigns each proposal. Every decision is recorded with who made it and when. A low-confidence proposal is a question for the session, not a default that slips through.

## Keeping the model current

The signals keep arriving after the first pass. A new table appears as an inferred entity waiting for review, a changed query pattern shows up as a relationship to confirm, a column that starts carrying addresses is flagged again. The Documentation agent proposes the updates; the owner of the entity approves them.

The model is current because the routine of approving updates is short, not because someone remembers to edit a wiki.

## What you have at the end

- One confirmed graph of the estate, in the team's own terms, that people and AI systems can trust.
- The infrastructure facts on the same graph, so the FinOps and Performance agents can start proposing with evidence.
- A record of every confirmation, which is the beginning of the [audit ledger](/docs/concepts/policy-approval-audit).

For the same job on a source system that is about to be migrated, see [migration mapping](/docs/guides/migration-mapping).