diff --git a/dev-docs/ARCH-FORM-BUILDER.md b/dev-docs/ARCH-FORM-BUILDER.md
index f6d72131..6d190f11 100644
--- a/dev-docs/ARCH-FORM-BUILDER.md
+++ b/dev-docs/ARCH-FORM-BUILDER.md
@@ -347,18 +347,31 @@ company-type (supplier/partner/etc.), KvK-nummer, BTW-nummer.
 **Who creates:** org-level schema (one per org), seeded from
 `ArtistAdvanceDefault`. Schema has `section_level_submit=true`.
 
-**Who submits:** artist via portal_token (no authentication required).
+**Who submits:** tour manager / artist representative via the
+engagement's `portal_token` (RFC-TIMETABLE v0.2 §5.3) — no
+authentication required.
+
+**Section model:** `advance_sections` rows are scoped to
+`engagement_id` (per-event), not to `artist_id` (master). One master
+artist with two engagements (e.g. Vrijdag and Zaterdag of the same
+festival) advances each engagement on its own trajectory.
+Section-type categorisation is driven by the `AdvanceSectionType`
+enum (see RFC v0.2 §10 + `App\Enums\Artist\AdvanceSectionType` —
+`guest_list | contacts | production | custom`). Section labels
+live in `advance_sections.name` (string 80). Default-section seeds
+are defined in Session 3 (`ArtistAdvanceDefault`).
 
 **Submission flow:**
-1. Artist receives email with portal link (triggered by organiser)
-2. Opens link → token resolved, submission fetched or created
-3. Form shown with sections: General Info, Contacts, Production (power,
-   catering, transport), Technical Rider, Hospitality
-4. Artist fills sections independently; each section submit separately
-5. On section submit: FormSubmissionSectionSubmitted event fires
+1. Tour manager receives email with portal link (triggered by organiser)
+2. Opens link → engagement resolved from `portal_token`, submission
+   fetched or created with the master `Artist` as subject (see §17.3)
+3. Form shown with the engagement's `advance_sections`
+4. Sections are filled independently; each section submits separately
+5. On section submit: `FormSubmissionSectionSubmitted` event fires
 6. Organiser reviews per section → section status approved/rejected/
    changes_requested
-7. When all sections approved: FormSubmissionSubmitted fires at submission level
+7. When all sections approved: `FormSubmissionSubmitted` fires at the
+   submission level
 8. Integration: triggers accreditation generation per ARCH-07 (future)
 
 **Mode:** draft_single.
@@ -2358,8 +2371,10 @@ support.
 | Slug | Label (NL) | Subject type | Default submission mode | Public access | Required bindings |
 |------|-----------|--------------|-------------------------|---------------|-------------------|
 | `event_registration` | Aanmelding vrijwilligers/crew | person | single | yes | `person.email`, `person.first_name`, `person.last_name` |
-| `artist_advance` | Artiest advance | artist | draft_single | no | — |
+| `artist_advance` | Artiest advance | artist | draft_single | no | — |[^artist-advance-engagement] |
 | `supplier_intake` | Leverancier intake | company | single | no | `company.name` |
+
+[^artist-advance-engagement]: *Engagement context resolution: `ArtistResolver::fromPortalToken` looks up `artist_engagements.portal_token` to find the engagement, then returns the engagement's master `Artist` as `subject`. The engagement's `event_id` populates `form_submissions.event_id` per WS-4 denormalisation. The advance-section breakdown lives per engagement (see §3.2.5 + RFC-TIMETABLE v0.2 §5.3), so multi-event artists get multi-trajectory advancing.*
 | `post_event_evaluation` | Evaluatie na afloop | person | single | no | — |
 | `incident_report` | Incident-melding | person | multiple | no | — |
 | `signature_contract` | Contract-ondertekening | user | single | no | — |