Broker Earnings Simulator: Candidate Context and Disclaimer
A broker simulator for recruitment should be framed as a context builder, not as a live calculator or a prediction tool. Its strongest version lets a candidate edit market-context fields, see clear labels beside every input, and understand which entries need manual review before discussion. The specification should separate user-entered assumptions from NAHY-reviewed notes, keep all labels visible, and avoid presenting any calculated personal projection. The disclaimer should be direct: the simulator is for discussion context only, does not forecast personal outcomes, and does not create a commitment. A useful version helps both sides talk about assumptions clearly without turning those assumptions into a promise.
Updated: 29 August 2026
Editable market-context fields
Fields should be treated as assumptions that a user may adjust for discussion.
N/A — practical guidance only
N/A
Visible labels
Every field should show whether it is user-entered, NAHY-reviewed, or pending review.
N/A — practical guidance only
N/A
Manual review
Marked fields should be checked by a person before being used in a role discussion.
N/A — practical guidance only
N/A
No-forecast disclaimer
The interface should state that outputs are discussion context only and not a prediction.
N/A — practical guidance only
N/A
Editable market-context fields for a responsible simulator
The simulator specification should start with fields that describe assumptions rather than conclusions. A useful field set can include transaction type, property category, deal stage, personal operating style, office support preference, activity mix, and split-structure notes. Each field should have a short help text explaining what the user is choosing, why the choice matters for conversation, and whether the entry is a personal assumption or a point to be reviewed later. The purpose is to make the candidate’s thinking visible without converting it into a fixed outcome.
A strong field design should avoid defaulting the user into a single story. For example, transaction type can be handled as a selectable context, not as a claim about what a person will handle. Property category can be grouped in broad labels rather than narrow promises. Deal stage can be described as “early conversation,” “active viewing,” “offer discussion,” or “closing support” if those labels are used as internal workflow descriptors, not as claims about availability. The interface should make it easy to clear a field, reset a section, and mark an assumption as “unknown” instead of forcing a confident entry.
The field sequence should also reduce misunderstanding. Start with identity-neutral context, then move into activity preferences, then support preferences, then review notes. A decision sequence can look like this: choose the broad scenario; identify which assumptions are user-entered; mark uncertain items; add optional notes; send the scenario for manual review; discuss the reviewed version with NAHY. This order helps prevent a user from treating early entries as final, while still giving enough structure for a practical conversation.
The specification should include validation that protects clarity rather than producing a number. For example, a required field can block submission only when the next step needs context, not because the tool is trying to force a calculation. Optional fields should remain optional. Error messages should be plain: “Select a context before review,” “Choose unknown if you are not sure,” or “This field needs a label.” These messages keep the workflow understandable without creating a sense that the simulator has produced a verified answer.
Source labels, review states, and interface wording
The most important visual rule is that every assumption needs a label. The label should sit close to the field, not hidden in a tooltip. Suggested labels include “User-entered,” “NAHY-reviewed,” “Pending review,” “Cleared by user,” and “Discussion note.” These labels are not decorative. They help the candidate see what came from their own input, what has been checked during a conversation, and what still needs attention before the scenario is used as a discussion reference.
The review state should be separate from the field value. A field can contain a user’s assumption while still being pending review. Another field can be empty but marked as intentionally skipped. A third can be reviewed but still open for discussion. This separation prevents the interface from making a field look more certain than it is. It also gives NAHY a clean way to discuss context without overwriting the candidate’s original thinking too early.
Interface wording should be direct and calm. Use “Review requested” instead of “approved,” “Discuss with NAHY” instead of “confirmed,” and “Context only” instead of “final.” Avoid labels that sound like a decision has already been made. The simulator should not rank candidate scenarios, score a person, or display success-style badges. A recruitment utility is strongest when it supports a clear conversation, not when it tries to dramatise the pathway.
Manual review should have defined steps. First, check that each field has a source label. Second, identify assumptions that need clarification. Third, add a review note without deleting the original entry. Fourth, mark the scenario as reviewed only for conversation context. Fifth, keep the no-forecast disclaimer visible on the reviewed view. This process gives both the candidate and NAHY a shared reference point while preserving the difference between an assumption and a reviewed discussion note.
Candidate decision flow and no-forecast disclaimer
The candidate-facing flow should be short enough to complete without confusion, but detailed enough to support a meaningful conversation. A clear flow can be: read the disclaimer; choose the scenario context; enter assumptions; mark uncertain items; review the summary; request manual review; discuss with NAHY. The summary screen should highlight unanswered items, pending-review labels, and the disclaimer before any next step. If the candidate changes an assumption later, the review state should return to pending review for that field.
The no-forecast disclaimer should be visible at the beginning, near the summary, and before any review request. A concise version can say: “This simulator is for discussion context only. It does not predict personal outcomes, does not create a commitment, and should be reviewed with NAHY before being used in a role conversation.” The wording should be repeated consistently so the user does not see one version on the first screen and a softer version later.
The specification should distinguish three types of content: editable assumptions, review notes, and discussion prompts. Editable assumptions belong to the user. Review notes belong to the reviewer. Discussion prompts belong to the conversation and should invite clarification, such as “Which context best reflects your current focus?” or “Which assumptions should be discussed first?” This distinction helps the interface stay transparent and prevents notes from being mistaken for personal guarantees.
A responsible final screen should not present a celebratory conclusion. It should show the selected assumptions, their labels, review status, and recommended discussion order. A useful discussion order might group open questions first, then reviewed context, then next conversation topics. The final action should be a request for human follow-up, not a simulated verdict. That keeps the experience practical, fair, and aligned with the stated disclaimer.
Is this a live calculator?
No. It is a specification for a broker simulator that organises editable assumptions, labels, review status, and discussion notes.
Should the simulator make a forecast?
No. The disclaimer should state that the simulator is for discussion context only and does not predict personal outcomes.
Which fields should be editable?
Editable fields should cover scenario context, activity preferences, support preferences, uncertainty markers, and optional notes for manual review.
Who should review a submitted scenario?
A person from NAHY should review labelled fields, clarify uncertain entries, and add discussion notes before using the scenario in conversation.
How should labels appear?
Labels should appear beside each field and show whether the entry is user-entered, NAHY-reviewed, pending review, cleared, or added as a discussion note.
Updated: 29 August 2026
By NAHY Team
| Context item | Specification decision | Source name | Date |
|---|---|---|---|
| Editable market-context fields | Fields should be treated as assumptions that a user may adjust for discussion. | N/A — practical guidance only | N/A |
| Visible labels | Every field should show whether it is user-entered, NAHY-reviewed, or pending review. | N/A — practical guidance only | N/A |
| Manual review | Marked fields should be checked by a person before being used in a role discussion. | N/A — practical guidance only | N/A |
| No-forecast disclaimer | The interface should state that outputs are discussion context only and not a prediction. | N/A — practical guidance only | N/A |
Editable market-context fields for a responsible simulator
The simulator specification should start with fields that describe assumptions rather than conclusions. A useful field set can include transaction type, property category, deal stage, personal operating style, office support preference, activity mix, and split-structure notes. Each field should have a short help text explaining what the user is choosing, why the choice matters for conversation, and whether the entry is a personal assumption or a point to be reviewed later. The purpose is to make the candidate’s thinking visible without converting it into a fixed outcome.
A strong field design should avoid defaulting the user into a single story. For example, transaction type can be handled as a selectable context, not as a claim about what a person will handle. Property category can be grouped in broad labels rather than narrow promises. Deal stage can be described as “early conversation,” “active viewing,” “offer discussion,” or “closing support” if those labels are used as internal workflow descriptors, not as claims about availability. The interface should make it easy to clear a field, reset a section, and mark an assumption as “unknown” instead of forcing a confident entry.
The field sequence should also reduce misunderstanding. Start with identity-neutral context, then move into activity preferences, then support preferences, then review notes. A decision sequence can look like this: choose the broad scenario; identify which assumptions are user-entered; mark uncertain items; add optional notes; send the scenario for manual review; discuss the reviewed version with NAHY. This order helps prevent a user from treating early entries as final, while still giving enough structure for a practical conversation.
The specification should include validation that protects clarity rather than producing a number. For example, a required field can block submission only when the next step needs context, not because the tool is trying to force a calculation. Optional fields should remain optional. Error messages should be plain: “Select a context before review,” “Choose unknown if you are not sure,” or “This field needs a label.” These messages keep the workflow understandable without creating a sense that the simulator has produced a verified answer.
Source labels, review states, and interface wording
The most important visual rule is that every assumption needs a label. The label should sit close to the field, not hidden in a tooltip. Suggested labels include “User-entered,” “NAHY-reviewed,” “Pending review,” “Cleared by user,” and “Discussion note.” These labels are not decorative. They help the candidate see what came from their own input, what has been checked during a conversation, and what still needs attention before the scenario is used as a discussion reference.
The review state should be separate from the field value. A field can contain a user’s assumption while still being pending review. Another field can be empty but marked as intentionally skipped. A third can be reviewed but still open for discussion. This separation prevents the interface from making a field look more certain than it is. It also gives NAHY a clean way to discuss context without overwriting the candidate’s original thinking too early.
Interface wording should be direct and calm. Use “Review requested” instead of “approved,” “Discuss with NAHY” instead of “confirmed,” and “Context only” instead of “final.” Avoid labels that sound like a decision has already been made. The simulator should not rank candidate scenarios, score a person, or display success-style badges. A recruitment utility is strongest when it supports a clear conversation, not when it tries to dramatise the pathway.
Manual review should have defined steps. First, check that each field has a source label. Second, identify assumptions that need clarification. Third, add a review note without deleting the original entry. Fourth, mark the scenario as reviewed only for conversation context. Fifth, keep the no-forecast disclaimer visible on the reviewed view. This process gives both the candidate and NAHY a shared reference point while preserving the difference between an assumption and a reviewed discussion note.
Candidate decision flow and no-forecast disclaimer
The candidate-facing flow should be short enough to complete without confusion, but detailed enough to support a meaningful conversation. A clear flow can be: read the disclaimer; choose the scenario context; enter assumptions; mark uncertain items; review the summary; request manual review; discuss with NAHY. The summary screen should highlight unanswered items, pending-review labels, and the disclaimer before any next step. If the candidate changes an assumption later, the review state should return to pending review for that field.
The no-forecast disclaimer should be visible at the beginning, near the summary, and before any review request. A concise version can say: “This simulator is for discussion context only. It does not predict personal outcomes, does not create a commitment, and should be reviewed with NAHY before being used in a role conversation.” The wording should be repeated consistently so the user does not see one version on the first screen and a softer version later.
The specification should distinguish three types of content: editable assumptions, review notes, and discussion prompts. Editable assumptions belong to the user. Review notes belong to the reviewer. Discussion prompts belong to the conversation and should invite clarification, such as “Which context best reflects your current focus?” or “Which assumptions should be discussed first?” This distinction helps the interface stay transparent and prevents notes from being mistaken for personal guarantees.
A responsible final screen should not present a celebratory conclusion. It should show the selected assumptions, their labels, review status, and recommended discussion order. A useful discussion order might group open questions first, then reviewed context, then next conversation topics. The final action should be a request for human follow-up, not a simulated verdict. That keeps the experience practical, fair, and aligned with the stated disclaimer.
Illustrative calculator
Model a share using your own inputs
Enter an amount and a percentage only to understand the arithmetic. This tool does not state a market rate, a NAHY term, a personal outcome or a job offer.
Individual terms are discussed in your interview.
Candidate questions
Is this a live calculator?
No. It is a specification for a broker simulator that organises editable assumptions, labels, review status, and discussion notes.
Should the simulator make a forecast?
No. The disclaimer should state that the simulator is for discussion context only and does not predict personal outcomes.
Which fields should be editable?
Editable fields should cover scenario context, activity preferences, support preferences, uncertainty markers, and optional notes for manual review.
Who should review a submitted scenario?
A person from NAHY should review labelled fields, clarify uncertain entries, and add discussion notes before using the scenario in conversation.
How should labels appear?
Labels should appear beside each field and show whether the entry is user-entered, NAHY-reviewed, pending review, cleared, or added as a discussion note.