feat(people): 재입사를 기존 Person + 새 Employment로 명시적으로 모델링 #302

Verified buyer / domain gap

Protected develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f already separates stable person_record identity from durable employment_record identity and bitemporal employment_record_version truth. That is the right foundation for rehire, but the protected People mutation boundary does not yet model rehire as its own governed employment event.

Current PostgresPeopleMutationPort.create_employment(...) accepts a new Employment for a Person after finding exactly one current candidate_worker_conversion_record for that tenant + Person. The lookup does not bind that conversion to the new Employment being created. As a result, an old/current-open candidate→worker conversion from an earlier hire can satisfy the generic precondition for a later Employment creation. The new write is then audited as ordinary employment_created; there is no durable prior-Employment reference, rehire decision/provenance, or explicit distinction between new hire and rehire.

The HRIS kernel correctly rejects overlapping exclusive Employments and allows a later exclusive Employment after the prior effective period ends, but that temporal rule alone is not rehire authority. “same Person can have another non-overlapping Employment” and “this write is an authorized rehire” are different domain statements.

This issue therefore owns a People/Employment domain increment, not a Candidate matching heuristic and not an identity-backend feature.

Domain direction

Default canonical rehire should preserve the existing person_record and create a new employment_record for the new employment relationship/contract. Prior Employment history, Assignment history, audit evidence, and bitemporal corrections remain immutable/history-preserving. Do not reactivate or rewrite the old Employment anchor merely to make the person active again.

A rehire command/result must be explicit enough to prove at least:

• tenant + existing Person identity;
• prior Employment identity being used as rehire context;
• new Employment identity/version being created;
• effective start of the new Employment;
• authoritative prior separation/termination/end-state evidence and non-overlap at the relevant business/system coordinate;
• accountable actor, purpose, controlled reason, evidence version, and human confirmation;
• whether the rehire originated from a new recruiting/candidate flow or a separately authorized direct People administration flow;
• idempotency identity and immutable audit/outbox evidence.

Do not infer rehire by name, email, date of birth, phone number, or fuzzy matching inside people_core. Matching/deduplication may produce candidate evidence, but the resulting Person binding must be an explicit governed decision before People persists rehire truth.

New Employment vs old Employment

Default: existing Person + new Employment.

A “rehire on old Employment” capability, if Orgmetra ever needs it for seasonal/special cases, is a distinct future policy and mutation contract. It must not emerge accidentally from reusing the old Employment ID or reopening history. It would require its own invariants for contract continuity, downstream references, effective/system time, audit, payroll/integration consequences, and correction semantics.

This distinction is also consistent with current SAP SuccessFactors product guidance: SAP documents both old- and new-employment rehire, states that new-employment rehire adds a new Employment to the existing Person while preserving Person-level identity, and recommends new Employment wherever possible; separate rehire verification asks an administrator to decide whether a potential former-employee match is actually a rehire or a new hire. This is vendor precedent, not a normative Orgmetra standard or legal rule.

Current primary vendor references checked 2026-09-12:

• SAP Help, Rehire with New and Old Employments: https://help.sap.com/docs/successfactors-onboarding/implementing-onboarding/rehire-with-new-and-old-employments
• SAP Help, Recommended Practices for Employee Master Data Replication: https://help.sap.com/docs/SAP_SUCCESSFACTORS_EMPLOYEE_CENTRAL_PAYROLL/185f14fbe60d4bbb8d7d5e4f8d89b24b/f6d617b220da403c8d427b3532e85902.html
• SAP Best Practices 1H 2026, Perform Second Rehire Verification: https://help.sap.com/docs/successfactors-onboarding/manage-onboarding-initiated-from-recruiting-test-script/perform-second-rehire-verification-optional?version=2605
• SAP Help, rehire target-population/configuration guidance, last updated 2026-08-14: https://help.sap.com/docs/successfactors-onboarding/implementing-onboarding/enabling-rehire-with-new-and-rehire-on-old-employments

DDD / ownership

Canonical owner is the existing People/Employment mutation owner (#64 or its normally integrated verified successor).

• people_core owns Person/Employment/Rehire truth and the new Employment transaction.
• talent_acquisition may own a new application/candidate, matching/review evidence, and a new hire/rehire selection decision. People consumes only a released/versioned decision/reference contract; no cross-service application SQL.
• Keyverse remains identity/authz backend; authentication identity is not person_record or Employment truth.
• Organization/Position/Assignment ownership does not move. A rehire may later create Assignments through released People/Organization contracts; it does not mutate a Position or resurrect an old Assignment implicitly.
• document_records retains candidate/worker artifact lifecycle; rehire is not permission to copy old recruiting documents into the new Employment record.

A normalized employment_rehire_record (or equivalent aggregate-support relation) is a plausible implementation if durable prior→new Employment provenance cannot be expressed safely in existing immutable audit/idempotency evidence. Do not lock that schema in from this issue alone: the #64 owner must first define the Aggregate/UL/API/DB transaction boundary and reject unnecessary duplicated truth.

Required RED before production repair

Add owner-level executable contracts that fail on current behavior before introducing the new persistence path.

1. Existing Person, ended prior Employment, valid rehire decision → creates a new Employment identity; prior Employment/version/Assignment history remains unchanged.
2. Generic old candidate-worker conversion only → cannot by itself authorize a rehire Employment.
3. Wrong prior Employment → tenant-local but different Person, cross-tenant, unknown, or malformed prior Employment fails closed before mutation/audit.
4. Prior Employment still active/overlapping → a new exclusive Employment fails under the authoritative business/system-time portfolio; concurrent remains a separate ordinary multi-employment case and must not be mislabeled as rehire.
5. Old Employment ID reused as the default rehire target → fail closed unless a future separately governed old-employment-rehire contract explicitly authorizes that operation.
6. Recruiting-origin rehire → a new candidate/selection decision may bind to the existing Person + new Employment only through explicit match/rehire decision evidence; candidate matching itself never becomes People authorization.
7. Direct People-admin rehire → if supported, requires a separately purpose-bound human-confirmed rehire decision and must not fabricate a candidate conversion or selection decision.
8. Same idempotency key + same semantic rehire command → deterministically replays the first committed new Employment identity; changed prior/new Employment semantics under the same key fail closed.
9. Concurrent first rehire attempts → real PostgreSQL two-session acceptance proves the conflict boundary and exactly one authoritative logical rehire outcome, without timing-only sleeps or broad table locks.
10. Failure cleanup → no orphan Employment/version/audit/outbox/idempotency/rehire evidence after rollback; all client/server sessions quiesce before teardown.

Synthetic structural rows are acceptable for PostgreSQL transaction/locking mechanism tests only. Buyer/scientific claims require right-cleared real evidence with provenance.

Persistence / evidence invariants

• Aggregate transaction remains minimal; no external matching, ATS call, LLM, document processing, or long computation inside an explicit DB transaction/lock.
• Same-tenant composite FKs and FORCE RLS/NOBYPASSRLS remain mandatory.
• Rehire provenance stores opaque identifiers, governed codes/digests and timestamps rather than names, contact data, resume content, compensation, ratings, or other duplicated PII.
• Audit/outbox must identify the operation as rehire (not silently ordinary new-hire creation) and bind prior + new Employment references without embedding mutable HR payloads.
• Bitemporal history uses correction-not-rewrite. Rehire does not edit a prior Employment's historical recorded interval except through an already-governed correction/termination owner contract.
• A proper authoritative separation/termination/end-of-employment write boundary is a prerequisite if protected truth cannot yet establish the prior Employment state needed by the rehire decision. Do not fake that prerequisite by creating a new Employment initially marked terminated or by treating a review packet as mutation truth.

Delivery / owner order

Do not create a parallel People mutation writer. Implement this after the current #64 owner contracts are reconciled and normally protected, or ordinary-forward on that exact canonical owner if it remains the active writer. #65 authorization reconciliation and #141 employing-organization work must then non-force adopt the resulting protected People truth in their existing order.

Before integration: People owned production docstrings/tests/edge coverage 100%; real PostgreSQL acceptance; PRD/TRD/ARCHITECTURE/Data Model/ERD/UML/SECURITY/THREAT_MODEL/TEST_STRATEGY/OPERABILITY/TRACEABILITY/ADR code-current through canonical writers; exact-head Foundation/SAST/Security/CodeQL/OpenCode/Noema/Strix and qualifying independent review; no self-approval, routine bypass, force push, destructive rebase, mutable sibling source copy, or predecessor GREEN transfer.

Keep this issue open until an executable canonical People owner reaches protected truth. A design note or UI label is not completion.