DefendableLedger · Overview

What DefendableLedger is

DefendableLedger is the doctrine and the destination: the house owns its own trust layer end to end. No external chain anchoring. No hosted-LLM tax. Receipts compound inside the books, not on someone else’s chain.

Today that doctrine is real in two concrete, honest layers:

Layer 1 — REAL · LIVE: the cloud per-org hash chain

DefendableCloud ships a per-organization append-only hash chain, persisted in Postgres and served at api.defendablecloud.com. Every receipt carries:

org_seq — sequential index from 0, per org
parent_hash — links to the prior receipt’s receipt_sha256 (genesis parent = sixty-four zeros)
receipt_sha256 — sha256_hex(orjson.dumps(payload, OPT_SORT_KEYS))
receipt_id — DCR-{org_seq:06d}-{hex8}

Two endpoints expose it:

GET /ledger — the org’s chain in org_seq order
GET /ledger/verify — server-side recompute of every receipt_sha256, sequential-org_seq check, and parent-link check; returns {ok, receipts_checked, errors[]}

Hash-Chain Format → · Verify a Receipt →

Layer 2 — REAL · LOCAL: router checksummed receipts

DefendableRouter (v0.1, local / not publicly deployed) writes flat checksummed-not-chained receipts to data/receipts/YYYY-MM-DD.receipts.jsonl. Each line carries a checksum_sha256 over the canonical JSON of the receipt (excluding the checksum field). These are tamper-evident per line but are not linked into a hash chain like the cloud’s. Say so honestly.

Verify a Receipt →

The four rails — roadmap

The intended shape, once built:

Receipt · the canonical event record · hashed + provenance-stamped
Verdict · Tribunal · SwarmCurator-9B grades on the 4-dimension rubric
Training Pair · SwarmJelly · extracts the (input → output) pair · routes to a Royal Jelly tier
Deed · seals verdict + pair + receipt into an append-only hash-chained record

Four Rails →

The doctrine

Language becomes Assignment. Assignment becomes Receipt. Receipt becomes Verdict. Verdict becomes Deed. Deed becomes Books and Records. Books and Records become Trust.

Books and Records →

Why this beats external chain anchoring

External chain anchoring (Hedera, IPFS pin, BTC OP_RETURN, etc.) is a form of dependency that does not compound the eco system’s own corpus or trust. The right shape is:

In-house hash → in-house ledger → in-house tiered training pairs → in-house Hacks
The house owns the rail end to end
Trust layer compounds inside the books, not on someone else’s chain

Kill Hedera doctrine →

Where the records flow

Receipt
  ↓
SwarmCurator-9B grades · 4-dim rubric · Verdict minted        (roadmap)
  ↓
SwarmJelly extracts pair · Royal Jelly tier assigned          (roadmap)
  ↓
DefendableLedger record appended · hash-chained               (roadmap)
  ↓
Batch publisher commits to defendable-ledger repo             (roadmap)
  ↓
CF Pages rebuilds → defendableledger.com renders publicly     (roadmap)

Publication Flow →

Verify a receipt

The live cloud chain verifies server-side: GET /ledger/verify recomputes each receipt_sha256 over the canonical (orjson sorted-keys) payload, checks the sequential org_seq, and checks each parent_hash link. Tamper a stored payload and ok flips to false, pinpointing the offending org_seq. It is authenticated and scoped to the caller’s org — not an anonymous client-side check.