Security & Privacy

01 / Sign-in

Account and session information

Email and password sign-in is enabled. Account registration sends an email verification message, and the signup flow directs accounts that are not yet verified to a pending verification step. Some billing and workspace operations also check verification state.

• Account records include a name, email address, email-verification state, role, and an optional profile image.
• Session records have optional IP-address and browser user-agent fields. They may be present; the app source does not document when they are populated or how long they are retained.

02 / Product records

Projects, calculations, and workspaces

• Project records include a project name and may include a selected NEC edition.
• Saved calculation records include submitted inputs and results, including Raceway Fill, Ampacity, Voltage Drop, and NEC 314 runs.
• Workspace records include workspace names, member identifiers and roles, and invitation email addresses, roles, and expiry dates.
• Company seat-purchase records include seat count, billing interval, amount, checkout session identifier, status, and verification time.
• Optional company profile details include business and licensing information, contact name, email and phone, mailing address, website, and logo.

03 / Application checks

Access controls

• The project and saved-calculation API flows reviewed require a signed-in account. Personal project and run requests are checked against the account that owns them.
• Shared-project flows check workspace membership and role. Workspace administrators can manage membership and shared-project changes; estimator/engineer members can edit shared projects; field foremen have read access in the shared saved-run flow.
• These are application-level checks observed in the reviewed flows, not a complete security audit or a guarantee about every risk.
• The browser policy restricts which scripts can run and blocks other sites from embedding WireWicket in a frame in browsers that enforce the policy.

04 / Browser storage

Offline calculations and analytics

• Raceway Fill, Ampacity, and Voltage Drop calculations queued while offline can be stored in the browser’s IndexedDB. A queued record can include its user and project identifiers, submitted payload, and result snapshot while it waits to sync.
• The service worker caches public app-shell pages and same-origin static assets. It skips API, sign-in, signup, profile, dashboard, admin, and workspace paths.
• The app creates a persistent polsia_vid identifier in local storage and sends a page-load beacon with that identifier and the deployment slug to the configured Polsia analytics endpoint (default host polsia.com). The app source does not document further beacon use or retention.
• Product measurement records an internal account ID, fixed event and feature keys, fixed offer keys, whether a recorded checkout is recurring, source record/import IDs, timestamps, provider event IDs, checkout session IDs, an allowlisted payment classification, and buyer-paid gross USD only when the payment feed supplies it. Payment customer email is used transiently to match a provider event to an account and is not stored in these event records.
• These events support trial-cohort and saved-workflow reporting for administrators. The report returns aggregates only; it does not include account IDs, emails, checkout IDs, submitted calculation inputs, calculation results, project names, IP addresses, or browser user-agent values. Historical source records are labeled as record counts and are not backfilled into trial or feature events. Product event and checkout attribution rows are pruned after 12 months. The independent page-view beacon above remains separate.

05 / Sharing and checkout

Shared links and payments

• An owner can publish a submittal-verification snapshot at a token URL. The owner can add a password or expiry and can revoke the link. An active, published snapshot is available to anyone with the token URL; when a password is set, the recipient must provide it.
• Checkout uses the signed-in account’s email and selected offer to create a hosted Stripe Checkout session. The app also keeps purchase records used for access, such as checkout session identifiers and seat-purchase details.
• These observed handoffs and app records do not establish what Stripe or Polsia retain.