Defined, not executed
Research question, method or next validation step exists, but no qualifying result is claimed.
Validation methodology
Define the claim before the result exists.
BPM validation is designed to reduce post-hoc interpretation: state the boundary, freeze the test contract, preserve the environment and accept that failure is a valid result.
01Claim boundary
What exactly is being asserted — and what is not.
02Authority boundary
Who or what may act, approve, override or escalate.
03Environment capture
Model, runtime, infrastructure, version and execution conditions.
04Acceptance contract
Metrics, evidence, PASS / PARTIAL / FAIL criteria.
05Execution
Run without moving the goalposts after results appear.
06Evidence pack
Logs, outputs, telemetry, hashes, reviewer actions and exceptions.
07Repeat / challenge
Independent, variant or adversarial runs when required by the claim.
08Publish bounded result
Promote only the evidence state the contract actually supports.
Evidence states
Public maturity is explicit.
A result can move forward only when the required evidence exists. A successful demo does not automatically become a validation claim.
Executed under exploration
Useful technical behaviour has been observed while method or acceptance conditions are still evolving.
Measured in a defined environment
The evidence supports a bounded statement about what happened in that execution context.
Acceptance contract satisfied
Required tests and evidence support the stated claim inside a defined boundary; this is not universal proof.
Failure discipline
No rerun-until-pass methodology.
Failed and partial runs are evidence. A rerun is a new event that must retain its relationship to the prior failure.
PASSAll required acceptance criteria and evidence fields are satisfied.
PARTIALUseful result exists, but at least one required gate remains incomplete.
FAILA required assertion, run, evidence element or authority constraint is not satisfied.
REMEDIATEDA documented change addresses a classified failure; the subsequent run remains separately identified.
Every material rerun should carry a reason code.
Failure classification, any change to environment or method, previous run reference and a new immutable run identity should be preserved.
Cross-infrastructure work
Compare invariants separately from infrastructure effects.
Portability claims require separating governance properties that should remain stable from performance variables that legitimately change with hardware, serving stack and scheduler conditions.
Governance invariants
- authority and approval boundary
- schema and controlled-output requirements
- escalation and fallback rules
- evidence completeness requirements
- failure classification and reviewer obligations
Infrastructure-dependent variables
- accelerator architecture and memory
- serving and attention backend
- precision and batching
- scheduler, storage and networking
- latency, throughput, energy and cost
Canonical example
See the methodology applied in RN-001.
Research Note 001 separates observed runtime evidence, bounded governance validation and the planned independent repeat.