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.

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
Step 8 · The rest of the suite

What else exists, and how far along it actually is

Everything above is RiverAct. Two sister products cover the parts of the problem RiverAct deliberately does not, and they are at very different stages — so this section says which is which rather than implying three finished products.

live in production RiverAct Govern the flow. AI governance, liability and compliance — the six planes you just walked through. Observe, classify, monitor, govern, alert, and produce tamper-evident evidence. Everything on this page runs against it. All six planes, a signed evidence chain, and the obligation engine are deployed and reachable now.
engine built · hardening · no public API yet SignWard Papers for agents. A European agent identity and trust registry — verifiable credentials for AI agents, scoped mandates, instant revocation, anchored to a real legal entity under eIDAS. The engine is substantial — roughly 38,000 lines of Go, 41% of it tests — and its operator console is live. There is no public verification API yet, and the eIDAS anchoring is built and tested but switched off in production for want of a config file, not a contract. On 31 August its evidence chain was hardened: a signature-stripping hole closed that a CI test had been pinning open, signatures bound to their position and to SignWard's own signature domain, and a head commitment added so a truncated tail is detectable. A compatibility claim that was no longer true was retracted rather than patched. Private beta is the next milestone, not a shipped product.
evidence core in build SureWard Evidence for liability. Court-ready records of how AI behaved, defence dossiers for product-liability claims, and consented telemetry for insurers. As of 31 August 2026 it has a real core: a zero-dependency evidence library with RFC 6962 inclusion and consistency proofs — the part that lets you show a slice of a record without disclosing the rest — and a single-file verifier a stranger runs with bare node, no install and no network. What it still does not have: an API, a database, or any decision about what a record contains. That is deliberate — the product specification is the owner's to write, and inventing it now would be work thrown away. Dossier and Score are not started.
Why say this out loud A governance vendor that overstates its own maturity has failed its own test on the first question. If you want the detail on either sister product, ask — but nothing on this page depends on them.