Review your AI Estate

Use AI Estate to review the systems behind your workloads and the relationships Orqestra can show. Start with a concrete question: who owns a system, what depends on an asset, where processing is declared, or which evidence is missing.

Before you start

Select the relevant workspace, then open Assure → AI Estate. The Estate module and Estate read access must be available. Other source permissions determine which records you can see. Cost requires cost access; registering or editing systems requires system-write access.

If Estate is unavailable, use the permitted Core workspace pages links for assets, releases, or execution evidence. Ask your administrator to confirm module availability and access. An unavailable Estate view does not mean those core records are absent.

Check the overview’s scope first

On Overview, read the access note, the number of workspaces in scope, retrieval time, and Coverage and limits before interpreting the inventory counts.

Check Latest recorded source update as well as retrieval time: retrieving an older record now does not make its underlying information current. Inventory totals do not infer data lineage, dependency impact, or unregistered systems.

Register a system and its owner

A system groups the workloads that serve an intended purpose. Its boundary states which workloads belong inside that system.

1. Open Systems and select Register system.
2. Enter System name and Intended purpose in terms another reviewer can understand.
3. Select an Accountable owner and Owner team, then set the Risk tier. If you cannot browse other people, select yourself or ask someone with member-management access to assign the appropriate owner.
4. Under Workloads inside this system, select the workloads that belong to it. Review the complete selection, then select Register system.
5. Open the resulting record and check the owner, boundary state, and workload membership. A system without available workloads can be registered as a draft; complete its boundary when the workloads are available.

An owner-team reference is ownership metadata. Entering a custom team value does not create a directory group or grant access. Registration records the system you describe; it does not discover all of its external dependencies automatically.

To correct metadata, open the record, select Edit system record, and use Save system record. To change membership, choose Edit boundary and Save boundary. These changes affect the shared system record, so coordinate ownership or membership changes with its accountable owner.

Review and confirm a boundary

1. In Systems, use the search and filters to find the system, then open its record.
2. Review its member workloads, active releases, dependencies, and any state reasons. Use Open Atlas when you need to investigate relationships.
3. If Review and confirm boundary is available, select it. Check the stated revision and workload count, then select Confirm revision for that revision.
4. Confirm that the boundary state reflects the saved confirmation.

Confirmation records your review of that boundary revision. It does not enforce a runtime perimeter or certify the system. Later membership changes can require another confirmation. If stored links are hidden or a workload cannot be resolved, editing may be unavailable to protect an incomplete boundary. Ask an authorized owner to resolve those links; do not remove them simply to enable saving.

If a save or confirmation fails, refresh the record and check whether its revision changed before retrying. Reopen the editor after a workload-list error.

Explore dependencies in Atlas

Open Atlas to move from the namespace map into workspace systems and system dependencies. Select a system or dependency to inspect its relationships and consumers. Use the table view and pagination when a graph is too dense, and read the Provenance and Last seen information for each relationship.

Use the result to identify owners to contact before changing a shared asset or route. Read coverage notices and truncation warnings before treating the visible consumers as a complete impact list. Relationships based on declared configuration and those observed at runtime are different evidence.

The data-flow view highlights recorded data-source reads. Writers and external lineage are not covered. A recorded retrieval does not establish that an output was wrong, and a missing relationship does not prove that no dependency exists.

Review data impact

1. Open Data impact and select an Observed window.
2. In Graph, choose a Data source and Reach. Inspect its observed readers, affected workloads, and systems.
3. Use Critical data to compare sources within the available observations. Review the ranking’s basis before using it to prioritize investigation.
4. Read the coverage notes and any at least qualification alongside the result.

This view reports reads recorded by executions in accessible workspaces. No observed data reads in this window does not mean a source has no consumers. Computed impact is a what-if based on the recorded relationships, not a live incident count or a guarantee that every affected system was found.

Review regions and route scenarios

Open Regions to compare location evidence. Keep its levels separate:

• Configured describes settings and provider defaults.
• Declared describes regions named by active release routes or their bound region set.
• Observed describes recorded runtime activity in the stated window.
• Verified is not covered by this view.

Read Coverage before drawing a location conclusion. A route without a region or a source hidden by permissions leaves a gap; it does not establish where processing took place.

Use Scenario preview to explore the stated provider or region outage, or a region-boundary scenario when available. Review which declared routes remain and which were not assessed. A preview does not change routes, test provider availability, or execute failover. Coordinate any real release or routing change through release operations.

Explain cost and evidence gaps

In Cost, choose Group by and Window. Compare Known subtotal with Priced coverage, Provider-reported actuals, Admission estimates, and Outstanding liabilities. Read Counting rules and Not covered before presenting a total. Outstanding liabilities are not included in the subtotal, and unmapped and unattributed amounts can overlap. This is live accounting state selected by execution creation time, not a fixed billing statement. For budget controls, see manage resource limits.

In Lenses, choose AI governance, Data privacy, or Operational resilience. Open a system’s cells to inspect the source facts and gaps. Sources found · not reviewed means supporting records exist, not that someone accepted them. Not covered can mean missing access, unavailable sources, unlinked records, or a source the lens does not read. Read the reason before assigning remediation.

Use these findings to agree an action with the system owner: correct ownership, complete a boundary, inspect a release, supply missing evidence, or request access. Lenses support internal review; they do not provide legal advice or certification. For policy approvals and assurance reviews, continue with governance and audit tasks.