ESS-008 — Issue and Change Audit Standard
| Field | Value |
|---|---|
| Document ID | ESS-008 |
| Title | Issue and Change Audit Standard |
| Status | Approved baseline |
| Owners | Arva Yusuf Ezzi and Vijay Panangipally |
| Effective Date | 2026-08-23 |
| Review Cycle | Annual and upon material workflow change |
Important
GitHub Issues are the auditable improvement ledger for this repository. They preserve the problem, rationale, ownership, implementation path, and closure outcome behind incremental change.
1. Executive Summary
This repository uses GitHub Issues to ensure that repository improvements do not appear as unexplained edits. An Issue captures why a change is needed before or while implementation occurs. The linked branch, commits, pull request, review discussion, changelog entry, and closure note then form a traceable chain from identified need to completed outcome.
Trivial typographical corrections may be committed without a dedicated Issue, but material changes should be linked to one.
2. When an Issue Is Required
Create or link an Issue when work involves: a new material document, policy, standard, or playbook; correction of a substantive factual error; a missing or conflicting corporate record; a compliance deadline or unresolved CRA matter; a change to source-of-truth hierarchy; a security or privacy concern; ownership, directors, officers, jurisdiction, name, tax accounts, or registered office; a new operational workflow; repository restructuring; strategic analysis that may lead to corporate action; or recurring improvement requiring follow-up.
3. Issue Types
| Type | Purpose | Example title |
|---|---|---|
| Architecture | Repository design or standards | Architecture: Define records-to-knowledge lineage |
| Compliance | Filing, CRA, provincial, or governance obligation | Compliance: Confirm first BC annual report deadline |
| Record Gap | Missing, incomplete, or conflicting evidence | Record Gap: Obtain central securities register |
| Documentation | New or improved living documentation | Documentation: Publish current status |
| Operations | Process, checklist, or control | Operations: Establish receipt-capture workflow |
| Security | Access, privacy, or sensitive-data treatment | Security: Review immigration records before upload |
| Strategy | Future option requiring structured analysis | Strategy: Assess Ontario continuance options |
| Verification | Fact requiring independent confirmation | Verification: Confirm GST/HST filing frequency |
| Maintenance | Recurring or housekeeping work | Maintenance: Conduct annual repository review |
4. Required Issue Content
Purpose; background; scope; evidence or sources; compliance and governance impact; acceptance criteria; owner; dependencies; implementation link (branch/PR); closure outcome.
5. Traceability Chain
Issue → Branch → Commit(s) → Pull Request → Review/Approval → Merge → Changelog → Issue Closure
Branches should reference the Issue number where practical. Pull requests should use
Closes #<issue> or Resolves #<issue> when merge completes the work.
governance/changelog.md must identify the related Issue and PR for material
entries.
6. Issue Lifecycle
flowchart LR
A[Identified] --> B[Triaged]
B --> C[Ready]
C --> D[In Progress]
D --> E[In Review]
E --> F[Completed]
E --> D
B --> G[Deferred]
B --> H[Not Pursued]
G --> B
Issues should remain open until their acceptance criteria are met or a clear deferred/not-pursued rationale is recorded.
7. Backlog Hygiene
Review open Issues monthly while this repository is actively being built out. Assign an owner to every actionable Issue. Record a revisit date or trigger for deferred work. Close duplicates by linking to the surviving Issue. Do not delete rejected ideas; close them with rationale.