Governance should be testable as runtime behaviour, not inferred from policy text.
AI governance is often described outside the execution path: a policy, review process or safety layer around a capable model. BPM RED Academy takes a narrower engineering position. Capability, operational authority and evidence are separate system properties. A model may be capable of producing or recommending an action without being authorised to decide, execute or bypass human review.
This research note documents the current evidence baseline behind that position and defines the next independent cross-infrastructure validation step. The baseline includes a single-GPU B300 execution of a full Llama 3.3 70B model with a runtime FinC2E v2 LoRA adapter, a preserved failure-to-recovery path, structured-output checks, telemetry and cryptographic evidence integrity. A separate governed reference workflow passed a full regression suite while explicitly retaining human review and disallowing autonomous decision authority.
The current evidence supports bounded runtime and governance claims under stated conditions. It does not establish universal safety, certification, production readiness, performance leadership or cross-infrastructure portability. The independent repeat is the next test, not a completed claim.
From claim to independent repeat.
Capability can increase faster than authority controls.
Modern AI systems can route between models, call tools, generate structured outputs and participate in operational workflows. If governance remains only an external compliance process, the runtime may still lack a machine-enforceable answer to five practical questions: which component is eligible, what it may do, when it must stop or escalate, who retains the decision right, and what evidence must survive execution.
The research hypothesis is therefore:
A governance runtime should bind permission, routing, escalation, human decision rights and evidence generation to the execution path itself.
Authority sits between intelligence and action.
What the organisation is trying to achieve.
Who or what may do which action under which conditions.
Which model, route, agent or tool is eligible.
Permitted output, escalation, fallback or stop condition.
Trace of route, policy state, review, failure and outcome.
The core assurance target is not simply “the model answered correctly.” It is whether the system can demonstrate that execution occurred inside a defined authority boundary and that the material path can be reconstructed afterward.
Three evidence layers exist today.
A. Single-B300 runtime
A full Meta Llama 3.3 70B Instruct model was loaded in BF16 on one NVIDIA B300 GPU. The FinC2E v2 runtime LoRA adapter loaded and executed. In the tested canonical structured-output task, the adapter produced 4/4 complete outputs while the tested baseline produced 0/4.
- Warm median TTFT
- 30.77 ms baseline / 49.81 ms adapter
- Warm decode
- 26.30 / 19.31 output tokens/s
- Evidence integrity
- External and internal SHA-256 verification passed
B. Failure → controlled recovery
The first inference path failed with a cuDNN SDPA execution-plan error. The recovery changed the failing backend path while keeping the model, adapter, prompts and evaluation structure fixed. The successful path and the failed path were both retained.
- Recovery
- cuDNN SDPA disabled; Flash and Math SDPA remained enabled
- Evidence
- Traceback, load summaries, outputs, telemetry, hashes and manifests retained
C. Governed reference workflow
A separate governed workflow passed the full regression suite under a human-accountability contract.
- Regression
- 249 tests + 23 subtests passed
- HumanReviewRequired
- True
- AutonomousDecisionAllowed
- False
This validates that reference workflow and acceptance contract. It does not convert the B300 runtime or every HumAI MightHub deployment into a universally validated system.
The B300 run also retained GPU utilisation, memory, power, temperature and clock telemetry. The purpose was reconstructability and workload characterisation, not an MLPerf or performance-leadership claim.
Keep governance claims fixed while the execution environment changes.
The next validation phase tests whether the governance method survives outside the environment that produced the current baseline. Independence matters because a governance claim that only works inside one provider, one accelerator path or one deployment stack may be an infrastructure-specific property rather than a portable runtime property.
Reproducibility & overhead
Repeat the reference workload and compare baseline execution with governance-enabled execution. Measure latency, throughput, schema compliance, determinism, failure/recovery, telemetry, audit completeness and governance overhead.
Model-fleet orchestration
Introduce multiple eligible models or routes. Test routing, fallback, consensus or disagreement handling, escalation and evidence continuity.
Portability & scale
Hold the governance methodology stable while changing accelerator, serving path, model or infrastructure environment.
Evidence maturity must match the claim.
Cross-infrastructure portability
Protocol is defined. Independent repeat evidence is not yet claimed.
Fleet-level assurance
Model-fleet routing and resilience are active research targets, not production acceptance claims.
B300 runtime behaviour
Observed under the documented single-GPU BF16, runtime-LoRA, concurrency-1 conditions.
Bounded workflow contract
A specific governed reference workflow passed its defined regression and human-authority acceptance conditions.
A future cross-infrastructure claim should only move from planned or experimental to observed or validated when the claim statement, environment, acceptance criteria, material failures, repeats and reviewer disposition are retained together.
What this note does not establish.
- It is not an MLPerf submission or a performance-leadership comparison.
- It does not compare the current path with batched vLLM, TensorRT-LLM, NIM, FP8/NVFP4 or multi-GPU production serving.
- It does not establish universal reliability, safety, legal compliance or domain correctness.
- The B300 workload was a bounded single-request validation with concurrency 1.
- The governed workflow regression and the B300 runtime are complementary evidence layers; they should not be silently treated as one identical execution environment.
- Independent cross-infrastructure repeat evidence has not yet been published.
Turn portability from an architectural claim into an evidence question.
The next release should report an independently repeated workload under a second infrastructure environment with a frozen claim definition and comparable evidence package. A useful result can be either success or a material failure: the purpose is to learn which governance properties survive the move and which are coupled to a specific execution stack.
Freeze
Reference workload, authority envelope, output contract and evidence schema.
Repeat
Execute in the independent environment and retain failures rather than normalising them away.
Compare
Separate infrastructure variance, model variance and governance variance before making a portability claim.
Stable reference.
Vučelj, E. (2026). From Governance Runtime to Evidence: Independent Cross-Infrastructure Validation. BPM Research Note 001, v1.0. BPM RED Academy. https://bpm.ba/research/governance-runtime-to-evidence/Evidence sources
- Single-B300 Validation of Llama 3.3 70B + Runtime LoRA: SDPA Recovery, Telemetry and Next Benchmark Design, public technical validation summary, 14 September 2026.
- BPM RED Academy governed reference-workflow regression evidence, September 2026: 249 full-regression tests + 23 subtests; selected non-sensitive acceptance results disclosed in this note.
- BPM RED Academy independent validation design note, September 2026: reproducibility/governance overhead → model-fleet orchestration → portability & scale. The independent repeat remains planned.
Third-party infrastructure and product names describe factual execution context only. They do not imply endorsement, certification or partnership.