# HR & Organization Architecture

## Purpose

This folder contains the static **HR & Organization Architecture** for **HAV Seafood**, the fictional Faroese seafood manufacturer used in the synthetic business dataset.

The files define how HAV Seafood's workforce is structurally organized and governed: employment relationships, positions and approved workforce establishment, contracts, compensation, working time, leave and absence, competencies and training, performance and development, recruitment and onboarding, HR policies and employee relations, and HR process/approval authority.

The architecture belongs to **Phase 1 — Business Architecture** of the project:

**1. Business architecture -> 2. Stories -> 3. Operational dataset**

It describes **what exists and how HR is designed**. It intentionally does **not** contain operational or historical HR activity such as attendance records, leave events, payroll runs, recruitment cases, completed reviews, training attendance, disciplinary cases, approvals, or employee change history.

---

## Core architecture principles

The HR & Organization Architecture follows these rules:

- Existing Shared Enterprise identifiers are reused rather than redefined.
- Employee identity, enterprise job roles, departments, organizational units, locations, systems, and shared classifications remain connected to the Shared Enterprise backbone.
- HR owns the domain-specific structures around employment, positions, contracts, compensation, working time, leave, capability, performance, recruitment, policy, and HR approvals.
- Production remains authoritative for production-specific shifts, crew groups, skills, proficiency, cross-training, work-center qualifications, and operational staffing requirements.
- Current-state architecture is separated from historical or transactional records.
- Rules and profiles are modeled separately from actual events.
- Authority is attached primarily to roles and positions rather than named employees.
- Derived reference workbooks do not override authoritative source workbooks.
- If a derived value conflicts with an authoritative source, the authoritative source wins.
- Synthetic employment, compensation, leave, disciplinary, approval, and other policy assumptions are internal fictional rules unless explicitly researched and documented otherwise.
- No deliberate business-story anomalies are seeded during Phase 1.

---

## Architecture scope at a glance

The current HR architecture is built around:

- **92 current employees** using the existing enterprise `EMP001`-`EMP092` identities.
- **56 enterprise job roles**.
- **56 structural position definitions**.
- **95 approved position seats**.
- **92 current incumbents**.
- **3 approved vacant seats**.
- **93.2 approved FTE** and **90.2 occupied FTE** in the current establishment.
- A complete current-state HR framework covering contracts, compensation, working time, leave, capability, performance, recruitment, policies, and approval authority.

These values describe the current synthetic architecture, not historical workforce activity.

---

## Files in this folder

### `hav_seafood_hr_employee_employment_master_v1.xlsx`

Defines the current employment relationship for all 92 employees.

Contains:

- current employment status and employment type;
- full-time/part-time category;
- weekly hours and FTE;
- salaried/hourly pay basis;
- HR employee groups;
- employment start and continuous-service dates;
- time-registration, overtime and shift-worker flags;
- Production shift references where applicable;
- source mappings, architecture notes, and data dictionary.

This workbook extends the enterprise employee identity layer rather than replacing it.

It does **not** contain employment-change history, attendance, absence events, salary amounts, payroll activity, performance history, training history, or termination events.

---

### `hav_seafood_hr_positions_workforce_establishment_v1.xlsx`

Defines the formal HR position and approved workforce-establishment model.

The core structure is:

`Job Role -> Position Definition -> Position Seat -> Employee Incumbent`

Contains:

- 56 structural position definitions;
- 95 approved position seats;
- 92 current incumbents;
- 3 approved vacancies;
- structural reporting relationships;
- approved and occupied FTE;
- current position incumbency;
- position type/status structures;
- workforce-establishment views;
- mappings to existing management positions and Production staffing context.

The separate `Position_Seat_ID` layer allows multiple approved seats to share one structural `Position_ID` without breaking existing Shared Enterprise position references.

---

### `hav_seafood_hr_employment_terms_contract_framework_v1.xlsx`

Defines reusable employment-contract structures and current employee-to-contract assignments.

Contains:

- 12 reusable contract profiles, of which 8 are currently used;
- one current `HRC-*` contract relationship for each of the 92 employees;
- contractual term categories;
- probation structures;
- notice structures;
- internal agreement/coverage structures;
- contract applicability rules;
- current mappings to position, employment type, work pattern, pay basis, and employee group.

The workbook defines contract architecture rather than signed contract documents or contract history.

Probation, notice, and agreement rules are synthetic internal assumptions and are not presented as Faroese statutory or collective-agreement rules.

---

### `hav_seafood_hr_compensation_structure_v1.xlsx`

Defines the static compensation architecture and current employee base-pay master.

Contains:

- 9 active pay grades;
- 12 active pay bands;
- role-to-grade mappings for all 56 job roles;
- current compensation assignments for all 92 employees;
- synthetic current base hourly/monthly rates;
- 15 compensation components;
- premium rules;
- allowances;
- benefit groups;
- compensation eligibility rules;
- variable-pay target structures.

The workbook separates **eligibility**, **rate/rule**, and **actual payment**.

It does **not** contain salary history, payroll runs, actual overtime payments, bonus awards, deductions, pension payments, payslips, or accounting postings.

All monetary values are fictional internal HAV Seafood assumptions rather than market benchmarks, statutory requirements, or collective-agreement rates.

---

### `hav_seafood_hr_working_time_framework_v1.xlsx`

Defines the HR interpretation and classification of working time.

Contains:

- 10 reusable working-time models;
- one current working-time assignment for each of the 92 employees;
- HR-owned office schedule patterns;
- role/position working-time defaults;
- time categories;
- overtime-classification rules;
- break rules;
- time-registration rules;
- holiday/weekend treatment;
- flex-time and remote-work rules;
- mappings to existing Production shifts and shift groups.

For the 65 employees already represented in Production shift assignments, the existing `SH-*` and `SG-*` references are preserved.

Production remains authoritative for the seeded Production shift definitions, while `ESYS-005 People & Payroll` is the intended system of record for operational time and attendance.

No timesheets, clockings, attendance events, actual overtime, schedule changes, shift swaps, or remote-work events are stored here.

---

### `hav_seafood_hr_leave_absence_framework_v1.xlsx`

Defines the static leave and absence framework.

Contains:

- 14 leave and absence types;
- 7 reusable entitlement profiles;
- current entitlement-profile assignments for all 92 employees;
- entitlement rules;
- eligibility rules;
- approval/notification rules;
- documentation rules;
- pay-treatment classifications;
- working-time mappings;
- return-to-work rules.

The architecture explicitly separates:

`Leave/Absence Type -> Eligibility -> Entitlement -> Operational Event`

Sickness and similar event-based absence categories are not modeled as arbitrary annual entitlement banks.

No leave requests, absence events, dates, balances, accruals, medical details, approvals, or payroll calculations are included.

All quantitative entitlement and documentation thresholds are synthetic internal assumptions.

---

### `hav_seafood_hr_competency_training_framework_v1.xlsx`

Defines the enterprise competency, training, and qualification architecture.

The architecture separates:

- **Competency** — capability or ability;
- **Training** — learning activity;
- **Certification / authorization** — formal evidence or permission.

Contains:

- 33 enterprise competencies;
- 5 competency levels;
- 24 training definitions;
- 10 certification/authorization definitions;
- competency requirements for all 56 job roles;
- training requirements for all 56 job roles;
- current enterprise competency profiles for all 92 employees;
- qualification/authorization references where appropriate;
- bridges to 106 unique Production skills.

Production remains authoritative for production-specific proficiency, cross-training, work-center qualification, operational authorization, and dated production skill assessments.

The architecture contains no deliberate competence gaps, overdue training, expired certificates, training attendance, test scores, or assessment history.

---

### `hav_seafood_hr_performance_development_framework_v1.xlsx`

Defines the static performance-management and employee-development framework.

Contains:

- 7 performance profiles;
- reusable review types and review cycles;
- a restrained enterprise rating scale;
- 15 performance dimensions;
- role-performance requirements for all 56 job roles;
- current performance-framework assignments for all 92 employees;
- goal categories;
- development activity types;
- 36 possible role-development pathways;
- career-level references;
- manager responsibilities;
- mappings to the Competency & Training architecture.

The architecture keeps separate:

`Performance Requirement -> Competency Requirement -> Review -> Development Action`

It contains no completed reviews, ratings, goals, feedback, development plans, promotion decisions, succession candidates, or performance-improvement cases.

---

### `hav_seafood_hr_recruitment_onboarding_framework_v1.xlsx`

Defines how approved workforce needs are translated into recruitment and onboarding structures.

Contains:

- 8 recruitment profiles;
- 15 reusable recruitment stages;
- role recruitment defaults for all 56 job roles;
- requisition types;
- recruitment channels;
- candidate evaluation criteria;
- interview frameworks;
- selection rules;
- pre-employment checks;
- offer-to-contract mappings;
- 7 onboarding profiles;
- 29 onboarding tasks;
- onboarding requirements for all 56 job roles;
- high-level system-access requirements;
- the 3 approved vacant position seats as architecture context only.

The core distinction is:

`Vacant Position != Recruitment Requisition != Candidate != Employee`

The current enterprise systems architecture has no dedicated applicant-tracking system. Recruitment coordination therefore references existing Microsoft 365 capabilities and HR ownership; `ESYS-005 People & Payroll` becomes authoritative once a person becomes an employee.

No requisitions, applications, candidates, interviews, offers, hiring decisions, start events, or onboarding completions are stored here.

---

### `hav_seafood_hr_policy_employee_relations_framework_v1.xlsx`

Defines the static HR policy and employee-relations architecture.

Contains:

- 30 HR/employment policy concepts;
- policy applicability and acknowledgment rules;
- 15 conduct standards;
- 21 employee-relations matter types;
- a 7-step grievance framework;
- an 8-step disciplinary framework;
- a 9-step investigation framework;
- 10 corrective-action types;
- escalation rules;
- representation/support principles;
- restricted case-access rules;
- policy/process mappings;
- policy/training mappings.

The architecture deliberately keeps separate:

`Policy -> Expected Conduct -> Alleged Concern -> Investigation / Process -> Outcome`

An allegation is never treated as a proven breach.

No grievances, disciplinary cases, allegations, investigation notes, findings, warnings, policy acknowledgments, appeals, or other employee-relations case history are included.

All grievance, disciplinary, representation, investigation, and corrective-action rules are synthetic internal company architecture rather than legal claims.

---

### `hav_seafood_hr_process_approval_authority_v1.xlsx`

Defines who may initiate, review, approve, or escalate HR actions.

Contains:

- 42 HR process definitions;
- 243 reusable static process steps;
- 10 authority/control levels;
- approval rules for all 42 processes;
- 25 position-to-authority mappings;
- delegation rules;
- escalation rules;
- 15 segregation-of-duties controls;
- 15 synthetic monetary/percentage approval thresholds;
- process/system mappings;
- policy/process mappings.

Authority is primarily attached to existing positions and role structures rather than named employees. The existing management hierarchy is used rather than creating a parallel approval organization.

The architecture separates:

`Responsibility -> Authority -> Approval Event`

No approval requests, decisions, timestamps, comments, delegation periods, exceptions, or approval history are included.

---

### `hav_seafood_hr_reference_tables_v1.xlsx`

Provides the derived, AI-friendly navigation and joining layer across the full HR architecture.

Contains compact reference views for:

- all 92 employees;
- all 95 approved position seats;
- all 56 enterprise job roles;
- employment/contract relationships;
- compensation assignments;
- working-time assignments;
- leave entitlement profiles;
- 1,100 role competency/training requirement relationships;
- performance assignments;
- recruitment/onboarding defaults;
- policy applicability;
- approval authority;
- HR data/system relationships;
- 65 Production-to-HR employee bridges;
- HR entity ownership/source registry;
- architecture-source catalog;
- relationship catalog.

This workbook is **derived** and does not own master data.

If it conflicts with an authoritative HR, Shared Enterprise, or Production source, the authoritative source wins.

This workbook should normally be the first HR workbook inspected when fast AI context or cross-domain navigation is needed.

---

## Companion Markdown files

Each authoritative/derived HR workbook has a matching `.md` file containing a compact description of:

- purpose;
- principal entities and relationships;
- workbook contents;
- ownership boundaries;
- important assumptions;
- relationships to other architectures;
- explicit exclusions.

These files are intended to give AI systems and human users quick context without requiring every workbook to be opened first.

---

## How the HR architecture fits together

At a high level, the HR model follows these relationships:

`Shared Enterprise Employee Identity + Organization + Job Roles`

`-> Employee Employment Master`

`-> Position Definitions + Position Seats + Incumbency`

`-> Contract Profile + Current Contract`

`-> Compensation Grade / Band + Current Base Rate`

`-> Working-Time Model`

`-> Leave / Absence Entitlement Profile`

`-> Competency / Training Requirements`

`-> Performance / Development Framework`

`-> Recruitment / Onboarding Defaults`

`-> Policy / Employee Relations Rules`

`-> HR Process / Approval Authority`

`-> HR Reference Tables`

Another useful view is:

`Job Role -> Position -> Position Seat -> Employee`

`Employee -> Employment -> Contract -> Compensation -> Working Time -> Leave`

`Job Role -> Competencies + Training + Performance Requirements`

`Job Role / Position -> Recruitment + Onboarding Defaults`

`Policy -> HR Process -> Approval Authority`

`All HR domains -> HR Reference Tables`

---

## Relationship with Shared Enterprise Architecture

The Shared Enterprise Architecture remains the enterprise backbone around HR.

HR reuses Shared Enterprise identifiers and structures including:

- company identity;
- departments;
- organizational units;
- enterprise locations;
- employee IDs;
- enterprise job roles/job families;
- management-position references already established before the detailed HR position model;
- enterprise systems;
- identifier conventions;
- shared reference data;
- system/data ownership rules.

HR extends those structures with domain-specific employment and workforce attributes rather than creating competing identities.

Important ownership distinctions include:

- **Shared Enterprise** — enterprise identity, organization, common locations, systems, shared classifications and cross-domain standards.
- **HR** — employment relationship, position seats/workforce establishment, contracts, compensation, working-time HR rules, leave, competency/training framework, performance/development, recruitment/onboarding, HR policy/employee relations and HR approval authority.
- **Finance** — future enterprise-wide cost-center and financial-authorization structures where those extend beyond HR-specific approval controls.
- **IT** — detailed technical identity/access architecture and system permissions.

The Shared Enterprise Systems Landscape and System/Data Ownership Model remain authoritative for system identity and system-of-record decisions.

---

## Relationship with Production Architecture

Production Architecture predates the detailed HR Architecture and remains authoritative for operational Production workforce structures.

Production continues to own:

- production-specific skills;
- proficiency levels and skill assessments;
- cross-training;
- work-center qualifications;
- production crew groups;
- production shift patterns;
- production employee default shift assignments;
- work-center staffing requirements;
- production capacity and labor requirements.

HR does not copy or redefine these structures.

Instead, HR provides employment interpretation and bridges such as:

- Enterprise Employee -> Production Employee;
- HR Working-Time Model -> Production Shift / Shift Group;
- HR Competency/Training -> Production Skill reference;
- Position / Role -> Production staffing context.

This maintains a clean distinction between **employment architecture** and **operational production qualification/scheduling architecture**.

---

## Authoritative versus derived files

The following HR workbooks are authoritative for their HR subject areas:

- `hav_seafood_hr_employee_employment_master_v1.xlsx`
- `hav_seafood_hr_positions_workforce_establishment_v1.xlsx`
- `hav_seafood_hr_employment_terms_contract_framework_v1.xlsx`
- `hav_seafood_hr_compensation_structure_v1.xlsx`
- `hav_seafood_hr_working_time_framework_v1.xlsx`
- `hav_seafood_hr_leave_absence_framework_v1.xlsx`
- `hav_seafood_hr_competency_training_framework_v1.xlsx`
- `hav_seafood_hr_performance_development_framework_v1.xlsx`
- `hav_seafood_hr_recruitment_onboarding_framework_v1.xlsx`
- `hav_seafood_hr_policy_employee_relations_framework_v1.xlsx`
- `hav_seafood_hr_process_approval_authority_v1.xlsx`

The following workbook is deliberately derived:

- `hav_seafood_hr_reference_tables_v1.xlsx`

The derived reference workbook exists to simplify navigation, joining, AI context, and later dataset generation. It must be refreshed when authoritative HR architecture changes and must never overrule a source workbook.

---

## Current-state versus history

Most employee-level HR architecture is intentionally modeled as **current state**.

Examples include:

- current employment relationship;
- current position incumbency;
- current contract assignment;
- current compensation assignment;
- current working-time model;
- current leave entitlement profile;
- current enterprise competency profile;
- current performance-framework assignment.

The architecture does not attempt to model every historical change through effective-dated records.

Later Phase 3 datasets can generate histories against these stable master structures, including promotions, transfers, pay changes, contract amendments, schedule changes, training history, leave history, recruitment activity, and employee-relations cases.

---

## Legal, collective-agreement, and market boundary

The HR architecture is designed to be realistic enough for a synthetic business dataset but is **not a statement of Faroese employment law**.

Unless explicitly stated otherwise, the following are fictional internal HAV Seafood assumptions:

- probation durations;
- notice rules;
- contract terms;
- pay bands and base rates;
- overtime and premium structures;
- pension/benefit assumptions;
- leave entitlement quantities;
- documentation thresholds;
- flexible-work rules;
- disciplinary/grievance procedures;
- employee representation/support rules;
- approval thresholds.

No real union or collective agreement is intentionally represented.

If legally accurate Faroese employment structures are required later, they should be researched and introduced deliberately rather than silently inferred from these synthetic rules.

---

## Sensitive-data boundary

The architecture contains structural HR classifications but intentionally avoids operational sensitive-case data.

It does not contain:

- medical diagnoses;
- detailed medical documents;
- grievance allegations against named people;
- disciplinary findings;
- investigation interview notes;
- candidate background-check results;
- private employee correspondence;
- employee review comments;
- payroll/tax/deduction details.

Later operational datasets may include carefully designed synthetic records of some of these categories where useful, but they should remain consistent with the confidentiality and access rules defined in this architecture.

---

## Architecture boundaries — operational data intentionally excluded

This folder does **not** contain historical or transactional records such as:

- employee hire/termination events;
- contract amendments and renewals;
- position-transfer history;
- salary-change history;
- payroll runs and payslips;
- gross/net pay transactions;
- tax, pension and deduction transactions;
- clock-in/clock-out events;
- timesheets;
- actual worked hours;
- overtime events;
- shift swaps;
- attendance exceptions;
- leave requests;
- leave approvals;
- absence/sickness events;
- leave balances and accruals;
- training registrations and completions;
- certification renewal history;
- competency assessments over time;
- completed performance reviews;
- performance ratings;
- employee goals;
- development-plan activity;
- recruitment requisitions;
- job advertisements;
- candidate records and CVs;
- interview results;
- offers and offer outcomes;
- onboarding completion records;
- policy acknowledgment events;
- grievances;
- disciplinary cases;
- investigations;
- warnings and corrective actions;
- approval requests and decisions;
- approval audit trails.

Those belong to Phase 3 after the Phase 2 business stories and patterns have been deliberately designed.

---

## Story neutrality

The HR architecture is intentionally designed to support future business stories without choosing them yet.

It does not deliberately seed patterns such as:

- unusual turnover;
- chronic absenteeism;
- understaffing caused by employee events;
- problematic managers;
- salary inequity;
- payroll mistakes;
- excessive overtime;
- training gaps;
- expired qualifications;
- weak performance;
- promotion candidates;
- hard-to-fill vacancies;
- failed hiring checks;
- onboarding failures;
- policy violations;
- disciplinary trends;
- approval-control failures.

Those patterns should be selected in **Phase 2 — Stories** and introduced deliberately when the operational dataset is generated.

---

## Identifier conventions

Existing Shared Enterprise and Production identifiers are preserved.

New HR-local identifiers use distinct prefixes for HR entities such as contracts, contract profiles, working-time models, leave structures, competencies, performance structures, recruitment structures, policies, and approval processes.

Where a potential collision exists with Production identifiers, HR uses a distinct HR-specific prefix. For example, HR Contract Profiles use `HCP-*` rather than `CP-*`, because Production already uses `CP-*` for control points.

Some HR-local prefixes are provisional domain conventions and should be registered in the Shared Enterprise identifier standards if the enterprise standards workbook is refreshed.

---

## Known source-data issue

The existing Production people source contains two `Hire_Date` values later than the HR architecture date of **2026-08-12** while both employees are marked active:

- `EMP015` — `2026-12-03`
- `EMP026` — `2026-12-25`

The HR Employee Employment Master preserves and flags these source values rather than silently correcting them.

They should be reconciled in the authoritative Production source before Phase 3 operational HR data is generated.

---

## Recommended use of the folder

For fast context, inspect files in this order:

1. `README_hr_organization_architecture.md` — overall HR architecture and boundaries.
2. `hav_seafood_hr_reference_tables_v1.xlsx` — compact cross-HR joining/reference layer.
3. The matching authoritative workbook for the subject being analyzed.
4. Shared Enterprise or Production source workbooks when a relationship crosses domain boundaries.

For AI workflows, the README plus the HR Reference Tables workbook should normally provide enough context to identify which detailed authoritative workbook must be inspected next.

---

## Use in later phases

### Phase 2 — Stories

The architecture provides the stable structures needed to design cross-functional stories involving areas such as:

- workforce capacity;
- recruitment;
- absence;
- overtime;
- compensation;
- training;
- performance;
- employee relations;
- management approvals;
- production staffing;
- finance/payroll impacts;
- IT onboarding/offboarding;
- quality and safety requirements.

Stories should reference existing IDs and relationships rather than changing the architecture merely to make a pattern possible.

### Phase 3 — Operational dataset generation

Operational HR datasets should:

1. reuse the employee, role, position, contract, compensation, working-time, leave, competency, policy, process, and system identifiers defined here;
2. preserve Shared Enterprise and Production identifiers;
3. generate events according to the static rules and profiles in the authoritative workbooks;
4. create realistic ordinary activity and noise around the deliberately selected Phase 2 stories;
5. avoid redefining master data inside transactional files;
6. preserve system-of-record and ownership boundaries;
7. create cross-functional records that can be joined consistently across HR, Production, Finance, IT, Quality, Sales, Procurement, and other domains.

---

## Overall role of this architecture

Together, these files form the **static HR & Organization master-data and rules layer** for HAV Seafood.

They provide a consistent foundation for later synthetic data involving people and workforce processes without mixing current structural design with operational history.

The architecture connects the enterprise organization and identity backbone to employment, positions, contracts, pay, working time, leave, capability, development, recruitment, policy, employee relations, and approval authority while preserving Production ownership of operational workforce qualifications and scheduling structures.

This allows later business stories and generated datasets to behave like parts of one coherent company rather than independent synthetic tables.
