Read the PDD¶
The seed's PDD.md is a signed, versioned Process Definition Document: fifteen sections describing how a property claim is handled, written by the business user and business analyst for whoever designs the solution. It is synthetic, but internally consistent and complete: every figure in it is a real oracle your build will be tested against.
You have the document in your cloned seed; every § link on this page opens the same document on GitHub at that exact section, so you can jump back and forth without leaving the course.
Why it names no product¶
Search it and you will not find a UiPath Agent, a Maestro Case, a Data Fabric Entity or any other product name. That is deliberate, and it is what makes block 1 a design exercise rather than a transcription. The PDD says what the business does and which decisions need judgement; your design decides what becomes an Agent, what becomes an expression, and what is already deployed and merely bound.
The column that drives your architecture more than any other is decision nature in the step table (§5.3): every step is marked rule-expressible (the rule can be written down and applied the same way every time) or judgement (something is being weighed, and what is weighed is named).
PDD §5.3, Stage 2: five checks
Open §5.3 in the full document ↗
All five checks run and all five are reported, whatever the result. A failure sets the overall result; it does not stop the other checks.
| Step | Action | Actor | System / data touched | Decision nature | Expected result | Remarks |
|---|---|---|---|---|---|---|
| 2.1 | validate that the policy was in force on the date of loss | system | claim data, policy | Rule-expressible — BR-01 | Pass or fail, with the policy's payment status and period quoted | |
| 2.2 | validate that the claimant and the policyholder are the same person | system | claim data, policy | Judgement — weighing nicknames, middle names and spelling variation against a genuinely different individual | Pass or fail, naming who the policy is in | Two names being similar is not the test; being the same person is |
| 2.3 | validate that the claim and the policy describe the same property | system | claim data, policy | Judgement — weighing formatting and abbreviation differences against a real difference of address | Pass or fail, quoting both addresses | |
| 2.4 | validate that the incident date falls inside the policy period | system | claim data, policy | Rule-expressible — BR-04 | Pass or fail, giving the loss date and the policy period | |
| 2.5 | validate that the claim was filed within the filing deadline | system | claim data | Rule-expressible with a judgement tail — BR-05 | Pass, fail, or late with justification | Late with justification is a caveat, not a failure |
| 2.6 | create the screening result | system | claim record | n/a | Every check, its result and its reason are on the record before any human is asked to look | A reviewer's screen is built from what has been recorded |
| 2.7 | review the screening result and decide whether the claim proceeds | Eligibility reviewer | claim record, claim form, policy | Judgement — whether a failed check is a reason to stop, given anything the claimant has documented | Proceed or refuse, with a written reason | Only reached if at least one check failed. See §5.7 H1 |
| 2.8 | transfer the claim for inspection | system | — | n/a | The claim is waiting for an assessor report | Instructing the assessor is OS1 — this process waits, it does not dispatch |
The tour: where the detail lives¶
| Section | What it holds | You'll need it |
|---|---|---|
| §1–§2 | Purpose, success criteria SC1–SC6, scope, assumptions | Now: it frames everything |
| §3 | The five personas and what each must be able to see | When the review screens are designed |
| §4 | The as-is process and its pain points | Context: what must not be reproduced |
| §5.3 | The step table: every step, its actor, its decision nature | Now, and at every design review |
| §5.4 | Control-flow structure: what forks, what waits, what repeats | The case block |
| §5.5 | Lifecycle stages and SLAs, and which stages are exceptional | The case block |
| §5.6 | The three documents and their structure | The extraction block |
| §5.7 | The two human touchpoints: who decides, what they must see, what happens if nobody acts | Now, and at the app block |
| §7 | The business rules, BR-01 onwards, grouped by family: eligibility, report validation, coverage, settlement, credibility, decision rules, correspondence, overrides | During the agents block, by rule id |
| §7.9 | What is not a finding: the rules that keep clean claims clean | Half the job. Read it twice |
| §8–§10 | Exceptions, integrations, compliance controls | Reference |
| §11 | Reporting: what the claims team lead must see | The process app, in the App section |
| §13 | One canonical worked example, and the catalogue of what can be planted | §13.2 now; §13.1 again at verify |
| §14 | Out of scope: nothing here may appear in your component inventory | At design review |
How to read it today¶
- Read now: §1–§2, the §5.1 narrative and §5.2 map, §5.7, §13.2. Twenty minutes, and you know the process.
- Reference later: §7 rule by rule during the build (your agent will cite rule ids like
BR-24); §5.4 and §5.5 at the case block; §13.1 at verify. - Mind the vocabulary. The glossary at the top fixes the business's exact words: claim, never case or ticket; assessor report, never survey. Synonym drift in a design turns into wrong stage and outcome names downstream, so the same discipline applies to everything you and your agent write.
See it in the original: the glossary and the verbatim labels
The business uses these words exactly as spelled here. Synonym drift turns into wrong stage, role and outcome names downstream.
| Term | Exact form used by the business | Meaning | Never call it |
|---|---|---|---|
| Claim | claim | One request for payment under one policy for one incident | case, ticket, file |
| Claim submission form | claim form | The document the claimant completes | application, FNOL form |
| Assessor report | assessor report | The independent inspection report on the damage | adjuster report, survey, inspection |
| Cause determination | cause determination | The assessor's professional finding of what caused the loss | root cause, incident type |
| Deductible | deductible | The amount the policyholder bears before the policy pays | excess, franchise |
| Sublimit | sublimit | A cap on one category inside a coverage section | inner limit, category cap |
| Annual aggregate | annual aggregate | The maximum payable for all property losses in one policy period | annual cap, total limit |
| Named peril | named peril | A cause the policy lists as covered; anything unlisted is not covered | listed risk |
| Open peril | open peril | Covered unless an exclusion applies | all-risk |
| Endorsement | endorsement | A clause added to the policy that changes what it does | rider, addendum |
| Loss of use | loss of use | Additional living costs while the property is uninhabitable | ALE, displacement |
| Eligibility screening | eligibility screening | The early check on whether the claim is worth investigating | triage, pre-check |
| Claim review | claim review | The decision on whether the claim is payable and for how much | adjudication, final review |
Decision outcome labels (verbatim): Approve · Partial approve · Deny · Escalate Role titles (verbatim): Claimant · Independent assessor · Eligibility reviewer · Claims adjuster · Claims team lead System short names (verbatim): Claims Intake · Document Store · Policy Administration · Claims History · Correspondence · Settlements
When documents disagree, that's a finding
The seed also ships contracts/: pinned technical interfaces that keep every solution inside a testable frame. If the PDD and a contract ever seem to disagree, the contract wins for anything at a component boundary, and the disagreement is worth logging. You'll meet this again at the design gate.