The Pitch How it works Architecture Live preview Glass box What we claim Verify Talk to us
© Predict AI · Adaptive Intelligence Fabric
Public verification guide

Verify AIF yourself. From your laptop. In five minutes.

Four read-only probes against a real signed audit chain hosted at aif.predictai.ai/verify-data. The cryptography is real. Every hash recomputes. The Ed25519 signature verifies against the published public key. Copy a command, paste it into your terminal, watch it work.

Time: ~5 min Required: curl · jq Network: public HTTPS Read-only: nothing you do can break it
This is a verifiable demonstration, not a placeholder. The DID document, audit chain, per-entry signatures, and Merkle root are all real and signed with a real Ed25519 keypair. Run the commands below — they work. For end-to-end chain + signature verification with a single command, see the one-line verification script at the bottom of this page.
PROBE 01

Who issued the signatures?

PROBE 02

Has anyone tampered with the log?

PROBE 03

Are individual decisions signed?

PROBE 04

Do the agents named actually exist?

The four probes

Copy. Paste. Verify.

Each probe fetches a real artifact from aif.predictai.ai/verify-data and shows what you'll see in your terminal. The outputs printed below are the actual current responses, not screenshots.

PROBE 01

Who signed the audit trail?

Retrieve the W3C DID document — a public identity record that binds AIF's public signing key to a verifiable name. If the signer isn't in this document, the signature is forged.

$curl -s https://aif.predictai.ai/verify-data/did.json | jq '{id, verificationMethod: .verificationMethod[0].id}'

{
  "id": "did:web:aif.predictai.ai:verify-data",
  "verificationMethod": "did:web:aif.predictai.ai:verify-data#key-1"
}
What it proves
The instance has a stable, publicly discoverable identity. The DID document follows the W3C DID Core 1.0 specification and contains the Ed25519 public key used to sign every audit entry. Any auditor can fetch this and verify signatures without access to our servers or source code.
PROBE 02

Has the log been tampered with?

Ask the system to verify its own audit chain and report whether every entry is intact. The system answers true or false — and refuses to start at all if the answer would be false.

$curl -s https://aif.predictai.ai/verify-data/audit-chain.json | jq '{valid, entries, merkleRoot}'

{
  "valid": true,
  "entries": 5,
  "merkleRoot": "a5460128e3313308ad3cdf2962c920acbbbcc56184031d32643bf14d44f8e66e"
}
What it proves
Every entry in the audit log has been verified against its cryptographic attestation. A single changed byte, a deleted row, or a reordered entry would flip valid to false — at which point the system stops accepting new work until a human investigates.
PROBE 03

Is each individual decision signed?

Fetch one audit entry and inspect its attestation. The chain-level guarantee above is built from per-entry signatures — you can drill down and verify any single row.

$curl -s https://aif.predictai.ai/verify-data/audit-entry.json | jq '{action, attested, signerDid, hash: .hash[0:24]}'

{
  "action": "capability.invoked",
  "attested": true,
  "signerDid": "did:web:aif.predictai.ai:verify-data",
  "hash": "c4a282ca2b5bcd55c09a12d8"
}
What it proves
Every single action the AI takes — every message, every tool call, every rejection — carries its own cryptographic signature and content hash. The signature follows W3C Data Integrity / Ed25519Signature2020. An auditor can verify any entry without trusting any other entry.
PROBE 04

Do the agents named in the log actually exist?

Audit entries reference agents by ID. Retrieve the live capability manifest to confirm each agent is registered, identified, and running — closing the loop between log claims and system reality.

$curl -s https://aif.predictai.ai/verify-data/capabilities.json | jq -c '.capabilities[]'

{"id":"research-agent","state":"active","trustLevel":"established"}
{"id":"communications-agent","state":"active","trustLevel":"established"}
{"id":"content-agent","state":"active","trustLevel":"established"}
{"id":"operations-agent","state":"active","trustLevel":"established"}
{"id":"finance-agent","state":"active","trustLevel":"probationary"}
What it proves
The agents named in audit entries are the agents actually running on the live instance. Each has a trust level that updates based on observed behaviour. If an agent misbehaves, the operator can kill it from the dashboard — the kill event itself lands in the signed audit trail.
The tamper test

What happens if someone edits the log?

This one you can't run against our server (we'd rather not invite it). But you can see the outcome. If a single byte in the audit log is altered — accidentally, maliciously, or by disk corruption — the system refuses to boot on the next start.

# One byte flipped in a single audit row on disk. # Operator restarts the service normally. # systemctl restart aif [FATAL] Attestation chain verification FAILED. [FATAL] First invalid entry at chain index: 2,814 [FATAL] The service will not start. Investigate before restarting. Do not delete entries to "fix" the chain.

This is what tamper-evident actually means. The system would rather halt than lie to you.

The one-line verification

End-to-end, in a single command.

Recomputes every entry hash, walks the chain, rebuilds the Merkle root, verifies the Ed25519 signature against the public key in did.json. Exits non-zero on any mismatch. Requires curl, jq, openssl, and python3.

VERIFY ALL

One curl. Six checks. Exit 0 on success.

Audit the script before you run it — it's 80 lines of stock shell, readable here. Nothing it does requires elevated privileges. The script writes only to a private temp dir and removes it on exit.

$curl -s https://aif.predictai.ai/verify-data/verify.sh | bash

  AIF verifiable demo — chain + signature check

  ▸ fetching did.json
  ✓ did.json fetched
  ▸ fetching audit-chain.json
  ✓ audit-chain.json fetched (5 entries)
  ▸ recomputing each entry's hash + verifying chain linkage
  ✓ all 5 entry hashes verified — chain integrity intact
  ▸ recomputing Merkle root
  ✓ Merkle root recomputed and matches: a5460128e3313308ad3cdf2962…
  ▸ verifying Ed25519 signature over Merkle root
  ✓ Ed25519 signature over Merkle root verified against did.json public key

  All checks passed. The chain is intact, the Merkle root
  recomputes, and the signature verifies against the published
  public key. The same primitives run in production AIF deployments.
What it proves
The audit chain is not just signed — it is structurally tamper-evident, sequentially chained, and the integrity of the entire history collapses to a single Ed25519 signature any auditor can verify with one public key. The same cryptographic primitives that govern this demo govern production AIF deployments. The only thing that changes in production is the data, not the maths.
For your technical team

Ready for the architect-tier deep look?

The four probes above are the public proof. If you have an architect evaluating AIF for deployment, they get the full technical package — under NDA, signed in your browser in under two minutes.

Request architect access → Architecture overview

NDA is signed electronically — fill the form, click sign, receive architect-tier access. The countersigned PDF arrives by email; every step is logged in AIF's own audit chain.