> For the complete documentation index, see [llms.txt](https://docs.buildings.ability.abb/collection/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.buildings.ability.abb/collection/copilot-assistant/improving-results/data-requirements.md).

# Data Requirements

Copilot Assistant works with the data available in your asset hierarchy. It does not create missing measurements or infer a reliable meaning for an asset that is not described clearly.\
While it can work in theory with a loosely defined hierarchy and lax asset model it might not be able to realize its full potential.\
Preparing the data foundation is therefore as important as writing a good prompt.

## Minimum Requirements

The following conditions are required for useful data requests:

* You have an asset catalog  contains the relevant locations, assets, and measurements.
* The asset hierarchy represents the relationships between those assets, such as portfolio -> site -> building -> floor -> room -> asset.\
  This makes the Assistant understand the locational relationships of your data.
* Assets and locations have stable, recognizable names. Use consistent naming for the same type of entity across buildings.
* Asset types, tags, and attributes describe what an asset represents -> these should be used consistently across all assets.
* Measurements have meaningful attribute names, attribute types and, where applicable, a unit such as `°C`, `kWh`, or `%`.
* Current data is available for live-status questions, and historical data is available for trend or comparison questions.
* Users have access to the assets and data they are asking about. Copilot Assistant cannot query data outside the permitted context of the specific user.

If one of these conditions is missing, Copilot Assistant may ask for clarification, return no matching data, or produce a result that is narrower than intended.

## Data That Improves Business Value

Data can be technically available and still be difficult to use for decisions. The following practices improve resolution, response quality, and the usefulness of follow-up analysis:

### Consistent Semantics

Use the same vocabulary for equivalent locations, asset types, metrics, and units. For example, decide whether a portfolio uses `occupancy`, `people_count`, or another agreed attribute for the number of people in a room. Document the mapping when the business term differs from the stored attribute name.\
\
Naming the same measurement differently without a clear reason (e.g. presence vs. people\_count) makes it much harder for the assistant to catch all relevant measurements, especially if these attributes do not have the same attribute type.

### Complete Hierarchies

Link assets to their real locations and parent assets. A flat list of sensors makes questions such as "which rooms on the third floor" difficult to resolve because the relationship is not available to the agent.

## Limitations

Copilot Assistant can retrieve and analyze available data, but it cannot repair an inconsistent asset model, supply missing history, or decide an undefined business KPI. Questions such as "Which buildings have the biggest opportunity?" need a measurable definition, such as energy consumption, cost, occupancy, or a target deviation, before they can be answered consistently.

For prompt patterns that make the intended scope explicit, see the [Prompting Guide](/collection/copilot-assistant/improving-results/prompting-guide.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.buildings.ability.abb/collection/copilot-assistant/improving-results/data-requirements.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.