Nomination

What It Models

A nomination follows a candidate from being put forward through selection and, where applicable, an appointment vote. It records the link between a candidate’s recruitment history and the appointment that results. Decline and withdrawal preserve the record rather than remove the candidate’s history.

Identity and Attributes

The candidate can be an existing contact or a named person with an e-mail address; contact identity is needed before a slate decision can appoint them. Targets are optional beyond the required committee. Slate and appointment references preserve the causal chain without copying those records.

Relationships

A nomination may target an opening and may have a linked slate decision. A carried decision elects still-slated nominees it actually appointed. The owning recruitment service retains the links, while appointments belong to the committee module.

Invariants

Creation verifies supplied target ownership and committee eligibility. Staff edits and moves use locks and versions. Declining or withdrawing a slate changes a pending decision appropriately, and its later close excludes candidates no longer eligible for appointment.

How It Is Stored and Shared

Recruitment owns nominations and the shared review ledger and acknowledgement working records grouped here for storage coverage. Decisions writes elected nominations in its closing transaction. Queries exposes nominations. The metadata registration declares configurable fields, forms and layouts, but the value path remains unbuilt.

Open Design Questions

Contact merging preserves nominee references, leaving future slates able to name a merged-away contact. Consent notices can be skipped without recovery. No production caller starts the declared review step, and configurable nomination fields still need implementation.