Seals & integrity
Sealing is Axowl’s core differentiator: consequential records are hash-chained and sealed so that tampering is detectable and decisions are independently verifiable.
Sealed records
Section titled “Sealed records”Every sealed record carries integrity fields:
- A record hash, the previous hash and a sequence number — the hash chain.
- A security mode (default
General), an optional hardware signature and the time of sealing — the seal. - A notarization status, hash and time — a second signature layer over the seal.
- A seal algorithm identifier — the algorithm the seal was made with (
HS256by default; signed records useES256, hash-chain anchorsSHA256). Verification reads this field to pick the verifier, so every record keeps verifying under the algorithm it was sealed with; an unknown value is a verification failure, never a pass.
Sealed vs. notarized
Section titled “Sealed vs. notarized”Sealing is the hash chain. Notarization is a second signature over the sealed record, and the notarization status names what actually produced it: Software for a software-backed signer, TPM or PUF for a hardware-backed one. None means the record has not been notarized and Failed that notarization did not succeed. Records in every security mode are signed this way; an Iron record is signed by the PUF, and if the PUF is not ready the write is refused rather than stored unsigned.
What this enables
Section titled “What this enables”- Tamper detection — a background scanner re-verifies stored hashes; a mismatch raises an integrity violation.
- Independent verification — hashing is reproducible client-side, so a consumer can verify a record on their own device (the WASM core; see Integrity SDK).
Two kinds of seal — cryptographic vs. visual
Section titled “Two kinds of seal — cryptographic vs. visual”“Seal” means two different things in Axowl. Keep them distinct:
| Cryptographic seal (everything above) | Visual seal (the stamp you design) | |
|---|---|---|
| What it is | A hash chain + TPM/passkey key that makes a record tamper-evident | A rendered SVG stamp (round stamp / signature) drawn onto a document |
| Org-level | The organization’s master seal key; gates every mutation | The corporate seal image |
| Person-level | The personal seal — a member’s first passkey; the member-identity anchor | The designed personal signature/seal |
| Mutable? | Immutable — once set, it cannot be replaced | Re-editable anytime |
| Purpose | Integrity + authorization | A human-recognizable mark on approval documents |
The two are independent: a member designs a visual seal that appears on documents, and separately registers a cryptographic personal seal (a passkey) that anchors identity and authorizes actions. The cryptographic side is documented in Seals (reference); the visual designer is below.
The visual seal designer
Section titled “The visual seal designer”Company seal — created in Org Settings
Section titled “Company seal — created in Org Settings”Owners/admins design the corporate seal in Org Settings → General → “Create Seal”. The designer offers:
- Style —
western(round-double / oval / boxed; arc text + a center icon) orasian(round / square seal-script stamp with a per-glyph grid layout). - Script & reading order — Traditional / Simplified Chinese, Japanese, Korean;
traditional(right-to-left, top-to-bottom) ormodernorder. - Font — open-licensed webfonts (Noto Serif CJK, Gowun Batang, Nanum Brush…) plus the HJ Hanjeon seal-script font for Korean.
- Ink / text / icon / sliders — hex ink, top/middle/bottom/center text, a center icon (bowtie/star/…), and border-width / ring-gap / letter-gap / glyph-fill sliders.
The design is saved as a 256-px SVG with the fonts it uses embedded, so the stored image renders identically anywhere: <img>, approval documents, PDF, email. It is uploaded via POST /api/org/{slug}/settings/seal (multipart form, file field seal) and the change is recorded as an organization settings update. A pre-made raster/SVG file may be uploaded instead of using the designer, and DELETE /api/org/{slug}/settings/seal removes it.
Its role: the company seal is the issuer stamp on every approval document. This is a visual mark only; it is not the master seal key that gates mutations.
Personal signature / seal — created in Member Detail
Section titled “Personal signature / seal — created in Member Detail”Each member designs their own mark in Member Detail → “Personal Signature / Seal” — self-only (even Owner/Admin cannot edit another member’s). Four kinds:
kind | What it renders |
|---|---|
signature | The member’s name in a handwriting webfont (Great Vibes, Sacramento…) |
seal | A personal round asian stamp, drawn the same way as the company seal |
draw | A mouse/touch-drawn signature captured to vector SVG (< 8 KB) |
image | An uploaded PNG/JPEG/WebP/SVG |
Saved via PUT /api/org/{slug}/members/{connectedId}/signature {kind, spec} (8 KB cap, JSON-validated; kind: "none" clears it) or POST .../signature/image for uploads; both emit org.member.signature_changed (ORG025). The spec is stored once per person — shared across every org the person belongs to — and surfaced on /me as signatureSpec. Wherever it is drawn, fonts are limited to an allowed list, ink colors are validated as hex and SVG is stripped of scripts; a member with no design falls back to a red circle with their name.
Its role: the personal seal is what gets stamped into an approval document’s seal columns — the drafter’s seal auto-stamps the drafter (staff) column on submit, and each approver’s seal fills their column when they stamp. See Teams & reporting → how a request flows.