A role-change label is a starting point for research. It is not a complete account of what happened, how recently it happened, or what action someone should take.
This walkthrough uses the canonical fictional Forma Labs signal: “A new sales leader.” Its supplied detail is: “Maya moved from Sales Director to VP Sales in this fictional scenario.” Maya Chen’s current fixture role is VP Sales. No date, external source, verified reporting relationship, or production monitoring result accompanies that scenario.
The output is a bounded interpretation and a review worksheet. This guide teaches event interpretation through a fictional example; it does not describe an active monitoring or alert feed.
1. State the claim without enlarging it
Start with the person, company and exact change described. Here, the claim is a fictional role transition for Maya at Forma Labs, forma.example. The prior role is Sales Director; the current role is VP Sales.
That supports a demonstration of a role-change record. It does not establish when Maya joined Forma Labs, whether this was an internal promotion in a real company, whether the title is current outside the fixture, or whether her responsibilities include your product category.
Keep the scenario label attached when writing a brief or passing the record to an agent. An attractive summary should not turn an illustration into a sourced announcement.
2. Resolve the subject before reviewing the change
Check that the person and company are the intended entities. A name alone is not enough to join two observations. Someone may hold multiple roles, share a name, or be associated with more than one organization.
In our exercise, the fixture links Maya to Forma Labs by the reserved company domain. The proposed data model keeps person, role and membership separate, using illustrative local IDs only to explain the joins. Those IDs are not live identifiers or an instruction to call an API.
For a real review, record identity ambiguity before deciding whether two titles describe a transition. If the subject cannot be resolved, keep the change unresolved instead of borrowing the strongest-looking match.
3. Keep the three clocks separate
Three dates would answer different questions. All three remain unknown in this example:
| Clock | Question | Worked-example value |
|---|---|---|
event_at |
When did the role change take effect? | Not supplied |
observed_at |
When did a system observe supporting evidence? | No external observation occurred |
verified_at |
When was the claim checked against its evidence? | No production verification occurred |
A page retrieved today might describe an older move. A review performed today would date the review, not the promotion. A claimed refresh schedule would not fill in the event’s effective date. Do not replace an absent clock with the current time merely to satisfy a required spreadsheet column.
In the proposed JSON examples, these fields are null. In the downloadable CSV, they are blank and explicitly described as not supplied. Neither representation means the event never happened; it means this fixture provides no value. A released interface would need a documented timestamp format, precision and policy before applications could depend on it.
4. Choose the conclusion the evidence allows
Review the claim’s impact separately from its existence:
| Question | Decision for this fictional example | What would need review next |
|---|---|---|
| What is the current supplied role? | VP Sales | The fixture is illustrative, not independently verified. |
| What previous role does the signal name? | Sales Director | Preserve the exact statement rather than expanding its history. |
| Is the promotion recent? | Unknown | An attributable effective date. |
| Did Maya’s manager change? | Unknown | Evidence for the specific reporting edge. |
| Is Forma Labs now buying? | Not established | A relevant need and its own evidence. |
| Should an automated action run? | No action follows from this preview | A defined workflow, sufficient evidence and an explicit review decision. |
A role change and a reporting-line change are separate facts. Seniority does not establish budget ownership. This is why the org-chart example leaves Maya’s manager unknown even though the role-change illustration exists.
5. Produce a bounded research note
A useful note would read:
The fictional scenario changes Maya Chen’s role at Forma Labs from Sales Director to VP Sales. The effective date, observation date and verification date are not supplied. Reporting relationships and buying intent are unknown. Before using a comparable real signal, resolve the person/company match and inspect the source and chronology.
An agent can help organize the supplied information, but it should return unknowns rather than manufacture dates or infer an executive’s priorities. Keep the original signal detail available beside the note so another reviewer can check that the summary did not add a claim.
6. Use the worksheet for the next review
Download the role-change worksheet. It separates the supplied current/prior roles from timing, manager and intent questions. It repeats no invented timestamp and provides blank source, clock and owner fields for your own review.
Review one claim per row. Record the next verification action, then add evidence only when it supports that claim. If sources disagree, keep the conflicting observations rather than replacing the old role without explanation. A future correction should remain distinguishable from the original observation.
The signals page separately shows a proposed hiring-event concept; a listing is not proof of a hire. Use the account/org mapping guide to review the relationship context and the field-provenance guide to preserve the evidence behind each field. No monitoring or outreach runs when you use these worksheets.