Visit chain · 0 blocks · tip GENESIS
EU AI Act · transparency duties live 2 Aug 2026 · high-risk duties 2 Dec 2027 · fines to 3% of global turnover

Monop Content presents AILeash — a compliance API for platforms running AI. Governance, child safety and fraud alerts on one tamper-evident engine

Every AI decision.
Sealed. Provable. Yours.

The compliance layer you build on top of. You put sebbi.pro underneath your app; it scores every AI decision in under 30ms — ALLOW, CHALLENGE or BLOCK — and seals each one into a SHA-256 chain nobody can quietly edit. Not a hacker. Not an employee. Not even us — the chain is timestamped through OpenTimestamps into Bitcoin, so the clock sits outside our control, and other platforms witness our chain so we cannot rebuild it either. Built to support EU AI Act Articles 9, 12, 13 and 14, the Online Safety Act, the ICO Children's Code and the DSA. When a regulator asks what your AI decided and why, you answer in one API call. Free for 90 days. Then 50p per device. No tiers, no sales calls.

Block 001 · How it works

Three steps. That is it.

What normally costs £50,000 a year in compliance tooling, free for 90 days and then 50p per device.

Step one

Get a free key

Sign up below. No card, no contract. Everything free for 90 days — the full engine against your real traffic, plus a step-by-step installation guide straight to your inbox.

Step two

Send us the event

Each time a user acts, your platform posts the details. We score it across 9 signals in under 30ms and return ALLOW, CHALLENGE or BLOCK — sealed into the chain before you get the reply.

Step three

You set the price

Charge your users what you like. After your 90 free days, we take 50p per device per month — metered on the real devices that used your key. Everything above it is yours, every month.

Block 002 · One line of code

Add one line. Never think about it again.

The slowest part of any compliance tool is wiring it in. So we removed that part. Put one line above a function and every call it makes from then on is fingerprinted and sealed — automatically, forever, with nothing else to remember.

@witness()
def approve_loan(application):
What leaves

A hash. Nothing else.

The inputs and the result are hashed on your machine. The hash goes out; the data does not. Not in debug mode, not in an error, not ever — there is no code in the file that could send it. It's one short file and your engineer can read the whole thing over a coffee and confirm that, which is a better answer than a promise from us.

What it costs

A tenth of a millisecond

Measured, not estimated: 0.098ms added to each call. The network part happens on a background thread, so your code never waits for us. If we go down your application doesn't slow down, doesn't error and doesn't care — records queue on your own disk and go out when we're back.

What you get back

A receipt, per call

Each call gets its position in the chain and the tip it was sealed under. Hand those two values to an auditor and they can check it without asking you for anything. No dependencies to install — it's a single file using nothing but the Python standard library, which is the only kind of thing a bank's security team approves quickly.

What a receipt proves, and what it doesn't

It proves that this exact input and this exact output existed at or before the moment they were sealed, and that neither has changed since.

It does not prove the decision was right. Wrong answers seal exactly as cleanly as right ones. It does not prove your records are complete — it seals what you decorated, and it cannot know about the call you didn't. It does not prove your model behaved; it fingerprints what went in and what came out, not the reasoning in between.

Those three sentences are in the file's own documentation, at the top, where a buyer's engineer will read them first. Anyone selling you the opposite of them is selling something that does not exist.

Block 003 · Products

Five products. One engine.

The same 9-signal engine and audit chain underneath all of them. Pick one or take the lot. Every one is free for your first 90 days. Four run on our infrastructure; Sebdog runs on yours.

AILeashAI governance

Who it's for: any company whose AI makes decisions about people — banks approving loans, insurers pricing policies, fintechs blocking payments, marketplaces banning accounts. What it does: every decision your AI makes gets scored, explained in plain English, and locked into a record that nobody can quietly change. The EU AI Act says you must keep this proof. When the regulator knocks, you hand it over — block by block.

9 signals scored per event, verdict in under 30ms
Tamper-evident SHA-256 chain — alterations are detectable, by anyone
Built for EU AI Act Articles 9, 12, 13 and 14
Free for 90 days, no card to start
50p
after 90 free days · per device · per month
Get AILeash key →
SonicBoomCompliance layer

Who it's for: companies already running AI on AWS, Azure, Google Cloud, OpenAI or Anthropic who need compliance without slowing anything down. What it does: one line of code adds a full audit record to every AI call. Powered by our Sebdog engine — the same core that runs AILeash — scoring in 28ms, so fast your users never notice it's there.

One line of code — nothing else in your stack changes
Works alongside AWS, Azure, Google Cloud, OpenAI, Anthropic
SHA-256 audit chain on every call, automatically
28ms median decision time, measured on our own traffic
50p
after 90 free days · per device · per month
About SonicBoom →
SentinelFraud & anomaly alerts

Who it's for: online shops, payment companies, marketplaces — anyone who loses money to fraud. What it does: watches every event on your platform. When something looks wrong — 500 messages in a minute, a login from a strange country, a pattern that smells like fraud — Sentinel emails you an alert with the sealed evidence attached. You catch it while it's happening, not after the money's gone.

Real-time scoring, alerts the moment thresholds trip
Velocity signals catch burst attacks, takeovers and bots
Every alert backed by its own tamper-evident chain entry
Same one API call, same 90 free days
50p
after 90 free days · per device · per month
Get Sentinel key →
GuardianChild safety for platforms · Online Safety Act

Who it's for: consoles, games and social apps with young users. The Online Safety Act makes you responsible for keeping children safe, with substantial fines if you don't. What it does: you get an API key and build Guardian into your own app. Your young users get a Help button and grooming-pattern flagging inside YOUR app; you get a tamper-proof record proving your duty of care — the exact evidence Ofcom asks for.

Flags known grooming and manipulation patterns — never falsely tells a child a message is "safe"
Every safety event sealed to the audit chain — provable to a regulator on demand
Message content never stored, only a fingerprint — privacy by design
CEOP, Childline and 999 one tap away for every child, always
You get the API key and build Guardian into your own app — your design, our safety engine underneath. Free for 90 days, then 50p per device. The families on your platform never pay.
50p
after 90 free days · families never pay
Learn about Guardian →
SebdogThe engine, on your hardware

Who it's for: hospitals, councils, defence suppliers, banks — anyone whose answer to “where does our data go?” has to be nowhere. What it does: the same engine, running inside your building on your own machine. Decisions, events and the audit chain never leave your disk. There is no phone home: the licence is checked locally with a signature, so it runs on a box with the network cable pulled out. And you can prove that with a packet capture rather than taking our word for it.

One Python file, no dependencies to install, runs on a laptop or a rack
Zero outbound connections — verify it yourself with tcpdump
Your chain witnessed by outside operators — only a hash leaves, and only if you switch it on
Daily backups, sealed into the chain, so restoring an old one is visible
50p
after 90 free days · per device · per month
How Sebdog works →
Block 004 · On your own hardware

The data never leaves. The proof still does.

Every compliance vendor asks you to send them your data. That is a straight trade: you get an audit trail, they get your records. For a hospital, a council or a defence supplier that trade is simply not available, so those organisations end up with nothing but a spreadsheet.

Sebdog is the same engine running inside your building. Your decisions, your events and your hash chain sit on your disk and never move. We cannot read them. We cannot subpoena them out of our own systems, because they were never in our systems.

Which leaves the obvious problem, and it is the one everybody skips: a hash chain on your own server proves nothing against you. You own the file. You own the keys. You can rebuild it forward, re-sign it and renumber it, and nobody outside can tell. An audit trail the owner can silently rewrite is a diary, not evidence.

How that gets fixed

Somebody else holds your history

Sebdog publishes its current chain head — 64 characters, no data in it — and independent operators fetch it on their own schedule and seal it into their own chains. From that moment your past sits inside records you do not control. Rewriting it would mean persuading all of them to rewrite theirs in step.

Why fetching matters

You can't choose the moment

A timestamp is something you go and get. A peer polling you is something that happens whether you want it to or not. That difference is the whole point: you cannot cherry-pick which of your events get covered, because a chain head commits to every block behind it.

What crosses the wire

One hash, and only if you enable it

Witnessing is off until you turn it on, and when it is on the entire payload is a hash. It cannot be reversed and it reveals nothing but that your chain exists and has moved. If you never enable it, Sebdog makes no outbound connection at all.

How you know that's true

Read it, or watch it

It is one file of plain Python with no dependencies. Your engineer can read every line, or run it behind a packet capture and watch it stay silent. We are not asking to be trusted on this — a claim you can check in an afternoon is worth more than a certification.

licencesigned by us, verified on your machine with a public key — works with the network unplugged
chainSHA-256, every block linked to the one before it, on your disk only
verifyone call rewalks and rehashes every block from genesis — not a summary, the actual arithmetic
backupsdaily, last seven kept, and each one sealed into the chain — so quietly restoring an older database shows up
witnessyour head published for peers to seal; theirs sealed into yours. Off by default
The honest limit. None of this proves your decisions were correct, and none of it proves your records are complete — Sebdog seals what you send it and cannot know about what you didn't. What it removes is the ability to change the story afterwards. That is a smaller claim than the industry makes and it is the one that survives an auditor.
Get Sebdog · 90 days free →
Block 005 · Signal Packs

Nine signals as standard. Then add your own.

Every event is scored against the nine core signals below. A Signal Pack loads extra signals on top, tuned to one kind of risk — and the pack itself is sealed into the chain, so the rules that were running at the moment of a decision are part of the record, not a memory.

The core nine — always on, in every product
trust velocity · 60s velocity · 5m velocity · 1h amount device risk anomaly country shift unsafe country
Payments & fraudPack

For checkouts, transfers and payment platforms. Sharpens the money signals — sudden value jumps, new beneficiaries, card testing patterns and burst behaviour that a flat rule set misses. Pairs with Sentinel.

value jumpnew beneficiarycard testingburst velocity
Child safetyPack

For games, consoles and social apps with young users. Adds grooming and manipulation pattern signals, age-context weighting, and contact-escalation detection. Content is never stored — only a fingerprint. Pairs with Guardian.

grooming patterncontact escalationage contextoff-platform pull
Lending & onboardingPack

For credit, insurance and account opening — the decisions the EU AI Act treats most seriously. Adds identity-consistency and document signals, and forces a CHALLENGE pathway wherever a decision would materially affect a person's access to a service.

identity consistencydocument riskaffordability shiftoversight trigger
Marketplace integrityPack

For marketplaces and platforms managing seller and account abuse. Adds account-age, listing-behaviour and coordinated-activity signals, so bans and suspensions carry evidence rather than a support note.

account agelisting anomalycoordinated activityreinstatement history
Build your ownCustom pack

Your risk is not everyone's risk. Define your own signals, set the weights and thresholds, and run them on the same deterministic engine. Same inputs give the same outputs, every time — no drift, no retraining, nothing to explain away.

The part that matters at audit

Anyone can log a decision. The hard question, eighteen months later, is which rules were live when that decision was made — and most systems answer it with a changelog somebody could have edited.

Every pack has a version hash. When a decision is sealed, the pack hash is sealed with it. Change a weight, change a threshold, add a signal, and the pack gets a new hash and a new block in the chain. Rule changes become auditable events, never silent edits — and any decision can be traced back to the exact rule set that produced it.

decisionseal 9f3c… · verdict CHALLENGE · score 0.41
packpayments-fraud · v4 · hash 7ab1…
meaningthis verdict, under these exact rules, at this exact time — provable by anyone
Block 006 · Your margin

You set the price. You keep the rest.

Your first 90 days are free. After that we take 50p per device per month. Everything above it is yours — every month, for as long as they stay.

You charge per device per month
£
Number of devices
Working out what it saves you rather than what it pays you? sebbi.pro/savings runs the arithmetic on your own figures — ingestion, log storage, monitoring, compliance pipeline, engineering time — and says so in red if a proof layer costs you more than what you already run.

Type your exact device count. You are only ever billed for the real number of unique devices that actually use your key — not the number you type here.
User pays
£1.99
per device per month
You keep
£1,490
per month
We take
£500
per month · after trial
Block 007 · Referrals

Tell a friend. Earn forever.

Your signup comes with a referral code. Every device that signs up with it pays you 10p a month, for as long as it stays. No cap, no expiry.

Get your code

Issued the moment you sign up. It looks like REF-JOHN-1234 and it's yours permanently.

Share it anywhere

A colleague, a dev group, a call centre. Anyone who signs up with your code is linked to you for good.

10p
per device · per month · forever

Collect monthly

Ten referrals running 1,000 devices each is £1,000 a month — and it renews itself.

Block 008 · Identity

Seal your profile before someone clones it.

AI can now copy a face, a voice and a bio in minutes. The Sovereign Profile Notary locks your public identity — name, bio, links — into the same tamper-evident chain that seals AI decisions, with an official timestamp. You get a short verification code for your LinkedIn bio; anyone can check it in seconds. If an impersonator changes even one letter of your profile, the check fails in public. Free, takes 60 seconds, and your details never leave your browser unless you choose to publish them.

And for businesses: the Payment Notary. Invoice fraud costs UK businesses hundreds of millions a year — criminals intercept real invoices and switch the bank details. Seal your true details once, print a short code on every invoice, and every customer can verify in 10 seconds before paying. Switched details fail the check — the fraud dies before the money moves.

Seal my profile — free → Payment Notary — free → Check a code →
Block 009 · The law

What the law actually requires.

Most compliance advice tells you what the text says. This is what it means for your platform in practice — including the dates that moved.

Date
What lands
2 Aug 2026
Transparency duties apply. Tell people when they are dealing with an AI system. Mark AI-generated or manipulated content so a machine can read it. Disclose deepfakes to the people who see them. The Commission's enforcement powers over general-purpose models start the same day.
2 Dec 2026
Content-marking grace period ends — shortened from six months to three by the AI Omnibus. Also the date the prohibition on AI-generated non-consensual intimate imagery and CSAM takes effect.
2 Dec 2027
High-risk duties apply to stand-alone systems — Articles 9, 12, 13 and 14. Delayed from August 2026, but the evidence they require is historical: you cannot seal decisions you never recorded.
2 Aug 2028
High-risk duties apply to AI embedded in products.
EU AI Act 2024/1689 · as amended by the AI Omnibus
“If your AI makes decisions that affect people, you will need permanent, tamper-evident proof of every one.”

Fines reach 3% of global annual turnover or €15m — whichever is higher, per violation. The high-risk deadline moved to December 2027. The record you hand over then has to cover the years before it.

  • Art. 9 — continuous risk management
  • Art. 12 — tamper-evident record keeping
  • Art. 13 — plain-language explanations
  • Art. 14 — human override pathway
Online Safety Act 2023 · UK · in force now
“If users can talk to each other on your platform, you are legally responsible for protecting them — today.”

Ofcom is already investigating platforms. The ICO fined TikTok £12.7m for Children's Code violations.

  • Documented risk assessment on demand
  • Moderation with an evidence trail
  • Age-appropriate design for child users
  • Ofcom-ready audit trails
ICO Children's Code · UK · in force now
“If under-18s can reach your platform — even unintentionally — the Children's Code applies to you.”

The ICO can and does act against platforms that expose children to harmful automated decisions without protection.

  • Best interests of the child by default
  • Data minimisation for child users
  • No profiling of children
  • Human oversight of automated decisions
Digital Services Act · EU 2022/2065
“Show how your algorithmic systems work — and prove you've mitigated the risks they create.”

Very Large Online Platforms carry the heaviest duties, but systemic risk assessment reaches smaller platforms too.

  • Systemic risk assessment with evidence
  • Algorithmic transparency reports
  • Minor-protection evidence packages
  • Regulator-ready submissions
Block 010 · Coverage map

Article by article. Feature by feature.

The law names its requirements. Here is the exact engine feature built to answer each one — taken directly from the regulation map sealed inside the engine itself. No hand-waving: requirement on the left, mechanism on the right.

Requirement
What the law demands
How the engine answers it
EU AI Act · Article 9Risk management system
A continuous, iterative risk management process running across the AI system's whole lifecycle — risks identified, estimated and mitigated, not assessed once and filed away.
Continuous per-event risk scoring — every single decision, not a quarterly review
9 weighted core signals, plus any Signal Pack you load on top
Fully deterministic — identical inputs give identical outputs, forever
EU AI Act · Article 12Record keeping & logging
Automatic recording of events over the system's lifetime, with logs that ensure a level of traceability appropriate to the system's risk — records a regulator can rely on.
Every decision sealed into a SHA-256 hash chain at the moment it's made
Gapless per-key receipt sequence — a missing record is mathematically provable, not arguable
Public verification endpoint — anyone can re-check the whole chain, any time
EU AI Act · Article 13Transparency
AI systems must be sufficiently transparent that the people deploying them can interpret the output and use it appropriately — no black-box verdicts.
Plain-language reason codes on every decision — velocity_spike, high_amount, country_shift, low_trust
Determinism proved by public challenge, not by a published listing — send any inputs, keep the fingerprint, send them again next year; the verdict must not move under an unchanged code fingerprint
Score, verdict, reasons and active pack version returned together in the same reply
EU AI Act · Article 14Human oversight
High-risk AI must be designed so that natural persons can effectively oversee it — able to intervene, override or interrupt the system's decisions.
The CHALLENGE verdict — a built-in pathway that stops the action and asks a human
Commit-before-reveal — the reviewer's own call is sealed before the machine's verdict is shown to them
Dwell time and divergence rate recorded per reviewer — rubber stamping becomes visible in the data
BLOCK verdicts trigger a real-time email alert with the sealed evidence attached
Online Safety Act 2023UK · in force
Platforms where users interact carry a duty of care — illegal-content risk assessments, protections for children, and evidence of moderation Ofcom can inspect.
Guardian flags known grooming and manipulation patterns in real time
Every safety event sealed to the chain — a moderation evidence trail, not a policy PDF
CEOP, Childline and 999 one tap away for every child, always
ICO Children's CodeUK · in force
Services likely to be accessed by under-18s must put the child's best interests first: data minimisation, no profiling of children, human oversight of automated decisions.
Deterministic scoring — no behavioural profiling of children, ever
Message content never stored — only a fingerprint; privacy by design
Full audit trail of every automated decision touching a young user
Digital Services ActEU 2022/2065
Platforms must assess and mitigate systemic risks created by their algorithmic systems — and show the evidence, not just describe the intention.
Sealed, per-decision evidence of how algorithmic systems actually behaved
Chain records ready to attach to a systemic risk assessment or transparency report
Verifiable by the regulator directly — not just by you
One more thing the engine does that most don't: the regulation map above is itself sealed into the audit chain, alongside the version hash of every Signal Pack in use. Whenever coverage is updated to match new guidance, that change becomes a sealed, timestamped block — regulatory updates are auditable events, never silent edits. And to be straight with you: this table is a design mapping of engine features to legal obligations, built to support these requirements — it is not a certification, because no software alone can be one. Your lawyers stay in the loop; our chain gives them the evidence.
Block 011 · Human oversight

Nobody can prove a person thought about it.

We will say the thing the rest of this market avoids. You cannot prove genuine human oversight happened. Thinking is an internal state and no amount of logging reaches it. Any vendor telling you they have solved that is selling you something that does not exist.

But rubber stamping is not an internal state. It is a pattern — and patterns leave marks, if you record the right things in the right order at the time. That part is solvable, and this is how.

One · Order

Commit before reveal

The case goes to the reviewer without the machine's verdict. Their own call and their reasoning are sealed first. Only then is the verdict revealed. Two blocks, in that order, in a chain that cannot be reordered — so nobody can have simply agreed with an answer they had already seen.

Two · Attention

The clock is on the record

The gap between opening a case and committing to it is sealed with the decision. A 0.8 second approval sits in the record permanently, next to a two minute one. Not proof of thought — but four hundred sub-second calls is not something anyone explains away.

Three · Independence

Divergence is measurable

A reviewer who has never once disagreed with the machine is visible in the data. One who diverges sometimes is demonstrably exercising judgement. Agreement rate, median dwell and the proportion of sub-two-second calls, per reviewer, all sealed.

What an auditor actually gets

Not an assertion that oversight happened. A dataset they can test — and one a rubber stamper cannot hide inside. The reviewer's judgement, sealed before the answer was known. The time they took. How often they diverged. All of it in the same chain as the decision itself, anchored outside our reach.

openedcase OVS-3A05 · material sha256 7e63… · verdict withheld
committedreviewer CHALLENGE · dwell 74.2s · reasoning sealed
revealedmachine said BLOCK · reviewer diverged
meaningthis person decided before they knew — provable by the order of the blocks

And the honest limit, because you will find it anyway: a reviewer can leave a screen open, and dwell time is gameable by anyone deliberately gaming it. If a platform shows its own staff the verdict before calling us, the ordering guarantee is worth nothing. That constraint is documented in the code, not buried — the guarantee is only ever as good as the integration honouring it.

Block 012 · The outside clock

Pinned from both sides. Before and after the fact.

A hash chain proves nothing was altered after the fact. On its own it does not prove when the chain was built — because in principle whoever runs the system could rebuild the whole thing and date it however they liked. Every vendor promising you an immutable audit trail has this hole in it. Most don't mention it.

So we moved the clock outside our own building. At regular intervals the current tip of the chain is submitted to OpenTimestamps, which aggregates it with thousands of unrelated timestamps into a single Merkle root and commits that root to the Bitcoin blockchain. Several independent calendar servers do this in parallel, so no single one of them can fail, disappear or lie without the others contradicting it. From that moment the timestamp is not ours to move, not ours to re-issue, and not ours to quietly correct. Rewriting a sealed record would mean rewriting Bitcoin.

Said precisely, because a reviewer found us saying it loosely. Anchoring is a property of an individual proof, not of the chain. Submitting a tip to OpenTimestamps is not the same as that proof being confirmed in a Bitcoin block — confirmation takes hours, and until it lands the proof is pending. So a tip is either covered by a confirmed proof or it is not, and we will not describe the chain as anchored while a proof covering it is still waiting.

Check the real state at /x/ots/status — it lists every proof, which are confirmed and which are pending, and returns the raw .ots file so you can verify it against Bitcoin without us. We publish that route because it is the one that can show us waiting.

What it proves

This record existed, then

Once a proof confirms, the chain state it covers is fixed in a public ledger you can check without asking us for anything. Existence and integrity, evidenced by a third party — not asserted by the vendor who produced the record. Before it confirms, the proof is pending and says so.

Why it matters at audit

Backdating stops being possible

The usual challenge to any audit trail is "you could have written this last week." An anchored chain answers it with arithmetic instead of an assurance. The regulator verifies it themselves.

What you do

Nothing to set up

Tips are submitted for anchoring automatically, underneath every product. No wallet, no crypto, no tokens, no volatility, nothing for you to hold or buy — Bitcoin is used purely as a clock nobody owns. You never touch it.

What you get

A reference anyone can check

Each anchor returns the chain tip it sealed and the transaction that carries it. Hand those two values to an auditor, a court or a customer and they can verify it without your help.

tipthe live chain state at the moment of anchoring
stampsubmitted to OpenTimestamps · aggregated into a Merkle root · root committed to Bitcoin — hours, not seconds
calendarsseveral independent servers stamp it — the count is returned with every anchor
check/api/anchor-status — live, no key needed, no permission needed
statea proof is pending until it lands in a block, then confirmed. Both states are published. Pending is not hidden
resultonce confirmed, that record cannot have been created later than that block. Verifiable by anyone, forever, without us.
Straight with you, because someone will ask: no record verifies the truth of its own inputs — not a ledger, not a court transcript, not a bank's books. That is what recording is, and any vendor claiming to have solved it is selling something that does not exist. What can be proved is the decision itself, from both sides. Before: the input is sealed at the moment of capture, so it cannot be swapped afterwards to justify the verdict. After: the scoring is deterministic and the pack version is sealed alongside it, so anyone can re-run that input and get the identical verdict — it cannot be re-explained later either. The only thing outside the seal is whether the world matched the data at the instant it was captured. Everything after that instant is arithmetic, and the story cannot be corrected in hindsight.
Block 013 · The witness network

One chain can be rebuilt. Ten cannot.

A confirmed anchor stops us backdating anything older than it. Good — and still not the end of it. So platforms witness each other.

This is running, not planned. Four chains are live and exchanging tips right now, one of them unattended and hourly since the first of August with several hundred observations behind it. The list is public and machine-readable at /x/roster/list — no key, no account, no permission. Peers run a single file on a cron line; there is nothing to install and no code of ours inside their stack.

Each platform periodically hands its current chain tip to its peers, and each peer seals that tip into its own chain. From that moment your history sits inside chains you do not control — chains that are themselves anchored externally. To rewrite your own past you would now need every peer who witnessed you to rewrite theirs in step and re-anchor all of it. That stops being a technical exercise and becomes a conspiracy, and it gets harder with every platform that joins.

What it takes

One request an hour

A chain tip is 64 characters. Recording one is a single sealed block. Ten platforms exchanging tips every hour is a few hundred blocks a day between all of them. The engineering was never the hard part.

Who runs it

No single authority

Every platform keeps its own product, its own customers and its own pricing. No participant is the arbiter, including us — which is the only reason the record means anything. You cannot buy an integrity property, you can only participate in one.

Who can check

Anyone

Ask whether we witnessed a given tip, and when, and you get a straight answer with the block it was sealed in. The network is queryable by third parties, not just described in marketing.

Who goes quiet

Visibly

Peers who stop publishing show as current, then stale, then silent. Those words measure time since we last saw them and nothing else — they are not a claim about anyone's uptime, and a peer who pushes manually will read silent while working perfectly.

Three ways to submit. Each says a different thing.

A peer chooses the lane. Every lane is free, and the record says which one was used, so nobody's submission is described as stronger than it was.

Lane one · Open

Anyone can submit

No account, no key. Hand us a name and a tip and it is sealed. Deliberately open, because a verification network with a signup form is a customer list. Everything submitted is sealed, including nonsense, because the record is of what arrived.

Does not prove who sent it
Lane two · Shared secret

Bound to a secret

An HMAC signature over the submission, using a secret both sides hold. Stated exactly, because a reviewer asked us to: this closes third-party submission under your name. It does not close submission by us under your name, because we hold the same secret.

Does not exclude the operator
Lane three · Your own key

Bound to a key we don't have

You generate an Ed25519 keypair and keep the private half. We store only the public half, so we can check your signature and can never produce one. Rotation has to be signed by the key it replaces, so we cannot swap your key either.

Excludes us. Arithmetic, not a promise
Why lane three exists: two independent reviewers arrived at the same gap in the same week — a shared secret cannot exclude the party holding it. The fix isn't a policy or a pledge, it's a key we mathematically do not have. It's public at /x/signed/spec, and the verification route is open to anyone, because a verification lane only account holders can check is not a verification lane.

Five founding seats. Four taken.

Joining is free and stays free, at any seat, forever. Witnessing is free. Every public verification route is free. The protocol code does not check whether anyone has paid, and it never will — an integrity property you can be cut off from is not one.

The first five chains are the founding cohort: a say in the specification the rest of the market ends up adopting, and an equal share of whatever the network ever earns. Four seats are filled. The fifth is open and being held for the right chain rather than the next one available.

Chain six onward joins free and is witnessed free, with no founding terms — the spec will already be written by then. Five is not a marketing number. It is how many integrations one person can support properly while getting this right.

The honest limits, stated up front: witnessing proves a tip existed at a time — it says nothing about whether the records behind it are true. Two platforms witnessing only each other prove very little; the strength comes from breadth, and a thin network is reported as thin. Nobody can be forced to keep publishing, and no design fixes that. Being listed on the roster is not partnership, endorsement or validation — it means a party submitted a tip. Those are properties of the design, not flaws we are hiding.

Ask about the fifth seat →
Block 014 · The notaries

Sealing the things that get argued about.

The engine seals decisions. These seal the processes around them — the parts that turn into a dispute eighteen months later, when everyone's memory has conveniently improved. Each one writes into the same chain, so the same verification and the same anchor cover all of it.

Data subject requestsNotary

Someone asks you to delete their data. Three things must be provable later: that you received it, that you actually considered it, and that you answered inside the legal deadline. Almost nobody can prove any of it — they have an email thread. This seals the whole lifecycle: received, assessed with the reasoning, extended, completed. The calendar-month deadline is fixed at receipt, and an extension is its own sealed block, so it cannot be applied retrospectively to cover a missed date.

The chain never holds the person's identity — the identifier is fingerprinted on arrival
Which answers the obvious objection: an append-only chain does not conflict with the right to erasure
The personal data is deleted in your systems as normal; what remains is a seal resolving to nothing
Overdue requests are one call away, not a spreadsheet nobody opened
included · every plan
ReconciliationNotary

A sealed chain proves records were not altered afterwards. It does not prove they were true when written — and an operator who seals fiction on time has a tamper-evident chain of fiction. Everyone honest knows this. Almost nobody says it. So we do what auditors actually do: take the sealed claim, go to the operator's own live system, and check whether the two agree.

The sample is chosen from the live chain tip — unpredictable in advance, unchangeable afterwards
The selection is sealed before any data is requested, so the flattering records cannot be cherry-picked
Mismatches are sealed exactly as permanently as matches
A run that was planned and never submitted stays visible forever as an abandoned test
included · every plan
DeclarationsNotary

You publish a file saying what must always be true of your decisions — "payments over £10,000 are never auto-approved", "every decision carries reasons" — and every record is tested against it. The obvious objection is that you wrote your own rules. Two things answer it: the rules are sealed before the records they judge, so a standard cannot be retrofitted to an outcome; and every version is kept, so loosening your own standard becomes a dated, permanent, public act instead of a quiet edit.

Declaration hashed, versioned and sealed on publication
Violations of your own published rules sealed with the same permanence as passes
Full version history — the March standard stays readable in September
Weak rules prove weak things, which is exactly why the declaration itself is published
included · every plan
Why these sit on one engine and not four products: every notary writes into the same chain as the decisions themselves. One verification endpoint covers all of it. One anchor covers all of it. Add a capability and it inherits the integrity properties of everything already there — no separate log to reconcile, no second thing to trust.
Block 015 · The evidence pack

The thing you actually hand to the auditor.

Everything above produces a chain. A chain is not a deliverable. When a regulator, an insurer, a court or an enterprise customer asks you to prove it, you need one file you can send them — and it has to survive being read by someone whose job is to find the hole in it.

So the pack does not summarise the chain. It re-verifies it. Every block is rewalked and rehashed from genesis at the moment the pack is built. A report tells you what a system claims about itself; this recomputes the arithmetic and fails loudly if it doesn't come out. Those are not the same product, and only one of them is worth anything in a dispute.

Re-verified
Every block rehashed and relinked from the first one. Not a count, not a status field — the actual chain arithmetic, run again, in front of you.
Gapless
Each key's records carry a sequence number issued at the moment of sealing, and the pack checks that sequence is unbroken. Tampering is one problem; quietly not recording something is the other one, and it is the one nobody else checks. A missing number is a missing record, and it cannot be hidden by deleting the block.
Witnessed
A snapshot of who was watching — which independent operators had sealed your chain head, and when they last did it. Internal integrity is the easy half. This is the half that shows somebody outside your building was holding your history.
Self-sealing
The pack hashes itself and seals that digest back into the chain. So the document you hand over is itself in the record — you cannot produce a flattering pack, send it, and later deny producing it.
Unbroken since
A date the chain has been continuously verifiable from. It costs nothing to start and it compounds every day you keep going. Two years of it is not something a competitor can buy, build or catch up on.
Stated limits
The pack carries its own list of what it does not prove, printed inside the document rather than in our marketing. An auditor who finds the caveats already written down stops looking for the ones you hid.
Build your evidence pack → Read the spec →
Why this is the part that gets bought. Nobody purchases a hash chain. They purchase the twenty minutes on a Friday when the request lands and the answer is a file rather than a fortnight. Everything else on this page exists to make that file worth reading.
Block 016 · Conformance

The instrument that would catch us failing.

Three things on this page have a soft edge, and we would rather name them than wait for you to find them. Oversight sealing only works if the platform using it doesn't show reviewers the verdict early. Witnessing only means something with breadth. A declaration is only as strong as the rules in it.

None of those can be fixed by arithmetic. All three can be measured — and a weakness somebody is measuring is a very different thing from one nobody is.

One · Probes

A case with a known answer

A probe is a real case with the machine's verdict deliberately set wrong. The reviewer cannot tell it apart from any other. Agree with it and you didn't evaluate it. And if someone's probe agreement matches their normal agreement, that is consistent with the verdict being visible before they committed — which is how you test an integration you cannot see inside.

Two · Breadth

Thin networks say so

Fewer than three live peers reports as weak. A single peer carries an explicit warning that two parties witnessing only each other can still collude. It doesn't stop a thin network — it stops one being presented as a thick one.

Three · Strength

Rules that never fire

Every rule is run against real records and reported on individually. One that has never constrained a single record is named in the output as decoration, not a standard. You can still publish a weak declaration. You can't publish one quietly.

Why build the thing that could embarrass us

Because "trust our design" is what everyone else says, and it is worth nothing. An evidence layer that cannot detect its own failure modes is just a nicer-looking promise. Ours reports a rubber stamper who caught none of eight deliberately wrong verdicts. It reports our own rules when they constrain nothing. It reports our witness network as weak when it is.

The probe method is not ours — it comes from a point James Stokes of Red Flag AI Pro made publicly about slipping a known error into a review queue and seeing who catches it. It was the right idea and it is credited in our whitepaper.

And its own limits: a probe tests a process, not a person — someone can catch one and rubber stamp the next hundred. An operator who works out which cases are probes controls their own screens. None of this is enforcement. It makes the alternative visible, which is the most an evidence layer can honestly claim to do.

Block 017 · The Proving Ground

Don't take any of it on trust.

Everything above this line is a claim. Below it is the live engine — no account, no email, no key. Send it a case and it scores it, seals it into the production chain, tells you exactly what would have changed the answer, and hands you the block number so you can check the lot yourself at endpoints that have never heard of you.

How this user has behaved before. 1.00 is spotless.
Log-scaled, so the first pound counts far more than the ten-thousandth.
Bursts are what automated attacks look like.
Independent of the others. Move one thing at a time and the counterfactual is exact.
The slowest window, and the least weighted.
Your own device signal, if you have one. Zero if not.
Your own anomaly signal. Zero if not.
Real engine. Real chain. Nothing about you is recorded.

Article 14 says a human must be able to oversee the machine. Everyone claims it. Almost nobody can show the difference between a reviewer who decided and one who agreed with an answer already on their screen.

So here is the case without the answer. Your verdict gets sealed first. Ours is revealed after. The chain fixes that order permanently — and the clock is running.

You commit once. That is rather the point.
Time on this case 0.0s

The engine has already decided. You will not see it until you have.

Live figures loading…
Chain growth
Blocks sealed per hour, last 24 hours. Every source, one sequence.
Where decisions land
Public scores across the range. The two lines are 0.35 and 0.70 — not chosen after the fact.
How long reviewers took
Time between seeing a case and committing to a verdict.

Every case run here becomes a genuine block in the production chain, covered by the same external timestamp as every customer decision. Public endpoints are rate limited, and the arithmetic is published in the whitepaper if you would rather check it than run it.

The ordering test — ten claims, published about ourselves every one of these is open, unauthenticated, and testable right now

We publish a conformance document listing ten checks, each carrying two separate flags: we built this, and — separately — you can verify it without an account. Those are different claims, and most of this market blurs them into one. Then we run a checker against our own document that refuses to mark generously: reachable is not verified.

the document/.well-known/ordering-test.json — the ten claims, and which are publicly demonstrable
the checker/self-check — runs all ten in your own browser and grades us without mercy
the console/console — grant authority, delegate it, exercise it, and watch the boundary hold (needs a key)
Prove a record is not there
A hash chain proves inclusion. Almost nobody does exclusion. Ask for any value at all and get back the two adjacent leaves with consecutive indices — nothing can sit between them, against a root committed before you asked.
Prove the log only ever grew
RFC 6962 consistency proofs, deliberately unmodified, so existing Certificate Transparency verifiers work against them without new code. Hand back any tip we ever served and we prove it is still on the chain we serve today.
Prove the clock is not ours
The chain tip goes to OpenTimestamps and into Bitcoin, and other platforms witness our chain so we cannot rebuild it either. The anchored tip is provably on this log, not a substituted one.
Prove the rules were bound in
The ruleset version is a component of the digest sealed with the decision, not a field beside it. The response hands back the exact string that was hashed — SHA-256 it yourself and confirm. No scoring logic is disclosed at any point.
packs/x/rulebind/packs
prove/x/rulebind/prove (POST)
Prove it is deterministic
Send any inputs you like. Keep the fingerprint. Send the identical inputs next month from anywhere. If the verdict ever moves under an unchanged code fingerprint, the engine is not deterministic and you hold the proof.
rules/x/replay/spec
fingerprint/x/replay/fingerprint
challenge/x/replay/challenge (POST)
Prove the agent was entitled
Every authority decision, traced to the human who granted it, with the person who accepted the risk named separately. Export one as a signed bundle and check it on your own machine with a script that never contacts us.

At the last run: eight verified, zero failed, two still amber. The two are reported as not yet demonstrable by an outside party, and they stay that way until they genuinely are — because a conformance document whose author scores full marks on the day he publishes it is a marketing page.

Block 018 · Authority

Authority, derived. Not assumed.

Everything above proves what your AI did. This proves it was entitled to. An agent takes an action; it got its authority from another agent, which got it from a system, which got it from a person. Nothing in the standard governance stack can show the authority used at the end derives from the authority granted at the start. Permissions answer one hop. Audit logs describe the aftermath. Neither derives anything.

One · Derivation

Every hop, back to a human

Every grant points at a parent and terminates at a named human principal. Scope, limits, purpose and validity must narrow at every hop — a child can inherit authority or reduce it, never widen it. A grant with no parent and no human issuer is not a root, it is an orphan, and it is refused.

Two · At execution

Re-derived, not trusted

The whole chain is re-derived at the instant of execution, not trusted from the instant of issue — because the interesting failures are never at the last hop. A parent revoked three hops up kills a child credential that is still technically valid, instantly, without anyone having to go and find it.

Three · Accountability

Who accepted the risk

Every lineage names a person who accepts the risk of that authority existing — separately from who granted it and who exercises it. An issuer says you may. A subject acts. Neither is a person putting their name to the capability being switched on, and that is the name an incident needs.

And the proof leaves the building

Export any authority decision and it comes back as a signed bundle carrying the entire authority path exactly as it stood at that instant, the parameters it was judged against, every digest, and an Ed25519 signature. Then check it somewhere else — with a script that has no dependencies, makes no network calls, and does not phone home, because a verification tool that reports back to the party being verified is not a verification tool.

get itcurl -sO https://sebbi.pro/verify-authority.py
run itcurl -s "https://sebbi.pro/x/continuity/proof?evaluation=<id>" | python3 verify-authority.py -
it checksthe signature · every digest recomputed · the whole derivation re-run from the published rules
thenit reaches its own verdict — and says so if that verdict disagrees with ours

And when authority cannot be derived, you do not get BLOCK. You get a proof of the refusal — which grant, which invariant, at which hop — and the verifier independently reproduces that failure in the same place. An agent that can prove it was not authorised is a different kind of object to one that was simply denied.

The honest limits, as everywhere else on this page: this proves authority was derivable from a human grant. It does not prove the human should have granted it, or that the parameters describe something that really happened. Grants are authenticated by sealing rather than per-issuer signatures, so an outside party verifies them through the chain rather than entirely offline. And the risk half of a composed verdict cannot be re-derived without the scoring engine — which the bundle states plainly rather than glosses over.

the rules/x/continuity/spec — enough to reimplement the evaluator and disagree with us
the decisions/x/continuity/decisions — real sealed evaluations, blocks listed beside allows
the path/x/continuity/trace?grant= — every hop, root first, with who accepted the risk
the proof/x/continuity/proof?evaluation= — the signed, portable bundle
the key/x/continuity/pubkey — Ed25519, RFC 8032, verifiable with any standard library
the checker/verify-authority.py — one file, no dependencies, no network
Run every check we publish → Read the whitepaper → Developer docs →
Block 019 · Install

Five minutes. Start to sealed.

No build step, no container, no dependencies to install, nothing added to your requirements file. If your organisation reviews new libraries before they go near production, this is one readable file rather than a supply chain.

Get your key

Fill in the form below. The key, your referral code and the install guide arrive instantly. No card, nothing to cancel — free for 90 days.

Drop in one file

Download sebbi_sdk.py and put it next to your code. Standard library only, so there is nothing to install and nothing new in your dependency tree.

# check it works before you wire it in
python3 sebbi_sdk.py --selftest

Set two values

Your key, and the name your records belong to. Environment variables, so nothing sensitive goes near your repository.

SEBBI_API_KEY=al_live_your_key
SEBBI_CHAIN=yourcompany.com
# recommended: keeps records safe if we're unreachable
SEBBI_SPOOL=/var/spool/sebbi

Add the line

Above any function whose decisions you need to prove. That is the integration. Nothing else in your code changes.

from sebbi_sdk import witness

@witness()
def approve_loan(application):
    # unchanged
    return decision

Check it landed

Every call now carries a receipt with its position in the chain. Print one, or read the counters, and you are done.

from sebbi_sdk import receipt_for, stats

result = approve_loan(app)
print(receipt_for(result))  # position + chain tip
print(stats())  # sent, sealed, dropped

Not on Python?

The whole protocol is a hash and one HTTP call, and it is published in full — run python3 sebbi_sdk.py --explain and you get the exact canonical form, the request shape and the rules. It ports in an hour to anything. Nothing about it is privileged, and we would rather you wrote your own than waited on us.

Running Sebdog instead? Then there is no SDK and no key in your code at all — the engine runs on your hardware and your application talks to it over your own network. How that works →

Block 020 · Start

AILeash API key. 90 days free.

Pick a product, add your name and email. Key, referral code and a step-by-step installation guide arrive instantly — everything free for 90 days, no card. When the trial ends you'll be directed to a secure Stripe payment reflecting only the real devices that used your key.

Your API key — save it now
Your referral code

Share it with anyone. Every device they sign up pays you 10p a month, for as long as it stays.

POST https://sebbi.pro/api/govern
Authorization: Bearer YOUR_KEY
Free for 90 days · 50p per device after the trial · billed via Stripe on real devices only