Skip to content

Record a review that concluded the plan should not change #4

Description

@schickling-assistant

Problem

CMP.DM-R07b refuses a version that alters no Step and no goal, and names the cost outright:

The cost is that a deliberate non-change cannot be recorded.

That cost is larger than it looks when read against the vision, which holds that the value of the system is "the reasoning that moved it from the last guess to this one." Concluding, after looking hard, that the plan is still right is reasoning of exactly that kind — and it is currently the one conclusion the Rationale chain cannot hold.

The observable consequence: a reader arriving cold at a Plan whose last version is a month old cannot distinguish "reviewed twice since, still correct, deliberately unchanged" from "abandoned." Both are a lineage that stopped. The first is a healthy plan and the second is dead work, and the vision's central promise — that someone arriving cold can read why the plan is what it is — fails precisely where "why" is "because we checked and it held."

Shape

A predecessor in-house planning design handled this with a record that was deliberately not a version. That is the right layer here too: decision 0002 already places review among the things that "are Progress Events and never create a Plan Version."

Distilled to what survives:

  • It cites the head version it was taken against. Under divergence that is one head member, chosen deterministically and disclosed, the way CMP.DM-R11a already requires of a progress record.
  • It carries what was examined and what was found. Prose is fine here — unlike an acceptance criterion, nothing folds over it.
  • It carries an outcome from a small closed set. The predecessor used continue | replan | integrate | pause | cancel, which is more states than this model needs. The honest set here is closer to continue | revise | abandon, where revise is not the change itself but a statement that one is owed — the version that follows carries its own Rationale as usual, and the two are linked by the review naming the version it was taken against.
  • It is append-only and immutable, like every other progress record. Reconsidering later is a further record, never an edit (CMP.DM-R11).

Where this sits in the current contract

  • Extends the progress layer. Progress kinds today are start, update, handoff, done, plus evidence, and all of them are recorded against a Stepcompass progress <plan> <step> <kind> takes the Step positionally. A review of the plan is about the Plan, so admitting it means the Step becoming optional. That is the same relaxation the companion issue on holding reasoning before Steps exist asks for, and the two should land together.
  • It does not weaken CMP.DM-R07b. The rule that a version must change something stays exactly as written; the non-change goes somewhere that mints no version. This is the cheapest available answer to a cost the requirement already admits it is paying.
  • It is committed content, not derived, so CMP-R14 and CMP.INT-R11 apply normally: it replicates, and it is not something a machine recomputes.
  • It feeds no criterion. Only evidence events feed acceptance; a review record is inert with respect to readiness, which keeps CMP.DM-R14 untouched.

Deliberately not proposed

The predecessor design also had a review that withheld work until it closed — a blocking checkpoint. That half does not transfer, and should not. The ontology states that "Compass has no separate gate concept, the acceptance predicate is the gate," and lists gate, check, approval, sign-off, definition-of-done under _Avoid_ for Acceptance. A review that must happen before a Step is accepted is already expressible as that Step's acceptance criterion reading a review-kind piece of evidence, with CMP.DM-R13b making the reviewer's identity a recorded field rather than a claimed one. Nothing new is needed for it.

What is missing is only the other half: the review that concludes nothing needs to change, and today leaves no trace anywhere.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions