Skip to content
Axowl

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 entities (AuthIntegrityBase)

Section titled “Sealed entities (AuthIntegrityBase)”

Entities extending AuthIntegrityBase carry integrity fields (AuthIntegrityBase.cs):

  • RecordHash (on the base GlobalBaseEntity), PreviousHash, SequenceNumber — the hash chain.
  • SecurityMode (default General), TpmSignature (hardware seal), SealedAt — the seal.
  • NotarizedStatus / NotarizedHash / NotarizedAt — a second PUF-notarization layer.

Sealed vs. notarized (by tier)

Section titled “Sealed vs. notarized (by tier)”
  • General tier → NotarizedStatus stays "None"; the software seal (hash chain) is sufficient.
  • Standard / Iron tiers → after sealing, a central PUF signs again and NotarizedStatus becomes Notarized (via the Iron seal provider).

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).

Operational notes

Section titled “Operational notes”
  • Raw-SQL migrations bypass the interceptor → blank RecordHash='' in the migration so the seeder’s reseal pass re-seals via the interceptor.
  • jsonb columns must be canonicalized before hashing to avoid false-positive tamper alerts.
Theory: Proof of Decision Why authority is a sealed history of decisions, not a mutable snapshot.