Skip to content

CIMP Canon v1.0

This document fixes CIMP Canon v1.0.

The canon defines the stable conceptual core of CIMP.
Everything outside this scope is allowed to evolve.


What the Canon is

The CIMP Canon is a system of concepts, definitions, and principles
that governs how changes are understood, evaluated, and remembered
in complex systems.

Remembering includes the conversion of experience from changes and incidents
into durable rules, constraints, and architectural memory over time.

The canon defines:

  • how Intent is formed
  • how Change is bounded and governed
  • how Incidents are understood
  • how Decisions and assumptions are preserved over time

The canon does not define tools, processes, or implementations.


Canon v1.0 scope

The following documents constitute CIMP Canon v1.0.

Philosophy

  • docs/philosophy/what-cimp-is-not.md
  • docs/philosophy/why-changes-fail.md

Core Concepts

  • docs/concepts/intent.md
  • docs/concepts/scope.md
  • docs/concepts/constraints.md
  • docs/concepts/change.md
  • docs/concepts/decisions.md
  • docs/concepts/incident.md
  • docs/concepts/remediation.md
  • docs/concepts/kill-criteria.md
  • docs/concepts/architecture-memory.md

Lifecycles

  • docs/lifecycle/change-lifecycle.md
  • docs/lifecycle/incident-lifecycle.md
  • docs/lifecycle/change-learning-loop.md

Governance

  • GOVERNANCE.md
  • BRANDING.md

Index

  • README.md

Only these documents are part of the canon.


What is explicitly not canon

The following are not part of the canon:

  • templates and checklists
  • examples and case studies
  • tools and automation
  • implementation details
  • organizational processes
  • workflows or approval models

These may evolve independently and must not redefine canonical concepts.


Stability guarantees

For Canon v1.0:

  • core concepts are considered stable
  • terminology is fixed
  • meanings must not drift silently
  • changes require explicit governance

Any modification to canonical meaning requires:

  • an explicit proposal
  • documented rationale
  • a versioned canon update

Versioning

  • Canon versions are immutable once fixed
  • Amendments require a new canon version (e.g. v1.1, v2.0)
  • Minor clarifications without semantic change may be documented separately

A canon version reflects conceptual stability, not project maturity.


Authority and governance

Canon evolution is governed by GOVERNANCE.md.

No single document may override the canon by implication.

Disagreements must be resolved by:

  • clarifying concepts
  • or explicitly versioning change

Final note

The canon exists to outlive individuals, teams, and tools.

If applied consistently,
CIMP Canon v1.0 should make systems safer to change over time.