Repository Standards

This is the operational rulebook beneath the Constitution — how files are named, where they live, how changes get traced, and what a commit or pull request needs to say. Most readers will refer back to a specific section (§3 for “where does this go,” §7–§9 for “how do I record this change”) rather than reading it start to finish.

Contents

• 1. Purpose
• 2. Repository Principles
• 3. Top-Level Structure
• 4. File Naming
• 5. Markdown Standard
• 6. Source Labels
• 7. Issue-Based Improvement Audit
• 8. Branch and Pull Request Standards
• 9. Commit and Changelog Standards
• 10. Updating Living Documents
• 11. What Does Not Belong Here
• 12. Review Cadence
• 13. Revision History

1. Purpose

These standards define how this repository’s files are named, organized, updated, secured, reviewed, and traced through Git history. They keep the repository readable, auditable, and proportionate as the corporation evolves. Read this document together with the Constitution (CONST-1001) and the Issue and Change Audit Standard (ESS-008).

2. Repository Principles

Preserve original source documents. Maintain current-state summaries separately from historical records. Give each material fact one primary home. Record decisions rather than burying them in notes or chat history. Store credentials outside GitHub. Add structure only when it has an immediate purpose. Use Issues as the incremental-improvement ledger, and branches and pull requests for material changes wherever practical, so that Git history, Issues, pull requests, and the changelog tell one coherent story.

3. Top-Level Structure

This repository is organized by business arm and governance function rather than by document type:

/
├── README.md
├── CLAUDE.md
├── governance/          — constitution, principles, manifesto, standards, decision log, changelog
│   └── standards/        — Enterprise Standards (ESS-* series)
├── registers/            — authoritative inventories: records, decisions, digital/brand assets
├── company/
│   ├── legal/
│   │   ├── corporate/    — incorporation, registration, share records
│   │   └── immigration/  — the C11 case docket (see security.md for the governed exception)
│   ├── strategy/         — business plan, roadmap, growth plan, org structure, current status
│   └── brand/            — shared positioning and voice
├── consulting/
│   ├── strategy/
│   ├── curriculum/
│   └── operations/
├── publishing/
│   ├── strategy/
│   ├── manuscripts/
│   └── operations/
├── knowledge/             — architecture decisions, technical reviews, institutional understanding
└── archive/               — superseded documents, kept for their point-in-time reasoning

flowchart LR
    G["governance/"] --> R["registers/"]
    R --> CL["company/legal/"]
    R --> CS["company/strategy/ · consulting/ · publishing/"]
    CS --> K["knowledge/"]
    CS -.superseded.-> AR["archive/"]
    CL -.superseded.-> AR

4. File Naming

For corporate records in company/legal/, use YYYY-MM-DD - Clear Document Name.ext. Avoid ambiguous suffixes such as final, final-final, updated, or new; where versions are genuinely needed, use a controlled suffix such as v1.0.

For living strategy and governance documents (company/strategy/, governance/, and similar), use a stable lowercase-kebab-case filename with no date in the name — these are living documents edited in place, not dated snapshots, so Git history is the changelog.

5. Markdown Standard

A significant living document should include, where relevant: a clear title, an executive summary or purpose statement, sufficient background and context, current-state facts or governing principles, risks/limitations/open questions, cross-links to related records and knowledge, and — for governance-tier documents — a Document Control metadata block. Use ISO dates and Canadian-dollar notation such as CAD 450. Favor detailed, explanatory prose over terse bullets for narrative content. The formatting techniques that make that prose readable — executive summaries, tables of contents, callouts, diagrams, collapsible sections — are defined in ESS-002.

6. Source Labels

Use these labels where a fact’s reliability matters:

• Confirmed: directly supported by an authoritative record.
• Reported: communicated by an advisor or vendor but not independently verified.
• Assumption: believed likely but unsupported.
• Recommendation: proposed action, not approved.
• Decision: approved and recorded in governance/decision-log.md.
• Open question: requires verification or decision.

7. Issue-Based Improvement Audit

GitHub Issues are the auditable backlog for incremental improvement. Create or link an Issue for material documentation, architecture, compliance, verification, security, operational, record-gap, or strategic work. Preferred traceability:

Issue → Branch → Commit(s) → Pull Request → Review → Merge → Changelog → Issue Closure

The full standard is ESS-008.

8. Branch and Pull Request Standards

Recommended branch patterns:

governance/<short-description>
docs/<issue-number>-<short-description>
compliance/<issue-number>-<short-description>
records/<issue-number>-<short-description>
strategy/<issue-number>-<short-description>
security/<issue-number>-<short-description>

Each material pull request should state its purpose, scope, material changes, affected documents, compliance/governance/security impact, open questions, and whether it authorizes any corporate action. Use Closes #<issue> when the merge completes the Issue.

9. Commit and Changelog Standards

Use concise conventional commit messages, for example:

feat(governance): establish repository constitution
docs(strategy): publish current status
records: add signed share certificate
compliance: update annual filing deadline
security: record immigration-document exception

Every material commit must be represented in the changelog with a short SHA and title, a plain-language change outline, an ISO 8601 timestamp, the related Issue and PR numbers where applicable, and its source-of-truth/compliance/governance/security impact.

10. Updating Living Documents

When a material corporate fact changes: create or update the related Issue; add the authoritative source record; update the relevant company/strategy/ document(s); record discretionary approval in the decision log; update current-status.md and roadmap.md where necessary; add the material commits to the changelog; and close the Issue with the final outcome after merge. Do not rewrite history to make an old document appear current.

11. What Does Not Belong Here

Do not store passwords, MFA or recovery codes, private keys, full credit-card numbers, personal banking credentials, or unredacted SIN records. See security.md for the full policy, including the governed exception for the C11 immigration docket already stored in company/legal/immigration/.

12. Review Cadence

Review open Issues monthly while the repository is actively being built out. Review current-status.md monthly during the foundation phase. Review business-plan.md after every material corporate or commercial change, and at least annually. Review access permissions and security at least annually.

13. Revision History