One chain.
Every proof.

Every product below writes into the same tamper-evident SHA-256 chain. Most of what follows needs no account at all — the proof routes are open on purpose, because a proof you can only check with the prover's permission is not a proof. Base URL: https://sebbi.pro

Quickstart — seal something in one call

No account needed. Fingerprint your content locally, send the hash, get a sealed receipt back:

curl -X POST https://sebbi.pro/api/post/seal \
  -H "Content-Type: application/json" \
  -d '{"fingerprint":"<64-char sha-256 of your content>"}'

{
  "sealed":      true,
  "seal":        "43ac8582…",   // the chain block hash
  "block_index": 1042,
  "sealed_at":   1789420000.12,
  "code":        "43ac85820f19"   // 12-char public verify code
}

Notary — seal a fingerprint of anything no key

Three notaries, one pattern: POST a fingerprint to seal, GET to verify. All public, all free. Re-sealing the same fingerprint returns the original receipt with already_registered: true.

Post notary — prove exact text existed

POST /api/post/seal — body {"fingerprint":"<sha256>"}.

GET /api/verify-post?content=<sha256> — returns {"verified":true,"block_index":…,"sealed_at":…,"seal":…}, else {"verified":false}.

Identity notary — prove a profile is the original

POST /api/identity/seal — body {"fingerprint":"<sha256>", "public":true, "profile":{…}}. With public set, a limited display set (name, title, bio, linkedin, facebook, org) is stored so a checker can show them; otherwise only the fingerprint is sealed.

GET /api/identity/check?code=<12+ chars> — short code or full fingerprint.

Payment notary — stop invoice fraud

POST /api/payment/seal — body {"fingerprint":"<sha256 of the real bank details>", "display":{"business":…,"sort_masked":…,"account_masked":…}}. Only masked display fields are stored; the true details never are.

GET /api/payment/check?code=<12+ chars>&fp=<optional full sha256> — returns MATCH, MISMATCH or NO_SEAL. Either way the check itself is sealed and returned as a receipt, giving provable evidence of the check under PSR reimbursement rules.

Wire it into your stack

# 1. fingerprint locally — content stays with you
import hashlib, requests
fp = hashlib.sha256(content.encode()).hexdigest()

# 2. seal the fingerprint
r = requests.post("https://sebbi.pro/api/post/seal",
                  json={"fingerprint": fp}).json()
code = r["code"]        # store this next to your record

# 3. anyone verifies later — no account
v = requests.get("https://sebbi.pro/api/verify-post",
                 params={"content": fp}).json()

Put that where your system creates the thing worth proving — a post published, an invoice issued, a profile created — and every record from then on carries tamper-evident proof automatically.

Decision engine — POST /api/govern POSTBearer key

Score an event, get a verdict, sealed before the response returns. Deterministic: identical inputs always produce identical outputs.

curl -X POST https://sebbi.pro/api/govern \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "user_id":    "user_123",
    "action":     "payment",
    "amount":     49.99,
    "country":    "UK",
    "device_id":  "dev_abc",
    "anomaly":    0.1,
    "device_risk":0.05
  }'

Verdicts: score < 0.35 → ALLOW · < 0.70 → CHALLENGE · else BLOCK. Every verdict carries plain-language reasons. Trust is earned slowly on ALLOW and lost eight times faster on BLOCK, so burst attacks self-amplify.

Challenges — the exception workflow is built in

{
  "decision": "CHALLENGE",
  "challenge_url":        "https://sebbi.pro/verify-challenge?token=…",
  "challenge_status_url": "https://sebbi.pro/api/challenge/status?token=…",
  "challenge_expires_in": 900
}

Surface challenge_url to your user; they confirm or deny on the hosted page; the resolution is sealed as its own block; you poll the status URL until resolved: true. Tokens are stateless and HMAC-signed. Three lines: if CHALLENGE → surface URL → poll.

Try it with no key at all

The demo module runs the real engine with no account on any route — it is what the public Proving Ground is built on.

The chain — receipts, sequences, inclusion mostly no key

Every govern response includes receipt_seq: a per-key sequence issued in the same transaction as the chain write, gapless by construction. Store them. If you ever hold receipts 46 and 48 with no 47, a record has been omitted — provable by arithmetic.

Anchoring — and what "anchored" actually means here

Chain tips are timestamped into Bitcoin through OpenTimestamps. A proof is pending when the calendar accepts it and confirmed only once the transaction lands and the proof is upgraded. Both states are reported as what they are, everywhere, because your own verifier will say it first.

Completeness and consistency — prove what isn't there no key

Anyone can show you a log of what happened. The hard questions are whether anything is missing, and whether the log you were shown last quarter is the same log you are being shown now.

complete — inclusion, absence, completeness

A sorted Merkle tree per period, with the leaf count committed before any export is requested. Absence is proved by returning two adjacent leaves with consecutive indices: nothing can sit between them. Erasure is handled by tombstone — the payload is deleted by your system, the leaf is retained, the erasure event is sealed. That proves a record existed and was erased while holding none of its content.

consistency — append-only, demonstrated not asserted

An ordered RFC 6962 Merkle tree over every audit hash in write order, deliberately unmodified so existing Certificate Transparency verifiers work against it.

Replay and lineage mostly no key

replay — determinism as a black box

The scoring maths is never disclosed. No route returns source, weights, thresholds or intermediate values — only a one-way SHA-256 fingerprint of the deployed decision function. Proof works by public challenge instead: POST any inputs, the run is sealed, and resubmitting identical inputs later must give an identical verdict under an unchanged fingerprint.

curl -X POST https://sebbi.pro/x/replay/challenge \
  -H "Content-Type: application/json" \
  -d '{"inputs":{"action":"payment","amount":49.99,"trust":0.5,
       "v60":1,"v5m":1,"v1h":1,"device_risk":0.05,
       "anomaly":0.1,"country":"UK","country_shift":0}}'

lineage — provenance across organisations

Each decision can record the receipt hashes of its inputs and which chain each came from. The graph then composes, and every hop is verifiable through routes that already exist. External hops are named with a verification plan pointing at the other party's own host — never resolved or certified by us.

Authority continuity — derive it, don't look it up Bearer key

Everything above proves what your system did. This proves it was entitled to. An agent acts; it got its authority from another agent, which got it from a system, which got it from a person. A permission check answers one hop. An audit log describes the aftermath. Neither derives anything, so neither can see authority widening three delegations back.

Every grant points at a parent and terminates at a named human. Scope, limits, purpose and validity must narrow at every hop, and the whole chain is re-derived at the instant of execution rather than trusted from the instant of issue.

Issue a root grant

A root must be issued by a human, must state a purpose, and must expire. Authority with no stated purpose cannot be checked for intent drift later, so it is refused.

curl -X POST https://sebbi.pro/x/continuity/issue \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"issuer":"you@company.com","issuer_kind":"human",
       "subject":"orchestrator",
       "scope":["payments.refund","payments.read"],
       "constraints":{"max_amount":5000,"allowed_currency":["GBP"]},
       "purpose":"resolve customer refund complaints",
       "purpose_tags":["refunds","support"],
       "not_after":1786400000,
       "delegations_left":2}'

{ "grant": "g_9ec009c0a02345169788", "depth": 0,
  "risk_accepted_by": "you@company.com",
  "digest": "…", "block_index": 842 }

Delegate it onward

Same endpoint with a parent. A child may narrow and never widen; raising max_amount above the parent's is refused with the axis named.

Exercise it

curl -X POST https://sebbi.pro/x/continuity/exercise \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{"grant":"g_9ec…","action":"payments.refund",
       "params":{"amount":150,"currency":"GBP"},
       "purpose_tag":"refunds"}'

{ "verdict": "ALLOW",
  "authority_verdict": "ALLOW", "risk_verdict": "ALLOW",
  "authorised_by": "you@company.com",
  "executed_by": "refund-agent",
  "risk_accepted_by": "you@company.com",
  "delegation_depth": 1,
  "lineage": [ … every hop, root first … ],
  "lineage_digest": "…", "params_digest": "…",
  "block_index": 843 }

A refusal names where it broke rather than simply denying:

{ "verdict": "BLOCK",
  "broken_at": "g_mid…", "broken_invariant": "boundary_integrity",
  "reasons": ["amount=900 exceeds max_amount=200"] }

Bind the execution to the decision

An ALLOW is a decision about a request that may not be the request that ran. confirm re-derives the parameter digest from what actually executed, enforces the validity window, and can be spent exactly once — enforced by a unique index rather than a read followed by a write, so concurrent attempts cannot both win.

curl -X POST https://sebbi.pro/x/continuity/confirm \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{"evaluation":"e_05da…","action":"payments.refund",
       "params":{"amount":150,"currency":"GBP"},"outcome":"executed"}'

Revoke

POST /x/continuity/revoke — body {"grant":"g_…","reason":"…"}. Transitive by derivation: everything beneath stops evaluating immediately, with no descendant needing to be found. Actions already evaluated stay exactly as they were decided — revocation does not rewrite history.

witnessed — the gap authority cannot close on its own

A well-formed grant that was never issued passes every internal check, because issuer, scope and approver all arrive on the request. So a grant sealed at tree size M, plus an independent peer that accepted a head at size N ≥ M at time T, proves the grant existed before T in a log we cannot write to. Back-dated grants die without a new protocol.

The exported proof — and a verifier that doesn't need us no key

A proof you can only check with the prover's own online tool is a reassurance. So any authority decision exports as a self-contained signed bundle, and the checker runs on your machine with the network off.

curl -sO https://sebbi.pro/verify-authority.py
curl -s "https://sebbi.pro/x/continuity/proof" | python3 verify-authority.py -

With no evaluation the proof route returns the most recent decision, so you can start knowing nothing.

{ "bundle_version": "1.0",
  "issued_by": { "algorithm": "Ed25519", "public_key": "…" },
  "decision": { "verdict": "ALLOW", "lineage_digest": "…",
                 "params_digest": "…", "broken_at": null },
  "request":  { "action": "payments.refund", "params": {…} },
  "lineage":  [ … every grant as it stood at that instant … ],
  "chain":    { "audit_hash": "…", "block_index": 843 },
  "rules":    { … how every digest and the signature are computed … },
  "signature": "…" }

The verifier does four separate things, each able to fail on its own: signature (Ed25519 over the canonical bundle), integrity (every digest recomputed from the fields in front of it), derivation (the authority path re-run from the published rules), and agreement (its verdict compared with ours — a disagreement is reported as our failure, not its).

The refusal proof

When authority cannot be derived you do not get a bare BLOCK. The bundle carries the grant and the invariant that failed, and the verifier independently reproduces that failure at the same hop. An agent that can prove it was not authorised is a different object to one that was merely denied — and it is what a counterparty needs when an action does not happen.

RESULT: VERIFIED - BLOCK
This is a proof that the action was NOT authorised, and where it failed.
Checked with no network access, no dependencies, and nothing taken on
the issuer's word except the meaning of their public key.

The offline verifier for the rest of it

aileash_verify.py is the auditor's tool: one file, no dependencies, never touches the network. It checks completeness inclusion, absence, RFC 6962 ancestry and prefix proofs, and replay stability. Run --selftest and it builds trees internally and confirms that tampered proofs and a forged prefix are rejected.

The witness network — the part we cannot control no key, ever

A chain the operator can rewrite forward is a claim. The answer is not a better promise, it is a copy held by somebody else. Chains exchange tips on an hourly cycle; once a peer holds our tip it sits in their record, not ours.

Joining is free and ungated, permanently. The protocol code never checks subscription status. There is no membership list, no seat to grant and none to revoke — the roster is a record of who submitted and when, with first-seen dates anyone can verify.

The Ordering Test no key

Sequence is the only property that cannot be retrofitted. Content can be fabricated, timestamps argued over, a log rebuilt — but a commitment made before the information existed cannot be reverse-engineered afterwards. Ten checks, published as a discovery document any vendor can serve from their own domain.

rule_binding          commit_before_reveal   completeness_proof
absence_proof         consistency_proof      reproducibility
mutual_witnessing     external_anchoring     authority_tokens
reconciliation

Each check declares supported and, separately, demonstrable_publicly — because "we built it" and "you can check it without an account" are different claims, and separating them is what stops an operator marking their own homework.

Packs — three different things, one chain

The word does three jobs, so here they are apart.

Cost packs — the library

Nine signals: exposure, size, ask, depth, tools, loop, burst, grind, novelty, plus raw counts and a composite score. Rules are written in a small expression language with no function calls, attribute access or strings in the grammar — nothing reaches eval. Every rule requires a stated reason or publishing fails.

A pack can return allow, downgrade, challenge or block. It can never return serve, and it can only make the engine's verdict stricter, never weaker — capping is reported rather than silently applied.

Evidence packs

On-premise — Sebdog runs without us

One Python file, standard library only, local SQLite with WAL, its own audit chain, daily sealed backups. Every decision, the chain and the database stay on your hardware.

python sebdog_engine.py --token-file licence.token --port 9090 --chain your-chain-name

That last pair of routes is the point of it: the only configuration where the data never leaves your building and the record is still externally witnessed. Pair it with meshwitness.py to run the exchange.

Client libraries and the metering gate

The wallet gate

Give an agent a budget and terminate it when the budget is gone. charge is the gate: it returns allowed true or false and seals every charge into the chain, so the spend record and the decision record are the same record. Balances are integer millipence — no floats.

Free tools no key on any route

Errors and router behaviour

Payloads are capped at 200KB. Public routes carry per-IP limits; keyed routes are metered per key.