Security & privacy

A clear view of how RafterDocket handles your paperwork.

RafterDocket helps small contractor teams move compliance paperwork from job inbox to closeout. This page explains the controls visible in the current product code and calls out what that code does not establish.

The useful answer is sometimes a limit. Where the current implementation does not document a guarantee, we say so plainly instead of turning a web control into a certification or promise.

Encryption

The verified web configuration includes HTTP Strict Transport Security withmax-age=63072000; includeSubDomains; preloadand an upgrade-insecure-requests directive. These browser-facing controls tell supported browsers to prefer secure requests and remember the HTTPS policy.

Current boundary. This repository does not establish a specific encryption-at-rest algorithm, key-management practice, provider-level encryption commitment, or end-to-end encryption claim. It does not make a claim here about AES, a particular TLS version, or database-at-rest encryption.

Data protection

The browser and server posture includes a per-request Content Security Policy nonce with strict-dynamic for scripts, along with frame-ancestors 'none', object-src 'none', and form-action 'self'. It also sets X-Frame-Options to DENY, X-Content-Type-Options to nosniff, a strict referrer policy, and same-origin Cross-Origin-Opener-Policy and Cross-Origin-Resource-Policy.

The Permissions-Policy is locked down: camera, microphone, geolocation, and browsing-topics are disabled. Application records are handled through server-side routes, and secret-bearing helpers are kept server-only. These are meaningful defense-in-depth controls, but they are not a claim of complete security, a certification, or an independent audit.

User permissions

RafterDocket uses better-auth for email/password sign-in and requires email verification during sign-up. Session-based requireAuth() checks protect signed-in application routes. Workspace membership distinguishes owner and member roles, active-subscription access gates workspace data, and admin-role checks protect admin surfaces.

Workspace invitations are created by an owner. The app stores a SHA-256 hash of each invite token, makes an invite single-use, and expires it after seven days. The current inspected configuration does not establish a particular password-strength policy or multifactor authentication, so neither is promised here.

Document access controls

The job, compliance-draft, closeout, recipient, delivery-history, and app-specific document-PDF handlers require an authenticated user with active workspace access. Their queries scope records by the signed-in user and by the relevant workspace or job ownership, rather than relying on an identifier alone.

Completed job PDF responses use cache-control: no-store. Document deliveries record the recipient and delivery status history, so the handoff remains visible in the job record.

Current boundary. The framework's generic /api/pdf/document route accepts validated caller input without authentication and is not the source of stored customer documents. It should not be presented as an authorization boundary for customer document access.

Backups

The public product implementation does not document a backup frequency, restore procedure, recovery point objective, recovery time objective, or backup durability guarantee.

Current boundary. This is a current limitation, not an implied schedule or recovery SLA. Contact us if you need to discuss backup and restore operations for your evaluation.

Data retention

The current models persist account, workspace, job, document-draft, and delivery-history records with creation and update timestamps. Those timestamps help the application manage its records, but they do not by themselves define a retention policy.

Current boundary. The app does not expose a verified retention period, deletion workflow, or purge SLA. This page makes no fixed retention commitment; contact us for current questions about retention or deletion.

Account security

Account access uses email/password sign-in, verification-link delivery, and session-based access checks. A signed-in user can visibly sign out, while admin capabilities require the separate verified admin role. Together, these are the access distinctions currently visible in the product.

Use a unique password for RafterDocket and avoid reusing it elsewhere. The current product code does not document password rotation, multifactor authentication, account-recovery guarantees, or breach monitoring, so those protections are not represented as available controls on this page.

Questions?

Ask about the details that matter to your team.

This page describes controls visible in the current product code. It does not create a warranty, certification, retention commitment, or backup SLA. For current questions about infrastructure, deletion, retention, or recovery, contact RafterDocket directly.

Email RafterDocket

Questions go to rafterdocket-888@polsia.app