Andorra AI Safe HavenEvidence · Temporal Replay

How It Works

An independent evidence plane for AI.

Safe Haven is designed as a temporal abstraction layer rather than a database view — evidence capture, temporal reconstruction and verifiable integrity as reusable infrastructure.

Architecture

Proposed layers

Layer 01

AI Applications

  • LLMs
  • Agents
  • ML
  • RAG
  • Automated Decisions

Layer 02

Safe Haven Connect

  • API
  • SDK
  • Gateway
  • Events

Layer 03

AI Evidence Envelope

  • Data
  • Model
  • Prompt
  • RAG
  • Tools
  • Policies
  • Identity
  • Human Intervention
  • Output
  • Action

Layer 04

Temporal Replay Engine

  • Valid Time
  • Transaction Time
  • Corrections
  • Version History
  • Temporal Relationships

Layer 05

Immutable Evidence Vault

  • Cryptographic Integrity
  • Digital Signatures
  • Tamper Evidence
  • Retention Policies

Layer 06

Audit & Replay

  • Historical Reconstruction
  • Investigation
  • Compliance
  • Counterfactual Analysis
  • Authorised Third-Party Access

Temporal Replay Engine

Two kinds of time, moved out of applications.

Gartner described the valid-time / transaction-time model as bitemporal data management and recommended moving temporal logic out of individual applications and into reusable infrastructure. The historic TRE concept was shown to Gartner by Oracle Consulting UK as a transparent temporal layer over Oracle RDBMS and SQL; the paper explicitly states TRE was not an Oracle product.

The original TRE concept was demonstrated as a transparent temporal layer over relational database technology. The proposed Safe Haven architecture evolves this principle into a database-neutral temporal evidence service capable of integrating with modern operational databases, warehouses, AI data stores and event sources through platform-specific adapters.

Proposed source categories

  • PostgreSQL
  • Oracle
  • SQL Server
  • Snowflake
  • BigQuery
  • Databricks / lakehouse
  • Vector databases
  • Document / object stores
  • Event streams
  • APIs and external tools

The temporal semantics should belong to Safe Haven rather than being reimplemented independently in each customer application.

Three forms of replay

Recorded, reconstructed, counterfactual.

  • Recorded Replay

    What actually happened?

    Display the evidence captured around the original AI event without rerunning it.

  • Historical Reconstruction

    What did the system know at that time?

    Reconstruct relevant data, policy, model, prompt, retrieval and knowledge state.

  • Counterfactual Replay

    What would happen using what we know now?

    Re-evaluate historical decisions using corrected data, changed policy or a different model.

Exact computational reproducibility may depend on the continued availability and deterministic behaviour of external models and services. Safe Haven therefore distinguishes recorded evidence from computational re-execution.

AI Evidence Envelope

Capture the context, not simply the output.

  • Model

    Provider, model family, exact version or checkpoint where available, and configuration.

  • Prompt

    System prompt, user prompt, template and template version.

  • Knowledge

    Documents, vector results, database queries and source records.

  • Data

    Relevant business data with its temporal state.

  • Agents

    Agent identity, task, hand-offs and workflow metadata.

  • Tools

    APIs, functions and external services invoked.

  • Policy

    Business rules, guardrails and regulatory controls active at the time.

  • Identity

    Person, service or AI process initiating the activity.

  • Human Oversight

    Approval, escalation, rejection or override by a person.

  • Decision

    Model output plus the actual downstream business action.

  • Integrity

    Hashes, signatures and evidence-chain verification.

Cryptographic trust

Evidence should be verifiable, not merely stored.

The proposed architecture is intended to support cryptographically protected evidence capable of showing whether historical records have been altered.
  • Hardware Security Modules (HSMs)
  • Protected signing keys
  • Digital signatures
  • Immutable / WORM storage
  • Evidence hashes
  • Hash chains or Merkle structures
  • Trusted timestamping
  • Strong administrator separation and role segregation

Architecture target: support for FIPS 140-3 Level 3 hardware-backed cryptographic key protection where required. Deployed FIPS compliance is not claimed until the final architecture and validated components are in service.

Service direction

A Safe Haven Evidence API and SDK.

Illustrative future endpoints. Safe Haven is designed as a service-oriented evidence layer, not a replacement database engine.
POST /evidence/event
POST /evidence/source
POST /evidence/decision
POST /evidence/human-action

GET  /replay/{case}
GET  /replay/{case}?transaction_time=T1
GET  /replay/{case}?valid_time=T2

Future natural-language capability

“What did the organisation know about customer 1927 when decision D552 was made?”

The platform would translate that request into temporal queries over the evidence model and connected source systems.

Strategic engagement

Government, banking or technology stakeholder?

We are currently developing the Safe Haven architecture and exploring potential pilot, policy, infrastructure and funding partnerships.

Discuss a PartnershipRequest the Concept PaperRegister Interest