> ## Documentation Index
> Fetch the complete documentation index at: https://docs.prophia.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Understanding onboarding

> How a building goes from an address to fully curated data — and how to tell where it is

Prophia data is not just uploaded, it is **curated**. Between a document landing in the system and its terms being trustworthy sit an AI extraction pass and a human review by Prophia's team. Onboarding is that arc, and several status fields report where a given asset sits on it.

If you are mirroring Prophia into a warehouse, this is the page that tells you what to gate on.

## The arc

```mermaid theme={null}
flowchart TB
    subgraph you["You — in the app, or over the API"]
        direction TB
        S1["<b>1 ·</b> Create the Property, Building, and its spaces"]
        S2["<b>2 ·</b> Add a Lease per tenant"]
        S3["<b>3 ·</b> Upload the documents — leases, amendments, exhibits"]
        S1 --> S2 --> S3
    end

    subgraph prophia["Prophia"]
        direction TB
        S4["<b>4 ·</b> AI extraction reads every PDF and machine-tags it"]
        S5["<b>5 ·</b> The implementation team reviews and curates"]
        S6["<b>6 ·</b> The building is signed off and handed over"]
        S4 --> S5 --> S6
    end

    S3 --> S4
```

Steps 1–3 are yours: they map onto the onboarding wizard in the app, and onto `POST` calls in this API if you have [write access](https://docs.prophia.com/developers/write-access.md). Steps 4–6 are Prophia's, and none of the status fields they drive are writable over REST.

Onboarding is not one-and-done. Every new document added to a live building runs through the same extraction-and-curation loop, so `documentStatus` matters long after a building is handed off.

## Document status: the atom

Everything else rolls up from here. A document normally goes `processing` → `incomplete` → any account-specific review states configured on your account → `complete`. Only `complete` means the data has been curated and signed off — every other value, built-in or account-specific, means it hasn't. See [Documents](https://docs.prophia.com/api-reference/v2/concepts/documents.md#documentstatus-the-curation-lifecycle) for the full table.

## Lease rollup: `docCompletionStatus`

A lease's [`docCompletionStatus`](https://docs.prophia.com/api-reference/v2/concepts/leases#three-status-fields-three-questions) is `complete` when **every** document on it is `complete`, and `incomplete` otherwise. One un-curated amendment holds the whole lease at `incomplete` — which is the point: a lease whose latest amendment hasn't been read yet is not a lease you want to report on.

## Building rollup: `onboardingStatus`

`onboardingStatus` tracks how far the building has moved through the process. It is read-only over this API.

| Value | Meaning |
| - | - |
| `NOT_STARTED` | The building record exists. Nothing else has been done — this is the default on create, including via `POST .../buildings`. |
| `INITIAL_SETUP` | Spaces and tenants have been entered. The building is set up but its documents haven't been supplied. |
| `ONBOARDING_IN_PROGRESS` | Setup is finished and handed to Prophia. Documents are uploaded and moving through extraction and curation. |
| `ONBOARDING_COMPLETE` | Every lease in the building has all of its documents `complete`. |

> [!WARNING]
>
> **The middle two values are driven by the app, not the API.** `INITIAL_SETUP` and `ONBOARDING_IN_PROGRESS` advance when someone works through the onboarding wizard in the UI and marks those steps done. Nothing in the REST API advances them, so a building created and populated purely over the API will likely sit at `NOT_STARTED` until it flips straight to `ONBOARDING_COMPLETE` — and even that path isn't guaranteed. Don't read `NOT_STARTED` on an API-driven building as "nothing here yet."

> [!NOTE]
>
> `ONBOARDING_COMPLETE` is set **automatically**, and it happens **once in a building's lifetime**. The system flips it when the building is not `INACTIVE` *and* every lease in it has finished document curation; the moment it flips, `onboardingCompleteDate` is stamped. It does not revert when a new document is later uploaded — a live building taking on a new amendment stays `ONBOARDING_COMPLETE` while that amendment works through the pipeline.

That last point matters: **`onboardingStatus` answers "did this building ever finish its initial onboarding?", not "is this building's data current right now."** For the current question, roll up `docCompletionStatus` across the building's leases yourself.

The progression is also one-way in practice — a building at `ONBOARDING_IN_PROGRESS` or `ONBOARDING_COMPLETE` cannot be pushed back to `INITIAL_SETUP` or `NOT_STARTED`.

## Building state: `activeStatus`

`activeStatus` is a different axis: it tracks the building record's operational state and the internal review checkpoints, and it is also read-only over this API.

| Value | Shown in-app as | Meaning |
| - | - | - |
| `WORK_IN_PROGRESS` | In Progress | The default on create. Data is being assembled. |
| `AI_PROCESSED` | AI Processed | Set automatically once every document *currently* in the building has cleared the AI pipeline. Machine-tagged, awaiting human review. |
| `QA_PENDING` | QA Pending | Prophia's internal quality-assurance checkpoint. |
| `ACTIVE` | Active | **Prophia has fully curated the building's data and handed it off.** This is the signal that the asset is ready for you to rely on. |
| `INACTIVE` | Inactive | The building will receive no further updates — a purely historical record. |

> [!WARNING]
>
> `AI_PROCESSED` means "everything uploaded so far has been machine-tagged", not "everything has been uploaded." Documents are frequently supplied across several sessions, so a building can reach `AI_PROCESSED` while more of its documents are still to come. Treat it as a checkpoint on the building's current contents rather than a statement that the building is fully loaded.

> [!NOTE]
>
> `activeStatus: ACTIVE` is the handoff signal, and it is the one worth building on. `onboardingStatus: ONBOARDING_COMPLETE` says the documents finished processing; `ACTIVE` says Prophia's team is satisfied with the result and has released the asset.

`implementationManager` on the building names the Prophia person responsible for that onboarding and review. It is not the account manager.

## What lags during onboarding

Some building fields are caches rebuilt from the stacking plan rather than computed per request, so they can be stale while leases are still in onboarding:

`totalRentableSquareFootage`, `squareFootageLeased`, `squareFootageOccupied`, `squareFootageVacant`

Each carries this caveat on the [building endpoint](https://docs.prophia.com/api-reference/v2/buildings/get-building.md). Don't use them for point-in-time occupancy on a building that isn't `ACTIVE` yet.

## Putting it together for a sync job

**1. Decide your bar**

For reporting you can stand behind, filter buildings on `activeStatus=ACTIVE` and leases on `docCompletionStatus: "complete"`. For a fuller mirror, take everything and carry the status fields through so downstream consumers can decide.

**2. Poll for change, don't re-crawl**

[`GET .../recent_changed_leases`](https://docs.prophia.com/api-reference/v2/accounts/list-leases-recently-updated) names the leases whose documents changed in a window. That covers both new documents arriving and existing ones reaching `complete`.

**3. Re-check status on every pass**

A lease that was `incomplete` last week may be `complete` now, with different tag values. Curation corrects machine extraction — treat pre-`complete` values as provisional and expect them to change.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.