This document explains every piece of sebbi.pro the way a systems engineer would explain it to a colleague: what each part does, why it is built that way, how the parts fit into one evidence layer — and where the design goes next.
No marketing language. Where something has a limit, the limit is stated. Where something is not yet built, it is marked as such. That discipline is not decoration around the product; it is the product.
Nearly every system keeps logs. Logs live in databases. Databases can be edited by anyone with the right access — an attacker, an insider, or the operator itself. That means an ordinary log can only ever say "this is what we currently claim happened." It cannot say "and nobody has changed it since."
Most of the time nobody notices the difference. The difference appears the day someone with authority — a regulator, a court, an insurer, a customer in dispute — stops accepting your word and asks for proof. At that moment, "our system recorded it" and "here is proof it was not changed" are two different sentences, and only the second one carries weight.
The problem has become urgent for a specific reason. Software used to do what it was told, so a log of the inputs implied the outputs. AI systems produce outputs that cannot be derived from the inputs by inspection, which means the output has to be recorded as a fact in its own right — and the regulation now arriving says so explicitly. The volume of decisions requiring evidence has risen by orders of magnitude; the mechanism most organisations use to evidence them has not changed since the 1990s.
Everything at sebbi.pro exists to produce the second sentence, cheaply, automatically, as a by-product of systems doing their normal work.
Before any component, one design decision governs the entire platform: the governance layer is not an AI. Not a model, not a classifier, not a language model with a system prompt. It is arithmetic — fixed weights, fixed thresholds, an explicit published formula.
This is not a technical preference. It is the only arrangement under which the layer can do its job.
Put a model in charge of deciding whether another model behaved acceptably, and every property you needed from the governance layer disappears at once. The verdict cannot be reproduced, because the same input may score differently tomorrow. It cannot be truly explained, because the explanation is itself generated rather than derived. It drifts silently, because a retrained or updated model changes its judgements without anyone choosing to change them. And it can be attacked through its inputs, because anything that reads natural language can be manipulated by natural language.
Worst of all, it regresses. If a model needs governing, and the governor is a model, the governor needs governing. There is no bottom to that stack. The regress terminates only at something that cannot behave unexpectedly — which means arithmetic.
A regulator, a court or a counterparty examining a decision two years later does not want a narrative. They want to establish that the decision followed from the stated rules. Determinism makes that a mechanical check: take the sealed inputs, take the sealed ruleset version, recompute. If the result matches the sealed verdict, the decision was not a judgement call and was not tampered with — it was the rules applied to the facts, and anybody can confirm it without the vendor in the room.
This is the difference between a record that describes a decision and a record that reproduces it. Only the second is evidence in any strong sense. Section 28 turns that property into something a stranger can test directly, without being shown the rules.
At the centre of the whole platform is one data structure: an append-only chain of sealed records. Every product described below — the decision engine, the fraud detectors, the notaries, Brain — writes into a chain built the same way.
Each record is sealed at the moment it is created. The seal is a SHA-256 hash computed over the record's content together with the seal of the record before it. Because each seal contains its predecessor, every block's integrity depends on the entire history beneath it:
seal(n) = SHA-256( seal(n−1) · timestamp · event · result · basis )
verify: recompute every seal from genesis;
any mismatch localises tampering to an exact block index
Alter one character of one historic record and every seal after it fails verification. There is no way to repair the chain after an edit without recomputing every subsequent seal — and the current tip is recorded in the same transaction as every write, so even chopping records off the end is detected. The operator cannot rewrite its own records. Neither can we.
Engineering properties, stated plainly:
One sentence captures the design philosophy: a system that does not trust its own creator is the only kind whose records qualify as evidence.
The chain described above has a hole in it, and it is the same hole every tamper-evident audit product has. Most do not mention it.
A hash chain proves no record was altered after the chain was built. It does not, on its own, prove when the chain was built. An operator with full control of the system could in principle discard the whole chain and construct a fresh one from scratch, containing whatever it preferred, dated however it liked. Every seal in that fabricated chain would verify perfectly. Internal integrity is necessary; alone it is not sufficient, because the operator still controls the clock.
So the clock was moved outside the building. At a defined interval the current tip of the chain is submitted to OpenTimestamps. OpenTimestamps aggregates that tip with thousands of unrelated timestamps into a single Merkle tree and commits the root of that tree to the Bitcoin blockchain. The proof returned is a path from our tip to that root, and from the root to a Bitcoin block. Several independent calendar servers perform this in parallel, so no single calendar can fail, disappear or lie without the others contradicting it.
The distinction matters and is worth stating precisely, because the loose version — "we write your hash to Bitcoin" — is both technically wrong and commercially misleading. We do not make a Bitcoin transaction per anchor. We contribute to one. That is why anchoring runs continuously rather than when someone remembers the cost: the marginal cost of an anchor is effectively zero, and a timestamp that only happens when convenient is not a timestamp.
From that moment the timestamp is not ours to move, not ours to re-issue, and not ours to quietly correct. Fabricating an earlier history would require rewriting Bitcoin itself.
anchor: tip(n) → OpenTimestamps → Merkle root → Bitcoin block
returns: chain tip · transaction id · block height · time
proves: the chain stood in exactly this state at or before
that block — verifiable by anyone, without asking us
The oldest objection to any audit trail is a single sentence: you could have written all of this last week. Every assurance a vendor offers in reply is another claim from the party being questioned. An anchored chain answers with arithmetic instead. The person checking needs no account, no cooperation from us, and no continued existence of this company — the reference sits in a public ledger, permanently, and the check is the same check whether we are still trading or not.
That last property deserves dwelling on, because it is the one buyers of compliance infrastructure ask about last and depend on most: the evidence outlives the vendor. A customer's sealed history remains verifiable if this company disappears entirely. Section 30 extends that to the checking tool itself.
The chain — nothing has been edited since it was written.
The anchor — it was written no later than a fixed, externally witnessed moment.
Neither is sufficient alone. Together they close both directions: history cannot be rewritten, and it cannot be manufactured after the fact.
Anchoring closes backdating, but only up to the last anchor. Between anchors an operator with full control of their own server can still, in principle, construct a history and present it. The gap is small, and it is real, and it is the same gap every vendor in this market has.
It closes when platforms witness each other. Each platform periodically publishes its current chain tip; each peer seals that tip into its own chain. From that moment one platform's history is recorded inside chains it does not control, which are themselves independently anchored.
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 is no longer a technical operation on a database. It is a coordinated conspiracy between commercial competitors, and the difficulty scales with the number of participants rather than with the size of anyone's engineering team.
The economics make it practical. A chain tip is 64 characters. Witnessing one is a single sealed block. Ten platforms exchanging tips hourly generates a few hundred blocks a day between all of them — an integrity property strong enough to matter, at a cost small enough to ignore.
The route that accepts a chain tip requires no account, no key and no approval from anyone. That is not an oversight and it is not generosity — it is the answer to the only serious objection the model faces.
The objection is collusion: if we choose our witnesses, we can choose witnesses who will lie with us. It is a fair challenge and it has been put to us directly. The answer has three parts. First, a peer lying about us cannot help us — sealing a tip we never issued produces an entry pointing at a chain state that does not exist, which fails the moment anyone checks. A peer can only conspire with us, never frame us. Second, our peers are anchored too, so the conspiracy is not two parties agreeing a story but two parties defeating timestamps already published in a ledger neither controls. Third, and decisively: because anyone can witness us without asking, we cannot know who is doing it. A client, an auditor, a regulator or a competitor can pull our tip on a timer and seal it wherever they like. Collusion requires knowing your co-conspirators. Open witnessing removes that knowledge from us permanently.
Three further properties are deliberate. Nobody owns it: there is no licence and no revenue share, because an integrity property is participated in rather than purchased. Anyone can query it: a third party can ask whether a given tip was witnessed, and when, and receive the block it was sealed in. Silence is visible: peers who stop publishing are marked stale and then silent, and a replayed tip is flagged automatically, because a network that cannot be audited is not a network.
Because submission is open, the chain name in a submission is self-declared — anyone can post under any name. That is not solved with accounts, because accounts would close the network. It is solved by publishing how strong each claim is, and by remembering. Two checks run on every submission and neither can reject it; a submission is always sealed, and what changes is what is said about it. A liveness check fetches the submitted URL and reports confirmed (it serves exactly the tip submitted), live (it serves a different valid tip, which is what a busy chain does between submitting and being fetched) or self-declared (no URL, or unreachable). A name binding check records the URL a name was first seen at and compares every later submission: first-use, bound, or conflict where the same name has been submitted from a different address. A conflict is not proof of theft — operators move hosts — but it is exactly the event an auditor needs to see, and it is recorded permanently in the chain rather than resolved quietly by us.
What this does not do. Witnessing proves a tip existed at a time. It says nothing about whether the records behind it are true — garbage sealed on time remains garbage. Two platforms witnessing only each other prove very little; the guarantee comes from breadth, which is why participants should publish who witnesses them. The liveness check proves the submitter operates a live chain producing that data; it does not prove they are who they say, because anyone running a real chain can point a stolen name at their own URL. And no design can compel a peer to keep publishing. These are properties of the model, not defects in the implementation.
A tamper-evident chain proves records were not edited. It does not by itself prove records were not omitted — an operator could simply fail to write an inconvenient event. The receipt system closes that hole.
Every sealed decision is issued a sequence number, generated in the same transaction as the chain write. Sequences are gapless by construction: 46, 47, 48. The caller stores their receipts. If you ever hold receipts 46 and 48 with no 47, a record has been omitted — and you can prove it by arithmetic, not argument.
Edited records break the chain. Missing records break the sequence. Fabricated history breaks the anchor. Between the three, every way of quietly rewriting the past is detectable from outside, by anyone, without trusting the operator. That triple is the whole security model, and it is deliberately small enough to hold in your head.
Receipts protect the holder of the receipt. They do not help a party who never received one, and they cannot answer "is this the complete set" for someone auditing from outside. Section 25 closes that remaining gap.
There are two different records hiding inside "what a system did." The first is the action: this decision, this result, this timestamp, sealed. The second is the basis: what the decision was permitted to rely on when it acted — which sources, which versions of them, which ruleset it was checked against.
A seal on the action alone proves the action happened exactly as recorded. It cannot show what the action rested on — and a decision made on the wrong source, sealed, is just a tamper-proof error. So the engine seals both, in the same block:
basis = { sources: ["invoice_4471.pdf", "supplier_record_88"],
source_versions: ["sha256:ab12…", "sha256:cd34…"],
ruleset: "AI-TXT/1.0 + EU-AI-Act-2024/1689",
ruleset_version: "regmap-v7",
signal_pack: "payments-fraud v4 · sha256:7ab1…" }
The basis is canonicalised, hashed, and folded into the block seal. Edit the recorded basis later and the chain breaks exactly as if the action had been edited. Even "no basis was supplied" is itself sealed as a fixed sentinel — so the absence of a basis is a provable fact, not a blank that can be filled in later.
Basis sealing records what a decision rested on inside one organisation. Section 29 extends the same idea across organisational boundaries, where the source of a decision is another company's decision.
Article 14 requires that natural persons can effectively oversee a high-risk system. Every vendor in this market claims to satisfy it, and the honest position is that none of them can, including this one. Whether a reviewer genuinely deliberated is an internal state. No logging reaches it. Any product claiming to prove human thought is selling something that does not exist.
Rubber stamping, however, is not an internal state. It is a behavioural pattern, and patterns leave marks provided the right things are recorded, in the right order, at the time. Three mechanisms follow from that.
Order. The case is presented to the reviewer without the machine's verdict. Their own decision and their reasoning are sealed first; the verdict is revealed only afterwards. Two blocks, in that sequence, in a chain that cannot be reordered. A reviewer therefore cannot have merely agreed with an answer they had already been shown, because the chain fixes which came first.
Attention. The interval between opening a case and committing to it is sealed alongside the decision. A 0.8-second approval sits in the record permanently, beside a two-minute one. This is not proof of thought, and a single fast decision proves nothing. Four hundred consecutive sub-second decisions is a different kind of object — one that survives being explained away.
Independence. Agreement rate is recorded per reviewer over time. A reviewer who has never once diverged from the machine across a meaningful sample is visible in the data; one who diverges sometimes is demonstrably exercising judgement. The measurement is dull, which is precisely why it works.
What an auditor receives is therefore not an assertion that oversight occurred, but a dataset that can be tested — and one that a rubber stamper cannot hide inside. It sits in the same chain as the decisions themselves, under the same anchor.
What this does not do. A reviewer can leave a screen open, so dwell time is gameable by anyone deliberately gaming it. The system cannot establish that the material was read, only that it was available and that time passed. Most importantly, the ordering guarantee is only as strong as the integration honouring it: if a platform displays the machine verdict to its own staff before calling the API, the sealed order proves nothing at all. That constraint is documented in the code rather than buried in it, because a guarantee whose failure mode is undisclosed is not a guarantee.
SonicBoom is the scoring engine at the heart of the paid platform — the component that looks at an event and answers, in a fraction of a second: allow it, challenge it, or block it. It is the deterministic gatekeeper of section 2, made concrete.
Seven fields per event: who is acting (user_id), what they are doing (action), the value involved (amount), where from (country), on what (device_id), plus two optional risk signals your own systems may already produce (anomaly, device_risk). If you do not have those signals, send zero — the engine works from its own analysis. An optional eighth field, authority_token, carries delegated authority, covered in section 11.
The engine combines several independent signals: how fast events are arriving for this user and device (velocity), whether the country has changed or is off the expected list, how large the amount is on a log scale, and a per-user trust score learned over time. Trust is earned slowly with every allowed action and lost roughly eight times faster on every block — so an account behaving normally builds standing, and a burst attack destroys its own standing as it runs, making each successive attempt score worse.
Every verdict is sealed into the chain before the response returns, with its reasons, its jurisdiction tag, its active Signal Pack version, and — where supplied — its basis. The caller receives the verdict, the plain-English reasons, the sealed hash and the gapless receipt number in one response, in about 28 milliseconds.
When the verdict is CHALLENGE, the response includes a hosted resolution flow: a signed link your user can open to confirm or deny the action, a status endpoint you poll for the outcome, and an expiry. The tokens are stateless and HMAC-signed; the resolution is sealed into the chain as its own block. The exception path — the moment a human steps in — becomes part of the evidence trail rather than a gap in it. Integration is three lines: if the verdict is CHALLENGE, show the link, poll the status.
Two authenticated endpoints give the operator live sight of their own traffic: a pulse view (last hour's verdicts, recent decisions with reasons and seals, current chain tip) and a coverage view reconciling receipts issued against blocks sealed — one call that answers "is my evidence complete?" with a yes or no. When the engine blocks on your traffic, the sealed evidence is emailed to the account address, throttled to once per hour so a burst cannot flood you.
The core engine scores every event against nine signals: trust, velocity at three windows (60 seconds, 5 minutes, 1 hour), amount, device risk, anomaly, country shift and unsafe country. Those nine are domain-neutral — they describe the shape of behaviour, not the specifics of an industry.
It is worth being precise about what those nine are and are not, because it is a fair criticism and it has been put to us. They are transaction-risk signals: velocity, anomaly, device, geography. That is the lineage of the engine and it is the right toolkit for fraud and abuse. It is not a risk taxonomy for the AI Act's risk-management obligations, and describing it as one would be an overclaim. What the platform provides toward those obligations is different and stated plainly in section 18: the evidence that a risk-management system was defined, was in force at a given moment, and governed the decisions taken under it. The taxonomy belongs to the operator. The proof that it operated belongs here.
A Signal Pack is a versioned bundle of additional signals, weights and thresholds loaded on top of the core, tuned to one kind of risk. Packs run on the same deterministic engine — no model, no training, no drift. Identical inputs under an identical pack produce an identical verdict, permanently.
This is the part that matters at audit, and most systems do not solve it. Suppose an examiner asks, two years later, why a particular decision came out the way it did. To answer, you must establish which rules were live at that moment. Almost every platform answers from a changelog — a document someone with access could have edited afterwards. The answer rests on the operator's word again, which is exactly the thing this system exists to remove.
So every pack carries a version hash over its full definition, and when a decision is sealed the pack hash is sealed inside the same block. Change a weight, change a threshold, add a signal, and the pack takes a new hash and the change enters the chain as its own timestamped, anchored block.
decision seal 9f3c1a… verdict CHALLENGE score 0.41
pack payments-fraud · v4 · sha256:7ab1…
meaning this verdict, from these inputs, under these exact
rules, at this exact time — re-derivable by anyone
Rule changes become auditable events, never silent edits. And because scoring is deterministic, any sealed decision can be independently re-run: take the sealed inputs, take the sealed pack version, recompute, confirm the verdict was what the rules dictated. The decision is not merely recorded — it is reproducible.
Three questions sit around every automated decision that the decision itself cannot answer: who authorised this person to act, who is this person in the legal sense, and which rules governed the moment it happened. The delegation layer answers all three with the same machinery — sealed, deterministic, verifiable.
Human oversight only means something if the human doing the overseeing was actually authorised to. The engine issues signed authority tokens: a single call binds a user to a role, a spending limit and an expiry, HMAC-signed server-side. The grant is sealed into the chain as its own block — so "who gave this person this power, and when" is a permanent record, not an HR email.
Events can then carry the token. The engine verifies it deterministically: wrong user, expired grant, tampered token, or an amount above the granted limit each escalates the verdict and seals the reason — authority_expired, authority_exceeds_limit — into the record. An approval made outside granted authority is no longer a quiet judgement call; it is a flagged, sealed, examinable event.
The platform does not verify passports — specialist providers do that, and pretending otherwise would be theatre. What the engine does is make the outcome provable: a single call seals a verification result — provider, verified or not, and the SHA-256 fingerprint of the provider's reference — into the chain. The document itself, and even the raw reference number, are never stored. Later, "this user was KYC-verified by provider X on date Y" is a sealed fact any auditor can check, with zero personal data held to leak.
Every governed decision is tagged with the regulatory frameworks that applied at the moment it was made — EU AI Act, GDPR and DSA for EU-origin events, the Online Safety Act, UK GDPR and Children's Code for the UK, and so on — using a versioned mapping sealed inside the decision block. A multinational can answer "show every decision and which regulator's rules governed it" from the chain alone.
Sentinel is the fraud-watching layer: it looks at the speed and shape of activity rather than the content of any single event. The patterns it recognises are the classic signatures of attack: a flood of login attempts against one account (credential stuffing), a burst of transactions in seconds (card testing, automated abuse), an account appearing in a new country moments after its last action (takeover).
Sentinel and SonicBoom work together: Sentinel's velocity analysis is one of the signals driving SonicBoom's score, and when a pattern crosses the line the flag — what fired, when, on what evidence — is sealed into the same chain. The result for a fraud team is not just an alert, but an alert with a tamper-evident, externally anchored record behind it that survives scrutiny later: exactly what happened, in what order, provably unaltered.
Guardian applies the same machinery to a different and more serious problem: platforms where children are present. It watches for the recognised behavioural warning signs that precede grooming — pressure toward secrecy, attempts to isolate, moves toward private channels — and flags them.
Two design decisions matter here. First, message content is never stored — only a fingerprint of it. Privacy is preserved; what is kept is proof that the flagged exchange existed in the exact form it had. Second, every flag is sealed into the chain, so the evidence trail handed to a parent, a platform's safety team or the authorities is tamper-evident from the moment of detection and externally anchored shortly after. A safeguarding report backed by an anchored chain is a fundamentally stronger document than one backed by an editable log — and in the one context where this evidence may end up in front of a court, that difference is the entire point.
The notaries expose the chain directly to the public, free, with no account and no code. They exist for two reasons. The obvious one: most people and small businesses have no "system" to integrate, but still have things worth proving. The strategic one: a claim about evidence infrastructure is only credible if anyone can test it in thirty seconds without asking permission. The notaries are that test, permanently available.
All three share one privacy-preserving design: your content never leaves your device. Your browser computes a SHA-256 fingerprint locally; only that 64-character fingerprint is sent and sealed. The chain proves a document with exactly that fingerprint existed at that moment. You reveal the original only if and when you ever need to — and if you never need to, nobody ever sees it.
Seal the exact words of anything before you send or publish it: a quote, a contract, an announcement, a message. Later, anyone can verify those exact words existed on that date and have not been edited. A tradesman who sealed a £2,400 quote the day he sent it ends a "you said £1,800" dispute with mathematics rather than argument — and it cost him nothing and took ten seconds.
Seal your name, role and links; receive a short verification code for your public profile. If a fraudster clones the profile, the clone fails the check — the genuine one was sealed first, and the chain proves which came first. Impersonation defence is usually framed as detection; this reframes it as chronology, which is a far easier thing to prove.
A business seals its genuine bank details once; every invoice carries a short code; the payer checks the code before releasing funds. If an intercepted invoice's details were swapped — the classic authorised-push-payment fraud — the check returns MISMATCH and the payment stops. The verification itself is sealed and returned as a receipt, so both sides hold provable evidence that care was taken before money moved. Under the 2024 mandatory reimbursement rules, that record speaks directly to where liability falls.
Every seal returns a unique 12-character code — the holder's permanent claim to that specific record. One shared chain underneath, anchored like everything else; one private, verifiable receipt each. A sole trader's sealed quote and a bank's sealed decision sit in the same structure with the same guarantees. That was deliberate.
When a person asks an organisation to delete their data, three facts must be provable afterwards: that the request was received and on what date, that it was actually considered and on what grounds, and that it was answered inside the statutory deadline. Almost no organisation can prove any of the three. They have an email thread and a recollection.
The notary seals the whole lifecycle — received, assessed with the reasoning, extended, completed — as ordinary blocks in the main chain. The calendar-month deadline is computed and sealed at receipt, and an extension is its own sealed block recording both the old and new dates, so an extension cannot be applied retrospectively to cover a deadline that was already missed.
The chain never holds the person's identity. The identifier supplied by the caller is fingerprinted on arrival and only the fingerprint is stored or sealed. This answers the objection that an append-only chain conflicts with the right to erasure: it does not. The personal data lives in the operator's own systems and is deleted there in the ordinary way. What remains in the chain is a seal that resolves to nothing — evidence that erasure was handled correctly, without obstructing it. Section 26 completes that story by making the erasure itself provable to the person who asked for it.
A sealed chain proves records were not altered afterwards. It does not prove they were true when written. An operator who seals fiction on time possesses a tamper-evident chain of fiction, and everyone honest in this field knows it. The reconciliation notary attacks that directly, by doing what auditors have always done: substantive testing against source records.
The mechanism that makes it more than theatre is the ordering. A selection seed is derived from the current chain tip — a value the operator cannot predict in advance and cannot alter afterwards without breaking the chain — the records to be tested are chosen from it, and that selection is sealed before any data is requested. Only then are the identifiers returned for the operator to fetch from their own live system.
The operator therefore cannot choose which records are examined, cannot prepare only the flattering ones, and cannot quietly discard a test that went badly: every planned run is sealed at the moment it is planned, and a plan with no submitted result remains permanently visible as an abandoned test. Mismatches are sealed with precisely the same permanence as matches. A reconciliation system that can bury its own failures is decoration.
What a pass means, stated exactly: two systems the operator controls agree with each other, on records the operator could not select, at a moment the operator could not choose. That is not proof of truth. An operator fabricating consistently across every system in real time, without knowing what will be sampled, will pass. What it changes is the cost of lying — from editing one database to maintaining a coherent parallel reality across independent systems indefinitely, under unpredictable sampling, with every failure sealed permanently.
An operator publishes a file stating what must always be true of their decisions: payments above a threshold are never auto-approved, every decision carries reasons, and so on. Every sealed record is then tested against it and violations are sealed.
The obvious objection is circularity — they wrote their own rules and supplied their own data. Two properties answer it. First, the rules are sealed before the records they judge, so a standard cannot be retrofitted to an outcome; the chain fixes which came first. Second, every version is retained and sealed, so loosening your own standard becomes a dated, permanent and public act rather than a quiet edit. The strict rule published in March remains readable in September, next to the loose one that replaced it.
The declaration does not establish that an operator is honest. It converts their claims into something testable, and removes their ability to move the goalposts afterwards. An auditor reads the declaration, the violations and the version history — all three sealed, none of them editable.
What these do not do. Weak rules prove weak things: a declaration requiring nothing passes everything, which is precisely why the declaration itself is published rather than merely its pass rate. Reconciliation tests the operator's systems against each other, not against the world. And none of these can find a decision that was never recorded at all — gapless receipts cover that hole, not these.
Brain applies the evidence layer to a newer problem: the instructions fed to AI systems. An AI does what it is told — so the question becomes who checks what it is being told. A poisoned instruction ("ignore your rules", "export the customer data", "delete the logs") walks straight in unless something stands in front.
Brain is that something: a gate every instruction passes through before the AI acts. It checks against five categories of known-dangerous patterns — child safety, data exfiltration, compliance bypass, prompt injection, system destruction — with normalisation defences so unicode look-alikes, zero-width characters and spacing tricks resolve to the same fingerprint as the plain form. Dangerous instructions are blocked with the reason stated. And every decision, allowed or blocked, is sealed — with its basis, where supplied — into a chain with all the properties above: gapless, anchored, truncation-evident.
Brain is deliberately distributed differently from the rest of the platform: a single pure-Python file, free to download, standard library only, no cloud, no API key. It runs entirely on your own machine and your instructions never leave your system. It is meant to be read before it is run — every line of it — because a governance tool you cannot inspect is itself an ungoverned claim.
The final layer is not code but a convention, modelled on robots.txt and security.txt: two small public text files at well-known paths that let any organisation declare, machine-readably, how its AI is governed.
On their own these are declarations — claims, not proof. Anyone can write "tamper-evident audit" in a text file. Their force comes from the third step: sealing the declarations themselves into the chain, so "this is our governance, as declared on this date" becomes provable and its history becomes tamper-evident. Declaration → rulebook → enforcement: words, backed by rules, backed by working code, backed by an external clock.
Every piece above is one layer of a single stack. Reading from the bottom up:
The flow of a single event: an instruction or action arrives → Brain checks it against the declared rules → the delegation layer establishes authority, identity and applicable jurisdiction → SonicBoom scores it under the active Signal Pack, informed by Sentinel's pattern analysis → the verdict, its reasons, its jurisdiction tag, its pack version and its basis are sealed into the chain in the same transaction, with a gapless receipt → any upstream receipts it depended on are declared as lineage edges → the period it falls in is later committed with its exact total → the chain tip is anchored externally and handed to peer chains → and anyone, at any time, can verify the whole thing from outside without an account.
The design principle tying it together: evidence accrues as a by-product of the system working. Nobody remembers to log anything. Nobody compiles an audit file before an inspection. The proof exists because the system ran — and it is exactly as trustworthy whether the operator is honest or not, which is the only kind of trustworthy that counts.
The platform maintains a versioned regulation map — itself hash-sealed, itself served at a public endpoint — linking each engine capability to the obligations it helps evidence: the EU AI Act's record-keeping, transparency and human-oversight expectations (Articles 9, 12, 13 and 14, with delegated-authority tokens directly supporting Article 14's requirement for effective, attributable human oversight), the UK Online Safety Act's duty-of-care documentation, and the ICO Children's Code. Jurisdiction tagging extends the map to the per-decision level. The map is versioned, so when regulations change, the history of what was mapped when is itself tamper-evident.
The 2026 AI Omnibus amended the AI Act's application dates. The high-risk obligations moved back; the transparency obligations did not, and one deadline was shortened. The delay is widely misreported, so the dates are set out here rather than summarised.
The delay is widely read as breathing room. It is not, for one structural reason: the evidence these articles require is historical. An organisation assessed in 2028 will be asked what its systems decided and why across the preceding period. Records cannot be created retrospectively — that is the entire point of a tamper-evident, externally anchored chain, and it is why the useful moment to start recording is before the obligation bites rather than when it does.
The platform runs two ways. Cloud: integrate against the hosted API — a few lines of code where your system makes decisions, an API key for the paid engine, nothing for the notaries. Sovereign: for organisations whose data cannot leave the building, the engine runs entirely inside your own network — decisions, chain and database on your hardware. Licensing for sovereign deployments is offline by design: HMAC-signed 365-day tokens validated with pure cryptography, no phone-home, suitable for air-gapped environments.
Pricing is deliberately simple: 50p per active device per month. Partners embedding the platform set their own customer pricing and keep the margin above the platform fee. The notaries and Brain are free — they are the public proof the machinery works, and the standard (ai.txt) is open because standards only matter if anyone can adopt them.
Joining the witness network costs nothing and always will. There is no gate to price: the submission endpoint takes a tip from anybody, and as section 5 sets out, that openness is the mechanism by which the collusion objection is answered. A witness you must ask permission from is a weaker witness. Charging for admission would damage the thing being sold.
What is charged for sits in the layer above, where real work happens: the engine that produces a chain worth witnessing in the first place, hosted chains for operators who will not run infrastructure, periodic evidence packs, certification and listing, dispute-time evidence bundles, and implementation work. This is the shape of every open protocol with a commercial layer on it — nobody charges for the transport, everybody charges for what runs on it.
Two commitments follow, and they are architectural rather than promises. The open protocol code never checks whether anyone has paid — it has no concept of a subscription, so the claim that it is ungated is true by construction rather than by policy. And each paid service checks only its own status, so an operator who stops paying for hosting but runs their own infrastructure keeps sealing and keeps being witnessed indefinitely, with no gap in their record.
Evidence packs are issued periodically: a customer's record for the period, with every seal, its witnesses, its anchors and the routes to verify each, as a document they own outright and may hand to anyone. Non-payment removes nothing — sealed history cannot be withdrawn without breaking the chain, and is not — but coverage stops, and the gap that opens cannot be filled in later at any price, because the only way to have had a period covered was to be covered during it.
Mutual anchoring was described here as a future direction in v4. It shipped and is documented in section 5. Completeness, absence, erasure proofs, fork detection, reproducibility testing and cross-organisation lineage were unwritten when v5 was published on 1 August 2026; all six shipped in the following two days and are documented in sections 25 to 30. They are listed here only so readers of earlier versions can see what moved from intention to deployment, and when.
The witnessing spec currently assumes both parties run always-on servers, because the first two chains happened to. That assumption is not required by the design and excludes exactly the systems most in need of it: edge deployments, off-grid nodes, anything with intermittent connectivity. The proposed replacement removes it. A node registers a public key once and signs every tip thereafter, so identity binds to a signature rather than to a reachable address; tips are pushed in batches whenever the node reaches a network. Before pushing, the node pulls the peer's current tip and seals it into its own chain — so its offline work is bounded at both ends: no later than its sync by the peer's observation, and no earlier than its previous sync by the peer tip sealed inside it. The sync event becomes the proof rather than a gap in it. The residual limit is honest and inherent: the bounding is only as tight as the sync frequency, and within a long offline stretch the ordering remains the node's own assertion.
A pack is a versioned, hashable, portable artefact — which means it can be authored by someone other than the platform. A fraud consultancy, a child-safety charity, a trade body or a regulator could publish a pack encoding their own expertise, and any operator could load it and prove which version they ran. Two consequences follow. Expertise becomes distributable without becoming a consultancy engagement. And a sector body gains something it has never had: a way to publish a standard that adopters can prove they actually applied, rather than a PDF everyone claims to have read.
Insurers and lenders price uncertainty. Today an organisation's controls are assessed through questionnaires and periodic audit — self-report plus sampling. An anchored, reproducible decision history is a different class of input: continuous, externally verifiable, and impossible to dress up before an inspection. It is reasonable to expect verifiable evidence to eventually attract better pricing than asserted evidence, in cyber cover, professional indemnity and payment-fraud liability. That is a hypothesis about a market, not a product feature, and it is stated as one.
The notaries already produce records with the properties evidence law cares about: fixed content, fixed time, independent verifiability, no reliance on the interested party. The natural extension is tooling aimed at that use directly — export formats for disputes and small claims, verification a non-technical third party can complete unaided, and plain-language explanations of exactly what a seal does and does not establish. Much of the value here is not cryptographic but explanatory: the proof already works; what is missing is a way for a non-specialist to rely on it confidently.
ai.txt and comply.txt are the smallest part of the platform by code and potentially the largest by consequence. Conventions of this shape — robots.txt, security.txt — succeed not by enforcement but by becoming the obvious thing to do, and value accrues to the reference implementation that got there first and kept practising it. The adoption path is deliberately staged: technical (the tools work and anyone can check), then network (enough operators declare and anchor that checking becomes routine), then expectation (an organisation without a declaration and a verifiable history looks like one with something to hide). Nothing about that sequence is guaranteed. It is, however, the reason the standard is open and the notaries are free.
Honesty about a roadmap means naming its dependencies. A wide witness network requires peers willing to coordinate. Cross-organisation lineage requires a second organisation actually declaring its inputs — the mechanism is built and the graph is empty until somebody else joins it. A pack market requires authors with reputations worth attaching to their packs. Evidence-priced risk requires an underwriter prepared to move first. The standard requires adoption this platform cannot manufacture alone. Each is plausible; none is in hand. The parts of this platform that exist do not depend on any of them — which is the property that makes it responsible to write this section at all.
Written with the same rule as the rest of the document: no claims that cannot be checked, and limits stated plainly.
Three regimes converge. The EU AI Act's transparency obligations and full penalty regime apply from 2 August 2026, with high-risk obligations following in December 2027 and August 2028, penalties measured in percentages of global turnover. The UK Online Safety Act and the 2024 Payment Services reimbursement rules are already in force. Every one shares a single practical demand: records that survive scrutiny. Most organisations meet that demand with editable database logs — which is to say, they do not meet it.
The Omnibus delay is commercially useful rather than harmful, and any investor who raises it deserves the structural answer: obligations arriving in 2027 will be assessed against historical records, and evidence cannot be back-filled. That makes the intervening period the natural adoption window rather than a pause. Organisations that start recording in 2026 have a defensible history in 2028; those that wait do not, and cannot acquire one.
A deployed, running platform: the deterministic decision engine (~28ms), the tamper-evident chain with gapless receipts and public verification endpoints, external anchoring of the chain tip to Bitcoin, a live mutual witness network exchanging tips hourly with an independent platform, versioned Signal Packs sealed per decision, delegated-authority tokens, KYC result sealing, per-decision jurisdiction tagging, three free public notaries, the Brain instruction gate, the Guardian child-safety suite, Stripe-metered per-device billing with automatic quantity sync, and a partner/white-label programme. Added in August 2026: completeness and absence proofs, proof of erasure, fork detection, black-box reproducibility testing and cross-organisation lineage, plus a standalone offline verifier. All verifiable right now at sebbi.pro — including by recomputing the chain yourself, checking the anchor in a public ledger, and running the verifier on your own machine with the network disconnected. Built and operated by a solo founder at near-zero fixed cost.
Infrastructure, not consultancy: 50p per active device per month, metered on real usage, billed automatically. Marginal cost per additional device is effectively zero; the same engine serves one customer or ten thousand. Partners and white-label operators build their own margin on top and bring their own customers — distribution that scales without headcount. The notaries, Brain, the witness network and the offline verifier are free by design: they are the demonstration layer that converts scrutiny into signups.
Five parts. The chain: switching costs rise every day a customer's evidence accrues, because an anchored history cannot be migrated mid-stream without breaking its own continuity — the anchors belong to the chain that was anchored. Determinism: a competitor building its governance layer on a model cannot offer reproducibility, and cannot retrofit it without rebuilding from the bottom; section 28 makes that difference testable by anyone in under a minute. Time: an unbroken witnessed record is the one input nobody can shortcut, because the only way to have had last year covered was to be in it last year. The standard: an open convention this platform originated and practises, and standards accrue value to their reference implementation. And least copyable, the honesty position: every competitor overclaims; a documented refusal to — limits stated on every page, in this document, and sealed into the platform's own chain — is precisely the property a buyer of evidence infrastructure is buying.
Pre-revenue. The platform is live with a 90-day free trial converting to metered billing; the pipeline is founder-led outreach and inbound from the free tools. The raise is a seed round with one purpose: to move the founder full-time onto the platform and fund the first sales and partnership cycle through the August 2026 transparency deadline and into the 2027 high-risk window — the period in which the historical record a customer will later need is either being created or is not.
Contact: justin@monopcontent.com — the technical demonstration takes fifteen minutes and every claim in sections 1–19 and 22–30 can be verified during it.
Three claims in this document have a soft edge, and the same soft edge in each case: the arithmetic is sound, but the guarantee depends on something outside the engine.
Commit-before-reveal proves ordering — but only if the integrator does not display the machine verdict to its reviewers before calling the endpoint. Mutual witnessing draws its strength from breadth — two platforms witnessing only each other prove very little. A declaration is only as strong as the rules declared — one that constrains nothing passes everything.
None of these can be closed by the engine alone, and a vendor claiming otherwise would be overstating what software can do. What they can be is measured. A measured weakness is a different object from an unmeasured one: it can be reported, tracked, compared between deployments and put in front of an auditor. That is what conformance testing does here.
The method is borrowed openly from how substantive audit has always worked, and specifically from a point made publicly by James Stokes of Red Flag AI Pro: put a case with a known answer into the queue, unannounced, and see who catches it.
A probe creates a genuine oversight case whose machine verdict has been deliberately set to a known-wrong value. To the reviewer it is indistinguishable from any other case. Two things follow. If the reviewer agrees with the planted verdict, they did not evaluate the case — that is a caught rubber stamp, sealed like any other event. And if the integration is displaying the verdict before the case is opened, the reviewer's agreement rate on probes will track their agreement rate on ordinary cases; if they are genuinely deciding blind, it will not. The gap between those two numbers is the conformance signal, and it is the closest thing available to testing an integration you cannot see inside.
A single probe establishes nothing about an individual. A catch rate across dozens is evidence about a process, and the process is what is under audit.
The witness network reports how many distinct peers are live, how concentrated observations are in the largest of them, and how many have gone quiet. Fewer than three live peers is reported as weak, because it is. A single peer pair carries an explicit warning that two parties witnessing only each other can still collude. None of this prevents a thin network. It prevents a thin network being presented as a thick one.
Each rule in a live declaration is run against sealed records and reported on individually: how many records it actually constrained, meaning how many matched its condition and therefore had to satisfy its requirement. A rule that has never constrained a single record is named in the output as decoration rather than a standard. An operator can still publish a weak declaration. They can no longer publish one and have its weakness go unstated.
What conformance testing does not do. Probes test a process, not a person: someone can catch a probe and rubber stamp the next hundred cases. A sufficiently motivated operator who identifies probe cases controls their own interface and can treat them differently — probe references carry no marking a reviewer can see, but that is a speed bump rather than a wall. And none of this is enforcement. Nothing here compels a platform to witness widely, declare strictly or integrate honestly. It makes the alternative visible, which is the most that an evidence layer can honestly claim to do.
A whitepaper that only lists strengths is marketing. These are the limits, stated as plainly as the capabilities:
Every one of these limits is stated on the product pages as well. A system whose whole value is honesty cannot afford a single overclaim — and a vendor who tells you their limits is giving you the strongest evidence available about how they will behave when it matters.
Nothing in this document asks to be believed. Every claim about the chain is checkable from outside, now, without an account:
/x/replay/spec/x/complete/periods/x/complete/prove/x/consistency/ancestor/x/consistency/proof/x/lineage/trace · /x/lineage/impact/x/continuity/spec/x/continuity/decisions · /x/continuity/trace/x/continuity/proof · /verify-authority.py--selftest first so you are not trusting the tool either.Check us. Don't trust us. That is not a slogan; it is the system's design requirement, and the only standard by which an evidence layer should ever be judged.
Every audit log in existence proves what happened. None of them prove what didn't.
A hash chain proves inclusion. It cannot prove exclusion. So when a firm hands an examiner four hundred decisions, there is nothing in the mathematics that shows it was not six hundred. Gapless receipts (§6) protect whoever holds a receipt, but they say nothing to a third party auditing the set as a whole. Every audit ever conducted has run on the assumption that the sample handed over is the whole sample. That assumption has never been provable. It has simply been accepted.
At the close of each period, every record sealed in it is taken, sorted, built into a Merkle tree, and the root and the exact count are sealed into the chain — and from there anchored externally and witnessed like everything else. Crucially this happens before anybody has asked for anything.
Sorting is the whole trick. In an unsorted tree you can only prove a leaf is present. In a sorted one you can prove a leaf is absent: produce the two leaves either side of where the queried value would have sorted, verify both against the sealed root, and show their indices are consecutive. Nothing can exist between two adjacent leaves of a sorted tree.
Three claims become checkable, by anyone, with no account:
A commitment is worth nothing if it can be recomputed later to suit circumstances. So a period can only be committed once it has closed — attempting to commit a live period is refused, because more records could still arrive. A period can only be committed once; a second attempt returns the existing root rather than a new one. And the sorted leaf list is stored at commit time rather than recomputed on demand, so proofs issued this year still verify against the root sealed this year even after records are erased next year.
Two commitment types are supported: over the receipts themselves, and over the distinct subjects those records concerned — which is what turns "do you hold anything about me" into an answerable question. The tree is built over key material only and never over content, so a leaf reveals whether something exists, not what it said.
What this does not do. It proves completeness of what was sealed. A decision that never reached the chain is outside anything it can see; garbage in still applies. What changes is that the operator can no longer choose which of the sealed records to show. Absence is scoped to a period, so "no record, ever" means checking every committed period — which is why the period list is public, and why a missing period is itself a visible fact worth asking about. And an absence proof discloses the two neighbouring keys, so where keys are sensitive they should be hashed before they become leaves; the proof works identically and we hold nothing legible.
There is a contradiction sitting inside every append-only compliance product, this one included, and most vendors disclaim it rather than solve it: append-only and the right to erasure do not obviously coexist. If nothing can be removed, how can a person's data be deleted? And if it can be removed, what was the chain for?
Section 14 gives half the answer — personal data lives in the operator's own systems and is deleted there, while the chain holds only a fingerprint that resolves to nothing. This section gives the other half: proving to the person who asked that it actually happened.
The payload is deleted by the operator's own system. The position in the tree remains, and the erasure itself is sealed as its own dated event. What can then be established, holding none of the content:
A data subject therefore receives proof of erasure rather than an assurance of it, and the organisation receives something equally useful: evidence it complied, which survives the deletion of the very data that would otherwise have been the evidence.
Roots committed before the erasure still contain the leaf, and that is correct rather than a leak. A leaf is key material, not content; and a root that changed after the fact would prove nothing about anything, which would defeat the whole structure. Combined with the DSR notary in section 14 — receipt, assessment, deadline and completion all sealed in order — an organisation can evidence the entire lifecycle of a request without retaining a single field of the data it was asked to destroy.
Honest scope: the tombstone proves the erasure was recorded, and that the record cannot have been backdated. It does not prove every copy in every backup and downstream system was actually destroyed — that is an operational discipline, and no cryptographic structure can reach into systems it does not sit in.
Mutual witnessing means several parties hold hashes of our chain. Until now, none of them could check whether they were all holding hashes of the same chain.
Nothing in the design so far stopped an operator running two histories in parallel: serve chain A to a witness, chain B to an auditor. Both receive a valid tip. Both anchor it. Both verify perfectly against the copy they were given. Neither can tell, because there was no way to ask the question that would expose it