Seal AuditAudit-first

Audit & Compliance

Tamper-evident records for compliance workflows.

SealAudit records the operational story behind each workflow run: what triggered it, which verification checks ran, what action followed, and which workflow and document versions were in force.

Why it matters

Audit records are not ordinary logs.

Operational logs help run a product and diagnose activity. Audit events exist for compliance review, investigations, and tamper detection. SealAudit keeps those concepts linked, but does not treat them as interchangeable.

Tamper evidence

A simple hash chain per organization.

Each audit event includes a chain index, the previous event hash, and a deterministic hash of canonical event data. If someone changes a past event, recalculating the chain exposes the mismatch.

Recorded evidence

What is captured at each workflow stage

The audit model follows the same plain-language runtime structure users see in the product: Trigger, Verification, and Action.

Trigger

How the workflow started

  • Trigger endpoint accessed from a QR code or direct URL.
  • Timestamp, trigger context, and site/project context when configured.
  • The published workflow version resolved for that trigger.

Verification

Which checks ran and what they returned

  • Authentication status when identity verification is required.
  • Consent-based location result when geolocation policy is enabled.
  • Pass, fail, bypass, or error outcomes for each configured rule.

Action

What the user attempted or completed

  • Action type, step key, completion state, and timestamp.
  • Document version reference for document display and acknowledgement flows.
  • Evidence references needed for later search, review, and export.

Version-aware records

Historical records stay tied to the rules in force.

Compliance evidence is hard to defend when old records point at mutable instructions. SealAudit keeps workflow, document, and verification context explicit.

Workflow version references

A trigger resolves to a specific published workflow version, so historical records stay tied to the rules and steps that were active when the run happened.

Document version references

Acknowledgements and document-based steps reference the exact document version shown, so later document updates do not rewrite historical evidence.

Verification outcome references

Verification results remain explicit instead of being hidden inside generic logs, which makes exceptions and failures easier to review.

What SealAudit can help prove

  • A trigger endpoint was accessed at a specific time.
  • A specific published workflow version was used.
  • Configured verification rules passed, failed, were bypassed, or returned errors.
  • One or more workflow actions were attempted or completed.
  • An acknowledgement was captured against a specific document version or prompt.
  • Stored audit events have not been silently altered within normal product control boundaries.

What SealAudit does not claim

  • A QR scan alone does not prove a person physically touched a printed sign.
  • Geolocation can strengthen proof-of-presence, but it is not perfect anti-spoofing.
  • Acknowledgements are operational sign-offs in MVP, not legally binding digital signatures.
  • Tamper evidence detects unexpected record changes; it does not guarantee fraud prevention.

Review and export

Evidence that can leave the product cleanly.

Audit trails should be reviewable by compliance teams and external auditors without requiring them to infer context from unrelated operational logs.

  • Chronological audit event review for compliance investigations.
  • Filtering by workflow, trigger, site, actor, event key, and date range.
  • Machine-readable exports suitable for auditor review and internal evidence packages.
  • Integrity checks that compare each event hash with the previous event in the chain.

Auditor FAQ

Questions compliance reviewers usually ask first

How is the audit trail different from ordinary logs?

Ordinary logs usually help teams operate and troubleshoot a product. SealAudit audit events are designed for compliance review: they are append-only, linked to operational records, and chained so unexpected changes can be detected.

What does hash-chain tamper evidence mean?

Each audit event stores a deterministic hash of its canonical event data and a reference to the previous event hash for the organization. If a stored event is changed later, recalculating the chain reveals the mismatch.

Can auditors review evidence without changing records?

The product model supports read-only auditor access, searchable audit history, exports, and integrity review so evidence can be inspected without weakening traceability.

Does SealAudit replace legal e-signature software?

No. MVP acknowledgements are compliance workflow sign-offs tied to workflow and document context. They should not be described as legally binding digital signatures.

Next step

Evaluate the workflow model behind the evidence.

Review how Trigger, Verification, and Action work together, or start a free workspace to model your first compliance workflow.