Technology / boundaries made visible

Private evidence. Explicit checks. A shared anchor.

Orvessian connects records across systems without pretending that every kind of trust is the same.

The architecture

Keep the boundaries visible.

01

Application

Your agent or runtime executes the work and enforces permissions.

02

Organisation

Authority and sensitive evidence remain within the organisation's controls.

03

Receipt

Signed records bind events to evidence; verifiers check specific properties.

04

Shared anchor

Base records batch commitments; private records, indexes and inclusion proofs support review.

Architecture direction. Components have different readiness levels; the complete product is not a production release.

What does “verified” actually mean?

Six checks. Six different answers.

Evidence integrity

Disclosed bytes match their commitment. This does not establish whether the evidence is true.

Issuer signature

A particular key signed a record. Identity and trust in that issuer require additional checks.

Authority

The relevant permission holds at a defined reference point. Runtime enforcement remains a separate responsibility.

Policy proof

A precisely defined computation evaluated a committed action against a committed policy. Not a general proof of AI correctness.

Human review

A reviewer attests to a specific decision and evidence version. Human judgement remains fallible.

Chain inclusion

A record belongs to a checked chain view or batch. Inclusion does not authorise every leaf or guarantee permanent finality.

Safety evidence boundary

Chain confirmation is evidence, not containment.

A policy gateway, sandbox or security monitor must make a local allow, block, pause or revoke decision without waiting for a ledger. Orvessian can then bind selected policy versions, alerts and authorised interventions into an independently checkable timeline.

Distributed does not mean AI-resistant

A confirmed record may be harder for one operator to silently change than a private database entry. Attackers can still compromise keys, source events, runtimes, relayers, indexes, contracts or consensus. The claim must always be checked against the actual system and its operators.

Explore the safety-evidence model →

Current technical baseline

Build the layers. Publish their limits.

01 / receipt

General format 0.4.0-alpha

Versioned profiles, exact-byte commitments, signatures, private openings, streams and batch links exist in local reference tooling.

02 / proof

A narrow deterministic statement

The internal alpha’s RISC Zero policy path proves a committed action against committed policy and configuration. It does not prove AI execution or outcome truth.

03 / foundation

Base Sepolia pilot

A supervised relayer sponsors synthetic batch transactions on Base Sepolia. The portal checks canonical inclusion; production mainnet operations remain gated.

Independent infrastructure

Why anchor on Base?

Base is the accepted launch settlement direction. Orvessian operates a governance and verification application on that network; it is not launching its own L1 or a separate L2.

Private structured records and receipt openings stay in the platform database. Only batch commitments are published. The recording key and gas-paying publisher have distinct roles; customers need neither ETH nor a native token.

Current evidence comes from Base Sepolia, including sponsored submission and restart recovery. Historical mining experiments are outside the launch plan. Larger and hierarchical batches still need measurement.

Prove the specific claim.

General 0.4.0-alpha receipts and the authorised AVR flow have different capabilities. Missing evidence, unsupported checks and unknown authority should remain visible rather than becoming a universal success badge.