Management of Protocols

VE-P1 v0.2.0 (2026)

Draft for comment — not citable in a conformance claim

Drafted under VE-D1 v0.4.0. Comments to the editor.

DOI: 10.67330/k1e2bp86


1. Scope

1.1 What this protocol covers. The lifecycle of a protocol published by The Valuation Engineer: how one is proposed, reviewed, exposed for comment, released, maintained, revised and withdrawn, and what record each step leaves. Its object is a protocol; its output is a released version together with the record of how it was reached.

1.2 What this protocol does not cover. It does not govern how a protocol is written — designation, versioning, scope form, requirement language and conformance claims are VE-D1’s subject. It does not govern the Journal’s editorial process for articles, which is not a protocol. It does not determine whether any protocol is technically correct: this procedure can be followed exactly and produce a bad protocol, and says so rather than implying otherwise.

1.3 It does not supersede legal requirements. Nothing here creates an obligation on any valuer (appraiser), and adoption of any protocol by any authority is that authority’s act.

1.4 What judgment it does not remove. Whether a comment is substantive, whether a change alters a requirement, and whether a protocol is ready for release are determinations left to the editor and named here so they are not mistaken for mechanical outcomes. What the protocol requires is that each be recorded with its reason, not that it be made in any particular way.

1.5 Terms are as defined in the Journal’s dictionary. Protocol means a specific instruction for the execution of a defined task — ordinarily a valuation task; this one governs a task of the Journal’s own. A protocol is not a standard: standards belong to the professional bodies that issue them. Editor means the person responsible for the protocol series. Sponsor means the person who proposed a protocol or a change to one.

2. Proposal

R-1shall A proposal for a new protocol, or for a change to one, be recorded before work begins, and state: the task it addresses, why existing protocols and external standards do not address it, its intended scope, and its sponsor.

R-2shall A proposal that would duplicate or narrow an existing protocol’s scope state which protocol, and why the overlap is intended.

R-3should A proposal identify any external standard it would reference normatively, by version, at the time of proposal rather than at drafting.

3. Drafting

R-4shall A draft carry the version of VE-D1 under which it was drafted.

R-5shall A draft be numbered v0.x.y and be marked, on its first page, as not citable in a conformance claim.

R-6shall A draft publish its machine-readable requirement set and its conformance suite, in whatever state they are in, alongside its prose. A draft whose requirement set does not yet exist is a proposal, not a draft.

4. Review

R-7shall A draft be exposed for review to a named roster of reviewers for a stated period of not less than thirty days before its first release, and the roster and the period be published with the draft.

R-8shall The Journal state, in each draft, that it does not operate a public comment process; and where a protocol’s subject affects parties not on the roster, the draft name whom it would have consulted. A limitation of process is disclosed, not concealed.

R-9shall Every comment received from a reviewer be recorded, with its author unless the author asks otherwise, and be disposed of as accepted, accepted with modification, or declined — each with a stated reason.

R-10shall The comment record be published with the released version and remain published for as long as that version does.

R-11should A comment that identifies a requirement as unverifiable — one no suite could check and no artifact could evidence — be treated as substantive, since a requirement of that kind returns conformance to attestation.

5. Release

R-12shall A release be assigned a version under VE-D1 §1.3, and the classification of the change — MAJOR, MINOR or PATCH — be recorded with its reason.

R-13shall A release state what it supersedes, and the superseded version be amended to state what supersedes it. Nothing else in a released version is ever edited.

R-14shall A release not occur while the conformance suite fails against the protocol’s own requirement set, or while a shall in the prose has no entry in the requirement set, or an entry no shall.

R-15shall A superseded version remain published, because claims made under it remain evaluable.

6. Maintenance

R-16shall Each protocol in force carry a stated review interval, not exceeding five years.

R-17shall A review end in a new version, a recorded reaffirmation issued as a PATCH, or withdrawal. A review that ends in silence is a failure of this protocol, and the absence is reported.

R-18shall A change in a normatively referenced external standard be recorded within ninety days of the Journal becoming aware of it, together with the determination whether the protocol moves and under what classification. The protocol does not follow the reference silently.

R-19should A requirement due to be removed be marked deprecated in one release before the release that removes it, so that a standing claim does not become unevaluable without notice.

7. Withdrawal

R-20shall A withdrawal state its reason and its effective date, and whether claims made under the withdrawn versions remain evaluable.

R-21shall A withdrawn protocol’s number be retired and never reused.

8. Records

R-22shall The following be published with each released version: the proposal, the comment record and its dispositions, the change classification and its reason, the requirement set, the conformance suite, and the suite’s result against the protocol’s own requirements.

R-23shall A determination this protocol leaves to judgment (§1.4) be recorded with its reason at the time it is made, not reconstructed afterwards.

9. Conformance

Conformance with VE-P1 is a property of the Journal’s process, not of any valuer’s work. The suite for this protocol takes the published record of a release and reports, per requirement, pass, fail, or not-applicable-with-reason.

The Journal publishes its own conformance report for every protocol it releases. A protocol process that asks others for evidence and offers none would be making exactly the claim this framework exists to refuse.

Open in this draft