Reliability before spectacle.

The Operator’s prime directive is that user writing must not be placed at risk. That includes manuscripts, chapters, unpublished drafts, encrypted payloads, beta-reader copies, and author notes. Reliability and access control take precedence over speed and visual polish.

Chapter bodies are stored as versioned encrypted envelopes. Encryption logic lives in a dedicated shared package; the user interface must not implement a second crypto path, silently decrypt, or render ciphertext as if it were text.

User content keys are created and wrapped on trusted devices. The server stores wrappings, device records, and recovery seals—not a plaintext master key that would let staff open a chapter in the database console.

If you lose every trusted device and cannot complete a governed recovery path, we may be unable to restore plaintext. That is an intentional property of the model, not an oversight.

Protected actions require an authenticated session, product access, a permission or role, and a resource grant where one applies. Those checks are enforced in the /api/v3 backend. A hidden button or client route is not an access control.

Book and chapter grants are explicit. Social features (profiles, friends, messages, rooms) never substitute for a content grant. Homelab requires a staging entitlement before protected application routes are usable.

Production traffic is served over HTTPS. Production responses include industry-standard security headers (including HSTS, frame denial, and nosniff). A content-security policy is not yet asserted on the public site because third-party challenge and embedded studio surfaces would break a naive policy.

Authentication, relational data, and object storage are provided by our database and auth vendor. Application compute is provided by our host. Transactional email is sent through a dedicated provider. Push addressing, where enabled, uses the relevant operating-system service.

Homelab is private staging, noindexed, and visually marked as such for authenticated operators. It is not a second production.

Security-relevant events—authentication, access decisions, decrypt and save operations, exports, and deployments—are written as structured audit records. Logs are designed to exclude passwords, tokens, raw keys, and chapter plaintext.

We do not claim formal certification (for example SOC 2 or ISO 27001) on this page. We do not claim that encryption survives a compromised endpoint, a malicious grantor, or a user who pastes plaintext into email or an unencrypted note.

You remain responsible for the physical and logical security of your devices, the people you grant, and any export you download. Desktop sideloads and TestFlight builds may have a different review and update posture than a later store release.

If you believe an account, device, grant, or manuscript has been compromised, email jacob@jacobhallmark.com immediately with a clear subject such as “Security incident.” Do not attach unpublished chapter plaintext unless we ask you to use a governed channel.

If you are a researcher and have found a vulnerability in a system you are authorized to test, describe the issue without including exploit code, credentials, or other users’ data. We will acknowledge good-faith reports that arrive at the same address.