Skip to content

CIMP

CIMP (Change Intelligence Management Platform) is a governance framework for designing, evaluating, and executing changes in complex systems.

CIMP sits between intent and execution.

It does not replace engineering practices, tools, or teams.
It makes change intentional, accountable, observable, and learnable.

Why CIMP exists

Modern systems fail not because of bad code, but because of unmanaged change.

Typical symptoms:

  • changes are made without explicit intent
  • risks are known but undocumented
  • constraints exist only “in people’s heads”
  • incidents are investigated, but lessons are lost
  • decisions disappear after the PR is merged

In most systems, learning stops at investigation.
Fixes are applied, but rules do not change.
The same class of failure returns in a different form.

CIMP exists to address this gap.

It provides a shared language and structure for changes — before, during, and after they happen.

What CIMP is

CIMP is:

  • a conceptual framework
  • a set of governance principles
  • a shared vocabulary for change
  • a lifecycle model for intent, execution, incidents, and learning
  • a way to preserve architectural memory over time

CIMP defines how experience from changes and incidents
is converted into durable system knowledge over time.

CIMP can be used:

  • without AI
  • without new tools
  • without changing your tech stack

What CIMP is not

CIMP is not:

  • a CI/CD system
  • a project management tool
  • a ticketing system
  • a code generator
  • a replacement for engineering judgment

CIMP does not automate decisions.
It makes decisions explicit and traceable.

See:
👉 docs/philosophy/what-cimp-is-not.md

CIMP builds upon and synthesizes ideas from established practices, including:

  • Architecture Decision Records (ADR) — explicit recording of architectural decisions
    (Michael Nygard's original ADR format)
  • RFC processes — structured change proposals and review
    (inspired by IETF RFC process and internal RFC practices at tech companies)
  • Post-mortem culture — learning from incidents and failures
    (practices from SRE and incident response communities)
  • Design by Contract / Invariant-driven design — defining and protecting system boundaries
    (concepts from Eiffel, formal methods, and constraint-based design)

CIMP's contribution is not the invention of new practices,
but the unified framework that connects Intent, Change, Decisions,
Incidents, and Architecture Memory into a single governance system.

Core concepts

CIMP is built around a small set of fundamental concepts.

Each concept is intentionally minimal and explicitly defined.

These concepts apply equally to:

  • code
  • infrastructure
  • data
  • processes
  • organizations

Lifecycles

CIMP defines three related lifecycles.

They describe how change and failure evolve over time.

Why changes fail

CIMP is grounded in analysis, not prescription.

A detailed explanation of structural failure modes can be found here:

👉 docs/philosophy/why-changes-fail.md

Governance

CIMP prioritizes stability and clarity over speed.

The governance model defines how the framework evolves:

👉 GOVERNANCE.md

Practical application

CIMP does not require tooling.

Practical templates and usage patterns live in a separate repository:

👉 cimp-practices

This repository is not part of the canon and does not define or modify canonical concepts.

Practices and checklists are treated as outputs of learning,
not opinions or best practices.

Status

CIMP is under active development as an open framework.

  • Concepts are stable
  • Practices evolve
  • Tooling is optional

License

Apache License 2.0