Product review method

Review one claim at a time

The model should not be approved as one large document. Reviewers verify individual objects, behaviours, rules, and scenarios.

Object checklist

• The definition names one real clinical concept.
• The identity remains meaningful over time.
• Fields are intrinsic domain information rather than implementation convenience.
• Relationships and cardinalities match real clinical work.
• Behaviours use recognizable business intent.
• Rules cover the important invalid cases.
• Outcomes describe meaningful facts.
• Corrections and historical reconstruction are sufficient.
• Privacy and blinding boundaries are correct.
• The object is not an unnecessary duplicate of another concept.

Behaviour checklist

• The correct object or policy owns the behaviour.
• Required inputs are domain objects or values.
• Preconditions are complete.
• Successful outcome is unambiguous.
• Refusal reasons are meaningful to the business.
• Authority and evidence requirements are clear.
• Repeated, corrected, withdrawn, and superseded cases are explained.
• The behaviour does not rely on a database, API, or UI concept.

Journey checklist

• Every step uses a named object and behaviour.
• Intended, planned, actual, observed, and decided truth remain distinguishable.
• No step silently changes several owners at once.
• Failed, delayed, partial, and conflicting cases are representable.
• The complete journey is reconstructable from outcomes and evidence.

Recording a review

For each claim, record:

Claim:
Reviewer:
Decision: verified | verified with limits | disputed | deferred
Supported scenarios:
Counterexample or missing case:
Required change:
Rationale:

The purpose is not unanimous terminology. It is explicit, testable product meaning.