Claim
State the property being tested without silently expanding it into a broader assurance claim.
Evidence & validation
Claims are not evidence.
BPM RED Academy separates capability claims, operational authority and validation evidence. Confidence is earned through defined boundaries, repeatable tests, preserved artifacts and accountable review.
Capability→Governed authority→Execution→Evidence
Evidence model
Every claim needs a boundary.
A model score or successful demo does not establish operational trust. The evidence package must identify what was tested, under which conditions, what failed, and who accepted the result.
Boundary
Define authority, policy, environment, inputs, tools, infrastructure and stop conditions.
Evidence
Preserve outputs, provenance, telemetry, exceptions, reviewer actions and acceptance records.
Status language
Public maturity is explicit.
These labels describe evidence maturity. They are not marketing grades, and they should not be interpreted beyond the stated test scope.
Defined, not yet executed
The claim, test design or acceptance gate exists, but no execution evidence is being asserted.
Observed in controlled work
Evidence exists from exploratory or bounded runs, but operational acceptance is not being claimed.
Repeated and inspectable
The behaviour has been observed under stated conditions with artifacts sufficient for technical review.
Accepted against defined criteria
A specific claim has passed a defined validation contract. The scope and limitations remain part of the claim.
Validation cycle
From hypothesis to evidence pack.
Assurance work follows a controlled sequence so failure is visible rather than averaged away.
1
Define the claim
What exactly must remain true?
2
Establish the boundary
Authority, policy, data, models, tools and infrastructure.
3
Execute & instrument
Run the workflow while preserving provenance and runtime evidence.
4
Repeat & challenge
Repeatability, variants, contradictory inputs and adversarial conditions.
5
Compare
Where relevant, test whether governance properties survive infrastructure changes.
6
Accept, reject or escalate
Human review closes the validation contract and records limitations.
Evidence pack
What a reviewable package should contain.
- Test claim and scope
- Environment and configuration identifiers
- Input set and policy state
- Outputs, exceptions and runtime logs
- Repeat / variant / adversarial results where applicable
- Reviewer decision and acceptance boundary
Public disclosure boundary
Evidence without unnecessary exposure.
Public material can describe methods, claims and selected results without publishing customer data, credentials, proprietary orchestration logic, private thresholds or security-sensitive deployment details.
Evidence is part of the runtime, not a slide added afterward.
The objective is not to make every system perfectly predictable. It is to make authority bounded, execution observable and failure reviewable.
Latest release
Evidence is useful only when its boundary is visible.
BPM-RN-001 publishes the current runtime baseline and explicitly keeps the independent cross-infrastructure repeat in the planned state.
BPM-RN-001
From Governance Runtime to Evidence
B300 runtime evidence, bounded workflow validation, limitations and the next independent portability test.
Evidence maturity: mixed / boundedOpen note →
Technical review
Need the evidence model behind a claim?
Qualified reviewers can request a controlled technical brief or discuss a scoped validation engagement.