Scenario 5
Preview — execution disabledVerification & epistemicsAdvancedEpistemic Verification
A claim is promoted only when a deterministic, LLM-free check settles it — a model’s confidence is never proof.
An agent that reasons in natural language produces statements that sound like conclusions: "the endpoint is not vulnerable", "this input is sanitised", "the property holds". The hard problem is epistemic — keeping the status of each statement honest. This scenario is a static architectural walkthrough of how a small pipeline distinguishes a hypothesis from gathered evidence, a proposed claim from a corroborated one, and a rejected claim from a genuinely unknown one, and of the exact condition under which a statement may be accepted as a conclusion.
The core rule is blunt: a language model’s statistical confidence is not proof. However fluent or certain the reasoner sounds, its output is a hypothesis. A claim is promoted to the evidence store only when a deterministic, LLM-free check settles a specific property under stated assumptions. If no such check settles it, the claim stays UNKNOWN by default — not quietly accepted because the model was confident. This is the epistemic core of ROOTVIEL and Rootchain.
Honesty
Nothing executes here and no model runs. The ladder below is a conceptual architecture with a synthetic trace; the "confidence" figure in the example is illustrative, not measured. The point is the acceptance condition — deterministic settlement under stated assumptions — not any score.
Preview Mode — Execution Disabled
This laboratory is currently available for architectural exploration and educational demonstrations only. Live agent execution and security testing are disabled. Operational access requires prior explicit authorization from RavenRootviel.
Architecture
Components and flows
The agents, services, verifiers, policy engines and evidence stores in this scenario, and how they connect. Drag to pan, scroll to zoom, and select any component for its role, inputs and outputs.
Agents
Agents and responsibilities
Each agent has a narrow responsibility, explicit inputs and outputs, and — crucially — its own authorization posture. Reasoning is never authorization.
Claim Proposer
Conceptual exampleReasons toward the task and emits claims as hypotheses — a statement plus the assumptions it would depend on and a self-reported confidence. It never promotes its own claims.
- Inputs
- Task / question · Working context
- Outputs
- Proposed claim (hypothesis) + stated assumptions + self-reported confidence
- Tools
- Reasoner (language model)
- Authorization
- None. It can propose a claim; it cannot mark one as corroborated.
- Verification
- Its confidence is advisory only; promotion never depends on it, and a high-confidence claim with no settling check stays UNKNOWN.
- Possible failures
- May state a plausible but false claim with high confidence — expected, and exactly what the verifier and adjudicator contain.
Evidence Gatherer
Conceptual exampleCollects the concrete artefacts a claim would need to be checked against — the specific value, trace, configuration or fact — and records where each came from. It does not judge whether the claim holds.
- Inputs
- Proposed claim + stated assumptions
- Outputs
- Evidence bundle (artefacts + provenance)
- Tools
- Artefact collector (deterministic)
- Depends on
- proposer
- Authorization
- Read-only; assembles facts, decides nothing.
- Verification
- Each artefact carries its provenance, so the adjudicator reasons about where evidence came from, not about the reasoner’s wording.
- Possible failures
- May return insufficient or missing artefacts — surfaced to the adjudicator, which abstains rather than guesses.
Deterministic Verifier
Runs an LLM-free check that settles a specific property of the claim under the stated assumptions, returning SETTLED-TRUE, SETTLED-FALSE or CANNOT-SETTLE for each property — never a probability.
- Inputs
- Proposed claim · Evidence bundle · Stated assumptions
- Outputs
- Per-property settlement result + the assumptions it relied on
- Tools
- Deterministic checker (LLM-free: parser, type/shape check, re-computation, decision procedure)
- Depends on
- gatherer
- Authorization
- Enforces the acceptance condition; it is part of the boundary.
- Verification
- A pure function of (claim, evidence, assumptions); reproducible and independent of any model. It settles only the specific property it is designed for and reports CANNOT-SETTLE for the rest.
- Possible failures
- A relied-on assumption may be false — then the settlement is void and the claim must be withdrawn, not downgraded to "probably true".
Adjudicator
Applies the deterministic acceptance rule: promote a claim to the evidence store only for the properties the verifier SETTLED-TRUE under assumptions that hold; reject what was SETTLED-FALSE; mark everything else UNKNOWN. Records the decision and the assumptions.
- Inputs
- Proposed claim · Verifier settlement result · Assumptions
- Outputs
- PROMOTE / REJECT / UNKNOWN per property · Decision record
- Tools
- Deterministic acceptance rule
- Depends on
- verifier
- Authorization
- This is the epistemic boundary. UNKNOWN by default; model confidence alone can never cause a PROMOTE.
- Verification
- The decision is a pure function of (settlement result, assumptions); reproducible and logged with the deciding condition.
- Possible failures
- A mis-stated acceptance rule could over-promote — a configuration risk, surfaced in the decision record, never fixed by trusting the reasoner.
Workflow
Processing and decisions
The ordered path from input to recorded decision.
- 1
Propose as hypothesis
The reasoner states a claim together with the assumptions it would depend on and its self-reported confidence. The claim enters the ladder marked UNKNOWN; nothing is accepted yet.
- 2
Gather evidence
The evidence gatherer collects the specific artefacts the claim must be checked against and records where each came from. Evidence is distinct from the claim about it.
- 3
Settle deterministically
An LLM-free verifier checks one specific property under the stated assumptions and returns SETTLED-TRUE, SETTLED-FALSE or CANNOT-SETTLE. It never returns a probability and never consults the model.
- 4
Apply the acceptance condition
A claim may be promoted only for the properties that were SETTLED-TRUE under assumptions that actually hold. Confidence, fluency and plausibility are not acceptance conditions.
- 5
Adjudicate: promote, reject or hold
Settled-true properties are promoted to the evidence store under their assumptions; settled-false ones are rejected; everything the verifier could not settle stays UNKNOWN by default.
- 6
Record the epistemic status
The claim, its assumptions, the settlement result and the verdict are written to a decision record, so every accepted conclusion traces back to a specific deterministic check.
Example execution
Walk through an illustrative trace
A synthetic, predefined sequence — step forward and back to see what each component does, the evidence it produces and the decisions taken. This is a conceptual/synthetic trace, not an executed experiment, and it cannot be run live in this preview.
Step 1 / 6 · Claim Proposer
Synthetic traceClaim proposed
For the question "is this API response safe to render?", the reasoner proposes "the response is well-formed JSON and contains no executable HTML", with self-reported confidence 0.94 (illustrative) and assumption "the response body is exactly the bytes captured".
▤ evidence: proposed-claim
Evidence
Evidence in this scenario
What is recorded, of what kind, with what integrity property and from where. Demonstrative data — not cryptographic evidence of a real system.
Proposed claim
HypothesisIntegrity: Carries assumptions and self-reported confidence; not treated as proof
Provenance: Claim Proposer
Deterministic settlement result
Deterministic resultIntegrity: Pure function of claim + evidence + assumptions; LLM-free and reproducible
Provenance: Deterministic Verifier
Adjudication decision record
Decision log entry (synthetic)Integrity: Append-only in a real deployment; demonstrative here
Provenance: Adjudicator
Security controls
Authorization, validation and containment
The mechanisms that make the scenario safe by design, independent of what any model concludes.
Confidence is not proof
A model’s self-reported or statistical confidence is advisory only; it can never, on its own, cause a claim to be accepted.
Deterministic, LLM-free settlement before promotion
A claim is promoted only after an LLM-free check settles the specific property; the check consults no model and is reproducible.
UNKNOWN by default
Anything no deterministic check has settled is kept explicitly as UNKNOWN, not quietly accepted because it seemed likely.
Assumptions and acceptance conditions recorded
Every promotion records the assumptions it relied on and the deciding condition, so a conclusion is only ever as strong as its stated assumptions.
Failure conditions
What can go wrong — and the expected behaviour
Honest failure modes and the containment or recovery that keeps a failure from becoming an unauthorized effect.
Overconfident but unverifiable claim
The reasoner asserts a claim with very high confidence, but no deterministic check can settle the property.
Recovery
The claim stays UNKNOWN by default; confidence does not substitute for settlement, and the gap is recorded rather than hidden.
Verifier assumption violated
A property was settled true, but an assumption it relied on turns out not to hold (e.g. the captured bytes were not the real response).
Recovery
The settlement is void: the promoted claim is withdrawn and returned to UNKNOWN, not downgraded to "probably true".
Evidence insufficient
The gatherer cannot collect the artefacts a claim would need to be checked against.
Recovery
The adjudicator abstains — the claim stays UNKNOWN — rather than accepting it on the reasoner’s word.
Technical notes
Design considerations, limitations and references
- This is a conceptual architecture with a synthetic trace; no language model is executed and the confidence figure is illustrative, not measured.
- The ladder keeps PROVEN, NOT PROVEN and UNKNOWN distinct: promotion is PROVEN-under-assumptions, a settled-false property is NOT PROVEN, and anything unsettled is UNKNOWN by default.
- This mirrors Rootchain’s evidence model: a valid proof attests that a specific statement holds under its stated assumptions — never that a decision was correct, complete or safe in general.
References
- NIST AI Risk Management Framework (AI RMF 1.0)
- ROOTVIEL Academy — Evidence, assumptions and the limits of proof
- ROOTVIEL Knowledge Base — Treating model confidence as proof (epistemic failure mode)
Try this lab
Run it — coming soon
Interactive execution of this scenario is not part of the preview. When it is enabled, it will run on controlled, authorized scenarios only.
Live execution is not available in this preview. Access will require explicit authorization from RavenRootviel.
Authorized Access Only — Live Security Testing
Live security testing and agent execution require prior explicit authorization from RavenRootviel. The current preview provides educational content and non-operational demonstrations only. Browsing the educational content is public; operational use of the labs will require express authorization when it is enabled in a later phase. Access & use policy.