R-BED™ · public technical resource · version 2.1

AI risk does not stop at deployment. Neither should evaluation.

R-BED™ (Risk-Based Evaluability Design) v2.1 proposes continuous, consequence-aware system evaluation: evidence that carries an expiry, safeguards that are shown to work, and monitoring effort directed by consequence. It is a proposed practitioner methodology and has not been empirically validated. No login, payment or registration is needed to read the documents.

Overview

R-BED connects four things in one traceable record for a configured AI system: technical evaluation evidence, evidence that deployment controls work, the real-world consequences at stake, and an accountable decision (Deploy, Restrict, Escalate, Remediate or Stop). It also addresses what happens after the decision: how long evidence may be relied on, how safeguards are re-challenged, where monitoring effort goes, and what is learned from failures. The contribution claimed is the combination of these elements in one evaluation-to-decision record; individual components have precedents. R-BED complements, and does not replace, NIST AI RMF 1.0, ISO/IEC 42001, model risk management and technical evaluation resources, and its empirical effectiveness has not yet been demonstrated.

Three methodological commitments

• Consequence-aware evaluation. Decide what matters by potential consequence (severity, reversibility, exposure), not by frequency alone.
• Evidence-based control assurance. A safeguard is credited only after it is shown to work under realistic failure, at a stated level of independent verification.
• Continuous evaluation and authorization. Evidence has an owner, a configuration, an expiry and invalidation triggers. An authorization cannot outlive the evidence it depends on.

Maturity labels used in the documents: [E] specified core, [P] proposed extension, [H] research hypothesis. Nothing labeled [E], [P] or [H] has been empirically validated.

Continuous System Evaluation (CSE)

Continuous assurance is not continuous testing. The aim is not to rerun every check all the time but to decide what must be rechecked, how often and by whom, in proportion to consequence and the rate of change. “Continue” is the renewal of a Deploy authorization, not a new disposition.

Traditional pre-deployment evaluation compared with continuous system evaluation

The comparison describes the proposal. It does not claim that existing practices lack these elements; model risk management, observability, runtime enforcement and incident-driven evaluation each cover parts of it (see the CSE Specification, Section 14).

Illustrative agentic use case (synthetic)

A support agent can read tickets and its own customer’s account, draft refunds and, with approval, initiate refunds up to a limit. The team records the agent’s authority and the reversibility of each action; tests the safeguards that enforce the limits rather than the model’s intentions; records which evidence the approval depends on and when it expires; and watches the irreversible pathway (cross-account disclosure) most closely. A major model update invalidates the over-limit evidence, the claim reverts to Unresolved, and the decision authority must review the pilot. The example is synthetic and illustrates the record; it is not a case study.

Evidence validity and authorization

Each item of evidence the decision depends on records the configuration it was gathered on, its owner, uncertainty, review-by and expiry dates, invalidation triggers and dependencies. A change to a critical dependency of major magnitude invalidates the evidence; a patch to a peripheral component has no effect; undeclared dependencies are treated conservatively. An invalid item returns its claim to Unresolved, and unresolved is not safe.

Roadmap and hypothesis H7

The Validation Plan sets out studies S1–S7. None has been run. S7 tests hypothesis H7: whether allocating a fixed monitoring budget by consequence-aware tiers avoids more harm than allocating by observed frequency or uniformly. The plan names settings in which R-BED is expected to do worse (for example, when consequence is misjudged, or when harm is dominated by frequent, low-severity events) and requires negative controls and replication.

Documents (version 2.1, 29 October 2026)

Practitioner documentation

The Public Framework and CSE Specification are written to be applied by risk, governance, engineering and independent-validation teams. The CSE Specification gives the protocol with acceptance criteria, the record fields and an illustrative agentic example. A reference implementation exists as a separate resource; it is tooling, and its tests show that the code follows the text, not that the method improves decisions. Cadences, thresholds and the impact table in the specifications are illustrative defaults to be justified locally.

Scope and limits

• Not empirically validated. Every [P] element is a design; H7 is a hypothesis.
• Consequence and Impact has three dimensions: C1 Incremental Impact (harm per affected exposure, against a stated baseline), C2 Scale (how many are genuinely affected, how concentrated and correlated) and C3 Regulatory and Reputational Impact (C3a regulatory and legal, C3b reputational and trust, assessed separately). They are not scored or multiplied, and amounts already priced in a loss estimate are not counted again.
• Terms: materiality directs evaluation effort; inherent risk is consequence potential before credited controls; residual risk is what remains after evidenced controls. Expected, stressed and tail loss are different quantities; VaR and Expected Shortfall are optional and need a defensible loss distribution. The expected-loss sum over exposure units needs no independence assumption; tail aggregation generally needs modeled dependence. These are proposed [P] practices and have not been validated.
• Not a standard, certification, monitoring platform, or replacement for pre-deployment validation, model risk management, security or privacy assessment, or enterprise governance.
• The mapping to NIST AI RMF 1.0 is the author’s interpretation. It does not claim that R-BED covers all outcomes or that following it achieves compliance or conformity. NIST has stated that a revision of AI RMF 1.0 is in progress; the crosswalk may be revised accordingly.
• Ordinal consequence ratings can be wrong or gamed; the burden of maintaining the records is unknown; detection measured on seeded failures may overstate real detection.
• No claim of superiority over any other resource is made.

Attribution and use

© 2026 Vishal Kumar Srivastava, PhD. The documents may be read, downloaded, cited and applied in an organization’s own evaluation practice without charge, with attribution. Republication, translation or derivative versions require written permission. Contact: vshfrm@gmail.com.

Notices

R-BED™ is claimed as a trademark by the author; no registration, certification or NIST endorsement is asserted. This resource is independent of NIST, has not been reviewed or endorsed by NIST, and does not offer a product or service. NIST AI RMF 1.0 is available from NIST.

Integrity

SHA-256 of the files as published:

Earlier versions

Version 2.1 (29 October 2026) is the current version. Earlier public versions are kept for reference only: framework 2.0 and 1.1; crosswalk 2.0 and 1.1.