Enterprise Job Description File Naming Architecture and Taxonomy SOP

Standard Operating Procedure: Enterprise Job Description File Naming Architecture and Document Taxonomy

1. Document Control Block

---

2. Executive Summary & Purpose

2.1 Executive Summary

Unstructured and non-standardized document naming conventions for Job Descriptions (JDs) introduce compliance vulnerabilities, corrupt enterprise search indexability, break automated Applicant Tracking System (ATS) ingestion pipelines, and generate audit tracking failures across human capital management platforms. This Standard Operating Procedure (SOP) defines the mandatory, deterministic file-naming syntax, directory taxonomy, and version-control metadata protocols for all job description assets enterprise-wide.

2.2 Purpose

The goal of this protocol is to:

• Enforce a programmatic, machine-readable string syntax for all JD file assets.
• Ensure zero syntax collisions across high-volume HRIS platforms (Workday, Greenhouse, SAP SuccessFactors).
• Maintain strict lineage and regulatory audit trails required for ISO 9001 document control and SOC 2 Type II compliance.
• Standardize cross-platform searching via precise parameter tokenization.

---

3. Scope & Prerequisites

3.1 Operational Scope

• In-Scope: All corporate, field, temporary, executive, and contract position description documents (Draft, Review, Production, and Archived states) generated across all business units and global regions.
• Out-of-Scope: Candidate resumes, offer letters, generic organization charts, or non-role-specific compensation benchmark sheets.

3.2 Prerequisites

• Access Permissions:
  • Read/Write authorization to the Enterprise Template Registry (S3 / Azure Blob / SharePoint Central Architecture).
  • Administrative rights to HRIS Job Catalog master files.
• Tooling & Environments:
  • jd-namelint CLI Utility (or native Python/Bash regex execution environment).
  • UTF-8 compliant text/document editor (VS Code, Microsoft Word 365 Enterprise).
  • System-configured Git repository or Cloud Storage bucket supporting POSIX-compliant paths.

---

4. Roles & Responsibilities

The RACI matrix below assigns accountability for execution, governance, and maintenance of the naming architecture.

Key: R = Responsible, A = Accountable, C = Consulted, I = Informed

---

5. Step-by-Step Procedure

Phase 1: String Construction Architecture Specification

All canonical job description files MUST strictly adhere to the standardized standard tokenization syntax:

[OrgUnit]_[JobFamily]_[JobCode]_[Level]_[Locale]_[LifecycleStatus]_v[Major.Minor].[ext]

Token Definitions & Technical Constraints

Canonical Example

ENG_PLAT_SE-04_L05_US-REM_PROD_v2.1.docx

Regex Validation Pattern

All file system upload pipelines MUST validate the document name against the following POSIX regular expression:

^[A-Z]{3,4}_[A-Z]{3,6}_[A-Z0-9\-]{3,10}_L[0-9]{2}_[A-Z]{2,4}(-[A-Z0-9]+)?_(DRAFT|REVIEW|PROD|ARCH)_v[0-9]+\.[0-9]+\.(pdf|docx|md)$

---

Phase 2: Pre-Publish Token Validation Workflow

• Step 2.1: Retrieve official JobCode and JobFamily designators from the Master HRIS Catalog. Do not invent arbitrary acronyms.
• Step 2.2: Verify that no spaces, special characters (!, @, #, $, %, ^, &, *, (), +, =), or soft hyphens are used in the filename.
• Step 2.3: Confirm delimiter usage:
  • Underscores (_) MUST be used exclusively to separate primary token groups.
  • Hyphens (-) MUST be used exclusively to separate sub-tokens (e.g., inside JobCode or Locale).
• Step 2.4: Validate casing rules:
  • All text tokens must be 100% UPPERCASE, except for the leading lowercase v in the version token and the lowercase file extension (.docx, .pdf, .md).
• Step 2.5: Run the local string verification check via CLI linting tool prior to staging:

  $ jd-namelint --filename "ENG_PLAT_SE-04_L05_US-REM_PROD_v2.1.docx"
  [SUCCESS] Token structure valid. Target environment: Enterprise Template Registry.
  

---

Phase 3: Directory Routing and Structural Placement

Documents must be routed to absolute POSIX pathing matching their metadata tokens. Direct file dumping into root or un-indexed folders is forbidden.

• Step 3.1: Select target root repository (e.g., s3://corp-hris-jd-registry-prod/).
• Step 3.2: Verify structural folder hierarchy adhering strictly to:

  /[OrgUnit]/[JobFamily]/[JobCode]/
  

  Example Path: /ENG/PLAT/SE-04/ENG_PLAT_SE-04_L05_US-REM_PROD_v2.1.docx
• Step 3.3: Stage document in correct path context and set object access permissions according to global governance standards (Read-Only for TA, Full-Control for HRIS Ops).

---

Phase 4: Document Internal Metadata Synchronization

To prevent discrepancies between file properties and document body content, internal metadata headers MUST match file names identically.

• Step 4.1: Open document and navigate to Document Properties / Header Section.
• Step 4.2: Populate document metadata parameters:
  • Title: Match complete string name (e.g., ENG_PLAT_SE-04_L05_US-REM_PROD_v2.1)
  • Subject: Standard Job Description
  • Author: Template Registry HRIS Pipeline
  • Keywords: ENG, PLAT, SE-04, L05, US-REM, PROD
• Step 4.3: Inject the exact canonical filename into the internal document footer using 10pt Roboto Mono or Courier New font.

---

Phase 5: Version Lifecycle Progression & Archival

• Step 5.1 (Draft Phase): Initial document drafting must use stage DRAFT and initial versioning (v0.1, v0.2).
  • Filename: FIN_ACCT_FIN-12_L03_GLOB-ALL_DRAFT_v0.1.docx
• Step 5.2 (Review Phase): Stakeholder review progression increments minor versions (v0.2 to v0.9) under stage REVIEW.
  • Filename: FIN_ACCT_FIN-12_L03_GLOB-ALL_REVIEW_v0.3.docx
• Step 5.3 (Production Lock): Approved production deployment locks status to PROD and sets Major version (v1.0).
  • Filename: FIN_ACCT_FIN-12_L03_GLOB-ALL_PROD_v1.0.pdf
• Step 5.4 (Deprecation Execution): Upon role revision or retirement, change stage string to ARCH. Move file into /ARCHIVE/ folder within 24 hours of standard update.
  • Filename: FIN_ACCT_FIN-12_L03_GLOB-ALL_ARCH_v1.0.pdf

---

6. Quality Assurance & Pro-Tips

6.1 Critical QA Metric Thresholds

• Name Conformance Rate: 100% adherence verified via CI/CD linting script. Non-conforming filenames are automatically rejected at upload interface.
• Filename String Length: Maximum 64 characters total (excluding file extension) to ensure legacy Windows API file path compatibility (MAX_PATH limit of 260 characters).
• ATS Indexing Failures: < 0.01% ingest errors caused by token parsing mismatches.

6.2 Common Pitfalls & Anti-Patterns

• The "Final" Fallacy: Never append descriptive text such as _final, _approved, _updated, or _v2_final_FINAL to filenames. Version states are exclusively managed via standard v[Major.Minor] tags.
• Whitespace Corruption: Inserting spaces breaks cloud storage path parsing and shell operations. Use underscores (_) only.
• Locale Ambiguity: Avoid local state/city jargon without standard ISO prefix formatting (e.g., use US-NYC, not NEWYORKCITY).

6.3 Pro-Tips

• Git Pre-Commit Hook: Install a git pre-commit script to block developers or HR tech operations from committing non-compliant filenames into standard repository environments:

  #!/bin/sh
  LC_ALL=C
  for FILE in $(git diff --cached --name-only); do
      if [[ "$FILE" =~ ^templates/.* ]] && ! [[ "$(basename $FILE)" =~ ^[A-Z]{3,4}_[A-Z]{3,6}_[A-Z0-9\-]{3,10}_L[0-9]{2}_[A-Z]{2,4}(-[A-Z0-9]+)?_(DRAFT|REVIEW|PROD|ARCH)_v[0-9]+\.[0-9]+\.(pdf|docx|md)$ ]]; then
          echo "ERROR: File '$FILE' fails standard job description naming convention rules."
          exit 1
      fi
  done
  

• Bilingual/Multi-Locale Handling: For bilingual JD requirements (e.g., Canadian Market Requirements), append the ISO-639-1 language sub-token to the locale string: CA-QC-FR or CA-ON-EN.

---

7. Frequently Asked Questions (FAQ)

FAQ 1: How do we handle custom executive or non-standard corporate titles that lack an existing JobCode or Level?

Answer: No document may bypass tokenization. If an executive role lacks standard JobCode indexing, HRIS Operations must execute an emergency requisition ticket to issue a temporary legacy job code (e.g., EXEC-99) and assign an executive tier level (e.g., L15 for C-Suite). Unindexed or arbitrary string naming is strictly blocked by template access policies.

FAQ 2: What is the exact workflow for correcting a legacy file that has already been ingested into the ATS with a non-compliant file name?

Answer: Do not rename the active file directly inside the public production bucket without prior deprecation flags, as this breaks existing URL link anchors.

1. Copy the legacy file to local storage.
2. Re-encode file name according to Section 5, incrementing version to v1.0 if production-ready.
3. Upload new standard object to canonical location.
4. Execute programmatic redirect/mapping inside ATS metadata tables.
5. Move legacy document to archival path tagged with stage ARCH.

FAQ 3: How should minor copy edits (e.g., fixing a typo in the role summary) be versioned?

Answer: Minor text/typographical fixes that do not change core compensation grade, requirements, or internal job code trigger a Minor Version Increment (e.g., v1.0 becomes v1.1). Any modifications altering compensation bands, role level (Level token), or core functional duties require a formal HRBP sign-off and a Major Version Increment (e.g., v1.1 becomes v2.0).