Staff Module

Status: Designed. This module is part of the current design and is verified in the formal model; in the running system today its one consumer — the order’s assignee — is still carried as a plain text field. This page describes the design target.

Purpose

A Staff member represents a person (or another real-world agent) the tenant assigns work to, names on business documents, and holds accountable — the “assigned to” on a purchase order, for example.

A staff member is deliberately not a system login. Who performed an action in the system is identity and provenance, handled by the platform’s security machinery; who owns a piece of work in the business is reference data, handled here. The same person may eventually be both, and the design keeps room to link them later — but the two ideas stay separate.

Context

Staff is a leaf of the domain map: it depends on no other domain module, and today it has one client. Clients sit to the left of the servers they depend on; the arrow is a dependency the client calls.

What this module consumes:

• Nothing — Staff sits at the bottom of the module dependency chain.

What its clients consume from it:

• Orders — the order’s assignee is a staff version pin: re-pinned to the member’s current version at each draft edit (a retired member is refused), frozen with the order’s header at submission.

Main entities

The module holds one entity, kept intentionally minimal.

• Staff member — a name, unique within the tenant (two tenants can each have their own “Alex Chen”; one tenant cannot have two). The name is the identity: staff members are not renamed. Richer detail — contact information, organizational roles, a link to a system login, a shop-floor characterization (station assignment and the operational events a person generates: scans, receipts, card moves) — is future work that can be added without disturbing anything built on this.

Staff subsumes what earlier drafts called the Operator: the manufacturing-domain projection of a person who interacts with physical workflows, distinct from the platform’s User/UserAccount identity.

Like the other reference-data modules (Item, Business Affiliate), a staff member is versioned, and other modules refer to one through a version pin — a reference to the staff member as of a specific version.

Lifecycle

The shared reference-data lifecycle, in its smallest form — what is specific to staff is the omission: since the name never changes, there is nothing to update, and the operation surface is just the two ends:

A retired member can take on no new work, while everything already assigned to them stays exactly as recorded.

Notifications

None, in either direction. Staff sits at the bottom of the module dependency chain: it depends on no other domain module, and its consumers read it through version pins rather than reacting to announcements.

Operations

Action	What it does	When it is allowed
Create	Enter a staff member. Born Live. Refused if the name is already taken in the tenant.	Any time.
Delete	Retire the member — terminal; history stays readable.	While the member is Live.
Query	List and look up staff members.	Any time.

Guarantees

• Names are unique within a tenant. The same name may recur across tenants.
• The shared reference-data guarantees apply: version pins never dangle, and retirement is terminal, history-preserving, and honors existing work.

How it relates to its neighbors

• Orders — an order’s assignee is a staff version pin. While the order is a draft the pin floats (each edit re-pins the member’s current version, and assigning a retired member is refused); at submission it freezes with the rest of the order’s header, so a submitted order’s assignee reads stably no matter what happens to the staff record afterward.

Linear

• Initiative: Product / Resources / Operators (the shop-floor characterization this module subsumes)