# Administration, Records & Services Framework

## Purpose

This workbook defines the static **Administration, Records & Services architecture** for **HAV Seafood**, the fictional Faroese seafood manufacturer used in the synthetic business dataset.

It belongs to **Phase 1 — Business Architecture**:

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

The workbook defines the reusable administrative structures around record classification, record custody, retention, business access expectations, repository precedence, correspondence routing, generic document templates, recurring administrative obligations, internal office services, travel administration, visitor/reception support, meeting administration, registers and insurance administration.

It intentionally contains **no operational or historical administrative activity**.

## Core design principle

Administration is a **custodial and support domain**, not a universal owner of documents.

A document can be stored or coordinated by Administration while remaining authoritative in another domain. The central rule is:

`Business owner / authoritative system -> controlled record`

`Administration -> custody / routing / support / generic office record where assigned`

Therefore:

- HR remains authoritative for employment, payroll and HR records;
- Finance remains authoritative for financial transactions and accounting records;
- Procurement remains authoritative for supplier commercial and purchasing records;
- Sales remains authoritative for customer commercial records;
- Quality remains authoritative for controlled Quality and food-safety records;
- Production remains authoritative for production execution records;
- Maintenance remains authoritative for maintenance/calibration records;
- Logistics remains authoritative for logistics execution records;
- IT remains authoritative for technical access/security records;
- Marketing remains authoritative for Marketing assets/content;
- Management remains authoritative for management decisions and governance content.

## Architecture scope at a glance

The workbook contains:

- **12 record categories**;
- **46 controlled record types**;
- **8 synthetic internal retention classes**;
- **5 confidentiality classes**;
- **9 correspondence types**;
- **8 generic Administration template types**;
- **10 recurring administrative obligation types**;
- **12 Administration service types**;
- **10 future service-request types**;
- service eligibility covering all **12 current HAV Seafood departments**;
- **7 visitor types**;
- **5 meeting-administration types**;
- **8 administrative register types**;
- **7 insurance categories**;
- repository/source precedence rules across the current enterprise systems;
- position-based Administration and cross-domain responsibility mappings;
- a full field-level data dictionary.

## Primary systems boundary

### Microsoft 365 — `ESYS-007`

The existing Systems & Data Ownership architecture makes Microsoft 365 authoritative for:

- controlled office-file copies where no specialist system is authoritative;
- email and Teams collaboration content within applicable retention rules;
- general Administration working records, templates and shared office documents.

However, Microsoft 365 does **not** overrule specialist systems merely because a copy exists there.

### Specialist authoritative systems

Examples include:

- `ESYS-001 Core ERP` — Finance, purchasing/sales transactions and selected enterprise masters;
- `ESYS-002 Production Execution System` — production execution records;
- `ESYS-003 Quality Management System` — controlled Quality/food-safety records;
- `ESYS-004 Maintenance Management System` — maintenance and calibration activity;
- `ESYS-005 People & Payroll` — employee, payroll and HR operational records;
- `ESYS-006 Sales CRM` — customer relationship and commercial activity;
- `ESYS-008 Microsoft Entra ID` — identity/access technical records;
- `ESYS-012 Endpoint Security & Backup` — security and backup events;
- `ESYS-013 Online Banking Portal` — authoritative external bank movements/statements;
- `ESYS-009 Power BI` — reporting only; never authoritative merely because it aggregates data.

## Workbook sheets

### `Architecture_Overview`

Contains **12 data rows.

High-level purpose, boundaries, core Administration identifiers and Phase 1 assumptions.

### `Record_Categories`

Contains **12 data rows.

Controlled high-level taxonomy for records across HAV Seafood domains.

### `Record_Types`

Contains **46 data rows.

Controlled record types with authoritative domain/system, Administration role, confidentiality and retention defaults.

### `Record_Ownership`

Contains **46 data rows.

Business ownership, custodian responsibility, authoritative system and conflict precedence for each record type.

### `Record_Lifecycle`

Contains **17 data rows.

Generic record lifecycle statuses and permitted transitions. Domain-specific lifecycle rules override this generic model where applicable.

### `Retention_Classes`

Contains **8 data rows.

Synthetic internal retention classes. These are not claims about Faroese law.

### `Retention_Assignments`

Contains **46 data rows.

Maps controlled record types to default retention classes and disposal-review expectations.

### `Confidentiality_Access`

Contains **5 data rows.

Business confidentiality classes and Administration access expectations; IT owns technical permissions.

### `Repository_Rules`

Contains **46 data rows.

Authoritative repository and permitted secondary/supporting repository for each record type.

### `Repository_Precedence`

Contains **10 data rows.

Rules describing which source wins when copies or reporting extracts conflict.

### `Correspondence_Types`

Contains **9 data rows.

Reusable business-correspondence classifications.

### `Correspondence_Routing`

Contains **9 data rows.

Default routing from correspondence type to responsible department/position.

### `Admin_Template_Types`

Contains **8 data rows.

Generic reusable Administration template classes.

### `Template_Governance`

Contains **8 data rows.

Maintenance, approval, repository and domain-override rules for Administration templates.

### `Obligation_Types`

Contains **10 data rows.

Reusable recurring administrative obligation concepts with no dated instances.

### `Obligation_Rules`

Contains **10 data rows.

Responsibility, review, escalation and evidence expectations for obligation types.

### `Admin_Service_Catalog`

Contains **12 data rows.

Internal Administration service catalog.

### `Service_Request_Types`

Contains **10 data rows.

Future operational request types that can be generated in Phase 3.

### `Service_Eligibility`

Contains **144 data rows.

Department-to-service eligibility relationships.

### `Travel_Administration`

Contains **7 data rows.

Static business-travel administration rules and ownership boundaries.

### `Visitor_Reception`

Contains **7 data rows.

Visitor taxonomy, host ownership and reception/site-access boundaries.

### `Meeting_Administration`

Contains **5 data rows.

Generic meeting-support classifications without taking ownership of management/domain decisions.

### `Register_Types`

Contains **8 data rows.

Definitions of future Administration registers; no populated register entries.

### `Insurance_Administration`

Contains **7 data rows.

Insurance categories and Administration/Finance governance only; no policies, premiums, coverage or claims.

### `Admin_Provider_Types`

Contains **8 data rows.

Administrative external-service categories while preserving Procurement supplier ownership.

### `Responsibility_Mappings`

Contains **14 data rows.

Position-based Administration and cross-domain responsibilities.

### `System_Data_Ownership`

Contains **11 data rows.

Administration interpretation of the current enterprise systems and their authoritative record roles.

### `Source_Mappings`

Contains **11 data rows.

Source lineage for the workbook.

### `Relationship_Catalog`

Contains **15 data rows.

Core conceptual relationships between Administration entities.

### `Architecture_Notes`

Contains **12 data rows.

Important boundaries, assumptions and Phase 1 exclusions.

### `Control_Parameters`

Contains **10 data rows.

Static validation expectations used when maintaining the architecture.

### `Data_Dictionary`

Contains **227 data rows.

Field-level definitions, datatypes and authoritative source references.

## Important conceptual boundaries

The architecture deliberately separates:

`Record Type != Record`

`Record Owner != Record Custodian`

`Business Ownership != Storage Responsibility`

`Repository != Authoritative Source`

`Document Copy != Master Record`

`Retention Rule != Disposal Event`

`Access Rule != IT Permission`

`Correspondence Type != Correspondence`

`Template Type != Template File`

`Administrative Obligation != Obligation Event`

`Service Type != Service Request`

`Travel Administration != Travel Expense`

`Visitor Type != Visitor Visit`

`Meeting Type != Meeting`

`Meeting Administration != Management Decision`

`Register Type != Register Entry`

These distinctions must remain intact when Phase 3 operational data is generated.

## Retention and legal boundary

All retention periods in this workbook are **synthetic internal HAV Seafood assumptions** intended to make the synthetic dataset coherent.

They are not presented as Faroese statutory, regulatory or legal retention requirements. If legally accurate retention schedules are required later, they should be researched and introduced deliberately rather than inferred from this architecture.

## Administration service boundary

The internal Administration service catalog includes reception, correspondence handling, courier coordination, meeting support, travel/accommodation booking support, general document preparation, records filing/archive support, office-supplies coordination, administrative-obligation coordination and general office support.

Administration service activity may create future Phase 3 records, but it must not create competing master data. Examples:

- employee identity remains HR-owned;
- supplier/provider identity remains Shared Enterprise/Procurement-owned;
- expense and financial accounting remain Finance-owned;
- visitor site-access controls remain with the relevant host/Quality/IT/security structures;
- customer/supplier commercial substance remains Sales/Procurement-owned.

## Architecture boundaries — operational data intentionally excluded

This workbook contains **no**:

- actual correspondence or emails;
- Word/PDF office documents;
- document-version history;
- retention/disposal events;
- access logs;
- actual obligation dates or renewals;
- service-request cases;
- visitor logs;
- travel bookings or itineraries;
- travel expenses;
- meeting invitations, minutes or action logs;
- insurance policies, premiums, coverage amounts or claims;
- courier/postal events;
- office-supply orders;
- record-access events;
- completed approvals or audit trails.

Those belong to Phase 3 after the business stories are deliberately designed.

## Story neutrality

No deliberate Phase 2 outcomes are seeded here. The architecture does not intentionally create:

- lost or misfiled records;
- missed renewals;
- inappropriate retention/disposal;
- confidentiality breaches;
- unauthorized access;
- visitor-control failures;
- travel-booking failures;
- administrative backlogs;
- contradictory document versions;
- incorrect repository usage.

Those patterns should be selected later in **Phase 2 — Stories**.

## Recommended AI navigation

For fast context:

1. Read this Markdown file.
2. Inspect `Record_Types` to identify the record and authoritative domain/system.
3. Use `Record_Ownership` and `Repository_Rules` to determine custody and source of truth.
4. Use the relevant specialist domain workbook when the substantive record is owned outside Administration.

Shortcuts:

- What kind of record is this? -> `Record_Types`
- Who owns it? -> `Record_Ownership`
- Where should it live? -> `Repository_Rules`
- Which source wins? -> `Repository_Precedence`
- How long is it retained? -> `Retention_Assignments`
- What access expectation applies? -> `Confidentiality_Access`
- Where should correspondence go? -> `Correspondence_Routing`
- What internal services exist? -> `Admin_Service_Catalog`
- Who can request a service? -> `Service_Eligibility`
- Recurring administrative requirement? -> `Obligation_Types` / `Obligation_Rules`
- Travel administration? -> `Travel_Administration`
- Visitor handling? -> `Visitor_Reception`
- Meeting support? -> `Meeting_Administration`
- Who is responsible? -> `Responsibility_Mappings`
- System/source ownership? -> `System_Data_Ownership`

## Overall role of this architecture

Together, the workbook and this companion reference form the **static Administration custody, records-governance and office-services layer** for HAV Seafood.

The architecture makes Administration useful across the enterprise without allowing it to become a competing owner of Finance, HR, Sales, Procurement, Quality, Production, Maintenance, Logistics, IT, Marketing or Management records.
