diff --git a/notations/CONTRACT.md b/notations/CONTRACT.md
index b3ba68d..2a3af62 100644
--- a/notations/CONTRACT.md
+++ b/notations/CONTRACT.md
@@ -397,12 +397,13 @@ The lifecycle fields are required on every canonical primitive once a notation s
 
 `ELEM-FORMER-ID-001` ([ELEMENT_PRIMITIVES.md](../notations/ELEMENT_PRIMITIVES.md) §9) flags any `former_id` that collides with a live element `id` or another element's `former_ids` — such a collision means Phase 2 was not completed cleanly.
 
+**First-class time-aware relations.** Kinds declared in [the REL specification](elements/17-relations.md) are lifecycle-bearing files in `canon/relations/`, with independent admission and inclusive day windows contained in both endpoint lifecycles. Each host notation declares which links remain inline; there is no blanket inline-only phase. Person reporting uses `reports_to` (REL §3.4).
+
 ### 7.5 Out of scope (v1)
 
 - **Bitemporality.** No separate `transaction_time` vs `valid_time`. v1 records what is true *now* about what was true *then*; back-dating corrections rewrite the file via git, and the git history is the audit trail.
 - **Branching timelines.** Alternative futures are the concern of the Scenarios notation (`notations/views/reports/11-scenarios.md`), not of the primitive lifecycle.
 - **Sub-day precision.** ISO 8601 date precision only; no timestamps, no timezones in canon. "Today" is the date of the query or render.
-- **First-class time-aware relations.** Promoting relations like `parent` / `applies_to` / activity→goal to first-class lifecycle-bearing files is planned for Wave 3 of the temporal model. In v1 such relations remain inline and timeless on their host primitive.
 
 ---
 
diff --git a/notations/ELEMENT_PRIMITIVES.md b/notations/ELEMENT_PRIMITIVES.md
index 92934a8..e273933 100644
--- a/notations/ELEMENT_PRIMITIVES.md
+++ b/notations/ELEMENT_PRIMITIVES.md
@@ -565,6 +565,7 @@ The active-structure identity primitive — *who or what exists and performs wor
 | `external_ref` | no | string | External identifier or URL — e.g. a `system`'s integration endpoint, or an external organisation's reference. |
 
 - **Identity only.** A `person` actor is *who someone is*, independent of engagement. Employment, candidacy, alumni status, community membership, and contracting are **first-class time-aware `REL` records** ([elements/17-relations.md](elements/17-relations.md) §3), not fields here — a person can exist in the org's scope (candidate, alumnus, contractor, community member) without being an employee.
+- **Person reporting.** `reports_to` is a first-class time-aware REL from subordinate `ACTOR(person)` to manager `ACTOR(person)`, never an inline manager field. Concurrent unranked managers are valid with a repository-health warning; employment, membership and unit hierarchy imply no reporting link. See [the reporting contract and oracle](elements/17-relations.md#34-reports_to--direct-person-reporting).
 - **Org hierarchy.** A `business_unit` actor's parent unit is a time-aware `REL` of `type: unit_parent` (`ACTOR(business_unit) → ACTOR(business_unit)`), not an inline field.
 - **Role assignment.** Which `ROLE` an actor fills is carried on the relevant engagement `REL` (e.g. `employment` carries role assignments), not inline on the actor.
 
diff --git a/notations/elements/17-relations.md b/notations/elements/17-relations.md
index 910a72f..f7b7818 100644
--- a/notations/elements/17-relations.md
+++ b/notations/elements/17-relations.md
@@ -1,8 +1,8 @@
 ---
 title: "Relations — first-class time-aware links"
-version: "0.5"
+version: "0.6"
 author: "Valerii Korobeinikov"
-last_updated: "2026-09-24"
+last_updated: "2026-10-12"
 status: "draft"
 ---
 
@@ -84,6 +84,7 @@ The enum is **closed** in v1. Each value names a specific kind of link between t
 | `assessment_influences_goal` | assessment → goal | `ASSESSMENT` → `GOAL` | An assessment (a dated finding about a `DRIVER`) influences a goal — the polarity edge of the ArchiMate motivation chain *Driver → Assessment → influences(±) → Goal*. **All polarity in the motivation model lives here**, not on the assessment node (the assessment records *what is*, this REL records *how it bears on this specific intent*). **M:N**: one assessment may bear on several goals, with opposite signs (one finding can support goal A and threaten goal B — SWOT is goal-relative), and one goal is influenced by many assessments. Required `sign` attribute on the REL file: closed vocabulary `positive` \| `negative` — the direction of the influence (DSM's up/down arrows on goals). Optional `magnitude` attribute: closed vocabulary `low` \| `medium` \| `high` — the strength of the influence; omit when unknown. Each (assessment, goal) pair is its own REL file; same shared REL machinery as `goal_parent`'s multi-parent form and `target_state_satisfies_goal`, not a one-off mechanism. A finding that ceases to bear on a goal (the goal retires, or re-measurement reverses the sign) ends with `valid_to` set; a new REL file carries the new sign. |
 | `action_goal` | action → goal | `ACTION` → `GOAL` | An action serves a goal. An action re-aimed mid-stream produces a new relation. **Deprecated alias:** `activity_goal` (accepted with `ACTION-005` warning). |
 | `unit_parent` | child → parent | `ACTOR(business_unit)` → `ACTOR(business_unit)` | Organisational re-parenting — a business-unit actor moved under a different parent unit. (Was `UNIT → UNIT` before the 2026-05-29 Actors decision folded `UNIT` into `ACTOR`.) |
+| `reports_to` | subordinate → manager | `ACTOR(person)` → `ACTOR(person)` | Direct person reporting, with concurrent unranked managers permitted. Each pair/window is a separate REL; reverse retrieval uses the same records. See §3.4. |
 | `employment` | person → org | `ACTOR(person)` → `ACTOR(business_unit)` | Employment of a person by a unit / organisation. Time-aware (the employment window); carries the most attributes of the engagement kinds — `contract_type`, role assignments (`roles: [ROLE-…]`). |
 | `candidacy` | person → org | `ACTOR(person)` → `ACTOR(business_unit)` | A person under evaluation (pre-hire). Carries `stage`, `source`. |
 | `alumni_membership` | person → org | `ACTOR(person)` → `ACTOR(business_unit)` | A former employee's continuing relationship; may reference the prior `employment`. |
@@ -176,6 +177,76 @@ What it says, and what it refuses to say:
 
 ---
 
+### 3.4 `reports_to` — direct person reporting
+
+A `reports_to` REL states that the subordinate person (`from`) reports directly
+to the manager person (`to`). Both endpoints MUST resolve to independently
+admitted `ACTOR` records with `type: person`. Employment, unit membership,
+role assignment and `unit_parent` retain their existing meanings and never
+imply a reporting edge. There is no same-unit or shared-employer prerequisite.
+The relationship is binary and M:N: concurrent managers are unranked, with no
+primary/functional distinction or allocation percentage. Store no inverse kind
+and no canonical inline manager field on ACTOR; free-form `extensions:` remain
+pass-through and do not establish reporting authority.
+
+**Time and admission.** Each REL has its own admission record and required
+`valid_from` and `valid_to`. Dates are quoted ISO days; the window is inclusive
+at both ends, and null end means unbounded, not already active. Equal dates
+form a valid one-day window. The entire window MUST fit inside both endpoint
+lifecycles (`REL-003`); a null relation end cannot fit a finite endpoint end.
+Do not silently clip invalid windows. A draft REL does not become admitted
+because its actors are admitted, nor does admitting a REL admit its actors.
+
+**Identity and graph.** Resolve supported identity aliases before comparing
+endpoints or counting people. A resolved self-link is `REL-011` (error).
+`REL-012` (error) rejects a cycle, including a cycle of three or more persons,
+whose admitted, resolved reporting edges are simultaneously effective on any
+date. Validate all history by interval change points or by a nonempty common
+intersection of the cycle's edge windows and endpoint lifecycles. A union of
+historical edges is insufficient: A→B ending June 30 and B→A starting July 1
+is valid; starting the second on June 30 creates a cycle on that date. Retain
+the ordered actor path, all incident REL IDs and a witness date/overlap interval
+in the diagnostic. Traversals must terminate with a visited set; invalid data
+must not produce a fabricated hierarchy.
+
+**Direct queries at date D.** Resolve identities, require admission and valid
+contained windows, and select edges for which both endpoints and the REL are
+in effect at D. `managers(A, D)` groups matching `from=A` edges by resolved `to`;
+`directReports(B, D)` groups matching `to=B` edges by resolved `from`. Return
+deterministically ordered distinct identities with **all contributing REL IDs**
+for each pair. Listing and trace must use the same population. No transitive
+management inference is required. Zero edges means “no reporting relationship
+recorded”, not proof that the person has no manager. An unresolved/unadmitted
+endpoint produces `REL-002`; an incomplete or unreadable catalogue produces an
+explicit incomplete result, never a clean empty answer or health success.
+
+**Matrix warning and evidence.** A repository-health scan emits `REL-013`
+(warning) when a person has more than one distinct concurrently effective
+manager. Include the person, manager identities, contributing REL IDs and
+witness date/overlap window. A dated scan evaluates D; an all-history scan
+checks interval change points. This warning does not invalidate the otherwise
+valid matrix relationship. Multiple records for one resolved manager do not
+trigger it. Preserve authored evidence IDs and windows, including disjoint
+recurrence of the same pair; ingest deduplication must not discard recurrence
+merely because kind/from/to already appeared.
+
+**Specification and compatibility boundary.** The [synthetic consumer example
+and acceptance oracle](../examples/relations/reports-to/) specify expected
+results and positive/negative vectors. This is an additive MINOR contract
+change (relation spec 0.6); it allocates `REL-011`–`REL-013` under
+[diagnostic identity rules](../CONTRACT.md#187-versioned-diagnostic-identity).
+The new errors apply only to the newly introduced kind. Existing codes, meanings
+and severities are unchanged. Existing records need
+no migration. Older pinned vocabularies/validators can reject `reports_to`
+as an unknown kind; a current vocabulary loader recognizing the token is not
+proof of subtype, temporal, graph or query enforcement. The methodology release
+pin remains unchanged until release preparation; no package is released here.
+Dependent validators, ingest and query consumers must bind conformance evidence
+to the delivered specification revision and diagnostic allocation. These rules
+and example are not a claim of released or installed runtime support.
+
+---
+
 ## 4. File location and naming
 
 ```
@@ -208,6 +279,9 @@ A typical naming convention encodes the endpoints and kind in the middle segment
 | `REL-008` | warning | A cycle exists in the `process_parent` graph among admitted REL files (A is a child of B … is a child of A). Cross-cutting — fires when the catalogue is loaded. Warning rather than error because a genuine mutual embedding is unusual but not always a data error. Kind-specific, parallel to `REL-006`; that code is not widened. |
 | `REL-009` | error | A `requirement_parent` REL has identical `from` and `to`. Applies to the requirement-chain extension. |
 | `REL-010` | warning | A cycle exists in the active union of inline `REQUIREMENT.parent` and `requirement_parent` REL edges at the as-at date, including an inline self-parent. Cross-cutting; retain every incident cycle edge and terminate traversal. Applies to the requirement-chain extension; does not widen `REL-006` or `REL-008`. |
+| `REL-011` | error | A `reports_to` REL resolves both endpoints to the same person, including supported identity aliases. Report the REL ID and resolved person ID. |
+| `REL-012` | error | A cycle of admitted `reports_to` edges is simultaneously effective on some date, including 3+ person cycles. Report the ordered actor path, incident REL IDs and witness date/overlap interval (§3.4). |
+| `REL-013` | warning | A repository-health scan finds more than one distinct concurrently effective manager for a person. Report identities, contributing REL IDs and witness date/window; duplicate evidence for one manager does not trigger this warning (§3.4). |
 
 For the requirement-chain extension, inline `parent`/`serves` and active matching
 REL records form an additive union. An identical pair is one logical edge with
diff --git a/notations/elements/19-actors.md b/notations/elements/19-actors.md
index 4a50230..3a6f4ab 100644
--- a/notations/elements/19-actors.md
+++ b/notations/elements/19-actors.md
@@ -1,8 +1,8 @@
 ---
 title: "Actors — active-structure identity primitive"
-version: "0.1"
+version: "0.2"
 author: "Valerii Korobeinikov"
-last_updated: "2026-05-29"
+last_updated: "2026-10-12"
 status: "draft"
 ---
 
@@ -102,12 +102,17 @@ All of an actor's links are first-class, time-aware `REL` records ([17-relations
 | Relation `type` | From → To | What it records |
 |---|---|---|
 | `unit_parent` | `ACTOR(business_unit)` → `ACTOR(business_unit)` | Org hierarchy — a unit's parent unit. Re-parenting = one ended relation + one new. |
+| `reports_to` | `ACTOR(person)` → `ACTOR(person)` | Direct subordinate → manager; concurrent unranked managers are valid with a health warning. See [reporting contract](17-relations.md#34-reports_to--direct-person-reporting). |
 | `employment` | `ACTOR(person)` → `ACTOR(business_unit)` | Employment window; carries `contract_type` and role assignments (`roles: [ROLE-…]`). |
 | `candidacy` | `ACTOR(person)` → `ACTOR(business_unit)` | Pre-hire evaluation; carries `stage`, `source`. |
 | `alumni_membership` | `ACTOR(person)` → `ACTOR(business_unit)` | Former-employee relationship; may reference the prior `employment`. |
 | `community_membership` | `ACTOR(person)` → `ACTOR(business_unit)` | Membership of a community modelled as a `business_unit` actor. |
 | `contracting` | `ACTOR(person\|business_unit)` → `ACTOR(business_unit)` | Contracting relationship; carries `contract_terms`. |
 
+Reporting is independent of employment and unit hierarchy; neither implies a manager.
+Use a separate REL for each pair/window, preserving recurrence. Do not interpret
+free-form `extensions:` as canonical reporting fields or reject their pass-through.
+
 Action ownership references an actor by ID: an action's `owner: ACTOR-…` ([07-action.md](../views/diagrams/07-action.md) §5.6). The Stakeholders notation references an actor for identity (`STAKEHOLDER.actor: ACTOR-…`, REQUIRED) — a stakeholder carries the stake, never the identity.
 
 ---
@@ -130,7 +135,7 @@ A flat catalogue listing (`*.actors.transitrix.yaml`) is an optional **view** ov
 |---|---|---|
 | `ACTOR-001` | error | `id` missing or not matching `ACTOR-[<middle>-]<INTEGER>` ([IDS_AND_REFERENCES.md](../IDS_AND_REFERENCES.md) §1); or a required field (`notation`, `name`, `type`, `zone`, `admitted_at`, `admitted_by`, `gate_checks`, `valid_from`, `valid_to`) is missing. |
 | `ACTOR-002` | error | `type` is not one of `person`, `business_unit`, `system`. |
-| `ACTOR-003` | error | An engagement / hierarchy field (`employment`, `unit_parent`, `roles`, `owner`, …) is present inline on the actor file — these belong in `REL-…` files (`REL-004`), not on the identity primitive. |
+| `ACTOR-003` | error | An engagement / hierarchy field (`employment`, `unit_parent`, `reports_to`, `manager`, `roles`, `owner`, …) is present inline on the actor file — these belong in `REL-…` files (`REL-004`), not on the identity primitive. |
 
 The shared header (`HDR-001..004`, [CONTRACT.md](../CONTRACT.md) §2) and primitive-lifecycle (`LIFECYCLE-001..004`, [CONTRACT.md](../CONTRACT.md) §7.3) rules apply to ACTOR files in addition to the ACTOR-* rules above.
 
diff --git a/notations/examples/relations/reports-to/README.md b/notations/examples/relations/reports-to/README.md
new file mode 100644
index 0000000..6bdbba7
--- /dev/null
+++ b/notations/examples/relations/reports-to/README.md
@@ -0,0 +1,93 @@
+# Direct person reporting — synthetic specification example
+
+This catalogue illustrates [`reports_to`](../../../elements/17-relations.md#34-reports_to--direct-person-reporting).
+Every person, admission and relationship is synthetic. Consumers can load the
+six YAML records under `canon/` without reconstructing a model from prose.
+The oracle below is also the expected-result contract for consumer tests.
+It specifies behavior; it does **not** claim an available reporting query CLI,
+released validator support, or that the current generic listing and trace
+implementations enforce this contract. The existing `7.0.0` manifest pin is
+unchanged; use the vocabulary at the specification revision containing this
+example. An older artifact at that pin can reject the added kind. Record the
+exact specification revision and consumer version when testing conformance.
+
+## Records and dated oracle
+
+A, B and C abbreviate `ACTOR-SYN-A-1`, `ACTOR-SYN-B-1` and `ACTOR-SYN-C-1`.
+R1, R2 and R3 abbreviate `REL-SYN-REPORTING-1`, `REL-SYN-REPORTING-2` and
+`REL-SYN-REPORTING-3`. All actors are admitted persons effective from January 1,
+2026 with no end. Each relation is independently admitted.
+
+| REL | Pair | Inclusive window |
+|---|---|---|
+| R1 | A → B | 2026-01-01 through 2026-06-30 |
+| R2 | A → C | 2026-06-01 through unbounded |
+| R3 | A → B | 2026-08-01 through unbounded |
+
+Reproduce each row by selecting admitted, resolved `reports_to` records whose
+window contains D and fits both active endpoint lifecycles. Group by resolved
+person identity, keep all contributing REL IDs, and sort identities and IDs.
+Reverse lookup selects the same records by `to`; it stores no inverse REL.
+These are direct queries, with no inferred or transitive management links.
+
+| D | managers(A), with evidence | directReports(B), with evidence | directReports(C), with evidence | Health |
+|---|---|---|---|---|
+| 2026-05-31 | B: [R1] | A: [R1] | empty | No reporting warning |
+| 2026-06-01 | B: [R1], C: [R2] | A: [R1] | A: [R2] | REL-013 warning |
+| 2026-06-15 | B: [R1], C: [R2] | A: [R1] | A: [R2] | REL-013 warning |
+| 2026-06-30 | B: [R1], C: [R2] | A: [R1] | A: [R2] | REL-013 warning |
+| 2026-07-01 | C: [R2] | empty | A: [R2] | No reporting warning |
+| 2026-08-01 | B: [R3], C: [R2] | A: [R3] | A: [R2] | REL-013 warning |
+
+`managers(B)`, `managers(C)` and `directReports(A)` are empty on these dates.
+Empty means no reporting relationship recorded. The matrix remains valid when
+REL-013 fires. An all-history health scan finds overlap windows June 1–30 and
+August 1 onward. R3 is recurrence, not a duplicate to discard during ingestion.
+
+For the duplicate-evidence control, copy R1 to a distinct R4 with the same pair
+and window. On May 31, managers(A) is B with [R1, R4] and **no REL-013**. On June
+15 it is B with [R1, R4] and C with [R2], with REL-013 for two people, not three
+records. Reverse evidence agrees. Supported aliases of B still count as B.
+
+## Acceptance vectors
+
+Apply each mutation independently to the base catalogue, retaining full
+admission and lifecycle records unless the vector explicitly changes them.
+Diagnostics retain field/endpoint context; graph failures retain incident
+records. These are normative expectations for dependent mechanical tests,
+not results from a runtime validator supplied by this example.
+
+| Vector | Expected result |
+|---|---|
+| Base matrix; optionally B→C while A→B and A→C hold | Valid matrix DAG. Multiple managers alone is not a cycle; health emits REL-013 for A. |
+| Each endpoint separately changed to an admitted ACTOR(business_unit), ACTOR(system), or ROLE | REL-002 error with REL ID, endpoint field, referenced ID and expected/actual TYPE/subtype. ACTOR ID grammar alone is insufficient. |
+| Each endpoint separately unknown or unadmitted | REL-002 error with unresolved/unadmitted reason. No valid pair may use it. |
+| Unreadable file or incomplete catalogue | Explicit incomplete result and diagnostics, never clean health or a definitive empty report. Preserve any partial-result qualification. |
+| `to: [B, C]` (using full IDs), or another wrong field shape | SCHEMA_INVALID with field context; use separate binary records for a matrix. |
+| Missing/malformed `from` or `to`; missing/unknown `type` | REL-002 for endpoint defects; REL-001 for missing/unknown kind. Structural schema errors retain field context. |
+| A→A; A→supported alias resolving to A | REL-011 error, naming relation and resolved person. No self-link disguised by aliases. |
+| Add B→C and C→A during June | REL-012 error for A→B→C→A, with ordered actor path, incident REL IDs and an effective witness date/window. |
+| Isolate A→B ending June 30 and B→A starting July 1 | Valid disjoint history; no REL-012. Historical union alone must not trigger a cycle. |
+| Same two edges, second starts June 30 | REL-012 error with June 30 witness. Both boundaries are inclusive. |
+| Relation start=end June 15 | Valid one-day link, present June 15 and absent June 14/16. |
+| Future start with null end; expired end | Excluded before start or after end; null does not override start. Historical query inside the window includes the link. |
+| Missing/invalid start; invalid end; end before start | LIFECYCLE-001/002/003 retain their respective meanings. Missing required `valid_to` produces SCHEMA_INVALID with field context. Equal dates remain valid. |
+| Relation starts before either endpoint, ends after either endpoint, or null end with finite endpoint end | REL-003 error identifying endpoint and out-of-bounds interval. No clipping. Repeat for each endpoint independently. |
+| Relation bounds exactly equal to both endpoint bounds | Valid containment, including both boundary days. |
+| Draft/unadmitted REL between admitted actors | No reporting claim. Endpoint admission does not admit the relation; admission diagnostics remain applicable. |
+| Admitted REL to a draft actor; future/expired actor at D | Unadmitted endpoint is REL-002; an inactive endpoint contributes no pair. Containment violations remain REL-003. |
+| Same pair in disjoint windows, including R1 and R3 | Preserve both identities and windows. Ingestion must retain recurrence; no evidence from an inactive window contributes at D. |
+| Overlapping same-pair evidence, including aliases of one manager | One logical pair with every contributing REL ID; no multi-manager warning from duplicates alone. |
+| Canonical inline `manager` or `reports_to` on ACTOR | ACTOR-003/REL-004 with field context and instruction to author a REL. Arbitrary `extensions:` retain EXT-001 pass-through and confer no reporting authority. |
+| Existing employment person→unit with roles; unit_parent unit→unit | Existing meaning, validation and temporal queries unchanged; no reporting inferred. Person→person employment and person endpoints on unit_parent remain invalid. |
+| No employment, same-unit, or shared-employer record | Valid person→person reporting; these are not prerequisites. |
+| Draft, future, expired, malformed or unresolved records in views | No fabricated valid reporting claim. Listing and trace agree at the same date; errors and incomplete populations remain visible. |
+
+`REL-011` (self-link error), `REL-012` (temporal-cycle error), and `REL-013`
+(multi-manager warning) are newly allocated identities. Existing diagnostics
+keep their meanings/severities and stored history under
+[CONTRACT §18.7](../../../CONTRACT.md#187-versioned-diagnostic-identity).
+The additive vocabulary/specification change requires a MINOR release when
+packaged; this example does not release, install or certify a consumer. Older
+pinned validators may reject `reports_to`; token recognition alone does not
+satisfy these acceptance vectors. Core ingestion coverage is unchanged.
diff --git a/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-A-1.yaml b/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-A-1.yaml
new file mode 100644
index 0000000..1d7526d
--- /dev/null
+++ b/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-A-1.yaml
@@ -0,0 +1,14 @@
+notation: actor
+id: ACTOR-SYN-A-1
+name: "Synthetic Person A"
+type: person
+zone: canon
+example: true
+admitted_at: "2026-01-01"
+admitted_by: synthetic-example
+gate_checks:
+  uniqueness: pass
+  consistency: pass
+  completeness: pass
+valid_from: "2026-01-01"
+valid_to: null
diff --git a/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-B-1.yaml b/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-B-1.yaml
new file mode 100644
index 0000000..d659830
--- /dev/null
+++ b/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-B-1.yaml
@@ -0,0 +1,14 @@
+notation: actor
+id: ACTOR-SYN-B-1
+name: "Synthetic Person B"
+type: person
+zone: canon
+example: true
+admitted_at: "2026-01-01"
+admitted_by: synthetic-example
+gate_checks:
+  uniqueness: pass
+  consistency: pass
+  completeness: pass
+valid_from: "2026-01-01"
+valid_to: null
diff --git a/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-C-1.yaml b/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-C-1.yaml
new file mode 100644
index 0000000..a9d2428
--- /dev/null
+++ b/notations/examples/relations/reports-to/canon/elements/02_business/actors/ACTOR-SYN-C-1.yaml
@@ -0,0 +1,14 @@
+notation: actor
+id: ACTOR-SYN-C-1
+name: "Synthetic Person C"
+type: person
+zone: canon
+example: true
+admitted_at: "2026-01-01"
+admitted_by: synthetic-example
+gate_checks:
+  uniqueness: pass
+  consistency: pass
+  completeness: pass
+valid_from: "2026-01-01"
+valid_to: null
diff --git a/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-1.yaml b/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-1.yaml
new file mode 100644
index 0000000..08e20e6
--- /dev/null
+++ b/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-1.yaml
@@ -0,0 +1,15 @@
+notation: relation
+id: REL-SYN-REPORTING-1
+type: reports_to
+from: ACTOR-SYN-A-1
+to: ACTOR-SYN-B-1
+zone: canon
+example: true
+admitted_at: "2026-01-01"
+admitted_by: synthetic-example
+gate_checks:
+  uniqueness: pass
+  consistency: pass
+  completeness: pass
+valid_from: "2026-01-01"
+valid_to: "2026-06-30"
diff --git a/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-2.yaml b/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-2.yaml
new file mode 100644
index 0000000..f8cfc7e
--- /dev/null
+++ b/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-2.yaml
@@ -0,0 +1,15 @@
+notation: relation
+id: REL-SYN-REPORTING-2
+type: reports_to
+from: ACTOR-SYN-A-1
+to: ACTOR-SYN-C-1
+zone: canon
+example: true
+admitted_at: "2026-01-01"
+admitted_by: synthetic-example
+gate_checks:
+  uniqueness: pass
+  consistency: pass
+  completeness: pass
+valid_from: "2026-06-01"
+valid_to: null
diff --git a/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-3.yaml b/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-3.yaml
new file mode 100644
index 0000000..ee2f316
--- /dev/null
+++ b/notations/examples/relations/reports-to/canon/relations/REL-SYN-REPORTING-3.yaml
@@ -0,0 +1,15 @@
+notation: relation
+id: REL-SYN-REPORTING-3
+type: reports_to
+from: ACTOR-SYN-A-1
+to: ACTOR-SYN-B-1
+zone: canon
+example: true
+admitted_at: "2026-01-01"
+admitted_by: synthetic-example
+gate_checks:
+  uniqueness: pass
+  consistency: pass
+  completeness: pass
+valid_from: "2026-08-01"
+valid_to: null
diff --git a/notations/examples/relations/reports-to/transitrix.yaml b/notations/examples/relations/reports-to/transitrix.yaml
new file mode 100644
index 0000000..395a652
--- /dev/null
+++ b/notations/examples/relations/reports-to/transitrix.yaml
@@ -0,0 +1,6 @@
+# Self-contained synthetic catalogue; see README.md for compatibility limits.
+transitrix: 1
+methodology_version: "7.0.0"
+notations: [actor, relation]
+zones: [canon]
+coverage_profile: core
diff --git a/notations/vocabulary.yaml b/notations/vocabulary.yaml
index 06e20f1..8c2c868 100644
--- a/notations/vocabulary.yaml
+++ b/notations/vocabulary.yaml
@@ -317,6 +317,11 @@ relation_types:
     from_subtype: [business_unit]
     to: [ACTOR]
     to_subtype: [business_unit]
+  reports_to:
+    from: [ACTOR]
+    from_subtype: [person]
+    to: [ACTOR]
+    to_subtype: [person]
   employment:
     from: [ACTOR]
     from_subtype: [person]
@@ -1391,6 +1396,15 @@ rule_codes:
   REL-010:
     severity: warning
     spec: notations/elements/17-relations.md
+  REL-011:
+    severity: error
+    spec: notations/elements/17-relations.md
+  REL-012:
+    severity: error
+    spec: notations/elements/17-relations.md
+  REL-013:
+    severity: warning
+    spec: notations/elements/17-relations.md
   REQ-PARENT-001:
     severity: error
     spec: notations/elements/15-requirement.md