Audit-grade publishing, by architecture — not by addendum.

The scene that makes this page exist.

A customer files a claim on August 15 for an event that happened on August 9. The policy was retroactively endorsed on August 10 — adding an exclusion the customer didn't see when they logged into the portal on the 13th to begin the filing. Legal asks the question that ends most CMS conversations:

"What exactly was on the portal when our customer logged in on August 13?"

Most content management systems cannot answer that question with the precision the question requires. They can tell you what's there now. They can tell you the timestamp of the last edit. They cannot reconstruct the page as it appeared, including every variable that changed it — content, template, theme, routing rule, embedded asset — at a specific instant in the past, with cryptographic confidence that the reconstruction is what was actually served.

StaticOwl can. The rest of this page explains how, and how that capability maps to your specific regulatory framework.

Three questions you're going to ask.

Direct answers first. Mechanism second.

1. Can you answer "what was published on August 13?" with cryptographic certainty?

Yes, by design. Every state of every content node — page, template, route, theme setting, media asset — is preserved as an immutable fact in a bitemporal graph. The graph carries two time dimensions per record: valid time (when the fact applied in the real world) and transaction time (when you recorded it). The August-13 question becomes a single graph query, not a subpoena-response archaeology project. The render that comes back is the page exactly as it appeared, including the linked schedule, the disclosure copy, the legal footer, the assets referenced.

2. Are records immutable? Can an administrator silently rewrite history?

No, and we ship cryptographic evidence of that. The graph engine (InvariantDB, our database layer) maintains a hash chain over every mutation. Each new fact's hash is computed over its content plus the previous hash. Any tampering — including by us — breaks the chain in a way that's verifiable by an external auditor with read-only access to the WAL. You can run that verification yourself; the procedure is documented and the verifier ships as a separate binary.

3. What are the data retention guarantees, and what happens if StaticOwl disappears?

Your data is yours, and you can take it out without us. The compiled output of every release is plain HTML/CSS/JS/assets in an S3 bucket. You can either own the bucket (BYO mode) or have us own it (managed tier); either way, you have export rights. The source content — every page, every field, every asset — is exportable as clean JSON or HTML at any time. The audit history is exportable as a verifiable evidence bundle. Nothing is in a proprietary format; nothing requires our continued existence to read.

The architecture, for the security architect.

Source of truth: bitemporal append-only graph

The content layer is a graph database (InvariantDB) configured in append-only mode. No record is ever overwritten in place. When you "edit" a page, the graph records a new version with valid_from set to the moment that version becomes the truth, and the previous version's valid_to set to the same instant. Versions can also be retroactively dated (you record on Aug 14 a fact that applied starting Aug 10) by setting valid_from independently of when the write happened. Both timestamps are preserved.

Cryptographic audit chain

Every mutation is appended to a write-ahead log (WAL) that's hash-chained: h(n) = SHA-256(h(n-1) || mutation_n). The chain head is published with each release. An external auditor with read-only access to the WAL can verify the chain end-to-end without trusting us. We use this verification ourselves — the binary is bin/verify-audit-chain, shipped with every release. (See SECURITY.md for the verification protocol and the engine team's threat model.)

Compiled artifacts as deploy unit

A deploy is not "push these edits to production." A deploy compiles the current state of the graph at a specific instant into an immutable bundle (HTML pages, sidecar JSON, manifest, signed lineage) and assigns it a Release ID. The CDN serves whatever Release is currently pointed at; rollback is the same operation in reverse — a new deployment fact that points at an older Release. Releases are cryptographically content-addressed; their hashes are stamped into the audit chain.

Reviews are first-class

Releases gate on Reviews — AI-powered (we run alt-text checks, broken-link scans, SEO regressions, etc.), automated (custom rules you write), manual approval (named reviewers per content type), and compliance checks (custom). Blocking findings prevent deploy with a 409 Conflict; reviewers and findings are recorded as graph facts tied to the Release ID. The audit answers "who approved this" with the named human or the named automated check.

Replay any past instant

Because every state of the graph is preserved, we can re-render the site exactly as it appeared at any past instant. Not "approximately." Bit-for-bit, the same compile applied to the historical graph state produces the same artifact, with the same hash. We use this for our own regression testing; you can use it for evidence preservation.

Framework alignment.

Direct mapping to the specific clauses your audit team is going to ask about. Where we're aligned by design, we say so; where the alignment requires customer-side configuration, we say that too; where the framework doesn't apply, we say nothing.

SOX (Sarbanes-Oxley, §302 + §404)

Section 302 requires officers to certify internal controls over financial reporting; §404 requires management to assess and attest those controls annually. For published content (10-K disclosures, investor relations updates, earnings releases): every release is signed, every reviewer is named, every change is reversible, every past state is reconstructable. The release log is the control evidence.

HIPAA (Health Insurance Portability and Accountability Act, §164.312)

§164.312(b) requires audit controls — hardware, software, and procedural mechanisms that record and examine activity. The hash-chained WAL is the audit control. §164.312(c) requires integrity controls; the cryptographic chain is the integrity proof. Note: we do NOT process PHI on behalf of customers. If your published content avoids PHI (most marketing/patient-portal content does), we are out of scope as a Business Associate. If your use case is PHI-bearing, talk to us directly — there are deployment patterns that keep us out of the PHI path.

FDA 21 CFR Part 11 (Electronic Records, Electronic Signatures)

Part 11 §11.10 requires controls over the integrity, authenticity, and confidentiality of electronic records: validation, audit trails, operational checks, authority checks, device checks, person accountability. The bitemporal graph + reviews + cryptographic chain map to §11.10(e) audit trails directly. §11.50 (signature manifestations) — signed reviews with named reviewers map here. We have NOT been through FDA validation for any specific use case; the architecture supports it; the customer-side validation effort is the customer's. We can support that effort with a Validation Package; talk to us.

NAIC Model Audit Rule (Annual Financial Reporting Model Regulation)

For insurance carriers: Section 12 requires evidence of internal controls over financial reporting; Section 14 requires that material changes to those controls be reported. The same release log + reviewer log that satisfies SOX §404 satisfies the NAIC §12 evidence requirement. Customer-side mapping to specific Schedule documentation is the customer's; we provide the underlying audit data.

GDPR Article 17 (Right to Erasure)

This one is the awkward one. Append-only architecture and right-to-erasure are in tension. Our resolution: subject content (e.g., a customer testimonial that includes the subject's name) can be erased on request — the graph supports tombstone-via-redaction where the record is replaced by an opaque marker that preserves the chain but removes the PII. The fact that an erasure happened remains in the chain (you can't erase the erasure); the content erased is genuinely gone. This satisfies Article 17 for personal data while preserving the audit chain's integrity for everything else. We ship this as destroySubjectKey() at the engine layer.

What's shipped, what's coming.

Honest accounting. We're in early access, so this matters more than usual.

Shipped today, ready to ship to you

• Bitemporal append-only graph — InvariantDB engine layer, production-stable across multiple customers.
• Cryptographic audit chain — hash-chained WAL with external verification binary (Sprint 3, 23 regression tests pinning tamper-detection paths).
• Releases as immutable compiled artifacts — content-addressed bundles, manifest pointer flips for atomic deploy/rollback.
• Reviews gate Releases — AI / automated / manual / compliance review types, blocking findings, signed by reviewer.
• Bitemporal queries — db.diff, db.changes, db.propertyHistory, db.replay procedures (Sprint 1 + 1.5, 37 + 14 + 50 tests).
• Subject erasure for GDPR — destroySubjectKey() with chain-preserving tombstones.
• Export — full content + audit-bundle export to S3 / GitHub / local disk.

Roadmap, named so you can plan

• SOC 2 Type II — engagement starts Q3 2026 with a top-quartile auditor. Type I report by Q4. Talk to us before then for design-partner-level diligence access.
• HIPAA BAA — available for the Business tier on request; we'll execute one if your use case requires it.
• FedRAMP — not on the immediate roadmap. If your use case needs it, talk to us about a path.
• Hosted-in-region — EU-hosted instance scheduled Q1 2027. Self-host mode is available today if data residency matters now.

Things we're not going to claim

• We do not have SOX, HIPAA, FDA, NAIC, or GDPR certifications. We have architecture that aligns with those frameworks' technical requirements. The certifications are customer-side audit efforts; we provide evidence support.
• We are early-access. Production SLAs are 99.9% on the managed tier today; we'll publish actual measurements quarterly once we have a year of operating data.
• We are a small team. Procurement responses come from a founder. That's a feature for design partners and a constraint to be aware of for enterprises with long procurement cycles.

Next steps.

If you've read this far, you're either evaluating us seriously or someone on your team really wants you to. Three paths from here, in order of effort:

1. Send us your procurement questionnaire. We'll answer every question with a direct citation to architecture, code, or a documented limitation. Reply to founders@staticowl.com; we'll get back within a business day.
2. Read the architecture docs. /docs/architecture/ covers the engine layer in detail — graph model, WAL format, hash chain construction, release manifest schema. Public, no signup required.
3. Get a developer key and try it. 60 seconds, no card. Request a key. The same API surface your team would use is available to you; the audit chain is on from the first write.

This page is itself a content record in the StaticOwl graph. The version you're reading was published as Release r…; the previous version, if any, is one query away. The audit chain entry for this publication is verifiable with verify-audit-chain --release=…. Even our marketing pages prove what they claim.