RiverAct · Guided walkthrough

Your company is
already using AI.
Can you prove how?

From 2 August 2026 the EU AI Act is being enforced, and from 9 December a customer harmed by an AI decision no longer has to prove you were careless — you have to prove you were. That proof is a record you can produce, dated, and show has not been edited since.

This page walks you through what that looks like — in plain language first, with the exact article, deadline and artefact one click down. Everything on it is live. Nothing you do here is sent anywhere.

connecting to the live API… fetching public key… Ed25519 · SHA-256
Step 1 · Why now

Two dates already passed. One is a hundred days away.

Most boards still file the AI Act under "2027 problem". Two of its obligations are already being enforced, and the one with the sharpest teeth is not the AI Act at all — it is the product-liability regime that arrives in December.

The one a business leader should care about most 9 December 2026 — the new Product Liability Directive. It brings software and AI inside strict product liability and lets a court presume defect and causation when a company cannot produce the technical records the law expects. In plain terms: the absence of evidence becomes evidence against you. And evidence is retrospective — a company that starts keeping records this month walks into 2027 with a year of history; one that starts in 2027 walks in with an explanation.
Step 2 · The walkthrough

Eight things that happen, and what the law says about each

A single scenario at an invented Central European bank, start to finish. Read the plain-language version, and open "What the law actually says" on any step when you want the article, the deadline and the artefact.

1 / 8
Chain verified
All records intact, linked in order, and signed by RiverAct's production key.
Step 3 · Prove it

Break the chain yourself

Below is a real signed chain: a bias finding, and the technical file that answers it. Edit any value in place, or run one of the four attacks. The verdict above updates as you type — and tells you which record gave you away.

The line an auditor writes down
Step 4 · How it holds

Why each attack fails

Nothing here is exotic. It is SHA-256 and Ed25519, arranged so that hiding one edit requires rewriting everything after it — and so that even a perfect rewrite is caught by a number you wrote down earlier.

Content → hash

The record proves itself

Every record's hash is derived from its own content, over a canonical JSON encoding with keys sorted, so the same facts always hash the same regardless of formatting. We do not compare against a second copy that an attacker could also reach — we re-derive the hash from what is in front of us.

Hash → link

Every record holds the one before it

Each entry stores link = SHA-256(previous link ‖ own hash). Repair one record and the break simply moves downstream. To hide a single edit you must rewrite every record that follows it — which is exactly what the next two checks are for.

Link → signature

A signature is bound to its position

Ed25519 signs domain ‖ seq ‖ prevHash ‖ recordHash, not the bare link. So a valid signature cannot be lifted to another position or another chain. And a missing signature is a failure, never a skip — otherwise deleting signatures would be an attack.

Chain → commitment

A perfect forgery is still the wrong chain

An attacker holding the signing key can rebuild a flawless chain. So verification also checks the head commitment {seq, link, count} published earlier. Truncation and wholesale rewrites both fail against it — which is why an auditor keeps that one line.

What this does not claim This is tamper-evident, never tamper-proof. It does not stop anyone writing to a database; it guarantees they cannot do so quietly. Two honest limits: the signing key is RiverAct's, so a signature attests that our API wrote a record — not that a customer cannot repudiate one (customer-held keys are the next increment). And our anchors carry an RFC-3161 third-party timestamp from a public authority, not an eIDAS-qualified one; a production tenant points at a qualified EU authority.
Step 5 · Every obligation

Which law, which artefact, and where to see it

Governance tools tend to assert coverage. This is the actual ruleset our engine classifies with — served from api.riveract.ai/v1/obligations/ruleset, unauthenticated, so what you read here cannot drift from what the product does. Pick a role and a risk tier and you get exactly the obligations that land on it, what each one demands, what we produce for it, and where that artefact lives.

Your role for this system
Risk tier
Triggers
Read this before quoting a date Applicability is derived from role × tier × trigger, and every obligation the product generates carries its own rationale — never a bare verdict. The dates are Omnibus-aligned as politically agreed in mid-2026; verify the final Official Journal text for your market before relying on them. This is indicative and counsel-confirmable. We produce the evidence; your advisers produce the opinion.
Step 6 · Where to look

What is public, what needs a login, what is synthetic

Four surfaces. Two of them need nothing from you at all.

SurfaceAccessWhat it shows
demo.riveract.ai
this page
public The evidence chain, verified in your browser against our production key — and the full obligation ruleset above. Nothing transmitted, no account.
api.riveract.ai/readiness public A 15-minute self-assessment returning a scored obligation map for one system, with dated deadlines and the gaps ranked. Stateless — no login, stores nothing.
app.riveract.ai
the console
login The six planes against your own tenant: inventory and shadow AI, classification, findings, policy decisions and oversight, incident clocks, the evidence vault, generated Annex IV / FRIA / model cards, and the Art. 22 mandate book.
Danubia Group
the demo tenant
synthetic An invented Central European bank and insurer. Every row created by a script calling the same public API you could call — no screenshots, no fixtures. It exists so a demo can show a populated console honestly.
Step 7 · Your own records

Verify a chain you were sent

If you hold an exported RiverAct evidence chain — from an audit pack, a due-diligence request, or a dispute — paste it here. Verification runs in this tab. Nothing is transmitted. You can also read this page's source, or do the same job in fifty lines of your own code.

Prefer your own tooling? Everything on this page is reproducible from the command line. The public key and the specimen are served unauthenticated; the anchor's timestamp verifies with stock OpenSSL.
curl -s https://api.riveract.ai/v1/evidence/pubkey
curl -s https://api.riveract.ai/v1/evidence/sample

# and the RFC-3161 timestamp over an anchor's Merkle root:
openssl ts -reply -in resp.tsr -text
openssl ts -verify -digest <root> -in resp.tsr -CAfile cacert.pem -untrusted tsa.crt