> For the complete documentation index, see [llms.txt](https://docs.aohwv.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.aohwv.dev/core-concepts/concepts.md).

# Overview

Understand how AOH Sync models your identity data and keeps it in sync.

The Core Concepts section covers the building blocks that underlie every feature in AOH Sync. Read these pages if you want to understand *why* the product works the way it does — or before diving into the Feature Reference for configuration walkthroughs.

## Guiding principles

A few principles shape how AOH Sync behaves throughout:

* **One canonical record per person.** A person may appear in many systems — HR, payroll, directory, SaaS apps. AOH Sync collapses those into a single Identity and keeps every linked record attached to it. There is always one authoritative answer to "who is this person?"
* **Access is decided by the backend, on every request.** The interface reflects what is permitted; it never grants access. When access is revoked, it takes effect immediately on the next request — there is no stale-UI window.
* **Everything that changes state is recorded.** Every action that modifies data — provisioning a user, resolving an orphan, acknowledging an anomaly, transferring machine identity ownership — is written to the audit trail.
* **Risk is measured, not guessed.** Orphan risk scores and posture scores are computed from explicit inputs on a defined schedule, not estimated by heuristics.
* **Long-running work happens in the background.** Full syncs and provisioning runs are asynchronous. The interface returns immediately; you track progress from the Connectors history or Status & Logs screen.

## Pages in this section

| Page                                                                                | What it explains                                                                                 |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| [How AOH Sync Works](/core-concepts/how-aohsync-works.md)                           | The end-to-end flow from your Source Systems to Microsoft Entra ID                               |
| [Identities, Accounts & Users](/core-concepts/identities-accounts-users.md)         | How AOH Sync models a person across multiple source systems                                      |
| [Source & Target Systems](/core-concepts/source-and-target-systems.md)              | What Source Systems and Target Systems are, and how they differ                                  |
| [Sync Types](/core-concepts/sync-types.md)                                          | Full, incremental, and delta syncs — when each runs and what it does                             |
| [Provisioning & Deprovisioning Lifecycle](/core-concepts/provisioning-lifecycle.md) | Joiner, Mover, Leaver, and Reactivation events — how AOH Sync tracks workforce changes           |
| [Roles & Permissions](/core-concepts/roles-and-permissions.md)                      | Who can do what inside AOH Sync, and how access decisions are enforced                           |
| [Machine Identities](/core-concepts/machine-identities.md)                          | Non-human accounts — service accounts, shared mailboxes, and bots — and how AOH Sync tracks them |

## Related

* [Getting Started](/getting-started/getting-started.md)
* [Feature Reference](/feature-reference/dashboard.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.aohwv.dev/core-concepts/concepts.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.