Skip to content

Trust & security

Sensitive operating work needs visible boundaries.

SOVHELM is designed for founder-led groups where work can belong to different ventures, legal entities, roles, stakeholders, and private records. The trust model is practical: publish the company posture, prove who can see what, show how records persist, explain how access changes are reflected, and recover the audit trail later.

SOVHELM LLC accountability Venture & role-based access Private records & restricted evidence Audit history & reference recovery Supabase-backed persistence Separated demo & live workspaces

Company operator

SOVHELM LLC operates the product.

Run through a company-led public identity and a monitored support route.

Access boundary

Scoped to role and venture.

Workspace, venture, function, role, investor, supplier, assistant and private-record scopes.

Demo separation

Demo never exposes live records.

Public demos and live customer workspaces are kept separate.

AI boundary

Customer data is customer data.

Customer workspace data is not used to train AI models.

Data posture

Company facts and infrastructure facts are separated from personal identity.

SOVHELM publishes company, product, support, data-handling and deployment facts so buyers can review the service at company level. Product controls, support responsiveness, data handling and rollout commitments are documented before sensitive records move in.

Company

SOVHELM LLC

SOVHELM is operated by SOVHELM LLC, a Wyoming limited liability company. Company contact is sales@sovhelm.com.

Current hosted model

Vercel delivery, Supabase persistence.

Live workspace records are designed around Supabase Auth, Postgres, Row Level Security and private storage. The website and app shell are hosted through Vercel.

Access enforcement

UI checks are not the boundary.

Hosted workspaces rely on database-side access rules and server-side privileged actions. Frontend hiding is treated as usability, not security.

Derived data

Derived surfaces follow permissions.

Search, notifications, attachment metadata and AI-assisted signals stop showing restricted content to users who no longer have permission.

01

Tenant and venture separation

Each organization is the tenant boundary. Inside it, ventures, functions, legal entities and private records restrict what each user sees.

02

Role-scoped access

Founder, partner, manager, team, investor, supplier and delegated assistant views expose only the records needed for that role and scope.

03

Persistent operating record

Tasks, comments, attachments, notifications, generated work, access changes and audit events remain traceable over time.

04

Sync and recovery visibility

Live workspaces surface save state, failed-save recovery, account setup and sync diagnostics so records are not silently lost.

Operating chain

Control is checked record by record, not by slogan.

SOVHELM is strongest when the customer can trace the chain from organization to venture, legal entity, function, OKR, project, task, comment, attachment, notification, audit log and search result. Each layer keeps the same visibility boundary.

TENANT

Organization & workspace boundary

SCOPE

Ventures, functions, legal entities & private records

WORK

OKRs, projects, tasks, decisions, risks, obligations & scheduled work

EVIDENCE

Comments, mentions, attachments, notes, audit logs, search & notifications

RECOVERY

Reference IDs, sync status, exports, deletion, support access, AI use & deployment

Assurance matrix

What is controlled in product, reviewed in rollout, and plan-dependent.

Controlled in product

Workspace, venture & role boundaries

Organization scoping, venture separation, function access, private records, delegated assistant scope, permission-aware search and visibility checks.

Controlled in product

Evidence & sync state

Comments, mentions, attachments, notifications, status changes, generated tasks, failed-save recovery, sync visibility and audit logs stay traceable.

Reviewed before rollout

Live and demo separation

Which demo data, live records, user roles, attachments and public guided-demo routes are available to each audience.

Reviewed before rollout

Support & administration

Admin responsibilities, support access expectations, user onboarding, suspended users and reset workflows.

Plan-dependent

Hosting & deployment model

Standard hosted workspaces are the starting point. Regional hosting, private deployment or customer-controlled models can be discussed where required.

Plan-dependent

Advanced assurance requests

Private infrastructure, subprocessor review, custom contractual terms or deeper security review.

Assurance review

Claims stay evidence-based.

Public trust statements are limited to implemented product controls, infrastructure posture and agreed contractual commitments. Customer-specific assurance requests are handled during rollout review.

Founder walkthrough package

Test the operating boundary before sensitive records move in.

A serious rollout starts with representative ventures, legal entities, users, workflow records, private notes, files and access rehearsals. The walkthrough proves the right people see the right work and the wrong people do not.

Request private fit review

Detailed control posture

These notes describe the public trust posture. Customer-specific commitments, regions, support access, subprocessors and private deployment terms are confirmed in the relevant order form, customer agreement or data processing agreement.

Access control

SOVHELM is designed to support role-based permissions for founders, partners, managers, team members, investors, suppliers and delegated assistants. Venture-level separation is a core principle so users only see the businesses, entities, projects, obligations, files and records they are allowed to see.

Demo and live workspace separation

Public demo workspaces are separated from live customer workspaces. Demo accounts are intended for product exploration and guided review. Live customer workspaces use the customer’s organization boundary, membership, role assignments, venture scopes and data-store persistence rules.

Persistence and sync recovery

Live operating records are designed to persist through the Supabase-backed data store. The application surfaces sync state, retry behaviour, failed-save recovery and workspace refresh controls so important work is not treated as disposable browser state.

Auditability

Audit logs are intended to help teams understand important changes across ventures, compliance obligations, risks, decisions, comments, mentions, notifications, attachments, generated work and access-sensitive actions.

Customer data and AI

Customer workspace data belongs to the customer. SOVHELM does not use customer workspace data to train AI models. Assisted capabilities are designed to process workspace records for the customer’s own operating signals, subject to the agreed controls and deployment model.

Data protection

SOVHELM production infrastructure uses HTTPS, hardened deployment headers, controlled access to operational systems, service-side privileged actions where required, monitored operational logs, and appropriate backup and recovery practices. Customer data processing is documented as part of workspace onboarding and contractual setup.

Infrastructure providers

The current hosted model uses Vercel for application delivery and Supabase for Auth, Postgres, Row Level Security and private storage. Additional services such as email delivery or analytics may be introduced only for the purpose needed and should be reviewed where a customer has stricter requirements.

Encryption and transport

Public and hosted application traffic is served over HTTPS. Hosted workspace storage uses provider-managed database and storage protections. Customer-specific encryption, key management or private infrastructure requirements should be reviewed before sensitive import.

Hosting and data residency

Incorporation jurisdiction, hosting region, support access, subprocessors and data transfer terms are separate concerns. Customers with stricter sovereignty, client, investor or regulatory requirements can discuss regional hosting, private deployment or customer-controlled operating models before sensitive data is imported.

Support access

SOVHELM support access to customer workspaces is limited to operational support needs. Higher-control plans may include owner-approved support access, access logging and reduced vendor access modes where appropriate for the deployment.

Deletion, backup, and recovery

Workspace retention, backup, export, deletion and recovery expectations should be agreed during onboarding. The product is designed to preserve audit history and reference recovery where appropriate, while sensitive erasure requests need controlled handling so related records do not become misleading.

Assurance status

SOVHELM publishes implemented controls and support commitments rather than unsupported badges. Formal assurance packages, uptime commitments, audit materials or customer-specific security reviews are provided only when they are agreed, documented and available for the relevant customer plan.

Lawful requests

SOVHELM only discloses customer data where legally required. Where legally permitted, we aim to notify the customer before disclosure and challenge requests that are improper, excessive or not valid for the relevant jurisdiction.

Responsible disclosure

If you believe you have found a security issue, contact security@sovhelm.com with enough detail for review. Please do not access, modify, delete or disclose data that does not belong to you.