# Phase 2 — data and system assessment

> **What you will learn**
> Four things to confirm before starting, and where you stall if you skip this
> phase.
>
> **If databases themselves are unfamiliar,** start with [What a database is](/guide/it-database).

## The purpose of this phase

> **Analyse the existing data and systems and plan the integration.**

In one sentence: **confirm you can build it before you build it.**

The most wasteful failure is this:

```
POC week 3: "you can't have that data"
→ security approval is needed and takes two months
→ or that system has no API
→ or the data exists but the quality is unusable
```

**Finding out while building means you already spent three weeks.** Phase 2
turns those three weeks into three days.

## Four activities

### 1. Map the data sources (API / DB / documents)

Write down **where the data you need lives and in what form.**

| What you need | Where | Form | Access | Confirmed |
|---|---|---|---|---|
| Original invoices | accounting mailbox | PDF attachment | IMAP | ○ |
| Supplier master | ERP | DB table | needs a read account | **△ requested** |
| Account code rules | in someone's head | — | document via interview | ✗ |
| Past entry history | ERP | DB | same as above | △ |

**Note the third row.** Rules that live "in someone's head" are extremely
common, and documenting them is itself an output of this phase.

### 2. Assess system integration options

Confirm **how you can connect** to each system.

| Integration | Difficulty | What to check |
|---|---|---|
| There is an official API | low | auth method, rate limits |
| Direct DB read | medium | read-only account, schema-change risk |
| File exchange | medium | frequency, location, format stability |
| Screen automation only | **high** | breaks when the screen changes. Last resort |

If it is the last row, **reconsider.** You can build it, but you cannot maintain
it.

### 3. Evaluate data quality

Being able to access it does not mean you can use it.

```
Check:
  □ how much is missing        (e.g. supplier code missing on 12%)
  □ is the format consistent   (dates in three different formats)
  □ are there duplicates       (the same supplier under 4 different names)
  □ how far back does it go    (only two years)
  □ how often it refreshes     (overnight batch, one day behind)
```

**There are projects where "one day behind" is fatal.** If data for real-time
support is a day old, that project does not stand up. This is what you must find
now.

### 4. Document governance and security requirements

| Check | Why |
|---|---|
| May this data leave the organisation | personal data or trade secrets |
| Is approval needed, and whose | usually takes longer than expected |
| Must you keep logs | mandatory in regulated industries |
| Must it be air-gapped | if so, the whole architecture changes |

**Always ask how long approval takes.** "About two weeks" and "it goes to the
quarterly review board" produce completely different plans.

## Output

> **System architecture & data flow diagram**

One picture is enough. Something like this:

```mermaid
graph TD
  A["Accounting mailbox<br/>PDF attachments"] --> B["Read the document"]
  C["ERP supplier master<br/>read-only account"] --> B
  D["Account code rules<br/>documented"] --> B
  B --> E["Produce a draft entry"]
  E --> F{"Over the approval threshold?"}
  F -->|"yes"| G["Human approval"]
  F -->|"no"| H["Auto-enter into ERP"]
  G --> H
```

The picture must show **where human approval sits.** That is the start of
[guardrail](/guide/ha-guardrails) design.

## Gate — to move on

> **Have you confirmed you can actually access the data you need?**

The standard for "confirmed" is **you actually pulled it once.** Not "it looks
possible."

```
✗ "They say the ERP has an API"
✓ "I got a read account and actually queried 10 supplier records"
```

## Common mistakes in this phase

### Judging from documentation alone

"It's in the API docs, so it'll work" → in reality the endpoint is disabled, the
permissions differ, or the response does not match the docs. **Actually calling
it once takes 30 minutes.**

### Deferring security approval

The most common cause of schedule slip. Technical review takes days; approval
takes weeks. **File the approval request on the day Phase 2 starts.** It runs in
parallel while you do the other checks.

### Eyeballing data quality

Looking at ten records and saying "seems fine" is not enough. Count **missing
rate, format variants, and duplicates** across the whole set. A few lines of
query.

---

## Check yourself

**1. What is the standard for "confirmed we can access the data"?**

<details>
<summary>Answer</summary>

**You actually pulled it once.** "They say there's an API" is not confirmation;
"I got a read account and queried 10 records" is.
</details>

**2. Why does "overnight batch, one day behind" matter?**

<details>
<summary>Answer</summary>

**Because it changes whether the project stands up at all.** Data for real-time
customer support that is a day old makes the project impossible. This has to be
found before building.
</details>

**3. Why file the security approval on day one of Phase 2?**

<details>
<summary>Answer</summary>

**Because approval takes far longer than technical review.** Technical checks
take days, approval takes weeks, and it is the most common cause of schedule
slip. Filing first lets it run in parallel with everything else.
</details>

---

Before building, check the legal requirements once →
[Regulation and compliance](/guide/ax-compliance)