Scenario 8
Preview — execution disabledEvidence & provenanceIntermediateSecurity Evidence & Provenance
Tracing how a security record was produced and showing it was not altered — never that its conclusion is true.
A security decision is only as trustworthy as the trail behind it. If an agent reports "this input was flagged" or "this action was denied", a reviewer needs to ask: where did that observation come from, what identifier does it carry, what was derived from it, and has the record been changed since it was written? This scenario is a static architectural walkthrough of a provenance chain: observations are captured with stable identifiers, transformations are recorded as links between records, and a validator re-checks a conceptual integrity chain before anything is trusted or appended to an audit store.
Everything below is a conceptual architecture with a synthetic trace. No analysis runs, nothing executes, and the records, identifiers and hashes are illustrative. The point is the mechanism — origin, identity, relationships, transformations, integrity checking and an append-only audit trail — not any particular finding.
Honesty
The data here does NOT constitute real cryptographic evidence: the integrity and hash-chaining are shown conceptually, not computed with real primitives. A provenance chain proves how a record was produced and that it was not altered under stated assumptions — it never proves that the underlying conclusion is true. Provenance is about the record, not about reality.
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.
Observation Recorder
Conceptual exampleCaptures each raw observation as it enters the system and assigns it a stable, namespaced identifier, binding the record to its origin so later stages reason about provenance rather than loose data.
- Inputs
- Observation from a source (scan result, detector hypothesis, policy verdict) · Source descriptor
- Outputs
- Observation record with a stable id and origin
- Tools
- Identifier minter (namespaced, deterministic)
- Authorization
- None — read-only capture; it records, it draws no conclusion and takes no action.
- Verification
- Origin is read from the ingestion path, and the identifier is namespaced by source so two sources cannot collide into one id.
- Possible failures
- Missing origin metadata on an incoming observation — fails closed, the record is marked origin=unknown and quarantined for review.
Transformation Tracker
Conceptual exampleRecords every transformation that derives a new record from existing ones (normalisation, correlation, enrichment) and writes the parent/child relationships that connect them, so any derived record can be traced back to its sources.
- Inputs
- Observation record(s) · Transformation descriptor
- Outputs
- Derived record linked to its parent(s) · Relationship edges (derived-from)
- Tools
- Lineage linker (deterministic)
- Depends on
- recorder
- Authorization
- None — it records lineage; it does not decide whether a record is valid.
- Verification
- Each derived record names the exact parent id(s) it came from; a transformation with no recorded parent is rejected as orphaned.
- Possible failures
- A transformation that loses its parent reference — the resulting record is flagged orphaned and is not appended to the store.
Integrity Validator
Conceptual exampleDeterministically re-checks the conceptual integrity chain of a record and its lineage: it recomputes each conceptual link hash and confirms it matches what the record claims, detecting any record whose chain has been broken or whose content no longer matches its recorded digest.
- Inputs
- Record + its recorded conceptual chain · Parent relationships
- Outputs
- ACCEPT / REJECT with a reason · Integrity report
- Tools
- Conceptual hash-chain checker (illustrative, not real crypto)
- Depends on
- recorder · tracker
- Authorization
- This is the integrity boundary. A record whose chain does not verify is rejected before it can be appended or trusted. Reject on any broken link.
- Verification
- The check is a pure function of (record content, recorded digest, parent digests); it is reproducible and logged. It attests integrity only — never the truth of the record’s conclusion.
- Possible failures
- A genuinely tampered record that happens to re-match a recomputed conceptual digest is out of scope here — this is a demonstrative chain, not a real cryptographic one, and that limitation is stated, not hidden.
Provenance & Audit Store
Conceptual exampleHolds the append-only provenance chain and audit log: accepted records, their identifiers, their relationships and the validator’s verdicts, exposing a trail a reviewer can walk from any conclusion back to its original observations.
- Inputs
- Accepted records + lineage · Integrity verdicts
- Outputs
- Append-only provenance chain · Auditable trail per record
- Tools
- Append-only log (demonstrative)
- Depends on
- validator
- Authorization
- Append-only; it never overwrites or deletes an existing entry.
- Verification
- Entries are write-once; an attempt to mutate an existing record appears as a new, linked entry, not an in-place edit.
- Possible failures
- Storage of an unvalidated record — prevented by only appending records the validator has ACCEPTed; a rejected record is logged as a rejection, not as a trusted entry.
Workflow
Processing and decisions
The ordered path from input to recorded decision.
- 1
Capture with an identifier
Each incoming observation is recorded and given a stable, namespaced identifier bound to its origin. Provenance comes from the ingestion path, not from the record’s own claims.
- 2
Link relationships
When a record relates to others — same subject, correlated signal, enrichment — those relationships are written as explicit edges so the graph of observations is traversable.
- 3
Record transformations
Whenever a record is derived from existing ones, the transformation and its parent id(s) are recorded, so any derived record names exactly where it came from.
- 4
Validate integrity (conceptual chain)
The integrity validator recomputes the conceptual hash-chain of a record and its lineage and confirms each link matches. This is illustrative, not real cryptography.
- 5
Append to the provenance store
A record that verifies is appended to the append-only store with its identifier, relationships and verdict. A record that fails is rejected and logged as a rejection, never as a trusted entry.
- 6
Expose the audit trail
A reviewer can walk the trail from any conclusion back through its transformations to its original observations, reading what was recorded and how — but never taking the trail as proof the conclusion is true.
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 · Observation Recorder
Synthetic traceObservation captured
A detector hypothesis arrives from a source and is recorded as obs:detector/0001 with origin=detector. A stable, namespaced identifier is assigned.
▤ evidence: observation-record
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.
Observation record
Captured observation (synthetic)Integrity: Stable namespaced id bound to origin; demonstrative, not real cryptographic evidence
Provenance: Observation Recorder
Derived-from relationship
Lineage edge (synthetic)Integrity: Names the exact parent id(s); orphaned edges are rejected
Provenance: Transformation Tracker
Integrity report
Deterministic resultIntegrity: Pure function of (content, recorded digest, parent digests); conceptual hash-chain, not real crypto
Provenance: Integrity Validator
Provenance & audit chain
Append-only log entry (synthetic)Integrity: Append-only in a real deployment; demonstrative here — attests how a record was produced, never that its conclusion is true
Provenance: Provenance & Audit Store
Security controls
Authorization, validation and containment
The mechanisms that make the scenario safe by design, independent of what any model concludes.
Stable, namespaced identifiers
Every observation gets a stable identifier namespaced by source, so records are addressable and two sources cannot collide into one id.
Append-only provenance
The store never overwrites or deletes; a correction appears as a new, linked entry, preserving the original trail.
Conceptual integrity / hash-chaining
Each record carries a recorded digest and links to its parents; the validator recomputes the chain before trusting a record. This is demonstrative, not real cryptography.
Relationships and transformations recorded
Derived records name their parents and the transformation that produced them, so any conclusion can be walked back to its original observations.
Provenance is not truth
The chain attests how a record was produced and that it was not altered under stated assumptions — it never asserts that the record’s conclusion is correct.
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.
Broken or missing provenance
A record has no resolvable parent, or its recorded chain is incomplete.
Recovery
The record is rejected rather than trusted; its status is UNKNOWN until its lineage can be re-established, and the gap is visible in the audit trail.
Identifier collision
Two observations from different sources are minted with the same id.
Recovery
Identifiers are namespaced by source so the collision cannot occur silently; an unnamespaced id fails closed and is quarantined for review.
Tampered record
A record’s content is altered after it was written, breaking its conceptual integrity link.
Recovery
The integrity check detects the mismatch and the record is quarantined and logged as a rejection — never appended as a trusted entry.
Technical notes
Design considerations, limitations and references
- This is a conceptual architecture with a synthetic trace; nothing is executed and every record, identifier and hash is illustrative.
- The integrity and hash-chaining are demonstrative, not real cryptography — the demo shows the shape of a provenance chain, not a cryptographically sound one.
- The same discipline underlies the Rootchain evidence model: a conclusion is only as trustworthy as the provenance behind it, and PROVEN / NOT PROVEN / UNKNOWN stay distinct from "the record verified".
References
- W3C PROV — provenance data model (entities, activities, agents, derivation)
- Hash chain / Merkle tree — tamper-evidence as a concept
- ROOTVIEL Knowledge Base — evidence scope: structural vs observed, and verified entries
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.