Skip to content

A waived acceptance should leave the obligation somewhere #5

Description

@schickling-assistant

Problem

The ontology admits a waiver as a legitimate kind of Evidence — "a test result, a measurement, a waiver". Allowing it is right: real plans carry work that ships without the check that was supposed to guard it, and a model that refuses to represent that just pushes it outside the model.

It has a failure mode worth designing against. A waiver satisfies the criterion. Once it is recorded the Step is accepted, readiness moves past it, and the obligation the waiver stood in for exists nowhere in the Plan. Structurally, a Plan where the work was done and a Plan where it was waived are identical: both show an accepted Step with a satisfied criterion. The only surviving trace is one evidence record whose kind happens to be waiver, and nothing makes anybody look at it again.

This sits awkwardly against CMP.DM-R13 — "Only Compass judges completion... completion follows from the Step's own acceptance criterion." That is a strong guarantee precisely because criteria are hard to satisfy by assertion. A waiver is the one evidence kind that is satisfiable by assertion by construction.

Prior design worth borrowing

A predecessor in-house planning design hit this and settled it as a rule: an unresolved review finding may be fixed, dismissed with a stated reason, or converted into a unit of work attached to the next point where it must be dealt with — but never carried by a generic time-boxed exception. Its stated reasoning:

If work proceeds before the gap is fixed, the gap remains visible as [a unit of work] attached to the next appropriate phase, so the [plan] cannot silently carry holes forward.

It refused expiring waivers explicitly, on the grounds that an expiry is a promise nobody is holding: it fires when nobody is looking, or it is quietly extended, and either way the plan changed without anyone deciding it should.

Translated into this model

The mechanism already exists and needs no new concept. Waiving something means two things, not one:

  1. recording the waiver evidence, and
  2. a revision that adds a Step carrying the obligation, with the waived work as its acceptance criterion, and edits whatever must not ship without it to depend on that new Step.

Step 2 is an ordinary revision with an ordinary Rationale — so why the waiver was acceptable lands in the chain that is the point of the system, instead of in an evidence payload nobody re-reads.

What is actually being asked

Not a mechanism. A stated position, and possibly one small report:

  • Should the docs say that a waiver is a deferral rather than a discharge — that it is expected to be paired with a Step carrying the obligation forward? CMP.DM-R13c deliberately leaves the evidence vocabulary undeclared, so Compass structurally cannot special-case the word "waiver" and should not try. But the docs can say what good practice looks like, and this is the only lever available given that constraint.
  • Should "accepted only by waiver" be visible? CMP.DM-R13d already checks a record against the criteria it could contribute to at the moment it is written, so the write path is somewhere this could be observed. It belongs in the aggregate report (see the companion issue on extending verification to model-level conditions) rather than as a refusal — this is a legitimate act, not a mistake.
  • Expiring evidence deserves an explicit no. An acceptance that silently withdraws on a date is a plan that changes without anyone authoring the change, which CMP-R02 and CMP-R10 both stand against, and which would need a clock inside a system whose evaluation environment deliberately has none (CMP-R12). Withdrawal by a further record is already the model — CMP.DM-R13d says a record matching a negated criterion "withdraws acceptance rather than granting it" — and that one has an author.

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