Add policy repository structure and initial governance documents

policies/README.md

@@ -0,0 +1,166 @@
+# Policy Repository
+
+This directory contains the controlled policy, procedure, standard, guideline, form, exception, and evidence records for the Kell Creations platform.
+
+## Purpose
+
+The purpose of this repository structure is to provide a controlled, auditable, and maintainable lifecycle for business policies and supporting governance records.
+
+This repository supports:
+
+- document creation
+- review and approval
+- publication to active status
+- version control
+- retirement of superseded documents
+- retention of approval and retirement evidence
+
+## Repository Structure
+
+### `active/`
+Contains approved documents that are currently in force.
+
+### `drafts/`
+Contains documents being authored or revised before formal review.
+
+### `review/`
+Contains documents that are under formal review and awaiting approval, rejection, or revision.
+
+### `retired/`
+Contains documents that are no longer active because they were superseded, withdrawn, or retired.
+
+### `templates/`
+Contains approved starter templates for controlled documents.
+
+### `register/`
+Contains the master document register and supporting control logs.
+
+### `evidence/`
+Contains approval records, review records, exceptions, and retirement evidence.
+
+## Lifecycle Model
+
+Controlled documents move through the following lifecycle:
+
+1. Draft
+2. Review
+3. Active
+4. Superseded or Revised
+5. Retired
+
+Documents should not skip lifecycle stages without documented approval.
+
+## Document Types
+
+The following document types are supported:
+
+- Policy
+- Procedure
+- Standard
+- Guideline
+- Form
+- Exception
+
+## Naming Convention
+
+Documents should follow this pattern:
+
+`KC-<TYPE>-<DOMAIN>-<NUMBER>-<short-title>.md`
+
+Examples:
+
+- `KC-POL-GOV-001-document-control-policy.md`
+- `KC-PRO-GOV-001-policy-review-and-retirement-procedure.md`
+- `KC-STD-MKT-001-social-media-publishing-standard.md`
+
+### Type codes
+
+- `POL` = Policy
+- `PRO` = Procedure
+- `STD` = Standard
+- `GLD` = Guideline
+- `FRM` = Form
+- `EXC` = Exception
+
+### Domain codes
+
+- `GOV` = Governance
+- `OPS` = Operations
+- `ECM` = Ecommerce
+- `MKT` = Marketing
+- `MFG` = Manufacturing
+- `FIN` = Finance
+- `IT` = Information Technology
+- `SEC` = Security
+- `PRV` = Privacy
+
+## Required Metadata
+
+All controlled documents must begin with YAML front matter that includes:
+
+- `document_id`
+- `title`
+- `document_type`
+- `domain`
+- `version`
+- `status`
+- `owner`
+- `reviewers`
+- `approver`
+- `effective_date`
+- `next_review_date`
+- `supersedes`
+- `related_documents`
+- `related_systems`
+- `retention_period`
+- `confidentiality`
+
+## Document Control Rules
+
+- All controlled documents must be stored in Git.
+- All changes must be reviewed through the approved repository workflow.
+- Active documents must have an approver and effective date.
+- Superseded documents must be moved to `retired/`.
+- Approval and retirement actions must be reflected in the control logs under `register/`.
+- Evidence of approval, review, exception, or retirement should be preserved under `evidence/`.
+
+## Registers
+
+### `policy-register.csv`
+The master index of controlled documents.
+
+### `document-control-log.csv`
+The record of lifecycle changes and status transitions.
+
+### `review-calendar.csv`
+The schedule for periodic policy review.
+
+### `exception-register.csv`
+The record of approved and tracked exceptions.
+
+## Recommended Workflow
+
+1. Create a new document in `drafts/`.
+2. Assign owner, reviewers, and proposed approver.
+3. Move document to `review/` when ready for formal review.
+4. Approve and move to `active/` when authorized.
+5. Update the document register and control log.
+6. Move superseded versions to `retired/`.
+7. Store supporting approval or retirement evidence in `evidence/`.
+
+## Relationship to Architecture and Operations
+
+This policy repository supports the architecture and workflow documentation maintained elsewhere in the repository, including:
+
+- policy lifecycle workflows
+- audit and compliance architecture
+- CI/CD workflow documentation
+- operating procedures for controlled publication
+
+## Ownership
+
+Unless otherwise specified in a document, repository governance is owned by the Kell Creations business owner.
+
+## Summary
+
+This policy repository is the controlled governance layer for Kell Creations documentation, operational rules, and retained compliance evidence.

policies/active/governance/KC-POL-GOV-001-document-control-policy.md

@@ -0,0 +1,194 @@
+---
+document_id: KC-POL-GOV-001
+title: Document Control Policy
+document_type: Policy
+domain: Governance
+version: 1.0
+status: Active
+owner: Business Owner
+reviewers:
+  - Operations Staff
+approver: Business Owner
+effective_date: 2026-04-03
+next_review_date: 2027-04-03
+supersedes: None
+related_documents:
+  - KC-PRO-GOV-001
+related_systems:
+  - Kell Creations Platform
+  - Policy Repository
+  - Forgejo Git
+  - Compliance Evidence Repository
+retention_period: 3 years
+confidentiality: Internal
+---
+
+# Purpose
+
+The purpose of this policy is to establish a controlled and auditable process for creating, reviewing, approving, publishing, revising, superseding, retaining, and retiring official Kell Creations governance and operational documents.
+
+# Scope
+
+This policy applies to all controlled documents maintained within the Kell Creations repository structure, including:
+
+- policies
+- procedures
+- standards
+- guidelines
+- forms
+- exception records
+
+This policy applies to all business areas using the policy repository, including governance, operations, ecommerce, marketing, manufacturing, finance, information technology, security, and privacy.
+
+# Policy Statement
+
+Kell Creations shall maintain all controlled documents through a defined document lifecycle that supports traceability, version control, formal approval, and retention of evidence.
+
+Controlled documents must be:
+
+- uniquely identified
+- versioned
+- assigned an owner
+- reviewed before activation
+- approved before publication to active status
+- retained in version-controlled form
+- retired when superseded, obsolete, or withdrawn
+
+No document shall be treated as active policy unless it is stored in the approved repository structure, has required metadata, and has been formally approved.
+
+# Document Lifecycle Requirements
+
+## Draft
+
+A document begins in draft status while being authored or revised.
+
+Draft documents must:
+
+- use an approved template where applicable
+- include required metadata
+- identify an owner
+- be stored in the `drafts/` area unless formally advanced
+
+## Review
+
+A document moves to review status when the owner determines it is ready for formal evaluation.
+
+Review documents must:
+
+- identify reviewers
+- be evaluated for completeness, clarity, and applicability
+- remain unchanged except through controlled revision
+
+## Active
+
+A document becomes active only after formal approval by the named approver.
+
+Active documents must:
+
+- include an effective date
+- include a next review date
+- be stored in the `active/` area
+- be referenced in the document register
+
+## Revision and Supersession
+
+When an active document is changed materially, the revised version must proceed through draft and review before replacing the active version.
+
+Superseded versions must not remain in the active area.
+
+## Retirement
+
+A document shall be retired when it is no longer needed, replaced, withdrawn, or no longer applicable.
+
+Retired documents must:
+
+- be moved to the `retired/` area
+- retain their historical metadata
+- be referenced in the control log
+- retain supporting retirement evidence when required
+
+# Metadata Requirements
+
+All controlled documents must include front matter with the required metadata fields defined in the repository guidance.
+
+Missing or incomplete metadata makes a document ineligible for active status.
+
+# Version Control Requirements
+
+Controlled documents must be maintained in the Kell Creations Git repository.
+
+All lifecycle changes must be traceable through version history and supporting control records.
+
+Git history supports technical traceability, but document register and control log updates are still required for formal lifecycle accountability.
+
+# Roles and Responsibilities
+
+## Business Owner
+
+The Business Owner shall:
+
+- approve active policies and procedures unless delegated otherwise
+- ensure document control is enforced
+- review high-impact governance changes
+- approve retirement of major governing documents
+- ensure repository integrity and governance consistency
+
+## Document Owner
+
+The document owner shall:
+
+- maintain document accuracy
+- initiate review when updates are needed
+- ensure metadata is complete
+- coordinate revisions and corrections
+- ensure the document is moved through the proper lifecycle state
+
+## Reviewers
+
+Reviewers shall:
+
+- evaluate assigned documents for accuracy and applicability
+- provide timely feedback
+- identify conflicts, ambiguity, or missing controls
+
+## Operations Staff
+
+Operations Staff shall:
+
+- use active documents as authoritative references
+- support document updates where assigned
+- avoid relying on draft or retired documents for active operations
+
+# Document Registers and Evidence
+
+The following records must be maintained:
+
+- `policy-register.csv`
+- `document-control-log.csv`
+- `review-calendar.csv`
+- `exception-register.csv` when applicable
+
+Approval, review, exception, and retirement evidence should be preserved under the `evidence/` structure when required by the document type or business need.
+
+# Exceptions
+
+Exceptions to this policy must be documented, justified, approved, time-bounded where appropriate, and recorded as controlled exception records.
+
+No informal exception overrides this policy.
+
+# Compliance and Enforcement
+
+Failure to maintain document control may result in:
+
+- use of outdated or unauthorized guidance
+- inconsistent business execution
+- loss of approval traceability
+- reduced audit readiness
+
+Noncompliant documents may be withdrawn from active use until corrected.
+
+# Review and Revision History
+
+| Version | Date | Description | Author | Approver |
+|---|---|---|---|---|
+| 1.0 | 2026-04-03 | Initial active release | Business Owner | Business Owner |

policies/active/governance/KC-PRO-GOV-001-policy-review-and-retirement-procedure.md

@@ -0,0 +1,192 @@
+---
+document_id: KC-PRO-GOV-001
+title: Policy Review and Retirement Procedure
+document_type: Procedure
+domain: Governance
+version: 1.0
+status: Active
+owner: Business Owner
+reviewers:
+  - Operations Staff
+approver: Business Owner
+effective_date: 2026-04-03
+next_review_date: 2027-04-03
+supersedes: None
+related_documents:
+  - KC-POL-GOV-001
+related_systems:
+  - Policy Repository
+  - Forgejo Git
+  - Compliance Evidence Repository
+retention_period: 3 years
+confidentiality: Internal
+---
+
+# Purpose
+
+This procedure defines the steps used to review active controlled documents and to retire documents that are superseded, obsolete, or no longer applicable.
+
+# Scope
+
+This procedure applies to all controlled documents maintained under the Kell Creations policy repository structure.
+
+# Preconditions
+
+Before starting this procedure, the following should exist:
+
+- the target document is identified
+- the current version is available in the repository
+- the owner and approver are known
+- supporting review or retirement rationale is available
+
+# Procedure Steps
+
+## A. Periodic Review Process
+
+### 1. Identify review candidate
+
+Identify a document for review using one or more of the following:
+
+- scheduled review date
+- business process change
+- system change
+- regulatory or governance update
+- issue discovered during operations
+- owner-requested review
+
+### 2. Confirm current document state
+
+Verify:
+
+- document ID
+- version
+- current status
+- owner
+- file location
+- related documents
+- next review date
+
+### 3. Evaluate the document
+
+Review the document for:
+
+- continued applicability
+- accuracy
+- clarity
+- completeness
+- consistency with current business practice
+- consistency with related architecture, systems, and workflows
+
+### 4. Determine review outcome
+
+Select one of the following outcomes:
+
+- no change required
+- revise and resubmit
+- supersede with a new version
+- retire document
+
+### 5. Record review result
+
+Update the appropriate records, including:
+
+- `review-calendar.csv`
+- `document-control-log.csv`
+
+If no change is required, update the next review date and close the review cycle.
+
+## B. Revision and Supersession Process
+
+### 6. Create revised draft
+
+If revision is required, create or update the next version in the appropriate `drafts/` area.
+
+### 7. Route for review
+
+Move or track the revised document through the `review/` state and gather reviewer input.
+
+### 8. Obtain approval
+
+Obtain formal approval from the named approver.
+
+### 9. Publish revised version
+
+After approval:
+
+- place the approved document in the correct `active/` location
+- update version and effective date
+- update the document register
+- log the transition in the control log
+
+### 10. Retire superseded version
+
+Move the superseded active version to the appropriate `retired/` location and record the supersession in the control log.
+
+## C. Retirement Process
+
+### 11. Identify retirement basis
+
+A document may be retired because it is:
+
+- replaced by a newer version
+- no longer applicable
+- obsolete due to process or system change
+- withdrawn by management decision
+
+### 12. Confirm retirement impact
+
+Before retiring the document, confirm:
+
+- no current dependency requires it to remain active
+- users can be directed to a replacement, if applicable
+- related records are updated
+- evidence of the retirement decision is captured when needed
+
+### 13. Obtain retirement approval
+
+The named approver must approve retirement before the document is removed from the active set.
+
+### 14. Move document to retired state
+
+Move the document to the matching path under `retired/`.
+
+Do not delete retired controlled documents unless a separate retention rule explicitly authorizes deletion.
+
+### 15. Update records
+
+Update:
+
+- `policy-register.csv`
+- `document-control-log.csv`
+- `review-calendar.csv` as applicable
+
+### 16. Preserve evidence
+
+Store supporting evidence in the appropriate evidence folder when required, including:
+
+- approval note
+- review outcome
+- supersession reference
+- retirement rationale
+
+# Outputs
+
+This procedure should result in one or more of the following:
+
+- updated active document
+- retired document
+- updated review date
+- updated registers and control log
+- retained approval or retirement evidence
+
+# Exceptions and Escalation
+
+If review cannot be completed on time, or if ownership, applicability, or replacement status is unclear, escalate to the Business Owner.
+
+If an active document appears unsafe, misleading, or materially outdated, it should be flagged for immediate review and may be temporarily withheld from operational use pending decision.
+
+# Review and Revision History
+
+| Version | Date | Description | Author | Approver |
+|---|---|---|---|---|
+| 1.0 | 2026-04-03 | Initial active release | Business Owner | Business Owner |

policies/register/document-control-log.csv

@@ -0,0 +1 @@
+timestamp,document_id,action,from_status,to_status,version,performed_by,approved_by,notes

policies/register/exception-register.csv

@@ -0,0 +1 @@
+exception_id,related_document_id,title,owner,approver,status,effective_date,expiration_date,notes

policies/register/policy-register.csv

@@ -0,0 +1 @@
+document_id,title,document_type,domain,version,status,owner,approver,effective_date,next_review_date,supersedes,file_path

policies/register/review-calendar.csv

@@ -0,0 +1 @@
+document_id,title,owner,current_version,status,next_review_date,review_cycle,notes

policies/templates/exception-template.md

@@ -0,0 +1,51 @@
+---
+document_id: KC-EXC-XXX-001
+title: Exception Title
+document_type: Exception
+domain: Domain Name
+version: 0.1
+status: Draft
+owner: Business Owner
+reviewers:
+  - Operations Staff
+approver: Business Owner
+effective_date: TBD
+next_review_date: TBD
+supersedes: None
+related_documents: []
+related_systems: []
+retention_period: 3 years
+confidentiality: Internal
+---
+
+# Exception Summary
+
+Describe the requested exception.
+
+# Related Policy or Standard
+
+List the governing document and requirement being excepted.
+
+# Business Justification
+
+Explain why the exception is needed.
+
+# Risk and Impact
+
+Describe operational, financial, security, or compliance impact.
+
+# Compensating Controls
+
+List temporary or alternate controls.
+
+# Approval
+
+- Approver:
+- Decision:
+- Expiration Date:
+
+# Review and Revision History
+
+| Version | Date | Description | Author | Approver |
+|---|---|---|---|---|
+| 0.1 | TBD | Initial draft | TBD | TBD |

policies/templates/form-template.md

@@ -0,0 +1,38 @@
+---
+document_id: KC-FRM-XXX-001
+title: Form Title
+document_type: Form
+domain: Domain Name
+version: 0.1
+status: Draft
+owner: Business Owner
+reviewers:
+  - Operations Staff
+approver: Business Owner
+effective_date: TBD
+next_review_date: TBD
+supersedes: None
+related_documents: []
+related_systems: []
+retention_period: 3 years
+confidentiality: Internal
+---
+
+# Form Purpose
+
+Describe what this form captures.
+
+# Form Fields
+
+- Requester Name:
+- Date:
+- Document ID:
+- Reason:
+- Impact:
+- Requested Approval:
+- Approver Decision:
+- Approval Date:
+
+# Usage Notes
+
+Describe how to complete, approve, store, and retain this form.

policies/templates/policy-template.md

@@ -0,0 +1,56 @@
+---
+document_id: KC-POL-XXX-001
+title: Policy Title
+document_type: Policy
+domain: Domain Name
+version: 0.1
+status: Draft
+owner: Business Owner
+reviewers:
+  - Operations Staff
+approver: Business Owner
+effective_date: TBD
+next_review_date: TBD
+supersedes: None
+related_documents: []
+related_systems: []
+retention_period: 3 years
+confidentiality: Internal
+---
+
+# Purpose
+
+State why this policy exists and what business objective it supports.
+
+# Scope
+
+Define what people, processes, systems, and records are covered.
+
+# Policy Statement
+
+State the governing rules, expectations, and required controls.
+
+# Roles and Responsibilities
+
+## Owner
+Define ownership responsibilities.
+
+## Staff
+Define staff responsibilities.
+
+## Approver
+Define approval authority.
+
+# Compliance and Enforcement
+
+Explain how compliance is expected, monitored, and enforced.
+
+# Exceptions
+
+State how exceptions are requested, approved, documented, and reviewed.
+
+# Review and Revision History
+
+| Version | Date | Description | Author | Approver |
+|---|---|---|---|---|
+| 0.1 | TBD | Initial draft | TBD | TBD |

policies/templates/procedure-template.md

@@ -0,0 +1,51 @@
+---
+document_id: KC-PRO-XXX-001
+title: Procedure Title
+document_type: Procedure
+domain: Domain Name
+version: 0.1
+status: Draft
+owner: Business Owner
+reviewers:
+  - Operations Staff
+approver: Business Owner
+effective_date: TBD
+next_review_date: TBD
+supersedes: None
+related_documents: []
+related_systems: []
+retention_period: 3 years
+confidentiality: Internal
+---
+
+# Purpose
+
+Describe the operational task this procedure supports.
+
+# Scope
+
+Define when and where this procedure applies.
+
+# Preconditions
+
+List prerequisites, inputs, or access requirements.
+
+# Procedure Steps
+
+1. Step one
+2. Step two
+3. Step three
+
+# Outputs
+
+List records, approvals, notifications, or resulting updates.
+
+# Exceptions and Escalation
+
+Describe what to do when the process cannot proceed normally.
+
+# Review and Revision History
+
+| Version | Date | Description | Author | Approver |
+|---|---|---|---|---|
+| 0.1 | TBD | Initial draft | TBD | TBD |

policies/templates/standard-template.md

@@ -0,0 +1,47 @@
+---
+document_id: KC-STD-XXX-001
+title: Standard Title
+document_type: Standard
+domain: Domain Name
+version: 0.1
+status: Draft
+owner: Business Owner
+reviewers:
+  - Operations Staff
+approver: Business Owner
+effective_date: TBD
+next_review_date: TBD
+supersedes: None
+related_documents: []
+related_systems: []
+retention_period: 3 years
+confidentiality: Internal
+---
+
+# Purpose
+
+Define the control objective or consistency objective.
+
+# Scope
+
+State where this standard applies.
+
+# Standard Requirements
+
+- Requirement 1
+- Requirement 2
+- Requirement 3
+
+# Measurement or Verification
+
+Describe how conformance is checked.
+
+# Exceptions
+
+Describe how deviations are handled.
+
+# Review and Revision History
+
+| Version | Date | Description | Author | Approver |
+|---|---|---|---|---|
+| 0.1 | TBD | Initial draft | TBD | TBD |