Documenting an estate

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.

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.

For the same job on a source system that is about to be migrated, see migration mapping.